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

From: Larry Blunk <[email-masked]>
Date: Fri, 26 Feb 2010 12:54:24 -0500

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