Home page logo
/

nanog logo nanog mailing list archives

Re: a radical proposal (Re: protocols that don't meet the need...)
From: "Edward B. DREGER" <eddy+public+spam () noc everquick net>
Date: Wed, 15 Feb 2006 20:02:06 +0000 (GMT)


CM> Date: Wed, 15 Feb 2006 14:37:44 -0500
CM> From: Chip Mefford

CM> ED> Of course not.  Let SBC and Cox obtain a _joint_ ASN and _joint_
CM> ED> address space.  Each provider announces the aggregate co-op space
CM> ED> via the joint ASN as a downstream.
CM> 
CM> This makes a lot of sense.

BTW, Paul, FixedOrbit reports 701 as having ~1500 peers and downstreams.  
As interconnected as even they are, that's still a far cry from the 
full-mesh O(N^2) situation you seemed to suggest.


CM> However, as one of those smaller players, who may be multihomed
CM> using SBC and Cox, as your example says, I can fairly say
CM> that I don't like renumbering very much, and sometimes one
CM> finds there is a good business case to be made to switch providers,
CM> In short, having an ASN is good for me, if not for the community
CM> at large, so how to balance that?

Changing ASNs is easy for small, one-router installations.  Renumbering 
would still be necessary, but that's no different than the status quo.  
i.e., my proposal does not make this worse.  That said, let's think if 
we can improve in that area.


CM> Right now, gettin ONE upstream to issue a private asn can be
CM> like an amatuer dental extraction, imagine 2 that don't like each other,
CM> or more often are totally ambivalent with regards to the others
CM> concerns/cares/policies/proceedures, et al.  One says xxx00, and
CM> the other xxx01, how am I supposed to sort this out?

RIR-issued public ASNs.  I probably should have merged the "truly 
radical" thread with this one.


CM> ED> We're dealing with _one_ routing policy: hand it to Cox, or hand it
CM> ED> to SBC.  Why explode it into two million "different" policies?
CM> 
CM> Are we? Or are we dealing with _one_ routing policy: handing
CM> it to Cox AND handing it to SBC, who mediates? Right now, it
CM> appears as if it would me, the end-user. I'm just not equipped for that.

Exactly.  It's _one_ routing policy.  Not equipped?  A little SOHO 
router could easily accept default and advertise a prefix or two via 
BGP.  Once upon a time a 2500 held a full table; consumer-grade routers 
of today boast better CPU and RAM.

Okay, so consumers must flash new firmware or forklift their $100 
router.  Oh well.


CM> I just don't know how it would play out in practice between
CM> two providers, who as we have seen over recent short history
CM> don't necessarily work and play well together.

In which case it's time for consumers to vote with their wallets.  Or, 
if that's not possible, perhaps the FCC and SEC (in the USA) need to 
evaluate certain providers.  Hence the "radical" aspect of the 
suggestion. ;-)


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc () brics com -*- jfconmaapaq () intc net -*- sam () everquick net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]