Hi Benoit, John, Whilst not claiming to be a NETCONF expert, I have spent significant time with the BGP modelling work, so let me add some points.
On October 15, 2015 at 14:22:12, John G. Scudder ([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. I agree with the sentiment here. However, we need to consider how wide-ranging this discussion might end up being, and what the implications elsewhere might be. Let’s take a very simple example of the Per-Peer Header (§4.2) ‘Peer Distinguisher’. The structure that the IETF is progressing towards is that we have a VRF-centric model for protocol configuration. That is to say that we have protocols that are rooted under a routing table, rather than vice-versa. This means that to be able to identify a particular peer, we need to distinguish the routing table to which it belongs (to find the correct routing table), and subsequently the address of the peer. The latter is fine, but the former is more problematic. For example, we may have a routing instance that does not have an RD specified (this is the case where we have VRFs that are not L3VPN VRFs). [0] This would mean that we can’t key the lists in the same way - so is the ask simply that we are able to determine - based on the set of input data that is received from BMP - the object within the YANG model hierarchy that is being referenced? Or is it more wide than that, which says that BMP and YANG objects should be keyed the same? I believe that the former is the only one that we can practically achieve - and in that case, only for a subset of cases. If we can clarify the intention here, I can take a look at the mapping. From a first pass, I don’t see huge problems (other than some values in the BMP header are perhaps not relevant to BGP configuration/state in general). The model that is perhaps as relevant as the models that Benoit mentioned is a model describing the BGP RIB - which should potentially have the same means of describing NLRI etc. such that they can be referenced (UPDATE in BMP message X can be referenced to entry in BGP RIB of router R). The RIB models that OpenConfig is working on are not (yet) published in the IETF: https://github.com/openconfig/public/tree/master/release/models/rib Kind regards, r. [0]: This might raise the question of what happens when we have multiple VRFs without RDs, but overlapping addressing in the BMP spec. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
