[mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments
Adrian Farrel <adrian@olddog.co.uk> Tue, 26 July 2022 22:14 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4B0C16ECB3; Tue, 26 Jul 2022 15:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfVVcsEu7ZdC; Tue, 26 Jul 2022 15:14:16 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0B3C16ECA4; Tue, 26 Jul 2022 15:14:14 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 26QMEBdX024060; Tue, 26 Jul 2022 23:14:11 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 34BEE4604B; Tue, 26 Jul 2022 23:14:11 +0100 (BST)
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 14DD446048; Tue, 26 Jul 2022 23:14:11 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS; Tue, 26 Jul 2022 23:14:11 +0100 (BST)
Received: from LAPTOPK7AS653V (dhcp-915d.meeting.ietf.org [31.133.145.93]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 26QME9BJ002588 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jul 2022 23:14:10 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-mpls-mna-requirements@ietf.org
Cc: mpls@ietf.org
Date: Tue, 26 Jul 2022 23:14:08 +0100
Organization: Old Dog Consulting
Message-ID: <06b701d8a13d$078d7e20$16a87a60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Adig/fuWZAc9De/ASQegN3/GPHBcbQ==
Content-Language: en-gb
X-Originating-IP: 31.133.145.93
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27040.003
X-TM-AS-Result: No--15.919-10.0-31-10
X-imss-scan-details: No--15.919-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27040.003
X-TMASE-Result: 10--15.918700-10.000000
X-TMASE-MatchedRID: XafQxseY2Bpgrjeh0lt2oIh/ebSxR/HnQR7lWMXPA1uFrpKurycGpZ7V Ny7+UW/9Xd7x++wtMvOWKEaQDHJkJoxpy4UOhqKr9Ib/6w+1lWTLa0eANE7Nz8boqPA6+88kI0y /lrQB4EOY5cvP7IrCcsc6RxaSHnv1vUxpsK1XD0tM7OLvNT++6TPRJAFM8pbhRZrOmBLNtw97cP UtfVgZLoSbWwTw5+yb9k0SD493dEcEIbfwCb92vYipvyKe+5UfUXlp1FHYSPWtBiS9hFeaTPAF4 3IXaj2gcHxFOYqCv3WmLIcc9IKdsNHRwU7yJMnMJmbrB1j4XwqlY4F8r0vXP2z3xnx8b/qRGSYb lrVFQLiXmPmCXqyOBTZB5rPgJpoqYdkdQa+cFKHX3j/lf1V8LN0pE2POjYg4yD259qEIabX/7Cp WnzSe27yxEvuWYPBqs3gZaLIY9nqZNo/wN8EMBUfhraIl1Xgxqr0Np6cKdO4oiFyh1jyXYVN9VN GAXlqCKFLstu6pCmLSxbPCIkQomAYU8o3sAyqyn6y0mNkW0aSdOLV5GEFw53vHxBKEEz6gRK7LD EHcSORrPg89NCqC9gzaHQtsXcxJByI+GlhTO0SYh7QjWI3JDBHlzzcojFNOMzH984sxnCo5d9n0 4fLNZj7Abily5v+L93OrJtU9s7eQ3eZOHQJIQesLOhZcNxRi5nHVd3/TU1vdym7nj6iFqvkXRyK NxjE+bxaY8x1C0vCXhy+IQjYeYCzTDssIplz2CKFDk1kJexKOQOsE4nDCdGuyajlFLKLVz69Ha2 fEinGHoEtOuywsRkGxndopM1xQqf8Hy2aCI2meAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtlExlQIQeRG0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Baaszqs65sfTerrEa1iX9znUfEk>
Subject: [mpls] Closing on draft-ietf-mpls-mna-requirements adoption poll comments
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2022 22:14:21 -0000
Hi authors, Thanks for your work in advancing this document and especially for collating the adoption poll comments in the Appendix. I agree that this Appendix can now be removed, but concurrent with that I thought it would be helpful to review your resolutions of the comments. It's not clear who raised which comments, but I'm considering them all here. Cheers, Adrian === 1. Normative Language [AF] OK with resolution 2. The NAS abbreviation [AF] OBE per 3 3. non-use of NAS abbreviation [AF] OK with resolution 4. Section 3.2 typo [AF] OK with resolution 5. Extra words [AF] OK with resolution 6. Merging of drafts? [AF] OK with resolution 7. ADI -> NAI [AF] OK with resolution 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. Ed.> Requirements 1-4 already cover points a and b. C is outside the scope of this document but we are not intending to limit or prescribe anything about existing standards. [AF] I disagree that 3.1#1 is related to backward compatibility. It talks about how the resultant solution must enable the functions currently available in MPLS: that is not backward compatibility. [AF] I disagree that 3.1#2 is about backward compatibility. It talks about how the resultant architecture must remain generally applicable, but it does not talk about backward compatibility. [AF] I disagree that 3.1#3 is about backward compatibility. It talks about extensions not being incompatible with the architecture, but it does not imply backward compatibility. [AF] Item 3.1#4 might be interpreted as being about backward compatibility, but it is not quite clear that "coexist with" and "not obsolete" actually means backward compatibility. That may be the authors' intention, but backward compatibility would also mean that a legacy implementation encountering a solution to these requirements must not have an undesired response or there must be a way to prevent such an implementation seeing such an encounter. [AF] However, 3.3#2 and 3.3#3 do seem to cover this. So no further action. 9. Action Indicators without AD [AF] OBE see #13 10. AD definition [AF] OK with resolution 11. Optional AD? [AF] OK with resolution 12. ADI and NAI are different [AF] OBE see #13 13. Retire ADI [AF] OK with resolution 14. AD generic? [AF] OK with resolution 15. What ADI indicates [AF] OBE see #13 16. Common requirement to carry AD [AF] OK with resolution 17. Not discussed [AF] OBE see #13 18. Discussed when draft presented in the Open DT [AF] OBE see #13 19. Comment from Loa [AF] OK with resolution 20. Keep using ADI [AF] OK with resolution 21. Use of NSI [AF] OBE 22. Revise definition of NAS [AF] OK with resolution 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 Ed.> No action [AF] I think that what is hiding in this issue is a description of what is required to happen to the ancillary data when the NAI is popped. [AF] It looks like there is a requirement to "remove the whole block" (per Kireeti's presentation today). That takes care of in-stack data and the NAI. [AF] Something needs to be said about the post-stack data (that may be that a solution may choose to leave it in place or strip it or null it). 24. More than a name change [AF] OK with resolution 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? Ed.> NAS has been removed. [AF] The fact that the term "NAS" has been removed is not material to this point. You could re-read this issues with s/NAS/NAI and in-stack AD/ [AF] Thus the question is about whether actions indicated higher up the stack can apply to hops lower down the stack. If so, there is a need to "move" the NAI and in-stack AD when it gets to top of stack. 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. Ed.> NFRR is not discussed in this draft. [AF] The point of the comment is to understand whether there is *any* motivation for allowing an intermediate node to write into an existing in-stack NAS or insert a new one. The requirements should be motivated by use cases, and the comment says that this use case does not motivate this requirement. See also #25 [AF] 3.3#1 certainly implies that NAIs and in-stack AD can be inserted by intermediate nodes. [AF] But see #27 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. Ed.> Added a requirement that network action specifications must describe whether ISD can be rewritten by an intermediate node. [AF] This is 3.3#16 [AF] But, per #26, his seems to be hiding from the debate! You have allowed "rewrite" without any specific use case that motivates it. Are there any implications of "rewrite" or does it come for free? If it's free, why do we even need to worry about the NA spec having to say yes or no? If there are implications we should call them out, and consider whether we don't actually want to rule out this "option". 28. Two types of indicators [AF] OK with resolution 29. Second term needed [AF] See #30 30. Propose text [AF] OK with resolution 31. NAS not general enough [AF] OK with resolution 32. Use of ancillary data [AF] OK with resolution 33. What the NAS contain [AF] OK with resolution 34. User-defined actions user-defined network actions? Should we mentione in the requirements doc? Ed.> The allocation policy should be specified in the draft that defines the IANA registry for the NAIs. [AF] You have 3.3#19 covers this more precisely by saying that user-defined NAs MAY be supported. No further action 35. draft-ietf-mpls-mna-requirements [AF] OK with resolution 36. In the Abstract (1) [AF] OK with resolution 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. Ed> OK agreed. [AF] The Abstract is now clean, thanks. [AF] Section 1.2 still talks about "applications" without qualifying the meaning. 38. In section 1 (1). [AF] OK with resolution 39. In section 1 (2). [AF] OK with resolution 40. In section 1.1 (1) [AF] OK with resolution 41. In section 1.1 (2). * 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? Ed.> Yes. [AF] Oh no it isn't! Router state is something held in the router and so the action is "instructed," "motivated," or "indicated" by the packet, but not performed *on* the packet. [AF] This issue is not resolved. It is *probably* only editorial, but until resolved it's not clear whether it is technical. 42. In section 1.1 (3) [AF] OK with resolution [AF] But note that the framework (and in-meeting discussion from Tarek) refers to the NAS 43. In section 1.1 (4) [AF] OK with resolution 44. In section 1.2 (1) s/number of new proposals/number of proposals/ [AF] Does not seem to have been applied 45. In Section 1.2 (2) for example In-situ OAM and Service Function Chaining (SFC) Might benefit from references for iOAM and SFC. [AF] Does not seem to have been applied 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. Ed.> New text is virtually identical. The existing text is fine and is not intended to be normative. [AF] If the new text is virtually identical, why do you object to the change? 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. Ed> Despite what BCP14 says, there is a long standing convention of using must and should in requirements documents because they specify requirements on protocol design. Suggest no change to the existing text. [AF] The convention extends to adding the proposed text. Why do you object to it? 48. In section 3.2 (1) [AF] OK with resolution 49. In section 3.2 (2) [AF] OK with resolution 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. Ed.> Existing text is fine. [AF] The existing text is not fine according to this definition. "Minimise" means "strive for as low a number as possible". Zero would be such a number. [AF] You mean "strive for no more than 1 bSPL". 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. Ed.> Existing text is fine. [AF] I agree with Loa that it is helpful to not use the term SPL unless that is what is meant. In this case, what is meant is bSPL (i.e., not eSPL): if the solution were to use a dozen ePSLs, I don't believe it would be an issue at all. 51. In section 3.2 bullet 5 [AF] OK with resolution 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. Ed.> Will move 10 up the list to be closer to 5 / 6. They are not the same but are related. [AF] Slightly confusing to map this as the bullets have moved between sections, but... 3.3#2 was 3.2#5 3.3#3 was 3.2#6 3.3#12 was 3.2#10 [AF] So it looks like 10 has not moved closer to 5 / 6 (i.e., 12 is not closer to 2 / 3) [AF] The three requirements read 2. An NAI MUST NOT be delivered to a node that is not capable of processing the indicated network action in a way that is acceptable to the imposing LER. 3. An NAI MUST NOT become top of stack at a node that does not understand how to perform a disposition operation on it. Disposition includes both processing and ignoring. 12. An MNA solution MUST enable a node inserting or modifying NAIs to determine if the far-end LER can accept and process a packet containing a given NAI. [AF] The points here are that you cannot achieve 2 or 3 without 12. It is not possible to stop the NAI being presented to a node that cannot process it unless you know which nodes cannot process it. [AF] With respect to 2 and 3 possibly being duplicates or overlapping, the question is what the different is between "delivered to a node" and "become top of stack at a node". How are they different? [AF] BTW, 3.2#6 reads... 6. If an MNA solution allows more than one scope, it must provide a mechanism MUST to specify the precedence of the scopes. ... which seems garbled. 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. Ed.> The text is correct as written. [AF] This is now 3.3#7 [AF] You need to explain how the "text is correct" at least in email, and possibly in the document. [AF] Perhaps it is that I just cannot parse this requirement easily. It seems to say that when there is a required function, exactly two NAIs should be defined: one for P2P and one for P2MP. But it says it very unclearly and "supported" has an implication for implementation rather than for specification! [AF] 1. If my understanding is correct, perhaps the text could be clearer. [AF] 2. If my understanding is correct, why? 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. [AF] I don't see an answer to this in the Appendix, but I do see 3.3#13 and #14 13. NAIs are normally inserted at LERs, but MAY be processed at LSRs and LERs. 14. If an network action needs to insert an NAI with in-stack ancillary data at a transit router on an LSP, then the new network action indicator and any required ancillary data MUST be pushed onto the MPLS label stack. [AF] #14 has address the "new label stack" issue. [AF] And #13 has reconciled the contradiction of what LSRs can do, but what is "normally inserted"? Does it mean that on Tuesdays an LSR can perform insertion? Does it mean that LSRs can do insertions, but in an abnormal way? [AF] If you say the LSRs do not normally do insertion then any (and every!) use case can claim that it is a special case and suddenly LSR insertion becomes normal. 55. In section 3.2 (4) [AF] OK with resolution 56. In section 3.3 (1) (3.3/1) is surely already covered by 3.3/4 Ed>These are correct but we have strengthened 3.3/1. [AF] My bad. Should have read 3.3/1 is surely already covered by 3.1/4 [AF] In the new revision, these are 3.4#1 and 3.1#4 [AF] Nothing wrong with the text of either, but there seems to be repetition from the "General Requirement" to the "AR Requirement" 57. In section 3.3 (2) [AF] OK with resolution 58. Semantic Routing [snip] We also set out to examine the challenges and concerns introduced by Semantic Routing in 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. Ed.> Agree with Loa's response. [AF] My point here is that you should look at draft-king-irtf-challenges-in-routing specifically to motivate requirements for inclusion here. I suspect, however, you are going to say that if I think there are additional requirements then I sould raise them myself. I guess that is the difference between an individual draft pre-adoption and a WG draft that we have now. 59. Understanding of Use Cases [AF] Well, the use cases draft has now been adopted as well, so we are beyond discussing this point. 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. 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? Ed> Updated abstract to focus on network actions. Will check for inconsistencies in rest of document. [AF] The edits here seem to have gone too far. [AF] The Title still says "... and MPLS Ancillary Data" but the Abstract makes no mention of ancillary data which sets it at odds. [AF] The Introduction does not introduce ancillary data, but suddenly says "... the encoding and use of the ancillary data." 61. Loa: I have been thinking about a short text (1 or 2 paragraphs) [AF] OK with resolution
- [mpls] Closing on draft-ietf-mpls-mna-requirement… Adrian Farrel
- Re: [mpls] Closing on draft-ietf-mpls-mna-require… Dongjie (Jimmy)
- Re: [mpls] Closing on draft-ietf-mpls-mna-require… Bocci, Matthew (Nokia - GB)
- Re: [mpls] Closing on draft-ietf-mpls-mna-require… Dongjie (Jimmy)
- Re: [mpls] Closing on draft-ietf-mpls-mna-require… Bocci, Matthew (Nokia - GB)
- Re: [mpls] Closing on draft-ietf-mpls-mna-require… Adrian Farrel