On 10/18/2015 10:46 PM, Rob Shakir wrote:
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?
What is required is an easy mapping, making sure that the operator has
got all the information.
1. So the minimum is: based on the set of input data that is received
from BMP - the object within the YANG model hierarchy that is being
referenced
2. Bonus points if BMP and YANG objects can be keyed the same.
3. And "félicitations du jury"
[https://en.wikipedia.org/wiki/Tr%C3%A8s_honorable_avec_f%C3%A9licitations]//if
you would have YANG directly in BMP so that no mapping is required. I
understand that change is too big at this point.
In the end, it depends how much automation you need for your use cases.
Or maybe you always expect an operator to look a BMP, for
troubleshooting. In which case, 1. is good enough.
I believe that the former is the only one that we can practically achieve - and
in that case, only for a subset of cases.
So let me ask this: if only for a subset of cases, does it imply that
we're missing some info in BMP for the other 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,
Thanks for engaging.
Regards, Benoit
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
