| draft-ietf-idr-bgp-extended-messages-12.txt | draft-ietf-idr-bgp-extended-messages-13.txt | |||
|---|---|---|---|---|
| Network Working Group R. Bush | Network Working Group R. Bush | |||
| Internet-Draft Internet Initiative Japan | Internet-Draft Internet Initiative Japan | |||
| Updates: 4271 (if approved) K. Patel | Updates: 4271 (if approved) K. Patel | |||
| Intended status: Standards Track D. Ward | Intended status: Standards Track D. Ward | |||
| Expires: November 22, 2016 Cisco Systems | Expires: December 24, 2016 Cisco Systems | |||
| May 21, 2016 | June 22, 2016 | |||
| Extended Message support for BGP | Extended Message support for BGP | |||
| draft-ietf-idr-bgp-extended-messages-12 | draft-ietf-idr-bgp-extended-messages-13 | |||
| Abstract | Abstract | |||
| The BGP specification mandates a maximum BGP message size of 4096 | The BGP specification mandates a maximum BGP message size of 4096 | |||
| octets. As BGP is extended to support newer AFI/SAFIs, there is a | octets. As BGP is extended to support newer AFI/SAFIs, there is a | |||
| need to extend the maximum message size beyond 4096 octets. This | need to extend the maximum message size beyond 4096 octets. This | |||
| document updates the BGP specification in RFC4271 by providing an | document updates the BGP specification by providing an extension to | |||
| extension to BGP to extend its current message size from 4096 octets | BGP to extend its current message size from 4096 octets to 65535 | |||
| to 65535 octets. | octets. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to | |||
| be interpreted as described in RFC 2119 [RFC2119] only when they | be interpreted as described in RFC 2119 [RFC2119] only when they | |||
| appear in all upper case. They may also appear in lower or mixed | appear in all upper case. They may also appear in lower or mixed | |||
| case as English words, without normative meaning. | case as English words, without normative meaning. | |||
| Status of This Memo | Status of This Memo | |||
| skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
| 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 November 22, 2016. | This Internet-Draft will expire on December 24, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 3, line 48 ¶ | skipping to change at page 3, line 48 ¶ | |||
| A BGP speaker that has the ability to use extended messages but has | A BGP speaker that has the ability to use extended messages but has | |||
| not advertised the BGP Extended Messages capability, presumably due | not advertised the BGP Extended Messages capability, presumably due | |||
| to configuration, SHOULD NOT accept an extended message. A speaker | to configuration, SHOULD NOT accept an extended message. A speaker | |||
| MAY implement a more liberal policy and accept extended messages even | MAY implement a more liberal policy and accept extended messages even | |||
| from a peer that has not advertised the capability. | from a peer that has not advertised the capability. | |||
| However, a BGP speaker that does not advertise the BGP Extended | However, a BGP speaker that does not advertise the BGP Extended | |||
| Messages capability might also genuinely not support extended | Messages capability might also genuinely not support extended | |||
| messages. Such a speaker would be expected to follow the error | messages. Such a speaker would be expected to follow the error | |||
| handling procedures of [RFC4221], Section 6.1, and reset the session | handling procedures of [RFC4271], Section 6.1, and reset the session | |||
| with a Bad Message Length NOTIFICATION if it receives an extended | with a Bad Message Length NOTIFICATION if it receives an extended | |||
| message. A speaker that treats an improper extended message as a | message. A speaker that treats an improper extended message as a | |||
| fatal error, as described in the preceding paragraph, MUST do | fatal error, as described in the preceding paragraph, MUST do | |||
| likewise. | likewise. | |||
| The inconsistency between the local and remote BGP speakers MUST be | ||||
| reported via syslog and/or SNMP. | ||||
| 6. Acknowledgements | 6. Acknowledgements | |||
| The authors thank Enke Chen, Susan Hares, John Scudder, John Levine, | The authors thank Enke Chen, Susan Hares, John Scudder, John Levine, | |||
| and Job Snijders for their input. | and Job Snijders for their input. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| The IANA is requested to register a new BGP Capability Code to be | The IANA is requested to register a new BGP Capability Code to be | |||
| named BGP Extended Message Capability and referring to this document. | named BGP Extended Message Capability and referring to this document. | |||
| skipping to change at page 4, line 28 ¶ | skipping to change at page 4, line 31 ¶ | |||
| ----- ----------------------------------- ------------- | ----- ----------------------------------- ------------- | |||
| 64 Graceful Restart Capability [RFC4724] | 64 Graceful Restart Capability [RFC4724] | |||
| .... | .... | |||
| 72 CP-ORF Capability [RFC7543] | 72 CP-ORF Capability [RFC7543] | |||
| ... | ... | |||
| TBD BGP-Extended Message [this draft] | TBD BGP-Extended Message [this draft] | |||
| 8. Security Considerations | 8. Security Considerations | |||
| This extension to BGP does not change BGP's underlying security | This extension to BGP does not change BGP's underlying security | |||
| issues. | issues. It does enable large BGPsec BGPSEC_PATHs, see | |||
| [I-D.ietf-sidr-bgpsec-protocol] | ||||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [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. | |||
| [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol | ||||
| Label Switching (MPLS) Management Overview", RFC 4221, | ||||
| November 2005. | ||||
| [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. | |||
| [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement | [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement | |||
| with BGP-4", RFC 5492, February 2009. | with BGP-4", RFC 5492, February 2009. | |||
| 9.2. Informative References | 9.2. Informative References | |||
| [I-D.ietf-sidr-bgpsec-overview] | [I-D.ietf-sidr-bgpsec-overview] | |||
| Lepinski, M. and S. Turner, "An Overview of BGPSEC", | Lepinski, M. and S. Turner, "An Overview of BGPSEC", | |||
| draft-ietf-sidr-bgpsec-overview-02 (work in progress), May | draft-ietf-sidr-bgpsec-overview-02 (work in progress), May | |||
| 2012. | 2012. | |||
| [I-D.ietf-sidr-bgpsec-protocol] | ||||
| Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- | ||||
| sidr-bgpsec-protocol-07 (work in progress), February 2013. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Randy Bush | Randy Bush | |||
| Internet Initiative Japan | Internet Initiative Japan | |||
| 5147 Crystal Springs | 5147 Crystal Springs | |||
| Bainbridge Island, Washington 98110 | Bainbridge Island, Washington 98110 | |||
| US | US | |||
| Email: randy@psg.com | Email: randy@psg.com | |||
| End of changes. 9 change blocks. | ||||
| 13 lines changed or deleted | 17 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||