--- 1/draft-ietf-grow-bmp-09.txt 2015-07-20 01:15:12.577504638 -0700 +++ 2/draft-ietf-grow-bmp-10.txt 2015-07-20 01:15:12.629505884 -0700 @@ -1,21 +1,21 @@ Network Working Group J. Scudder, Ed. Internet-Draft Juniper Networks Intended status: Standards Track R. Fernando -Expires: January 5, 2016 Cisco Systems +Expires: January 21, 2016 Cisco Systems S. Stuart Google - July 4, 2015 + July 20, 2015 BGP Monitoring Protocol - draft-ietf-grow-bmp-09 + draft-ietf-grow-bmp-10 Abstract This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen- scraping approach in common use today. 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. @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 5, 2016. + This Internet-Draft will expire on January 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,21 +79,21 @@ 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 + 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 @@ -797,27 +797,26 @@ between how different implementations format path attributes. 6. Route Mirroring Route Mirroring messages are provided for two primary reasons: First, to enable an implementation to operate in a mode where it provides a full-fidelity view of all messages received from its peers, without state compression. As we note in Section 5, BMP's normal operational mode cannot provide this. Implementors are strongly cautioned that without state compression, an implementation could require unbounded - storage to buffer messages queued to be mirrored. This requirement, - its concomitant performance implications, and other possible negative - consequences such as the potential to flow-block BGP peers, slowing - routing convergence, means this mode of operation is unlikely to be - suitable for implementation in conventional routers, and its use is - NOT RECOMMENDED except in cases where implementors have carefully - considered the tradeoffs. + storage to buffer messages queued to be mirrored. Route Mirroring is + unlikely to be suitable for implementation in conventional routers, + and its use is NOT RECOMMENDED except in cases where implementors + have carefully considered the tradeoffs. These tradeoffs include: + router resource exhaustion, the potential to flow-block BGP peers, + and the slowing of routing convergence. The second application for Route Mirroring is for error reporting and diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router can process BGP messages that are determined to contain errors, without resetting the BGP session. Such messages MAY be mirrored. The buffering used for such mirroring SHOULD be limited. If an errored message is unable to be mirrored due to buffer exhaustion, a message with the "Messages Lost" code SHOULD be sent to indicate this. (This implies a buffer should be reserved for this use.) @@ -1030,70 +1028,78 @@ provide mutual authentication, data integrity and transport protection. Unless a transport that provides mutual authentication is used, an attacker could masquerade as the monitored router and trick a monitoring station into accepting false information. 12. Acknowledgements Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji - Ioannidis, Mack McBride, Danny McPherson, David Meyer, Dimitri - Papadimitriou, Robert Raszuk, Erik Romijn, and the members of the - GROW working group for their comments. + Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer, + Dimitri Papadimitriou, Robert Raszuk, Erik Romijn, and the members of + the GROW working group for their comments. 13. References 13.1. Normative References [I-D.ietf-idr-error-handling] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", draft- ietf-idr-error-handling-19 (work in progress), April 2015. [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", - STD 17, RFC 1213, March 1991. + STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, - January 2007. + DOI 10.17487/RFC4724, January 2007, + . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, - May 2008. + DOI 10.17487/RFC5226, May 2008, + . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet - Autonomous System (AS) Number Space", RFC 6793, December - 2012. + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + . 13.2. Informative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification - of management information for TCP/IP-based internets", STD - 16, RFC 1155, May 1990. + of management information for TCP/IP-based internets", + STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, + . [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual - Conventions for Additional High Capacity Data Types", RFC - 2856, June 2000. + Conventions for Additional High Capacity Data Types", + RFC 2856, DOI 10.17487/RFC2856, June 2000, + . - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - 4303, December 2005. + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, DOI 10.17487/RFC4303, December 2005, + . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP - Authentication Option", RFC 5925, June 2010. + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, . Appendix A. Changes Between BMP Versions 1 and 2 o Added Peer Up Message o Added L flag o Editorial changes Appendix B. Changes Between BMP Versions 2 and 3 o Added a 32-bit length field to the fixed header.