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.
On Oct 15, 2015, at 6:10 AM, Benoit Claise <[email protected]> wrote:
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.
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.
----------------------------------------------------------------------
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"
Noted, thank you.
- 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.
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.
(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
Will be corrected in the next version. Thanks.
– John
.
