idnits 2.17.00 (12 Aug 2021) /tmp/idnits28556/draft-you-idr-bgp-vpn-discovery-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 date (September 15, 2014) is 2805 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) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Downref: Normative reference to an Informational RFC: RFC 6624 == Outdated reference: A later version (-08) exists of draft-raszuk-idr-bgp-auto-discovery-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Idr Working Group J. You 3 Internet-Draft Q. Liang 4 Intended status: Standards Track Huawei 5 Expires: March 19, 2015 September 15, 2014 7 BGP VPN Peer Discovery Method 8 draft-you-idr-bgp-vpn-discovery-00 10 Abstract 12 This document proposes a VPN peer discovery method based on BGP. All 13 BGP peers need to establish sessions with a centralized control point 14 which collects and distributes BGP VPN Peer information according to 15 local policies or filtering policies subscribed from BGP peers. 16 Thereafter, the BGP node can select the interested peers with the 17 same VPN services to establish sessions. This would avoid 18 unnecessary session between uninterested BGP peers. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 19, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. VPN Peer Discovery Method . . . . . . . . . . . . . . . . . . 3 63 3.1. VPN Peer Filter . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. VPN Peer Information . . . . . . . . . . . . . . . . . . 5 65 3.3. Deployment Considerations . . . . . . . . . . . . . . . . 7 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The base BGP-4 specification ([RFC4271]) utilizes TCP for session 77 establishment between peers, which requires prior knowledge of the 78 end point's address to which a BGP session should be targeted. The 79 BGP auto discovery [I-D.raszuk-idr-bgp-auto-discovery] describes a 80 method for automating portions of a router's BGP configuration via 81 discovery of BGP peers with which to establish further sessions from 82 an initial "bootstrap" router. However, in 83 [I-D.raszuk-idr-bgp-auto-discovery], the VPN information of BGP peers 84 is not collected by the "bootstrap" router. Instead, the VPN-related 85 information is obtained after the BGP session established between BGP 86 peers ([RFC4761], [RFC6624]). Basically, if there's no same VPN 87 service between the BGP nodes, there's no need to establish the BGP 88 session. If BGP node can obtain the VPN information of the BGP peers 89 before BGP session establishment, it could avoid unnecessary session 90 between uninterested BGP peers. 92 This document proposes a VPN peer discovery method based on BGP. All 93 BGP peers need to establish sessions with a centralized control point 94 which collects and distributes BGP VPN Peer information according to 95 local policies or filtering policies subscribed from BGP peers. 97 Thereafter, the BGP node can select the interested peers with the 98 same VPN services to establish sessions. From OAM aspects, it is 99 beneficial for BGP node only following the interested BGP peers based 100 on its filtering policies e.g. BGP peers in a specified AS. So this 101 BGP node doesn't need to follow the VPN information of the BGP peers 102 in other ASs. Thus, the BGP session between uninterested BGP peers 103 will not be established. 105 2. Terminology 107 This section contains definitions for terms used frequently 108 throughout this document. However, many additional definitions can 109 be found in [RFC4760] and [RFC5575]. 111 AFI: Address Family Identifier 113 AS: Autonomous System number 115 NLRI: Network Layer Reachability Information 117 RD: Route Distinguisher 119 RR: Route Reflector 121 SAFI: Subsequent Address Family Identifier 123 3. VPN Peer Discovery Method 125 The centralized control point collects all the VPN service 126 information of BGP nodes within the domain, and then distributes the 127 BGP VPN Peer information to the BGP peers according to local policies 128 or filtering policies subscribed from BGP peers. 130 3.1. VPN Peer Filter 132 A new Path Attribute, i.e. VPN Peer Filter Attribute (Type Code: 133 TBD1) is defined to carry VPN peer filtering information. It is 134 carried in the BGP Update message. This attribute is used by the BGP 135 peer for subscribing the interested VPN peer information towards the 136 centralized control point. 138 The format of VPN Peer Filter Attribute is defined in Figure 1: 140 +-----------------------------------------------------+ 141 |Attr. Flags (1 octet) | Attr. Typr Code (1 Octec) | 142 +-----------------------------------------------------+ 143 | Attribute Length (2 octets) | 144 +-----------------------------------------------------+ 145 | Filter 1 (var) | 146 +-----------------------------------------------------+ 147 | ... | 148 +-----------------------------------------------------+ 149 | Fitler N (var) | 150 +-----------------------------------------------------+ 152 Figure 1: VPN Peer Filter Attribute 154 The attribute flags and type code fields are detailed in Figure 2: 156 0 1 157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 158 +-+-+-+-+-+-+-+-+---------------+ 159 |1|0|0|0|0|0|0|0| TBD1 | 160 +-+-+-+-+-+-+-+-+---------------+ 162 Figure 2: Flags & Type Code Fields 164 Bit 0: Optional attribute (value 1) 166 Bit 1: Non transitive attribute (value 0) 168 Bit 2: Partial bit (value 0 for optional non transitive 169 attributes) 171 Bit 3: Length of one octet (value 0) 173 Bit 4-7: Unused (value all zeros) 175 Type code: Attribute type code TBD1 177 Each VPN Peer Filter Attribute contains one or more filters. The 178 Filter is encoded as: ([RFC5575]). It 179 contains a set of {operator, value} pairs that are used to match the 180 specified value of the corresponding type defined in filter encoding. 181 The operator byte is encoded as: 183 0 1 2 3 4 5 6 7 184 +---+---+---+---+---+---+---+---+ 185 | e | a |not|eq |str| len | 186 +---+---+---+---+---+---+---+---+ 188 Figure 3: Numeric Operator 190 e: end-of-list bit. Set in the last {op, value} pair in the list. 192 a: AND bit. If unset, the previous term is logically ORed with 193 the current one. If set, the operation is a logical AND. It 194 should be unset in the first operator byte of a sequence. The AND 195 operator has higher priority than OR for the purposes of 196 evaluating logical expressions. 198 not: NOT bit. If set, logical negation of operation. 200 eq: equality between data and value. 202 str: STRING bit. If set, the value is an ASCII string. 204 len: The length of the value field for this operand is given as (1 205 << len). 207 For the filter, the following types are defined: 209 type 1 - RD: RD, 8 octets 211 type 2 - AS: AS, 4 octets 213 type 3 - AFI/SAFI: AFI/SAFI, 3 octets 215 type 4 - Service Type: Service Type, 2 octets, to identify a VPN 216 service type, e.g. EVPN, Kompella VPLS [RFC4761], BGP AD VPLS 217 [RFC6074], IP VPN. 219 type 5 - Peer IP: Peer IP, 4 octets for IPv4 or 16 octets for 220 IPv6. 222 type 6 - Export RT: RT/VPN target, 8 octets, filled with local 223 import RTs/VPN targets of the subscriber. 225 3.2. VPN Peer Information 227 The BGP Speaker can use the Network Layer Reachability Information 228 field of the MP_REACH_NLRI ([RFC4760]) attribute to notify the peer 229 the corresponding VPN peer information, which is satisfied with local 230 or peer's filtering policies. Similarly, The BGP Speaker can use the 231 Withdrawn Route NLRIs field of the MP_UNREACH_NLRI ([RFC4760]) 232 attribute to notify the peer of removing the corresponding VPN peer 233 information. 235 Besides, this document defines a new value for the Address Family 236 Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI 237 attributes: 239 3 (TBD2) - Network Layer Reachability Information used for VPN 240 Service 242 For the Subsequent Address Family Identifier field carried in the 243 MP_REACH_NLRI and MP_UNREACH_NLRI attributes, if AFI = 3 (TBD), then 244 the SAFI could be set to 0 by the sender, and it is ignored by the 245 receiver. 247 The Network Layer Reachability information is encoded as one or more 248 2-tuples of the form ([RFC4760]). 250 The extended Network Layer Reachability information field of the 251 MP_REACH_NLRI or the Withdrawn Route NLRIs field of the 252 MP_UNREACH_NLRI is encoded as shown in Figure 4, therein the VPN 253 information including service type, RD, AS, AFI/SAFI and peer address 254 can be regarded as a particular prefix. 256 +-----------------------------------+ 257 | Length (1 octet) | 258 +-----------------------------------+ 259 | Service Type (1 octet) | 260 +-----------------------------------+ 261 | Route Distinguisher (8 octets) | 262 +-----------------------------------+ 263 | AS (4 octets) | 264 +-----------------------------------+ 265 | AFI/SAFI (3 octets) | 266 +-----------------------------------+ 267 | Peer Address (4 or 16 octets) | 268 +-----------------------------------+ 270 Figure 4: VPN Service Informatiom 272 The use and meaning of these fields are as follows: 274 Length: The Length field indicates the length of the VPN service 275 information, including service type, RD, AS, AFI/SAFI and peer 276 address. 278 Service Type: Service type is used to identify a VPN service type, 279 e.g. EVPN, Kompella VPLS [RFC4761], BGP AD VPLS [RFC6074], IP 280 VPN. 282 Route Distinguisher (RD): An 8-byte Route Distinguisher 284 AS: Autonomous System number 286 Address Family Identifier (AFI): This field in combination with 287 the Subsequent Address Family Identifier field identifies the set 288 of Network Layer protocols to which the address carried in the 289 Next Hop field must belong, the way in which the address of the 290 next hop is encoded, and the semantics of the Network Layer 291 Reachability Information that follows. If the Next Hop is allowed 292 to be from more than one Network Layer protocol, the encoding of 293 the Next Hop MUST provide a way to determine its Network Layer 294 protocol. Presently defined values for the Address Family 295 Identifier field are specified in the IANA's Address Family 296 Numbers registry. 298 Subsequent Address Family Identifier (SAFI): This field in 299 combination with the Address Family Identifier field identifies 300 the set of Network Layer protocols to which the address carried in 301 the Next Hop must belong, the way in which the address of the next 302 hop is encoded, and the semantics of the Network Layer 303 Reachability Information that follows. If the Next Hop is allowed 304 to be from more than one Network Layer protocol, the encoding of 305 the Next Hop MUST provide a way to determine its Network Layer 306 protocol. 308 Peer Address: the address of the peer, 4 bytes for IPv4, and 16 309 bytes for IPv6. 311 3.3. Deployment Considerations 313 The centralized control point can be deployed on the RR. Then the RR 314 needs to establish the sessions with all the PEs to obtain the 315 interested VPN peer information. 317 BGP nodes use VPN Peer Filter Attribute (Type Code: TBD1) for 318 subscribing the interested VPN peer information towards the 319 centralized control point. 321 The RR notifies the BGP peer the corresponding VPN peer information 322 (an extended Network Layer Reachability Information), which is 323 satisfied with local or peer's filtering policies. 325 4. IANA Considerations 327 This document defines a new Path Attribute, i.e. VPN Peer Filter 328 Attribute (Type Code: TBD1), which will be used to carry VPN peer 329 filtering information. A new attribute type code TBD1 is to be 330 assigned by IANA from the BGP path attribute Type Code space. 332 This document defines a new MP_REACH_NLRI /MP_UNREACH_NLRI AFI type 333 code TBD2 which will be used to carry VPN service. That value will 334 need to be assigned by IANA from BGP AFI Type Code space. 336 This document defines a new NLRI format, to be carried in 337 MP_REACH_NLRI and MP_UNREACH_NLRI attributes. 339 5. Security considerations 341 This extension to BGP does not change the underlying security issues 342 inherent in the existing BGP. 344 6. Acknowledgement 346 TBD. 348 7. References 350 7.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 356 Protocol 4 (BGP-4)", RFC 4271, January 2006. 358 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 359 "Multiprotocol Extensions for BGP-4", RFC 4760, January 360 2007. 362 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 363 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 364 4761, January 2007. 366 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 367 and D. McPherson, "Dissemination of Flow Specification 368 Rules", RFC 5575, August 2009. 370 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 371 "Provisioning, Auto-Discovery, and Signaling in Layer 2 372 Virtual Private Networks (L2VPNs)", RFC 6074, January 373 2011. 375 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 376 Virtual Private Networks Using BGP for Auto-Discovery and 377 Signaling", RFC 6624, May 2012. 379 7.2. Informative References 381 [I-D.raszuk-idr-bgp-auto-discovery] 382 Raszuk, R., Kumari, W., Mitchell, J., Patel, K., and J. 383 Scudder, "BGP Auto Discovery", draft-raszuk-idr-bgp-auto- 384 discovery-01 (work in progress), August 2014. 386 Authors' Addresses 388 Jianjie You 389 Huawei 390 101 Software Avenue, Yuhuatai District 391 Nanjing, 210012 392 China 394 Email: youjianjie@huawei.com 396 Qiandeng Liang 397 Huawei 398 101 Software Avenue, Yuhuatai District 399 Nanjing, 210012 400 China 402 Email: liuweihang@huawei.com