Erik Romijn wrote:
Hi Ondrej,
Ondrej Zajicek wrote:
I am implementing MRT dump feature in BIRD Internet Routing Daemon [1]
I have done quite some of the work on implementing AS4 MRT support in
Quagga, and am one of the current maintainers of libbgpdump.
I have looked at your suggestions and how this is currently implemented
in Quagga and libbgdump, which are used to create process RIS[1] data.
- Fields Local/Peer IP address (and even Peer AS number) may
be sometimes undefined (if there is no open TCP connection, for
example in BGP4MP_STATE_CHANGE generated by Idle -> Active state
change). It would be nice to mention in the draft that these fields
may be also zero if the values are unknown/undefined.
I don't see any state changes without a peer IP address in RIS data, but
I do see some where the peer AS is recorded as zero. So, your suggestion
seems consistent with that.
I will add text to indicate that the AS number should be
zero if undefined.
- The IP address / AS number fields are marked as Peer / Local,
but bgpdump tool shows them as From / To. Is there an implicit
assumption that only received (and not sent) BGP messages are
dumped?
I don't think there is such an assumption. Probably the naming used in
bgpdump was written assuming that it would be mostly used to look at
received messages.
However, looking at RIS data, it does seem like Quagga does not store
self-originated BGP messages at this time. But, I see no reason to
forbid this in the format.
Erik,
Would you be in favor of changing the draft language
to use From/To or Source/Destination instead of the current
Peer/Local distinction and explicitly permit the logging of
locally generated messages? In the case of locally generated
messages, the AS numbers and IP's would be swapped.
I think that if the Peer/Local language is
left as is, new subtypes would be needed. I guess my preference
would be to change the language.
- The most important question is whether difference in BGP4MP_MESSAGE
and BGP4MP_MESSAGE_AS4 is just in MRT message header format, or if it
is also semantic information whether these BGP messages were received
in 'AS4-style' session or 'old' session (and therefore whether
AS_PATH attribute in UPDATE messages contains 2B or 4B AS numbers).
For the current implementation in Quagga there is semantic information.
The code checks whether the AS4 capability is present on the session
and, if so, uses BGP4MP_MESSAGE_AS4. If the AS4 capability is absent, it
will use BGP4MP_MESSAGE and write the AS_PATH and AS4_PATH attributes as
received from the peer.
However, I am not entirely sure whether it should be an explicit
requirement to store this semantic information in this way.
Table dumps are always done in TABLE_DUMP_V2 format in Quagga, because
all internal structures of Quagga are AS4-capable.
Could you and Ondrej come up with some text on what you
would like to see in the draft?
Thanks,
Larry Blunk
Merit
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
