Erik Romijn wrote:
On Tue, Jan 16, 2007 at 03:04:37PM +0100, Simon Leinen wrote:
Erik Romijn writes:
On Mon, Jan 15, 2007 at 10:46:36AM -0500, Larry J. Blunk wrote:
[...]
I am in favour of TABLE_DUMP_32BIT_AS. I don't see any real
advantage to moving to BGP4MP_ENTRY and do see significant extra
work to modify software.
One advantage of BGP4MP_ENTRY is that it includes the SAFI value.
It is otherwise very similar to TABLE_DUMP, so I don't see how
the extra work would be that much more significant than the work to
implement the TABLE_DUMP_32BIT_AS that you propose.
One thing I'm missing here. Where is the peer's AS stored in a
BGP4MP_ENTRY? As a BGP attribute? Or is it not stored at all?
I don't see it being mentioned in the draft.
Erik,
The definition of the BGP4MP_ENTRY subtype was taken from
http://www.zebra.org/zebra/Packet-Binary-Dump-Format.html. The
header does not contain the peer AS -- although I guess it
be divined from the AS_PATH attribute.
I did a bit of implementation review regarding the BGP4MP_ENTRY
and found the following:
1) Zebra/Quagga has an incomplete (only supports IPv4, no IPv6)
and inconsistent (does not include "View #" and "Status" fields)
implementation. Further, it is hard-coded to always use the
TABLE_DUMP type.
2) The Sprint Labs Python Routing Toolkit (PyRT) defines a new type
(BGP-4PY) which includes a subsecond timestamp field. This type
is re-named BGP4MP_ET in the Internet Draft. I had not noticed this
initially, but the BGP4MP_ENTRY definition is modified to include a
source and dest AS number and interface index when used with
the BGP4MP_ET type (which makes it more consistent with
the BGP4MP_STATE_CHANGE and BGP4MP_ENTRY subtypes).
However, PyRT does not actually implement support for the
BGP4MP_ENTRY.
3) OpenBGPd implements support for BGP4MP_ENTRY, but
it is inconsistent with Zebra/Quagga documentation/implementation.
Namely, it includes source/dest AS, interface index, and source/dest
IP addresses.
As an observation, I don't see a need for including non-IPv4 NLRI,
SAFI, and Next-Hop in the BGP4MP_ENTRY header since that info is
already in the MP_REACH_NLRI attribute.
Also, it wouldn't hurt to add TABLE_DUMP_32BIT_AS, would it?
Well, not if you have it already, but if not it's more code...
We don't have it yet, but for both quagga and libbgpdump
TABLE_DUMP_32BIT_AS would be a trivial 30-second change.
All of the code is already there, we just need to disable the address
family mangling and use TABLE_DUMP_32BIT_AS instead.
Code for BGP4MP_ENTRY in quagga is partial, in libbgpdump non-existing.
Given the inconsistent and confusing implementation
support for BGP4MP_ENTRY, I'm tempted to mark it as
deprecated and define a new TABLE_DUMP type that includes
support for 16-bit or 32-bit AS numbers, and includes support
for NLRI other than IPv4 and IPv6. The only question I
have is should it include the local (destination) IP adddress and
AS in addition to the peer's IP and AS numbers?
-Larry
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
