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

Geoff Huston <gih@apnic.net> Thu, 13 October 2005 07:19 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxNK-0000a4-Tp; Thu, 13 Oct 2005 03:19:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxNJ-0000Zz-Cn for idr@megatron.ietf.org; Thu, 13 Oct 2005 03:19:37 -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 DAA28476 for <idr@ietf.org>; Thu, 13 Oct 2005 03:19:34 -0400 (EDT)
Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPxXk-0001TV-Dk for idr@ietf.org; Thu, 13 Oct 2005 03:30:26 -0400
Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id j9D7BrXv071750; Thu, 13 Oct 2005 17:12:00 +1000 (EST) (envelope-from gih@apnic.net)
Message-Id: <6.2.0.14.2.20051013171027.02d20c40@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 13 Oct 2005 17:11:51 +1000
To: curtis@faster-light.net
From: Geoff Huston <gih@apnic.net>
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-as4bytes-11.txt
In-Reply-To: <200510130522.j9D5MfpE037505@workhorse.faster-light.net>
References: <Your message of "Thu, 13 Oct 2005 14:39:16 +1000." <6.2.0.14.2.20051013143340.02e25900@localhost> <200510130522.j9D5MfpE037505@workhorse.faster-light.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: idr@ietf.org, Paul Jakma <paul@clubi.ie>, John Leslie <john@jlc.net>
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

 > Would you prefer transit and stub to backbone and edge?

yes!

>It doesn't matter which AS converts to as4byte capable first as long
>as the deployment is very far along before 4 byte AS start showing up.


I have got to agree wholeheartedly here

   geoff


At 03:22 PM 13/10/2005, Curtis Villamizar wrote:

>In message <6.2.0.14.2.20051013143340.02e25900@localhost>
>Geoff Huston writes:
> >
> >
> > > > It's the other way around more likely. The edges of the internet are
> > > > more likely to go NEW first...
> > >
> > >    We've agreed that we should spec a transition which can work
> > >either way (backbone going 4-byte first or edges going 4-byte first).
> >
> > I do not understand this. Surprisingly, he earth is not flat.
>
>That is only a theory according to some proposed science curriculum
>revisions in the US.  [Is that too US Centric a joke?]
>
> > What is
> > an 'edge' and what is a 'backbone' are from an individual network
> > operator's perspective often arbitrary distinctions, and then talking
> > about which is these "goes first" is perhaps unhelpful What I like
> > about the draft as it stands is that it views transition as a set of
> > OLD / NEW and NEW / OLD transitions. That's simple and effective.  I
> > would not readily ascribe attributes to a transition spec that starts
> > from a premise of "backbones" and "edges" and then starts to talk
> > about which "goes first".
> >
> > regards,
> >
> >      Geoff
>
>Edges are things that are single homed or at most dual homed but the
>important thing is that they don't take full routes, don't provide any
>transit, and don't readvertise any routes that they learn from one
>Internet facing interface to another.
>
>Would you prefer transit and stub to backbone and edge?
>
>It doesn't matter if single homed stubs ever understand as4byte.  They
>don't really need to run an external routing protocol.  The dual homed
>non-transit might take a subset of routes, but if a few are missing
>they'll never know since they have a default (other than load balance
>might be affected).  As soon as an AS passes routes from one peer to
>another it might start to matter, but many small providers don't
>provide transit to any BGP peers and their customers are not (or
>should not be) passing routes to their other providers if dual homed
>to more than one provider.  These "edges" don't have to convert before
>a transition occurs.
>
>It doesn't matter which AS converts to as4byte capable first as long
>as the deployment is very far along before 4 byte AS start showing up.
>
>Curtis



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