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

John Leslie <john@jlc.net> Wed, 12 October 2005 20:27 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCE-0007Hr-T0; Wed, 12 Oct 2005 16:27:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPnCD-0007H0-7J for idr@megatron.ietf.org; Wed, 12 Oct 2005 16:27:30 -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 QAA28958 for <idr@ietf.org>; Wed, 12 Oct 2005 16:27:26 -0400 (EDT)
Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPnMX-0002Y9-C8 for idr@ietf.org; Wed, 12 Oct 2005 16:38:12 -0400
Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B404E0595; Wed, 12 Oct 2005 16:27:06 -0400 (EDT)
Date: Wed, 12 Oct 2005 16:27:06 -0400
From: John Leslie <john@jlc.net>
To: Curtis Villamizar <curtis@faster-light.net>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
Message-ID: <20051012202706.GB27304@verdi>
References: <200510111734.j9BHYi7a017649@workhorse.faster-light.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200510111734.j9BHYi7a017649@workhorse.faster-light.net>
User-Agent: Mutt/1.4.1i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: idr@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

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.

> 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.

> 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>

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