Jeff,
Benoit,
To add to some of Rob's observations:
On Sun, Oct 18, 2015 at 02:46:58PM -0600, Rob Shakir wrote:
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]
There is additional some matters of perspective. BMP permits the monitoring
of BGP, but there's no specific binding guaranteed in the BMP document to
what the BGP instances are. This is intended to be done via configuration.
As an example, the monitored instance may belong to the master BGP instance
in which case VPN routes may be visible and will have Route Distinguisher
semantics. However, it is just as possible to have BMP be configured within
a VRF instance and monitor things from the perspective of the PE-CE peering
session, if BGP is used as the PE-CE protocol.
It is also possible to have multiple disjoint BGP sessions on a given
device; e.g. virtual routers.
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 think it's broader than that. The perspective of BGP's RIBs models
doesn't fully align with the netmod-rtg-cfg model at this point. The
operational model for monitoring BGP RIB data in the IDR/openconfig yang
models isn't there yet, although Rob notes that there is work in progress
within openconfig on this.
My suspicion is that it may be simplest to provide a yang model toward the
management of the BMP instance. From there, the relationship to the
underlying BGP would be clearer. I don't believe that this requires
modification of the BMP protocol.
So, if I understand correctly this proposal (YANG model toward the
management of the BMP instance)
When an operator needs to troubleshoot,
1. He configures BMP for a specific BGP instance: master, VRF
2. He receives the information via BMP (which might lack the BGP
instance information)
3. He needs to combine the information from the BGP instance he
configured and the BMP info to be able to configure
draft-ietf-idr-bgp-model with YANG. (assuming that re-configuration is
required)
So practically, this imposes a manual process.
In this case, having step 1 done with YANG does not buy much for the
full automation, because step 3 would still be manual, right?
Regards, Benoit
-- Jeff
.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
