Re: [mpls] This is not a last call! draft-ietf-mpls-mna-requirements-08.txt

Dear authors and WG, 

Thanks for the effort in incorporating my review comments into the -08 version. I found that most of my WG LC comments have been addressed. 

Since there are new requirements added in this version, and some requirements are updated, please find some further comments as below:

7.   A solution MUST NOT require an implementation to support in-
        stack or post-stack ancillary data, unless the implementation
        chooses to support a network action that uses in-stack or post-
        stack ancillary data.

  [Jie]: This is a negative statement and it seems too strong. Also it mixes up the requirement on solution and the requirement on implementation. How about rephrase it like this: 

       A solution SHOULD support network actions that uses in-stack or post-stack ancillary data, or both. Depends on the MNA use cases an implementation chooses to support, the implementation MAY support in-stack or post-stack ancillary data, or both.

12.  The design of any MNA solution MUST NOT expose information to
        the LSRs that is not already exposed to the PE.

  [Jie] It is not clear whether this requirement is about not exposing information to any LSR, or not exposing information to PE? 

20.  Insertion, parsing, processing and disposition of NAIs SHOULD make use of existing MPLS data plane operations.

  [Jie] Does this mean new extension to MPLS data plane operation is not allowed? In my understanding ISD requires some new operation to the label stack, and new parsing behavior to the LSE. And this contradicts to the text in the introduction:

  "These use cases require the definition of extensions to the MPLS architecture and label stack operations..."

About requirement 21, 22, 26, 28, 30: 

  [Jie] It seems these requirements are more related to network actions, as they are about the ability of the LSRs to perform specific network action, not just the parsing of the indicator. 

38.  An MNA solution MUST specify where NAIs are to be placed in the packet i.e. in-stack or post-stack.

  [Jie] Do we allow NAIs to be carried both in-stack and post-stack? E.g. some specific NAIs are in-stack, some else are post-stack. 

39.  MNA specifications MUST specify whether ancillary data is required and whether it is in-stack and/or post-stack.

  [Jie] Should this be specified per network action? 

After requirement 42, suggest to add another requirement about the limit of in-stack ancillary data as below: 

  For MNA use cases in which the quantity or size of ancillary data exceeds the limit of the in-stack ancillary data, MNA solutions SHOULD place such ancillary data as post-stack.

45. Any MNA solution specification MUST describe whether it can coexist with existing post-stack data mechanisms e.g. control words and G-ACH, and if so how this coexistence operates.

  [Jie] Suggest to add references to the RFCs of Control Words and G-ACH. 

53. Ancillary data MUST only be inserted at LERs, and can be processed at LSRs and LERs.  Processing MAY include rewriting the ancillary data, but MUST NOT include changing its size.

  [Jie] There could be use cases which require to change the size of the ancillary data along the forwarding path, e.g. IOAM. 

Best regards,
Jie

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Matthew Bocci
> (Nokia)
> Sent: Wednesday, January 3, 2024 11:20 PM
> To: adrian@olddog.co.uk; mpls@ietf.org
> Cc: draft-ietf-mpls-mna-requirements@ietf.org
> Subject: Re: [mpls] This is not a last call!
> draft-ietf-mpls-mna-requirements-08.txt
> 
> Hi WG
> 
> Thank you to everyone who reviewed the previous version of the draft and
> provided valuable comments.
> 
> There were many comments embedded in the WG last call discussions on the
> list and we made numerous changes to address these, as well as some other
> editorial improvements to the text. This made it a challenge to track all the
> improvements.
> 
> Please refer to the following diff to see where changes were made:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-mpls-mna-requirements-0
> 7&url2=draft-ietf-mpls-mna-requirements-08&difftype=--html
> 
> We would greatly appreciate feedback on the updates and any further
> comments on the draft.
> 
> Best regards
> Matthew
> 
> 
> On 11/12/2023, 14:26, "Adrian Farrel" <adrian@olddog.co.uk
> <mailto:adrian@olddog.co.uk>> wrote:
> 
> 
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links
> or opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> 
> 
> 
> Hi,
> 
> 
> The authors have been busy making changes based on the extensive review
> comments and discussions arising from the first last call for this document.
> 
> 
> It would be really helpful if people could start to look through the document
> and see which of their concerns have been addressed and what is still
> outstanding.
> 
> 
> Given the volume of comments, it would be no surprise if the authors need
> to make a further round of adjustments, but starting to look at the text (and
> possibly focusing on the diffs) might speed things along.
> 
> 
> Thanks,
> Adrian
> 
> 
> -----Original Message-----
> From: I-D-Announce <i-d-announce-bounces@ietf.org
> <mailto:i-d-announce-bounces@ietf.org>> On Behalf Of
> internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
> Sent: 11 December 2023 12:05
> To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> Cc: mpls@ietf.org <mailto:mpls@ietf.org>
> Subject: I-D Action: draft-ietf-mpls-mna-requirements-08.txt
> 
> 
> Internet-Draft draft-ietf-mpls-mna-requirements-08.txt is now available. It is
> a work item of the Multiprotocol Label Switching (MPLS) WG of the IETF.
> 
> 
> Title: Requirements for Solutions that Support MPLS Network Actions
> Authors: Matthew Bocci
> Stewart Bryant
> John Drake
> Name: draft-ietf-mpls-mna-requirements-08.txt
> Pages: 11
> Dates: 2023-12-11
> 
> 
> Abstract:
> 
> 
> This document specifies requirements for the development of MPLS network
> actions which affect the forwarding or other processing of MPLS packets.
> These requirements are informed by a number of proposals for additions to
> the MPLS information in the labeled packet to allow such actions to be
> performed, either by a transit or terminating LSR (i.e. the LER).
> 
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/>
> 
> 
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-08
> <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-08
> >
> 
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements-0
> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements-
> 0>
> 8
> 
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> <https://www.ietf.org/mailman/listinfo/i-d-announce>
> 
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls