Subject: [Idr] Fwd: about the NLRI encoding extensions

From: Denis Ovsienko <[email-masked]>
Date: Mon, 30 Nov 2015 10:55:08 +0000

Hello.

As the below message had never been responded to, let me forward those comments to the WG mailing list (which I am not a subscriber of). They still seem to apply to the latest version of the I-D.

 == == == == == == Forwarded message == == == == == == 
>From : Denis Ovsienko<[email-masked]>
To : <[email-masked]>
Date : Mon, 29 Jun 2015 18:59:34 +0100
Subject : about the NLRI encoding extensions
 == == == == == == Forwarded message == == == == == == 
Greetings to the people behind draft-ietf-idr-add-paths!

Today I was helping to look into a BGP issue, which later turned out to be a bug in an implementation of ADD-PATH. The first thing I noticed during the packet capture study was that tcpdump did not recognize the capability 69, so I found respective specification and decided to add that support while at it. The capability part of the specification (Section 4) was straightforward but looking at the NLRI section (Section 3) I had realized that there was no way to tell which of the encodings a given NLRI attribute is going to have. So it ended up done just half-way: https://github.com/the-tcpdump-group/tcpdump/commit/c9c3d3cfdf3a926e02114cfe611ffe20167ab5f4

Of course, it can be said that looking at both OPENs of a BGP session and the Send/Receive field of the capability it is possible to see which format must be used in the subsequent UPDATE messages. But in the scope of a network analyzer it is very much preferred to be able to decode a given protocol packet with as little dependency on earlier packets as possible. This is in part because packet loss just happens and in part because packet captures don't necessarily cover full protocol sessions, especially where sessions remain up for a long time.

To add to this, the actual speaker behaviour was inconsistent with the OPENs: with the capability set to 3 on both ends one speaker sent MP_REACH_NLRI in the traditional encoding (without prepending the path identifier field). The network prefixes themselves were correct otherwise. The other speaker detected an encoding error and shut down the session with a NOTIFICATION message. But in a slightly different configuration the first speaker behaved according to the I-D and sent MP_REACH_NLRI respectively encoded. Though the BGP session stayed up it wasn't possible to read the prefixes any more as the decoder has no means to understand it needed to switch to the ADD-PATH format. In this context it would be very handy to have an explicit indicator of the encoding (normal/extended) right in the UPDATE message, so that the packet analyzer could properly display the contents regardless of the OPENs.

In theory, a possible (from packet analyzer point of view) way to do that could be not to reuse previously assigned path attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) to mean a new, not backward-compatible structure, but to assign new attributes for the new encoding. As far as I can see, this does not help the non-MP traditional NLRI part of an UPDATE, but this may be irrelevant. I am not an expert. Since this I-D is in a very late development phase and there are implementations around, I understand this is too complicated anyway due to existing deployments.

Do you see any _other_ simple ways to encode the "extended NLRI format follows" hint into an UPDATE message? An additional attribute maybe?

Thank you.

-- 
 Denis Ovsienko

-- 
    Denis Ovsienko