idnits 2.17.1 draft-bryant-mpls-sfl-control-05.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 (January 02, 2020) is 1569 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) == Outdated reference: A later version (-11) exists of draft-ietf-mpls-sfl-framework-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Bryant 3 Internet-Draft Futurewei Technologies Inc. 4 Intended status: Standards Track G. Swallow 5 Expires: July 5, 2020 Southend Technical Center 6 S. Sivabalan 7 Cisco Systems 8 January 02, 2020 10 A Simple Control Protocol for MPLS SFLs 11 draft-bryant-mpls-sfl-control-05 13 Abstract 15 In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow 16 labels (SFL) was introduced. This document describes a control 17 protocol that runs over an associated control header to request, 18 withdrawn and extend the lifetime of such labels. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on July 5, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 3. SFL Control . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3.1. SFL Control Message . . . . . . . . . . . . . . . . . . . 3 58 3.2. SFL Control Proceedures . . . . . . . . . . . . . . . . . 6 59 3.2.1. Request/Grant . . . . . . . . . . . . . . . . . . . . 6 60 3.2.2. Refresh . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2.3. Withdraw . . . . . . . . . . . . . . . . . . . . . . 9 62 3.2.4. Timer Accuracy . . . . . . . . . . . . . . . . . . . 9 63 4. Return Path . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5. Manageability Considerations . . . . . . . . . . . . . . . . 10 65 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 In [I-D.ietf-mpls-sfl-framework] the concept of MPLS synonymous flow 76 labels (SFL) was introduced. This document describes a simple 77 control protocol, for use in a well managed MPLS network, that runs 78 over an associated control header to request, withdrawn, and extend 79 the lifetime of such labels. 81 2. Requirements Language 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in BCP 86 14 [RFC2119] [RFC8174] when, and only when, they appear in all 87 capitals, as shown here. 89 3. SFL Control 91 This section describes the process by which the RFC6374 Querier 92 requests SFLs, the process by which the RFC6374 Responder sends them 93 to the Querier, and the process for managing the SFL lifetime. SFL 94 Control Messages are carried over the SFL Control ACH. The SFL ACH 95 is carried over a Pseudowire(PW) in place of the PW Control Word 96 (CW), over an MPLS LSP using the GAL, or over some other mutually 97 agreed path. Similarly the response may be returned over a PW, over 98 a bidirectional LSP or over some other mutually agreed path. See 99 Section 4. 101 3.1. SFL Control Message 103 The format of an SFL Control message, which follows the Associated 104 Channel Header (ACH), is as follows: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 |Version| Flags | Control Code | Message Length | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Session Identifier | SFL Batch | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Lifetime (seconds) | Num SFL | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | SFL 0 | LFlags | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 . . 118 . . 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | SFL n | LFlags | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Forwarding Equivalence Class (FEC) | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Figure 1: SFL Control Message Format 127 Reserved fields MUST be set to 0 and ignored upon receipt. The 128 possible values for the remaining fields are as follows: 130 Version Protocol version. Set to zero in this specification. 132 Flags Message control flags. 134 Control Code Code identifying the query or response type. 136 Message Length Total length of this message in bytes. 138 Session Identifier Set arbitrarily by the querier and used as a 139 message handle. 141 SFL Batch Used where the SFLs for this Session Identifier 142 managed across multiple SFL Control Messages. A given 143 set of SFLs MUST be retained in the same batch. 145 Lifetime The lifetime in seconds of the SFLs in this message. 146 In a Query message it is the requested lifetime. In a 147 Response message it is the lifetime that the SFLs have 148 been allocated for by the Responder. The Querier MUST 149 NOT use an SFL after expiry of its lifetime, a 150 Responder MUST make the SFL available for at least its 151 lifetime. 153 Num SFL The number of SFLs in this SFL Batch. This MUST be 154 constant for the lifetime of the batch. 156 SFL n The n'th SFL carried in this TLV. This is an MPLS 157 label which is a component of a label stack entry as 158 defined in Section 2.1 of [RFC3032]. The position of 159 a label within a batch is constant for the lifetime of 160 the batch. Enumeration starts at zero. 162 LFlags The set of flags associated with the immediately 163 preceding SFL. See below. 165 FEC The Forwarding Equivalence Class that the SFLs in this 166 TLV correspond to. This is encoded as per 167 Section 3.4.1 of [RFC5036]. 169 Flags: The format of the Flags field is shown below. 171 +-+-+-+-+ 172 |R|0|0|0| 173 +-+-+-+-+ 175 SFL Control Message Flag 177 R: Query/Response indicator. Set to 0 for a Query and 1 for a 178 Response. 180 0: Set to zero by the Sender and ignored by the Receiver. 182 Control Code: Set as follows according to whether the message is a 183 Query or a Response as identified by the R flag. 185 For a Query: 187 Request This indicates that the responder is requested to allocate 188 the set of SFLs marked with the R LFlag in this Message. 190 Refresh This indicates that the responder is requested to refresh 191 the set of SFLs marked with the V LFlag in this Message. 193 Withdraw This indicates that the querier will no longer use the set 194 of SFLs marked with the V Lflag and the responder may expire their 195 lifetime. 197 For a Response: 199 Grant This indicates that the responder allocated the set of SFLs 200 marked with the A LFlag in this Message. 202 Refresh-Ack This indicates that the responder has refreshed the set 203 of SFLs marked with the V LFlag in this Message, and the lifetime 204 is now as indicated by the lifetime field. 206 Withdraw-Ack This indicates that the responder has received the 207 Withdraw message and will withdraw the SFLs 209 SFL-Unable The Responder was unable to satisfy the SFL Request. The 210 details of the failure can be determined by comparing the Request 211 and Grant messages. 213 Further error codes are for future study. 215 The LFlags field is defined as follows: 217 0 1 218 0 1 2 3 4 5 6 7 8 9 0 1 219 +-+-+-+-+-+-+-+-+-+-+-+-+ 220 |0|1|2|3| MBZ | 221 +-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: LFlags Bit Definition 225 Where: 227 0 (Valid (V)) The Label value of the corresponding SFL is valid. In 228 an SFL Request setting the V Lflag indicates a request 229 for the specified label value. Where an SFL has a 230 valid flag clear in a request message this indicates 231 that any SFL value is acceptable. 233 1 (Request (R)) Indicates to the Querier that this member of the SFL 234 batch is requested. Where a value is specified in the 235 request, but the Responder is unable honour that 236 request, no SFL is allocated and the corresponding A 237 flag MUST be cleared. 239 2 (Allocated (A) Indicates to the Querier that this SFL was 240 allocated. 242 3 (Withdraw (W)) Indicates to the Responser that this SFL is to be 243 withdrawn and to the Querier that the withdrawal has 244 been carried out. 246 MBZ MUST be sent as zero and ignored on receive. 248 A flag value of one is true/set and a flag value of zero is false/ 249 clear. The use of these bits is described in more detail in the 250 following sub-sections. 252 3.2. SFL Control Proceedures 254 3.2.1. Request/Grant 256 To request a batch of SFLs the Querier constructs an SFL Control 257 Request, encapsulates it in an SFL Control ACH and sends it to the 258 Responder via an appropriate path. It sets the Control Message Flag 259 to Query and the Control Code to Request. It chooses a session 260 identifier as a handle for this transaction and as a way of binding 261 this batch of SFLs to other operations that will use members of this 262 SFL batch. Since members of the batch are treated as a group, the 263 SFL Batch identifier is used to identify different SFL batches used 264 in conjunction with the same session identifier. 266 The requested lifetime is set. This is the number of seconds from 267 the time of the query to the time when the batch of SFLs will expire 268 unless refreshed. 270 The Num SFL field is set to the SFL batch size. 272 Each SFL is set as follows: if a specific value is requested (for 273 example for continuity across system restarts) this is written into 274 the SFV n field and the V LFlag set. Otherwise, and including spare 275 SFLs where an allocation is not requested, the label value is set to 276 zero and the V LFlag is cleared. For each SFL entry where an 277 allocation is requested the R LFlag is set. All other LFlags are 278 cleared. 280 The Forwarding Equivalence Class (FEC) is set to the FEC for which 281 the SFLs are requested. 283 The Message Length is determined and filled in. 285 The Responder proceeds as follows: 287 It sets the control Message Flag to Response and initially sets the 288 Control Code to Grant. 290 For each SFL with an R flag set, it determines whether it can honour 291 the request, if so sets the A Lflag, and if the SFL value in the 292 query was zero it overwrites it with the allocated SFL label value. 293 In all other cases it leaves the SFL value and LFlag unchanged. 295 The lifetime field is updated with the lifetime of the SFLs if this 296 is different from the requested lifetime. 298 All other fields in the Query message are left unchanged and the 299 message is sent back to the Querier using the signaled or previously 300 agreed message path. 302 Where the offered lifetime is other than the requested lifetime the 303 Querier may accept the proposed value, or withdraw the SFLs and 304 attempt to negotiate a new set of SFLs with a different lifetime. 306 If the Responder is unable to allocate all of the requested SFLs it 307 MUST respond with a response code of SFL-Unable. The Querier MUST 308 determine whether the allocated SFLs were adequate for its purposes 309 and MUST send a withdraw if there are not adequate. A Querier MUST 310 NOT attempt to hoard labels in the hope that the residual labels 311 needed may become available in the future. 313 A Querier MUST wait a configured time (suggested wait of 60 seconds) 314 before reattempting negotiation for a resource. Any failure to 315 negotiate the required resources MUST be notified through the 316 management interface of both Querier and Responder. 318 A Querier MUST NOT send an expired SFL to a Responder since to do so 319 may invalidate another SFL operation. 321 3.2.2. Refresh 323 To request the lifetime refresh of a batch of SFLs the Querier 324 constructs an SFL Refresh Request, encapsulates it in an SFL Control 325 ACH and sends it to the Responder via an appropriate path. It sets 326 the Control Message Flag to Query and the Control Code to Refresh. 327 It uses the session identifier and the SFL Batch identifier that it 328 used to request this SFL batch. 330 The requested lifetime is set. This is the number of seconds from 331 the time of the query to the time when the batch of SFLs will expire 332 unless refreshed. 334 The Num SFL field is set to the SFL batch size. 336 Each SFL is set as follows: the allocated SFL label value is written 337 into the SFL n field and the V LFlag set. All other LFlags are 338 cleared. 340 The Forwarding Equivalence Class (FEC) is set to the FEC for which 341 the SFLs are requested. 343 The Message Length is determined and filled in. 345 The Responder proceeds as follows: 347 It sets the control Message Flag to Response and sets the Control 348 Code to Refresh-Ack. 350 It sets the lifetime to the lifetime of the SFL. 352 All other fields in the Query message are left unchanged and the 353 message is sent back to the Querier using the signaled or previously 354 agreed message path. 356 Where the offered lifetime is other than the requested lifetime the 357 Querier may accept the proposed value, or withdraw the SFLs and 358 attempt to negotiate a new set of SFLs with a different lifetime. 360 A Querier MUST wait a configured time (suggested wait of 60 seconds) 361 before reattempting negotiation for a resource. Any failure to 362 negotiate the required resources MUST be notified through the 363 management interface of both Querier and Responder. 365 3.2.3. Withdraw 367 To request the withdrawal of some or all of a batch of SFLs the 368 Querier constructs an SFL Withdraw Request, encapsulates it in an SFL 369 Control ACH and sends it to the Responder via an appropriate path. 370 It sets the Control Message Flag to Query and the Control Code to 371 Withdraw. It uses the session identifier and the SFL Batch 372 identifier that it used to request this SFL batch. 374 The requested lifetime is set to zero. 376 The Num SFL field is set to the SFL batch size. 378 Each SFL being withdrawn is set as follows: the allocated SFL label 379 value is written into the SFL n field and the V and W LFlags set. 380 All other LFlags are cleared. 382 The Forwarding Equivalence Class (FEC) is set to the FEC for which 383 the SFLs are requested. 385 The Message Length is determined and filled in. 387 The Responder proceeds as follows: 389 It sets the control Message Flag to Response and sets the Control 390 Code to Withdraw-Ack. 392 All other fields in the Query message are left unchanged and the 393 message is sent back to the Querier using the signaled or previously 394 agreed message path. 396 A Querier MUST wait a configured time (suggested wait of 60 seconds) 397 before reattempting a Withdraw request. No more than three Withdraw 398 requests should be made. 400 3.2.4. Timer Accuracy 402 The lifetime of SFLs is expected to be sufficiently long that there 403 are no significant constraints on timer accuracy. A node should be 404 conservative in its assumptions concerning the lifetime of an SFL. A 405 Querier MUST stop using a SFL significantly before the expiry of its 406 lifetime and a Responder must maintain an SFL in active operation 407 significantly beyond nominal expiry. A margin of the order of 408 minutes is RECOMMENDED. 410 4. Return Path 412 Where the LSP is a mulit-point to point, or multi-point to multi- 413 point MPLS LSP (or other MPLS construct) the RFC6374 Address TLV MUST 414 be included in Query packet, even if the response is requested in- 415 band, since this is needed to provide the necessary return address 416 for this request. 418 5. Manageability Considerations 420 This may be provided in a future version of this memo. 422 6. Privacy Considerations 424 The inclusion of originating and/or flow information in a packet 425 provides more identity information and hence potentially degrades the 426 privacy of the communication. Whilst the inclusion of the additional 427 granularity does allow greater insight into the flow characteristics 428 it does not specifically identify which node originated the packet 429 other than by inspection of the network at the point of ingress, or 430 inspection of the control protocol packets. This privacy threat may 431 be mitigated by encrypting the control protocol packets, regularly 432 changing the synonymous labels and by concurrently using a number of 433 such labels. 435 7. Security Considerations 437 It is assumed that this protocol is run in a well managed MPLS 438 network with strict access controls preventing unwanted parties from 439 generating MPLS OAM packets. The control protocol described in this 440 memo thus introduced no additional MPLS security vulnerabilities. 442 8. IANA Considerations 444 As per the IANA considerations in [RFC5586], IANA is requested to 445 allocate the following Channel Types in the "MPLS Generalized 446 Associated Channel (G-ACh) Types" registry: 448 Value Description TLV Follows Reference 449 ------ ---------------------------------------- ----------- --------- 450 0x0XXX SFL Control No This 452 A value of 0x60 is suggested. 454 RFC Editor please remove this note which is used to force the 455 following references to appear [RFC3032] [RFC5036] 457 9. References 459 9.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 467 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 468 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 469 . 471 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 472 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 473 October 2007, . 475 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 476 "MPLS Generic Associated Channel", RFC 5586, 477 DOI 10.17487/RFC5586, June 2009, 478 . 480 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 481 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 482 May 2017, . 484 9.2. Informative References 486 [I-D.ietf-mpls-sfl-framework] 487 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 488 and G. Mirsky, "Synonymous Flow Label Framework", draft- 489 ietf-mpls-sfl-framework-06 (work in progress), October 490 2019. 492 Authors' Addresses 494 Stewart Bryant 495 Futurewei Technologies Inc. 497 Email: stewart.bryant@gmail.com 499 George Swallow 500 Southend Technical Center 502 Email: swallow.ietf@gmail.com 503 Siva Sivabalan 504 Cisco Systems 506 Email: msiva@cisco.com