16-bit ASN kludge

Fri Dec 3 22:45:17 UTC 2004

I think the original proposal was to still go with 32 bit ASNs, but, adapt
a range of 32 bit ASNs for the assignment to "NON-TRANSIT" ASNs leaving
the entire 16 bit range reserved for "TRANSIT" ASNs.

I think there's merit to the idea, but, I think that it could use some
refinement.  I agree there will be many more non-transit than transit ASNs
(non-transit is an ASN that does not provide transit, transit is an
ASN that provides transit).

I think it would make more sense to put the boundary somewhere around 12
bits or so.  If we reserved the first meg 1024k ASNs for transit providers
(excepting the Private ASN reservation already in place), and, allowed the
remaining ASNs to be assigned to non-transit ASNs, this functionality could
be implemented relatively easily with maximum backward compatibility.

Just my $0.02.

Owen

--On Friday, December 3, 2004 16:36 -0600 John Dupuy 
<jdupuy-list at socket.net> wrote:

>
> Along these lines, one could leave the transit AS networks alone if a
> parallel 16 bit ASN space were created. Essentially, any non-transit
> network would have it's non-public ASN retranslated NAT-style by upstream
> transit network border routers. Only the border routers would have to be
> changed. They would have to differentiate between public ASN X and
> non-public ASN X (same number) based on the which side of the router the
> ASN was learned from.
>
> This would essentially double the ASN numbers available.
>
> All that being said, I'd much rather see 32-bit ASNs.
>
> John
>
> At 10:48 AM 12/3/2004, Edward B. Dreger wrote:
>
>> Perhaps transit networks should receive 16-bit ASNs.  Leaf networks
>> would use { a special ASN | I'm still brainstorming | who knows } and
>> carry an "available upstreams" BGP tag for each upstream.
>>
>> Metrics are calculated for each transit AS.  Those metrics are then
>> combined with <as yet unspecified intelligence in "available upstreams"
>> tag> for each leaf ASN.
>>
>> BGP loop detection might present a problem if all leaf ASNs use, say,
>> 16-bit AS65535.  If existing allowas-in is too coarse, refer to "32-bit
>> ASN" BGP attribute for fine-grained control.
>>
>> In short: I'm trying to think up a mechanism that performs full Dijkstra
>> calculations _only_ for transit networks, and uses some cheaper version
>> for the degenerate case of a leaf network.
>>
>>
>> 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 at brics.com -*- jfconmaapaq at intc.net -*- sam at everquick.net
>> Sending mail to spambait addresses is a great way to get blocked.
>

-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041203/c2293e08/attachment.sig>