[76252] in North American Network Operators' Group
Re: 16-bit ASN kludge
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Dec 3 21:10:10 2004
Date: Fri, 03 Dec 2004 18:09:48 -0800
From: Owen DeLong <owen@delong.com>
To: "Edward B. Dreger" <eddy+public+spam@noc.everquick.net>
Cc: John Dupuy <jdupuy-list@socket.net>, nanog@merit.edu
In-Reply-To: <Pine.LNX.4.44.0412040019470.8060-100000@a.mx.ict1.everquick.net>
Errors-To: owner-nanog-outgoing@merit.edu
--==========3976027474C77462FC01==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I think all the meaningful parties have already pretty much agreed on
32bit ASNs in BGP4. I think that will be coded in the routers well before
any attribute-based thing for 32bit ASNs is. As such, I don't see much
point to kludging this instead of just going for it assuming a 32bit world.
Owen
--On Saturday, December 4, 2004 0:30 +0000 "Edward B. Dreger"=20
<eddy+public+spam@noc.everquick.net> wrote:
> OD> Date: Fri, 03 Dec 2004 14:45:17 -0800
> OD> From: Owen DeLong <owen@delong.com>
>
> OD> I think the original proposal was to still go with 32 bit ASNs, but,
> adapt OD> a range of 32 bit ASNs for the assignment to "NON-TRANSIT" ASNs
> leaving OD> the entire 16 bit range reserved for "TRANSIT" ASNs.
>
> Correct. BGP would still carry traditional 16-bit ASNs, which would be
> used strictly by transit networks. Leaf ASes would use the "new" 32-bit
> ASNs, which would be carried as BGP attributes.
>
> It's similar to a transit provider with a downstream connected to
> multiple POPs: $transit_provider assigns all downstreams a private AS,
> which is stripped from outbound advertisements.
>
>
> OD> I think there's merit to the idea, but, I think that it could use =
some
> OD> refinement. I agree there will be many more non-transit than transit
> ASNs
>
> No disagreement re needing refinement. I lack the clout to push BGPv8
> on the world. ;-)
>
>
> OD> (non-transit is an ASN that does not provide transit, transit is an
> OD> ASN that provides transit).
> OD>
> OD> I think it would make more sense to put the boundary somewhere around
> 12 OD> bits or so. If we reserved the first meg 1024k ASNs for transit
> providers OD> (excepting the Private ASN reservation already in place),
> and, allowed the OD> remaining ASNs to be assigned to non-transit ASNs,
> this functionality could OD> be implemented relatively easily with
> maximum backward compatibility.
>
> Part of the kludge intent was to create something that standard routers
> would carry. Hence 16-bit traditional ASNs, with extended information
> as an attribute. It certainly would be possible to reserve 2^20 "new"
> ASNs, though, for when BGP5 (or whatever) had native 32-bit support.
>
>
> 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.
>
--==========3976027474C77462FC01==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQFBsRxsn5zKWQ/iqj0RAq+RAJ0cXu7kToOPn/D5W7/tZFGKtZgvEQCeKu8k
2kOWgoxGkziy4YeYMOwIL8Y=
=u+tL
-----END PGP SIGNATURE-----
--==========3976027474C77462FC01==========--
