Benoit (and all), > On Oct 15, 2015, at 7:10 PM, Benoit Claise <[email protected]> wrote: > > This DISCUSS is in line with Mahesh's OPS DIR review. > If BMP (which I consider like a span port feature btw) troubleshooting > shows that the BGP configuration is required, then the standard way to > configure BGP will be > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. > I'm wondering about the link between BMP and the following > draft-ietf-idr-bgp-model-00.txt YANG models: > > bgp-types.yang > bgp-policy.yang > bgp-multiprotocol.yang > bgp.yang > bgp-operational.yang > > Specifically: are we able to map the Per-Peer Header (section 4.2) and > Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either > because the field information come from the same reference (ex: both this > draft and the idr one have the same reference for the Peer > Distinguisher), or because specific references to the YANG key > information is provided. > I believe that the draft-ietf-grow-bmp and draft-ietf-idr-bgp-model > authors should sit down and go through the exercise of mapping the BMP > data model into the YANG data model, for a couple of troubleshooting > scenarios. The OPS world suffers from too many different data models > (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to make sure that we > won't fall into the trap of defining a new one without at least providing > the necessary mappings. Note: I see that sysName and sysDescr make the > link with the MIB world, that's a step in the right direction.
Although not every one of your questions above were explicitly answered by Rob and Jeff in the subsequent mail thread, on reviewing that thread I'm hopeful that their comments may have been sufficiently informative to allow you to clear the discuss. Can you indicate if this is so, and if not, what the major outstanding issues are? (Your answer might be "please just answer the above list of questions" but obviously I'm hoping not.) Below I paraphrase a few of Rob and Jeff's comments (which I agree with): 1. BMP's primary use-case is not a surgical troubleshooting tool, it's an ongoing statistics gathering tool. 2. It would be ill-advised to reopen the encodings in an attempt to harmonize them with a (TBD) RIB model, although it's not impossible the latter might someday replace the former. 2.a. The BMP encodings are fundamentally a very thin wrapper around naked BGP binary messages. 3. The schemas by which BMP (to the extent BMP can even be said to have a schema) and the BGP YANG model are keyed are pretty different. BMP is effectively peer-centric (though really, session-centric, as Jeff noted). The YANG model is rooted at a routing table. If you consider point 2.a. above and the fact that MP-BGP multiplexes different routing tables onto the same session, this mismatch is probably inescapable. 3.a. However, as Rob notes, it should frequently be possible, given BMP data, to identify the relevant YANG object. Jeff adds two points. The first is that the delta ought to be addressable by providing a YANG model toward management of the BMP instance -- since the ambiguity Rob identified related to disambiguation when multiple sessions have the same IP address, router ID, etc, due to being in different VRFs. The second is that this issue may be largely notional if BGP Identifiers have been chosen sanely. By the way, to reply to Rob's question, On Oct 19, 2015, at 5:46 AM, Rob Shakir <[email protected]> wrote: > [0]: This might raise the question of what happens when we have multiple VRFs > without RDs, but overlapping addressing in the BMP spec. I think for practical purposes this can currently be addressed by running a separate BMP session that binds to the "VRF" in question, quoted because I think an L3VPN VRF always would have an RD so the issue would not arise. (See also Jeff's comment about virtual routers.) If we wanted to address this some nicer way, we could add a new Peer Type whose Peer Distinguisher is an arbitrary integer. See also my reply to Alia. Thanks, --John _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
