4-Byte AS Number soon to come?

Tue Aug 23 13:16:04 UTC 2005

On Tue, 23 Aug 2005, Glen Kent wrote:

> Are you're talking about clearing the BGP session between the two 
> remote ends, for the *analyser* to work?

My understanding is:

For the analyser, IFF it supports the current 4-bytes draft, to be 
able to *reliably* parse AS_PATH, it must either observe capability 
negotiation during OPEN OR it must be explicitely told which encoding 
is being used by the operator.

To be fair to the draft, in bulk of cases the analyser ought to be 
able to figure out whether AS_PATH is using 4 or 2 byte ASN, simply 
because it will be implausible using one encoding (eg, lots of 0x00 
0x00 byte sequences), and hence it can try with the other.

There may be /some/ cases though where an AS_PATH would be plausible 
regardless of which form of encoding you assume. So the analyser 
would need a 'knob' to allow the user to 'tune-in' the AS_PATH, in 
most cases it would be reasonably to tell which looks the more 
plausible (eg cause of weird things like AS_SETs, CONFED's, etc, that 
you're just not expecting to see much of). There may be a rare set of 
cases where it is not easy to discern whether the path is more 
plausible with one encoding or the other.

Eg:

0x02 0x03 0x00 0x19 0x01 0x56 0x00 0x0c 0x02 0x02 0x00 0x41 0xc9 0x89

This is either 25_342_12_65_51593 in 2-octet encoded AS_PATH data, or 
it's 25:342_12:514_65:51593 in 4-octet encoded.

Which is the right one? A human might now that 65:51593 is nowhere 
near being allocated yet. Or maybe your tool could download a list of 
assigned ASN's from IANA or the RIRs and figure it out that way. ;)

Old analysers, which are not aware of this draft, will produce an 
error or gibberish or worse (eg crash) if they encounter a 4byte 
AS_PATH. (Where, if the draft were done differently, they could still 
at least parse AS_PATH if it were there, or deal with AS_PATH not 
being there at all).

> This is weird and will most definitely not be accepted. There could 
> be numerous such applications running that would want to look at 
> the BGP stream. The peers are not expected to reset the session to 
> make them work!

See above.

> If there isnt a wide installed base for the draft, and if there are 
> solutions available that can solve this problem

There's an easy enough solution, use NEW_AS_PATH, which is specified 
by the same draft. But it would mean changing the draft in a way 
incompatible with itself, when there are deployed implementations of 
it. Ie, need a good reason.

> then i would prefer going ahead with the new solution and picking 
> it up if it works!

Well, in order to justify the hassle of invalidating existing 
implementations of the draft as it stands, I suspect there'd need to 
be sufficient examples of real-world problems with passive BGP 
'readers' to get consensus in IDR to change.

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
"When people are least sure, they are often most dogmatic."
-- John Kenneth Galbraith