| draft-ietf-grow-bmp-14.txt | draft-ietf-grow-bmp-15.txt | |||
|---|---|---|---|---|
| Network Working Group J. Scudder, Ed. | Network Working Group J. Scudder, Ed. | |||
| Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
| Intended status: Standards Track R. Fernando | Intended status: Standards Track R. Fernando | |||
| Expires: February 8, 2016 Cisco Systems | Expires: February 12, 2016 Cisco Systems | |||
| S. Stuart | S. Stuart | |||
| August 7, 2015 | August 11, 2015 | |||
| BGP Monitoring Protocol | BGP Monitoring Protocol | |||
| draft-ietf-grow-bmp-14 | draft-ietf-grow-bmp-15 | |||
| Abstract | Abstract | |||
| This document defines a protocol, BMP, that can be used to monitor | This document defines a protocol, BMP, that can be used to monitor | |||
| BGP sessions. BMP is intended to provide a convenient interface for | BGP sessions. BMP is intended to provide a convenient interface for | |||
| obtaining route views. Prior to introduction of BMP, screen-scraping | obtaining route views. Prior to introduction of BMP, screen-scraping | |||
| was the most commonly-used approach to obtaining such views. The | was the most commonly-used approach to obtaining such views. The | |||
| design goals are to keep BMP simple, useful, easily implemented, and | design goals are to keep BMP simple, useful, easily implemented, and | |||
| minimally service-affecting. BMP is not suitable for use as a | minimally service-affecting. BMP is not suitable for use as a | |||
| routing protocol. | routing protocol. | |||
| skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on February 8, 2016. | This Internet-Draft will expire on February 12, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 19, line 10 | skipping to change at page 19, line 10 | |||
| the authors envision this list may grow in the future with new | the authors envision this list may grow in the future with new | |||
| applications that require BMP-style monitoring. | applications that require BMP-style monitoring. | |||
| 8. Other Considerations | 8. Other Considerations | |||
| 8.1. Multiple Instances | 8.1. Multiple Instances | |||
| Some routers may support multiple instances of the BGP protocol, for | Some routers may support multiple instances of the BGP protocol, for | |||
| example as "logical routers" or through some other facility. The BMP | example as "logical routers" or through some other facility. The BMP | |||
| protocol relates to a single instance of BGP; thus, if a router | protocol relates to a single instance of BGP; thus, if a router | |||
| supports multiple BGP instances it should also support multiple BMP | supports multiple BGP instances it should also support multiple BMP | |||
| instances (one per BGP instance). | instances (one per BGP instance). Different BMP instances SHOULD | |||
| generate Initiation Messages that are distinct from one another, for | ||||
| example by using distinguishable sysNames or by inclusion of | ||||
| instance-identifying information in a string TLV. | ||||
| 8.2. Locally-Originated Routes | 8.2. Locally-Originated Routes | |||
| Some consideration is required for routes originated into BGP by the | Some consideration is required for routes originated into BGP by the | |||
| local router, whether as a result of redistribution from a another | local router, whether as a result of redistribution from a another | |||
| protocol or for some other reason. | protocol or for some other reason. | |||
| Such routes can be modeled as having been sent by the router to | Such routes can be modeled as having been sent by the router to | |||
| itself, placing the router's own address in the Peer Address field of | itself, placing the router's own address in the Peer Address field of | |||
| the header. It is RECOMMENDED that when doing so the router should | the header. It is RECOMMENDED that when doing so the router should | |||
| skipping to change at page 23, line 40 | skipping to change at page 23, line 40 | |||
| Where the security considerations outlined above are a concern, users | Where the security considerations outlined above are a concern, users | |||
| of this protocol should consider using some type of transport that | of this protocol should consider using some type of transport that | |||
| provides mutual authentication, data integrity and transport | provides mutual authentication, data integrity and transport | |||
| protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If | protection, such as IPsec [RFC4303] or TCP-AO [RFC5925]. If | |||
| confidentiality is considered a concern, a transport providing that | confidentiality is considered a concern, a transport providing that | |||
| as well could be selected. | as well could be selected. | |||
| 12. Acknowledgements | 12. Acknowledgements | |||
| Thanks to Ebben Aries, Michael Axelrod, Tim Evens, Pierre Francois, | Thanks to Ebben Aries, Michael Axelrod, Serpil Bayraktar, Tim Evens, | |||
| Jeffrey Haas, John ji Ioannidis, John Kemp, Mack McBride, Danny | Pierre Francois, Jeffrey Haas, John ji Ioannidis, John Kemp, Mack | |||
| McPherson, David Meyer, Dimitri Papadimitriou, Tom Petch, Robert | McBride, Danny McPherson, David Meyer, Dimitri Papadimitriou, Tom | |||
| Raszuk, Erik Romijn, and the members of the GROW working group for | Petch, Robert Raszuk, Erik Romijn, Peter Schoenmaker and the members | |||
| their comments. | of the GROW working group for their comments. | |||
| 13. References | 13. References | |||
| 13.1. Normative References | 13.1. Normative References | |||
| [I-D.ietf-idr-error-handling] | [I-D.ietf-idr-error-handling] | |||
| Chen, E., Scudder, J., Mohapatra, P., and K. Patel, | Chen, E., Scudder, J., Mohapatra, P., and K. Patel, | |||
| "Revised Error Handling for BGP UPDATE Messages", draft- | "Revised Error Handling for BGP UPDATE Messages", draft- | |||
| ietf-idr-error-handling-19 (work in progress), April 2015. | ietf-idr-error-handling-19 (work in progress), April 2015. | |||
| End of changes. 6 change blocks. | ||||
| 10 lines changed or deleted | 13 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||