Re: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-09.txt

Hi Paolo, Yunan,

>From section 1, intro:
“This means that both Route Monitoring and Peer Down messages have a non-extensible format.”

The above has been updated by section 5.3 RFC9069 where reason code 6 includes TLVs.

“The proposal of this document is to bump the BMP version, for backward compatibility, and allow all message types to make provision for trailing TLV data.”

Do all messages have to be version 4 for a session or can a BMP session use both versions based on the need for additional TLVs or not?

Some comments:

  *   The main use-cases call out route-monitor and peer down messages that didn’t have optional TLVs. RFC9069 updates Peer Down with reason code 6, that indicates TLVs to follow.  Might make sense to use that instead of changing it in version 4.

  *   Instead of sorting TLVs by code point/type/… , wouldn’t it be okay to process them in order as they are encoded? In other words, let the sender define the order by how the sender encodes them. Having to sort would require buffering to process all TLVs so they can be sorted before processing/forwarding on.

  *   To me, encoding per NLRI characteristics in TLVs with indexing is duplicate of attributes. It also could get large when a handful of NLRIs (sharing the same BGP attributes, packed into the same message) have different or shared BMP TLV characteristics.   For example, 10 NLRIs packed, 8 of them share characteristic A and the other 2 share characteristic B.  The TLV cannot be indexed as 0 because all of them do not share the TLVs in common, resulting in 10 TLVs being needed.

  *   The current TLV types suggest the primary use case is per BMP message conveyance of BGP capabilities that effect how to parse the message itself.  Such as add-paths, multiple labels, …  ASN encoding is already indicated by the “A” flag. Both RFC8277 and 3107 are the same in terms of decoding multiples of label 3 octets in length minus the prefix length. This can be handled stateless still.  RFC8277 does clarify what to expect in terms of number of labels, but from a stateless standpoint can’t we still process it as defined by 3107?  This draft focuses on stateless processing, where the Peer Up with the OPEN message was not seen and/or not considered.  I believe the only capability that is a problem is add-paths. Add-paths could be handled with a new flag. I believe all the other BGP TLVs are defined well enough to process the message without having to see the OPEN message exchange. Are there others that cannot be processed stateless?

  *   A VRF name is conveyed via Peer Up and Peer Down and not included in each route-monitor message.  Strictly stateless, the receiver would not know which VRF name the per-peer header correlates to without having some level of state correlation of per-peer header values to Peer Up/Down. Maybe for VRF name it doesn’t matter, but at some point receivers are expected to keep some level of state for peering sessions. This is needed with RIB state tracking and route-refreshes, which may come in via route-mirror message or another/repeated Peer Up message, but not in the form of a route-monitor message.

Thanks,
Tim

On 10/12/22, 5:34 AM, "GROW" <grow-bounces@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

        Title           : TLV support for BMP Route Monitoring and Peer Down Messages
        Authors         : Paolo Lucente
                          Yunan Gu
  Filename        : draft-ietf-grow-bmp-tlv-09.txt
  Pages           : 7
  Date            : 2022-10-12

Abstract:
   Most of the message types defined by the BGP Monitoring Protocol
   (BMP) make provision for optional trailing data.  However, Route
   Monitoring messages (which provide a snapshot of the monitored
   Routing Information Base) and Peer Down messages (which indicate that
   a peering session was terminated) do not.  Supporting optional data
   in TLV format across all BMP message types allows for a homogeneous
   and extensible surface that would be useful for the most different
   use-cases that need to convey additional data to a BMP station.
   While it is not intended for this document to cover any specific
   utilization scenario, it defines a simple way to support optional TLV
   data in all message types.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-tlv-09

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow