idnits 2.17.1 draft-ietf-spring-nsh-sr-02.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 4 instances of too long lines in the document, the longest one being 82 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2020) is 1478 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 503 == Missing Reference: 'ThisDocument' is mentioned on line 587, but not defined == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 647, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-12 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-09 Summary: 3 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 H. Song 4 Intended status: Standards Track Futurewei Technologies 5 Expires: October 8, 2020 J. Tantsura 6 Apstra inc. 7 J. Halpern 8 Ericsson 9 W. Henderickx 10 Nokia 11 M. Boucadair 12 Orange 13 S. Hassan 14 Cisco Systems 15 April 6, 2020 17 Network Service Header (NSH) and Segment Routing Integration for Service 18 Function Chaining (SFC) 19 draft-ietf-spring-nsh-sr-02 21 Abstract 23 This document describes two application scenarios where Network 24 Service Header (NSH) and Segment Routing (SR) techniques can be 25 deployed together to support Service Function Chaining (SFC) in an 26 efficient manner while maintaining separation of the service and 27 transport planes as originally intended by the SFC architecture. 29 In the first scenario, an NSH-based SFC is created using SR as the 30 transport between Service Function Forwarders (SFFs). SR in this 31 case is just one of many encapsulations that could be used to 32 maintain the transport-independent nature of NSH-based service 33 chains. 35 In the second scenario, SR is used to represent each service hop of 36 the NSH-based SFC as a segment within the segment-list. SR and NSH 37 in this case are integrated. 39 In both scenarios SR is responsible for steering packets between SFFs 40 along a given Service Function Path (SFP) while NSH is responsible 41 for maintaining the integrity of the service plane, the SFC instance 42 context, and any associated metadata. 44 These application scenarios demonstrate that NSH and SR can work 45 jointly and complement each other leaving the network operator with 46 the flexibility to use whichever transport technology makes sense in 47 specific areas of their network infrastructure, and still maintain an 48 end-to-end service plane using NSH. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on October 8, 2020. 67 Copyright Notice 69 Copyright (c) 2020 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (https://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3 86 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 87 1.3. SFC within SR Networks . . . . . . . . . . . . . . . . . 4 88 2. NSH-based SFC with SR-based Transport Tunnel . . . . . . . . 5 89 3. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9 90 4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11 91 4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11 92 4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13 96 6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 8.2. Informative References . . . . . . . . . . . . . . . . . 15 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 1.1. SFC Overview and Rationale 107 The dynamic enforcement of a service-derived, adequate forwarding 108 policy for packets entering a network that supports advanced Service 109 Functions (SFs) has become a key challenge for network operators. 110 Particularly, cascading SFs, for example at the Gi interface in the 111 context of mobile network infrastructure, have shown their limits, 112 such as the same redundant classification features must be supported 113 by many SFs in order to execute their function, some SFs are 114 receiving traffic that they are not supposed to process (e.g., TCP 115 proxies receiving UDP traffic), which inevitably affects their 116 dimensioning and performance, an increased design complexity related 117 to the properly ordered invocation of several SFs, etc. 119 In order to solve those problems and to avoid the adherence with the 120 underlying physical network topology while allowing for simplified 121 service delivery, Service Function Chaining (SFC) techniques have 122 been introduced. 124 SFC techniques are meant to rationalize the service delivery logic 125 and master the companion complexity while optimizing service 126 activation time cycles for operators that need more agile service 127 delivery procedures to better accommodate ever-demanding customer 128 requirements. Indeed, SFC allows to dynamically create service 129 planes that can be used by specific traffic flows. Each service 130 plane is realized by invoking and chaining the relevant service 131 functions in the right sequence. [RFC7498] provides an overview of 132 the SFC problem space and [RFC7665] specifies an SFC architecture. 133 The SFC architecture has the merit to not make assumptions on how 134 advanced features (e.g., load-balancing, loose or strict service 135 paths) have to be enabled with a domain. Various deployment options 136 are made available to operators with the SFC architecture and this 137 approach is fundamental to accommodate various and heterogeneous 138 deployment contexts. 140 Many approaches can be considered for encoding the information 141 required for SFC purposes (e.g., communicate a service chain pointer, 142 encode a list of loose/explicit paths, disseminate a service chain 143 identifier together with a set of context information, etc.). 144 Likewise, many approaches can also be considered for the channel to 145 be used to carry SFC-specific information (e.g., define a new header, 146 re-use existing fields, define an IPv6 extension header, etc.). 147 Among all these approaches, the IETF endorsed a transport-independent 148 SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC 149 encapsulation solution. This design is pragmatic as it does not 150 require replicating the same specification effort as a function of 151 underlying transport encapsulation. Moreover, this design approach 152 encourages consistent SFC-based service delivery in networks enabling 153 distinct transport protocols in various segments of the network or 154 even between SFFs vs SF-SFF hops. 156 1.2. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 RFC2119 [RFC2119] when, and only when, they appear in all capitals, 162 as shown here. 164 1.3. SFC within SR Networks 166 As described in [RFC8402], Segment Routing (SR) leverages the source 167 routing technique. Concretely, a node steers a packet through an SR 168 policy instantiated as an ordered list of instructions called 169 segments. While initially designed for policy-based source routing, 170 SR also finds its application in supporting SFC 171 [I-D.xuclad-spring-sr-service-programming]. The two SR flavors, 172 namely MPLS-SR [RFC8660] and SRv6 [RFC8754], can both encode a 173 Service Function (SF) as a segment so that an SFC can be specified as 174 a segment list. Nevertheless, and as discussed in [RFC7498], traffic 175 steering is only a subset of the issues that motivated the design of 176 the SFC architecture. Further considerations such as simplifying 177 classification at intermediate SFs and allowing for coordinated 178 behaviors among SFs by means of supplying context information should 179 be taken into account when designing an SFC data plane solution. 181 While each scheme (i.e., NSH-based SFC and SR-based SFC) can work 182 independently, this document describes how the two can be used 183 together in concert and complement each other through two 184 representative application scenarios. Both application scenarios may 185 be supported using either MPLS-SR or SRv6: 187 o NSH-based SFC with SR-based transport plane: in this scenario 188 segment routing provides the transport encapsulation between SFFs 189 while NSH is used to convey and trigger SFC polices. 191 o SR-based SFC with integrated NSH service plane: in this scenario 192 each service hop of the SFC is represented as a segment of the SR 193 segment-list. SR is responsible for steering traffic through the 194 necessary SFFs as part of the segment routing path and NSH is 195 responsible for maintaining the service plane, and holding the SFC 196 instance context and associated metadata. 198 It is of course possible to combine both of these two scenarios so as 199 to support specific deployment requirements and use cases. 201 A classifier SHOULD assign an NSH Service Path Identifier (SPI) per 202 SR policy so that different traffic flows that use the same NSH 203 Service Function Path (SFP) but different SR policy can coexist on 204 the same SFP without conflict during SFF processing. 206 2. NSH-based SFC with SR-based Transport Tunnel 208 Because of the transport-independent nature of NSH-based service 209 chains, it is expected that the NSH has broad applicability across 210 different domains of a network. By way of illustration the various 211 SFs involved in a service chain are available in a single data 212 center, or spread throughout multiple locations (e.g., data centers, 213 different POPs), depending upon the operator preference and/or 214 availability of service resources. Regardless of where the service 215 resources are deployed it is necessary to provide traffic steering 216 through a set of SFFs and NSH-based service chains provide the 217 flexibility for the network operator to choose which particular 218 transport encapsulation to use between SFFs, which may be different 219 depending upon which area of the network the SFFs/SFs are currently 220 deployed. Therefore from an SFC architecture perspective, segment 221 routing is simply one of multiple available transport encapsulations 222 that can be used for traffic steering between SFFs. Concretely, NSH 223 does not require to use a unique transport encapsulation when 224 traversing a service chain. NSH-based service forwarding relies upon 225 underlying service node capabilities. 227 The following three figures provide an example of an SFC established 228 for flow F that has SF instances located in different data centers, 229 DC1 and DC2. For the purpose of illustration, let the SFC's Service 230 Path Identifier (SPI) be 100 and the initial Service Index (SI) be 231 255. 233 Referring to Figure 1, packets of flow F in DC1 are classified into 234 an NSH-based SFC and encapsulated after classification as and forwarded to SFF1 236 (which is the first SFF hop for this service chain). 238 After removing the outer transport encapsulation, that may or may not 239 be MPLS-SR or SRv6, SFF1 uses the SPI and SI carried within the NSH 240 encapsulation to determine that it should forward the packet to SF1. 241 SF1 applies its service, decrements the SI by 1, and returns the 242 packet to SFF1. SFF1 therefore has when the packet 243 comes back from SF1. SFF1 does a lookup on which 244 results in and forwards the packet to DC1-GW1. 246 +--------------------------- DC1 ----------------------------+ 247 | +-----+ | 248 | | SF1 | | 249 | +--+--+ | 250 | | | 251 | | | 252 | +------------+ | +------------+ | 253 | | N(100,255) | | | F:Inner Pkt| | 254 | +------------+ | +------------+ | 255 | | F:Inner Pkt| | | N(100,254) | | 256 | +------------+ ^ | | +------------+ | 257 | (2) | | | (3) | 258 | | | v | 259 | (1) | (4) | 260 |+------------+ ----> +--+---+ ----> +---------+ | 261 || | NSH | | NSH | | | 262 || Classifier +------------+ SFF1 +--------------+ DC1-GW1 + | 263 || | | | | | | 264 |+------------+ +------+ +---------+ | 265 | | 266 | +------------+ +------------+ | 267 | | N(100,255) | | N(100,254) | | 268 | +------------+ +------------+ | 269 | | F:Inner Pkt| | F:Inner Pkt| | 270 | +------------+ +------------+ | 271 | | 272 +------------------------------------------------------------+ 274 Figure 1: SR for inter-DC SFC - Part 1 276 Referring now to Figure 2, DC1-GW1 performs a lookup on the 277 information conveyed in the NSH which results in . The SR encapsulation has the SR segment-list to 279 forward the packet across the inter-DC network to DC2. 281 +----------- Inter DC ----------------+ 282 | (5) | 283 +------+ ----> | +---------+ ----> +---------+ | 284 | | NSH | | | SR | | | 285 + SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + | 286 | | | | | | | | 287 +------+ | +---------+ +---------+ | 288 | | 289 | +------------+ | 290 | | S(DC2-GW1) | | 291 | +------------+ | 292 | | N(100,254) | | 293 | +------------+ | 294 | | F:Inner Pkt| | 295 | +------------+ | 296 +-------------------------------------+ 298 Figure 2: SR for inter-DC SFC - Part 2 300 When the packet arrives at DC2, as shown in Figure 3, the SR 301 encapsulation is removed and DC2-GW1 performs a lookup on the NSH 302 which results in next-hop: SFF2. The outer transport encapsulation 303 may be any transport that is able to identify NSH as the next 304 protocol. 306 +------------------------ DC2 ----------------------+ 307 | +-----+ | 308 | | SF2 | | 309 | +--+--+ | 310 | | | 311 | | | 312 | +------------+ | +------------+ | 313 | | N(100,254) | | | F:Inner Pkt| | 314 | +------------+ | +------------+ | 315 | | F:Inner Pkt| | | N(100,253) | | 316 | +------------+ ^ | | +------------+ | 317 | (7) | | | (8) | 318 | | | v | 319 | (6) | (9) | 320 |+----------+ ----> +--+---+ ----> | 321 || | NSH | | IP | 322 || DC2-GW1 +------------+ SFF2 | | 323 || | | | | 324 |+----------+ +------+ | 325 | | 326 | +------------+ +------------+ | 327 | | N(100,254) | | F:Inner Pkt| | 328 | +------------+ +------------+ | 329 | | F:Inner Pkt| | 330 | +------------+ | 331 +---------------------------------------------------+ 333 Figure 3: SR for inter-DC SFC - Part 3 335 The benefits of this scheme are listed hereafter: 337 o The network operator is able to take advantage of the transport- 338 independent nature of the NSH encapsulation. 340 o The network operator is able to take advantage of the traffic 341 steering capability of SR where appropriate. 343 o Light-weight NSH is used in the data center for SFC and avoids 344 more complex hierarchical SFC schemes between data centers. 346 o Clear responsibility division and scope between NSH and SR. 348 Note that this scenario is applicable to any case where multiple 349 segments of a service chain are distributed into multiple domains or 350 where traffic-engineered paths are necessary between SFFs (strict 351 forwarding paths for example). Further note that the above example 352 can also be implemented using end to end segment routing between SFF1 353 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the packets 354 based on segment routing instructions and are not looking at the NSH 355 header for forwarding). 357 3. SR-based SFC with Integrated NSH Service Plane 359 In this scenario we assume that the SFs are NSH-aware and therefore 360 it should not be necessary to implement an SFC proxy to achieve 361 Service Function Chaining. The operation relies upon SR to perform 362 SFF-SFF transport and NSH to provide the service plane between SFs 363 thereby maintaining SFC context and metadata. 365 When a service chain is established, a packet associated with that 366 chain will first encapsulate an NSH that will be used to maintain the 367 end-to-end service plane through use of the SFC context. The SFC 368 context (e.g., the service plane path referenced by the SPI) is used 369 by an SFF to determine the SR segment list for forwarding the packet 370 to the next-hop SFFs. The packet is then encapsulated using the 371 (transport-specific) SR header and forwarded in the SR domain 372 following normal SR operation. 374 When a packet has to be forwarded to an SF attached to an SFF, the 375 SFF performs a lookup on the prefix SID associated with the SF to 376 retrieve the next-hop context between the SFF and SF. E.g. to 377 retrieve the destination MAC address in case native Ethernet 378 encapsulation is used between SFF and SF. How the next-hop context 379 is populated is out of the scope of this document. The SFF strips 380 the SR information of the packet, updates the SR information, and 381 saves it to a cache indexed by the NSH SPI. This saved SR 382 information is used to encapsulate and forward the packet(s) coming 383 back from the SF. 385 When the SF receives the packet, it processes it as usual and sends 386 it back to the SFF. Once the SFF receives this packet, it extracts 387 the SR information using the NSH SPI as the index into the cache. 388 The SFF then pushes the SR header on top of the NSH header, and 389 forwards the packet to the next segment in the segment list. 391 Figure 4 illustrates an example of this scenario. 393 +-----+ +-----+ 394 | SF1 | | SF2 | 395 +--+--+ +--+--+ 396 | | 397 | | 398 +-----------+ | +-----------+ +-----------+ | +-----------+ 399 |N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt| 400 +-----------+ | +-----------+ +-----------+ | +-----------+ 401 |F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) | 402 +-----------+ | +-----------+ +-----------+ | +-----------+ 403 (2) ^ | (3) | (5) ^ | (6) | 404 | | | | | | 405 | | v | | v 406 +------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP 407 | | NSHoSR | | NSHoSR | | 408 | Classifier +--------+ SFF1 +---------------------+ SFF2 | 409 | | | | | | 410 +------------+ +------+ +------+ 412 +------------+ +------------+ 413 | S(SF1) | | S(SF2) | 414 +------------+ +------------+ 415 | S(SFF2) | | N(100,254) | 416 +------------+ +------------+ 417 | S(SF2) | | F:Inner Pkt| 418 +------------+ +------------+ 419 | N(100,255) | 420 +------------+ 421 | F:Inner Pkt| 422 +------------+ 424 Figure 4: NSH over SR for SFC 426 The benefits of this scheme include: 428 o It is economically sound for SF vendors to only support one 429 unified SFC solution. The SF is unaware of the SR. 431 o It simplifies the SFF (i.e., the SR router) by nullifying the 432 needs for re-classification and SR proxy. 434 o It provides a unique and standard way to pass metadata to SFs. 435 Note that currently there is no solution for MPLS-SR to carry 436 metadata and there is no solution to pass metadata to SR-unaware 437 SFs. 439 o SR is also used for forwarding purposes including between SFFs. 441 o It takes advantage of SR to eliminate the NSH forwarding state in 442 SFFs. This applies each time strict or loose SFPs are in use. 444 o It requires no interworking as would be the case if MPLS-SR based 445 SFC and NSH-based SFC were deployed as independent mechanisms in 446 different parts of the network. 448 4. Encapsulation Details 450 4.1. NSH using MPLS-SR Transport 452 MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore 453 the segment routing header is a stack of MPLS labels. 455 When carrying NSH within an MPLS-SR transport, the full encapsulation 456 headers are as illustrated in Figure 5. 458 +------------------+ 459 ~ MPLS-SR Labels ~ 460 +------------------+ 461 | NSH Base Hdr | 462 +------------------+ 463 | Service Path Hdr | 464 +------------------+ 465 ~ Metadata ~ 466 +------------------+ 468 Figure 5: NSH using MPLS-SR Transport 470 As described in [RFC8402] the IGP signaling extension for IGP-Prefix 471 segment includes a flag to indicate whether directly connected 472 neighbors of the node on which the prefix is attached should perform 473 the NEXT operation or the CONTINUE operation when processing the SID. 474 When NSH is carried beneath MPLS-SR it is necessary to terminate the 475 NSH-based SFC at the tail-end node of the MPLS-SR label stack. This 476 is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore 477 the prefix-SID associated with the tail-end of the SFC MUST be 478 advertised with the CONTINUE operation so that the penultimate hop 479 node does not pop the top label of the MPLS-SR label stack and 480 thereby expose NSH to the wrong SFF. It is RECOMMENDED that a 481 specific prefix-SID be allocated at each node for use by the SFC 482 application for this purpose. 484 At the end of the MPLS-SR path it is necessary to provide an 485 indication to the tail-end that NSH follows the MPLS-SR label stack. 487 There are several ways to achieve this but its specification is 488 outside the scope of this document. 490 4.2. NSH using SRv6 Transport 492 When carrying NSH within an SRv6 transport the full encapsulation is 493 as illustrated in Figure 6. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Next Header | Hdr Ext Len | Routing Type | Segments Left | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Last Entry | Flags | Tag | S 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e 502 | | g 503 | Segment List[0] (128 bits IPv6 address) | m 504 | | e 505 | | n 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t 507 | | 508 | | R 509 ~ ... ~ o 510 | | u 511 | | t 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i 513 | | n 514 | Segment List[n] (128 bits IPv6 address) | g 515 | | 516 | | S 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R 518 // // H 519 // Optional Type Length Value objects (variable) // 520 // // 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 524 | Service Path Identifier | Service Index | S 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H 526 | | 527 ~ Variable-Length Context Headers (opt.) ~ 528 | | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 6: NSH using SRv6 Transport 533 Encapsulation of NSH following SRv6 may be indicated either by 534 encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the 535 Next Header field of the SRH, or by indicating an IP protocol number 536 for NSH in the Next Header of the SRH. The behavior for 537 encapsulating NSH over UDP, including the selection of the source 538 port number in particular, adheres to similar considerations as those 539 discussed in [RFC8086]. 541 5. Security Considerations 543 Generic SFC-related security considerations are discussed in 544 [RFC7665]. NSH-specific security considerations are discussed in 545 [RFC8300]. NSH-in-UDP with DTLS [RFC6347] should follow the 546 considerations discussed in Section 5 of [RFC8086], with a 547 destination port number set to TBA2 549 6. IANA Considerations 551 6.1. UDP Port Number for NSH 553 IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the NSH from the "Service Name and Transport Protocol Port Number Registry" available at 554 https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml: 556 Service Name: NSH-in-UDP 557 Transport Protocol(s): UDP 558 Assignee: IESG iesg@ietf.org 559 Contact: IETF Chair chair@ietf.org 560 Description: NSH-in-UDP Encapsulation 561 Reference: [ThisDocument] 562 Port Number: TBA1 563 Service Code: N/A 564 Known Unauthorized Uses: N/A 565 Assignment Notes: N/A 567 Service Name: NSH-UDP-DTLS 568 Transport Protocol(s): UDP 569 Assignee: IESG iesg@ietf.org 570 Contact: IETF Chair chair@ietf.org 571 Description: NSH-in-UDP with DTLS Encapsulation 572 Reference: [ThisDocument] 573 Port Number: TBA2 574 Service Code: N/A 575 Known Unauthorized Uses: N/A 576 Assignment Notes: N/A 577 6.2. Protocol Number for NSH 579 IANA is requested to assign a protocol number TBA3 for the NSH from the "Assigned Internet Protocol Numbers" registry available at 580 https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. 582 +---------+---------+--------------+---------------+----------------+ 583 | Decimal | Keyword | Protocol | IPv6 | Reference | 584 | | | | Extension | | 585 | | | | Header | | 586 +---------+---------+--------------+---------------+----------------+ 587 | TBA3 | NSH | Network | N | [ThisDocument] | 588 | | | Service | | | 589 | | | Header | | | 590 +---------+---------+--------------+---------------+----------------+ 592 7. Acknowledgments 594 TBD. 596 8. References 598 8.1. Normative References 600 [I-D.ietf-spring-segment-routing-mpls] 601 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 602 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 603 data plane", draft-ietf-spring-segment-routing-mpls-12 604 (work in progress), February 2018. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 612 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 613 January 2012, . 615 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 616 Chaining (SFC) Architecture", RFC 7665, 617 DOI 10.17487/RFC7665, October 2015, 618 . 620 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 621 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 622 March 2017, . 624 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 625 "Network Service Header (NSH)", RFC 8300, 626 DOI 10.17487/RFC8300, January 2018, 627 . 629 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 630 Decraene, B., Litkowski, S., and R. Shakir, "Segment 631 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 632 July 2018, . 634 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 635 Decraene, B., Litkowski, S., and R. Shakir, "Segment 636 Routing with the MPLS Data Plane", RFC 8660, 637 DOI 10.17487/RFC8660, December 2019, 638 . 640 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 641 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 642 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 643 . 645 8.2. Informative References 647 [I-D.ietf-6man-segment-routing-header] 648 Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., 649 Field, B., daniel.voyer@bell.ca, d., 650 daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., 651 Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, 652 D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing 653 Header (SRH)", draft-ietf-6man-segment-routing-header-09 654 (work in progress), March 2018. 656 [I-D.xuclad-spring-sr-service-programming] 657 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 658 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 659 Henderickx, W., and S. Salsano, "Service Programming with 660 Segment Routing", draft-xuclad-spring-sr-service- 661 programming-02 (work in progress), April 2019. 663 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 664 Service Function Chaining", RFC 7498, 665 DOI 10.17487/RFC7498, April 2015, 666 . 668 Authors' Addresses 670 James N Guichard (editor) 671 Futurewei Technologies 672 2330 Central Express Way 673 Santa Clara 674 USA 676 Email: james.n.guichard@futurewei.com 678 Haoyu Song 679 Futurewei Technologies 680 2330 Central Express Way 681 Santa Clara 682 USA 684 Email: haoyu.song@futurewei.com 686 Jeff Tantsura 687 Apstra inc. 688 USA 690 Email: jefftant.ietf@gmail.com 692 Joel Halpern 693 Ericsson 694 USA 696 Email: joel.halpern@ericsson.com 698 Wim Henderickx 699 Nokia 700 USA 702 Email: wim.henderickx@nokia.com 704 Mohamed Boucadair 705 Orange 706 USA 708 Email: mohamed.boucadair@orange.com 709 Syed Hassan 710 Cisco Systems 711 USA 713 Email: shassan@cisco.com