Re: Concern about gTLD servers in India
On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: I can see India has 3 root servers hosting root zone - i, j k in India which is good. So we can resolve the root zone i.e dot within India. One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... -Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Re: Concern about gTLD servers in India
Thanks for info Peter I missed that because firstly no routes from major Indian backbones and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. On Sun, Mar 11, 2012 at 4:27 PM, Peter Losher plos...@isc.org wrote: On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: I can see India has 3 root servers hosting root zone - i, j k in India which is good. So we can resolve the root zone i.e dot within India. One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... -Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: Concern about gTLD servers in India
On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote: Thanks for info Peter I missed that because firstly no routes from major Indian backbones I can assure you that we get a good chunk of traffic from at least one of the major Indian Backbones. The Chennai PoP is smaller than NIXI's other locations in Mumbai/Dehli/Kolkata, but it has a couple of the major players... and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. Umm, but it is... search for Chennai, IN and also look the F bubble on Chennai on the Google Map that is on the page. Best Wishes - Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Re: Concern about gTLD servers in India
Oops Almost missed that. Sorry about that. Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. On Sun, Mar 11, 2012 at 4:37 PM, Peter Losher plos...@isc.org wrote: On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote: Thanks for info Peter I missed that because firstly no routes from major Indian backbones I can assure you that we get a good chunk of traffic from at least one of the major Indian Backbones. The Chennai PoP is smaller than NIXI's other locations in Mumbai/Dehli/Kolkata, but it has a couple of the major players... and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. Umm, but it is... search for Chennai, IN and also look the F bubble on Chennai on the Google Map that is on the page. Best Wishes - Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ] -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
Re: Concern about gTLD servers in India
On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. Best Wishes - Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Re: Concern about gTLD servers in India
As J is already there in India which is operated by Verisign, I don't think it's difficult to add .com .net by Verisign. Just talk to them. Regards, Che-Hoo On 11 Mar, 2012, at 7:27 PM, Peter Losher wrote: On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote: Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. Best Wishes - Peter -- [ plos...@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Re: root zone stats
Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 11, 2012 4:44 AM, Doug Barton do...@dougbarton.us wrote: Since there was a question about this, some numbers: Serial: 2012031001 Statistics == Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs:249 Number of IDN TLDs: 42 Total number of TLDs:313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts:427 Number of IPv6 addresses:412 TLDs with IPv6 glue: 258 Total name server hosts:1177 Total NS addresses: 1557 Number of DS records:141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough
Re: [apnic-talk] root zone stats
Anurag, On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote: Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of their servers is a business decision that they would each independently make. Regards, -drc
Re: filtering /48 is going to be necessary
On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: The way we are headed right now, it is likely that the IPv6 address space being issued today will look like the swamp in a few short years, and we will regret repeating this obvious mistake. We had this discussion on the list exactly a year ago. At that time, the average IPv6 origin ASN was announcing 1.43 routes. That figure today is 1.57 routes per origin ASN. The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table. But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this: 1. Attackers could flood BGP with bogus prefixes to make tables overflow 2. Legitimate prefixes may be deaggregated so tables overflow It won't be quick or easy, but the RPKI stuff should solve 1. So that leaves the issue of deaggregating legitimate prefixes. There are around 100k prefixes given out by the RIRs and nearly 400k in the routing tables. A quick look at the IPv4 BGP table shows that unless I missed the day in school when they covered reasons to advertise 64 /22s instead of a /16 a good percentage of those deaggregates happen without any legitimate reason. Although the RIRs don't make this as easy as they could, it IS possible to determine the maximum prefix length for any given block of RIR space, and then simply filter on that prefix length. That takes care of the /48s and /32 deaggregating, but unfortunately not the /44s out of space used for /48s or the /20s out of space used for /32s. So the RIRs should up their game here, then we can really hold LIR's feet to the fire and stop them from deaggregating. That does of course leave people who do have a good reason to deaggreagate in the cold. But that's also easy to solve: if you run two separate networks, you need two prefixes and two AS numbers. So the RIRs should develop policies that allow for this if it's reasonable. If that means that an organization can't have both a bunch of independently announced prefixes AND have all those prefixes be part of one aggregate for easy firewall configuration, that's too bad. The RIRs should pick up on this, because there WILL be a moment an ISP deaggregates a /32 into 65000 /48s with the result that half the IPv6 internet goes down.
Re: root zone stats
On Sunday, 11 March 2012, David Conrad d...@virtualized.org wrote: Anurag, On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote: Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of their servers is a business decision that they would each independently make. Regards, -drc Correct, location of the .uk servers aren't published as they are treated as part of national infrastructure and protected as such -- Martin Oxford uk -- -- Martin Hepworth Oxford, UK
ccTLD operators do not rule, was Re: Concern about ...
At 16:38 -0800 3/10/12, Owen DeLong wrote: The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with. This is not true. First, there is the ccTLD itself - it is an organization that is recognized has having legitimate claim to the country code. These do change at times. Then there is the ccTLD operator. Some ccTLDs own and operate and some do out source the technical operations, sometimes just DNS, sometimes everything (e.g., the database). When out sourcing, the ccTLD owner makes contractural demands of the operator. If the ccTLD requires an in-country DNS presence that is easily arranged by the operator. (The operator reflects the cost in the price.) With the growing awareness of the role of the Internet, ccTLDs do not let the operator do their thing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!
Re: filtering /48 is going to be necessary
On 3/11/12 08:48 , Iljitsch van Beijnum wrote: On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: The way we are headed right now, it is likely that the IPv6 address space being issued today will look like the swamp in a few short years, and we will regret repeating this obvious mistake. We had this discussion on the list exactly a year ago. At that time, the average IPv6 origin ASN was announcing 1.43 routes. That figure today is 1.57 routes per origin ASN. The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. Sancho Panza couldn't get us out of that one.
Re: filtering /48 is going to be necessary
On 11 Mar 2012, at 09:48, Iljitsch van Beijnum iljit...@muada.com wrote: On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote: The way we are headed right now, it is likely that the IPv6 address space being issued today will look like the swamp in a few short years, and we will regret repeating this obvious mistake. We had this discussion on the list exactly a year ago. At that time, the average IPv6 origin ASN was announcing 1.43 routes. That figure today is 1.57 routes per origin ASN. The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table. But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this: 1. Attackers could flood BGP with bogus prefixes to make tables overflow 2. Legitimate prefixes may be deaggregated so tables overflow It won't be quick or easy, but the RPKI stuff should solve 1. Unless the attacker uses the same origin AS that is in the ROA. Probably it won't hijack the traffic but it may create a DoS or any other kind of problem. Regards, as
RE: BellSouth (att?) with a clue in Raleigh, NC
Verizon is FiOS, ATT has U-verse which is FTTC. Frank -Original Message- From: chris [mailto:tknch...@gmail.com] Sent: Saturday, March 10, 2012 8:34 PM To: Faisal Imtiaz Cc: NANOG list Subject: Re: BellSouth (att?) with a clue in Raleigh, NC Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz fai...@snappydsl.net wrote: Google for their Uverse site and check if u can get it... They will do Uverse (Internet only). Only if u order online Faisal Sent from my iPhone On Mar 10, 2012, at 9:02 PM, chris tknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
RE: root zone stats
Some nice info here, too: http://bgp.he.net/report/dns Frank -Original Message- From: Doug Barton [mailto:do...@dougbarton.us] Sent: Saturday, March 10, 2012 5:14 PM Cc: APNIC Mailing List; nanog@nanog.org Subject: root zone stats Since there was a question about this, some numbers: Serial: 2012031001 Statistics == Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs:249 Number of IDN TLDs: 42 Total number of TLDs:313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts:427 Number of IPv6 addresses:412 TLDs with IPv6 glue: 258 Total name server hosts:1177 Total NS addresses: 1557 Number of DS records:141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough
Re: BGP MD5 at IXP
On 10/03/2012 11:24, Robert E. Seastrom wrote: Hopefully your modern exchange point router has some sort of control plane policing. My gut feeling is that lots don't. The behaviour of various operating systems regarding MD5 processing is interesting. *BSD (and I assume consequently junos) checks ttl and sequence numbers before checking md5. Linux and IOS do md5 first, and I just wonder about the wisdom of this approach due to the slightly higher computational overhead of calculating the hash. In general, I'm slightly in favour of md5 at ixps, not because of session security, but when exchange participants leave an ixp, lots of people don't bother to remove the bgp sessions. If as a newcomer to the IXP you get a re-used ip address, without md5 it can sometimes be possible to do Interesting and Bad Things with old sessions from other ixp participants. FWIW, for the INEX route server system we: - use bsd - implement packet filtering to accept tcp/bgp only from the ixp subnet - generally use md5 for ipv4 sessions - generally don't use md5 for ipv6 sessions for historical reasons This works for us. I agree with Andy's conclusion. Don't do it unless whoever you're peering with demands it. It's not worth the complexity to set it up in the first place, and it's not worth your time to argue against it if someone is quite convinced that enabling md5 on your bgp session will save the world. yep, agreed. Doesn't make that much difference in real life so don't lose sleep about it. The only real difference it makes is that it can help shut up security audit people (the tick-box compliance variety) from their ivory tower whining. Nick
Shim6, was: Re: filtering /48 is going to be necessary
On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion basement multihomers with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream.
Re: BellSouth (att?) with a clue in Raleigh, NC
HI Chris, If you are out of luck in getting DSL or Uverse. I would suggest that you try your local Cable Service Provider. If that does not work out either, I would suggest you take a look to see if you have A WISP (Fixed Wireless Service) service provider in the area. (http://www.wipa.org/find-a-wisp .. Find a WISP link is under About WISPA menu). Regards. Faisal Imtiaz Snappy Internet Telecom On 3/10/2012 9:34 PM, chris wrote: Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz fai...@snappydsl.net mailto:fai...@snappydsl.net wrote: Google for their Uverse site and check if u can get it... They will do Uverse (Internet only). Only if u order online Faisal Sent from my iPhone On Mar 10, 2012, at 9:02 PM, chris tknch...@gmail.com mailto:tknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
Re: Concern about gTLD servers in India
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/11/2012 03:57 AM, Peter Losher wrote: On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote: I can see India has 3 root servers hosting root zone - i, j k in India which is good. So we can resolve the root zone i.e dot within India. One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. - --- I see 192.5.5.0/24 less widely seen by the peers as opposed to 192.5.4.0/23 maybe as you mentioned the longer prefix (/24) should be visible to clients using local instance of f-root. Why? It would be bad to attract traffic from half way around the world to a local node as they are there to serve the local community. Just wondering how do the other root keepers manage that because reminds me of an outage (k-root related) sometime september or october time frame of 2010 that a /24 may have leak more widely than intended from a one of the local instances. I know off-topic here but what caught my interest is in no_export set for root server as the outage mentioned above came near the K-root local instance in India. regards, /virendra And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... -Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk9dM6QACgkQ3HuimOHfh+H61gD/VGHBJdphTPA1yOYUGr7nmouG UJwR3yL4WAPcgfpDh6oA/AvwWW7kqU00ghOVE+Xioejv2gKPBQDB18hHGrmEcxtY =RDVK -END PGP SIGNATURE-
Re: BellSouth (att?) with a clue in Raleigh, NC
Faisal Imtiaz fai...@snappydsl.net wrote: HI Chris, If you are out of luck in getting DSL or Uverse. I would suggest that you try your local Cable Service Provider. If that does not work out either, I would suggest you take a look to see if you have A WISP (Fixed Wireless Service) service provider in the area. (http://www.wipa.org/find-a-wisp .. Find a WISP link is under About WISPA menu). Spelling counts. The correct URL is; http://www.wispa.org/find-a-wisp As in Wireless Internent Services Provider Association.
Re: Shim6, was: Re: filtering /48 is going to be necessary
On 3/11/2012 3:15 PM, Iljitsch van Beijnum wrote: But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade Because as far back as 2003 ARIN members (and members from all the other RIRs for that matter) were saying in very clear terms that PI space was a requirement for moving to v6. No one wanted to lose the provider independence that they had gained with v4. Without that, v6 was a total non-starter. ARIN was simply listening to its members. Doug -- If you're never wrong, you're not trying hard enough
Re: Shim6, was: Re: filtering /48 is going to be necessary
On Mar 11, 2012, at 3:15 PM, Iljitsch van Beijnum wrote: On 11 Mar 2012, at 20:15 , Joel jaeggli wrote: The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. That's a fairly simplistic version of why shim6 failed. A better reason (appart from the fact the building an upper layer overlay of the whole internet on an ip protocol that's largely unedeployed was hard) is that it leaves the destination unable to perform traffic engineering. I'm not saying that shim6 would have otherwise ruled the world by now, it was always an uphill battle because it requires support on both sides of a communication session/association. But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade, just when the multi6/shim6 effort started to get going but before the work was complete enough to judge whether it would be good enough. As the person who led the charge in that action, I can probably answer that question... First, from my perspective at the time, SHIM6 didn't stand a chance. It was massively complex, required modifying the stack on every single end system to yield useful results and mad windows domain administration look simple by comparison. As such, I just didn't see any probability of SHIM6 becoming operational reality. (I think LISP suffers from many, though not all) of the same problems, frankly. I remember having this argument with you at the time, so, I'm surprised you don't remember the other side of the argument from the original discussions. However, there was also tremendous pressure in the community for We're not going to adopt IPv6 when it puts us at a competitive disadvantage by locking us in to our upstream choices while we have portability with IPv4. Like it or not, that's a reality and it's a reality that is critically important to getting IPv6 adopted on a wider scale. Fortunately, it was a reality we were able to address through policy (though not without significant opposition from purists like yourself and larger providers that like the idea of locking in customers). That fundementaly is the business we're in when advertising prefixes to more than one provider, ingress path selection. That's the business network operators are in. That's not the business end users who don't want to depend on a single ISP are in. Remember, shim6 was always meant as a solution that addresses the needs of a potential 1 billion basement multihomers with maybe ADSL + cable. The current 25k or so multihomers are irrelevant from the perspective of routing scalability. It's the other 999,975,000 that will kill the routing tables if multihoming becomes mainstream. It's not just about depending on a single ISP, it's also about being able to change your mind about which ISPs you are attached to without having to undertake a multi-month corporate-wide project in the process. Let's compare... BGP multihoming with portable PI prefix: 1. Sign new contract. 2. Make new connection. 3. Bring up new BGP session. 4. Verify routes are working in both directions and seen globally. 5. -- 6. -- 7. -- 8. -- 9. Tear down old BGP session. 10. -- 11. Terminate old contract. 12. -- PA based prefix: 1. Sign new contract. 2. Make new connection. 3. Get routing working for new prefix over new connection. 4. Add new prefix to all routers, switches, provisioning systems, databases, etc. 5. Renumber every machine in the company. 6. Renumber all of the VPNs. 7. Deal with all the remote ACL issues. 8. Deal with any other fallout. 9. Turn off old prefix and connection. 10. Deal with the fallout from the things that weren't symptomatic in steps 4-9. 11. Terminate old contract 12. Remove old prefix from all remaining equipment configurations. By my count, that's twice as many steps to move a PA end-user organization and let's face it, steps 5, 6, and 7 (which don't exist in the PI scenario) take the longest and steps 7, 8, and 10 (again, non-existant in the PI scenario) are the most painful and potentially the most costly. No multihomed business in their right mind is going to accept PA space as a viable way to run their network. Owen
Re: BellSouth (att?) with a clue in Raleigh, NC
It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. One more thing, once you get UVerse, you have to forfeit your traditional DSL. Apparently, the two services cannot coexist (some billing program issue), what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. If you can avoid the ATT hassle. Try looking into wireless providers. WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. -Mario Eirea On Mar 10, 2012, at 9:03 PM, chris tknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
Re: BellSouth (att?) with a clue in Raleigh, NC
my comments below:- Faisal Imtiaz Snappy Internet Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 3/11/2012 10:25 PM, Mario Eirea wrote: It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. Yes, that is true, ATT would mark an area as not qualifying for DSL if there was Uverse in the Area, but this practice has been in-consistent. There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. Yes, we have seen that too, not sure what is the official reason, but in system show the Remote DSLAM being out of capacity. :) On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. There has to be more context to this... a lot of DSLAM they are or have quietly turned down backhaul capacity, as such new circuits are only for lower speeds. One more thing, once you get UVerse, you have to forfeit your traditional DSL. Apparently, the two services cannot coexist (some billing program issue), Yes that is correct ... what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. That does not make sense... there is no such thing as 768K Uverse... (Uverse starts at 3meg down, 768K down is called DSL Lite.. ) If you can avoid the ATT hassle. Try looking into wireless providers. Agreed... WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. Agreed.. -Mario Eirea On Mar 10, 2012, at 9:03 PM, christknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
Re: BellSouth (att?) with a clue in Raleigh, NC
919 is in fact the area I'm looking at. so far i've put together: select areas can get att dsl up to 3mbit but its rare select areas have uverse select areas have centurylink(couldnt believe this but verified it from a friend in cary, nc) twc cable has good coverage over most of the area all in all what a horrible lack of options really. i just started looking into time warner, looks like they have some kind of wholesale offering: http://wholesalecarrierservice.com/ crossing my fingers that the twc wholesale will fit my needs but not holding my breath i thank everyone for all their replies to this thread, there has been an abundance of great information. chris On Sun, Mar 11, 2012 at 11:08 PM, LQ Marshall qmarsh...@inetspace.netwrote: There are a number of COs in RDU area and especially 919 area code which are reportedly at capacity. There has been little or no movement in upgrade plans at these locations (over years). Depending on which CO you are coming out of and your budget there are other options. FIOS is very rare in the 919 area as most of it (all?) is Bell South/ATT. U-Verse has limited coverage in the area. IMOHO if you're looking for the sub $100 solution TWC is the way to go. gl -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: Sunday, March 11, 2012 5:23 PM To: 'chris' Cc: NANOG list Subject: RE: BellSouth (att?) with a clue in Raleigh, NC Verizon is FiOS, ATT has U-verse which is FTTC. Frank -Original Message- From: chris [mailto:tknch...@gmail.com] Sent: Saturday, March 10, 2012 8:34 PM To: Faisal Imtiaz Cc: NANOG list Subject: Re: BellSouth (att?) with a clue in Raleigh, NC Looks like no dice on uverse, says its not available. i thought uverse was fios though atleast that was my understanding. now im even more confused, how can att/bellsouth be the ILEC and have zero internet options at all but be offering pots? Only logical thing I can think of is distance from the CO making dsl a no-go but i cant get an actual qual to atleast confirm that :( On Sat, Mar 10, 2012 at 9:23 PM, Faisal Imtiaz fai...@snappydsl.net wrote: Google for their Uverse site and check if u can get it... They will do Uverse (Internet only). Only if u order online Faisal Sent from my iPhone On Mar 10, 2012, at 9:02 PM, chris tknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
RE: BellSouth (att?) with a clue in Raleigh, NC
On 3/11/2012 10:25 PM, Mario Eirea wrote: It has been my personal experience that when UVerse enters an area, traditional DSL has disappears. Yes, that is true, ATT would mark an area as not qualifying for DSL if there was Uverse in the Area, but this practice has been in-consistent. There are locations where we have ONUs in the building with available DSL circuits and they refuse to sell it to us. Yes, we have seen that too, not sure what is the official reason, but in system show the Remote DSLAM being out of capacity. :) I'm sure this is true, I know we have requested service disconnections more than once in the past and have had the account closed, but DSL has remained on the line. Plug in a modem and you get sync, type in a user and password for another site and you are surfing... I hope they don't make it a habit of leaving circuits up for non paying customers. That a lot of unused service going to waste. On another note, they sometimes try to offer us a 768k connection in a place where we currently have 6mb DSL service. There has to be more context to this... a lot of DSLAM they are or have quietly turned down backhaul capacity, as such new circuits are only for lower speeds. One more thing, once you get UVerse, you have to forfeit your traditional DSL. Apparently, the two services cannot coexist (some billing program issue), Yes that is correct ... what makes it worse, if you suddenly realize your 6Mb was replaced with a 768k UVerse, there's no going back. That does not make sense... there is no such thing as 768K Uverse... (Uverse starts at 3meg down, 768K down is called DSL Lite.. ) That's what I thought, but not the case. This is especially prevalent in the South Miami area. One think I know is that the service was labeled UVerse not Fast Access DSL, however, I cannot tell you if the underlying technology is ADSL or VDSL2 (we went running to the hills after 768k). The justification they gave us for the lower speeds on the UVerse service was that they were in the process of transitioning their existing DSL service to UVerse, and until that was complete, the backhaul capacity was not going to be available. I still don't believe this... Does not make any sense to me that they would have to wait for everyone on their old service to switch to UVerse before they make the bandwidth available. Its ATT, I have a real hard time cutting though all the layers of junk before you get to someone that actually tells you the truth or knows what's going on. If you can avoid the ATT hassle. Try looking into wireless providers. Agreed... WiMax has come to the rescue many times when the Cable and Telco companies have not been able to provide us with the service at the price point we were looking for. Agreed.. -Mario Eirea On Mar 10, 2012, at 9:03 PM, christknch...@gmail.com wrote: Hi, I am trying to look into dsl in the RDU area and att customer service has been exceedingly unhelpful only telling me no service available, we have no idea when services will become available, check back periodically. I would atleast like to get an answer that theres no available capacity, its over the 18k limit of dsl, or some other logical answer. Is there anyone at bellsouth/att or one of their clec's who can help me do some qual's and hopefully also help get this delivered? i did some lookups on known pots in the area and came up with: LATA426 NameR ALEIGH N CAROLINA Historical Region BellSouth Area Codes in LATA 919 Carrier Common Name ATT Southeast OCN 9417 OCN Type RBOC Name Bellsouth Telecomm Inc dba Southern Bell Telephone Telegraph Abbreviation BELLSOUTH SO BELL DBA Southern Bell Telephone Telegraph FKA Southern Bell Telephone Telegraph so im pretty sure im contacting the right telco just surprised that their customer service is offering pots but says no internet available, wtf? thanks for any info you can provide, chris
Re: filtering /48 is going to be necessary
On Fri, Mar 9, 2012 at 11:27 PM, Owen DeLong o...@delong.com wrote: 1) absolutely must drop /48 de-aggregates from ISP blocks 2) absolutely must make RIR policy so orgs can get /48s for anycasting, and whatever other purposes Item 1 will be interesting. Item 2 is already done in ARIN and I think RIPE and APNIC. I'm not sure about AfriNIC or LACNIC. AfriNC already does so. See http://www.afrinic.net/docs/policies/AFPUB-2007-v6-001.htm -- Mukom Akong [Tamon] __ “We don't LIVE in order to BREATH. Similarly WORKING in order to make MONEY puts us on a one way street to irrelevance.“ [In Search of Excellence Perfection] - http://perfexcellence.org [Moments of TechXcellence] - http://techexcellence.net [ICT Business Integration] - http://ibiztech.wordpress.com [About Me] - http://about.me/perfexcellence
