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]