Anyone in the list has a good update on the IETF:draftietf-
idr-as4bytes-10.txt ?
Is the projection os AS Number exhaustion of 2011-2013 exaggerated or do
we really have a potential big problem with a slow solution ahead of us?
-Elvis.
expect that brickwall to be pretty solid.
--bill
(working on a patch for Zebra to handle 4byte ASNs)
Elvis DePaula wrote:
Anyone in the list has a good update on the IETF:draftietf-
idr-as4bytes-10.txt ?Is the projection os AS Number exhaustion of 2011-2013 exaggerated or do we really have a potential big problem with a slow solution ahead of us?
-Elvis.
Are you asking this after having read recent archives or not?
Joe
Pretty much. I also read the pdf posting from Geoff Huston (The ISP
Column).
-E.
Hi,
The IDR draft is awaiting implementation report. There are apparently two implementations, one with field deployment, which suffices to move the draft forward. I happen to have one concern about the draft, and I'd like to ask on NANOG to find out whether or not my concern is of actual operational significance (ie significant enough to revise the draft and start again on implementations):
How important is the operational use of BGP protocol analysers?
Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug a BGP problem?
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 whether the flow uses 2 or 4 byte ASNs?
Do you ever have an operational need to watch several BGP flows at the same time?
Are there any other operational uses for tools which *passively* read BGP besides debug? Eg, passive gathering of BGP data, a 'BGP IDS'? Are these used at all?
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.
Thanks.
regards,
The IDR draft is awaiting implementation report.
If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways.
Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to debug a BGP problem?
I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic.
(It's easier if tcpdump is implemented on your router, of course.)
>The IDR draft is awaiting implementation report.
If this is true, it's very distressing. Drafts are deleted after
about six months. That means that any implementations will be based
on a no longer existing specification. That's wrong in so many ways.
... working code...
based on the draft that is there, there are serious implementation
problems, e.g. the draft needs clarification. one does not expect
prototype implementations based on drafts to be production level
code... well this one does not anyway. implement away.
>Is it common or uncommon to fire up 'ethereal' or 'tcpdump' to
>debug a BGP problem?I think I only felt the need to do this a handful of times over the
last decade, but it's generally difficult to position tcpdump such
that it will intercept the eBGP traffic.(It's easier if tcpdump is implemented on your router, of course.)
i did during the BGP3-BGP4 transition, and a couple of times
in the "add-thousands-of-knobs" to BGP4... I expect this transtion
will be similar.
--bill
If this is true, it's very distressing. Drafts are deleted after about six months. That means that any implementations will be based on a no longer existing specification. That's wrong in so many ways.
Well, maybe that was a misunderstanding of IETF process of mine. But AIUI, it's intended to progress towards proposed standard, and getting implementations is part of that, in some fashion.
The draft has been kept active by the IDR since 2001 btw.
I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic.
Ok. So that's a "not important" then.
I'm interested in operational use of any kind of passive BGP 'reader' btw - not just ethereal/tcpdump. (Just to make it obvious 
).
regards,
Paul Jakma wrote:
I think I only felt the need to do this a handful of times over the last decade, but it's generally difficult to position tcpdump such that it will intercept the eBGP traffic.
Ok. So that's a "not important" then.
I'm interested in operational use of any kind of passive BGP 'reader' btw - not just ethereal/tcpdump. (Just to make it obvious
IMO it is very important to have the ability to listen into a BGP
stream at any point in time and have the reader decode the updates/
withdrawls starting from the next message boundary.