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

[Zhuangshunwan <[e-mail]>]

Greetings,

First of all, thank the BMP Hackathon team for doing a great job!

Regarding BMP Peer Up message (Further, we should include the BMP Peer Down message), the key point is how to handle the enable / disable monitoring of per Peer per afi/safi granularity.

For example, if there is a bgp peer session A, where the IPv4 unicast address family is successfully negotiated(IPv4 unicast address family Received & Sent).
Now we have 4 monitor options:

1)       pre-policy Adj-RIB-In

2)       post-policy Adj-RIB-In

3)       pre-Policy Adj-RIB-Out

4)       post-policy Adj-RIB-Out

Now the question comes:

1)       If we send only one BMP Peer Up message to BMP Sever, how to signal which monitor options are selected?

2)       When multiple options have been selected (The BMP server can infer it from the subsequently received BMP RM message), if we disable part of the monitoring options(e.g. disable post-policy Adj-RIB-Out from the 4 selected options), how to signal to the BMP Server that the monitored device will no longer send post-policy Adj-RIB-Out RM messages ?

Any suggestions are welcome.

Thanks,
Shunwan

From: GROW [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Sunday, November 17, 2019 7:39 PM
To: [e-mail]
Cc: [e-mail]; Christian Kuster <[e-mail]>; [e-mail]
Subject: [GROW] 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