Internet DRAFT - draft-chakrabarti-idr-as4-route-cap
draft-chakrabarti-idr-as4-route-cap
Internet Domain Routing S. Chakrabarti
Internet-Draft IP Infusion - An Access Company
Intended status: Standards Track July 7, 2008
Expires: January 9, 2009
AS4-specific RD/RT/SOO Capability exchange
draft-chakrabarti-idr-as4-route-cap-01.txt
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 January 9, 2009.
Abstract
RFC 4893 defines BGP support for four-octet AS number space for
handling AS_PATH attributes and "My ASN" value in BGP OPEN messages.
Foue-Octet AS specific Extended Community attribute formats are
defined in draft-rekhter-as4octet-ext-community-03.txt. However, an
implementation compliant to RFC 4893 does not necessarily provide
support for 4-Octet Route-distinguisher, Route-target or Site-of-
origin in the BGP-MPLS-VPN. Thus BGP capability exchange for
extended AS number attribute does not cover the BGP-MPLS-VPN AS4-
specific route-attributes and route-distinguishers. This document
proposes an optional BGP capability exchange between the Provider
Edge (PE) routers in order to communicate the intention of handling
4-Octet or 2-Octet exteneded AS-specific Route-targets or Site-of-
Chakrabarti Expires January 9, 2009 [Page 1]
Internet-Draft AS4-specific PE-Route Capability July 2008
Origins or being able to handle and inteprete the 4-Octet route-
distinguishers correctly. This capability parameter will be part of
OPEN message during the BGP session initiation.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use BGP Capability advertisement . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Chakrabarti Expires January 9, 2009 [Page 2]
Internet-Draft AS4-specific PE-Route Capability July 2008
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
RFC 4893[AS4PATH] defines BGP support for four-octet AS number space
for handling AS_PATH attributes and "My ASN" value in BGP OPEN
messages. Foue-Octet AS specific Extended Community attribute
formats are defined in [AS4-EXTCOM]. However, an implementation
compliant to RFC 4893[AS4PATH] does not necessarily provide support
for 4-Octet Route-distinguisher, Route-target or Site-of-origin in
the BGP-MPLS-VPN. Thus BGP capability exchange for extended AS
number attribute does not cover the BGP-MPLS-VPN AS4-specific route-
attributes and route-distinguishers. This document proposes an
optional BGP capability exchange between the Provider Edge (PE)
routers in order to communicate the intention of handling 4-Octet or
2-Octet exteneded AS-specific Route-targets or Site-of-Origins or
being able to handle and inteprete the 4-Octet route-distinguishers
correctly. This capability parameter will be part of OPEN message
during the BGP session initiation.
Provider Edge (PE) rotuers [BGP-MPLS] are normally configured with
Route-distinguishers (RD), Route-targets(RT). RFC 4364 [BGP-MPLS]
states that a PE router may assign a Site Of origin in order to
prevent routing loops when CEs use private non-unique AS numbers.
In the following diagram, PE1 and PE2 belong to the same autonomous
system. But they may run two different vendors' implementations.
Even though both PEs can be compliant to RFC 4893, it is possible
that they may not support 4-Octet AS specific Route-target(RT) or
Route-distinguishers(RD) at the same time. The capability exchange
on handling 4-octet AS-specific Route-target, Route distinguishers
and Site Of Origin is needed for two PEs to interoperate efficiently
in interpreting each-other's route-attributes and RDs in a VPN-IPv4
or VPN-IPv6 prefixes. So far, the Route-target and Site Of Orgin are
used as extended community attributes with 2byte AS number format,
thus static configurations on different PEs were sufficient. With
the introduction of 4-Octet AS specific extended communities
[AS4-EXTCOM] and 4-Octet AS specifc RDs [BGP-MPLS], static
configurations in different PEs are not enough; if one does not
support the 4-octet RT for example, it the other expects 4-Octet RTs
the sessions will be reset in the middle of the session and routing
outage will take place. This capability negotiation will be also
useful for inter-AS BGP-MPLS-VPN scenario option C. This document
Chakrabarti Expires January 9, 2009 [Page 3]
Internet-Draft AS4-specific PE-Route Capability July 2008
introduces a new capability message for BGP-MPLS-VPN scenarios for
handling OLD and NEW implementations which support extended AS-
specific routing attributes. The following sections will detail the
format of AS-specifc routing capability messages.
------------ ------------- ----- ------------- -------
| | | | | | | | | |
| CE1 |-----| PE1 |-----| P |--| PE2 |--------| CE2 |
| | | | | | | | | |
------------ ------------- ------- ------------- --------
rd = 200:300 rd = 200:300
rt = 200:300 (export/import ) rt = 200:300 (export/import)
(2byte format) (4byte format)
configured configured
A problem scenario with PEs supporting 2byte and 4byte AS-specific
ext-communities
3. Terminology
OLD implementation: A BGP speaker which is RFC 4364[BGP-MPLS]
compliant and does not implement 4byte extension to the AS number as
defined in RFC 4893 or it implements RFC 4893, but does not implement
AS4-specific extended RT, SOO communities or 4-octet AS specific RDs.
NEW implementation: A BGP speaker which implements the 4-byte AS
number support as defined in RFC 4893 and it supports As4-specific
extended communities [AS4-EXTCOM]
4. Use BGP Capability advertisement
The AS-specific routing capability message will be used during OPEN
message as defined in RFC 4271. This capability message SHOULD be
used in conjuction with Extended AS capability message defined in RFC
4893.
The fields in the Capabilities Optional Parameter are set as follows.
The Capability type Code field is TBD (to be assigned by IANA). The
Capability Length field is set to 2. The Capability Value field is
defined as:
Chakrabarti Expires January 9, 2009 [Page 4]
Internet-Draft AS4-specific PE-Route Capability July 2008
The use and meaning of this field is as follow:
0 7 15
+-------+-------+-------+-------+
| Resvd | |D|S|R| Resvd | RT-val|
+-------+-------+-------+-------+
Resvd - These 4 bits are reserved for future use
D - If D bit is on the implementation sends and receives 4-octet
AS-specific RD format
S - If S bit is on, then implementation sends and receives 4-octet
AS-specific Site Of Origin attributes along with the VPN routes
R - If R bit is on, the implementation is able to send and receive
4-octet AS specific RT format
RT-val - If this value is 1, the PE is able to export 4-octet AS-
specific RTs; if this value is 2 the PE is able to import 4-octet
AS-specific RT attributes. When the value is 3, the
implementation is able to handle As4-specific RT extended
community attributes for both export and import.
Please note that a NEW implementation supporting the above
capabilities SHOULD be able to optionally support 2-octet AS-specific
RD, RT and Site of origin attributes as per the local configuration.
The NEW implementation is not capable of converting the 2-octet AS
specific to 4-octet AS specific attributes for a given route.
5. IANA Considerations
This document requests a BGP capability type code from IANA.
6. Acknowledgements
7. Normative References
[AS4PATH] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[BGP-MPLS]
Rekhter, Y. and E. Rosen, "BGP/MPLS IP Virtual Private
Networks", RFC 4364, February 2006.
[AS4-EXTCOM]
Rekhter, Y., Sangli, S., and D. Tappan, "Four-octet AS
Specific BGP Extended Community",
Chakrabarti Expires January 9, 2009 [Page 5]
Internet-Draft AS4-specific PE-Route Capability July 2008
draft-rekhter-as4octet-ext-community-03.txt (work in
progress), April 2008.
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "Border Gateway
Protocol 4", RFC 4271, January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Samita Chakrabarti
IP Infusion - An Access Company
1188 Arques Avenue
Sunnyvale, CA
USA
Email: samitac@ipinfusion.com
Chakrabarti Expires January 9, 2009 [Page 6]
Internet-Draft AS4-specific PE-Route Capability July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Chakrabarti Expires January 9, 2009 [Page 7]
