idnits 2.17.1 draft-ietf-spring-nsh-sr-11.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2022) is 741 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: '0' on line 535 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING J. Guichard, Ed. 3 Internet-Draft Futurewei Technologies 4 Intended status: Standards Track J. Tantsura, Ed. 5 Expires: 21 October 2022 Microsoft 6 April 2022 8 Integration of Network Service Header (NSH) and Segment Routing for 9 Service Function Chaining (SFC) 10 draft-ietf-spring-nsh-sr-11 12 Abstract 14 This document describes the integration of the Network Service Header 15 (NSH) and Segment Routing (SR), as well as encapsulation details, to 16 support Service Function Chaining (SFC) in an efficient manner while 17 maintaining separation of the service and transport planes as 18 originally intended by the SFC architecture. 20 Combining these technologies allows SR to be used for steering 21 packets between Service Function Forwarders (SFF) along a given 22 Service Function Path (SFP) while NSH has the responsibility for 23 maintaining the integrity of the service plane, the SFC instance 24 context, and any associated metadata. 26 This integration demonstrates that NSH and SR can work cooperatively 27 and provide a network operator with the flexibility to use whichever 28 transport technology makes sense in specific areas of their network 29 infrastructure while still maintaining an end-to-end service plane 30 using NSH. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 3 October 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 67 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 69 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 70 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 71 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11 72 5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11 73 5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11 74 6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12 76 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 79 9. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 80 10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. Protocol Number for NSH . . . . . . . . . . . . . . . . 14 83 11.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15 84 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 13.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 91 1.1. SFC Overview and Rationale 93 The dynamic enforcement of a service-derived and adequate forwarding 94 policy for packets entering a network that supports advanced Service 95 Functions (SFs) has become a key challenge for network operators. 96 For instance, cascading SFs at the 3GPP (Third Generation Partnership 97 Project) Gi interface (N6 interface in 5G architecture) has shown 98 limitations such as 1) redundant classification features must be 99 supported by many SFs to execute their function, 2) some SFs receive 100 traffic that they are not supposed to process (e.g., TCP proxies 101 receiving UDP traffic) which inevitably affects their dimensioning 102 and performance, and 3) an increased design complexity related to the 103 properly ordered invocation of several SFs. 105 In order to solve those problems, and to decouple the services 106 topology from the underlying physical network while allowing for 107 simplified service delivery, Service Function Chaining (SFC) 108 techniques have been introduced [RFC7665]. 110 SFC techniques are meant to rationalize the service delivery logic 111 and master the resulting complexity while optimizing service 112 activation time cycles for operators that need more agile service 113 delivery procedures to better accommodate ever-demanding customer 114 requirements. SFC allows network operators to dynamically create 115 service planes that can be used by specific traffic flows. Each 116 service plane is realized by invoking and chaining the relevant 117 service functions in the right sequence. [RFC7498] provides an 118 overview of the overall SFC problem space and [RFC7665] specifies an 119 SFC data plane architecture. The SFC architecture does not make 120 assumptions on how advanced features (e.g., load-balancing, loose or 121 strict service paths) could be enabled within a domain. Various 122 deployment options are made available to operators with the SFC 123 architecture and this approach is fundamental to accommodate various 124 and heterogeneous deployment contexts. 126 Many approaches can be considered for encoding the information 127 required for SFC purposes (e.g., communicate a service chain pointer, 128 encode a list of loose/explicit paths, or disseminate a service chain 129 identifier together with a set of context information). Likewise, 130 many approaches can also be considered for the channel to be used to 131 carry SFC-specific information (e.g., define a new header, re-use 132 existing packet header fields, or define an IPv6 extension header). 133 Among all these approaches, the IETF created a transport-independent 134 SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic as 135 it does not require replicating the same specification effort as a 136 function of underlying transport encapsulation. Moreover, this 137 design approach encourages consistent SFC-based service delivery in 138 networks enabling distinct transport protocols in various network 139 segments or even between SFFs vs SF-SFF hops. 141 1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 147 as shown here. 149 2. SFC within Segment Routing Networks 151 As described in [RFC8402], SR leverages the source routing technique. 152 Concretely, a node steers a packet through an SR policy instantiated 153 as an ordered list of instructions called segments. While initially 154 designed for policy-based source routing, SR also finds its 155 application in supporting SFC 156 [I-D.ietf-spring-sr-service-programming]. 158 The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and 159 SRv6 [RFC8754], can both encode an SF as a segment so that an SFC can 160 be specified as a segment list. Nevertheless, and as discussed in 161 [RFC7498], traffic steering is only a subset of the issues that 162 motivated the design of the SFC architecture. Further considerations 163 such as simplifying classification at intermediate SFs and allowing 164 for coordinated behaviors among SFs by means of supplying context 165 information (a.k.a. metadata) should be considered when designing an 166 SFC data plane solution. 168 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work 169 independently, this document describes how the two can be used 170 together in concert and complement each other through two 171 representative application scenarios. Both application scenarios may 172 be supported using either SR-MPLS or SRv6: 174 * NSH-based SFC with SR-based transport plane: in this scenario SR- 175 MPLS or SRv6 provides the transport encapsulation between SFFs 176 while NSH is used to convey and trigger SFC policies. 178 * SR-based SFC with integrated NSH service plane: in this scenario 179 each service hop of the SFC is represented as a segment of the SR 180 segment-list. SR is thus responsible for steering traffic through 181 the necessary SFFs as part of the segment routing path while NSH 182 is responsible for maintaining the service plane and holding the 183 SFC instance context (including associated metadata). 185 It is of course possible to combine both of these two scenarios to 186 support specific deployment requirements and use cases. 188 A classifier MUST use an NSH Service Path Identifier (SPI) per SR 189 policy so that different traffic flows that use the same NSH Service 190 Function Path (SFP) but different SR policy can coexist on the same 191 SFP without conflict during SFF processing. 193 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel 195 Because of the transport-independent nature of NSH-based service 196 function chains, it is expected that the NSH has broad applicability 197 across different network domains (e.g., access, core). By way of 198 illustration the various SFs involved in a service function chain may 199 be available in a single data center, or spread throughout multiple 200 locations (e.g., data centers, different Points of Presence (POPs)), 201 depending upon the network operator preference and/or availability of 202 service resources. Regardless of where the SFs are deployed it is 203 necessary to provide traffic steering through a set of SFFs, and when 204 NSH and SR are integrated, this is provided by SR-MPLS or SRv6. 206 The following three figures provide an example of an SFC established 207 flow F that has SF instances located in different data centers, DC1 208 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 209 100 and the initial Service Index (SI) be 255. 211 Referring to Figure 1, packets of flow F in DC1 are classified into 212 an NSH-based SFC and encapsulated after classification as and forwarded to SFF1 214 (which is the first SFF hop for this service function chain). 216 After removing the outer transport encapsulation, SFF1 uses the SPI 217 and SI carried within the NSH encapsulation to determine that it 218 should forward the packet to SF1. SF1 applies its service, 219 decrements the SI by 1, and returns the packet to SFF1. SFF1 220 therefore has when the packet comes back from SF1. 221 SFF1 does a lookup on which results in and forwards the packet to DC1-GW1. 224 +--------------------------- DC1 ----------------------------+ 225 | +-----+ | 226 | | SF1 | | 227 | +--+--+ | 228 | | | 229 | | | 230 | +------------+ | +------------+ | 231 | | N(100,255) | | | N(100,254) | | 232 | +------------+ | +------------+ | 233 | | F:Inner Pkt| | | F:Inner Pkt| | 234 | +------------+ ^ | | +------------+ | 235 | (2) | | | (3) | 236 | | | v | 237 | (1) | (4) | 238 |+------------+ ----> +--+---+ ----> +---------+ | 239 || | NSH | | NSH | | | 240 || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | 241 || | | | | | | 242 |+------------+ +------+ +---------+ | 243 | | 244 | +------------+ +------------+ | 245 | | N(100,255) | | N(100,254) | | 246 | +------------+ +------------+ | 247 | | F:Inner Pkt| | F:Inner Pkt| | 248 | +------------+ +------------+ | 249 | | 250 +------------------------------------------------------------+ 252 Figure 1: SR for inter-DC SFC - Part 1 254 Referring now to Figure 2, DC1-GW1 performs a lookup using the 255 information conveyed in the NSH which results in . The SR encapsulation, which may be SR-MPLS or 257 SRv6, has the SR segment-list to forward the packet across the inter- 258 DC network to DC2. 260 +----------- Inter DC ----------------+ 261 (4) | (5) | 262 +------+ ----> | +---------+ ----> +---------+ | 263 | | NSH | | | SR | | | 264 + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | 265 | | | | | | | | 266 +------+ | +---------+ +---------+ | 267 | | 268 | +------------+ | 269 | | S(DC2-GW1) | | 270 | +------------+ | 271 | | N(100,254) | | 272 | +------------+ | 273 | | F:Inner Pkt| | 274 | +------------+ | 275 +-------------------------------------+ 277 Figure 2: SR for inter-DC SFC - Part 2 279 When the packet arrives at DC2, as shown in Figure 3, the SR 280 encapsulation is removed and DC2-GW1 performs a lookup on the NSH 281 which results in next hop: SFF2. When SFF2 receives the packet, it 282 performs a lookup on and determines to forward 283 the packet to SF2. SF2 applies its service, decrements the SI by 1, 284 and returns the packet to SFF2. SFF2 therefore has when the packet comes back from SF2. SFF2 does a lookup on 286 which results in the end of the service 287 function chain. 289 +------------------------ DC2 ----------------------+ 290 | +-----+ | 291 | | SF2 | | 292 | +--+--+ | 293 | | | 294 | | | 295 | +------------+ | +------------+ | 296 | | N(100,254) | | | N(100,253) | | 297 | +------------+ | +------------+ | 298 | | F:Inner Pkt| | | F:Inner Pkt| | 299 | +------------+ ^ | | +------------+ | 300 | (7) | | | (8) | 301 | | | v | 302 (5) | (6) | (9) | 303 +---------+ ---> | +----------+ ----> +--+---+ ----> | 304 | | SR | | | NSH | | IP | 305 + DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | 306 | | | | | | | | 307 +---------+ | +----------+ +------+ | 308 | | 309 | +------------+ +------------+ | 310 | | N(100,254) | | F:Inner Pkt| | 311 | +------------+ +------------+ | 312 | | F:Inner Pkt| | 313 | +------------+ | 314 +---------------------------------------------------+ 316 Figure 3: SR for inter-DC SFC - Part 3 318 The benefits of this scheme are listed hereafter: 320 * The network operator is able to take advantage of the transport- 321 independent nature of the NSH encapsulation, while the service is 322 provisioned end-to-end. 324 * The network operator is able to take advantage of the traffic 325 steering (traffic engineering) capability of SR where appropriate. 327 * Clear responsibility division and scope between NSH and SR. 329 Note that this scenario is applicable to any case where multiple 330 segments of a service function chain are distributed across multiple 331 domains or where traffic-engineered paths are necessary between SFFs 332 (strict forwarding paths for example). Further note that the above 333 example can also be implemented using end-to-end segment routing 334 between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the 335 packets based on segment routing instructions and are not looking at 336 the NSH header for forwarding.) 338 4. SR-based SFC with Integrated NSH Service Plane 340 In this scenario we assume that the SFs are NSH-aware and therefore 341 it should not be necessary to implement an SFC proxy to achieve SFC. 342 The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF 343 transport and NSH to provide the service plane between SFs thereby 344 maintaining SFC context (e.g., the service plane path referenced by 345 the SPI) and any associated metadata. 347 When a service function chain is established, a packet associated 348 with that chain will first carry an NSH that will be used to maintain 349 the end-to-end service plane through use of the SFC context. The SFC 350 context is used by an SFF to determine the SR segment list for 351 forwarding the packet to the next-hop SFFs. The packet is then 352 encapsulated using the SR header and forwarded in the SR domain 353 following normal SR operations. 355 When a packet has to be forwarded to an SF attached to an SFF, the 356 SFF performs a lookup on the segment identifier (SID) associated with 357 the SF. In the case of SR-MPLS this will be a prefix SID [RFC8402]. 358 In the case of SRv6, the behavior described within this document is 359 assigned the name END.NSH, and section 9.2 requests allocation of a 360 code point by IANA. The result of this lookup allows the SFF to 361 retrieve the next hop context between the SFF and SF (e.g., the 362 destination MAC address in case native Ethernet encapsulation is used 363 between SFF and SF). In addition the SFF strips the SR information 364 from the packet, updates the SR information, and saves it to a cache 365 indexed by the NSH Service Path Identifier (SPI) and the Service 366 Index (SI) decremented by 1. This saved SR information is used to 367 encapsulate and forward the packet(s) coming back from the SF. 369 The behavior of remembering the SR segment-list occurs at the end of 370 the regularly defined logic. The behavior of reattaching the 371 segment-list occurs before the SR process of forwarding the packet to 372 the next entry in the segment-list. Both behaviors are further 373 detailed in section 5. 375 When the SF receives the packet, it processes it as usual. When the 376 SF is co-resident with a classifier, the already processed packet may 377 be re-classified. The SF sends the packet back to the SFF. Once the 378 SFF receives this packet, it extracts the SR information using the 379 NSH SPI and SI as the index into the cache. The SFF then pushes the 380 retrieved SR header on top of the NSH header, and forwards the packet 381 to the next segment in the segment-list. The lookup in the SFF cache 382 might fail if re-classification at the SF changed the NSH SPI and/or 383 SI to values that do not exist in the SFF cache. In such a case, the 384 SFF must generate an error and drop the packet. 386 Figure 4 illustrates an example of this scenario. 388 +-----+ +-----+ 389 | SF1 | | SF2 | 390 +--+--+ +--+--+ 391 | | 392 | | 393 +-----------+ | +-----------+ +-----------+ | +-----------+ 394 |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | 395 +-----------+ | +-----------+ +-----------+ | +-----------+ 396 |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| 397 +-----------+ | +-----------+ +-----------+ | +-----------+ 398 (2) ^ | (3) | (5) ^ | (6) | 399 | | | | | | 400 | | | | | | 401 (1) | | v (4) | | v (7) 402 +------------+ ---> +-+----+ ----> +---+--+ --> 403 | | NSHoverSR | | NSHoverSR | | IP 404 | Classifier +-----------+ SFF1 +---------------------+ SFF2 | 405 | | | | | | 406 +------------+ +------+ +------+ 408 +------------+ +------------+ +------------+ 409 | S(SF1) | | S(SF2) | | F:Inner Pkt| 410 +------------+ +------------+ +------------+ 411 | S(SFF2) | | N(100,254) | 412 +------------+ +------------+ 413 | S(SF2) | | F:Inner Pkt| 414 +------------+ +------------+ 415 | N(100,255) | 416 +------------+ 417 | F:Inner Pkt| 418 +------------+ 420 Figure 4: NSH over SR for SFC 422 The benefits of this scheme include: 424 * It is economically sound for SF vendors to only support one 425 unified SFC solution. The SF is unaware of the SR. 427 * It simplifies the SFF (i.e., the SR router) by nullifying the 428 needs for re-classification and SR proxy. 430 * SR is also used for forwarding purposes including between SFFs. 432 * It takes advantage of SR to eliminate the NSH forwarding state in 433 SFFs. This applies each time strict or loose SFPs are in use. 435 * It requires no interworking as would be the case if SR-MPLS based 436 SFC and NSH-based SFC were deployed as independent mechanisms in 437 different parts of the network. 439 5. Packet Processing for SR-based SFC 441 This section describes the End.NSH behavior (SRv6), Prefix SID 442 behavior (SR-MPLS), and NSH processing logic. 444 5.1. SR-based SFC (SR-MPLS) Packet Processing 446 When an SFF receives a packet destined to S and S is a local prefix 447 SID associated with an SF, the SFF strips the SR segment-list (label 448 stack) from the packet, updates the SR information, and saves it to a 449 cache indexed by the NSH Service Path Identifier (SPI) and the 450 Service Index (SI) decremented by 1. This saved SR information is 451 used to re-encapsulate and forward the packet(s) coming back from the 452 SF. 454 5.2. SR-based SFC (SRv6) Packet Processing 456 This section describes the End.NSH behavior and NSH processing logic 457 for SRv6. The pseudo code is shown below. 459 When N receives a packet destined to S and S is a local End.NSH SID, 460 the processing is the same as that specified by [RFC8754] section 461 4.3.1.1, up through line S.15. 463 After S.15, if S is a local End.NSH SID, then: 465 S15.1. Remove and store IPv6 and SRH headers in local cache indexed 466 by 468 S15.2. Submit the packet to the NSH FIB lookup and transmit to the 469 destination associated with 470 Note: The End.NSH behavior interrupts the normal SRH packet 471 processing as described in [RFC8754] section 4.3.1.1, which does not 472 continue to S16 at this time. 474 When a packet is returned to the SFF from the SF, reattach the cached 475 IPv6 and SRH headers based on the from the NSH header. Then resume processing from [RFC8754] 477 section 4.3.1.1 with line S.16. 479 6. Encapsulation 481 6.1. NSH using SR-MPLS Transport 483 SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore 484 the segment routing header is a stack of MPLS labels. 486 When carrying NSH within an SR-MPLS transport, the full encapsulation 487 headers are as illustrated in Figure 5. 489 +------------------+ 490 ~ MPLS-SR Labels ~ 491 +------------------+ 492 | NSH Base Hdr | 493 +------------------+ 494 | Service Path Hdr | 495 +------------------+ 496 ~ Metadata ~ 497 +------------------+ 499 Figure 5: NSH using SR-MPLS Transport 501 As described in [RFC8402], the IGP signaling extension for IGP-Prefix 502 segment includes a flag to indicate whether directly connected 503 neighbors of the node on which the prefix is attached should perform 504 the NEXT operation or the CONTINUE operation when processing the SID. 505 When NSH is carried beneath SR-MPLS it is necessary to terminate the 506 NSH-based SFC at the tail-end node of the SR-MPLS label stack. This 507 can be achieved using either the NEXT or CONTINUE operation. 509 If the NEXT operation is to be used, then at the end of the SR-MPLS 510 path it is necessary to provide an indication to the tail-end that 511 NSH follows the SR-MPLS label stack as described by [RFC8596]. 513 If the CONTINUE operation is to be used, this is the equivalent of 514 MPLS Ultimate Hop Popping (UHP) and therefore it is necessary to 515 ensure that the penultimate hop node does not pop the top label of 516 the SR-MPLS label stack and thereby expose NSH to the wrong SFF. 517 This is realized by setting No-PHP flag in Prefix-SID Sub-TLV 518 [RFC8667], [RFC8665]. It is RECOMMENDED that a specific prefix-SID 519 be allocated at each node for use by the SFC application for this 520 purpose. 522 6.2. NSH using SRv6 Transport 524 When carrying NSH within an SRv6 transport the full encapsulation is 525 as illustrated in Figure 6. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Last Entry | Flags | Tag | S 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 534 | | g 535 | Segment List[0] (128 bits IPv6 address) | m 536 | | e 537 | | n 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 539 | | 540 | | R 541 ~ ... ~ o 542 | | u 543 | | t 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 545 | | n 546 | Segment List[n] (128 bits IPv6 address) | g 547 | | 548 | | S 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 550 // // H 551 // Optional Type Length Value objects (variable) // 552 // // 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 556 | Service Path Identifier | Service Index | S 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 558 | | 559 ~ Variable-Length Context Headers (opt.) ~ 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Figure 6: NSH using SRv6 Transport 564 Encapsulation of NSH following SRv6 is indicated by the IP protocol 565 number for NSH in the Next Header of the SRH. 567 7. Security Considerations 569 Generic SFC-related security considerations are discussed in 570 [RFC7665]. 572 NSH-specific security considerations are discussed in [RFC8300]. 574 Generic segment routing related security considerations are discussed 575 in section 7 of [RFC8754] and section 5 of [RFC8663]. 577 8. Backwards Compatibility 579 For SRv6/IPv6, if a processing node does not recognize NSH it should 580 follow the procedures described in section 4 of [RFC8200]. For SR- 581 MPLS, if a processing node does not recognize NSH it should follow 582 the procedures laid out in section 3.18 of [RFC3031]. 584 9. Caching Considerations 586 The cache mechanism must remove cached entries at an appropriate time 587 determined by the implementation. Further, an implementation MAY 588 allow network operators to set the said time value. In the case a 589 packet arriving from an SF does not have a matching cached entry, the 590 SFF SHOULD log this event. 592 10. MTU Considerations 594 Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it 595 is RECOMMENDED for network operators to increase the underlying MTU 596 so that SR/NSH traffic is forwarded within an SR domain without 597 fragmentation. 599 11. IANA Considerations 601 11.1. Protocol Number for NSH 602 IANA is requested to assign a protocol number TBA1 for the NSH from the 603 "Assigned Internet Protocol Numbers" registry available at 604 https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 606 +---------+---------+--------------+---------------+----------------+ 607 | Decimal | Keyword | Protocol | IPv6 | Reference | 608 | | | | Extension | | 609 | | | | Header | | 610 +---------+---------+--------------+---------------+----------------+ 611 | TBA1 | NSH | Network | N | [This Document]| 612 | | | Service | | | 613 | | | Header | | | 614 +---------+---------+--------------+---------------+----------------+ 616 11.2. SRv6 Endpoint Behavior for NSH 618 This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors" 619 sub-registry belonging to the top-level "Segment-routing with IPv6 data 620 plane (SRv6) Parameters" registry, the following allocations: 622 Value Description Reference 623 -------------------------------------------------------------- 624 TBA2 End.NSH - NSH Segment [This.ID] 626 12. Contributing Authors 627 The following co-authors, along with their respective affiliations at 628 the time of publication, provided valuable inputs and text contributions 629 to this document. 631 Mohamed Boucadair 632 Orange 633 mohamed.boucadair@orange.com 635 Joel Halpern 636 Ericsson 637 joel.halpern@ericsson.com 639 Syed Hassan 640 Cisco System, inc. 641 shassan@cisco.com 643 Wim Henderickx 644 Nokia 645 wim.henderickx@nokia.com 647 Haoyu Song 648 Futurewei Technologies 649 haoyu.song@futurewei.com 651 13. References 653 13.1. Normative References 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, 657 DOI 10.17487/RFC2119, March 1997, 658 . 660 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 661 Label Switching Architecture", RFC 3031, 662 DOI 10.17487/RFC3031, January 2001, 663 . 665 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 666 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 667 May 2017, . 669 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 670 (IPv6) Specification", STD 86, RFC 8200, 671 DOI 10.17487/RFC8200, July 2017, 672 . 674 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 675 "Network Service Header (NSH)", RFC 8300, 676 DOI 10.17487/RFC8300, January 2018, 677 . 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, . 684 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 685 Decraene, B., Litkowski, S., and R. Shakir, "Segment 686 Routing with the MPLS Data Plane", RFC 8660, 687 DOI 10.17487/RFC8660, December 2019, 688 . 690 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 691 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 692 DOI 10.17487/RFC8663, December 2019, 693 . 695 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 696 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 697 Extensions for Segment Routing", RFC 8665, 698 DOI 10.17487/RFC8665, December 2019, 699 . 701 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 702 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 703 Extensions for Segment Routing", RFC 8667, 704 DOI 10.17487/RFC8667, December 2019, 705 . 707 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 708 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 709 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 710 . 712 13.2. Informative References 714 [I-D.ietf-spring-sr-service-programming] 715 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 716 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 717 S. Salsano, "Service Programming with Segment Routing", 718 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 719 service-programming-05, 10 September 2021, 720 . 723 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 724 Service Function Chaining", RFC 7498, 725 DOI 10.17487/RFC7498, April 2015, 726 . 728 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 729 Chaining (SFC) Architecture", RFC 7665, 730 DOI 10.17487/RFC7665, October 2015, 731 . 733 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 734 "MPLS Transport Encapsulation for the Service Function 735 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 736 DOI 10.17487/RFC8596, June 2019, 737 . 739 Authors' Addresses 741 James N Guichard (editor) 742 Futurewei Technologies 743 2330 Central Express Way 744 Santa Clara, 745 United States of America 746 Email: james.n.guichard@futurewei.com 748 Jeff Tantsura (editor) 749 Microsoft 750 United States of America 751 Email: jefftant.ietf@gmail.com