idnits 2.17.1 draft-ietf-spring-nsh-sr-09.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 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 (July 26, 2021) is 998 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 537 == Missing Reference: 'ThisDocument' is mentioned on line 614, but not defined == Unused Reference: 'RFC6347' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC8086' is defined on line 677, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8596 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 Summary: 4 errors (**), 0 flaws (~~), 6 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: January 27, 2022 Microsoft 6 July 26, 2021 8 Integration of Network Service Header (NSH) and Segment Routing for 9 Service Function Chaining (SFC) 10 draft-ietf-spring-nsh-sr-09 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 January 27, 2022. 49 Copyright Notice 51 Copyright (c) 2021 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 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 68 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4 70 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5 71 4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 72 5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11 73 5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11 74 5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11 75 6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12 77 6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 80 9. Caching Considerations . . . . . . . . . . . . . . . . . . . 14 81 10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 11.1. Protocol Number for NSH . . . . . . . . . . . . . . . . 14 84 11.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15 85 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 88 13.2. Informative References . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 92 1.1. SFC Overview and Rationale 94 The dynamic enforcement of a service-derived and adequate forwarding 95 policy for packets entering a network that supports advanced Service 96 Functions (SFs) has become a key challenge for network operators. 97 For instance, cascading SFs at the 3GPP (Third Generation Partnership 98 Project) Gi interface (N6 interface in 5G architecture) has shown 99 limitations such as 1) redundant classification features must be 100 supported by many SFs to execute their function, 2) some SFs receive 101 traffic that they are not supposed to process (e.g., TCP proxies 102 receiving UDP traffic) which inevitably affects their dimensioning 103 and performance, and 3) an increased design complexity related to the 104 properly ordered invocation of several SFs. 106 In order to solve those problems, and to decouple the services 107 topology from the underlying physical network while allowing for 108 simplified service delivery, Service Function Chaining (SFC) 109 techniques have been introduced [RFC7665]. 111 SFC techniques are meant to rationalize the service delivery logic 112 and master the resulting complexity while optimizing service 113 activation time cycles for operators that need more agile service 114 delivery procedures to better accommodate ever-demanding customer 115 requirements. SFC allows network operators to dynamically create 116 service planes that can be used by specific traffic flows. Each 117 service plane is realized by invoking and chaining the relevant 118 service functions in the right sequence. [RFC7498] provides an 119 overview of the overall SFC problem space and [RFC7665] specifies an 120 SFC data plane architecture. The SFC architecture does not make 121 assumptions on how advanced features (e.g., load-balancing, loose or 122 strict service paths) could be enabled within a domain. Various 123 deployment options are made available to operators with the SFC 124 architecture and this approach is fundamental to accommodate various 125 and heterogeneous deployment contexts. 127 Many approaches can be considered for encoding the information 128 required for SFC purposes (e.g., communicate a service chain pointer, 129 encode a list of loose/explicit paths, or disseminate a service chain 130 identifier together with a set of context information). Likewise, 131 many approaches can also be considered for the channel to be used to 132 carry SFC-specific information (e.g., define a new header, re-use 133 existing packet header fields, or define an IPv6 extension header). 134 Among all these approaches, the IETF created a transport-independent 135 SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic as 136 it does not require replicating the same specification effort as a 137 function of underlying transport encapsulation. Moreover, this 138 design approach encourages consistent SFC-based service delivery in 139 networks enabling distinct transport protocols in various network 140 segments or even between SFFs vs SF-SFF hops. 142 1.2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 148 as shown here. 150 2. SFC within Segment Routing Networks 152 As described in [RFC8402], SR leverages the source routing technique. 153 Concretely, a node steers a packet through an SR policy instantiated 154 as an ordered list of instructions called segments. While initially 155 designed for policy-based source routing, SR also finds its 156 application in supporting SFC 157 [I-D.ietf-spring-sr-service-programming]. 159 The two SR data plane encapsulations, namely SR-MPLS [RFC8660] and 160 SRv6 [RFC8754], can both encode an SF as a segment so that an SFC can 161 be specified as a segment list. Nevertheless, and as discussed in 162 [RFC7498], traffic steering is only a subset of the issues that 163 motivated the design of the SFC architecture. Further considerations 164 such as simplifying classification at intermediate SFs and allowing 165 for coordinated behaviors among SFs by means of supplying context 166 information (a.k.a. metadata) should be considered when designing an 167 SFC data plane solution. 169 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work 170 independently, this document describes how the two can be used 171 together in concert and complement each other through two 172 representative application scenarios. Both application scenarios may 173 be supported using either SR-MPLS or SRv6: 175 o NSH-based SFC with SR-based transport plane: in this scenario SR- 176 MPLS or SRv6 provides the transport encapsulation between SFFs 177 while NSH is used to convey and trigger SFC policies. 179 o SR-based SFC with integrated NSH service plane: in this scenario 180 each service hop of the SFC is represented as a segment of the SR 181 segment-list. SR is thus responsible for steering traffic through 182 the necessary SFFs as part of the segment routing path while NSH 183 is responsible for maintaining the service plane and holding the 184 SFC instance context (including associated metadata). 186 It is of course possible to combine both of these two scenarios to 187 support specific deployment requirements and use cases. 189 A classifier MUST assign an NSH Service Path Identifier (SPI) per SR 190 policy so that different traffic flows that use the same NSH Service 191 Function Path (SFP) but different SR policy can coexist on the same 192 SFP without conflict during SFF processing. 194 3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel 196 Because of the transport-independent nature of NSH-based service 197 function chains, it is expected that the NSH has broad applicability 198 across different network domains (e.g., access, core). By way of 199 illustration the various SFs involved in a service function chain may 200 be available in a single data center, or spread throughout multiple 201 locations (e.g., data centers, different Points of Presense (POPs)), 202 depending upon the network operator preference and/or availability of 203 service resources. Regardless of where the SFs are deployed it is 204 necessary to provide traffic steering through a set of SFFs, and when 205 NSH and SR are integrated, this is provided by SR-MPLS or SRv6. 207 The following three figures provide an example of an SFC established 208 flow F that has SF instances located in different data centers, DC1 209 and DC2. For the purpose of illustration, let the SFC's NSH SPI be 210 100 and the initial Service Index (SI) be 255. 212 Referring to Figure 1, packets of flow F in DC1 are classified into 213 an NSH-based SFC and encapsulated after classification as and forwarded to SFF1 215 (which is the first SFF hop for this service function chain). 217 After removing the outer transport encapsulation, SFF1 uses the SPI 218 and SI carried within the NSH encapsulation to determine that it 219 should forward the packet to SF1. SF1 applies its service, 220 decrements the SI by 1, and returns the packet to SFF1. SFF1 221 therefore has when the packet comes back from SF1. 222 SFF1 does a lookup on which results in and forwards the packet to DC1-GW1. 225 +--------------------------- DC1 ----------------------------+ 226 | +-----+ | 227 | | SF1 | | 228 | +--+--+ | 229 | | | 230 | | | 231 | +------------+ | +------------+ | 232 | | N(100,255) | | | N(100,254) | | 233 | +------------+ | +------------+ | 234 | | F:Inner Pkt| | | F:Inner Pkt| | 235 | +------------+ ^ | | +------------+ | 236 | (2) | | | (3) | 237 | | | v | 238 | (1) | (4) | 239 |+------------+ ----> +--+---+ ----> +---------+ | 240 || | NSH | | NSH | | | 241 || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | 242 || | | | | | | 243 |+------------+ +------+ +---------+ | 244 | | 245 | +------------+ +------------+ | 246 | | N(100,255) | | N(100,254) | | 247 | +------------+ +------------+ | 248 | | F:Inner Pkt| | F:Inner Pkt| | 249 | +------------+ +------------+ | 250 | | 251 +------------------------------------------------------------+ 253 Figure 1: SR for inter-DC SFC - Part 1 255 Referring now to Figure 2, DC1-GW1 performs a lookup using the 256 information conveyed in the NSH which results in . The SR encapsulation, which may be SR-MPLS or 258 SRv6, has the SR segment-list to forward the packet across the inter- 259 DC network to DC2. 261 +----------- Inter DC ----------------+ 262 (4) | (5) | 263 +------+ ----> | +---------+ ----> +---------+ | 264 | | NSH | | | SR | | | 265 + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | 266 | | | | | | | | 267 +------+ | +---------+ +---------+ | 268 | | 269 | +------------+ | 270 | | S(DC2-GW1) | | 271 | +------------+ | 272 | | N(100,254) | | 273 | +------------+ | 274 | | F:Inner Pkt| | 275 | +------------+ | 276 +-------------------------------------+ 278 Figure 2: SR for inter-DC SFC - Part 2 280 When the packet arrives at DC2, as shown in Figure 3, the SR 281 encapsulation is removed and DC2-GW1 performs a lookup on the NSH 282 which results in next hop: SFF2. When SFF2 receives the packet, it 283 performs a lookup on and determines to forward 284 the packet to SF2. SF2 applies its service, decrements the SI by 1, 285 and returns the packet to SFF2. SFF2 therefore has when the packet comes back from SF2. SFF2 does a lookup on 287 which results in the end of the service 288 function chain. 290 +------------------------ DC2 ----------------------+ 291 | +-----+ | 292 | | SF2 | | 293 | +--+--+ | 294 | | | 295 | | | 296 | +------------+ | +------------+ | 297 | | N(100,254) | | | N(100,253) | | 298 | +------------+ | +------------+ | 299 | | F:Inner Pkt| | | F:Inner Pkt| | 300 | +------------+ ^ | | +------------+ | 301 | (7) | | | (8) | 302 | | | v | 303 (5) | (6) | (9) | 304 +---------+ ---> | +----------+ ----> +--+---+ ----> | 305 | | SR | | | NSH | | IP | 306 + DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | | 307 | | | | | | | | 308 +---------+ | +----------+ +------+ | 309 | | 310 | +------------+ +------------+ | 311 | | N(100,254) | | F:Inner Pkt| | 312 | +------------+ +------------+ | 313 | | F:Inner Pkt| | 314 | +------------+ | 315 +---------------------------------------------------+ 317 Figure 3: SR for inter-DC SFC - Part 3 319 The benefits of this scheme are listed hereafter: 321 o The network operator is able to take advantage of the transport- 322 independent nature of the NSH encapsulation, while the service is 323 provisioned end-to-end. 325 o The network operator is able to take advantage of the traffic 326 steering (traffic engineering) capability of SR where appropriate. 328 o Clear responsibility division and scope between NSH and SR. 330 Note that this scenario is applicable to any case where multiple 331 segments of a service function chain are distributed across multiple 332 domains or where traffic-engineered paths are necessary between SFFs 333 (strict forwarding paths for example). Further note that the above 334 example can also be implemented using end-to-end segment routing 335 between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the 336 packets based on segment routing instructions and are not looking at 337 the NSH header for forwarding.) 339 4. SR-based SFC with Integrated NSH Service Plane 341 In this scenario we assume that the SFs are NSH-aware and therefore 342 it should not be necessary to implement an SFC proxy to achieve SFC. 343 The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF 344 transport and NSH to provide the service plane between SFs thereby 345 maintaining SFC context (e.g., the service plane path referenced by 346 the SPI) and any associated metadata. 348 When a service function chain is established, a packet associated 349 with that chain will first carry an NSH that will be used to maintain 350 the end-to-end service plane through use of the SFC context. The SFC 351 context is used by an SFF to determine the SR segment list for 352 forwarding the packet to the next-hop SFFs. The packet is then 353 encapsulated using the SR header and forwarded in the SR domain 354 following normal SR operations. 356 When a packet has to be forwarded to an SF attached to an SFF, the 357 SFF performs a lookup on the segment identifier (SID) associated with 358 the SF. In the case of SR-MPLS this will be a prefix SID [RFC8402]. 359 In the case of SRv6, the behavior described within this document is 360 assigned the name END.NSH, and section 9.2 requests allocation of a 361 code point by IANA. The result of this lookup allows the SFF to 362 retrieve the next hop context between the SFF and SF (e.g., the 363 destination MAC address in case native Ethernet encapsulation is used 364 between SFF and SF). In addition the SFF strips the SR information 365 from the packet, updates the SR information, and saves it to a cache 366 indexed by the NSH Service Path Identifier (SPI) and the Service 367 Index (SI) decremented by 1. This saved SR information is used to 368 encapsulate and forward the packet(s) coming back from the SF. 370 The behavior of remembering the SR segment-list occurs at the end of 371 the regularly defined logic. The behavior of reattaching the 372 segment-list occurs before the SR process of forwarding the packet to 373 the next entry in the segment-list. Both behaviors are further 374 detailed in section 5. 376 When the SF receives the packet, it processes it as usual. When the 377 SF is co-resident with a classifier, the already processed packet may 378 be re-classified. The SF sends the packet back to the SFF. Once the 379 SFF receives this packet, it extracts the SR information using the 380 NSH SPI and SI as the index into the cache. The SFF then pushes the 381 retrieved SR header on top of the NSH header, and forwards the packet 382 to the next segment in the segment-list. The lookup in the SFF cache 383 might fail if re-classification at the SF changed the NSH SPI and/or 384 SI to values that do not exist in the SFF cache. In such a case, the 385 SFF must generate an error and drop the packet. 387 Figure 4 illustrates an example of this scenario. 389 +-----+ +-----+ 390 | SF1 | | SF2 | 391 +--+--+ +--+--+ 392 | | 393 | | 394 +-----------+ | +-----------+ +-----------+ | +-----------+ 395 |N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) | 396 +-----------+ | +-----------+ +-----------+ | +-----------+ 397 |F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt| 398 +-----------+ | +-----------+ +-----------+ | +-----------+ 399 (2) ^ | (3) | (5) ^ | (6) | 400 | | | | | | 401 | | | | | | 402 (1) | | v (4) | | v (7) 403 +------------+ ---> +-+----+ ----> +---+--+ --> 404 | | NSHoverSR | | NSHoverSR | | IP 405 | Classifier +-----------+ SFF1 +---------------------+ SFF2 | 406 | | | | | | 407 +------------+ +------+ +------+ 409 +------------+ +------------+ +------------+ 410 | S(SF1) | | S(SF2) | | F:Inner Pkt| 411 +------------+ +------------+ +------------+ 412 | S(SFF2) | | N(100,254) | 413 +------------+ +------------+ 414 | S(SF2) | | F:Inner Pkt| 415 +------------+ +------------+ 416 | N(100,255) | 417 +------------+ 418 | F:Inner Pkt| 419 +------------+ 421 Figure 4: NSH over SR for SFC 423 The benefits of this scheme include: 425 o It is economically sound for SF vendors to only support one 426 unified SFC solution. The SF is unaware of the SR. 428 o It simplifies the SFF (i.e., the SR router) by nullifying the 429 needs for re-classification and SR proxy. 431 o SR is also used for forwarding purposes including between SFFs. 433 o It takes advantage of SR to eliminate the NSH forwarding state in 434 SFFs. This applies each time strict or loose SFPs are in use. 436 o It requires no interworking as would be the case if SR-MPLS based 437 SFC and NSH-based SFC were deployed as independent mechanisms in 438 different parts of the network. 440 5. Packet Processing for SR-based SFC 442 This section describes the End.NSH behavior (SRv6), Prefix SID 443 behavior (SR-MPLS), and NSH processing logic. 445 5.1. SR-based SFC (SR-MPLS) Packet Processing 447 When an SFF receives a packet destined to S and S is a local prefix 448 SID associated with an SF, the SFF strips the SR segment-list (label 449 stack) from the packet, updates the SR information, and saves it to a 450 cache indexed by the NSH Service Path Identifier (SPI) and the 451 Service Index (SI) decremented by 1. This saved SR information is 452 used to re-encapsulate and forward the packet(s) coming back from the 453 SF. 455 5.2. SR-based SFC (SRv6) Packet Processing 457 This section describes the End.NSH behavior and NSH processing logic 458 for SRv6. The pseudo code is shown below. 460 When N receives a packet destined to S and S is a local End.NSH SID, 461 the processing is the same as that specified by [RFC8754] section 462 4.3.1.1, up through line S.16. 464 After S.15, if S is a local End.NSH SID, then: 466 S15.1. Remove and store IPv6 and SRH headers in local cache indexed 467 by 469 S15.2. Submit the packet to the NSH FIB lookup and transmit to the 470 destination associated with 472 Note: The End.NSH behavior interrupts the normal SRH packet 473 processing as described in [RFC8754] section 4.3.1.1, which does not 474 continue to S16 at this time. 476 When a packet is returned to the SFF from the SF, reattach the cached 477 IPv6 and SRH headers based on the from the NSH header. Then resume processing from [RFC8754] 479 section 4.3.1.1 with line S.16. 481 6. Encapsulation 483 6.1. NSH using SR-MPLS Transport 485 SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore 486 the segment routing header is a stack of MPLS labels. 488 When carrying NSH within an SR-MPLS transport, the full encapsulation 489 headers are as illustrated in Figure 5. 491 +------------------+ 492 ~ MPLS-SR Labels ~ 493 +------------------+ 494 | NSH Base Hdr | 495 +------------------+ 496 | Service Path Hdr | 497 +------------------+ 498 ~ Metadata ~ 499 +------------------+ 501 Figure 5: NSH using SR-MPLS Transport 503 As described in [RFC8402], the IGP signaling extension for IGP-Prefix 504 segment includes a flag to indicate whether directly connected 505 neighbors of the node on which the prefix is attached should perform 506 the NEXT operation or the CONTINUE operation when processing the SID. 507 When NSH is carried beneath SR-MPLS it is necessary to terminate the 508 NSH-based SFC at the tail-end node of the SR-MPLS label stack. This 509 can be achieved using either the NEXT or CONTINUE operation. 511 If the NEXT operation is to be used, then at the end of the SR-MPLS 512 path it is necessary to provide an indication to the tail-end that 513 NSH follows the SR-MPLS label stack as described by [RFC8596]. 515 If the CONTINUE operation is to be used, this is the equivalent of 516 MPLS Ultimate Hop Popping (UHP) and therefore it is necessary to 517 ensure that the penultimate hop node does not pop the top label of 518 the SR-MPLS label stack and thereby expose NSH to the wrong SFF. 519 This is realized by setting No-PHP flag in Prefix-SID Sub-TLV 520 [RFC8667], [RFC8665]. It is RECOMMENDED that a specific prefix-SID 521 be allocated at each node for use by the SFC application for this 522 purpose. 524 6.2. NSH using SRv6 Transport 526 When carrying NSH within an SRv6 transport the full encapsulation is 527 as illustrated in Figure 6. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Last Entry | Flags | Tag | S 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 536 | | g 537 | Segment List[0] (128 bits IPv6 address) | m 538 | | e 539 | | n 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 541 | | 542 | | R 543 ~ ... ~ o 544 | | u 545 | | t 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 547 | | n 548 | Segment List[n] (128 bits IPv6 address) | g 549 | | 550 | | S 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 552 // // H 553 // Optional Type Length Value objects (variable) // 554 // // 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 558 | Service Path Identifier | Service Index | S 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 560 | | 561 ~ Variable-Length Context Headers (opt.) ~ 562 | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 6: NSH using SRv6 Transport 567 Encapsulation of NSH following SRv6 is indicated by the IP protocol 568 number for NSH in the Next Header of the SRH. 570 7. Security Considerations 572 Generic SFC-related security considerations are discussed in 573 [RFC7665]. 575 NSH-specific security considerations are discussed in [RFC8300]. 577 Generic segment routing related security considerations are discussed 578 in section 7 of [RFC8754] and section 5 of [RFC8663]. 580 8. Backwards Compatibility 582 For SRv6/IPv6, if a processing node does not recognize NSH it should 583 follow the procedures described in section 4 of [RFC8200]. For SR- 584 MPLS, if a processing node does not recognize NSH it should follow 585 the procedures laid out in section 3.18 of [RFC3031]. 587 9. Caching Considerations 589 The cache mechanism must remove cached entries at an appropriate time 590 determined by the implementation. Further, an implementation MAY 591 allow network operators to set the said time value. In the case a 592 packet arriving from an SF does not have a matching cached entry, the 593 SFF SHOULD log this event. 595 10. MTU Considerations 597 Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it 598 is RECOMMENDED for network operators to increase the underlying MTU 599 so that SR/NSH traffic is forwarded within an SR domain without 600 fragmentation. 602 11. IANA Considerations 604 11.1. Protocol Number for NSH 605 IANA is requested to assign a protocol number TBA1 for the NSH from the 606 "Assigned Internet Protocol Numbers" registry available at 607 https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml 609 +---------+---------+--------------+---------------+----------------+ 610 | Decimal | Keyword | Protocol | IPv6 | Reference | 611 | | | | Extension | | 612 | | | | Header | | 613 +---------+---------+--------------+---------------+----------------+ 614 | TBA1 | NSH | Network | N | [ThisDocument] | 615 | | | Service | | | 616 | | | Header | | | 617 +---------+---------+--------------+---------------+----------------+ 619 11.2. SRv6 Endpoint Behavior for NSH 621 This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors" 622 sub-registry belonging to the top-level "Segment-routing with IPv6 data 623 plane (SRv6) Parameters" registry, the following allocations: 625 Value Description Reference 626 -------------------------------------------------------------- 627 TBA2 End.NSH - NSH Segment [This.ID] 629 12. Contributing Authors 630 The following co-authors, along with their respective affiliations at 631 the time of publication, provided valuable inputs and text contributions 632 to this document. 634 Mohamed Boucadair 635 Orange 636 mohamed.boucadair@orange.com 638 Joel Halpern 639 Ericsson 640 joel.halpern@ericsson.com 642 Syed Hassan 643 Cisco System, inc. 644 shassan@cisco.com 646 Wim Henderickx 647 Nokia 648 wim.henderickx@nokia.com 650 Haoyu Song 651 Futurewei Technologies 652 haoyu.song@futurewei.com 654 13. References 656 13.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, 660 DOI 10.17487/RFC2119, March 1997, 661 . 663 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 664 Label Switching Architecture", RFC 3031, 665 DOI 10.17487/RFC3031, January 2001, 666 . 668 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 669 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 670 January 2012, . 672 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 673 Chaining (SFC) Architecture", RFC 7665, 674 DOI 10.17487/RFC7665, October 2015, 675 . 677 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 678 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 679 March 2017, . 681 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 682 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 683 May 2017, . 685 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 686 (IPv6) Specification", STD 86, RFC 8200, 687 DOI 10.17487/RFC8200, July 2017, 688 . 690 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 691 "Network Service Header (NSH)", RFC 8300, 692 DOI 10.17487/RFC8300, January 2018, 693 . 695 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 696 Decraene, B., Litkowski, S., and R. Shakir, "Segment 697 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 698 July 2018, . 700 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 701 "MPLS Transport Encapsulation for the Service Function 702 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 703 DOI 10.17487/RFC8596, June 2019, 704 . 706 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 707 Decraene, B., Litkowski, S., and R. Shakir, "Segment 708 Routing with the MPLS Data Plane", RFC 8660, 709 DOI 10.17487/RFC8660, December 2019, 710 . 712 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 713 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 714 DOI 10.17487/RFC8663, December 2019, 715 . 717 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 718 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 719 Extensions for Segment Routing", RFC 8665, 720 DOI 10.17487/RFC8665, December 2019, 721 . 723 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 724 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 725 Extensions for Segment Routing", RFC 8667, 726 DOI 10.17487/RFC8667, December 2019, 727 . 729 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 730 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 731 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 732 . 734 13.2. Informative References 736 [I-D.ietf-spring-sr-service-programming] 737 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 738 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 739 Henderickx, W., and S. Salsano, "Service Programming with 740 Segment Routing", draft-ietf-spring-sr-service- 741 programming-03 (work in progress), September 2020. 743 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 744 Service Function Chaining", RFC 7498, 745 DOI 10.17487/RFC7498, April 2015, 746 . 748 Authors' Addresses 750 James N Guichard (editor) 751 Futurewei Technologies 752 2330 Central Express Way 753 Santa Clara 754 USA 756 Email: james.n.guichard@futurewei.com 758 Jeff Tantsura (editor) 759 Microsoft 760 USA 762 Email: jefftant.ietf@gmail.com