- mice-discuss - lists.micemn.net

Re: Potential MICE member agreement

by Jeremy Lumby

Reid, I knew I might open up a can of worms since I do not have a whole lot of peering experience. Could you mention a couple hypothetical situations to help some of the less experienced members better understand some of the issues. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Sunday, December 16, 2012 11:11 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Potential MICE member agreement Speaking from experience, and NOT as a Hurricane employee, you are thinking it is easy to expand peering. Trust us, it isn't. Its not just emailing them and connecting a new cable. There are MANY reasons why some peers are what they are. Again, let me state that I am NOT talking as a Hurricane Employee. Thus, as a member of the steering committee, I would have to vote against any agreement which tries to understand peering agreements. Reid On Sun, Dec 16, 2012 at 11:49 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I have not heard much discussion of maintenance fees lately, however a recent set of two situations brought an idea to the front of my mind. Should MICE have a very basic agreement with each of its members? The reason I bring this up is that we want to keep everyone's experience with the community positive. For example the agreement could contain a requirement to upgrade your connection if it is saturated to the point of causing packet loss (which I would assume members would want to do on their own). The reason I bring this up is because in the past few months I have run across carriers that I am purchasing from that had saturated peering. The two different carriers had two completely different approaches, and the second one concerns me, and is the reason I bring up the MICE agreement. The first was with Hurricane. They had a saturated link to Charter in Chicago. Within an hour of emailing in the details of what I had found to support, they had confirmed the issue, started sending me regular updates until the link upgrade was completed. Due to the short time period that this trouble ticket lasted, I felt it went much better than I would have hoped. The second issue was with Cogent. They had, and possibly still have a saturated peering link with TimeWarner in Chicago. It took me 3 emails with support across 2 business days to get them to believe the issue existed, and then once they got on the same page as me, the would not even provide me with updates on if they will even fix the issue. I have included their final support email below. After waiting a few days hoping they would just fix it, I was forced to manipulate BGP to avoid this saturated link. The bottom line is I bring this up because even though I am a paying customer of both carriers, the second situation made me feel powerless, and that I was not valued as a customer. I realize that they probably have their legal reasons to keep me in the dark, however it has now made me an unhappy customer, and if there was a simple agreement in place about how the peering link should be maintained, then there would be a timeframe for this to be resolved within. Jeremy -----Original Message----- From: Cogent Help Desk [mailto:support@cogentco.com] Sent: Wednesday, December 05, 2012 7:03 PM To: jlumby(a)mnvoip.com Subject: RE: #HD0000005266692-RE: Related Case: HD0000005265974-Packet Loss for customer TWINCITY00001 Dear Cogent Customer, The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with our peer TimeWarner . Our peering engineers have made them aware of the continuing issue and are pending their response. Cogent is ready to act as soon as we have cooperation from our peer and they are ready to move forward. There is no estimated time of resolve. Please understand that Cogent does not discuss peering specific plans with our customers. Our customer support group will not be able to provide regular updates in regard to peer maintenance. If you have any questions please feel free to contact us by e-mail at support(a)cogentco.com or by phone at 877-7COGENT (877-726-4368). Thank You, Cogent Communications T 877.726.4368, option 2 F 202.295.9061 E support(a)cogentco.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Reid Fishler To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by Doug McIntyre

On Sun, Dec 16, 2012 at 09:11:00PM -0600, David Farmer wrote: > What every you did its announcing the new next-hop addresses now. > Maybe you were having a similar issue to what the CDW/Berbee guys > were. I apologize, and hopefully everyone's issues are as simple. ... There is an oddity in the route servers, in such that, even though they are configured to present the router-ID in the new session as the new IP, that they have been seen to be using the old IP address to connect to the remote host for the new session. It could be this sort of oddness that triggers some sides to be announcing out the old next-hop for their blocks. This is what I accounted for on one announcement previously. Digging into the route tables on the route servers, only one AS isn't dual announcing, and since you already named it, we could do the push on them. AS 15011. Although they did respond to me privately a couple weeks ago that they know they need to get this done ASAP. The others that are showing up with 69.147.218/24 next-hops are all dual-announcing as far as I can tell, and a few blocks just happen to have choosen the announcement with the old-next hop in there (especially on the 2nd RR), but all others are dual-announcing. It is almost to the point where we should clean up the route servers. We are sitting pretty good for the renumbering project for the final stretch. I think everybody but AS15011 is ready to go and drop the old block, although the schedule allows that to have happened on the 1st of the month already. -- Doug McIntyre <merlyn(a)iphouse.net> -- ipHouse/Goldengate/Bitstream/ProNS -- Network Engineer/Provisioning/Jack of all Trades ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by David Farmer

I want to thank several of you for finding and fixing issues, here's what's left; * 63.144.82.0/23 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i *> 66.44.129.0/24 69.147.218.107 180 0 25615 23430 23430 i *> 66.44.152.0/22 69.147.218.107 180 0 25615 23430 23430 i *> 66.44.166.0/24 69.147.218.107 180 0 25615 23430 23430 23430 23430 i *> 66.44.176.0/22 69.147.218.107 180 0 25615 23430 23430 i * 70.35.96.0/20 69.147.218.107 180 0 25615 32264 ? * 199.86.16.0/22 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 199.199.147.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 199.199.151.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.8.2.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.90.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.205.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.208.0/23 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.215.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.216.0/23 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.220.0/23 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.9.240.0 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i * 206.53.192.0/21 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i *> 206.146.40.0/21 69.147.218.107 180 0 25615 21730 i * 209.131.224.0/21 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i *> 209.191.222.0 69.147.218.107 0 180 0 25615 i * 216.188.192.0/19 69.147.218.105 0 180 0 15011 i *> 69.147.218.105 0 180 0 15011 i On 12/16/12 19:45 , David Farmer wrote: > OK, I think it is now time for a little public shaming; the following > MICE participants are only announcing their prefixes using the old > next-hop addresses through the route servers. We were all suppose to be > using only the new addresses as of two weeks ago. There is one other > participant announce with both the old and the new next-hop address, we > (Northern Lights GigAPOP) just stopped doing this earlier today, and are > now announcing using only the new next-hop addresses. All other > participants are announcing to the route servers are using only the new > next-hop addresses. > > AS33362 Wikstrom Telephone Company (Wiktel) > AS25694 Atomic Data > AS15011 Jaguar Communications > AS3599 CDW/Berbee > > Please convert your peering session to announcing with the new next-hop > addresses, ASAP. If for some reason you can't do this in the next week, > please send a note to the MICE-DISCUSS mailing list detailing when you > will be converting. > > As a reminder, here is the original cutover schedule that was emailed > out several months ago: > > Addition of Address Secondary: before 10/1/2012 > New Prefix Announcements: after 10/1/2012 > Final use of old IP address next-hop: before 11/30/2012 > Removal of old IP address range: after 12/1/2012 > Project End: 12/31/2012 > > Thanks. -- ================================================ David Farmer Email: farmer(a)umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: Potential MICE member agreement

by Reid Fishler

Speaking from experience, and NOT as a Hurricane employee, you are thinking it is easy to expand peering. Trust us, it isn't. Its not just emailing them and connecting a new cable. There are MANY reasons why some peers are what they are. Again, let me state that I am NOT talking as a Hurricane Employee. Thus, as a member of the steering committee, I would have to vote against any agreement which tries to understand peering agreements. Reid On Sun, Dec 16, 2012 at 11:49 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I have not heard much discussion of maintenance fees lately, however a > recent set of two situations brought an idea to the front of my mind. > Should MICE have a very basic agreement with each of its members? The > reason I bring this up is that we want to keep everyone's experience with > the community positive. For example the agreement could contain a > requirement to upgrade your connection if it is saturated to the point of > causing packet loss (which I would assume members would want to do on their > own). > > The reason I bring this up is because in the past few months I have run > across carriers that I am purchasing from that had saturated peering. The > two different carriers had two completely different approaches, and the > second one concerns me, and is the reason I bring up the MICE agreement. > The first was with Hurricane. They had a saturated link to Charter in > Chicago. Within an hour of emailing in the details of what I had found to > support, they had confirmed the issue, started sending me regular updates > until the link upgrade was completed. Due to the short time period that > this trouble ticket lasted, I felt it went much better than I would have > hoped. > > The second issue was with Cogent. They had, and possibly still have a > saturated peering link with TimeWarner in Chicago. It took me 3 emails > with support across 2 business days to get them to believe the issue > existed, and then once they got on the same page as me, the would not even > provide me with updates on if they will even fix the issue. I have > included their final support email below. After waiting a few days hoping > they would just fix it, I was forced to manipulate BGP to avoid this > saturated link. > > The bottom line is I bring this up because even though I am a paying > customer of both carriers, the second situation made me feel powerless, and > that I was not valued as a customer. I realize that they probably have > their legal reasons to keep me in the dark, however it has now made me an > unhappy customer, and if there was a simple agreement in place about how > the peering link should be maintained, then there would be a timeframe for > this to be resolved within. > > Jeremy > > -----Original Message----- > From: Cogent Help Desk [mailto:support@cogentco.com] > Sent: Wednesday, December 05, 2012 7:03 PM > To: jlumby(a)mnvoip.com > Subject: RE: #HD0000005266692-RE: Related Case: HD0000005265974-Packet > Loss for customer TWINCITY00001 > > Dear Cogent Customer, > > The latency and/or packet loss that you are experiencing to this > destination is due to occasional high traffic with our peer TimeWarner . > Our peering engineers have made them aware of the continuing issue and are > pending their response. Cogent is ready to act as soon as we have > cooperation from our peer and they are ready to move forward. There is no > estimated time of resolve. > > Please understand that Cogent does not discuss peering specific plans with > our customers. Our customer support group will not be able to provide > regular updates in regard to peer maintenance. If you have any questions > please feel free to contact us by e-mail at support(a)cogentco.com or by > phone at 877-7COGENT (877-726-4368). > > Thank You, > > Cogent Communications > T 877.726.4368, option 2 > F 202.295.9061 > E support(a)cogentco.com > > ######################################################################## > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > -- Reid Fishler ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: Potential MICE member agreement

by Richard Laager

On Sun, 2012-12-16 at 22:49 -0600, Jeremy Lumby wrote: > I have not heard much discussion of maintenance fees lately At this point, I this is dependent on the steering committee. Perhaps we can hear from them? -- Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Potential MICE member agreement

by Jeremy Lumby

I have not heard much discussion of maintenance fees lately, however a recent set of two situations brought an idea to the front of my mind. Should MICE have a very basic agreement with each of its members? The reason I bring this up is that we want to keep everyone's experience with the community positive. For example the agreement could contain a requirement to upgrade your connection if it is saturated to the point of causing packet loss (which I would assume members would want to do on their own). The reason I bring this up is because in the past few months I have run across carriers that I am purchasing from that had saturated peering. The two different carriers had two completely different approaches, and the second one concerns me, and is the reason I bring up the MICE agreement. The first was with Hurricane. They had a saturated link to Charter in Chicago. Within an hour of emailing in the details of what I had found to support, they had confirmed the issue, started sending me regular updates until the link upgrade was completed. Due to the short time period that this trouble ticket lasted, I felt it went much better than I would have hoped. The second issue was with Cogent. They had, and possibly still have a saturated peering link with TimeWarner in Chicago. It took me 3 emails with support across 2 business days to get them to believe the issue existed, and then once they got on the same page as me, the would not even provide me with updates on if they will even fix the issue. I have included their final support email below. After waiting a few days hoping they would just fix it, I was forced to manipulate BGP to avoid this saturated link. The bottom line is I bring this up because even though I am a paying customer of both carriers, the second situation made me feel powerless, and that I was not valued as a customer. I realize that they probably have their legal reasons to keep me in the dark, however it has now made me an unhappy customer, and if there was a simple agreement in place about how the peering link should be maintained, then there would be a timeframe for this to be resolved within. Jeremy -----Original Message----- From: Cogent Help Desk [mailto:support@cogentco.com] Sent: Wednesday, December 05, 2012 7:03 PM To: jlumby(a)mnvoip.com Subject: RE: #HD0000005266692-RE: Related Case: HD0000005265974-Packet Loss for customer TWINCITY00001 Dear Cogent Customer, The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with our peer TimeWarner . Our peering engineers have made them aware of the continuing issue and are pending their response. Cogent is ready to act as soon as we have cooperation from our peer and they are ready to move forward. There is no estimated time of resolve. Please understand that Cogent does not discuss peering specific plans with our customers. Our customer support group will not be able to provide regular updates in regard to peer maintenance. If you have any questions please feel free to contact us by e-mail at support(a)cogentco.com or by phone at 877-7COGENT (877-726-4368). Thank You, Cogent Communications T 877.726.4368, option 2 F 202.295.9061 E support(a)cogentco.com ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by David Farmer

On 12/16/12 22:05 , Richard Laager wrote: > I think we're in the same boat as the others. I had both addresses > configured and all sessions configured on the new IPs, but only three > session remaining on the old IPs: the two route servers and Spiralight. > (Spiralight hadn't turned up their new IP at the point I turned it up on > my side.) All of these sessions were also configured on the new IPs. > > I removed the old IPs and sessions using the old IPs. I cleared all of > the BGP sessions using the new IPs. Do things look better now? I assume > they will at this point, since all the references to the old IPs are > gone. > Yep, your good now. -- ================================================ David Farmer Email: farmer(a)umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by Richard Laager

I think we're in the same boat as the others. I had both addresses configured and all sessions configured on the new IPs, but only three session remaining on the old IPs: the two route servers and Spiralight. (Spiralight hadn't turned up their new IP at the point I turned it up on my side.) All of these sessions were also configured on the new IPs. I removed the old IPs and sessions using the old IPs. I cleared all of the BGP sessions using the new IPs. Do things look better now? I assume they will at this point, since all the references to the old IPs are gone. -- Richard ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by David Farmer

You can telnet to route-server.micemn.net the username is rviews and get a command line route server. However, I don't think there is a web interface. On 12/16/12 21:36 , Larry Patterson wrote: > I was using 2 physically separate layer 3 interfaces on my router, no secondary IP addresses here (only way I could get around the Cisco next-hop limitation). Maybe the route server was only sending you the lower IP address path (step 13 of BGP selection process)??? Or maybe the original peer was up longer (step 10)?? ? It would be good to have route server access to see what the route server was seeing and sending. I can only tell what I am sending. Is there a web interface (or plan to implement one)? > > Sent from my iPhone > -- ================================================ David Farmer Email: farmer(a)umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012

Re: MICE Renumbering

by Larry Patterson

I was using 2 physically separate layer 3 interfaces on my router, no secondary IP addresses here (only way I could get around the Cisco next-hop limitation). Maybe the route server was only sending you the lower IP address path (step 13 of BGP selection process)??? Or maybe the original peer was up longer (step 10)?? ? It would be good to have route server access to see what the route server was seeing and sending. I can only tell what I am sending. Is there a web interface (or plan to implement one)? Sent from my iPhone On Dec 16, 2012, at 21:11, "David Farmer" <farmer(a)umn.edu> wrote: > Well, here is what I was seeing earlier; > > * 63.127.10.0/23 69.147.218.14 180 0 25694 18606 i > *> 69.147.218.14 180 0 25694 18606 i > * 64.244.48.0/20 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 69.67.16.0/20 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 71.5.104.0/21 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 74.202.238.0/24 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 74.202.239.0/24 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 199.66.72.0/22 69.147.218.14 0 180 0 25694 i > *> 69.147.218.14 0 180 0 25694 i > * 204.17.210.0 69.147.218.14 180 0 25694 40796 i > *> 69.147.218.14 180 0 25694 40796 i > > And, here is what I am seeing now; > > * 63.127.10.0/23 206.108.255.14 180 0 25694 18606 i > *> 206.108.255.14 180 0 25694 18606 i > * 64.244.48.0/20 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 69.67.16.0/20 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 71.5.104.0/21 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 74.202.238.0/24 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 74.202.239.0/24 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 199.66.72.0/22 206.108.255.14 0 180 0 25694 i > *> 206.108.255.14 0 180 0 25694 i > * 204.17.210.0 206.108.255.14 180 0 25694 40796 i > *> 206.108.255.14 180 0 25694 40796 i > > What every you did its announcing the new next-hop addresses now. Maybe you were having a similar issue to what the CDW/Berbee guys were. I apologize, and hopefully everyone's issues are as simple. > > Thanks. > > On 12/16/12 20:40 , Larry Patterson wrote: >> David, >> >> We've been announcing on both ranges for quite some time. We only left >> the old ones up because many bi-lateral's had not changed to our new peers >> yet. I've just turned down all of our old peering sessions now. I think >> that you are incorrect that we were announcing via only our old next-hop >> address. We were announcing via both, I can assure you of this. Just to >> be sure (and to be compliant with the schedule), I've turned down all of >> our old IPv4 and IPv6 sessions. Please let me know if you see any issues. >> >> Thanks, >> Larry Patterson Chief Technology Officer >> Atomic Data >> 615 North 3rd Street >> Minneapolis, MN 55401 >> 612.466.2000 Main Line >> 612.466.2080 Direct Dial >> Twitter <http://twitter.com/AtomicData> | Facebook >> <http://www.facebook.com/AtomicDataCenters> | LinkedIn >> <http://www.linkedin.com/companies/atomic-data-centers> >> Simple. Safe. Smart. >> www.atomicdata.com <http://www.atomicdata.com/> >> This message and any information or attachments included therewith is >> intended only for the individual or entity named above. If the reader is >> not the intended recipient, you are hereby notified that any use, >> dissemination, distribution or copy of this message or any information >> attached or contained therein is strictly prohibited. If you have received >> this message in error, please notify the sender by return e-mail and >> destroy all copies of the message and any attachments. >> Thank you. >> >> Please consider the environment before printing this email. >> >> >> >> >> >> >> >> >> On 12/16/12 8:22 PM, "David Farmer" <farmer(a)umn.edu> wrote: >> >>> I apologize for implying you hadn't done you part and thanks for fixing >>> it, I now see you announcing the new next-hop address. >>> >>> On 12/16/12 20:11 , James Stahr wrote: >>>> I can't speak for anyone else, but I thought I had completed the >>>> changes by swapping my $C secondary addresses around a few weeks ago and >>>> thought I was done. But it looks like I did the swap too quickly and >>>> even though 69.147.218.26 was now a secondary address and all of my BGP >>>> sessions were using 206.108.255.26 as the source IP, I was still >>>> advertising the next-hop using the old block. Turns out if the BGP >>>> sessions don't drop, the next-hop won't change. As I've previously >>>> stated, my $C equipment cannot advertise routes with BOTH next-hops. >>>> >>>> -James >>>> >>>> >>>> -----Original Message----- >>>> From: David Farmer [mailto:farmer@umn.edu] >>>> Sent: Sunday, December 16, 2012 7:46 PM >>>> To: MICE Discuss; peering(a)wiktel.com; James Stahr; mwilker(a)jagcom.net; >>>> servicenotices(a)atomicdata.com >>>> Cc: farmer(a)umn.edu >>>> Subject: MICE Renumbering >>>> >>>> OK, I think it is now time for a little public shaming; the following >>>> MICE participants are only announcing their prefixes using the old >>>> next-hop addresses through the route servers. We were all suppose to be >>>> using only the new addresses as of two weeks ago. There is one other >>>> participant announce with both the old and the new next-hop address, we >>>> (Northern Lights GigAPOP) just stopped doing this earlier today, and are >>>> now announcing using only the new next-hop addresses. All other >>>> participants are announcing to the route servers are using only the new >>>> next-hop addresses. >>>> >>>> AS33362 Wikstrom Telephone Company (Wiktel) >>>> AS25694 Atomic Data >>>> AS15011 Jaguar Communications >>>> AS3599 CDW/Berbee >>>> >>>> Please convert your peering session to announcing with the new next-hop >>>> addresses, ASAP. If for some reason you can't do this in the next week, >>>> please send a note to the MICE-DISCUSS mailing list detailing when you >>>> will be converting. >>>> >>>> As a reminder, here is the original cutover schedule that was emailed >>>> out several months ago: >>>> >>>> Addition of Address Secondary: before 10/1/2012 >>>> New Prefix Announcements: after 10/1/2012 >>>> Final use of old IP address next-hop: before 11/30/2012 >>>> Removal of old IP address range: after 12/1/2012 >>>> Project End: 12/31/2012 >>>> >>>> Thanks. >>>> -- >>>> ================================================ >>>> David Farmer Email: farmer(a)umn.edu >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 1-612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >>>> ================================================ >>> >>> >>> -- >>> ================================================ >>> David Farmer Email: farmer(a)umn.edu >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 1-612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 >>> ================================================ >> >> ######################################################################## >> >> To unsubscribe from the MICE-DISCUSS list, click the following link: >> http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > -- > ================================================ > David Farmer Email: farmer(a)umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Dec. 17, 2012