Network Working Group Gargi Nalawade Internet Draft Himanshu Shah Expires: February 2004 Cisco Systems BGPv4 Update-v2 Message draft-nalawade-bgp-update-v2-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a new BGP message type, the BGP UPDATE-v2 message that organizes the attribute encodings and the NLRI sections in a better manner. This is especially useful in light of the many new AFI/SAFIs that have been proposed in the recent years and the reliability and robustness of the BGP Protocol. 1. Introduction The current version of the BGP UPDATE Message has evolved from its original definition for IPv4 Unicast AFI/SAFI. The use of new AFI/SAFIs in BGP has caused the MP_REACH and MP_UNREACH attributes to draft-nalawade-bgp-update-v2-00.txt [Page 1] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 be defined. But the attributes such as NEXTHOP still continued to apply only to IPv4 Unicast. It is only defined to carry an IPv4 address. This has forced several workarounds over the years such as carrying the Nexthop corresponding to the AFI/SAFI inside the MP_REACH/MP_UNREACH attribute. Carrying non-IPv4 NLRIs in the MP_REACH/MP_UNREACH attribute itself is a workaround to the fact that the NLRI section only applies to IPv4 Unicast routes. Also, the current BGP UPDATE Message starts out as being generic such that it could apply to any AFI/SAFI - until an MP_REACH/MP_UNREACH section is encountered. Only then can it be decided whether to use the NEXTHOP attribute or the NEXTHOP encoded in the MP_REACH attribute as the applicable NEXTHOP. The MP_REACH/MP_UNREACH attribute needs to be successfully parsed to identify the AFI/SAFI to which the UPDATE Message applies. Thus, if there is an error in the section preceding the MP_REACH attribute, the whole BGP session and other AFI/SAFIs running on the same saession are impacted. This does not protect one AFI/SAFI from being impacted by the other AFI/SAFIs on the same session - in case of AFI/SAFI specific errors that make it impossible to parse the MP_REACH/ MP_UNREACH section. The proposed BGP UPDATE-v2 message proposes solving all of the above-mentioned problems. BGP UPDATE-v2 will enable separation of updates belonging to different AFI/SAFI and an error in attribute can be isolated to a particular AFI/SAFI. 2. Definition of the BGP UPDATE-v2 Message The BGP UPDATE-v2 message is a BGP message with type TBD. In addition to the fixed-size BGP header, the UPDATE-v2 message contains the following fields: +-----------------------------------------------------+ | AFI (2 octets) | +-----------------------------------------------------+ | SAFI (2 octets) | +-----------------------------------------------------+ | Reserved (2 octets) | +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | draft-nalawade-bgp-update-v2-00.txt [Page 2] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+ | Total Path Attribute Length (2 octets) | +-----------------------------------------------------+ | Path Attributes (variable) | +-----------------------------------------------------+ | Network Layer Reachability Information (variable) | +-----------------------------------------------------+ where : AFI : as defined in [IANA-AFI] [IANA-SAFI] SAFI : a 2-octet long field, where the second of the 2 octets, contains the SAFI as defined in [IANA-AFI] [IANA-SAFI] Withdrawn Routes Length : as defined in [BGP-4] Withdrawn Routes : would contain NLRIS that need to be withdrawn and which belong to the AFI/SAFI as specified in the AFI/SAFI field in the message. Total Path Attribute Length : as defined in [BGP-4] Path Attributes : as defined in [BGP-4] except for the attributes NEXTHOP, MP_REACH, MP_UNREACH Network Layer Reachability Information : would contain NLRI information for the AFI/SAFI as specified in the Update-v2 Message 2.1. BGP Attributes The BGP Attributes used by UPDATE-v2 remain the same as the BGP UPDATE Message, with the following exceptions : THE MP_REACH and MP_UNREACH Attributes will get deprecated. The NEXTHOP attribute will have the format as defined by [BGP-MP- NHOP]. 3. Operation draft-nalawade-bgp-update-v2-00.txt [Page 3] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 The Operation remains the same as the Update Message as defined in [BGP-4] If a BGP speaker that has successfully negotiated a Capability for exchanging UPDATE-v2 for an AFI/SAFI and receives an Update Message for that AFI/SAFI it MUST signal an error condition to that peer. For peers that support [BGP-SOFT], a BGPv4 Soft-Notification Message should be sent back to the peer with a Error Code Update and sub-code Invalid Message Type. For peers that dont support [BGP-SOFT] the BGP SPeaker may reset the session with the peer with Error Code Update Message Error and a new Error Sub-code Invalid Message Type. 4. Capability A new capability [BGP-CAP] code (TBD) is defined for the BGP UPDATE- v2 messages. A BGP UPDATE-v2 message can only be sent to peers that have advertised this capability. The Capability will have the following format : +-----------------------------------------------------+ | NLRI AFI (2 octets) | +-----------------------------------------------------+ | NLRI SAFI (2 octets) | +-----------------------------------------------------+ | Reserved Field (2 octets) | +-----------------------------------------------------+ | Nexthop AFI - 1 (2 octets) | +-----------------------------------------------------+ | Nexthop SAFI - 1 (2 octets) | +-----------------------------------------------------+ | ..... | +-----------------------------------------------------+ | Nexthop AFI - n (2 octets) | +-----------------------------------------------------+ | Nexthop SAFI - n (2 octets) | +-----------------------------------------------------+ | | | ..... | +-----------------------------------------------------+ | NLRI AFI (2 octets) | +-----------------------------------------------------+ | NLRI SAFI (2 octet) | +-----------------------------------------------------+ | Reserved Field (2 octets) | +-----------------------------------------------------+ | Nexthop AFI - 1 (2 octets) | draft-nalawade-bgp-update-v2-00.txt [Page 4] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 +-----------------------------------------------------+ | Nexthop SAFI - 1 (2 octets) | +-----------------------------------------------------+ | ..... | +-----------------------------------------------------+ | Nexthop AFI - n (2 octets) | +-----------------------------------------------------+ | Nexthop SAFI - n (2 octets) | +-----------------------------------------------------+ NLRI AFI/SAFI indicates the NLRIs to be expected in UPDATE-v2 message, followed by a list of nexthop AFI/SAFI indicating the nexthop type supported by the NLRI AFI/SAFI. Once peers exchange UPDATE-v2 capability, they should use UPDATE-v2 to exchange BGP updates. If, after exchanging UPDATE-v2 capability, a peer receives the older UPDATE message, then it should signal an error notification to the peer. For peers that support [BGP-SOFT], a BGPv4 Soft-Notification Message should be sent back to the peer with a Error Code Update and sub-code Invalid Message Type. For peers that dont support [BGP-SOFT] the BGP Speaker may reset the session with the peer with Error Code Update Message Error and a new Error Sub-code Invalid Message Type. 5. Future Directions There is a potential opportunity to cleanup encodings and add more flexibility and robustness to BGPv4. There is an opportunity to redefine the encodings for BGP attributes that contain or depend upon IPv4 Unicast addresses, and to make them SAFI-aware. There is also an opportunity to create a SAFI-specific attribute-space for attributes that are specific to a SAFI. 6. Deployment considerations This draft does not affect the deployment considerations for BGP. 7. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and draft-nalawade-bgp-update-v2-00.txt [Page 5] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 8. Security Considerations This extension to BGP does not change the underlying security issues. 9. Acknowledgements The authors would like to thank Keyur Patel, Bob Albrightson, Barry Friedman and Arjun Sreekantiah for their inputs and feedback. 10. Normative References [IANA-AFI] http://www.iana.org/assignments/address-family-numbers [IANA-SAFI] http://www.iana.org/assignments/safi-namespace [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-21.txt, March 2004. [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. [BGP-MP_NHOP] LeFausher, F., Tappan D., Nalawade, G., "BGPv4 Multiprotocol NEXTHOP", draft-lefaucher-bgp-mp-nexthop-01.txt, August 2002. [BGP-SOFT] Nalawade, G., Patel, K., Scudder, J., Ward, D., "BGPv4 SOFT-NOTIFICATION Message", draft-nalawade-bgp-soft-notify-00.txt, April 2004. 11. Author's Addresses Gargi Nalawade mailto:gargi@cisco.com Himanshu Shah mailto:hhshah@cisco.com draft-nalawade-bgp-update-v2-00.txt [Page 6] Internet Draft draft-nalawade-bgp-update-v2-00.txt August 2003 Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134 12. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this doc- ument itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-nalawade-bgp-update-v2-00.txt [Page 7]