draft-ietf-idr-bgp-ipv6-rt-constrain-00.txt   draft-ietf-idr-bgp-ipv6-rt-constrain-01.txt 
L3VPN Working Group K. Patel Network Working Group K. Patel
Internet-Draft R. Raszuk Internet-Draft Cisco Systems
Intended status: Standards Track Cisco Systems Intended status: Standards Track R. Raszuk
Expires: December 15, 2011 M. Djernaes Expires: May 3, 2012 NTT MCL Inc.
M. Djernaes
Juniper Networks Juniper Networks
J. Dong J. Dong
M. Chen M. Chen
Huawei Technologies Co., Ltd. Huawei Technologies
June 13, 2011 October 31, 2011
IPv6 Extensions for Route Target Distribution IPv6 Extensions for Route Target Distribution
draft-ietf-idr-bgp-ipv6-rt-constrain-00.txt draft-ietf-idr-bgp-ipv6-rt-constrain-01
Abstract Abstract
The current route target distribution specification described in The current route target distribution specification described in
RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. RFC4684 defines Route Target NLRIs of maximum length of 12 bytes.
The IPv6 specific Route Target extended community is defined in The IPv6 specific Route Target extended community is defined in
RFC5701 as length of 20 bytes. Since the current specification only [RFC5701] as length of 20 bytes. Since the current specification
supports prefixes of maximum length of 12 bytes, the lack of an IPv6 only supports prefixes of maximum length of 12 bytes, the lack of an
specific Route Target reachability information may be a problem when IPv6 specific Route Target reachability information may be a problem
an operator wants to use this application in a pure IPv6 environment. when an operator wants to use this application in a pure IPv6
This document defines an extension that allows BGP to exchange longer environment. This document defines an extension that allows BGP to
length IPv6 Route Target prefixes. exchange longer length IPv6 Route Target prefixes.
Requirements Language
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 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 3, 2012.
This Internet-Draft will expire on December 15, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. BGP IPv6 Constrained Route Target Capability . . . . . . . . . 4
2. BGP IPV6 Constrained Route Target Capability . . . . . . . . . 4 3. IPv6 Constrained Route Target NLRI Advertisements . . . . . . . 4
3. IPV6 Constrained Route Target NLRI Advertisements . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The current constrained route distribution specification defined in The current constrained route distribution specification defined in
[RFC4684] supports prefixes with a fixed maximum length of 12 bytes. [RFC4684] supports prefixes with a fixed maximum length of 12 bytes.
The prefix length needs to be extended to support the IPv6 specific The prefix length needs to be extended to support the IPv6 specific
Route Target extended community defined in [RFC5701] which is 20 Route Target extended community defined in [RFC5701] which is 20
bytes in length. bytes in length. This document defines an extension to the current
constrained route distribution specification that allows BGP speakers
This document defines an extension to the current constrained route to distribute longer length Route Target prefixes. A new BGP
distribution specification that allows BGP speakers to distribute capability known as BGP IPv6 Constrained Route Target capability is
longer length Route Target prefixes. A new BGP capability known as defined as part of extension that allows an exchange of longer length
BGP IPv6 Constrained Route Target capabiltiy is defined as part of Route Target prefixes. BGP speakers that do not exchange this
extension that allows an exchange of longer length Route Target capability MUST use Route Target NLRIs of maximum length of 12 bytes.
prefixes. BGP speakers that do not exchange this capability MUST use In this way, the current extension would preserve the backward
Route Target NLRIs of maximum length of 12 bytes. In this way, the compatibility with [RFC4684].
current extension would preserve the backward compatibility with
[RFC4684].
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. BGP IPV6 Constrained Route Target Capability 2. BGP IPv6 Constrained Route Target Capability
The "BGP IPV6 Constrained Route Target Capability" is a new BGP The "BGP IPV6 Constrained Route Target Capability" is a new BGP
capability [RFC5492]. The Capability code for this capability is capability [RFC5492]. The Capability code for this capability is
specified in the IANA Considersations section of this document. The specified in the IANA Considerations section of this document. The
Capability length field of this capability is zero. Capability length field of this capability is zero.
By advertising this capability to a peer, a BGP speaker conveys to By advertising this capability to a peer, a BGP speaker conveys to
the peer that the speaker support the longer length Route Target the peer that the speaker support the longer length Route Target
prefixes and the related procedures described in this document. prefixes and the related procedures described in this document.
3. IPV6 Constrained Route Target NLRI Advertisements 3. IPv6 Constrained Route Target NLRI Advertisements
Route Target membership NLRI is advertised in BGP UPDATE messages Route Target membership NLRI is advertised in BGP UPDATE messages
using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in
[RFC4760]. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI [RFC4760]. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI
is a prefix of 0 to 24 octets, encoded as defined in Section 4 of is a prefix of 0 to 24 octets, encoded as defined in Section 4 of
[RFC4760] for all the constrain route distribution. [RFC4760] for all the constrain route distribution.
This prefix is structured as follows: This prefix is structured as follows:
+-------------------------------+ +-------------------------------+
| origin as (4 octets) | | origin as (4 octets) |
+-------------------------------+ +-------------------------------+
| route target (8 or 20 octets)| | route target (8 or 20 octets)|
~ ~ ~ ~
| | | |
+-------------------------------+ +-------------------------------+
Except for the default route target, which is encoded as a zero- Except for the default route target, which is encoded as a zero-
length prefix, the minimum prefix length is 32 bits. length prefix, the minimum prefix length is 32 bits.
Route targets can then be expressed as prefixes, where, for instance, Route targets can then be expressed as prefixes, where, for instance,
a prefix would encompass all route target extended communities a prefix would encompass all route target extended communities
assigned by a given Global Administrator [RFC4360] and [RFC5701]. assigned by a given Global Administrator [RFC4360] and [RFC5701].
Alternatively, route target prefixes could be aggregated however if Alternatively, route target prefixes could be aggregated however if
done so, then only the Local Administrator field of the Route Target done so, then only the Local Administrator field of the Route Target
can be aggregated. Route Target Type and the Global Administrator can be aggregated. Route Target Type and the Global Administrator
Route Target fields MUST not be aggregated. Route Target fields MUST not be aggregated.
The default route target can be used to indicate to a peer the The default route target can be used to indicate to a peer the
willingness to receive all VPN route advertisements such as, for willingness to receive all VPN route advertisements such as, for
instance, the case of a route reflector speaking to one of its PE instance, the case of a route reflector speaking to one of its PE
router clients. router clients.
4. Acknowledgements 4. IANA Considerations
The authors would like to thank Pedro Marques, John Scudder, Alton Lo
and Zhengqiang Li for discussions and review.
5. IANA Considerations
This document defined the IPV6 Constrained Route Target Capability This document defined the IPV6 Constrained Route Target Capability
for BGP. The Capability code needs to be assigned by the IANA. for BGP. The Capability code needs to be assigned by the IANA.
6. Security Considerations 5. Security Considerations
This extension to [RFC4684] does not change the underlying security This extension to [RFC4684] does not change the underlying security
issues inherent in the existing BGP and [RFC4684]. issues inherent in the existing BGP and [RFC4684].
6. Acknowledgements
The authors would like to thank Pedro Marques, John Scudder, Alton Lo
and Zhenqiang Li for discussions and review.
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.
[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.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
skipping to change at page 7, line 4 skipping to change at page 6, line 28
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
Robert Raszuk Robert Raszuk
Cisco Systems NTT MCL Inc.
170 W. Tasman Drive 101 S Ellsworth Avenue Suite 350
San Jose, CA 95134 San Mateo, CA 94401
USA USA
Email: raszuk@cisco.com Email: robert@raszuk.net
Martine Djernaes Martin Djernaes
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: mdjernaes@juniper.net Email: mdjernaes@juniper.net
Jie Dong Jie Dong
Huawei Technologies Co., Ltd. Huawei Technologies
Huawei Building, No.3 Xinxi Rd. Huawei Building, No.156 Beiqing Rd.
Hai-Dian District, Beijing 100085 Beijing 100095
P.R. China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd. Huawei Technologies
Huawei Building, No.3 Xinxi Rd. Huawei Building, No.156 Beiqing Rd.
Hai-Dian District, Beijing 100085 Beijing 100095
P.R. China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
 End of changes. 24 change blocks. 
85 lines changed or deleted 70 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/