idnits 2.17.1 draft-ietf-trill-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 -- The document date (October 28, 2016) is 2729 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 2 INTERNET-DRAFT Huawei 3 Intended status: Proposed Standard Bob Briscoe 4 Simula Research Lab 5 Expires: April 27, 2017 October 28, 2016 7 TRILL: ECN (Explicit Congestion Notification) Support 8 10 Abstract 12 Explicit congestion notification (ECN) allows a forwarding element to 13 notify downstream devices, including the destination, of the onset of 14 congestion without having to drop packets. This document extends this 15 capability to TRILL switches, including integration with IP ECN. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Distribution of this document is unlimited. Comments should be sent 23 to the TRILL working group mailing list . 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 37 Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction............................................3 43 1.1 Conventions used in this document......................4 45 2. The ECN Specific Extended Header Flags..................5 47 3. ECN Support.............................................6 48 3.1 Ingress ECN Support....................................6 49 3.2 Transit ECN Support....................................6 50 3.3 Egress ECN Support.....................................7 52 4. TRILL Support for ECN Variants..........................9 53 4.1 Pre-Congestion Notification (PCN)......................9 54 4.2 Low Latency, Low Loss, Scalable Throughput (L4S)......10 56 5. IANA Considerations....................................11 58 6. Security Considerations................................12 59 7. Acknowledgements.......................................12 61 Normative References......................................13 62 Informative References....................................13 64 Appendix A. TRILL Transit RBridge Behavior to Support L4S.15 65 Authors' Addresses........................................17 67 1. Introduction 69 Explicit congestion notification (ECN [RFC3168]) allows a forwarding 70 element, such as a router, to notify downstream devices, including 71 the destination, of the onset of congestion without having to drop 72 packets. Instead, the forwarding element can explicitly mark a 73 proportion of packets in an ECN field. For example, a two-bit field 74 is available for ECN marking in IP headers. 76 ............................. 77 . . 78 +---------+ . 79 +------+ | Ingress | . 80 |Source| +->| RBridge | . +----------+ 81 +---+--+ | | RB1 | . |Forwarding| 82 | | +------+--+ +----------+ . | Element | 83 v | . | | Transit | . | Y | 84 +-------+--+ . +---->| RBridges | . +--------+-+ 85 |Forwarding| . | RBn | . ^ | 86 | Element | . +-------+--+ +---------+ | v 87 | X | . | | Egress | | +-----------+ 88 +----------+ . +---->| RBridge +-+ |Destination| 89 . | RB9 | +-----------+ 90 . TRILL +---------+ 91 . campus . 92 ............................. 94 Figure 1. Example Path Forwarding Nodes 96 In [RFC3168] it was recognized that tunnels and lower layer protocols 97 would need to support ECN, and ECN markings would need to be 98 propagated, as headers were encapsulated and decapsulated. 99 [ECNencapGuide] gives guidelines on the addition of ECN to protocols 100 like TRILL that often encapsulate IP packets, including propagation 101 of ECN from and to IP. 103 In the figure above, assuming IP traffic, RB1 is an encapsulator and 104 RB9 a decapsulator. Traffic from Source to RB1 might or might not get 105 marked as having experienced congestion in forwarding elements, such 106 as X, before being encapsulated at ingress RB1. Any such ECN marking 107 is encapsulated with a TRILL Header. 109 This specification provides for any ECN marking in the traffic at the 110 ingress to be copied into the TRILL Extension Header Flags Word. It 111 also enables congestion marking by a congested RBridge such as RBn or 112 RB1 above in the TRILL Header Extension Flags Word [RFC7179]. 114 At RB9, the TRILL egress, it specifies how any ECN markings in the 115 TRILL Header Flags Word and in the encapsulated traffic are combined 116 so that subsequent forwarding elements, such as Y and the 117 Destination, can see if congestion was experienced at any previous 118 point in the path from Source. 120 A large part of the guidelines for adding ECN to lower layer 121 protocols [ECNencapGuide] concerns safe propagation of congestion 122 notifications in scenarios where some of the nodes do not support or 123 understand ECN. Whichever RBridges do not support ECN, this 124 specification ensures congestion notification will propagate safely 125 to Destination because the packet will be dropped if explicit 126 congestion notification cannot be propagated and drop is itself an 127 implicit form of congestion notification. 129 1.1 Conventions used in this document 131 The terminology and acronyms defined in [RFC6325] are used herein 132 with the same meaning. 134 In this documents, "IP" refers to both IPv4 and IPv6. 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 Acronyms: 142 AQM - Active Queue Management 144 CCE - Critical Congestion Experienced 146 CE - Congestion Experienced 148 CItE - Critical Ingress-to-Egress 150 ECN - Explicit Congestion Notification 152 ECT - ECN Capable Transport 154 L4S - Low Latency, Low Loss, Scalable throughput 156 NCHbH - Non-Critical Hop-by-Hop 158 NCCE - Non-Critical Congestion Experienced 160 Not-ECT - Not ECN-Capable Transport 162 PCN - Pre-Congestion Notification 164 2. The ECN Specific Extended Header Flags 166 The extension header fields for explicit congestion notification 167 (ECN) in TRILL are defined as a two-bit TRILL-ECN field and a one-bit 168 Critical Congestion Experienced (CCE) field in the TRILL Header 169 Extension Flags Word [RFC7780]. 171 These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN 172 field consists of bits 12 and 13, which are in the range reserved for 173 non-critical hop-by-hop (NCHbH) bits. The CCE field consists of bit 174 26, which is in the range reserved for Critical Ingress-to-Egress 175 (CItE) bits. See [RFC7780] and [RFC7179] for the meaning of the other 176 bits. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE | 182 |.....|.........|...........|.....|.......|...........|.........| 183 |C|C|C| |C|N| | | | | | | | | 184 |R|R|R| |R|C| |ECN| Ext | | |C|Ext| | 185 |H|I|R| |C|C| | | Hop | | |C|Clr| | 186 |b|t|s| |A|A| | | Cnt | | |E| | | 187 |H|E|v| |F|F| | | | | | | | | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 2 The ECN and CCE TRILL Header Extension Flags Word Fields 192 Table 1 shows the meaning of the codepoints in the TRILL-ECN field. 193 Note that the first three have the same meaning as the corresponding 194 ECN field codepoints in the IPv4 or IPv6 header as defined in 195 [RFC3168]. However codepoint 11 is called Non-Critical Congestion 196 Experienced (NCCE) to distinguish it from Congestion Experienced in 197 IP. 199 Binary Name Meaning 200 ------ ------- ----------------------------------- 201 00 Not-ECT Not ECN-Capable Transport 202 01 ECT(1) ECN-Capable Transport (1) 203 10 ECT(0) ECN-Capable Transport (0) 204 11 NCCE Non-Critical Congestion Experienced 206 Table 1. TRILL-ECN Field Codepoints 208 3. ECN Support 210 The subsections below describe the required behavior to support ECN 211 at TRILL ingress, transit, and egress. The ingress behavior logically 212 occurs as a native frame is encapsulated with a TRILL Header to 213 produce a TRILL Data packet. The transit behavior logically occurs in 214 all RBridges where TRILL Data packets are queued, usually at the 215 output port. The egress behavior logically occurs as a TRILL Data 216 packet is decapsulated and output as a native frame through an 217 RBridge port. 219 An RBridge that supports ECN MUST behave as described in the relevant 220 subsections below, which correspond to the recommended provisions of 221 [ECNencapGuide]. Nonetheless, the scheme is designed to safely 222 propagate some form of congestion notification even if some RBridges 223 in the path followed by a TRILL Data packet support ECN and others do 224 not. 226 3.1 Ingress ECN Support 228 The ingress behavior is as follows: 230 o When encapsulating an IP frame, the ingress RBridge MUST: 232 + set the F flag in the main TRILL header [RFC7780]; 233 + create a Flags Word as part of the TRILL Header; 234 + copy the two ECN bits from the IP header into the TRILL-ECN 235 field (Flags Word bits 12 and 13) 236 + ensure the CCE flag is cleared to zero (Flags Word bit 26). 238 o When encapsulating a frame for a non-IP protocol, where that 239 protocol has a means of indicating ECN that is understood by the 240 ingress RBridge, it MUST follow the guidelines in [ECNencapGuide] 241 to add a Flags Word to the TRILL Header. For a non-IP protocol 242 with a similar ECN field to IP, this would be achieved by copying 243 into the TRILL-ECN field from the encapsulated native frame. 245 3.2 Transit ECN Support 247 The transit behavior, show below, is required at all RBridges where 248 TRILL Data packets are queued, usually at the output port. 250 o An RBridge that supports ECN MUST implement some form of active 251 queue management (AQM) according to the guidelines of [RFC7567]. 252 The RBridge detects congestion either by monitoring its own queue 253 depth or by participating in a link-specific protocol. 255 o If the TRILL Header Flags Word is present, whenever the AQM 256 algorithm decides to indicate congestion on a TRILL Data packet it 257 MUST set the CCE flag (Flags Word bit 26). 259 o If the TRILL header Flags Word is not present, to indicate 260 congestion the RBridge will either drop the packet or it MAY do 261 all of the following instead: 263 + set the F flag in the main TRILL header; 264 + add a Flags Word to the TRILL Header; 265 + set the TRILL-ECN field to Not-ECT (00); 266 + and set the CCE flag and the Ingress-to-Egress critical summary 267 bit (CRIbE). 269 Note that a transit RBridge that supports ECN does not refer to the 270 TRILL-ECN field before signalling CCE in a packet. It signals CCE 271 irrespective of whether the packet indicates that the transport is 272 ECN-capable. The egress/decapsulation behavior (described next) 273 ensures that a CCE indication is converted to a drop if the transport 274 is not ECN-capable. 276 3.3 Egress ECN Support 278 If the egress RBridge does not support ECN, it will ignore bits 12 279 and 13 of any Flags Word that is present, because it does not contain 280 any special ECN logic. Nonetheless, if a transit RBridge has set the 281 CCE flag, the egress will drop the packet. This is because drop is 282 the default behavior for an RBridge decapsulating a Critical Ingress- 283 to-Egress flag when it has no specific logic to understand it. Drop 284 is the intended behavior for such a packet, as required by 285 [ECNencapGuide]. 287 If an RBridge supports ECN, the egress behavior is as follows: 289 o When decapsulating an inner IP packet, the RBridge sets the ECN 290 field of the outgoing native IP packet using Table 2. It MUST set 291 the ECN field of the outgoing IP packet to the codepoint at the 292 intersection of the row for the arriving encapsulated IP packet 293 and the column for 3-bit ECN codepoint in the arriving outer TRILL 294 Data packet TRILL Header. If no TRILL Header Extension Flags Word 295 is present, the 3-bit ECN codepoint is assumed to be all zero 296 bits. 297 The name of the TRILL 3-bit ECN codepoint is defined using the 298 combination of the TRILL-ECN and CCE fields in Table 3. 299 Specifically, the TRILL 3-bit ECN codepoint is called CE if either 300 NCCE or CCE is set in the TRILL Header Extension Flags Word. 301 Otherwise it has the same name as the 2-bit TRILL-ECN codepoint. 302 In the case where the TRILL 3-bit ECN codepoint indicates 304 congestion experienced (CE) but the encapsulated native IP frame 305 indicates a not ECN-capable transport (Not-ECT), the RBridge MUST 306 drop the packet. Such packet dropping is necessary because a 307 transport above the IP layer that is not ECN-capable will have no 308 ECN logic, so it will only understand dropped packets as an 309 indication of congestion. 311 o When decapsulating a non-IP protocol frame with a means of 312 indicating ECN that is understood by the RBridge, it MUST follow 313 the guideines in [ECNencapGuide] when setting the ECN information 314 in the decapsulated native frame. For a non-IP protocol with a 315 similar ECN field to IP, this would be achieved by combining the 316 information in the TRILL Header Flags Word with the encapsulated 317 non-IP native frame, as specified in Table 2. 319 +---------+----------------------------------------------+ 320 | Inner | Arriving TRILL 3-bit ECN Codepoint Name | 321 | Native +---------+------------+------------+----------+ 322 | Header | Not-ECT | ECT(0) | ECT(1) | CE | 323 +---------+---------+------------+------------+----------+ 324 | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | | 325 | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | 326 | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | 327 | CE | CE | CE | CE(*) | CE | 328 +---------+---------+------------+------------+----------+ 330 Table 2: Egress ECN Behavior 332 An asterisk in the above table indicates a currently unused 333 combination that SHOULD be logged. In contrast to [RFC6040], in TRILL 334 the drop condition is the result of a valid combination of events and 335 need not be logged. 337 +------------+-----+---------------------+ 338 | TRILL-ECN | CCE | Arriving TRILL 3-bit| 339 | | | ECN codepoint name | 340 +------------+-----+---------------------+ 341 | Not-ECT 00 | 0 | Not-ECT | 342 | ECT(1) 01 | 0 | ECT(1) | 343 | ECT(0) 10 | 0 | ECT(0) | 344 | NCCE 11 | 0 | CE | 345 | Not-ECT 00 | 1 | CE | 346 | ECT(1) 01 | 1 | CE | 347 | ECT(0) 10 | 1 | CE | 348 | NCCE 11 | 1 | CE | 349 +------------+-----+---------------------+ 351 Table 3: Mapping of TRILL-ECN and CCE Fields to TRILL 3-bit ECN 352 Codepoint Name 354 4. TRILL Support for ECN Variants 356 This section is informative, not normative. 358 Section 3 specifies interworking between TRILL and the original 359 standardized form of ECN in IP [RFC3168]. 361 The ECN wire protocol for TRILL (Section 2) has been designed to 362 support the other known variants of ECN, as detailed below. New 363 variants of ECN will have to comply with the guidelines for defining 364 alternative ECN semantics [RFC4774]. It is expected that the TRILL 365 ECN wire protocol is generic enough to support such potential future 366 variants. 368 4.1 Pre-Congestion Notification (PCN) 370 The PCN wire protocol [RFC6660] is recognised by the use of a PCN- 371 compatible Diffserv codepoint in the IP header and a non-zero IP-ECN 372 field. For TRILL or any lower layer protocol, equivalent traffic 373 classification codepoints would have to be defined, but that is 374 outside the scope of the current document. 376 The PCN wire protocol is similar to ECN, except it indicates 377 congestion with two levels of severity. It uses: 379 o 11 (CE) as the most severe, termed the Excess-traffic-marked (ETM) 380 codepoint 382 o 01 ECT(1) as a lesser severity level, termed the Threshold-Marked 383 (ThM) codepoint. 385 To implement PCN on a transit RBridge would require a detailed 386 specification. But in brief: 388 o the TRILL Critical Congestion Experienced (CCE) flag would be used 389 for the Excess-Traffic-Marked (ETM) codepoint; 391 o ECT(1) in the TRILL-ECN field would be used for the Threshold- 392 Marked codepoint. 394 Then the ingress and egress behaviors defined in Section 3 would not 395 need to be altered to ensure support for PCN as well as ECN. 397 4.2 Low Latency, Low Loss, Scalable Throughput (L4S) 399 L4S is currently only a proposal being considered for adoption onto 400 the IETF's experimental track. An outline of how a transit TRILL 401 RBridge would support L4S [ECNL4S] is given in Appendix A. 403 5. IANA Considerations 405 IANA is requested to update the TRILL Extended Header Flags registry 406 by replacing the lines for bits 9-13 and for bits 21-26 with the 407 following: 409 Bits Purpose Reference 410 ----- ------- --------- 411 9-11 available non-critical hop-by-hop flags 412 12-13 TRILL-ECN (Explicit Congestion Notification) [this doc] 414 21-25 available critical ingress-to-egress flags 415 26 Critical Congestion Experienced (CCE) [this doc] 417 6. Security Considerations 419 TRILL support of ECN is a straight forward combination of previously 420 specified ECN and TRILL with no significnat new security 421 considerations. 423 For ECN tunneling security considerations, see [RFC6040]. 425 For general TRILL protocol security considerations, see [RFC6325]. 427 7. Acknowledgements 429 This document was prepared with basic NROFF. All macros used were 430 defined in the source file. 432 Normative References 434 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 436 March 1997, . 438 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 439 of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 440 10.17487/RFC3168, September 2001, . 443 [RFC4774] - Floyd, S., "Specifying Alternate Semantics for the 444 Explicit Congestion Notification (ECN) Field", BCP 124, RFC 445 4774, DOI 10.17487/RFC4774, November 2006, . 448 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 449 Ghanwani, "Routing Bridges (RBridges): Base Protocol 450 Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, 451 . 453 [RFC7179] - Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and 454 C. Bestler, "Transparent Interconnection of Lots of Links 455 (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 456 2014, . 458 [RFC7567] - Baker, F., Ed., and G. Fairhurst, Ed., "IETF 459 Recommendations Regarding Active Queue Management", BCP 197, 460 RFC 7567, DOI 10.17487/RFC7567, July 2015, . 463 [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., 464 Ghanwani, A., and S. Gupta, "Transparent Interconnection of 465 Lots of Links (TRILL): Clarifications, Corrections, and 466 Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, 467 . 469 [ECNencapGuide] - B. Briscoe, J. Kaippallimalil, P. Thaler, 470 "Guidelines for Adding Congestion Notification to Protocols 471 that Encapsulate IP", draft-ietf-tsvwg-ecn-encap-guidelines, 472 work in progress. 474 Informative References 476 [RFC6040] - Briscoe, B., "Tunnelling of Explicit Congestion 477 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, 478 . 480 [RFC6660] - Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three 481 Pre-Congestion Notification (PCN) States in the IP Header Using 482 a Single Diffserv Codepoint (DSCP)", RFC 6660, DOI 483 10.17487/RFC6660, July 2012, . 486 [ECNL4S] - K. De Schepper, B. Briscoe, I. Tsang, "Identifying 487 Modified Explicit Congestion Notification (ECN) Semantics for 488 Ultra-Low Queueing Delay", draft-briscoe-tsvwg-ecn-l4s-id, work 489 in progress. 491 Appendix A. TRILL Transit RBridge Behavior to Support L4S 493 An initial specification of the Low Latency, Low Loss, Scalable 494 throughput (L4S) wire protocol for IP is given in [ECNL4S]. It is 495 similar to the original ECN wire protoocl for IP [RFC3168], except: 497 o An AQM that supports L4S classifies packets with ECT(1) or CE in 498 the IP header into an L4S queue and a "Classic" queue otherwise. 500 o the meaning of CE markings applied by an L4S queue is not the same 501 as the meaning of a drop by a "Classic" queue (contrary to the 502 original requirement for ECN [RFC3168]). Instead the likelihood 503 that the Classic queue drops packets is defined as the square of 504 the likelihood that the L4S queue marks packets (e.g. when there 505 is a drop probability of 0.0009 (0.09%) the L4S marking 506 probability will be 0.03 (3%)). 508 This seems to present a problem for the way that a transit TRILL 509 RBridge defers the choice between marking and dropping to the egress. 510 Nonetheless, the following pseudocode outlines how a transit TRILL 511 RBridge can implement L4S marking in such a way that the egress 512 behavior already described in Section 3.3 for Classic ECN [RFC3168] 513 will produce the desired outcome. 515 /* p is an internal variable calculated by any L4S AQM 516 * dependent on the delay being experienced in the Classic queue. 517 * bit13 is the least significant bit of the TRILL-ECN field 518 */ 520 % On TRILL transit 521 if (bit13 == 0 ) { 522 % Classic Queue 523 if (p > max(random(), random()) ) 524 mark(CCE) % likelihood: p^2 526 } else { 527 % L4S Queue 528 if (p > max(random()) ) { 529 if (p > max(random()) ) 530 mark(CCE) % likelihood: p^2 531 else 532 mark(NCCE) % likelihood: p - p^2 533 } 534 } 536 With the above transit behavior, an egress that supports ECN (Section 537 3.3) will drop packets or propagate their ECN markings depending on 538 whether the arriving inner header is from a non-ECN-capable or ECN- 539 capable transport. 541 Even if an egress has no L4S-specific logic of its own, it will drop 542 packets with the square of the probability that an egress would if it 543 did support ECN, for the following reasons: 545 o Egress with ECN support: 547 + L4S: propagates both the Critical and Non-Critical CE marks 548 (CCE & NCCE) as a CE mark. 550 Likelihood: p^2 + p - p^2 = p 552 + Classic: Propagates CCE marks as CE or drop, depending on 553 inner. 555 Likelihood: p^2 557 o Egress without ECN support: 559 + L4S: does not propagate NCCE as a CE mark, but drops CCE marks. 561 Likelihood: p^2 563 + Classic: drops CCE marks. 565 Likelihood: p^2 567 Authors' Addresses 569 Donald E. Eastlake, 3rd 570 Huawei Technologies 571 155 Beaver Street 572 Milford, MA 01757 USA 574 Tel: +1-508-333-2270 575 Email: d3e3e3@gmail.com 577 Bob Briscoe (editor) 578 Simula Research Lab 580 Email: ietf@bobbriscoe.net 581 URI: http://bobbriscoe.net/ 583 Copyright and IPR Provisions 585 Copyright (c) 2016 IETF Trust and the persons identified as the 586 document authors. All rights reserved. 588 This document is subject to BCP 78 and the IETF Trust's Legal 589 Provisions Relating to IETF Documents 590 (http://trustee.ietf.org/license-info) in effect on the date of 591 publication of this document. Please review these documents 592 carefully, as they describe your rights and restrictions with respect 593 to this document. Code Components extracted from this document must 594 include Simplified BSD License text as described in Section 4.e of 595 the Trust Legal Provisions and are provided without warranty as 596 described in the Simplified BSD License. The definitive version of 597 an IETF Document is that published by, or under the auspices of, the 598 IETF. Versions of IETF Documents that are published by third parties, 599 including those that are translated into other languages, should not 600 be considered to be definitive versions of IETF Documents. The 601 definitive version of these Legal Provisions is that published by, or 602 under the auspices of, the IETF. Versions of these Legal Provisions 603 that are published by third parties, including those that are 604 translated into other languages, should not be considered to be 605 definitive versions of these Legal Provisions. For the avoidance of 606 doubt, each Contributor to the IETF Standards Process licenses each 607 Contribution that he or she makes as part of the IETF Standards 608 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 609 language to the contrary, or terms, conditions or rights that differ 610 from or are inconsistent with the rights and licenses granted under 611 RFC 5378, shall have any effect and shall be null and void, whether 612 published or posted by such Contributor, or included with or in such 613 Contribution.