RE: 4-Byte AS Number soon to come?
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
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@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "When people are least sure, they are often most dogmatic." -- John Kenneth Galbraith
On 23-aug-2005, at 15:16, Paul Jakma wrote:
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.
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.
In message <C4572125-356D-49B9-BE24-AA55B1C014E7@muada.com>, Iljitsch van Beijn um writes:
On 23-aug-2005, at 15:16, Paul Jakma wrote:
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.
This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study.
In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations. For everything else, you're right. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
On 23-aug-2005, at 23:55, Steven M. Bellovin wrote:
This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study.
In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations.
Ah, that makes sense. So how does that work for work on TCP (which is even more crucial than BGP)? You have to have interoperable implementations before writing the draft? (I knew the IETF had some trouble with its internal organization. I had no idea it was this bad.)
In message <4EB85F14-0F65-45F6-8DF4-F11A8EE638FD@muada.com>, Iljitsch van Beijn um writes:
On 23-aug-2005, at 23:55, Steven M. Bellovin wrote:
This is exactly why people shouldn't implement drafts except possibly as a private in-house feasibility study.
In general, you're right; however, BGP documents have a special status. Because of how crucial BGP is to the Internet's functioning, I-Ds won't progress to RFC status (at least as Proposed Standard) without two interoperating implementations.
Ah, that makes sense. So how does that work for work on TCP (which is even more crucial than BGP)? You have to have interoperable implementations before writing the draft?
No. TCP is end-to-end; a problem shows up on that connection. By contrast, a BGP issue can affect everyone else, since your peers see only what you advertise based on your policy and what you've learned from others. Put another way, your problems (or your implementation's problems) affect others. That's not true for TCP, with the exception of congestion control behavior.
(I knew the IETF had some trouble with its internal organization. I had no idea it was this bad.)
Some would say that it's a feature -- rely on running code. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
participants (4)
-
Glen Kent -
Iljitsch van Beijnum -
Paul Jakma -
Steven M. Bellovin