Re: [GROW] BMP @ IETF 106 Hackathon, GROW WG Feedback

[<[e-mail]>]

Dear GROW WG,

Thank you very much for the provided feedback.

Regarding BGP next-hop attribute of local originated routes when exposed with draft-ietf-grow-bmp-local-rib. We understood that it differs among vendor implementation. Therefore we decided to add an informational paragraph in draft-ietf-grow-bmp-local-rib to describe that behavior so it's not perceived as being wrongly implemented.

Regarding peer_up message type vendor implementations when multiple BMP RIB's are configured. We have observed that there are two different peer_up message type vendor implementations.


  *   For each RIB having one peer_up message
  *   For all RIB's together one peer_up message containing a nonstandard extension describing the AFI/SAFI covered

It seems that IETF specifications are either not precise enough or one of the two types of implementations is not according to RFC.

Please feedback to the mailing list if for each RIB having one peer_up message is intendent and according to RFC 8671 or not. Further we like to know if it makes sense to combine these peer_up's into one new peer_up message type definition and you would support such a draft.

Hackathon Reference: https://github.com/IETF-Hackathon/ietf106-project-presentations/blob/master/IETF106-hackathon-BMP.pdf

Best Wishes
Thomas Graf

From: Graf Thomas, INI-ONE-WSN-DCF
Sent: Sunday, November 17, 2019 12:39 PM
To: [e-mail]
Cc: Guyunan (Yunan Gu, IP Technology Research Dept. NW) <[e-mail]>; Camilo Cardona <[e-mail]>; Paolo Lucente <[e-mail]>; Arnold Matthias, SCS-NIT-NIO-NTO-COY-EDG <[e-mail]>; Christian Kuster <[e-mail]>
Subject: BMP @ IETF 106 Hackathon, GROW WG Feedback

Dear GROW WG,

We tested interoperability between router and data-collection for the following BMP drafts and RFC's at the past two days at the IETF 106 hackathon.


  *   draft-ietf-grow-bmp-local-rib (BGP Local RIB)
  *   RFC 8671 (BGP Adj-RIB Out)

Attached you will find a slide deck describing


  *   what we did
  *   our findings and discovery of missing gaps
  *   and next steps for hackathon 107

We would like to collect some feedback from the GROW working group regarding the following two questions:


  *   We noticed that depending on vendor implementation of draft-ietf-grow-bmp-local-rib, BGP next-hop attribute value of local originated routes are exposed differently (127.0.0.1 vs. 0.0.0.0). We noticed that RFC 4271 does specify how BGP next-hop attribute is defined when propagated to neighbors, but does not specify what the next-hop attribute value should be when route is locally originated and still is in BGP local RIB installed, before it is propagated to any peer. We would like to collect best common practice among vendors and would like to understand if you would support that we describe this common practice in draft-ietf-grow-bmp-local-rib or not.
  *   We noticed that BMP peer up message type implementation of RFC 8671 differs among vendors. Depending on vendors, the BMP collector either receives one or 4 peer up peer up messages (with different O and L bit set in peer header) if BMP Adj-RIB Out and/or post policy is configured. We would like to understand which vendor implemented/understood what; which approach makes sense the most and why. If there are reasons why one of the two possibilities could causing issues/drawbacks, we would like to understand the reasons.


And last but not least if you are interested to participate in the next BMP hackathon at IETF 107 in Vancouver please let us know. The bigger and diverse the group is, the better. We like to validate and test BMP implementations, feedback and contribute input to the GROW working group for a better BMP standardization. Thanks a lot for your support.

Best Wishes
Thomas Graf