Subject: Re: [GROW] Missing things in the current MRT draft

From: Erik Romijn <[email-masked]>
Date: Mon, 04 Jan 2010 13:30:39 +0100

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.

>  - 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.

>  - 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.

[1] http://www.ripe.net/ris/

cheers,
Erik Romijn
Software Engineer
RIPE NCC

---

From: Ondrej Zajicek <[email-masked]>
Date: Tue, 5 Jan 2010 11:42:57 +0100

> Quagga, and am one of the current maintainers of libbgpdump.

Thank you for the answer.

> will use BGP4MP_MESSAGE and write the AS_PATH and AS4_PATH attributes as

I examined the behavior of Quagga and found this behavior, but with
one exception - first message (OPEN meesage) of the session is always
logged as BGP4MP_MESSAGE, even if it contains AS4 capability.
This seems a bit crazy to be, for example it does not allow to
store real AS numbers.

I tested Quagga version 0.99.6, so i don't know if it is not fixed in
later releases, but latest bgpdump tool expects this behavior - it
parses OPEN messages stored in BGP4MP_MESSAGE_AS4 incorrectly.

> requirement to store this semantic information in this way.

This has two sides - if it is not a requirement, it cannot be expected
by tools processing stored MRT dumps. And current bgpudmp tool expects
that. It fails to parse AS_PATHs in 'old-style' UPDATEs stored
BGP4MP_MESSAGE_AS4.

-- 
Ondrej 'SanTiago' Zajicek (email: [email-masked])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."