Network Working Group M. Djernaes Internet-Draft C. Appanna Intended status: Informational D. Ward Expires: April 16, 2007 Cisco Systems, Inc. October 13, 2006 Context updates in BGP draft-djernaes-simple-context-update-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 16, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Djernaes, et al. Expires April 16, 2007 [Page 1] Internet-Draft Context updates in BGP October 2006 Abstract Currently BGP protocol can carry reachability information for multiple Address Families (AFI) and Subsequence Address Families (SAFI) using the Multiprotocol Extension[RFC2858], but it is limited to grouping of information based on the AFI/SAFI hierarchy. This document describes a mechanism to group and exchange prefix information based on properties other than just the AFI/ SAFI[RFC2858]. The mechanism is flexible and backwards compatible with the current methods for exchanging prefixes and hence does not require any changes to the the protocol formats. It introduces a new capability that allows two BGP speakers negotiate during the BGP OPEN phase in order to define what each AFI/SAFI means. In other words, the concept of a 'context' is defined and each such 'context' can be mapped to an AFI/SAFI. The context to AFI/SAFI mapping is only relevant to the BGP peers of the BGP session and hence offers great flexibility in how 2 BGP speakers can choose to group and exchange prefix information. Djernaes, et al. Expires April 16, 2007 [Page 2] Internet-Draft Context updates in BGP October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Context Capability . . . . . . . . . . . . . . . . . . . . . . 6 3. Context Description . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Djernaes, et al. Expires April 16, 2007 [Page 3] Internet-Draft Context updates in BGP October 2006 1. Introduction The motivation for this proposal is the ever changing requirement to use BGP for exchanging reachability information of different types destined to different destination tables or databases. This is especially true in the context of BGP[I-D.ietf-idr-bgp4] UPDATE messages or in general of all reachability exchanged between pairs of BGP speakers. This in turn has resulted in BGP defining mechanisms to group and demultiplex incoming data on the same BGP session so as to be able to process them differently and put them in different destination tables. Originally BGP UPDATE messages targeted the global IPv4 Unicast table. Then came the Multiprotocol Extension[RFC2858] which allowed prefix exchange based Address Families and Subsequence Address Family identifiers so that for eg. IPv6 Unicast prefix information could be exchanged between a pair of BGP speakers. The Multiprotocol Extension based its design on the fact that a way to address special target tables based on AFI and SAFI values. For each new grouping, it is required to obtain a unique AFI/SAFI value to define the group. While this definition has served BGP very well till now, there are new requirements that demand the grouping to be more flexible and also local to a pair of BGP speakers (that can be extended to any set of BGP speakers without loss of the point being made). In many such situations it neither is it necessary to obtain a unique global AFI/SAFI pair nor is it possible to always define the group in with a bi-level scheme such as AFI/SAFI. A case when an opaque context is useful and doesn't directly or easily follow AFI/SAFI semantics is when it is to imply that a specific service is available from this peering point. For example, if the a provider would like to announce reachability for a specific QOS service; it would be easily possible. A provider would not have to actually negotiate in the protocol what the markings on the packets to be forwarded would have to be nor would we further have to invent AFI/SAFI combinations to represent this service. Instead we announce that all NLRIs advertised with this Context Id (see below) will be avalible for the QOS service represented by the AFI / SAFI / QOS Id triplet. One of the options available would be to define a 3rd level the is either below or above the AFI/SAFI levels but that would have the same disadvantages as AFI/SAFI the moment a grouping is required that does not fit into the three levels. This document defines an context capability which can be used in Djernaes, et al. Expires April 16, 2007 [Page 4] Internet-Draft Context updates in BGP October 2006 combination with, or instead of, the multiprotocol capability and which describes each destination context, using well known types and values, and associate a context identifier to each context. When two BGP speakers have exchanged their context descriptions, prefix exchange can happen, using a special CONTEXT AFI (value to be defined) and the the context identifier in place of the SAFI value. The advantage of this approach is that the existing update message format can be reused, but still adding the benefit of being able to group prefixes with greater flexibility than permitted by the AFI/ SAFI hirearchy and without requiring the addition of a new level. It also does not force all groupings to be forced into the two level afi/safi hierarchy. It also allows for backward compatibility with existing BGP extensions, like Route Refresh[RFC2918]. Djernaes, et al. Expires April 16, 2007 [Page 5] Internet-Draft Context updates in BGP October 2006 2. Context Capability This specification defines the Context capability (CTXT-Cap) as: Capability code (1 octet): fixed value. TBD Capability length (2 octet): length of capability Capability value (1 octet): Context Id followed by Description. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+ | Context Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Context Description (variable length) .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The use and meaning of these fields are as follows: Context Identifier The Context Identifier is a single octet (8 bit) values which is used as the SAFI value in the update messages. Context Description The Context Description is a list of TLV triplets which can fully describe the context in which the reachability information advertised with this identifier (SAFI) should be processed. For a BGP speaker to be able to exchange reachability information for individual contexts it must first advertise the Context Capability, using the Capability code TDB, to its peer. If a BGP speaker want to advertise multiple contexts it should repeat the Context Capability for each context. Djernaes, et al. Expires April 16, 2007 [Page 6] Internet-Draft Context updates in BGP October 2006 3. Context Description The Context Description capability is used to fully describe the context associated with a Context Identifier. It consists of a list of TLV triplets. The Type space enumerates that various types that are defined. This specification defines 4 type values and others may be defined as and when required. This type space will need to be maintained by IANA. A context is said to be matching if, and only if, all triplets match. Type value = 0 This value is reserved and should not be used. Its presence should be ignored in a message. Type value = 1 This type represents the AFI. The length field is 1 octet and the value field is also 1 octet. The value field contains the AFI value associated with the Context Id. The value field must contain a valid AFI value according to the AFI name space maintained by IANA[IANA-AFI] Type value = 2 This type represents the SAFI. The length field is 1 octet and the value field is also 1 octet. The value field contains the SAFI value associated with the Context Id. The value field must contain a valid SAFI value according to the SAFI name space maintained by IANA[IANA-SAFI] Type value = 3 This type represents a QOS Id. The length field is 1 octet and the value field is also 1 octet. The value field contains values that represent a further subdivision or grouping of the reachability information represented by the AFI/SAFI if specified. This value is only required to be of scope relevant to the two BGP speakers of a BGP peering session. It is not required to have global scope like the AFI/SAFI values. The remaining Context Description Types should be maintained by IANA. Djernaes, et al. Expires April 16, 2007 [Page 7] Internet-Draft Context updates in BGP October 2006 4. IANA Considerations BGP Capability A new BGP Capability type must be allocated, by IANA, for the CONTEXT capability. CONTEXT Address Family Identifier A new CONTEXT AFI must be allocated by IANA. Context Description Types The Context Description Types must be maintained by IANA. Djernaes, et al. Expires April 16, 2007 [Page 8] Internet-Draft Context updates in BGP October 2006 5. Operation When a pair of BGP speakers want to exchange reachability information grouped or scoped by a context that is defined by more than the AFI/ SAFI hierarchy, they can use the Context Capability. Each BGP speaker must send to the other its list of Context Ids and Context Descriptions. Two BGP speakers is said to have advertised the same context if, and only if, the received and advertised Context descriptions are exactly the same. While it may be convenient to have the same Context Id associated with the same Context Description on both BGP Speakers, it is not mandatory. However the received Context Id must be stored by the BGP process so that it can identify the context while processing received data. When the Context capability have been exchanged and two BGP speakers want to exchange reachability information for a given context, the speakers must use the Context AFI to identify that an extended context is used and use the Context Identifier as the SAFI value. The Context Identifier must be the value advertised along with the Context Description during Context Capability negotiation. The BGP speakers can also exchange reachability information for other AFI/SAFI pairs along with the Context capability. The Context capability does not impact other AFI/SAFI semantics, but a BGP speaker must must not accept a Context Identifier describing an AFI/ SAFI pair also announced in the Multiprotocol Extension. Djernaes, et al. Expires April 16, 2007 [Page 9] Internet-Draft Context updates in BGP October 2006 6. Discussion This approach for extending the available contexts beyond the current AFI/SAFI context reuses the current Multiprotocol Extension formats and therefore no changes is needed to the BGP UPDATE format. Existing extensions which rely on the AFI/SAFI values to specify a given context can, without protocol modifications, use the Context AFI and the Context Identifier (as SAFI value) to specify the new contexts. Alternative approaches considered to provide a hierarchy or grouping of reachability information on more than AFI/SAFI suffered from the disadvantage of affecting the base BGP UPDATE message format and would require substantial changes to BGP implementations. Djernaes, et al. Expires April 16, 2007 [Page 10] Internet-Draft Context updates in BGP October 2006 7. Security Considerations tbd Djernaes, et al. Expires April 16, 2007 [Page 11] Internet-Draft Context updates in BGP October 2006 8. References [I-D.ietf-idr-bgp4] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-26 (work in progress), October 2004. [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, September 2000. [IANA-AFI] "http://www.iana.org/assignments/address-family-numbers". [IANA-SAFI] "http://www.iana.org/assignments/safi-namespace". Djernaes, et al. Expires April 16, 2007 [Page 12] Internet-Draft Context updates in BGP October 2006 Authors' Addresses Martin Djernaes Cisco Systems, Inc. 170 W. Tasman Drive San Jose 95134 US Phone: +1 408 853 1676 Email: djernaes@cisco.com Chandrashekhar Appanna Cisco Systems, Inc. 170 W. Tasman Drive San Jose 95134 US Phone: +1 408 826 6198 Email: achandra@cisco.com David Ward Cisco Systems, Inc. 170 W. Tasman Drive San Jose 95134 US Phone: +1 651 726 2368 Email: dward@cisco.com Djernaes, et al. Expires April 16, 2007 [Page 13] Internet-Draft Context updates in BGP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Djernaes, et al. Expires April 16, 2007 [Page 14]