draft-ietf-grow-bmp-09.txt   draft-ietf-grow-bmp-10.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: January 5, 2016 Cisco Systems Expires: January 21, 2016 Cisco Systems
S. Stuart S. Stuart
Google Google
July 4, 2015 July 20, 2015
BGP Monitoring Protocol BGP Monitoring Protocol
draft-ietf-grow-bmp-09 draft-ietf-grow-bmp-10
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 more convenient interface BGP sessions. BMP is intended to provide a more convenient interface
for obtaining route views for research purpose than the screen- for obtaining route views for research purpose than the screen-
scraping approach in common use today. The design goals are to keep scraping approach in common use today. The design goals are to keep
BMP simple, useful, easily implemented, and minimally service- BMP simple, useful, easily implemented, and minimally service-
affecting. BMP is not suitable for use as a routing protocol. affecting. BMP is not suitable for use as a routing protocol.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 5, 2016. This Internet-Draft will expire on January 21, 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 2, line 44 skipping to change at page 2, line 44
4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9 4.4. Information TLV . . . . . . . . . . . . . . . . . . . . . 9
4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10 4.5. Termination Message . . . . . . . . . . . . . . . . . . . 10
4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11 4.6. Route Monitoring . . . . . . . . . . . . . . . . . . . . 11
4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11 4.7. Route Mirroring . . . . . . . . . . . . . . . . . . . . . 11
4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12 4.8. Stats Reports . . . . . . . . . . . . . . . . . . . . . . 12
4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14 4.9. Peer Down Notification . . . . . . . . . . . . . . . . . 14
4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15 4.10. Peer Up Notification . . . . . . . . . . . . . . . . . . 15
5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17 5. Route Monitoring . . . . . . . . . . . . . . . . . . . . . . 17
6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18 6. Route Mirroring . . . . . . . . . . . . . . . . . . . . . . . 18
7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Stat Reports . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Other Considerations . . . . . . . . . . . . . . . . . . . . 19 8. Other Considerations . . . . . . . . . . . . . . . . . . . . 18
8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19 8.1. Multiple Instances . . . . . . . . . . . . . . . . . . . 19
8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19 8.2. Locally-Originated Routes . . . . . . . . . . . . . . . . 19
9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Using BMP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20 10.1. BMP Message Types . . . . . . . . . . . . . . . . . . . 20
10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20 10.2. BMP Statistics Types . . . . . . . . . . . . . . . . . . 20
10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21 10.3. BMP Initiation Message TLVs . . . . . . . . . . . . . . 21
10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21 10.4. BMP Termination Message TLVs . . . . . . . . . . . . . . 21
10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21 10.5. BMP Termination Message Reason Codes . . . . . . . . . . 21
10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22 10.6. BMP Peer Down Reason Codes . . . . . . . . . . . . . . . 22
skipping to change at page 18, line 19 skipping to change at page 18, line 19
between how different implementations format path attributes. between how different implementations format path attributes.
6. Route Mirroring 6. Route Mirroring
Route Mirroring messages are provided for two primary reasons: First, Route Mirroring messages are provided for two primary reasons: First,
to enable an implementation to operate in a mode where it provides a to enable an implementation to operate in a mode where it provides a
full-fidelity view of all messages received from its peers, without full-fidelity view of all messages received from its peers, without
state compression. As we note in Section 5, BMP's normal operational state compression. As we note in Section 5, BMP's normal operational
mode cannot provide this. Implementors are strongly cautioned that mode cannot provide this. Implementors are strongly cautioned that
without state compression, an implementation could require unbounded without state compression, an implementation could require unbounded
storage to buffer messages queued to be mirrored. This requirement, storage to buffer messages queued to be mirrored. Route Mirroring is
its concomitant performance implications, and other possible negative unlikely to be suitable for implementation in conventional routers,
consequences such as the potential to flow-block BGP peers, slowing and its use is NOT RECOMMENDED except in cases where implementors
routing convergence, means this mode of operation is unlikely to be have carefully considered the tradeoffs. These tradeoffs include:
suitable for implementation in conventional routers, and its use is router resource exhaustion, the potential to flow-block BGP peers,
NOT RECOMMENDED except in cases where implementors have carefully and the slowing of routing convergence.
considered the tradeoffs.
The second application for Route Mirroring is for error reporting and The second application for Route Mirroring is for error reporting and
diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router diagnosis. When [I-D.ietf-idr-error-handling] is in use, a router
can process BGP messages that are determined to contain errors, can process BGP messages that are determined to contain errors,
without resetting the BGP session. Such messages MAY be mirrored. without resetting the BGP session. Such messages MAY be mirrored.
The buffering used for such mirroring SHOULD be limited. If an The buffering used for such mirroring SHOULD be limited. If an
errored message is unable to be mirrored due to buffer exhaustion, a errored message is unable to be mirrored due to buffer exhaustion, a
message with the "Messages Lost" code SHOULD be sent to indicate message with the "Messages Lost" code SHOULD be sent to indicate
this. (This implies a buffer should be reserved for this use.) this. (This implies a buffer should be reserved for this use.)
skipping to change at page 23, line 20 skipping to change at page 23, line 20
provide mutual authentication, data integrity and transport provide mutual authentication, data integrity and transport
protection. protection.
Unless a transport that provides mutual authentication is used, an Unless a transport that provides mutual authentication is used, an
attacker could masquerade as the monitored router and trick a attacker could masquerade as the monitored router and trick a
monitoring station into accepting false information. monitoring station into accepting false information.
12. Acknowledgements 12. Acknowledgements
Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji Thanks to Michael Axelrod, Tim Evens, Pierre Francois, John ji
Ioannidis, Mack McBride, Danny McPherson, David Meyer, Dimitri Ioannidis, John Kemp, Mack McBride, Danny McPherson, David Meyer,
Papadimitriou, Robert Raszuk, Erik Romijn, and the members of the Dimitri Papadimitriou, Robert Raszuk, Erik Romijn, and the members of
GROW working group for their comments. 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.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets:MIB-II", 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,
<http://www.rfc-editor.org/info/rfc1213>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007. DOI 10.17487/RFC4724, January 2007,
<http://www.rfc-editor.org/info/rfc4724>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793,
2012. DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>.
13.2. Informative References 13.2. Informative References
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets", STD of management information for TCP/IP-based internets",
16, RFC 1155, May 1990. STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990,
<http://www.rfc-editor.org/info/rfc1155>.
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual [RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual
Conventions for Additional High Capacity Data Types", RFC Conventions for Additional High Capacity Data Types",
2856, June 2000. RFC 2856, DOI 10.17487/RFC2856, June 2000,
<http://www.rfc-editor.org/info/rfc2856>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
4303, December 2005. RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [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, <http://www.rfc-editor.org/info/rfc5925>.
Appendix A. Changes Between BMP Versions 1 and 2 Appendix A. Changes Between BMP Versions 1 and 2
o Added Peer Up Message o Added Peer Up Message
o Added L flag o Added L flag
o Editorial changes o Editorial changes
Appendix B. Changes Between BMP Versions 2 and 3 Appendix B. Changes Between BMP Versions 2 and 3
o Added a 32-bit length field to the fixed header. o Added a 32-bit length field to the fixed header.
 End of changes. 15 change blocks. 
28 lines changed or deleted 35 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/