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