16-bit ASN kludge

Mailman List Mirror (Read Only)
1

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"

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

2

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

3

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

4

So given the lack of trouble with NAT sites leaking rfc1918 addresses, you
foresee no problems with sites accidentally leaking the non-public ASN's, right?

5

I don't see non-transit ASN leakage as any greater issue than current
private ASN leakage.

However, I do see the ability to use non-transit ASNs to multihome end sites
with provider independent addresses and allow better aggregation as a good
thing. In this case, leakage would only have the same consequences as doing
things the way we do them now.

I don't see a real downside.

Owen

6

Date: Fri, 03 Dec 2004 14:45:17 -0800
From: Owen DeLong <owen@delong.com>

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.

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.

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

No disagreement re needing refinement. I lack the clout to push BGPv8
on the world. :wink:

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

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

7

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

8

Date: Fri, 03 Dec 2004 18:09:48 -0800
From: Owen DeLong

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.

Then belay my 16-bit ramblings. I'm probably a bit naive in thinking a
new attribute would be passed along by enough transits to be useful; an
"adopt this incompatible protocol or become an island" approach may well
be needed.

I still have to wonder if some leaf optimizations are possible. Perhaps
an incompatible protocol would leave more implementation wiggle room.

Eddy

9

I think the general idea of dividing ASNs into LEAF and TRANSIT categories
is a good one. A method of determining which ASs need to know about
a given LEAF AS is needed, and, I think a lot of optimizations may well
be possible.

Like I said, I think it requires some additional thought and refinement,
but, I like the general idea.

Owen

10

I think the general idea of dividing ASNs into LEAF and TRANSIT categories
is a good one. A method of determining which ASs need to know about
a given LEAF AS is needed, and, I think a lot of optimizations may well
be possible.

So now people have to renumber their AS when they start selling transit? Not such a great idea...

Now watch out, since you completely unnecessirily quoted Eddy's message in full, I'm going to reply to that here rather than use a separate message for this.

> 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 OD> any attribute-based thing for 32bit ASNs is. As such, I don't
see much OD> point to kludging this instead of just going for it assuming
a 32bit world.

Then belay my 16-bit ramblings. I'm probably a bit naive in thinking a
new attribute would be passed along by enough transits to be useful; an
"adopt this incompatible protocol or become an island" approach may well
be needed.

This is not what the 32 bit AS draft proposes. (From memory, so I might get some of the small details wrong.) The idea is that the new 32 bit AS path is a new transitive attribute, which should be carried by existing BGP implementations. However, the 16 bit AS path is still there as well, with all the 16 bit incompatible ASes replaced by a "special" AS.

So all of this should work with existing implementations except that they don't see the full picture so AS path filtering on 32 bit ASes won't work. Basic operation shouldn't be a problem, though.

Note that I suggested starting to give out 32 bit AS numbers to new 32 bit compatible leaf sites while giving out 16 bit AS numbers to transit ASes as a way to ease in to all of this with the least amount of operational trouble. But at some point we'll run out of 16 bit AS numbers and 32 bit leaf networks will become transit networks, so people should upgrade at some point or live with the reduced filtering capabilities. And new ASes can't get around 32 bit support if their AS number isn't 16 bit safe, of course.

I still have to wonder if some leaf optimizations are possible. Perhaps
an incompatible protocol would leave more implementation wiggle room.

What would you like to optimize for?

11

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.

Was I the only person who noticed when someone (apparently) typoed
their router config and leaked a 32-bit ASN into the global table?
(This was about 3 months back - I don't recall any mention of it
then)

12

Date: Sat, 4 Dec 2004 12:17:22 +0100
From: Iljitsch van Beijnum

So now people have to renumber their AS when they start selling
transit? Not such a great idea...

Yeah. They'll have to tell their upstreams "here's our new ASN". No
downstreams will be affected -- by definition. Hopefully routers will
be friendlier to ASN changes; else one can use confederations.

How is this half as bad as renumbering even a /22 of IPv4 space? I'll
grant that it's imperfect, and there'd be the occasional large leaf with
many routers to reconfigure, but leaves tend to be _small_ networks.

This is not what the 32 bit AS draft proposes. (From memory, so I might
get some of the small details wrong.) The idea is that the new 32 bit
AS path is a new transitive attribute, which should be carried by
existing BGP implementations. However, the 16 bit AS path is still
there as well, with all the 16 bit incompatible ASes replaced by a
"special" AS.

Close, except I initially suggested 16-bit ASNs be reserved for transit
networks.

So all of this should work with existing implementations except that
they don't see the full picture so AS path filtering on 32 bit ASes
won't work. Basic operation shouldn't be a problem, though.

Correct. Existing software would see the "special" 16-bit AS for all
leaves. Newer software would understand $attribute and supply the
correct AS path.

Note that I suggested starting to give out 32 bit AS numbers to new 32
bit compatible leaf sites while giving out 16 bit AS numbers to transit
ASes as a way to ease in to all of this with the least amount of
operational trouble. But at some point we'll run out of 16 bit AS
numbers and 32 bit leaf networks will become transit networks, so

I suppose there could be in excess of 65431 transit networks. I think
that's why Owen suggested reserving, say, 2^20 ASNs for transit in
32-bit space. That's probably wise, and at that point 16-bit ASNs would
be totally unsuitable. Until then, though...

people should upgrade at some point or live with the reduced filtering
capabilities. And new ASes can't get around 32 bit support if their AS
number isn't 16 bit safe, of course.

No matter _what_ the implementation details of expanded ASN space,
people must upgrade or lose <varying amounts of> capabilities.

What would you like to optimize for?

Application of Dijkstra's algorithm. Perform full SPF calculations on
transit networks. Leaves carry "my upstream" attributes with metrics a
la DPA; such information is combined with relevant transits' metrics.
Although not directly akin to OSPF stub areas and NSSAs, the basic
premise is the same.

Eddy

13

I suppose there could be in excess of 65431 transit networks. I think
that's why Owen suggested reserving, say, 2^20 ASNs for transit in
32-bit space.

How does this make sense? If you have one of the ASes in the range 2^16 - 2^20-1 you, your customers and your transits still need to be able to handle 32 bit AS numbers. Apart from the backward compatibility being slightly more important for transit networks there is no upside to having a separate transit network and leaf network AS space.

> What would you like to optimize for?

Application of Dijkstra's algorithm.

Well, then you're in luck as BGP is highly optimized in this regard: it doesn't use the Dijkstra or SPF algorithm. BGP is pretty much a distance vector routing protocol.

14

My thinking was that transit networks could aggregate leaf advertisements
and share only the aggregates instead of the more specifics. The hope
here was that by having separate leaf/transit ASNs, we could perform another
level of routing table size management/optimization.

I think optimizing for backward compatibility for transit initially, and,
eventually, for transit routing table size while still providing leaf
multihoming capabilities is desirable.

Owen

15

Date: Sun, 5 Dec 2004 15:55:04 +0100
From: Iljitsch van Beijnum

Well, then you're in luck as BGP is highly optimized in this
regard: it doesn't use the Dijkstra or SPF algorithm. BGP is pretty
much a distance vector routing protocol.

D'oh. Pardon the round of public stupidity. I think I need to back
away from OSPF for a bit.

Eddy

16

If somebody leaks a private ASN, we can tell that it's a private ASN by
inspection.

If somebody is using '1312' inside their parallel ASN space and accidentally
leaks it, it's a bit harder to diagnose.

And if somebody is leaking 1312, I'll be quite put out... :wink:

17

The proposal was that transit ASNs would begin with 12 leading 0 bits and
non-transit ASNs would not. As such, 1312 would not be a non-transit ASN.

The proposal wasn't for "parallel" ASN space. The proposal was to have
a range of ASNs for leaf-networks and a range for transit networks, allowing
transit networks to make more rational (possibly automated) decisions about
route aggregation.

Owen

18

The proposal wasn't for "parallel" ASN space. The proposal was to have
a range of ASNs for leaf-networks and a range for transit networks, allowing
transit networks to make more rational (possibly automated) decisions about
route aggregation.

That may be sane, but that's not how I read John's actual proposal:

19

Sorry... I was talking about Eds proposal... I hadn't noticed the shift
to an entirely different proposal by John.

I think Eds proposal (which I proposed some modification to) has merit.
I think Johns alternative is far less desirable and agree with your concerns
about it.

Owen