Subject: [GROW] Benoit Claise's Discuss on draft-ietf-grow-bmp-15: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 15 Oct 2015 03:10:26 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-grow-bmp-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

Below is Mahesh's OPS DIR review:

Summary:
This document defines a protocol, BMP, that can be used to monitor BGP
sessions.  BMP is intended to provide a convenient interface for
obtaining route views.  Prior to introduction of BMP, screen-scraping was
the most commonly-used approach to obtaining such views.  The design
goals are to keep BMP simple, useful, easily implemented, and minimally
service-affecting.  BMP is not suitable for use as a routing protocol.

The document is on standards track and defines another monitoring method
specifically for BGP. The original draft is dated 2005, long before
NETCONF or YANG were defined, and when there was probably no way to view
routes. With the advent of NETCONF and specifically the BGP YANG model,
which is currently a WG document, it would be helpful to know how BMP
stands apart. The NETCONF notification structure allows for notifications
described in this draft and the ability to collect stats reports and
route monitoring. It would be helpful to know how BMP compliments that
capability.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

COMMENT:
- From the write-up:

-- The BMP protocol has been a GROW document for quite sometime.  The
-- length of time has allowed the document to have multiple
implementations
-- completed, along with incorporating working group feedback into the
spec
-- and polishing the document. 

Btw, don't forget, for future documents, the experimental RFC 6982
"Improving Awareness of Running Code: The Implementation Status Section"

-  following nits need to be addressed in the document.

Miscellaneous warnings:
 
----------------------------------------------------------------------------

  == The document seems to contain a disclaimer for pre-RFC5378 work, but
was
     first submitted on or after 10 November 2008.  The disclaimer is
usually
     necessary only for documents that revise or obsolete older RFCs, and
that
     take significant amounts of text from those RFCs.  If you can
contact all
     authors of the source material and they are willing to grant the
BCP78
     rights to the IETF Trust, you can and should remove the disclaimer.

     Otherwise, the disclaimer is needed and you can ignore this comment.

     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.)

  Checking references for intended status: Proposed Standard
 
----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  == Outdated reference: draft-ietf-idr-error-handling has been published
as
     RFC 7606

---

From: Benoit Claise <[email-masked]>
Date: Thu, 15 Oct 2015 12:13:53 +0200

Typo in one email address. Corrected now.

Regards, Benoit
> .

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 15 Oct 2015 16:21:23 -0400

Hi Benoit,

Thanks for your comments. I'll follow up on your discuss by and by, likely it will be most convenient to huddle with the other authors in Yokohama. Other comments in-line below.

> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/

I don't have the expertise with NETCONF to provide an accurate comparison between the two. Perhaps someone else on the cc can chime in.

Noted, thank you.

> -  following nits need to be addressed in the document.

I've taken notice of the nit and elected to ignore the comment. Note that idnits is mistaken about the first submission date, apparently it doesn't follow the replaced-by chain back to the individual submission, which dates to 2005 as you observe above.

>  Checking references for intended status: Proposed Standard

Will be corrected in the next version. Thanks.

– John

---

From: Benoit Claise <[email-masked]>
Date: Fri, 16 Oct 2015 08:56:01 +0200

Thanks John,

Regards, Benoit

---

From: Rob Shakir <[email-masked]>
Date: Sun, 18 Oct 2015 14:46:58 -0600

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.

> > 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.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 18 Oct 2015 14:02:35 -0700

> Hi Benoit, John,

<snip>

> 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]

the scenario you describe inclusive of overlapping prefixes describes
a number of deployments.

> 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.
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Oct 2015 15:48:55 -0400

Benoit,

To add to some of Rob's observations:

> 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, rathe…

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 Y…

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.

-- Jeff

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Oct 2015 12:18:21 +0200

> 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 Y…
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?

> 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…
Thanks for engaging.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Oct 2015 12:30:16 +0200

Jeff,
> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Oct 2015 10:35:43 -0400

Benoit,

On Fri, Oct 23, 2015 at 12:30:16PM +0200, Benoit Claise wrote:
> draft-ietf-idr-bgp-model with YANG. (assuming that re-configuration
> is required)
> 

I think there may be a slight disconnect as to what I think your perception
is of BMP's use cases vs. what it is used for.

BMP is largely used for route monitoring, along with some amount of counter
transmission.  In most cases, BMP is pre-provisioned and left running rather
than dynamically provisioned.

The missing bit of correlation is what a given BMP session is monitoring.
There is no requirement, for example, that the same IP address is used for
the BMP session and the IP loopback address used by a BGP routing instance.
That's a common deployment case, but it's not required.  Also, arguably the
BMP session could be bound to an IP address that is on a management network
that is dijoint from the typical routing-plane.

Practically speaking, the BMP protocol provides the majority of correlating
data to BGP session as part of its messages:
- IP addresses of the sessions and their AS numbers.  However, those
  addresses may not be unique in the network.
- Peer's BGP Open message.

This second detail is what tends to provide stronger correlation, since it
includes the BGP Identifier (router-id) of the session.  For proper
operation of BGP in a network, it is necessary to have router-ids unique
across all systems and technically all adjacent systems that may be outside
of your AS.  If you don't, it's not catastrophic but can cause odd
behaviors.

To tie this all back together, BMP yang state can be correlated to BGP
operational state.  Where it isn't, the message contents can be.
In the absence of BGP yang operational state, you could get the same from
SNMP or even simply your network provisioning information.

-- Jeff

---

From: Rob Shakir <[email-masked]>
Date: Fri, 23 Oct 2015 08:41:51 -0600

Jeff,

+1 on this, I think you’re right.

> operational state.  Where it isn't, the message contents can be.

Agreed, given that BMP will simply transmit the PDU, the only requirement this raises for a YANG BGP RIB model (such that the two can be correlated) is to use the same encoding that is used in existing messages for attributes of a BGP message.

I’m not aware of any modelling work that does not meet this requirement.

r.

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 25 Oct 2015 11:17:41 -0400

On Sat, Oct 24, 2015 at 09:48:20PM -0700, Mahesh Jethanandani wrote:
> I understand that the operational model for monitoring BGP RIB data is not
> quite there in either the IDR or the openconfig YANG model. But if we
> agree that there could be a single YANG BGP RIB model, then is it possible
> that information carried by BMP could be transmitted say as part of a
> NETCONF/RESTCONF notification? Or is there something specific about the
> information that is being transmitted or how it is being transmitted that
> is BMP specific?

The more fundamental issue between any of the BGP related components is that
they are simply *routes*.  Arguably, they should be covered by the routing
cfg module in netmod with appropriate augmentations for BGP.

But that's the routes.  There is other session operational state for the
protocol that should be covered in the individual yang protocol modules.

BMP is also arguably a lot lazier about what is coming down the wire in
terms of specification.  It is best to read the spec as if it has a "please
see all relevant BGP standards for further informatino."

-- Jeff

---

From: Rob Shakir <[email-masked]>
Date: Sun, 25 Oct 2015 18:49:27 -0600

> On Oct 24, 2015, at 22:48, Mahesh Jethanandani <[email-masked]> wrote:
> 
> 
>>> On Oct 23, 2015, at 7:41 AM, Rob Shakir <[email-masked]> wrote:
>>> 
> I had a slightly different question, and comes from my lack of complete understanding of BMP.
> 
> I understand that the operational model for monitoring BGP RIB data is not quite there in either the IDR or the openconfig YANG model. But if we agree that there could be a single YANG BGP RIB model, then is it possible that information carried by BMP could be transmitted say as part of a NETCONF/RESTCONF notification? Or is there something specific about the information that is being transmitted or how it is being transmitted that is BMP specific?

Yes and no. As Jeff indicated BMP is a lot more raw than having entirely parsed the contents of a message. 

Also, BMP is implemented and running today. We need to give operators tools that are useful now - and nailing down the BMP spec is one of the ways we do that. If it is replaced at a later date by some new streamed update relating to the RIB model is something that future implementors and users will decide. 

Cheers,
r. 

> Mahesh Jethanandani
> [email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 19 Oct 2015 20:07:20 -0700

> On Oct 19, 2015, at 12:48 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> underlying BGP would be clearer. 

+1

I would add that the YANG model in https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00 <https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00> should also align with the notifications BMP supports. With its support for routing instance and if/when the BGP RIB data model becomes available, the operators can decide if they want to use BMP or NETCONF/RESTCONF (or any protocol that supports YANG) notifications to receive the updates. 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 24 Oct 2015 21:48:20 -0700

Mahesh Jethanandani
[email-masked]