November 2008 - Test - lists.nanog.org

routing around Sprint's depeering damage
by Dave Blaine 05 Nov '08

05 Nov '08

There are at least three ways to address this Sprint / Cogent partition: 1. Send Vint Cerf back up to Capitol Hill with a doomsday scenario of what would happen to the economy if anyone else gets as stupid as Sprint has been, begging for laws that any tier-1 or tier-2 who wants to de-peer needs to provide all their customers and peers with 90 day notice or face stiff fines. Send John Schnizlein along with him to get the House Communications Director an Akamai hosting account. Repeat the "eyeballs-or-data, which is more valuable" mantra whether or not there are still forty Republicans in the Senate. 2. Pick up some more fiber, dust off the router manuals, and allow and recommend that tier-1s transit any third party tier-1-to-tier-1 traffic. 3. Both. Which is the best way?

30 47

AT&T routing issue
by Campbell, Alex 04 Nov '08

04 Nov '08

Hi all, We have recently brought up some BGP sessions with a new provider, and have found that we can get end to end connectivity through the new provider to pretty much everywhere except networks behind AT&T (AS7018). We are able to see our routes in AT&T's route server, but all traceroutes from our network to hosts behind 7018 stop at AT&T's border. We are multihomed, so I've local-prefed up our secondary ISP and the problem resolves immediately. Our upstream (AS9443) and their upstream (AS11867) have been chasing this up with AT&T for a couple of days, but don't seem to have had made much progress. Does anyone have any suggestions as to what could be causing this, or a contact at AT&T who might be able to assist? Thanks, Alex

3 3

Metro Ethernet Multicast Support
by Holmes,David A 04 Nov '08

04 Nov '08

The Metro Ethernet Forum (MEF) MEF10-1 ELAN multipoint-to-multipoint specification says that multicast packets must be replicated out all ports in the ELAN, except the ingress port. Some carriers have taken this literally and built a virtual ELAN service emulating a 1990's style hub in which all multicast packets are replicated out all ports regardless of the L3 multicast routing protocol in use. In the case of PIM sparse mode real physical Ethernet switches use IGMP snooping to construct a directed path through the switch fabric, so that a given established multicast stream is forwarded just like a directed unicast connection with mac/port table entries establishing a single path through the L2 fabric, and no flooding is done. Some carriers flood directed multicast traffic out all ELAN ports even though a single path should be taken. In networks with a large number of directed multicast streams, flooding out all ports uses unnecessary bandwidth, sometimes rendering a 10 Mb port useless due to oversubscription caused by this unnecessary flooding. Can anyone suggest a carrier MEF ELAN multipoint-to-multipoint service that does not flood established directed PIM sparse mode streams?

2 1

FW: Sprint v. Cogent, some clarity & facts
by Tomas L. Byrnes 04 Nov '08

04 Nov '08

-----Original Message----- From: Tomas L. Byrnes Sent: Tuesday, November 04, 2008 4:08 PM To: 'Niels Bakker' Subject: RE: Sprint v. Cogent, some clarity & facts There was nothing in my post advocating free transit or peering. I merely pointed out that peering only without downstream propagation was a technical error, based on the proper implementation of the protocols as designed. All the discussion of practicality and politics are implementation failures: the first because of crappy routers, the second because of the established player issue you called out. We've all had enough of crappy networks causing unreachability. >-----Original Message----- >From: Niels Bakker [mailto:niels=nanog@bakker.net] >Sent: Tuesday, November 04, 2008 9:30 AM >To: nanog(a)nanog.org >Subject: Re: Sprint v. Cogent, some clarity & facts > >* tomb(a)byrneit.net (Tomas L. Byrnes) [Tue 04 Nov 2008, 17:51 CET]: >>The concept of "Transit Free" is a political failure, not a technical >>one. > >Yeah, networks should be free! And Cogent, if they don't get access to >Sprint directly, should just set a default route over some public IX >where Sprint is also present at to reach their network!! And then hack >their routers to do likewise. > > >>The protocols are designed, and the original concept behind the >Internet >>is, to propagate all reachability via all paths. IE to use Transit if >>peering fails. > >Yeah, the original concept of the internet. Like classful IP routing. > > >>Not doing so is a policy decision that breaks the redundancy in the >>original design. > >Because the original design totally had in mind established players >locking out cheaper newcomers and explicitly specified a maximum band >where prices for transit had to exist inside of. > >Please stop it. We've had enough. > > > -- Niels. > >-- >"We humans get marks for consistency. We always opt for > civilization after exhausting the alternatives." > -- Carl Guderian >

1 0

RE: Sending vs requesting. Was: Re: Sprint / Cogent
by Lamar Owen 04 Nov '08

04 Nov '08

Charles Wyble charles(a)thewybles.com wrote: > We know they can partition at any time. > We know that certain players have a history of causing this to happen > more then others. > What I haven't seen discussed in any great detail, is how to limit those > events. There are three ways that I know of (feel free to add to this list) to limit the events: 1.) As you mentioned, regulation (or a government run and regulated backbone); 2.) Economic pressures of a free market (cause event, lose customers or cause customers to multihome, thus costing you upgrade money; or other market 'pressures' a la the recent Intercage Capers); 3.) 'For the good of the Internet!' I would much prefer option 2 since regulation is too easy to mess up, and option 3's realistic chances of occurring are slim to none, and Slim done left town. Unless operators really want unfunded yet mandated peering arrangements. Or a return to a government (mix of state and federal) funded backbone a la NSFnet or ARPAnet with mandated (but unfunded, of course) open peering to all Tier 1 (TM) providers on the planet. Something like CATV must-carry rules (47 CFR 76.51 through 76.70). Hah! If you will indulge me a flight of hyperbole for a few moments, I wonder if, perhaps, an extension of 47 CFR 51.701 through 51.717 to cover NSPs would be considered. The FCC might not even need extra regulatory authority from an amendment to the Communications Act of 1934, as amended, to put IP carriers under 47 CFR 51, and it is, relatively speaking, fairly straightforward reading. Costs the FCC a lot less to change existing regulations than to write new ones, too, and falls under an existing Bureau. Operators really would not want this, I would think, as then things can get really complicated really qickly (read the broadcast radio and television regulations in 47 CFR 73, especially something technically specific like 47 CFR 73.186 for an idea of how cumbersome things CAN be made on the technical side). Endusers who just want the thing to work would be all over it. The FCC certainly has the technical expertise in-house to write regs to deal with it. The Commission would issue an NPRM, gather comments and reply comments, issue maybe an FNPRM or three, gather comments and reply comments, mull over it for five years or more, and then issue an R&O that very few will want (at least this is what happened with AM Stereo, HD Radio, and Digital Television). People will file objections to the R&O, the process will churn for a while, maybe with an FR&O, etc. Welcome to the world of regulation. The RFC process is a model of streamlining compared to anything before the Commission. Hmm, on the other hand, maybe that's not hyperbole after all. You and Randy are both right; this issue gets rehashed a lot (this is most certainly far from the first time I've seen the discussion pass by). But the reason it keeps coming up is because it is a real problem, and it hasn't been fixed by the people who can fix it, if they will, without getting the cumbersome beast called regulation into play.

2 1

diverse multisite advertising?
by Gregori Parker 04 Nov '08

04 Nov '08

I've been reading up on BGP and asking around, but still havent found a hard yes/no on this...hopefully someone here can provide clarification. If I have a single ASN and an IP allocation from ARIN, can I advertise one half of my prefix from one site and the other half from another distinct non-connected site using the same ASN? If so, are there implications with mutihoming to all unique ISPs (2 per location)? I seem to remember that an AS Path wouldnt be valid with the same AS appearing more than once in non-sequential order, i.e. at the beginning and the end in this case, but am unable to verify since everything I've been reading up on discusses BGP in single-site terms. Thanks in advance, Gregori

3 2

Re: diverse multisite advertising?
by Scott Weeks 04 Nov '08

04 Nov '08

--- Gregori.Parker(a)theplatform.com wrote: From: "Gregori Parker" <Gregori.Parker(a)theplatform.com> If I have a single ASN and an IP allocation from ARIN, can I advertise one half of my prefix from one site and the other half from another distinct non-connected site using the same ASN? If so, are there implications with mutihoming to all unique ISPs (2 per location)? ---------------------------------------------- You can find all the details in the NANOG archives. This has been covered many times in grueling detail. scott

1 0

[NANOG-announce] The new NANOG Mailing List Committee
by kris foster 04 Nov '08

04 Nov '08

Hi everyone The Steering Committee has selected new Mailing List Committee members. We would like to thank our outgoing member David Barak for all of his work over the last two years. The MLC members and their term lengths are: Randy Epstein - 11 / 2010 Kris Foster - 11 / 2009 Sue Joiner - Merit appointee Simon Lyall - 11 / 2009 Tim Yocum - 11 / 2010 Thank you to everyone who put their names forward to volunteer! Sincerely Kris Foster Mailing List Committee Chair _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Sending vs requesting. Was: Re: Sprint / Cogent
by bas 04 Nov '08

04 Nov '08

On Fri, Oct 31, 2008 at 7:03 PM, Patrick W. Gilmore <patrick(a)ianai.net> wrote: > If Sprint is upset that Cogent is sending Sprint much more traffic than > Sprint is sending Cogent, how does Sprint sending Cogent even less traffic > (and making the ratio even worse) help Sprint? Why would Cogent care? Why does everyone keep referring to traffic flows as sendng? In this case it's not as if Cogent just randomly sends data to Sprint. Sprint customers are requesting content from Cogent customers right? So Sprint depeers Cogent because Sprint customers are requesting to much content from Cogents customers? I've heard eyeball networks refer to traffic flows as sending too.. "You content hosters are sending us too much traffic, we want money to upgrade ports and transport all that traffic" Complete reverse logic imho. It is always eyeball network customers that request data. (except for a small portion of iphone/blackberry push email, but that can't account for much.) Bastiaan

11 12

Any recent predictions for routing table growth?
by Brad Freeman 04 Nov '08

04 Nov '08

Hi, I am looking for some recent estimates of future IPv4 & IPv6 routing table growth, the most recent reliable estimate I can find was done by Vince Fuller in his presentation in March 2007, is there any newer or alternative figures out? Thanks Bradley

5 6