idnits 2.17.1 draft-eastlake-sfc-nsh-ecn-support-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 234 has weird spacing: '... sender doma...' == Line 235 has weird spacing: '...ingress v |...' -- The document date (July 2, 2018) is 2123 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) ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-tunnel-congestion-feedback (ref. 'TunnelCongFeedback') -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Huawei 3 Bob Briscoe 4 Independent 5 Andrew Malis 6 Huawei 7 Expires: January 1, 2019 July 2, 2018 9 Explicit Congestion Notification (ECN) and Congestion Feedback 10 Using the Network Service Header (NSH) 11 13 Abstract 15 Explicit congestion notification (ECN) allows a forwarding element to 16 notify downstream devices of the onset of congestion without having 17 to drop packets. Coupled with a means to expose congestion by feeding 18 back information about it to upstream nodes, this can improve network 19 efficiency through better congestion control, frequently without 20 packet drops. This document specifies ECN and congestion feedback 21 support through use of the Network Service Header (NSH, RFC 8300) and 22 IP Flow Information Export (IPFIX, draft-ietf-tsvwg-tunnel- 23 congestion-feedback). 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the SFC Working Group mailing list or to the 32 authors. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 46 Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Table of Contents 51 1. Introduction............................................3 52 1.1 NSH Background.........................................3 53 1.2 ECN Background.........................................5 54 1.3 Tunnel Congestion Feedback Background..................5 55 1.4 Conventions Used in This Document......................6 57 2. The NSH ECN Field.......................................8 59 3. ECN Support in the NSH.................................10 60 3.1 At The Ingress........................................11 61 3.2 At Transit Nodes......................................11 62 3.2.1 At NSH Transit Nodes................................12 63 3.2.2 At an SF/Proxy......................................12 64 3.2.3 At Other Forwarding Nodes...........................13 65 3.3 At Exit/Egress........................................13 66 3.4 Conservation of Packets...............................14 68 4. Tunnel Congestion Feedback Support.....................15 70 5. IANA Considerations....................................16 71 6. Security Considerations................................17 72 7. Acknowledgements.......................................17 74 Normative References......................................18 75 Informative References....................................19 77 Authors' Addresses........................................20 79 1. Introduction 81 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 82 element to notify downstream devices of the onset of congestion 83 without having to drop packets. Coupled with a means to expose 84 congestion by feeding back information about it to upstream nodes, 85 this can improve network efficiency through better congestion 86 control, frequently without packet drops. This document specifies ECN 87 and congestion feedback support through use of the Network Service 88 Header (NSH [RFC8300]) and IP Flow Information Export (IPFIX 89 [TunnelCongFeedback]). 91 This section provides background information on NSH, ECN, congestion 92 feedback, and terminology used in this document. 94 1.1 NSH Background 96 The Service Function Chaining (SFC [RFC7665]) architecture calls for 97 the encapsulation of traffic within a service function chaining 98 domain with a Network Service Header (NSH [RFC8300]) added by the 99 "Classifier" (ingress node) on entry to the domain and the NSH being 100 removed on exit from the domain at the egress node. The NSH is used 101 to control the path of a packet in an SFC domain. The NSH is a 102 natural way, in a domain where traffic is NSH encapsulated, to both 103 (1) note congestion, avoiding possible confusion due, for example, to 104 changes in the outer transport header in different parts of the 105 domain, and, 106 (2) direct congestion information feedback to the domain ingress so 107 that it can take action when appropriate to alleviate congestion. 109 | 110 v 111 +----------+ 112 . .|Classifier|. . . . . . . . . . . . . . 113 . +----------+ . 114 . | +----+ . 115 . | --+ SF | Service . 116 . | / +----+ Function . 117 . v --- Chaining . 118 . +-----+/ +----+ domain . 119 . | SFF |--------+ SF | . 120 . +-----+\ +----+ . 121 . | --- . 122 . | \ +----+ . 123 . | --+ SF | . 124 . v +----+ . 125 . +-----+ +----+ . 126 . | SFF |-----------------+ SF | . 127 . +-----+ +----+ . 128 . | +----+ . 129 . | --+ SF | . 130 . | / +----+ . 131 . v --- . 132 . +-----+/ +----+ . 133 . | SFF |--------+ SF | . 134 . +-----+\ +----+ . 135 . | --- . 136 . | \ +----+ . 137 . | --+ SF | . 138 . v +----+ . 139 . +------+ . 140 . . .| Exit |. . . . . . . . . . . . . . . 141 +------+ 142 | 143 v 145 Figure 1. Example SFC Path Forwarding Nodes 147 Figure 1 shows an SFC domain for the purpose of illustrating the use 148 of NSH. Traffic passes through a sequence of Service Function 149 Forwarders (SFFs) each of which sends the traffic to one or more 150 Service Functions (SFs). Each SF performs some operation on the 151 traffic, for example firewall or Network Address Translation (NAT), 152 and then returns it to the SFF from which it was received. 154 Logically, during the transit of each SFF, the outer transport header 155 that got the packet to the SFF is stripped, the SFF decides on the 156 next forwarding step, either adding a transport header or, if the SFF 157 is the exit/egress, removing the NSH header. The transport headers 158 added may be different in different regions of the SFC domain. For 159 example, IP could be used for some SFF-to-SFF communication and MPLS 160 used for other such communication. 162 1.2 ECN Background 164 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 165 element (such as a router or an Service Function Forwarder (SFF) or 166 Service Function (SF)) to notify downstream devices of the onset of 167 congestion without having to drop packets. This can be used as an 168 element in active queue management (AQM) [RFC7567] to improve network 169 efficiency through better traffic control without packet drops. The 170 forwarding element can explicitly mark some packets in an ECN field 171 instead of dropping the packet. For example, a two-bit field is 172 available for ECN marking in IP headers [RFC3168]. 174 1.3 Tunnel Congestion Feedback Background 176 Tunnel Congestion Feedback [TunnelCongFeedback] is a building block 177 for various congestion mitigation methods that supports feedback of 178 congestion information from an egress node to an ingress node. 179 Examples of actions that can be taken by an ingress node when it has 180 knowledge of downstream congestion include those listed below. 181 Details of implementing these traffic control methods, beyond those 182 given here, are outside the scope of this document. 184 (1) Traffic throttling (policing), where the downstream traffic 185 flowing out of the ingress node is limited to reduce or eliminate 186 congestion. 188 (2) Upstream congestion feedback, where the ingress node sends 189 messages upstream to or towards the ultimate traffic source, a 190 function that can throttle traffic generation/transmission. 192 (3) Traffic re-direction, where the ingress node configures the NSH 193 so that some future traffic avoids congested paths. 195 NOTE: With this method 3 great care must be taken to avoid (a) 196 significant re-ordering of traffic in flows that it is desirable 197 to keep in order and (b) oscillation/instability in traffic paths 198 due to alternate congestion of previously idle paths and the 199 idling of previously congested paths. For example, it is 200 preferable to classify traffic into flows or a sufficiently 201 coarse granularity that the flows are long lived and use a stable 202 path per flow sending only newly appearing flows on apparently 203 uncongested paths. 205 Figure 2 shows an example path from an origin sender to a final 206 receiver passing through an example chain of service functions 207 between the ingress and egress of an SFC domain. The path is also 208 likely to pass through other network nodes outside the SFC domain 209 (not shown). The figure shows typical congestion feedback that would 210 be expected from the final receiver to the origin sender, which 211 controls the load the origin sender applies to all elements on the 212 path. The figure also shows the congestion feedback from the egress 213 to the ingress of the SFC domain that is described in this document, 214 to control or balance load within the SFC domain. 216 .:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :. 217 _||_ End-to-End Congestion Feedback || 218 \ / || 219 \/ || 220 Inner Transport Header and Payload __ 221 | | - - - - - - - - - - - - - - - ->- - - - - -- - - - - - - - | | 222 | | | | 223 | | .:= = = = = = = = = = = = = = = = = = = = = =:. | | 224 | | _||_ Tunnel Congestion Feedback || | | 225 | | \ / || | | 226 | | \/ || | | 227 | | __ NSH __ | | 228 | | | |-------------------------->--------------| | | | 229 | |. . . | | ___ ___ ___ | |. . .| | 230 | | | | OT1 | | OT4 | | . . . | | OTn | | | | 231 | | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | | 232 |__| |__| |___| |___| |___| |__| |__| 233 origin SFC | ^ | ^ SFC final 234 sender domain OT2| |OT3 OT6| |OT7 domain rcvr 235 ingress v | v | egress 236 +---+ +---+ 237 |SF | |SF | 238 +---+ +---+ 240 Figure 2: Congestion Feedback across an SFC Domain 242 SFC Domain congestion feedback in Figure 2 is shown within the 243 context of an end-to-end congestion feedback loop. Also shown is the 244 encapsulated layering of NSH headers within a series of outer 245 transport headers (OT1, OT2, ... OTn). 247 1.4 Conventions Used in This Document 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119] [RFC8174] 252 when, and only when, they appear in all capitals, as shown here. 254 Acronyms: 256 AQM - Active Queue Management [RFC7567] 258 CE - Congestion Experienced [RFC3168] 260 downstream - The direction from ingress to egress 262 ECN - Explicit Congestion Notification [RFC3168] 264 ECT - ECN Capable Transport [RFC3168] 266 IPFIX - IP Flow Information Export [RFC7011] 268 Not-ECT - Not ECN-Capable Transport [RFC3168] 270 NSH - Network Service Header [RFC8300] 272 SF - Service Function [RFC7665] 274 SFC - Service Function Chaining [RFC7665] 276 SFF - Service Function Forwarder [RFC7665] - A type of node that 277 forwards based on the NSH. 279 TLV - Type Length Value 281 upstream - The direction from egress to ingress 283 2. The NSH ECN Field 285 The NSH header is used to encapsulate and control the subsequent path 286 of traffic (see Section 2 of [RFC8300]). The NSH also provides for 287 metadata inclusion, as shown in Figure 3. 289 +-----------------------------------+ 290 | Transport Encapsulation | 291 +-----------------------------------+ 292 | Network Service Header (NSH) | 293 | +------------------------------+ | 294 | | Base Header | | 295 | +------------------------------+ | 296 | | Service Path Header | | 297 | +------------------------------+ | 298 | | Metadata (Context Header(s)) | | 299 | +------------------------------+ | 300 +-----------------------------------+ 301 | Original Packet / Frame | 302 +-----------------------------------+ 304 Figure 3. Data Encapsulation with the NSH 306 Two currently unused bits (indicated by "U") in the NSH Base Header 307 (Section 2.2 of [RFC8300]) are allocated for ECN as shown in Figure 308 4. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 ^ ^ 316 | | 317 +-------+ 318 |NSH ECN| 319 | field | 320 +-------+ 322 Figure 4: NSH Base Header 324 Note to RFC Editor: The above figure should be adjusted based on the 325 bits assigned by IANA (see Section 5) and this note deleted. 327 Table 1 shows the meaning of the code points in the NSH ECN field. 328 These have the same meaning as the ECN field code points in the IPv4 329 or IPv6 header as defined in [RFC3168]. 331 Binary Name Meaning 332 ------ ------- -------------------------------- 333 00 Not-ECT Not ECN-Capable Transport 334 01 ECT(1) ECN-Capable Transport 335 10 ECT(0) ECN-Capable Transport 336 11 CE Congestion Experienced 338 Table 1. ECN Field Code Points 340 3. ECN Support in the NSH 342 This section describes the required behavior to support ECN using the 343 NSH. There are two aspects to ECN support: 344 1. ECN propagation during encapsulation or decapsulation 345 2. ECN marking during congestion at bottlenecks. 347 While this section covers all combinations of ECN-aware and not ECN- 348 aware, it is expected that in most cases the NSH domain will be 349 uniform so that, if this document is applicable, all SFFs will 350 support ECN; however, some legacy SFs might not support ECN. 352 ECN Propagation: 354 The specification of ECN tunneling [RFC6040] explains that an 355 ingress must not propagate ECN support into an encapsulating 356 header unless the egress supports correct onward propagation of 357 the ECN field during decapsulation. We define Compliant ECN 358 Decapsulation here as decapsulation compliant with either 359 [RFC6040] or an earlier compatible equivalent ([RFC4301], or full 360 functionality mode of [RFC3168]). 362 The procedures in Section 3.2.1 ensure that each ingress of the 363 large number of possible transport links within the SFC domain 364 does not propagate ECN support into the encapsulating outer 365 transport header unless the corresponding egress of that link 366 supports Compliant ECN Decapsulation. 368 Section 3.3 requires that all the egress nodes of the SFC domain 369 support Compliant ECN Decapsulation in conjunction with tunnel 370 congestion feedback, otherwise the scheme in this document will 371 not work. 373 ECN Marking: 375 At transit nodes the marking behavior specified in 3.2.1 is 376 recommended and if not implemented at such transit nodes, there 377 may be unmanaged congestion. 379 Detection of congestion will be most effective if ECN marking is 380 supported by all potential bottlenecks inside the domain in which 381 NSH is being used to route traffic as well as at the ingress and 382 egress. Nodes that do not support ECN marking, or that support 383 AQM but not ECN, will naturally use drop to relieve congestion. 384 The gap in the end-to-end packet sequence will be detected as 385 congestion by the final receiving endpoint, but not by the NSH 386 egress (see Figure 2). 388 3.1 At The Ingress 390 When the ingress/Classifier encapsulates an incoming IP packet with 391 an NSH, it MUST set the NSH ECN field using the "Normal mode" 392 specified in [RFC6040] (i.e., copied from the incoming IP header). 394 Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD 395 set it to ECT(0), in order to indicate that the NSH encapsulation is 396 an ECN-Capable Transport. It MAY instead be set to ECT(1) if the NSH 397 domain supports the experimental L4S capability [RFC8311], [ecnL4S]. 399 Packets arriving at the ingress might not use IP. If the protocol of 400 arriving packets supports an ECN field similar to IP, the procedures 401 for IP packets can be used. If arriving packets do not support an ECN 402 field similar to IP, they MUST be treated as if they are Not-ECT IP 403 packets. 405 Then, as the NSH encapsulated packet is further encapsulated with a 406 transport header, if ECN marking is available for that transport (as 407 it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the 408 transport header MUST be set using the "Normal mode" specified in 409 [RFC6040] (i.e., copied from the NSH ECN field). 411 A summary of these normative steps is given in Table 2. 413 +-----------------+-------------------------------+ 414 | Incoming Header |Departing NSH and Outer Headers| 415 | (also equal to +---------------+---------------+ 416 | departing Inner | Classic ECN | L4S ECN | 417 | Header) | Mode | Mode | 418 +-----------------+---------------+---------------+ 419 | Not-ECT | ECT(0) | ECT(1) | 420 | ECT(0) | ECT(0) | ECT(0) | 421 | ECT(1) | ECT(1) | ECT(1) | 422 | CE | CE | CE | 423 +-----------------+---------------+---------------+ 425 Table 2. Setting of ECN fields by an ingress/Classifier 427 The requirements in this section apply to all ingress nodes for the 428 domain in which NSH is being used to route traffic. 430 3.2 At Transit Nodes 432 This section described behavior at nodes that forward based on the 433 NSH such as SFF and other forwarding nodes such as IP routers. Figure 434 5 shows a packet on the wire between forwarding nodes. 436 +-----------------+ 437 | Outer Header | 438 +-----------------+ 439 | NSH | 440 +-----------------+ 441 | Inner Header | 442 +-----------------+ 443 | Payload | 444 +-----------------+ 446 Figure 5. Packet in Transit 448 3.2.1 At NSH Transit Nodes 450 When a packet is received at an NSH based forwarding node N1, such as 451 an SFF, the outer transport encapsulation is removed and its ECN 452 marking SHOULD be combined into the NSH ECN marking as specified in 453 [RFC6040]. If this is not done, any congestion encountered at non-NSH 454 transit nodes between N1 and the next upstream NSH based forwarding 455 node will be lost and not transmitted downstream. 457 The NSH forwarding node SHOULD use a recognized AQM algorithm 458 [RFC7567] to detect congestion. If the NSH ECN field indicates ECT, 459 it will probabilistically set the NSH ECN field to the Congestion 460 Experienced (CE) value or, in cases of extreme congestion, drop the 461 packet. 463 When the NSH encapsulated packet is further encapsulated for 464 transmission to the next SFF or SF, ECN marking behavior depends on 465 whether or not the node that will decapsulate the outer header 466 supports Compliant ECN Decapsulation (see Section 3). If it does, 467 then the ingress node propagates the NSH ECN field to this outer 468 encapsulation using the "Normal Mode" of ECN encapsulation [RFC6040] 469 (it copies the ECN field). If it does not, then the ingress MUST 470 clear ECN in the outer encapsulation to non-ECT (the "Compatibility 471 Mode" of [RFC6040]). 473 3.2.2 At an SF/Proxy 475 If the SF is NSH and ECN-aware, the processing is essentially the 476 same at the SF as at an SFF as discussed in Section 3.2.1. 478 If the SF is NSH-aware but not ECN-aware, then the SFF transmitting 479 the packet to the SF will use Compatibility Mode. Congestion 480 encountered in the SFF to SF and SF to SFF paths will be unmanaged. 482 If the SF is not NSH-aware, then an NSH proxy will be between the SFF 483 and the SF to avoid exposure of the NSH at the SF that does not 484 understand NSHs. This is described in Section 4.6 of [RFC7665]. The 485 SF and proxy together look to the SFF like an NSH-aware SF. The 486 behavior at the proxy and SF in this case is as below: 488 If such a proxy is not ECN-aware then congestion in the entire 489 path from SFF to proxy to SF back to proxy to SFF will be 490 unmanaged. 492 If the proxy is ECN-aware the proxy uses an AQM to indicate 493 congestion in the proxy itself in the NSH that it returns to the 494 SFF. The outer header used for the proxy to SF path uses Normal 495 Mode. The outer head used for the proxy return to SFF path uses 496 Normal Mode based copying the NSH ECN field to the outer header. 497 Thus congestion in the proxy will be managed. Congestion in the SF 498 will be managed only if the SF is ECN-aware implementing an AQM. 500 3.2.3 At Other Forwarding Nodes 502 Other forwarding nodes, that is non-NSH forwarding nodes between NSH 503 forwarding nodes, such as IP routers, might also be potential 504 bottlenecks. If so, they SHOULD implement an AQM algorithm to update 505 the ECN marking in the outer transport header as specified in 506 [RFC3168]. 508 3.3 At Exit/Egress 510 First, any actions are taken based on Congestion Experienced such as 511 forwarding statistics back to the ingress (see Section 4). If the 512 packet being carried inside the NSH is IP, when the NSH is removed 513 the NSH ECN field MUST be combined with IP ECN field as specified in 514 Table 3 that was extracted from [RFC6040]. This requirement applies 515 to all egress nodes for the domain in which NSH is being used to 516 route traffic. 518 +---------+---------------------------------------------+ 519 |Arriving | Arriving Outer Header | 520 | Inner +---------+-----------+-----------+-----------+ 521 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 522 +---------+---------+-----------+-----------+-----------+ 523 | Not-ECT | Not-ECT |Not-ECT |Not-ECT | | 524 | ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE | 525 | ECT(1) | ECT(1) | ECT(1) | ECT(1) | CE | 526 | CE | CE | CE | CE | CE | 527 +---------+---------+-----------+-----------+-----------+ 529 Table 3. Exit ECN Fields Merger 531 All the egress nodes of the SFC domain MUST support Compliant ECN 532 Decapsulation as specified in this section. If this is not the case, 533 the scheme described in this document will not work, and cannot be 534 used. 536 3.4 Conservation of Packets 538 The SFC specification permits an SF to absorb packets and to generate 539 new packets as well as to process and forward the packets it 540 receives. Such actions might appear to be packet loss due to 541 congestion or might mask the loss of packets by generating additional 542 packets. 544 The tunnel congestion feedback approach [TunnelCongFeedback] detects 545 loss by counting payload bytes in at the ingress and counting them 546 out at the egress. This does not work unless nodes conserve the 547 amount of payload bytes. Therefore, it will not be possible to detect 548 loss using this technique if they are not conserved. 550 Nonetheless, if a bottleneck supports ECN marking, it will be 551 possible to detect the very high level of CE markings that are 552 associated with congestion that is so excessive that it leads to 553 loss. However, it will not be possible for the tunnel congestion 554 feedback approach to detect any congestion, whether slight or severe, 555 if it occurs at a bottleneck that does not support ECN marking. 557 4. Tunnel Congestion Feedback Support 559 The collection and storage of congestion information may be useful 560 for later analysis but, unless it can be fed back to a point which 561 can take action to reduce congestion, it will not be useful in real 562 time. Such congestion feedback to the ingress enables it to take 563 actions such as those listed in Section 1.3. 565 IP Flow Information Export (IPFIX [RFC7011]) provides a standard for 566 communicating traffic flow statistics. As extended by 567 [TunnelCongFeedback], IPFIX can be used to determine the extent of 568 congestion between an ingress and egress. 570 IPFIX recommends use of SCTP [RFC4960] in partial reliability mode. 571 This mode allows loss of some packets, which is tolerable because 572 IPFIX communicates cumulative statistics. IPFIX over SCTP SHOULD be 573 used directly where there is IP connectivity between the ingress and 574 egress; however, there might be different transport protocols or 575 address spaces used in different regions of an SFC domain that make 576 such direct IP connectivity problematic. The NSH provides the general 577 method of routing of traffic within such domain so the IPFIX over 578 SCTP over IP traffic should be encapsulated in NSH when necessary. 580 5. IANA Considerations 582 IANA is requested to assign two contiguous bits in the NSH Base 583 Header Bits registry for ECN (bits 16 and 17 suggested) and note this 584 assignment as follows: 586 Bit Description Reference 587 ---------- ----------- --------------- 588 tbd(16-17) NSH ECN [this document] 590 6. Security Considerations 592 For general NSH security considerations, see [RFC8300]. 594 For security considerations concerning tampering with ECN signaling, 595 see [RFC3168]. For security considerations concerning ECN 596 encapsulation, see [RFC6040]. 598 For general IPFIX security considerations, see [RFC7011]. If deployed 599 in an untrusted environment, the signaling traffic between ingress 600 and egress can be protected utilizing the security mechanisms 601 provided by IPFIX (see section 11 in RFC7011). 603 The solution does not introduce any greater potential to invade 604 privacy than would have been possible without the solution. 606 7. Acknowledgements 608 The authors wish to thank the following for their comments and 609 suggestion: 611 Joel Halpern, Xinpeng Wei 613 Normative References 615 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 617 March 1997, . 619 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 620 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 621 10.17487/RFC3168, September 2001, . 624 [RFC5129] - Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion 625 Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, 626 . 628 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 629 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 630 . 632 [RFC7011] - Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 633 "Specification of the IP Flow Information Export (IPFIX) 634 Protocol for the Exchange of Flow Information", STD 77, RFC 635 7011, DOI 10.17487/RFC7011, September 2013, . 638 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 639 Recommendations Regarding Active Queue Management", BCP 197, 640 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 643 [RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 645 2017, 647 [RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 648 "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, 649 January 2018, . 651 [TunnelCongFeedback] - Wei, X., Zhu, L., and L. Deng, "Tunnel 652 Congestion Feedback", draft-ietf-tsvwg-tunnel-congestion- 653 feedback, work in progress. 655 Informative References 657 [RFC4301] - Kent, S. and K. Seo, "Security Architecture for the 658 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 659 2005, . 661 [RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol", 662 RFC 4960, DOI 10.17487/RFC4960, September 2007, 663 . 665 [RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service 666 Function Chaining (SFC) Architecture", RFC 7665, DOI 667 10.17487/RFC7665, October 2015, . 670 [RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion 671 Notification (ECN) Experimentation", RFC 8311, DOI 672 10.17487/RFC8311, January 2018, . 675 [ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified 676 Explicit Congestion Notification (ECN) Semantics for Ultra-Low 677 Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in 678 progress. 680 Authors' Addresses 682 Donald E. Eastlake, 3rd 683 Huawei Technologies 684 1424 Pro Shop Court 685 Davenport, FL 33896 USA 687 Tel: +1-508-333-2270 688 Email: d3e3e3@gmail.com 690 Bob Briscoe 691 Independent 692 UK 694 Email: ietf@bobbriscoe.net 695 URI: http://bobbriscoe.net/ 697 Andrew G. Malis 698 Huawei Technologies 700 Email: agmalis@gmail.com 702 Copyright and IPR Provisions 704 Copyright (c) 2018 IETF Trust and the persons identified as the 705 document authors. All rights reserved. 707 This document is subject to BCP 78 and the IETF Trust's Legal 708 Provisions Relating to IETF Documents 709 (http://trustee.ietf.org/license-info) in effect on the date of 710 publication of this document. Please review these documents 711 carefully, as they describe your rights and restrictions with respect 712 to this document. Code Components extracted from this document must 713 include Simplified BSD License text as described in Section 4.e of 714 the Trust Legal Provisions and are provided without warranty as 715 described in the Simplified BSD License. The definitive version of 716 an IETF Document is that published by, or under the auspices of, the 717 IETF. Versions of IETF Documents that are published by third parties, 718 including those that are translated into other languages, should not 719 be considered to be definitive versions of IETF Documents. The 720 definitive version of these Legal Provisions is that published by, or 721 under the auspices of, the IETF. Versions of these Legal Provisions 722 that are published by third parties, including those that are 723 translated into other languages, should not be considered to be 724 definitive versions of these Legal Provisions. For the avoidance of 725 doubt, each Contributor to the IETF Standards Process licenses each 726 Contribution that he or she makes as part of the IETF Standards 727 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 728 language to the contrary, or terms, conditions or rights that differ 729 from or are inconsistent with the rights and licenses granted under 730 RFC 5378, shall have any effect and shall be null and void, whether 731 published or posted by such Contributor, or included with or in such 732 Contribution.