idnits 2.17.1 draft-ietf-mpls-miad-mna-requirements-00.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 (May 05, 2022) is 722 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bryant-mpls-dev-primer-01 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group M. Bocci 3 Internet-Draft Nokia 4 Intended status: Informational S. Bryant 5 Expires: November 6, 2022 University of Surrey 5GIC 6 May 05, 2022 8 Requirements for MPLS Network Action Indicators and MPLS Ancillary Data 9 draft-ietf-mpls-miad-mna-requirements-00 11 Abstract 13 This draft specifies requirements for indicators in the MPLS label 14 stack to support ancillary data in the packet and high level 15 requirements on that ancillary data. This work is the product of the 16 IETF MPLS Open Design Team. Requirements are derived from a number 17 of new proposals for additions to the MPLS label stack to allow 18 forwarding or other processing decisions to be made, either by a 19 transit or terminating LSR (i.e. the LER), based on application data 20 that may be in or below the bottom of the label stack. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 6, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 60 3. MPLS Network Action Indicator Requirements . . . . . . . . . 5 61 3.1. General Requirements . . . . . . . . . . . . . . . . . . 5 62 3.2. Requirements on Network Action Indicators . . . . . . . . 6 63 3.3. Requirements on Ancillary Data . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Working Group Adoption Comments . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 73 1. Introduction 75 There is significant interest in developing the MPLS data plane to 76 address the requirements of new applications 77 [I-D.saad-mpls-miad-usecases]. These applications typically require 78 the inclusion of ancillary data in the MPLS packet. This data may be 79 encoded either in the label stack or below the bottom of the label 80 stack. This data is then either intercepted and processed, or some 81 other forwarding decision is taken by routers processing the packet. 82 The ancillary data is added by the ingress LSR, and is then processed 83 using mechanisms implemented by intermediate and/or egress LSRs that 84 comply with the MPLS base architecture and potentially its 85 extensions, including (but not limited to) [RFC3031], [RFC3032], 86 [RFC6790]. 88 This draft specifies requirements for indicators in the MPLS label 89 stack to support these applications, as well as the encoding and use 90 of the ancillary data. 92 1.1. Terminology 94 o Ancillary Data (AD): Data relating to the MPLS packet that may be 95 used to affect the forwarding or other processing of that packet, 96 either at an Label Edge Router (LER) [RFC4221] or Label Switching 97 Router (LSR). This data may be encoded within a network action 98 sub-stack (see below) (in-stack data), and/or after the bottom of 99 the label stack (post-stack data). 101 o Network Action: An operation to be performed on a packet. A 102 network action may affect router state, packet forwarding, or it 103 may affect the packet in some other way. 104 A network action is said to be present if there is an indicator in 105 the packet that invokes the action. 107 o Network Action Indication (NAI): An indication in the packet that 108 a certain network action is to be perfomed. There may be 109 associated ancillary data in the packet. 111 o Network Action Sub-Stack (NAS): A set of related, contiguous Label 112 Stack Entries (LSEs). 113 The first LSE contains the NAI. The TC and TTL values in the sub- 114 stack may be redefined. 115 The label field in the second and following LSE may be redefined. 116 Solutions MUST NOT redefine the S bit. See Section 3.1 through 117 Section 3.5. 119 o In-Stack Data: Any data within the MPLS label stack including the 120 outer LSE and the bottom of stack (the LSE with the S-bit set). 122 o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but 123 before the first octet of the user payload. This document does 124 not prescribe whether post-stack data precedes or follows any 125 other protocol structure such as a control word or associated 126 channel header (ACH). 128 o Scope: The set of nodes that should perform a given action. 130 1.2. Background 132 The MPLS architecture is specified in [RFC3031] and provides a 133 mechanism for forwarding packets through a network without requiring 134 any analysis of the packet payload's network layer header by 135 intermediate nodes (Label Switching Routers - LSRs). Formally, 136 inspection may only occur at network ingress (the Label edge router - 137 LER) where the packet is assigned to a forwarding equivalence class 138 (FEC). 140 MPLS uses switching based on a label pushed on the packet to achieve 141 efficient forwarding and traffic engineering of flows associated with 142 the FEC. While originally used for IP traffic, MPLS has been 143 extended to support point-to-point, point-to-multipoint and 144 multipoint-to-multipoint layer 2 and layer 3 services. An overview 145 of the development of MPLS is provided in 146 [I-D.bryant-mpls-dev-primer]. 148 A number of applications have emerged which require LSRs to make 149 forwarding or other processing decisions based on inspection of the 150 network layer header, or some other ancillary information in the 151 protocol stack encapsulated deeper in the packet. An early example 152 of this was generation of a hash of the payload header to be used for 153 load balancing over Equal Cost Multipath (ECMP) or Link Aggregation 154 Group (LAG) next hops. This is based on an assumption that the 155 network layer protocol is IP. MPLS was extended to avoid the need 156 for LSRs to perform this operation if load balancing was needed based 157 on the payload and instead use only the MPLS label stack, using the 158 Entropy Label / Entropy Label Indicator [RFC6790] which are inserted 159 at the LER. Other applications where the intermediate LSRs may need 160 to inspect and process a packet on an LSP include OAM, which can make 161 use of mechanisms such the Router Alert Label [RFC3032] or the 162 Generic Associated Channel Label (GAL) [RFC5586] to indicate that an 163 intercepted packet should be processed locally. See 164 [I-D.bryant-mpls-dev-primer] for detailed list of such applications. 166 There have been a number of new proposals for how ancillary data is 167 carried in MPLS and how its presence is indicated to the LSR or 168 egress LER, for example In-situ OAM and Service Function Chaining 169 (SFC). A summary of these proposals is contained in 170 [I-D.bryant-mpls-dev-primer], an overview of use cases is provided in 171 [I-D.saad-mpls-miad-usecases]. [I-D.song-mpls-extension-header] 172 summarises some of the issues with existing solutions to address 173 these new applications (note that this document draws on the 174 requirements and issues without endorsing a specific solution from 175 [I-D.song-mpls-extension-header]): 177 These solutions rely on either the built-in next-protocol 178 indicator in the header or the knowledge of the format and size of 179 the header to access the following packet data. The node is 180 required to be able to parse the new header, which is unrealistic 181 in an incremental deployment environment. 183 A piecemeal solution often assumes the new header is the only 184 extra header and its location in the packet is fixed by default. 185 It is impossible or difficult to support multiple new headers in 186 one packet due to the conflicted assumption. An example of this 187 is that the GAL/G-ACH mechanism assumes that if the GAL is 188 present, only a single G-ACH header follows. 190 New applications therefore require the definition of extensions to 191 the MPLS architecture and label stack operations that can be used 192 across these applications in order to minimise implementation 193 complexity and promote interoperability and extensibility. 195 2. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 3. MPLS Network Action Indicator Requirements 205 This document specifies requirements of MPLS Network Action 206 Indicators, and the associated Ancillary Data. The requirements are 207 for the behavior of the protocol mechanisms and procedures that 208 constitute building blocks out of which indicators for network 209 actions and associated ancillary data are constructed. 210 It does not specify the detailed actions and processing that may be 211 required by an application for any ancillary data by an LSR or LER. 212 The requirements in this document do not describe what functions an 213 implementation must support. The purpose of this document is to 214 identify the toolkit and any new protocol work that is required. 215 This new protocol work MUST be based on the existing MPLS 216 architecture. 218 3.1. General Requirements 220 1. MPLS combines extensibility, flexibility and efficiency by using 221 control plane context combined with a simple data plane mechanism 222 to allow the network to make forwarding decisions about a packet. 223 Any solution MUST maintain these properties of MPLS. 225 2. Any solutions to these requirements MUST NOT restrict the 226 generality of MPLS architecture [RFC3031], [RFC3032]. 228 3. If extensions to the MPLS data plane are required, they MUST NOT 229 be inconsistent with the MPLS architecture [RFC3031], [RFC3032]. 231 4. Solutions meeting the requirements set out in this document MUST 232 be able to coexist with and MUST NOT obsolete existing MPLS 233 mechanisms. 235 5. The design of any mechanism SHOULD be such that an LSR is able to 236 efficiently parse the label stack. 238 6. Mechanisms MUST NOT increase the size of the MPLS label stack 239 more than is necessary. 241 7. The design of solutions MUST NOT expose confidential information 242 [RFC6973] [RFC3552] to the LSRs. 244 8. Solution specifications MUST document any changes to the existing 245 MPLS data plane security model that they introduce. 247 3.2. Requirements on Network Action Indicators 249 1. When an MPLS Network Action is required, and indicator is 250 REQUIRED in the label stack. 252 2. An MPLS Network Action MUST specify whether ancillary data is 253 required in the label stack and/or post-stack data. 255 3. Any solution MUST respect the principle that Special Purpose 256 Labels are the mechanism of last resort and therefore must 257 minimise the number of new SPLs that are allocated. 259 4. Insertion, parsing, processing and disposition of Network Action 260 Indicators SHOULD make use of existing MPLS data plane 261 operations. 263 5. An NAI MUST NOT be delivered to a node that is not capable of 264 processing in the way in a way that is acceptable to the 265 imposing LER. 267 6. NAI MUST NOT become top of stack at a node that does not 268 understand how to perform a disposition operation on it. 269 Disposition includes both processing and ignoring. 271 7. The NAI design MUST support scoping of network actions. 273 8. A given NAI specification MUST specify if the scope is end-to- 274 end, hop-by-hop, or directed at one or more selected nodes. 276 9. If a design allows more than one scope, a mechanism MUST be 277 provided to specify the precedence of the scopes. 279 10. A mechanism is REQUIRED to enable an LER inserting NAIs to 280 determine if the far-end LER can accept and process a packet 281 containing a given NAI. 283 11. NAIs SHOULD be supported for both P2P and P2MP paths, but any 284 specific NAI may only be supported for one or the other. 286 12. Data plane mechanisms for NAIs MUST be consistent across 287 different control plane protocol types. 289 13. A mechanism MUST be defined for control / management planes in 290 use to determine the ability of downstream LSRs/LERs to accept/ 291 process a given NAI. 293 14. A mechanism is REQUIRED to enable an LSR to determine if an NAI 294 is present in a packet. 296 15. NAIs can only be inserted at LERs, but MAY be processed at LSRs 297 and LERs. If it is required to insert an NAI at a transit LSR 298 on an LSP, then a new label stack MUST be pushed. 300 16. It SHOULD be possible to include indicators for multiple network 301 actions in the same packet. 303 17. The solution MUST allow NAI-carrying and non-NAI-carrying 304 packets to coexist on the same LSP. 306 18. The solution MUST support the processing of a subset of the NAIs 307 on a packet. 309 19. Any specification of a solution that inserts or modifies the NAI 310 MUST discuss the possible ECMP consequences. 312 3.3. Requirements on Ancillary Data 314 1. Solutions for in-stack ancillary data MUST be able to coexist 315 with and MUST NOT obsolete existing MPLS mechanisms. 317 2. A common preamble for ancillary data MUST be defined so that a 318 node receiving the ancillary data can determine whether to 319 process, ignore, skip over or discard it according to network or 320 local policies. 322 3. Any specification of a mechanism MUST describe whether it can 323 coexist with existing post-stack data mechanisms e.g. control 324 words and G-ACH, and if so how this coexistence operates. 326 4. A mechanism MUST be defined for an LER inserting ancillary data 327 to determine that each node that needs to process the ancillary 328 data can read the required distance into the packet at that 329 node, for example [RFC9088]. 331 5. Ancillary data MAY be associated with control or maintenance 332 information for traffic carried by an LSP, and/or it MAY be 333 associated with the user traffic itself. 335 6. For scoped ancillary data, a mechanism is REQUIRED to enable an 336 LER inserting NAIs whose network actions make use of that 337 ancillary data, to determine if the NAI and ancillary data will 338 be processed by LSRs within the scope along the path. Such a 339 mechanism MAY need to determine if LSRs along the path can 340 process a specific type of AD implied by the NAI at the depth in 341 the stack that it will be presented to the LSR. 343 7. Network action specifications MUST specify if the ancillary data 344 needs to be processed as a part of the immediate forwarding 345 operation and whether packet mis-ordering is allowed to occur as 346 a result of the time taken to process the ancillary data. 348 8. In order to prevent unnecessary scanning of the packet, care 349 needs to be taken in the location of post stack ancillary data, 350 for example it SHOULD be located as close to the bottom of the 351 label stack as possible. 353 9. A solution MUST be provided to verify the authenticity of 354 ancillary data processed to LSRs [RFC3552]. 356 10. The design of the ancillary data MUST NOT expose confidential 357 information [RFC6973] [RFC3552] to the LSRs. 359 4. IANA Considerations 361 This document makes no request of IANA. 363 Note to RFC Editor: this section may be removed on publication as an 364 RFC. 366 5. Security Considerations 368 The mechanisms required by this document introduce new security 369 considerations to MPLS. Individual solution specifications meeting 370 these requirements MUST address any security considerations. 372 6. Acknowledgements 374 The authors gratefully acknowledge the contributions from Greg 375 Mirsky, Yingzhen Qu, Haoyu Song, Tarek Saad, Loa Andersson, Tony Li, 376 John Drake and Bruno Decraene. 378 The authors also gratefully acknowledge the input of the members of 379 the MPLS Open Design Team. 381 7. References 383 7.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 391 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 392 May 2017, . 394 7.2. Informative References 396 [I-D.bryant-mpls-dev-primer] 397 Bryant, S., "A Primer on the Development of MPLS", draft- 398 bryant-mpls-dev-primer-01 (work in progress), December 399 2021. 401 [I-D.saad-mpls-miad-usecases] 402 Saad, T., Makhijani, K., Song, H., and G. Mirsky, "Use 403 Cases for MPLS Network Action Indicators and MPLS 404 Ancillary Data", draft-saad-mpls-miad-usecases-02 (work in 405 progress), April 2022. 407 [I-D.song-mpls-extension-header] 408 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 409 "MPLS Extension Header", draft-song-mpls-extension- 410 header-06 (work in progress), January 2022. 412 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 413 Label Switching Architecture", RFC 3031, 414 DOI 10.17487/RFC3031, January 2001, 415 . 417 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 418 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 419 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 420 . 422 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 423 Text on Security Considerations", BCP 72, RFC 3552, 424 DOI 10.17487/RFC3552, July 2003, 425 . 427 [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol 428 Label Switching (MPLS) Management Overview", RFC 4221, 429 DOI 10.17487/RFC4221, November 2005, 430 . 432 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 433 "MPLS Generic Associated Channel", RFC 5586, 434 DOI 10.17487/RFC5586, June 2009, 435 . 437 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 438 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 439 RFC 6790, DOI 10.17487/RFC6790, November 2012, 440 . 442 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 443 Morris, J., Hansen, M., and R. Smith, "Privacy 444 Considerations for Internet Protocols", RFC 6973, 445 DOI 10.17487/RFC6973, July 2013, 446 . 448 [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 449 and M. Bocci, "Signaling Entropy Label Capability and 450 Entropy Readable Label Depth Using IS-IS", RFC 9088, 451 DOI 10.17487/RFC9088, August 2021, 452 . 454 Appendix A. Working Group Adoption Comments 456 1. Normative Language 458 Use of the normative language, Terminology section in 459 particular. For example, in "There may be associated ancillary 460 data in the packet." 462 2. The NAS abbreviation 464 Network Action Sub-Stack is abbreviated as NAS. I think that 465 abbreviating as NASS or presenting the extended term as Network 466 Action Sub-stack improves correlation between the full form and 467 acronym. 469 3. non-use of NAS abbreviation 471 Also, I've noticed that NAS is not used throughout the document. 472 It might not be useful after all. 474 4. Section 3.2 typo 475 Perhaps a typo in the first requirement Section 3.2 s/and/an/ It 476 is not clear what "NAI is delivered to a node" might mean in the 477 requirement 5 of Section 3.2. Perhaps the next requirement is 478 sufficient and #5 can be removed from the document. 480 5. Extra words 482 Also, #5 seems like it has some extra wording. Perhaps s/in the 483 way in a way/in a way/? 485 6. Merging of drafts? 487 One thing I'm debating is whether draft-bryant-mpls-dev- 488 primer-01 - A Primer on the Development of MPLS (ietf.org) 489 should be merged with this draft? 491 7. ADI -> NAI 493 In this version the term "Ancillary Data Indicator" is changed 494 to "Network Action Indicator". While there is some difference 495 between the definition of the two terms: Ancillary Data 496 Indicator (ADI): A indicator in the MPLS label stack that 497 ancillary data exists in this packet. It MAY also indicate the 498 specific type of the ancillary data. Network Action Indication 499 (NAI): An indication in the packet that a certain network action 500 is to be performed. There may be associated ancillary data in 501 the packet. The above definition shows that ADI firstly is the 502 indicator of the existence of the ancillary data, and optionally 503 can be the indicator of specific type of ancillary data. While 504 NAI is only the indicator of a certain type of network action. 505 Thus NAI cannot replace ADI directly in this document. I'd 506 suggest to add the ADI back to the terminology section, and 507 change all the NAI in section 3.2 back to ADI. If needed, the 508 requirements on NAI can be added as separate items. 510 8. Addition to section 3.1 512 For backward compatibility and consistency, It is suggested to 513 add the below items to section 3.1 as general requirements: a) 514 Solutions meeting the requirements set out in this document MUST 515 be compatible with existing MPLS mechanisms. b) Solutions 516 meeting the requirements set out in this document MUST reuse 517 existing MPLS mechanisms when possible. c) For network actions 518 which are developed or under development in IETF, the encoding 519 and processing of the network action data MUST be reused. 521 9. Action Indicators without AD 522 Do not use the ADI for Network Actions that does not have 523 ancillary data, use NADI (non-ADI). 525 10. AD definition 527 I was under the impression reading Jie's note that actions 528 _itself_ are the Ancillary Data. Your definition of "Ancillary 529 Data" seems to be limited to action parameters or metadata which 530 is likely why you draw such conclusions. 532 11. Optional AD? 534 AD definition treats anything new to the current label stack as 535 an optional add-on == ancillary while NAI treats only optional 536 parameters or metadata associated with newly defined actions as 537 ancillary. 539 12. ADI and NAI are different 541 It is also my understanding that the definition of ADI and NAI 542 are different. ADI is used to indicate that there is 543 information in addition to the legacy label stack in the packet, 544 while NAI is used to indicate a certain type of network action. 545 The existence of NAI and the optional data associated with the 546 action need an indicator, which is the ADI. 548 13. Retire ADI 550 There is no need for an ancillary data indicator and we should 551 probably retire the term. 553 14. AD generic? 555 As Robert and I mentioned, the term ancillary data is generic 556 and refers to all types network actions information, including 557 those with and without additional action data. 558 Thus NAI can be considered as one type of ancillary data. 560 15. What ADI indicates 562 An ADI is the indicator of the presence of ANY non-label 563 information in the MPLS packet. Following it there may be 564 indicators of each specific network action. And my 565 understanding is the requirements in section 3.2 was mainly on 566 the ADI. 568 16. Common requirement to carry AD 569 According to the use cases collected, their common requirement 570 is to carry ancillary data in the data packet to affect the 571 packet forwarding or processing behavior, or the network states. 572 There is no specific requirement on where the ancillary data 573 should be put in the packet. Thus in the requirement document 574 it would be clear enough to just mention ancillary data and its 575 indicator (ADI). 577 17. Not discussed 579 We have not discussed changing ADI to NAI. 581 18. Discussed when draft presented in the Open DT 583 The change of ADI to NAI was presented when the new version of 584 the Framework were discussed in the Open DT. 586 19. Comment from Loa 588 I think both comment 17 and 18, could be misunderstod, yes the 589 NAI was introduced (for good reason) in new Framework, however 590 it does not in itself exclude have an ADI in a packet, only that 591 is not the all-emcompassing term that it was earlier. 593 20. Keep using ADI 595 My suggestions would be to keep using ADI for the generic 596 indicator, and could use NAI for the indicator of specific 597 action. I don'think we need to mention NAS here, which is 598 specific to ISD based solution. 600 21. Use of NSI 602 I propose Network Action Sub-stack Indcator (NSI) for this 603 purpose. 604 Proposed definition: An LSE used to indicate the presence of a 605 Network Action Sub-stack. 607 22. Revise definition of NAS 609 We should also revise the definition of NAS to use this (21). 611 23. Popping NAS 613 When you pop a stack in programming, the concept that MPLS 614 borrowed, you pop the procedure indicator and the procedure 615 parameters. This is consistent with popping an NAS 617 24. More than a name change 619 No it is more than just a name change. There is a concept 620 change and we re-wrote a bunch of text to align with the NAI 621 approach. For example an NAI may not have AD to indicate. 623 25. Writeable NAS 625 I have some further questions. NAS is something within the 626 label stack but writable by intermediate nodes. Is this the 627 stack operation? Besides, if NAS emerges at ToS, you said it'll 628 be popped and discarded. What if the NAS also needs to be 629 applied to the labels below it? Whatever measures you will take 630 here, are those the stack operations? 632 26. The NFRR use case 634 I have several questions about the NFRR use case. As I 635 understand it, a point of local repair (PLR) imposes NAS with 636 the NFRR indicator so that it becomes ToS at the merge node 637 (MN). If that is correct, then the MN will remove the NAS with 638 the NFRR indicator as the packet is returned on the "normal" 639 path. Hence, I don't see why an intermediate node would need to 640 write into an existing in the label stack NAS in support of 641 NFRR. 643 27. Intermediate node re-writing 645 I may not see a case for an intermediate node re-writing the 646 existing NAI. I think that the node should impose a new NAS. I 647 see the case for an intermediate node writing into PSD (e.g., 648 HbH IOAM though I think that is too expensive and the IOAM 649 Direct Export or Hybrid Two-Step are a better choice). To 650 summarize, I don't see the need for an intermediate node to 651 write into ISD and am open to discussing the node writing into 652 PSD. 654 28. Two types of indicators 656 One of my concern is that there are two types of indicators, and 657 they cannot be represented using the same term. - The first one 658 (call it indicator-1) is used to indicate the presence of any 659 non-forwarding-label information in the packet. As discussed it 660 may be realized as a bSPL. It does not indicate the type of 661 actions to be performed. - The second type of indicator (call 662 it indicator-2) is used to indicate the presence of a specific 663 type of action. Such action may or may not have associated data 664 with it. This may be realized as a Flag or an action type in 665 the packet. 667 29. Second term needed 669 do not understand why we need another term. We have not had a 670 situation where we wanted to refer to "NAS + PSD" and lacked a 671 term for it. 673 30. Propose text 675 That said, please feel free to propose a term and a definition. 676 I do not understand why we need another term. We have not had a 677 situation where we wanted to refer to "NAS + PSD" and lacked a 678 term for it. 680 That said, please feel free to propose a term and a definition. 682 31. NAS not general enough 684 Thus NAS is not general enough to cover the PSD. What we need 685 is a generic term to cover all the possible cases of ancillary 686 data. Furthermore, the indicator and the ancillary data would 687 need separate terms anyway and does not need to be coupled under 688 one term. 690 32. Use of ancillary data 692 * We are already using ancillary data for this purpose 694 * Exactly, and that' why we don't need to mention NAS in the 695 requirement document. 697 33. What the NAS contain 699 * Let me put it this way: By definition, NAS contains: ADI, 700 Optional NAI and Optional ISD. While what we want to refer 701 to with the term is: Optional NAI Optional ISD and Optional 702 PSD. Note it does not include the ADI. 704 * This is incorrect. It contains a network action sub-stack 705 indicator, network action indicators, and any in-stack 706 ancillary data (as defined by the specified network actions) 708 34. User-defined actions 710 user-defined network actions? Should we mentione in the 711 requirements doc? 713 35. draft-ietf-mpls-mna-requirements 715 I hope, if adopted, the filename can be adjusted to use MRN not 716 MIAD-ADI. 718 Comment from Loa: I think the filename we are considering is: 719 draft-ietf-mpls-mna-requirements 721 36. In the Abstract (1) 723 This work is the product of the IETF MPLS Open Design Team. 725 Before posting as a Working Group draft, this sentence needs to 726 be removed. It's OK to say something in the Acknowledgements. 728 Loa: Depending on what is meant by "before", I have a comment on 729 this, just because info is at the wrong place it should not be 730 considered "blocking" and could be update at any time. 731 Personally I think working group draft version -01 would be a 732 good place to do this update. 734 37. In the Abstract (2) 736 The term "application data" may be (is) confusing. While you 737 probably mean it to imply an application of MPLS, it may be 738 confused with the type of application that runs end-to-end 739 (i.e., on a host). Although, reading some of the text, it does 740 feel like some of the time you _are_ intending to imply that the 741 application software may somehow be able to provide the 742 ancillary data that is ultimately carried by MPLS. 744 I think, in the Abstract, you could say... 746 based on ancillary data that may be carried in or below the 747 bottom of the label stack. 749 ...but you should probably look through the rest of the text and 750 consider the use of the word "application." Maybe one approach 751 would be to specifically call out the term near the top of the 752 document in order to correctly set the context. 754 38. In section 1 (1). 756 is then processed using mechanisms implemented by intermediate 757 and/or egress LSRs that comply with the MPLS base architecture 758 and potentially its extensions, including (but not limited to) 759 [RFC3031], [RFC3032],[RFC6790]. 761 This sounds like the mechanisms to process the ancillary data 762 are already specified in those RFCs, but (of course) that's not 763 the case. 765 You are probably making a point about the nodes being "MPLS" and 766 also saying something about backward compatibility of the 767 mechanism. But it should be clear that only nodes that contain 768 new functionality will be able to recognise and process 769 ancillary data. 771 39. In section 1 (2). 773 This draft specifies 775 Say 'document' so that you are future-proofed for publication as 776 an RFC. 778 40. In section 1.1 (1) 780 s/an Label/a Label/ s/perfomed/performed/ 782 41. In section 1.1 (2). 784 * Network Action: An operation to be performed on a packet. A 785 network action may affect router state, packet forwarding, or 786 it may affect the packet in some other way. 788 If the operation affects router state, is it really performed on 789 the packet? 791 42. In section 1.1 (3) 793 * Network Action Indication (NAI): An indication in the packet 794 that a certain network action is to be perfomed. There may 795 be associated ancillary data in the packet 797 * Network Action Sub-Stack (NAS): A set of related, contiguous 798 Label Stack Entries (LSEs). The first LSE contains the NAI. 799 The TC and TTL values in the sub-stack may be redefined. 801 The first bullet simply says that the NAI is "in the packet", 802 but the second bullet goes on to define where/how it is carried. 803 I would say that it is totally irrelevant to the _requirements_ 804 how the NAI is encoded/carried (although there may be some 805 requirements that limit the options). But I note that there is 806 no further mention of the NAS or of a "sub-stack". I suggest 807 removing this second bullet. 809 43. In section 1.1 (4) 811 * In-Stack Data: Any data within the MPLS label stack including 812 the outer LSE and the bottom of stack (the LSE with the S-bit 813 set). 815 * Post-Stack Data: Any data beyond the LSE with the S-Bit set, 816 but before the first octet of the user payload. This 817 document does not prescribe whether post-stack data precedes 818 or follows any other protocol structure such as a control 819 word or associated channel header (ACH). 821 Does "any data" mean "any ancillary data"? 823 44. In section 1.2 (1) 825 s/number of new proposals/number of proposals/ 827 45. In Section 1.2 (2) 829 for example In-situ OAM and Service Function Chaining (SFC) 831 Might benefit from references for iOAM and SFC. 833 46. In section 1.2 (3) 835 [I-D.song-mpls-extension-header] summarises some of the issues 836 with existing solutions to address these new applications (note 837 that this document draws on the requirements and issues without 838 endorsing a specific solution from 839 [I-D.song-mpls-extension-header]): 841 This gives more emphasis to the referenced draft than I think 842 you intend. If you intend that people read that draft to see 843 the issues, it is a normative reference. But if you are just 844 mentioning it and have pulled the information into this 845 document, then you need to reduce the emphasis. How about... 847 [I-D.song-mpls-extension-header] sets out some of the issues in 848 how existing solutions address these new applications. This 849 document draws on the requirements and issues noted in that 850 document without endorsing any specific solution. 852 47. Section 2 854 While I understand the desire to express the requirements in 855 definitive language, BCP14 is not about requirements. Rather it 856 is intended to describe implementation behaviours. 858 A way around this that is often used is to include a subsequent 859 paragraph such as... 861 Although this document is not a protocol specification, this 862 convention is adopted for clarity of description of 863 requirements. 865 See, for example, RFC 4139, RFC 4687, or RFC 5862. 867 48. In section 3.2 (1) 869 s/and indicator/an indicator/ 871 49. In section 3.2 (2) 873 (2). An MPLS Network Action MUST specify whether ancillary data 874 is required in the label stack and/or post-stack data. 876 Do you mean this, or do you mean that this must be specified in 877 the documentation of the NA? 879 50. In section 3.2 (1) 881 (3). Any solution MUST respect the principle that Special 882 Purpose Labels are the mechanism of last resort and therefore 883 must minimise the number of new SPLs that are allocated. 885 Presumably a minimum here would be zero? 887 Loa: No we have considere this and decided that there is room to 888 specify 1 bSPL for MNA. 890 Loa: I also think that we should s/Special Purpose Labels/Base 891 Special-Purpose Labels Note: for the Extended SPLs there sare no 892 such reestriction. 894 51. In section 3.2 bullet 5 896 s/in the way in a way/in a way/ 898 52. In section 3.2 (bullet, 5, 6 and 10) 900 Bullet 10 is a wholly contained subset of bullet 5. Actually, 901 bullet 10 is a wholly contained subset of bullet 6. Makes me 902 think that bullets 5 and 6 possibly say the same thing as each 903 other. 905 53. In section 3.2 (2) 906 (11). NAIs SHOULD be supported for both P2P and P2MP paths, but 907 any specific NAI may only be supported for one or the other. 909 Really? You can't have an NAI that is equally applicable for 910 both P2P and P2MP? Seems an odd restriction to impose. 912 54. In section 3.2 (3) 914 (15). NAIs can only be inserted at LERs, but MAY be processed 915 at LSRs and LERs. If it is required to insert an NAI at a 916 transit LSR on an LSP, then a new label stack MUST be pushed. 918 What does it mean to push a new label stack? If you mean that 919 we should support "MPLS in MPLS" encapsulation so that the 920 packet has two bottom of stack bits set, I should point out that 921 this was previously discussed and abandoned because the presence 922 of an LSE immediately after a set bottom of stack bit was 923 considered unacceptable because of the assumptions made by 924 existing hardware about what follows the bottom of stack. 926 55. In section 3.2 (4) 928 (19). Any specification of a solution that inserts or modifies 929 the NAI MUST discuss the possible ECMP consequences. 931 This seems to at least partially contradict 3.2/15 933 It is also not clear what it means "to modify an indication in 934 the packet that a certain network action is to be performed". I 935 guess it means to remove the NAI? 937 56. In section 3.3 (1) 939 (3.3/1) is surely already covered by 3.3/4 941 57. In section 3.3 (2) 943 (3.3/3) seems to be unnecessary given 3.3/1 945 58. Semantic Routing 947 I think the proposal here falls in the scope of "Semantic 948 Routing". That is, adding information to packets so that the 949 forwarding decisions may be enhanced to act not just on the 950 destination address or next hop label, but also on the 951 additional information. The precise forwarding action may be 952 known by the forwarders by definition (such as a protocol 953 specification), installed by a routing engine according to a 954 routing algorithm acting on information exchanged by routing 955 protocols, or programmed into the forwarder from a management or 956 orchestration system. 958 We wrote an introduction to the idea of Semantic Routing draft- 959 farrel-irtf-introduction-to-semantic -routing which you can look 960 at if you want some context. 962 We also set out to examine the challenges and concerns 963 introduced by Semantic Routing in draft-king-irtf-challenges-in- 964 routing and I think it would be good if this work was calibrated 965 against those challenges. 967 Loa: While semantic routing is intresting, and good be 968 "calibrated" against MNA as a whole (guiding documents and 969 solutions), I think it is out of scope for the requirement 970 document. 972 59. Understanding of Use Cases 974 I would think that a more detailed an understanding of the use 975 cases is needed before moving ahead with the requirements. I 976 wouldn't go as far as saying that the use cases need to be 977 referenced normatively, but I do think they need a little more 978 attention from the WG to motivate actually adopting this work. 979 That is, this document shows what we might need to do, but 980 without the use cases, we would be doing it "because we can" and 981 "because it might be useful one day." Those are not, I think 982 really good reasons to make fairly substantial changes to 983 deployed forwarding paradigms. 985 This is not to say that I dispute that there may be some 986 valuable use cases, but that the WG needs to agree which ones 987 are important in order to be sure that the requirements are on 988 target. 990 60. Conflicting text in document 992 I'm puzzled that some of the text in this document appears to 993 limit itself to cases that require ancillary data, while other 994 parts also consider the requirements for network functions that 995 don't require ancillary data, but do still need to be encoded in 996 the label stack in some way. I suspect this is just editorial, 997 but while the document title is "Requirements for MPLS Network 998 Action Indicators and MPLS Ancillary Data" the Abstract says 999 "This draft specifies requirements for indicators in the MPLS 1000 label stack to support ancillary data in the packet and high 1001 level requirements on that ancillary data," and the Introduction 1002 seems entirely focused on the ancillary data case. 1004 It would be good to be clear, at the point of adoption, which 1005 way we are jumping on this question. 1007 draft-andersson-mpls-mna-fwk 1009 seems to be fully behind network actions some of which may also 1010 require ancillary data. 1012 Perhaps this document should reference that one for additional 1013 information? 1015 61. Loa: I have been thinking about a short text (1 or 2 paragraphs) 1016 on how the guiding documents fit togehter that should appear, 1017 e.g. in the introduction of all 3 documents. It could be added 1018 later in the process, but should be there when the documents go 1019 to wglc. Let me know if there are someone that will help work 1020 on this, 1022 Authors' Addresses 1024 Matthew Bocci 1025 Nokia 1027 Email: matthew.bocci@nokia.com 1029 Stewart Bryant 1030 University of Surrey 5GIC 1032 Email: sb@stewartbryant.com