| draft-ietf-idr-bgp-extended-messages-00.txt | draft-ietf-idr-bgp-extended-messages-01.txt | |||
|---|---|---|---|---|
| Network Working Group K. Patel | Network Working Group K. Patel | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Standards Track D. Ward | Intended status: Standards Track D. Ward | |||
| Expires: December 8, 2011 Juniper Networks | Expires: December 30, 2011 Juniper Networks | |||
| R. Bush | R. Bush | |||
| Internet Initiative Japan | Internet Initiative Japan | |||
| June 6, 2011 | June 28, 2011 | |||
| Extended Message support for BGP | Extended Message support for BGP | |||
| draft-ietf-idr-bgp-extended-messages-00 | draft-ietf-idr-bgp-extended-messages-01 | |||
| Abstract | Abstract | |||
| The current BGP specification mandates a maximum BGP message size of | The BGP specification mandates a maximum BGP message size of 4096 | |||
| 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is | octets. As BGP is extended to support newer AFI/SAFIs, there is a | |||
| a need to extend the maximum message size beyond 4096 octets. This | need to extend the maximum message size beyond 4096 octets. This | |||
| draft provides an extension for BGP to extend its current message | draft provides an extension to BGP to extend its current message size | |||
| size for BGP messages from 4096 octets to 65535 octets. | from 4096 octets to 65535 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" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 43 | skipping to change at page 1, line 43 | |||
| 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 December 8, 2011. | This Internet-Draft will expire on December 30, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 7 | skipping to change at page 3, line 7 | |||
| 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 | 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 4 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . . 4 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 4 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 1. Introduction | 1. Introduction | |||
| The current BGP specification [RFC4271] mandates a maximum BGP | The BGP specification [RFC4271] mandates a maximum BGP message size | |||
| message size of 4096 octets. As BGP is extended to support newer | of 4096 octets. As BGP is extended to support newer AFI/SAFIs and | |||
| AFI/SAFIs and newer capabilities (e.g., | newer capabilities (e.g., [I-D.ietf-sidr-bgpsec-overview]), there is | |||
| [I-D.lepinski-bgpsec-overview], there is a need to extend the maximum | a need to extend the maximum message size beyond 4096 octets. This | |||
| message size beyond 4096 octets. This draft provides an extension | draft provides an extension to BGP to extend its current message size | |||
| for BGP to extend its current message size for BGP messages from 4096 | from 4096 octets to 65535 octets. | |||
| octets to 65535 octets. | ||||
| 2. Extended message Capability for BGP | 2. Extended message Capability for BGP | |||
| To advertise BGP Extended Message Capability to a peer, a BGP speaker | To advertise BGP Extended Message Capability to a peer, a BGP speaker | |||
| uses BGP Capabilities Advertisement [RFC3392]. By advertising the | uses BGP Capabilities Advertisement [RFC5492]. By advertising the | |||
| BGP Extended Message Capability to a peer, a BGP speaker conveys that | BGP Extended Message Capability to a peer, a BGP speaker conveys that | |||
| either peer MAY send, and both peers MUST be able to receive and | it is able to send, receive, and properly handle BGP Extended | |||
| properly handle, BGP Extended Messages. | Messages. | |||
| The BGP Extended Message Capability is a new BGP Capability [RFC3392] | A peer which does not advertise this capability MUST NOT send BGP | |||
| Extended Messages, and BGP Extended Messages MUST NOT be sent to it. | ||||
| The BGP Extended Message Capability is a new BGP Capability [RFC5492] | ||||
| defined with Capability code TBD and Capability length 0. | defined with Capability code TBD and Capability length 0. | |||
| 3. Operation | 3. Operation | |||
| A BGP speaker that is willing to send and receive BGP Extended | A BGP speaker that is willing to send and receive BGP Extended | |||
| Messages from its peer should advertise the BGP Extended Message | Messages from its peer should advertise the BGP Extended Message | |||
| Capability to its peer using BGP Capabilities Advertisement | Capability to its peer using BGP Capabilities Advertisement | |||
| [RFC3392]. A BGP speaker may send extended messages to its peer only | [RFC5492]. A BGP speaker may send extended messages to its peer only | |||
| if it has received the Extended Message Capability from its peer. | if it has received the Extended Message Capability from its peer. | |||
| All BGP extended messages have maximum message size of 65535 octets. | All BGP extended messages have maximum message size of 65535 octets. | |||
| The smallest message that may be sent consists of a BGP header | The smallest message that may be sent consists of a BGP header | |||
| without a data portion (19 octets). All multi-octet fields are in | without a data portion (19 octets). All multi-octet fields are in | |||
| network byte order. | network byte order. | |||
| Applications generating messages which might be encapsulated within | Applications generating messages which might be encapsulated within | |||
| BGP messages MUST limit the size of their payload to take into | BGP messages MUST limit the size of their payload to take into | |||
| account the maximum message size and all encapsulation overheads on | account the maximum message size and all encapsulation overheads on | |||
| the path the encapsulated data are expected to traverse. | the path the encapsulated data are expected to traverse. | |||
| 4. Acknowledgements | 4. Acknowledgements | |||
| The authors thank John Scudder for his input. | The authors thank John Scudder and John Levine for their input. | |||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document defines the Extended Message Capability for BGP. The | The IANA is requested to register a new BGP Capability Code in the | |||
| new Capability code needs to be assigned by IANA. | upper range named BGP Extended Message Capability referring to this | |||
| document. | ||||
| 6. Security Considerations | 6. 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. | |||
| 7. References | 7. References | |||
| 7.1. Normative References | 7.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. | |||
| [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement | ||||
| with BGP-4", RFC 3392, November 2002. | ||||
| [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 | ||||
| with BGP-4", RFC 5492, February 2009. | ||||
| 7.2. Informative References | 7.2. Informative References | |||
| [I-D.lepinski-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-lepinski-bgpsec-overview-00 (work in progress), | draft-ietf-sidr-bgpsec-overview-00 (work in progress), | |||
| March 2011. | June 2011. | |||
| Authors' Addresses | Authors' Addresses | |||
| Keyur Patel | Keyur Patel | |||
| Cisco Systems | Cisco Systems | |||
| 170 W. Tasman Drive | 170 W. Tasman Drive | |||
| San Jose, CA 95134 | San Jose, CA 95134 | |||
| USA | USA | |||
| Email: keyupate@cisco.com | Email: keyupate@cisco.com | |||
| End of changes. 16 change blocks. | ||||
| 30 lines changed or deleted | 33 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||