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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
