North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: 4-Byte AS Number soon to come?

  • From: Paul Jakma
  • Date: Tue Aug 23 09:20:32 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 [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
"When people are least sure, they are often most dogmatic."
-- John Kenneth Galbraith