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