4-Byte AS Number soon to come?
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.
On Mon, Aug 22, 2005 at 05:05:02PM -0400, 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.
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. On Mon, 22 Aug 2005, Joe Maimon wrote:
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
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, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Piece of cake! -- G.S. Koblas
On 23-aug-2005, at 11:53, Paul Jakma wrote:
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.)
On Tue, Aug 23, 2005 at 12:53:45PM +0200, Iljitsch van Beijnum wrote:
On 23-aug-2005, at 11:53, Paul Jakma wrote:
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
Bill,
On Tue, Aug 23, 2005 at 12:53:45PM +0200, Iljitsch van Beijnum wrote:
On 23-aug-2005, at 11:53, Paul Jakma wrote:
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.
If you think there are problems with the draft please send an e-mail to the IDR mailing list describing the problems. Yakov.
On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote:
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 paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The doctrine of human equality reposes on this: that there is no man really clever who has not found that he is stupid. -- Gilbert K. Chesterson
Paul Jakma wrote:
On Tue, 23 Aug 2005, Iljitsch van Beijnum 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. -- Andre
Folks,
On Tue, 23 Aug 2005, Iljitsch van Beijnum wrote:
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 ;) ).
May I suggest that you send your opinion on this topic to the IDR mailing list (idr@ietf.org), as it would help the IDR WG to reach a (rough) consensus on how to proceed with the draft. Yakov.
participants (7)
-
Andre Oppermann -
bmanning＠vacation.karoshi.com -
Elvis DePaula -
Iljitsch van Beijnum -
Joe Maimon -
Paul Jakma -
Yakov Rekhter