List of outstanding comments on MNA requirement draft: 1. Normative Language ------------------ Use of the normative language, Terminology section in particular. For example, in "There may be associated ancillary data in the packet." 2. The NAS abbreviation -------------------- Network Action Sub-Stack is abbreviated as NAS. I think that abbreviating as NASS or presenting the extended term as Network Action Sub-stack improves correlation between the full form and acronym. 3. non-use of NAS abbreviation --------------------------- Also, I've noticed that NAS is not used throughout the document. It might not be useful after all. 4. Section 3.2 typo ---------------- Perhaps a typo in the first requirement Section 3.2 s/and/an/ It is not clear what "NAI is delivered to a node" might mean in the requirement 5 of Section 3.2. Perhaps the next requirement is sufficient and #5 can be removed from the document. 5. Extra words ----------- Also, #5 seems like it has some extra wording. Perhaps s/in the way in a way/in a way/? 6. Merging of drafts? ------------------ One thing I'm debating is whether draft-bryant-mpls-dev-primer-01 - A Primer on the Development of MPLS (ietf.org) should be merged with this draft? 7. ADI -> NAI ---------- In this version the term "Ancillary Data Indicator" is changed to "Network Action Indicator". While there is some difference between the definition of the two terms: Ancillary Data Indicator (ADI): A indicator in the MPLS label stack that ancillary data exists in this packet. It MAY also indicate the specific type of the ancillary data. Network Action Indication (NAI): An indication in the packet that a certain network action is to be performed. There may be associated ancillary data in the packet. The above definition shows that ADI firstly is the indicator of the existence of the ancillary data, and optionally can be the indicator of specific type of ancillary data. While NAI is only the indicator of a certain type of network action. Thus NAI cannot replace ADI directly in this document. I'd suggest to add the ADI back to the terminology section, and change all the NAI in section 3.2 back to ADI. If needed, the requirements on NAI can be added as separate items. 8. Addition to section 3.1 ----------------------- For backward compatibility and consistency, It is suggested to add the below items to section 3.1 as general requirements: a) Solutions meeting the requirements set out in this document MUST be compatible with existing MPLS mechanisms. b) Solutions meeting the requirements set out in this document MUST reuse existing MPLS mechanisms when possible. c) For network actions which are developed or under development in IETF, the encoding and processing of the network action data MUST be reused. 9. Action Indicators without AD ---------------------------- Do not use the ADI for Network Actions that does not have ancillary data, use NADI (non-ADI). 10. AD definition ------------- I was under the impression reading Jie's note that actions *itself* are the Ancillary Data. Your definition of "Ancillary Data" seems to be limited to action parameters or metadata which is likely why you draw such conclusions. 11. Optional AD? ------------ AD definition treats anything new to the current label stack as an optional add-on == ancillary while NAI treats only optional parameters or metadata associated with newly defined actions as ancillary. 12. ADI and NAI are different ------------------------- It is also my understanding that the definition of ADI and NAI are different. ADI is used to indicate that there is information in addition to the legacy label stack in the packet, while NAI is used to indicate a certain type of network action. The existence of NAI and the optional data associated with the action need an indicator, which is the ADI. 13. Retire ADI ---------- there is no need for an ancillary data indicator and we should probably retire the term. 14. AD generic? ----------- As Robert and I mentioned, the term ancillary data is generic and refers to all types network actions information, including those with and without additional action data. Thus NAI can be considered as one type of ancillary data. 15. What ADI indicates ----------------- And ADI is the indicator of the presence of ANY non-label information in the MPLS packet. Following it there may be indicators of each specific network action. And my understanding is the requirements in section 3.2 was mainly on the ADI. 16. Common requirement to carry AD ------------------------------ According to the use cases collected, their common requirement is to carry ancillary data in the data packet to affect the packet forwarding or processing behavior, or the network states. There is no specific requirement on where the ancillary data should be put in the packet. Thus in the requirement document it would be clear enough to just mention ancillary data and its indicator (ADI). 17. Not discussed ------------- We have not discussed changing ADI to NAI. 18. Discussed when draft presented in the Open DT --------------------------------------------- The change of ADI to NAI was presented when the new version of the Framework were discussed in the Open DT. 19. Comment from Loa ---------------- I think both comment 17 and 18, could be misunderstod, yes the NAI was introduced (for good reason) in new Framework, however it does not in itself exclude have an ADI in a packet, only that is not the all-emcompassing term that it was earlier. 20. Keep using ADI -------------- My suggestions would be to keep using ADI for the generic indicator, and could use NAI for the indicator of specific action. I don’think we need to mention NAS here, which is specific to ISD based solution. 21. Use of NSI ---------- I propose Network Action Sub-stack Indcator (NSI) for this purpose. Proposed definition: An LSE used to indicate the presence of a Network Action Sub-stack. 22. Revise definition of NAS ----------------------- We should also revise the definition of NAS to use this (21). 23. Popping NAS ----------- When you pop a stack in programming, the concept that MPLS borrowed, you pop the procedure indicator and the procedure parameters. This is consistent with popping an NAS 24. More than a name change ----------------------- No it is more than just a name change. There is a concept change and we re-wrote a bunch of text to align with the NAI approach. For example an NAI may not have AD to indicate. 25. Writeable NAS ------------- I have some further questions. NAS is something within the label stack but writable by intermediate nodes. Is this the stack operation? Besides, if NAS emerges at ToS, you said it’ll be popped and discarded. What if the NAS also needs to be applied to the labels below it? Whatever measures you will take here, are those the stack operations? 26. The NFRR use case ----------------- I have several questions about the NFRR use case. As I understand it, a point of local repair (PLR) imposes NAS with the NFRR indicator so that it becomes ToS at the merge node (MN). If that is correct, then the MN will remove the NAS with the NFRR indicator as the packet is returned on the "normal" path. Hence, I don't see why an intermediate node would need to write into an existing in the label stack NAS in support of NFRR. 27. Intermediate node re-writing ---------------------------- I may not see a case for an intermediate node re-writing the existing NAI. I think that the node should impose a new NAS. I see the case for an intermediate node writing into PSD (e.g., HbH IOAM though I think that is too expensive and the IOAM Direct Export or Hybrid Two-Step are a better choice). To summarize, I don't see the need for an intermediate node to write into ISD and am open to discussing the node writing into PSD. 28. Two types of indicators ----------------------- One of my concern is that there are two types of indicators, and they cannot be represented using the same term. - The first one (call it indicator-1) is used to indicate the presence of any non-forwarding-label information in the packet. As discussed it may be realized as a bSPL. It does not indicate the type of actions to be performed. - The second type of indicator (call it indicator-2) is used to indicate the presence of a specific type of action. Such action may or may not have associated data with it. This may be realized as a Flag or an action type in the packet. 29. Second term needed ------------------ do not understand why we need another term. We have not had a situation where we wanted to refer to “NAS + PSD” and lacked a term for it. 30. Propose text ------------ That said, please feel free to propose a term and a definition. I do not understand why we need another term. We have not had a situation where we wanted to refer to “NAS + PSD” and lacked a term for it. That said, please feel free to propose a term and a definition. 31. NAS not general enough ---------------------- Thus NAS is not general enough to cover the PSD. What we need is a generic term to cover all the possible cases of ancillary data. Furthermore, the indicator and the ancillary data would need separate terms anyway and does not need to be coupled under one term. 32. Use of ancillary data -------------------- - We are already using ancillary data for this purpose - Exactly, and that’ why we don’t need to mention NAS in the requirement document. 33. What the NAS contain -------------------- - Let me put it this way: By definition, NAS contains: ADI, Optional NAI and Optional ISD. While what we want to refer to with the term is: Optional NAI Optional ISD and Optional PSD. Note it does not include the ADI. - This is incorrect. It contains a network action sub-stack indicator, network action indicators, and any in-stack ancillary data (as defined by the specified network actions) 34. User-defined actions -------------------- user-defined network actions? Should we mentione in the requirements doc? 35. draft-ietf-mpls-mna-requirements -------------------------------- I hope, if adopted, the filename can be adjusted to use MRN not MIAD-ADI. Comment from Loa: I think the filename we are considering is: draft-ietf-mpls-mna-requirements 36. In the Abstract (1) ------------------- This work is the product of the IETF MPLS Open Design Team. Before posting as a Working Group draft, this sentence needs to be removed. It's OK to say something in the Acknowledgements. Loa: Depending on what is meant by "before", I have a comment on this, just because info is at the wrong place it should not be considered "blocking" and could be update at any time. Personally I think working group draft version -01 would be a good place to do this update. 37. In the Abstract (2) ------------------- The term "application data" may be (is) confusing. While you probably mean it to imply an application of MPLS, it may be confused with the type of application that runs end-to-end (i.e., on a host). Although, reading some of the text, it does feel like some of the time you *are* intending to imply that the application software may somehow be able to provide the ancillary data that is ultimately carried by MPLS. I think, in the Abstract, you could say... based on ancillary data that may be carried in or below the bottom of the label stack. ...but you should probably look through the rest of the text and consider the use of the word "application." Maybe one approach would be to specifically call out the term near the top of the document in order to correctly set the context. 38. In section 1 (1). ----------------- is then processed using mechanisms implemented by intermediate and/or egress LSRs that comply with the MPLS base architecture and potentially its extensions, including (but not limited to) [RFC3031], [RFC3032], [RFC6790]. This sounds like the mechanisms to process the ancillary data are already specified in those RFCs, but (of course) that's not the case. You are probably making a point about the nodes being "MPLS" and also saying something about backward compatibility of the mechanism. But it should be clear that only nodes that contain new functionality will be able to recognise and process ancillary data. 39. In section 1 (2). ---------------- This draft specifies Say 'document' so that you are future-proofed for publication as an RFC. 40. In section 1.1 (1) ------------------ s/an Label/a Label/ s/perfomed/performed/ 41. In section 1.1 (2). ------------------- o Network Action: An operation to be performed on a packet. A network action may affect router state, packet forwarding, or it may affect the packet in some other way. If the operation affects router state, is it really performed on the packet? 42. In section 1.1 (3) ------------------ o Network Action Indication (NAI): An indication in the packet that a certain network action is to be perfomed. There may be associated ancillary data in the packet o Network Action Sub-Stack (NAS): A set of related, contiguous Label Stack Entries (LSEs). The first LSE contains the NAI. The TC and TTL values in the sub-stack may be redefined. The first bullet simply says that the NAI is "in the packet", but the second bullet goes on to define where/how it is carried. I would say that it is totally irrelevant to the *requirements* how the NAI is encoded/carried (although there may be some requirements that limit the options). But I note that there is no further mention of the NAS or of a "sub-stack". I suggest removing this second bullet. 43. In section 1.1 (4) ------------------ o In-Stack Data: Any data within the MPLS label stack including the outer LSE and the bottom of stack (the LSE with the S-bit set). o Post-Stack Data: Any data beyond the LSE with the S-Bit set, but before the first octet of the user payload. This document does not prescribe whether post-stack data precedes or follows any other protocol structure such as a control word or associated channel header (ACH). Does "any data" mean "any ancillary data"? 44. In section 1.2 (1) ------------------ s/number of new proposals/number of proposals/ 45. In Section 1.2 (2) ------------------ for example In-situ OAM and Service Function Chaining (SFC) Might benefit from references for iOAM and SFC. 46. In section 1.2 (3) ------------------ [I-D.song-mpls-extension-header] summarises some of the issues with existing solutions to address these new applications (note that this document draws on the requirements and issues without endorsing a specific solution from [I-D.song-mpls-extension-header]): This gives more emphasis to the referenced draft than I think you intend. If you intend that people read that draft to see the issues, it is a normative reference. But if you are just mentioning it and have pulled the information into this document, then you need to reduce the emphasis. How about... [I-D.song-mpls-extension-header] sets out some of the issues in how existing solutions address these new applications. This document draws on the requirements and issues noted in that document without endorsing any specific solution. 47. Section 2 ------------- While I understand the desire to express the requirements in definitive language, BCP14 is not about requirements. Rather it is intended to describe implementation behaviours. A way around this that is often used is to include a subsequent paragraph such as... Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements. See, for example, RFC 4139, RFC 4687, or RFC 5862. 48. In section 3.2 (1) ------------------ s/and indicator/an indicator/ 49. In section 3.2 (2) ------------------ 2. An MPLS Network Action MUST specify whether ancillary data is required in the label stack and/or post-stack data. Do you mean this, or do you mean that this must be specified in the documentation of the NA? 50. In section 3.2 (1) ------------------ 3. Any solution MUST respect the principle that Special Purpose Labels are the mechanism of last resort and therefore must minimise the number of new SPLs that are allocated. Presumably a minimum here would be zero? Loa: No we have considere this and decided that there is room to specify 1 bSPL for MNA. Loa: I also think that we should s/Special Purpose Labels/Base Special-Purpose Labels Note: for the Extended SPLs there sare no such reestriction. 51. In section 3.2 bullet 5 ----------------------- s/in the way in a way/in a way/ 52. In section 3.2 (bullet, 5, 6 and 10) ------------------------------------ Bullet 10 is a wholly contained subset of bullet 5. Actually, bullet 10 is a wholly contained subset of bullet 6. Makes me think that bullets 5 and 6 possibly say the same thing as each other. 53. In section 3.2 (2) ------------------ 11. NAIs SHOULD be supported for both P2P and P2MP paths, but any specific NAI may only be supported for one or the other. Really? You can't have an NAI that is equally applicable for both P2P and P2MP? Seems an odd restriction to impose. 54. In section 3.2 (3) ------------------ 15. NAIs can only be inserted at LERs, but MAY be processed at LSRs and LERs. If it is required to insert an NAI at a transit LSR on an LSP, then a new label stack MUST be pushed. What does it mean to push a new label stack? If you mean that we should support "MPLS in MPLS" encapsulation so that the packet has two bottom of stack bits set, I should point out that this was previously discussed and abandoned because the presence of an LSE immediately after a set bottom of stack bit was considered unacceptable because of the assumptions made by existing hardware about what follows the bottom of stack. 55. In section 3.2 (4) ------------------ 19. Any specification of a solution that inserts or modifies the NAI MUST discuss the possible ECMP consequences. This seems to at least partially contradict 3.2/15 It is also not clear what it means "to modify an indication in the packet that a certain network action is to be performed". I guess it means to remove the NAI? 56. In section 3.3 (1) ------------------ 3.3/1 is surely already covered by 3.3/4 57. In section 3.3 (2) ------------------ 3.3/3 seems to be unnecessary given 3.3/1 58. Semantic ROuting --------------------- I think the proposal here falls in the scope of "Semantic Routing". That is, adding information to packets so that the forwarding decisions may be enhanced to act not just on the destination address or next hop label, but also on the additional information. The precise forwarding action may be known by the forwarders by definition (such as a protocol specification), installed by a routing engine according to a routing algorithm acting on information exchanged by routing protocols, or programmed into the forwarder from a management or orchestration system. We wrote an introduction to the idea of Semantic Routing https://datatracker.ietf.org/doc/draft-farrel-irtf-introduction- to-semantic -routing/ which you can look at if you want some context. We also set out to examine the challenges and concerns introduced by Semantic Routing in https://datatracker.ietf.org/doc/draft-king-irtf-challenges- in-routing/ and I think it would be good if this work was calibrated against those challenges. Loa: While semantic routing is intresting, and good be "calibrated" against MNA as a whole (guiding documents and solutions), I think it is out of scope for the requirement document. 59. Understanding of Use Cases -------------------------- I would think that a more detailed an understanding of the use cases is needed before moving ahead with the requirements. I wouldn't go as far as saying that the use cases need to be referenced normatively, but I do think they need a little more attention from the WG to motivate actually adopting this work. That is, this document shows what we might need to do, but without the use cases, we would be doing it "because we can" and "because it might be useful one day." Those are not, I think really good reasons to make fairly substantial changes to deployed forwarding paradigms. This is not to say that I dispute that there may be some valuable use cases, but that the WG needs to agree which ones are important in order to be sure that the requirements are on target. 60. Conflicting text in document -------------------------------- I'm puzzled that some of the text in this document appears to limit itself to cases that require ancillary data, while other parts also consider the requirements for network functions that don't require ancillary data, but do still need to be encoded in the label stack in some way. I suspect this is just editorial, but while the document title is "Requirements for MPLS Network Action Indicators and MPLS Ancillary Data" the Abstract says "This draft specifies requirements for indicators in the MPLS label stack to support ancillary data in the packet and high level requirements on that ancillary data," and the Introduction seems entirely focused on the ancillary data case. It would be good to be clear, at the point of adoption, which way we are jumping on this question. https://datatracker.ietf.org/doc/draft-andersson-mpls-mna-fwk/ seems to be fully behind network actions some of which may also require ancillary data. Perhaps this document should reference that one for additional information? 61. Loa: I have been thinking about a short text (1 or 2 paragraphs) on how the guiding documents fit togehter that should appear, e.g. in the introduction of all 3 documents. It could be added later in the process, but should be there when the documents go to wglc. Let me know if there are someone that will help work on this,