idnits 2.17.1 draft-keyur-bgp-af-specific-rt-constrain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2010) is 4939 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 176 == Missing Reference: 'AFI' is mentioned on line 171, but not defined == Missing Reference: 'SAFI' is mentioned on line 171, but not defined -- Looks like a reference, but probably isn't: '6' on line 197 == Unused Reference: 'RFC4271' is defined on line 227, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group K. Patel 3 Internet-Draft R. Raszuk 4 Intended status: Standards Track Cisco Systems 5 Expires: April 21, 2011 M. Djernaes 6 Juniper Networks 7 J. Dong 8 M. Chen 9 Huawei Technologies Co., Ltd. 10 October 18, 2010 12 AFI Specific Route Target Distribution 13 draft-keyur-bgp-af-specific-rt-constrain-00.txt 15 Abstract 17 The current route target distribution specification described in 18 RFC4684 defines Route Target NLRIs of maxiumum length of 12 bytes. 19 Furthermore, the current specification mandates that Route Targets 20 exchanged using the current specification are applied towards 21 filtering for all VPN applications that uses the notion of Route 22 Target BGP extended communities. 24 In particular, the same Route Target distribution mechanism is used 25 to exchange VPNv4, VPNv6 and L2VPN prefixes. The IPv6 specific Route 26 Target extended community is defined in RFC5701 as length of 20 27 bytes. Since the current specification only supports prefixes of 28 maximum length of 12 bytes, the lack of an IPv6 specific Route Target 29 reachability information may be a problem when an operator wants to 30 use this application in a pure IPv6 environment. This document 31 defines an extension to the current constrained route distribution 32 specification that allows BGP speakers to distribute Route Target 33 prefixes using multiple different Address Families thereby limiting 34 the application of Route Target prefix filters to the specific 35 address family under which it is advertised. Furtheremore, this 36 document defines an extension that allows BGP to exchange longer 37 length IPv6 Route Target prefixes. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 21, 2011. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 87 2. BGP Constrained Route Target Capability . . . . . . . . . . . . 4 88 3. AFI specific Route Target NLRI Advertisements . . . . . . . . . 5 89 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 94 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 97 1. Introduction 99 The current constrained route distribution specification defined in 100 [RFC4684] supports prefixes with a fixed maximum length of 12 bytes. 101 Furthermore, the current specification mandates that the Route 102 Targets exchanged using the current specification are applied towards 103 filtering for all VPNv4, VPNv6, and L2VPN address families. 105 This behavior needs to be modified for the following reasons: 107 o The IPv6 specific Route Target extended community defined in 108 [RFC5701] is 20 bytes in length. Since the current specification 109 only supports prefixes of maximum length of 12 bytes, the lack of 110 an IPv6 specific Route Target reachability information may be a 111 problem when one wants to use this application in a pure IPv6 112 environment. 114 o The behavior of applying filtering for all VPN address families 115 (VPNv4, VPNv6 and L2VPN) is sub-optimal in cases where the 116 operators want to assign common Route Targets and perform scoped 117 filtering on an address family basis. 119 This document defines an extension to the current constrained route 120 distribution specification that allows BGP speakers to distribute 121 Route Target prefixes using multiple different Adddress Families 122 thereby limiting the application of Route Target filters to the 123 specific address family under which it is advertised. Address 124 families that do not exchange Route Target information using their 125 own AFI and SAFI = 132 MUST always use AFI=1 and SAFI=132 to exchange 126 their Route Targets and filter prefixes accordingly. Furthermore, 127 Address families that do exchange the Route Target information using 128 its own AFI and SAFI = 132 MUST override the Route Target information 129 received in AFI=1 and SAFI=132. In this way, the current extension 130 would preserve the backward compatibility with [RFC4684]. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. BGP Constrained Route Target Capability 140 A BGP speaker that wishes to exchange Route Target membership 141 information for any address family must use the Multiprotocol 142 Extensions Capability Code, as defined in [RFC4760] section [5], to 143 advertise the corresponding (AFI, SAFI) pair. 145 The BGP IPv6 Constrained Route Target capability is a new BGP 146 Capability [RFC5492] defined with Multiprotocol Extension Capability 147 code with AFI=2 and SAFI=132. 149 The BGP L2VPN Constrained Route Target capability is a new BGP 150 Capability [RFC5492] defined with Multiprotocol Extension Capability 151 code with AFI=25 and SAFI=132. 153 By advertising these capabilities to a peer, a BGP speaker conveys to 154 the peer that the speaker supports and can interpret appropriate 155 address family based Route Target reachability information and the 156 related procedures described in this document along with the 157 procedures described in [RFC4684]. When not present, the current 158 Constrained Route Target AFI=1 and SAFI=132 MUST apply to all the VPN 159 address families that did not exchanged the Constrained AFI specific 160 capability. Alternatively, the VPN address families that do 161 successful negotiation of newly defined Constrained Route Target 162 capabilities MUST override the Route Target information received in 163 the Constrained Route Target Address family of AFI=1 and SAFI=132. 164 In this way we make this specification fully backwards compatible 165 with the existing deployments. 167 3. AFI specific Route Target NLRI Advertisements 169 Route Target membership NLRI is advertised in BGP UPDATE messages 170 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes as defined in 171 [RFC4760]. The [AFI, SAFI] value pair used to identify this NLRI is 172 (AFI=X,SAFI=132) where X describes the address family to which 173 Specific RT Constrained advertisement will apply. 175 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 176 of 0 to 24 octets, encoded as defined in Section 4 of [5] for all the 177 constrain route distribution AFI/SAFI other than AFI = 1 and SAFI = 178 132. The valid NLRI length value for AFI = 1 and SAFI = 132 is 179 defined in [RFC4684]. 181 This prefix is structured as follows: 183 +-------------------------------+ 184 | origin as (4 octets) | 185 +-------------------------------+ 186 | route target (8 or 20 octets)| 187 ~ ~ 188 | | 189 +-------------------------------+ 191 Except for the default route target, which is encoded as a zero- 192 length prefix, the minimum prefix length is 32 bits. As the origin- 193 as field cannot be interpreted as a prefix. 195 Route targets can then be expressed as prefixes, where, for instance, 196 a prefix would encompass all route target extended communities 197 assigned by a given Global Administrator [6]. 199 The default route target can be used to indicate to a peer the 200 willingness to receive all VPN route advertisements such as, for 201 instance, the case of a route reflector speaking to one of its PE 202 router clients. 204 4. Acknowledgements 206 The authors would like to thank Pedro Marques, John Scudder and Alton 207 Lo for discussions and review. 209 5. IANA Considerations 211 This draft does not require any new allocations by IANA. In all 212 address families constrained route target distribution will use the 213 already allocated SAFI = 132. 215 6. Security Considerations 217 This extension to [RFC4684] does not change the underlying security 218 issues inherent in the existing BGP and [RFC4684]. 220 7. References 222 7.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 228 Protocol 4 (BGP-4)", RFC 4271, January 2006. 230 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 231 R., Patel, K., and J. Guichard, "Constrained Route 232 Distribution for Border Gateway Protocol/MultiProtocol 233 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 234 Private Networks (VPNs)", RFC 4684, November 2006. 236 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 237 with BGP-4", RFC 5492, February 2009. 239 [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community 240 Attribute", RFC 5701, November 2009. 242 7.2. Informative References 244 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 245 "Multiprotocol Extensions for BGP-4", RFC 4760, 246 January 2007. 248 Authors' Addresses 250 Keyur Patel 251 Cisco Systems 252 170 W. Tasman Drive 253 San Jose, CA 95134 254 USA 256 Email: keyupate@cisco.com 258 Robert Raszuk 259 Cisco Systems 260 170 W. Tasman Drive 261 San Jose, CA 95134 262 USA 264 Email: raszuk@cisco.com 265 Martine Djernaes 266 Juniper Networks 267 1194 N. Mathilda Avenue 268 Sunnyvale, CA 94089 269 USA 271 Email: mdjernaes@juniper.net 273 Jie Dong 274 Huawei Technologies Co., Ltd. 275 KuiKe Building, No.9 Xinxi Rd. 276 Hai-Dian District, Beijing 100085 277 P.R. China 279 Email: dongjie_dj@huawei.com 281 Mach(Guoyi) Chen 282 Huawei Technologies Co., Ltd. 283 KuiKe Building, No.9 Xinxi Rd. 284 Hai-Dian District, Beijing 100085 285 P.R. China 287 Email: mach@huawei.com