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
Google Google
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/