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