idnits 2.17.1 draft-bryant-mpls-unified-ip-sr-03.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 (October 30, 2017) is 2369 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) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-13 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-07 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-10 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-21 == Outdated reference: A later version (-12) exists of draft-ietf-spring-ipv6-use-cases-11 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track A. Farrel, Ed. 5 Expires: May 3, 2018 J. Drake 6 Juniper Networks 7 J. Tantsura 8 Individual 9 October 30, 2017 11 MPLS Segment Routing in IP Networks 12 draft-bryant-mpls-unified-ip-sr-03 14 Abstract 16 Segment routing is a source routed forwarding method that allows 17 packets to be steered through a network on paths other than the 18 shortest path derived from the routing protocol. The approach uses 19 information encoded in the packet header to partially or completely 20 specify the route the packet takes through the network, and does not 21 make use of a signaling protocol to pre-install paths in the network. 23 Two different encapsulations have been defined to enable segment 24 routing in an MPLS network or in an IPv6 network. While 25 acknowledging that there is a strong need to support segment routing 26 in both environments, this document defines a mechanism to carry MPLS 27 segment routing packets encapsulated in UDP. The resulting approach 28 is applicable to both IPv4 and IPv6 networks without the need for any 29 changes to the IP or segment routing specifications. 31 This document makes no changes to the segment routing architecture 32 and builds on existing protocol mechanisms such as the encapsulation 33 of MPLS within UDP defined in RFC 7510. 35 No new procedures are introduced, but existing mechanisms are 36 combined to achieve the desired result. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on May 3, 2018. 61 Copyright Notice 63 Copyright (c) 2017 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. The MPLS-SR-over-UDP Encoding Stack . . . . . . . . . . . . . 4 80 3. The Segment Routing Instruction Stack . . . . . . . . . . . . 5 81 3.1. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. UDP/IP Encapsulation . . . . . . . . . . . . . . . . . . . . 6 83 5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6 84 5.1. Domain Ingress Nodes . . . . . . . . . . . . . . . . . . 7 85 5.2. Legacy Transit Nodes . . . . . . . . . . . . . . . . . . 8 86 5.3. On-Path Pass-Through SR Nodes . . . . . . . . . . . . . . 8 87 5.4. SR Transit Nodes . . . . . . . . . . . . . . . . . . . . 9 88 5.5. Penultimate SR Transit Nodes . . . . . . . . . . . . . . 9 89 5.6. Domain Egress Nodes . . . . . . . . . . . . . . . . . . . 10 90 6. A Note on Segment Routing Paths and Penultimate Hop Popping . 11 91 7. Modes of Deployment . . . . . . . . . . . . . . . . . . . . . 11 92 7.1. Interconnection of SR Domains . . . . . . . . . . . . . . 11 93 7.2. SR Within an IP Network . . . . . . . . . . . . . . . . . 12 94 8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 13 95 9. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 102 14.2. Informative References . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 105 1. Introduction 107 Segment routing (SR) [I-D.ietf-spring-segment-routing] is a source 108 routed forwarding method that allows packets to be steered through a 109 network on paths other than the shortest path derived from the 110 routing protocol. SR also allows the packets to be steered through a 111 set of packet processing functions along that path. SR uses 112 information encoded in the packet header to partially or completely 113 specify the route the packet takes through the network and does not 114 make use of a signaling protocol to pre-install paths in the network. 116 The approach to segment routing in IPv6 networks is known as SRv6 and 117 is described in [I-D.ietf-6man-segment-routing-header]. The 118 mechanism described encodes the segment routing instruction list as 119 an ordered list of 128-bit IPv6 addresses that is carried in a new 120 IPv6 extension header: the Source Routing Header (SRH). 122 MPLS Segment Routing (MPLS-SR) [I-D.ietf-spring-segment-routing-mpls] 123 encodes the route the packet takes through the network and the 124 instructions to be applied to the packet as it transits the network 125 by imposing a stack of MPLS label stack entries on the packet. 127 This document describes a method for running SR in IPv4 or IPv6 128 networks by using an MPLS-SR label stack carried in UDP. No change 129 is made to the MPLS-SR encoding mechanism as described in 130 [I-D.ietf-spring-segment-routing-mpls] where a sequence of 32 bit 131 units, one for each instruction, called the Segment Routing 132 Instruction Stack (SRIS) is used. Each basic unit is encoded as an 133 MPLS label stack entry and the segment routing instructions (i.e., 134 the Segment Identifiers, SIDs) are encoded in the 20 bit MPLS Label 135 fields. 137 In summary, the processing described in this document is a 138 combination of normal MPLS-over-UDP behavior as described in 139 [RFC7510], MPLS-SR lookup and label-pop behavior as described in 140 [I-D.ietf-spring-segment-routing-mpls], and normal IP forwarding. No 141 new procedures are introduced, but existing mechanisms are combined 142 to achieve the desired result. 144 The method defined is a complementary way of running SR in an IP 145 network that can be used alongside or interchangeably with that 146 defined in [I-D.ietf-6man-segment-routing-header]. Implementers and 147 deployers should consider the benefits and drawbacks of each method 148 and select the approach most suited to their needs. 150 2. The MPLS-SR-over-UDP Encoding Stack 152 The MPLS-SR-over-UDP encoding stack is shown in Figure 1. 154 +---------------------+ 155 | | 156 | IP Header | 157 | | 158 +---------------------+ 159 | | 160 | UDP Header | 161 | | 162 +---------------------+ 163 | | 164 | Segment Routing | 165 | Instruction Stack | 166 ~ ~ 167 ~ ~ 168 | | 169 +---------------------+ 170 | | 171 | Payload | 172 ~ ~ 173 ~ ~ 174 | | 175 +---------------------+ 177 Figure 1: Packet Encapsulation 179 The payload may be of any type that, with an appropriate convergence 180 layer, can be carried over a packet network. It is anticipated that 181 the most common packet types will be IPv4, IPv6, native MPLS, and 182 pseudowires [RFC3985]. 184 Preceding the Payload is the Segment Routing Instruction Stack (SRIS) 185 that carries the sequence of instructions to be executed on the 186 packet as it traverses the network. This is the Segment Identifier 187 (SID) stack that is the ordered list of segments described in 188 [I-D.ietf-spring-segment-routing]. 190 Preceding the SRIS is a UDP header. The UDP header is included to: 192 o Introduce entropy to allow equal-cost multi-path load balancing 193 (ECMP) [RFC2992] in the IP layer [RFC7510]. 195 o Provide a protocol multiplexing layer as an alternative to using a 196 new IP type/next header. 198 o Allow transit through firewalls and other middleboxes. 200 o Provide disaggregation. 202 Preceding the UDP header is the IP header which may be IPv4 or IPv6. 204 3. The Segment Routing Instruction Stack 206 The Segment Routing Instruction Stack (SRIS) consists of a sequence 207 of Segment Identifiers (SIDs) as described in 208 [I-D.ietf-spring-segment-routing] encoded as an MPLS label stack as 209 described in [I-D.ietf-spring-segment-routing-mpls]. 211 The top SRIS entry is the next instruction to be executed. When the 212 node to which this instruction is directed has processed the 213 instruction it is removed (popped) from the SRIS, and the next 214 instruction is processed. 216 Each instruction is encoded in a single Label Stack Entry (LSE) as 217 shown in Figure 2. The structure of the LSE is unchanged from 218 [RFC3032]. 220 0 1 2 3 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Instruction | TC |S| TTL | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Instruction: Label Value, 20 bits 227 TC: Traffic Class, 3 bits 228 S: Bottom of Stack, 1 bit 229 TTL: Time to Live, 8 bits 231 Figure 2: SRIS Label Stack Entry 233 As with [I-D.ietf-spring-segment-routing-mpls] a 32 bit LSE is used 234 to carry each SR instruction. The instruction itself is carried in 235 the 20 bit Label Value field. The TC field has the normal meaning as 236 defined in [RFC3032] and modified in [RFC5462]. The S bit has bottom 237 of stack semantics defined in [RFC3032]. TTL is discussed in 238 Section 3.1. 240 3.1. TTL 242 The setting of the TTL is application specific, but the following 243 operational consideration should be born in mind. In SR the size of 244 the label stack may be increased within a single routing domain by 245 various operations such as the pushing of a Binding SID. 246 Furthermore, in SR packets are not necessarily constrained to travel 247 on the shortest path within a routing domain. Therefore, 248 considration has to be given to the possibility that there may be a 249 forwarding loop. To mitigate against this it is RECOMMENDED that the 250 TTL is decremented at each hop as the packet passes through the SR 251 network regardless of any other changes to the network layer 252 encapsulation. 254 Further discussion of the use of TTL during tunnelling can be found 255 in [RFC4023]. 257 4. UDP/IP Encapsulation 259 [RFC7510] specifies the values to be used in the UDP Source Port, 260 Destination Port, and Checksum fields. 262 An administrative domain, or set of administrative domains that are 263 sufficiently well managed and monitored to be able to safely use IP 264 segment routing is likely to comply with the requirements called out 265 in [RFC7510] to permit operation with a zero UDP checksum over IP. 266 However each operator needs to validate the decision on whether or 267 not to use a UDP checksum for themselves. 269 The [RFC7510] UDP header may be carried over IPv4 or over IPv6. 271 The IP source address is the address of the encapsulating device. 272 The IP destination address is implied by the instruction at the top 273 of the instruction stack. 275 If IPv4 is in use, fragmentation is not permitted. 277 5. Elements of Procedure 279 Nodes that are SR capable can process MPLS-SR packets. Not all of 280 the nodes in an SR domain are SR capable. Some nodes may be "legacy 281 routers" that cannot handle SR packets but can forward IP packets. 282 An SR capable node may advertise its capabilities using the IGP as 283 described in Section 8. There are six types of node in an SR domain: 285 o Domain ingress nodes that receive packets and encapsulate them for 286 transmission across the domain. Those packets may be any payload 287 protocol including native IP packets or packets that are already 288 MPLS encapsulated. 290 o Legacy transit nodes that are IP routers but that are not SR 291 capable (i.e., are not able to perform segment routing). 293 o Transit nodes that are SR capable but that are not identified by a 294 SID in the SID stack. 296 o Transit nodes that are SR capable and need to perform SR routing 297 because they are identified by a SID in the SID stack. 299 o The penultimate SR capable node on the path that processes the 300 last SID on the stack on behalf of the domain egress node. 302 o The domain egress node that forwards the payload packet for 303 ultimate delivery. 305 The following sub-sections describe the processing behavior in each 306 case. 308 In summary, the processing is a combination of normal MPLS-over-UDP 309 behavior as described in [RFC7510], MPLS-SR lookup and label-pop 310 behavior as described in [I-D.ietf-spring-segment-routing-mpls], and 311 normal IP forwarding. No new procedures are introduced, but existing 312 mechanisms ae combined to achieve the desired result. 314 The descriptions in the following sections represent the functional 315 behavior. Optimizations on this behavior may be possible in 316 implementations. 318 5.1. Domain Ingress Nodes 320 Domain ingress nodes receive packets from outside the domain and 321 encapsulate them to be forwarded across the domain. Received packets 322 may already be MPLS-SR packets (in the case of connecting two MPLS-SR 323 networks across a native IP network), or may be nativee IP or MPLS 324 packets. 326 In the latter case, the packet is classified by the domain ingress 327 node and an MPLS-SR stack is imposed. In the former case the MPLS-SR 328 stack is already in the packet. The top entry in the stack is popped 329 from the stack and retained for use below. 331 The packet is then encapsulated in UDP with the destination port set 332 to 6635 to indicate "MPLS-UDP" or to 6636 to indicate "MPLS-UDP-DTLS" 333 as described in [RFC7510]. The source UDP port is set randomly or to 334 provide entropy as described in [RFC7510]. 336 The packet is then encapsulated in IP for transmission across the 337 network. The IP source address is set to the domain ingress node, 338 and the destination address is set to the address corresponding to 339 the label that was previously popped from the stack. 341 This processing is equivalent to sending the packet out of a virtual 342 interface that corresponds to a virtual link between the ingress node 343 and the next hop SR node realized by a UDP tunnel. 345 The packet is then sent into the IP network and is routed according 346 to the local FIB and applying hashing to resolve any ECMP choices. 348 5.2. Legacy Transit Nodes 350 A legacy transit node is an IP router that has no SR capabilities. 351 When such a router receives an MPLS-SR-in-UDP packet it will carry 352 out normal TTL processing and if the packet is still live it will 353 forward it as it would any other UDP-in-IP packet. The packet will 354 be routed toward the destination indicated in the packet header using 355 the local FIB and applying hashing to resolve any ECMP choices. 357 If the packet is mistakenly addressed to the legacy router, the UDP 358 tunnel will be terminated and the packet will be discarded either 359 because the MPLS-in-UDP port is not supported or because the 360 uncovered top label has not been allocated. This is, however, a 361 misconnection and should not occur unless there is a routing error. 363 5.3. On-Path Pass-Through SR Nodes 365 Just because a node is SR capable and receives an MPLS-SR-in-UDP 366 packet does not mean that it performs SR processing on the packet. 367 Only routers identified by SIDs in the SR stack need to do such 368 processing. 370 Routers that are not addressed by the destination address in the IP 371 header simply treat the packet as a normal UDP-in-IP packet carrying 372 out normal TTL processing and if the packet is still live routing the 373 packet according to the local FIB and applying hashing to resolve any 374 ECMP choices. 376 This is important because it means that the SR stack can be kept 377 relatively small and the packet can be steered through the network 378 using shortest path first routing between selected SR nodes. 380 5.4. SR Transit Nodes 382 An SR capable node that is addressed by the top most SID in the stack 383 when that is not the last SID in the stack (i.e., the S bit is not 384 set) is an SR transit node. When an SR transit node receives an 385 MPLS-SR-in-UDP packet that is addressed to it, it acts as follows: 387 o Perform TTL processing as normal for an IP packet. 389 o Determine that the packet is addressed to the local node. 391 o Find that the payload is UDP and that the destination port 392 indicates MPLS-in-UDP. 394 o Strip the IP and UDP headers. 396 o Pop the top label from the SID stack and retain it for use below. 398 o Encapsulate the packet in UDP with the destination port set to 399 6635 (or 6636 for DTLS) and the source port set for entropy. The 400 entropy value SHOULD be retained from the received UDP header or 401 MAY be freshly generated since this is a new UDP tunnel. 403 o Encapsulate the packet in IP with the IP source address set to 404 this transit router, and the destination address set to the 405 address corresponding to the next SID in the stack. 407 o Send the packet into the IP network routing the packet according 408 to the local FIB and applying hashing to resolve any ECMP choices. 410 5.5. Penultimate SR Transit Nodes 412 The penultimate SR transit node is an SR transit node as described in 413 Section 5.4 where the SID for the node is directly followed by the 414 final SID (i.e., that of domain egress node). When a penultimate SR 415 transit node receives an MPLS-SR-in-UDP packet that is addressed to 416 it, it acts according to whether penultimate hop popping (PHP) is 417 supported for the final SID. That information could be indicated 418 using the control plane as described in Section 8. It is worth 419 making some additional observations about PHP in SR: these are 420 collected in Section 6. 422 If PHP is allowed the penultimate SR transit node acts as follows: 424 o Perform TTL processing as normal for an IP packet. 426 o Determine that the packet is addressed to the local node. 428 o Find that the payload is UDP and that the destination port 429 indicates MPLS-in-UDP. 431 o Strip the IP and UDP headers. 433 o Pop the top label from the SID stack and retain it for use below. 435 o Pop the next label from the SID stack. 437 o Encapsulate the packet in UDP with the destination port set to 438 6635 (or 6636 for DTLS) and the source port set for entropy. The 439 entropy value SHOULD be retained from the received UDP header or 440 MAY be freshly generated since this is a new UDP tunnel. 442 o Encapsulate the packet in IP with the IP source address set to 443 this transit router, and the destination address set to the domain 444 egress node IP address corresponding to the label that was 445 previously popped from the stack. 447 o Send the packet into the IP network routing the packet according 448 to the local FIB and applying hashing to resolve any ECMP choices. 450 If PHP is not supported, the penultimate SR transit node just acts as 451 a normal SR transit node just as described in Section 5.4. However, 452 the penultimate SR transit node may be required to replace the final 453 SID with an MPLS-SR label stack entry carrying an explicit null label 454 value (0 for IPv4 and 2 for IPv6) before forwarding the packet. This 455 requirement may also be indicated by the control plane as described 456 in Section 8. 458 5.6. Domain Egress Nodes 460 The domain egress acts as follows: 462 o Perform TTL processing as normal for an IP packet. 464 o Determine that the packet is addressed to the local node. 466 o Find that the payload is UDP and that the destination port 467 indicates MPLS-in-UDP. 469 o Strip the IP and UDP headers. 471 o Pop the outermost SID if present (i.e., if PHP was not performed 472 as described in Section 5.5. 474 o Pop the explicit null label if it is present in the label stack as 475 requested by the domain egress and communicated in the control 476 plane as described in Section 8. 478 o Forward the payload packet according to its type and the local 479 routing/forwarding mechanisms. 481 6. A Note on Segment Routing Paths and Penultimate Hop Popping 483 End-to-end SR paths are comprised of multiple segments. The end 484 point of each segment is identified by a SID in the SID stack. 486 In normal SR processing a penultimate hop is the router that performs 487 SR routing immediately prior to the end of segment router. 488 Penultimate hop popping (PHP) is processing that applies at the 489 penultimate router in a segment. 491 With MPLS-SR-in-UDP encapsulation, each SR segment is achieved using 492 using an MPLS-in-UDP tunnel that runs the full length of the segment. 493 The SR SID stack on a packet is only examined at the head and tail of 494 this segment. Thus, each segment is effectively one hop long in the 495 SR overlay network and if there is any PHP processing it takes place 496 at the head-end of the segment. 498 However, in order to simplify processing at each MPLS-SR-in-UDP end 499 point, it is RECOMMENDED that PHP processing is only used for the 500 final segment in an SR path as described in Section 5.5. 502 7. Modes of Deployment 504 As previously noted, the procedures described in this document may be 505 used to connect islands of SR functionality across an IP backbone, or 506 can provide SR function within a native IP network. This section 507 briefly expounds upon those two deployment modes. 509 7.1. Interconnection of SR Domains 511 Figure 3 shows two SR domains interconnected by an IP network. The 512 procedures described in this document are deployed at border routers 513 R1 and R2 and packets are carried across the backbone network in a 514 UDP tunnel. 516 R1 acts as the domain ingress as described in Section 5.1. It takes 517 the MPLS-SR packet from the SR domain, pops the top label and uses it 518 to identify its peer border router R2. R1 then encapsulates the 519 packet in UDP in IP and sends it toward R2. 521 Routers within the IP network simply forward the packet using normal 522 IP routing. 524 R2 acts as a domain egress router as described in Section 5.6. It 525 receives a packet that is addressed to it, strips the IP and UDP 526 headers, and acts on the payload SR label stack to continue to route 527 the packet. 529 ________________________ 530 ______ ( ) ______ 531 ( ) ( IP Network ) ( ) 532 ( ) ( ) ( ) 533 ( -------- -------- ) 534 ( | Border | SR-in-UDP Tunnel | Border | ) 535 ( SR | Router |========================| Router | SR ) 536 ( | R1 | | R2 | ) 537 ( -------- -------- ) 538 ( ) ( ) ( ) 539 (______) ( ) (______) 540 (________________________) 542 Figure 3: SR in UDP to Tunnel Between SR Sites 544 7.2. SR Within an IP Network 546 Figure 4 shows the procedures defined in this document to provide SR 547 function across an IP network. 549 R1 receives a native packet and classifies it, determining that it 550 should be sent on the SR path R2-R3-R4-R5. It imposes a label stack 551 accordingly and then acts as a domain ingress as described in 552 Section 5.1. It pops the label for R2, and encapsulates the packet 553 in UDP in IP, sets the IP source to R1 and the IP destination to R2, 554 and sends the packet into the IP network. 556 Routers Ra and Rb are transit routers that simply forward the packets 557 using normal IP forwarding. They may be legacy transit routers (see 558 Section 5.2) or on-path pass-through SR nodes (see Section 5.3). 560 R2 is an SR transit nodes as described in Section 5.4. It receives a 561 packet addressed to it, strips the IP and UDP headers, and processes 562 the SR label stack. It pops the top label and uses it to identify 563 the next SR hop which is R3. R2 then encapsulates the packet in UDP 564 in IP setting the IP source to R2 and the IP destination to R3. 566 Rc, Rd, and Re are transit routers and perform as Ra and Rb. 568 R3 is an SR transit node and performs as R2. 570 R4 is a penultimate SR transit node as described in Section 5.5. It 571 receives a packet addressed to it, strips the IP and UDP headers, and 572 processes the SR label stack. It pops the top label and uses it to 573 identify the next SR hop which is R5. 575 R5 is the domain egress as described in Section 5.6. It receives a 576 packet addressed to it, strips the IP and UDP headers. 578 __________________________________ 579 __( IP Network )__ 580 __( )__ 581 ( -- -- -- ) 582 -------- -- -- |R2| -- |R3| -- |R4| -- -------- 583 | Ingress| |Ra| |Rb| | | |Rc| | | |Rd| | | |Re| | Egress | 584 --->| Router |===========| |======| |======| |======| Router |---> 585 | R1 | | | | | | | | | | | | | | | | | | R5 | 586 -------- -- -- | | -- | | -- | | -- -------- 587 (__ -- -- -- __) 588 (__ __) 589 (__________________________________) 591 Figure 4: SR Within an IP Network 593 8. Control Plane 595 This document is concerned with forwarding plane issues, and a 596 description of applicable control plane mechanisms is out of scope. 597 This section is provided only as a collection of references. No 598 changes to the control plane mechanisms for MPLS-SR are needed or 599 proposed. 601 A routers that is able to support SR can advertise the fact in the 602 IGP as follows: 604 o In IS-IS, by using the SR-Capabilities TLV as defined in 605 [I-D.ietf-isis-segment-routing-extensions] 607 o In OSPF/OSPFv3 by using the Router Information LSA as defined in 608 [I-D.ietf-ospf-segment-routing-extensions] and 609 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 611 Nodes can advertise SIDs using the mechanisms defined in 612 [I-D.ietf-isis-segment-routing-extensions], 613 [I-D.ietf-ospf-segment-routing-extensions], or 614 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 616 Support for PHP can be indicated in a SID advertisement using flags 617 in the advertisements as follows: 619 o For IS-IS, the N (no-PHP) flag in the Prefix-SID sub-TLV indicates 620 whether PHP is not to be used. 622 o For OSPF/OSPFv3, the NP (no-PHP) flag in the Prefix SID Sub-TLV 623 indicates whether PHP is not to be used. 625 The requirement to use an explicit null SID if PHP is not in use can 626 be indicated in SID advertisement using the Explicit-Null Flag 627 (E-Flag). If set, the penultimate SR transit node replaces the final 628 SID with a SID containing an Explicit-NULL value (0 for IPv4 and 2 629 for IPv6) before forwarding the packet. 631 The method of advertising the tunnel encapsulation capability of a 632 router using IS-IS or OSPF are specified in 633 [I-D.ietf-isis-encapsulation-cap] and 634 [I-D.ietf-ospf-encapsulation-cap] respectively. No changes to those 635 procedures are needed in support of this work. 637 9. OAM 639 OAM at the payload layer follows the normal OAM procedures for the 640 payload. To the payload the whole SR network looks like a tunnel. 642 OAM in the IP domain follows the normal IP procedures. This can only 643 be carried out between on the IP hops between pairs of SR nodes. 645 OAM between instruction processing entities i.e., at the SR layer 646 uses the procedures documented for MPLS. 648 10. Security Considerations 650 The security consideration of [I-D.ietf-spring-ipv6-use-cases] and 651 [RFC7510] apply. DTLS [RFC6347] SHOULD be used where security is 652 needed on an MPLS-SR-over-UDP segment. 654 It is difficult for an attacker to pass a raw MPLS encoded packet 655 into a network and operators have considerable experience at 656 excluding such packets at the network boundaries. 658 It is easy for an ingress node to detect any attempt to smuggle IP 659 packet into the network since it would see that the UDP destination 660 port was set to MPLS. SR packets not having a destination address 661 terminating in the network would be transparently carried and would 662 pose no security risk to the network under consideration. 664 11. IANA Considerations 666 This document makes no IANA requests. 668 12. Acknowledgements 670 This draft was partly inspired by 671 [I-D.xu-mpls-unified-source-routing-instruction], and we acknowledge 672 the following authors of version -02 of that draft: Robert Raszuk, 673 Uma Chunduri, Luis M. Contreras, Luay Jalil, Hamid Assarpour, Gunter 674 Van De Velde, Jeff Tantsura, and Shaowen Ma. 676 Thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, 677 Eric Rosen, Robert Raszuk, Wim Henderickx, Jim Guichard, and Gunter 678 Van De Velde for their insightful comments on this draft. 680 13. Contributors 682 o Mach Chen, Huawei Technologies, mach.chen@huawei.com 684 14. References 686 14.1. Normative References 688 [I-D.ietf-spring-segment-routing] 689 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 690 Litkowski, S., and R. Shakir, "Segment Routing 691 Architecture", draft-ietf-spring-segment-routing-13 (work 692 in progress), October 2017. 694 [I-D.ietf-spring-segment-routing-mpls] 695 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 696 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 697 data plane", draft-ietf-spring-segment-routing-mpls-10 698 (work in progress), June 2017. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, 702 DOI 10.17487/RFC2119, March 1997, 703 . 705 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 706 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 707 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 708 . 710 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 711 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 712 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 713 2009, . 715 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 716 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 717 January 2012, . 719 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 720 "Encapsulating MPLS in UDP", RFC 7510, 721 DOI 10.17487/RFC7510, April 2015, 722 . 724 14.2. Informative References 726 [I-D.ietf-6man-segment-routing-header] 727 Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., 728 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 729 Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, 730 T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, 731 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 732 segment-routing-header-07 (work in progress), July 2017. 734 [I-D.ietf-isis-encapsulation-cap] 735 Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, 736 L., and L. Jalil, "Advertising Tunnelling Capability in 737 IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in 738 progress), April 2017. 740 [I-D.ietf-isis-segment-routing-extensions] 741 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 742 Litkowski, S., Decraene, B., and j. jefftant@gmail.com, 743 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 744 segment-routing-extensions-13 (work in progress), June 745 2017. 747 [I-D.ietf-ospf-encapsulation-cap] 748 Xu, X., Decraene, B., Raszuk, R., Contreras, L., and L. 749 Jalil, "The Tunnel Encapsulations OSPF Router 750 Information", draft-ietf-ospf-encapsulation-cap-09 (work 751 in progress), October 2017. 753 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 754 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 755 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 756 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 757 segment-routing-extensions-10 (work in progress), 758 September 2017. 760 [I-D.ietf-ospf-segment-routing-extensions] 761 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 762 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 763 Extensions for Segment Routing", draft-ietf-ospf-segment- 764 routing-extensions-21 (work in progress), October 2017. 766 [I-D.ietf-spring-ipv6-use-cases] 767 Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and 768 M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- 769 ipv6-use-cases-11 (work in progress), June 2017. 771 [I-D.xu-mpls-unified-source-routing-instruction] 772 Xu, X., Bashandy, A., Assarpour, H., Ma, S., Henderickx, 773 W., and j. jefftant@gmail.com, "Unified Source Routing 774 Instructions using MPLS Label Stack", draft-xu-mpls- 775 unified-source-routing-instruction-04 (work in progress), 776 September 2017. 778 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 779 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 780 . 782 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 783 Edge-to-Edge (PWE3) Architecture", RFC 3985, 784 DOI 10.17487/RFC3985, March 2005, 785 . 787 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 788 "Encapsulating MPLS in IP or Generic Routing Encapsulation 789 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 790 . 792 Authors' Addresses 794 Stewart Bryant (editor) 795 Huawei 797 Email: stewart.bryant@gmail.com 798 Adrian Farrel (editor) 799 Juniper Networks 801 Email: afarrel@juniper.net 803 John Drake 804 Juniper Networks 806 Email: jdrake@juniper.net 808 Jeff Tantsura 809 Individual 811 Email: jefftant.ietf@gmail.com