RE: 4-Byte AS Number soon to come?

Mailman List Mirror (Read Only)
1

Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug
a BGP problem?

I have done that a few times in my life (not that i have lived long
enough like others in this list)

Would it be problematic to have to either a) clear sessions for your
analyser to fully understand the BGP stream or b) tell your analyser

Are you're talking about clearing the BGP session between the two
remote ends, for the *analyser* to work? 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!

whether the flow uses 2 or 4 byte ASNs?

This would imply prior knowledge about the ASNs which may not be
available with the analyser.

Essentially, this draft as it stands is going to make it difficult to
observe and comprehend BGP AS_PATH without either human intervention
or restart of the session(s) concerned. A guage how much of a problem
this would be in real-life (if any problem at all?) would be useful
in determining whether it's worth lobbying to change the draft.

If there isnt a wide installed base for the draft, and if there are
solutions available that can solve this problem then i would prefer
going ahead with the new solution and picking it up if it works!

Kent

2

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. :wink:

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,

3

This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study. There has been a huge inflation of the status of various IETF documents, to the degree than BGP today apparently isn't considered mature enough to be an "internet standard".

BTW, I find the notion that there is a new attribute that carries 32-bit AS numbers while at the same time the original AS path can either hold 16-bit or 32-bit AS numbers depending on the capabilities of the peer rather strange. Why not simply keep the current AS path 16 bits and create a new 32-bit one?

And what's with that "octet" thing, anyway.