idnits 2.17.1 draft-li-idr-mpls-path-programming-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 (July 1, 2014) is 3580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3032' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 426, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-li-spring-mpls-path-programming-00 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft Z. Zhuang 4 Intended status: Informational Huawei Technologies 5 Expires: January 2, 2015 July 1, 2014 7 BGP Extensions for Service-Oriented MPLS Path Programming (MPP) 8 draft-li-idr-mpls-path-programming-00 10 Abstract 12 Service-oriented MPLS programming is to provide customized service 13 process based on flexible label combinations. BGP will play an 14 important role for MPLS path programming to allocate MPLS segment, 15 download programmed MPLS path and the mapping of the service path to 16 the transport path. This document defines BGP extensions to support 17 service-oriented MPLS path programming. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 2, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. MPLS Segment Allocations . . . . . . . . . . . . . . . . . . 3 62 4. Download of MPLS Path . . . . . . . . . . . . . . . . . . . . 3 63 5. Download of Mapping of Service Path to Transport Path . . . . 5 64 5.1. Extended Unicast Tunnel Attributes . . . . . . . . . . . 5 65 5.2. Extended PMSI Tunnel Attribute . . . . . . . . . . . . . 7 66 6. Capability Negotiation . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Service-oriented MPLS programming proposed by 77 [I-D.li-spring-mpls-path-programming] is to provide customized 78 service process based on flexible label combinations. BGP will play 79 an important role for MPLS path programming to allocate MPLS segment, 80 download programmed MPLS path and the mapping of the service path to 81 the transport path. This document defines BGP extensions to support 82 service-oriented MPLS path programming. 84 2. Terminology 86 BGP: Border Gateway Protocol 88 EVPN: Ethernet VPN 90 L2VPN: Layer 2 VPN 92 L3VPN: Layer 3 VPN 94 MPP: MPLS Path Programming 96 MVPN: Multicast VPN 97 RR: Route Reflector 99 SDN: Software-Defined Network 101 S-EVPN: Segment-based EVPN 103 SR-Path: Segment Routing Path 105 NLRI: Network Layer Reachability Information 107 3. MPLS Segment Allocations 109 MPLS Segment is the component to compose the MPLS path. 110 [I-D.li-spring-mpls-path-programming] proposes the use cases for 111 service-oriented MPLS path programming which needs following MPLS 112 segments: 114 1. MPLS path programming for unicast service 116 o MPLS Segment for VPN identification 118 o MPLS Segment for ECMP 120 o MPLS Segment for OAM (Source identification) 122 o MPLS Segment for Traffic Steering 124 2. MPLS path programming for multicast service 126 o MPLS Segment for MVPN identification 128 o MPLS Segment for Source identification 130 3. MPLS virtual network for services 132 o MPLS Segment for MPLS virtual network 134 These MPLS Segments are defined in individual drafts. It is out of 135 the scope of this document. 137 4. Download of MPLS Path 139 According to the service requirements, the central controller can 140 combine MPLS segments flexibly. Then it can download the service 141 label combination for specific prefix related with the service.BGP 142 extensions are necessary to advertise label stacks for prefix in NLRI 143 field. 145 +---------------------------+ 146 | Length (1 octet) | 147 +---------------------------+ 148 | Label (3 octets) | 149 +---------------------------+ 150 ............................. 151 +---------------------------+ 152 | Prefix (variable) | 153 +---------------------------+ 154 Figure 1: NLRI Definition in RFC3107 156 [RFC3107] defines above NLRI to advertise label binding for specific 157 prefix. The label field can carry one or more labels. Each label is 158 encoded as 3 octets, where the high-order 20 bits contain the label 159 value, and the low order bit contains "Bottom of Stack". But for 160 other AFI/SAFIs using label binding such as VPNv4, VPNv6, EVPN, MVPN, 161 etc., it dose not support the capability to carry more labels for the 162 specific prefix. Moreover for the AFI/SAFIs which do not support 163 label binding capability originally, but may possibly adopt MPLS path 164 programming now, there is no label field in the NLRI. In order to 165 support flexible MPLS path programming, this document defines and 166 uses a new BGP attribute called the "Extended Label attribute". This 167 is an optional transitive BGP attribute. The format of this 168 attribute is defined as follows: 170 +---------------------------+ 171 | Label 1 (3 octets) | 172 +---------------------------+ 173 | Label 2 (3 octets) | 174 +---------------------------+ 175 ............................. 176 +---------------------------+ 177 | Label n (3 octets) | 178 +---------------------------+ 179 Figure 2: Extended Label Attribute 181 The Label field carries one or more labels (that corresponds to the 182 stack of labels [[RFC3032]]). Each label is encoded as 3 octets, 183 where the high-order 20 bits contain the label value, and the low 184 order bit contains "Bottom of Stack" (as defined in [[RFC3032]]). 186 The Central Controller for MPLS path programming could build a route 187 with Extended Label attribute and send it to the ingress routers. 189 Upon receiving such a route from the MPP Controller, the ingress 190 router SHOULD select such a route as the best path. If a packet 191 comes into the ingress router and uses such a path, the ingress 192 router will encapsulate the stack of labels which gets from the 193 Extended Label Attribute of the route into the packet and forward the 194 packet along the path. 196 The "Extended Label attribute" can be used for various BGP address 197 families. Before using this attribute, firstly, it is necessary to 198 negotiate the capability between two nodes to support MPLS path 199 programming for a specific BGP address family. If negotiation fails, 200 a node MUST NOT send this attribute and MUST discard this attribute 201 when it receives. 203 5. Download of Mapping of Service Path to Transport Path 205 Since the transport path is also to satisfy the service bearing the 206 requirement, it can also be programmed according to traffic 207 engineering requirements of service. Or the transport path can be 208 set up according to general traffic engineering requirements. Then 209 there needs to be implements the mapping of the service path to the 210 transport path. BGP Extensions is necessary that through the 211 community attribute of BGP, the identifier of the transport path can 212 be carried when distribute label stack for a specific prefix. 214 +---------------------------------+ 215 | Flags (1 octet) | 216 +---------------------------------+ 217 | Tunnel Type (1 octets) | 218 +---------------------------------+ 219 | MPLS Label (3 octets) | 220 +---------------------------------+ 221 | Tunnel Identifier (variable) | 222 +---------------------------------+ 223 Figure 3: PMSI Tunnel Attribute in RFC6514 225 [RFC6514] defines the "P-Multicast Service Interface Tunnel (PMSI 226 Tunnel) attribute". It is shown in the above figure. Since the 227 attribute is always for the specific usage in BGP-based MVPN, it can 228 not be applied to all possible use cases of service-oriented MPLS 229 path programming. This document accordingly defines two new types of 230 BGP attribute for both usage of unicast service path and the 231 multicast service path: Extended Unicast Tunnel Attribute and 232 Extended PMSI Tunnel Attribute. 234 5.1. Extended Unicast Tunnel Attributes 236 This document defines and uses a new BGP attribute called the 237 "Extended Unicast Tunnel attribute". This is an optional transitive 238 BGP attribute. The format of this attribute is defined as follows: 240 +------------------------------------------------+ 241 | Flags (1 octet) | 242 +------------------------------------------------+ 243 | Tunnel Type (1 octets) | 244 +------------------------------------------------+ 245 | Tunnel Identifier (variable) | 246 +------------------------------------------------+ 247 | Tunnel Specific Attributes (Variable)(Optional)| 248 +------------------------------------------------+ 250 This document defines the following flags: 251 0 1 2 3 4 5 6 7 252 +-+-+-+-+-+-+-+-+ 253 | reserved |S| 254 +-+-+-+-+-+-+-+-+ 256 + Unicast Tunnel Setup Required (S) 258 If the S flag is not set, the client node is just to map the service 259 path to the corresponding tunnel. If the S flag is set, the client 260 node MUST set up the tunnel according to the tunnel identifier and 261 the tunnel specific attribute firstly. Then it maps the service path 262 to the corresponding tunnel. 264 The Tunnel Type identifies the type of the tunneling technology used 265 for the unicast service path. The type determines the syntax and 266 semantics of the Tunnel Identifier field. This document defines the 267 following Tunnel Types: 269 + 0 - No tunnel information present 270 + 1 - RSVP-TE LSP 271 + 2 - LDP LSP 272 + 3 - GRE Tunnel 273 + 4 - MPLS-based Segment Routing Best-effort Path 274 + 5 - MPLS-based Segment Routing Traffic Engineering Path 276 Tunnel Specific Attributes contains the attributes of the tunnel. 277 The field is optional. The value depends on the tunnel type. It 278 will be defined in the future versions. 280 When the Tunnel Type is set to "No tunnel information present", the 281 Tunnel attribute carries no tunnel information (no Tunnel 282 Identifier). when the type is used, the tunnel used for the service 283 path is determined by the ingress router. 285 When the Tunnel Type is set to RSVP - Traffic Engineering (RSVP-TE) 286 Label Switched Path (LSP), the Tunnel Identifier is as specified in 288 [RFC3209]. If C-Type = 7, Tunnel Sender Address and Tunnel End-point 289 Address are IPv4 address in 4 octets. If C-Type = 8, Tunnel Sender 290 Address and Tunnel End-point Address are IPv6 address in 16 octets. 291 The other fields in the RSVP-TE LSP Identifier are the same as 292 specified in [RFC3209]. 294 When the Tunnel Type is set to LDP LSP, the Tunnel Identifier is 295 296 as specified in [RFC5036]. 298 When the Tunnel Type is set to GRE Tunnel, the Tunnel Identifier is 299 . 302 When the Tunnel Type is set to MPLS-based Segment Routing Best-effort 303 Path, the Tunnel Identifier is . When the ingress router receives a BGP 305 route with MPLS-based Segment Routing Path Tunnel Identifier in the 306 Extended Unicast Tunnel attribute, it will find the best-effort SR- 307 path based on the destination address. 309 When the Tunnel Type is set to MPLS-based Segment Routing Traffic 310 Engineering Path, the Tunnel Identifier is . If C-Type = 7, Tunnel 312 Sender Address and Tunnel End-point Address are IPv4 address in 4 313 octets. If C-Type = 8, Tunnel Sender Address and Tunnel End-point 314 Address are IPv6 address in 16 octets. The tunnel identifier is 315 similar as that of RSVP-TE LSP. 317 5.2. Extended PMSI Tunnel Attribute 319 This document defines and uses a new BGP attribute called the 320 "Extended PMSI Tunnel attribute". This is an optional transitive BGP 321 attribute. The format of this attribute is defined as follows: 323 +------------------------------------------------+ 324 | Flags (1 octet) | 325 +------------------------------------------------+ 326 | Tunnel Type (1 octets) | 327 +------------------------------------------------+ 328 | Tunnel Identifier (variable) | 329 +------------------------------------------------+ 330 | Tunnel Specific Attributes (Variable)(Optional)| 331 +------------------------------------------------+ 333 This document defines the following flags: 334 0 1 2 3 4 5 6 7 335 +-+-+-+-+-+-+-+-+ 336 | reserved |S| 337 +-+-+-+-+-+-+-+-+ 339 + PMSI Tunnel Setup Required (S) 341 If the S flag is not set, the client node is just to map the service 342 path to the corresponding tunnel. If the S flag is set, the client 343 node MUST set up the tunnel according to the tunnel identifier and 344 the tunnel specific attribute firstly. Then it maps the service path 345 to the corresponding tunnel. 347 The Tunnel Type identifies the type of the tunneling technology used 348 for the multicast service path. The type determines the syntax and 349 semantics of the Tunnel Identifier field. This document defines the 350 following Tunnel Types: 352 + 0 - No tunnel information present 353 + 1 - RSVP-TE P2MP LSP 354 + 2 - mLDP P2MP LSP 355 + 3 - PIM-SSM Tree 356 + 4 - PIM-SM Tree 357 + 5 - BIDIR-PIM Tree 358 + 6 - Ingress Replication 359 + 7 - mLDP MP2MP LSP 361 Tunnel Identifier: The definition of Tunnel Identifier is the same as 362 those specified in section 5 of [RFC6514]. 364 Tunnel Specific Attributes contains the attributes of the PMSI 365 tunnel. The field is optional. The value depends on the PMSI tunnel 366 type. It will be defined in the future versions. 368 6. Capability Negotiation 370 It is necessary to negotiate the capability to support MPLS path 371 programming. The MPLS-Path-Programming Capability is a new BGP 372 capability [RFC5492]. The Capability Code for this capability is to 373 be specified by the IANA. The Capability Length field of this 374 capability is variable. The Capability Value field consists of one 375 or more of the following tuples: 377 +--------------------------------------------------+ 378 | Address Family Identifier (2 octets) | 379 +--------------------------------------------------+ 380 | Subsequent Address Family Identifier (1 octet) | 381 +--------------------------------------------------+ 382 | Send/Receive (1 octet) | 383 +--------------------------------------------------+ 385 The meaning and use of the fields are as follows: 387 Address Family Identifier (AFI): This field is the same as the one 388 used in [RFC4760]. 390 Subsequent Address Family Identifier (SAFI): This field is the same 391 as the one used in [RFC4760]. 393 Send/Receive: This field indicates whether the sender is (a) willing 394 to receive programming MPLS paths from its peer (value 1), (b) would 395 like to send programming MPLS paths to its peer (value 2), or (c) 396 both (value 3) for the . 398 7. IANA Considerations 400 TBD. 402 8. Security Considerations 404 TBD. 406 9. References 408 9.1. Normative References 410 [I-D.li-spring-mpls-path-programming] 411 Li, Z., "Use Cases and Framwork of Service-Oriented MPLS 412 Path Programming (MPP)", draft-li-spring-mpls-path- 413 programming-00 (work in progress), July 2014. 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, March 1997. 418 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 419 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 420 Encoding", RFC 3032, January 2001. 422 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 423 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 424 Tunnels", RFC 3209, December 2001. 426 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 427 Protocol 4 (BGP-4)", RFC 4271, January 2006. 429 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 430 "Multiprotocol Extensions for BGP-4", RFC 4760, January 431 2007. 433 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 434 Specification", RFC 5036, October 2007. 436 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 437 with BGP-4", RFC 5492, February 2009. 439 9.2. Informative References 441 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 442 BGP-4", RFC 3107, May 2001. 444 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 445 Encodings and Procedures for Multicast in MPLS/BGP IP 446 VPNs", RFC 6514, February 2012. 448 Authors' Addresses 450 Zhenbin Li 451 Huawei Technologies 452 Huawei Bld., No.156 Beiqing Rd. 453 Beijing 100095 454 China 456 Email: lizhenbin@huawei.com 457 Shunwan Zhuang 458 Huawei Technologies 459 Huawei Bld., No.156 Beiqing Rd. 460 Beijing 100095 461 China 463 Email: zhuangshunwan@huawei.com