Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt

Curtis Villamizar <curtis@faster-light.net> Wed, 12 October 2005 21:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoXS-000142-Sl; Wed, 12 Oct 2005 17:53:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPoXO-00013s-Kn for idr@megatron.ietf.org; Wed, 12 Oct 2005 17:53:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07718 for <idr@ietf.org>; Wed, 12 Oct 2005 17:53:22 -0400 (EDT)
Received: from relay00.pair.com ([209.68.5.9] helo=relay.pair.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPohm-0006OZ-Ko for idr@ietf.org; Wed, 12 Oct 2005 18:04:11 -0400
Received: (qmail 37576 invoked from network); 12 Oct 2005 21:53:17 -0000
Received: from unknown (HELO workhorse.faster-light.net) (unknown) by unknown with SMTP; 12 Oct 2005 21:53:17 -0000
X-pair-Authenticated: 69.37.59.162
Received: from workhorse.faster-light.net (localhost.faster-light.net [127.0.0.1]) by workhorse.faster-light.net (8.12.11/8.12.11) with ESMTP id j9CLmaJD035226; Wed, 12 Oct 2005 17:48:36 -0400 (EDT) (envelope-from curtis@workhorse.faster-light.net)
Message-Id: <200510122148.j9CLmaJD035226@workhorse.faster-light.net>
To: John Leslie <john@jlc.net>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
In-reply-to: Your message of "Wed, 12 Oct 2005 16:27:06 EDT." <20051012202706.GB27304@verdi>
Date: Wed, 12 Oct 2005 17:48:36 -0400
From: Curtis Villamizar <curtis@faster-light.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: curtis@faster-light.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

In message <20051012202706.GB27304@verdi>
John Leslie writes:
>  
> Curtis Villamizar <curtis@faster-light.net> wrote:
> > 
> > The deployment of as4bytes is likely to be similar to the deployment
> > of bgp4 itself. 
>  
>    I would hope we could do better -- or at least better than that
> transition would be if scaled to today's deployment figures.

It actully went quite well.  The first BGP4 implementation to be
deployed was Cisco, written by Tony, deployed by Sean Doran of
Sprintlink, then others.  That happenned in about October 1993.  The
next major hurdle was the NSFNET finishing the gated implementation,
that Dennis Furgusson was writing.  That was done in very early 1994
and was deployed by about February 1994.  In the mean time a few
research people like ISI were announcing CIDR routes for testing
purposes.  At the April 1994 IETF the BGPD WG met and it was decided
that BGP4 deployment was widespread enough and nothing bad happenned
with the test routes and CIDR was turned on.  It worked.

What was the problem that you wouldn't want to repeat?  First
implementation to global deployment in a little over 1/2 year.  No
negative impacts on the network other that NASA had to take default
routes due to their proteon routers.

> > In both cases it is known that "bad things can happen" if a subset of
> > core AS deploy "the new stuff" and enable "the new features", in this
> > case start using 4 byte AS numbers. 
>  
>    Agreed, "bad things can happen". :^(
>  
>    Some of them, I would hope, we can predict and tell folks how to
> recognize. That by itself would ease the transition.
>  
>    In an ideal world, we could deploy some debugging tools to aid in
> finding where the problems originate and how to fix them most quickly.
> (Alas, I have no suggestions at the moment.)
>  
> > Since the day that we are actually forced to use 4 byte AS numbers
> > is still quite a ways off it is likely that tier-1 and tier-2
> > providers will deploy as4bytes capable code long before any 4 byte
> > AS is advertised.
>  
>    ... for real customers...
>  
> > It is also likely that providers will coordinate the deployment
> > advertising some test AS numbers first. 
>  
>    Hopefully true. There is no substitute for live testing.
>  
> > It is also possible that straglers will remain that have not deployed
> > as4bytes capable code or have not enabled it, but like NASA in 1994
> > who were still running EGP on their Proteon routers and couldn't
> > handle CIDR routes for a while, it is likely that these straglers
> > are not providing major transit and won't have any impact on the rest
> > of the Internet.
>  
>    That's a bit optimistic, if you mean that bugs in their code won't
> affect the rest of us. Hopefullly it will represent a small minority
> of transport, but I'll be surprised if it doesn't consume a larger
> share of our time chasing rare problems.
>  
> > Just as at the point of CIDR deployment the rule was "support CIDR or
> > use a default route" the rule when as4bytes is deployed may have to be
> > "support as4bytes or use a default route".
>  
>    It's really not that simple, but certainly having a fallback default
> should be strongly recommended for anyone not willing to chase problems.
>  
>    The fly in the ointment is that your _own_ router supporting as4bytes
> won't protect you from bugs introduced by an OLD BGP middleman. While
> there is reason to hope we can "mostly" avoid OLD BGP middlemen, I
> don't believe we can entirely avoid them.
>  
> > If we persisted in discussing what happens in arbitrary mixed
> > CIDR/non-CIDR and BGP/EGP networks we'd still be running EGP and the
> > Internet would have collapsed long ago. 
>  
>    That was a rather different time. There were a limited number of
> backbone routers which _had_to_ support CIDR, and we arranged for them
> to do so. The "don't even try to run defaultless without CIDR" rule
> was very little hassle. As far as BGP-vs-EGP, folks were welcome to
> waste however much time they wanted there, but if they screwed up we
> could simply ignore their routes.
>  
>    Those rules won't work today. We're going to have to plan a campaign
> with no flag days.


Backbone routers were spread among commercial and research backbones.
I'd guess that there were some 50 organizations that took full routes
and had to deploy CIDR capable router code or switch to default.

At that time many US states or groups of states had regional
networks.  Many large US governement agencies had networks providing
transit, not just the NSF, there were many separate European networks
each run by a private or governement agency int a different country,
and there were purely commercial providers as well.

The players have changed but the number of players and peering
complexity has not changed that radically.

CIDR was a much bigger change than as4byte.  CIDR could affect
everything down to the LAN and even the host.  The as4byte changes
affect only provider routers running BGP.


> > This is not to say that some discussion isn't good but at this point
> > we are beating a dead horse.
>  
>    "I ain't dead yet!" ;^)
>  
> > Lets move on with as4bytes.  We hopefully can assume that intelligent
> > people are at the controls at the tier-1 and tier-2 networks for some
> > value of intelligent that is sufficient to get this deployment right.
>  
>    I don't want to claim there aren't enough intelligent folks there,
> but the intelligent ones I know have been known to express such doubts.
> Besides, this is a problem of interaction _between_ AS domains: there's
> not necessarily any level of intelligence sufficient to keep up with
> funky things happening as other AS domains try to adjust to the funky
> things they're seening from yet other AS domains...
>  
>    We're in WGLC here. However much we wish otherwise, it takes a WGLC
> to bring out some issues. We need to be intelligent about whether those
> issues are things worth treating in the spec.
>  
>    Personally, I see several areas which my experience tells me are
> very much worth treating in the spec. YMMV...
>  
> --
> John Leslie <john@jlc.net>

If you get 90+% of the networks to transition to being as4byte
capable, then run a lot of test routes with 4 byte AS and see where
they don't go and also to see that they don't cause trouble where they
do go.

The first time ISI put a CIDR route into the global routing they
repeatedly added it and then withdrew it after a few minutes in case
anything bad happenned that they couldn't detect.  Others were doing
the same and those announcing CIDR test routes were cooperating in the
testing.

Then put google, yahoo, and a few other biggies behind a 4 bytes AS
and watch how fast the other <10% convert.  :-)

OK so that's not quite practical, but essentially the problem is the
occasional uncooperative who doesn't get with the program and doesn't
even keep track of what is going on in IETF.  With CIDR it was PSI.
NASA was cooperative in that they had old unsupported routers and so
they used default routing for a while and converted late, but they
made it a point not to hold up CIDR deployment.

The whole point is that there is no problem using as4byte capable code
and using only 2byte AS until there is a need.  During that time
originating test routes from as4byte test AS around the globe can help
flush out the straglers.  In this case there is plenty of time.

Curtis

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr