Re: [mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-10.txt

["Matthew Bocci (Nokia)" <[e-mail]>]

Hi Jie and Haoyu

Thanks for your comments. Please see below for some responses.

Matthew

From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Date: Thursday, 8 February 2024 at 07:50
To: [e-mail] <[e-mail]>, 'Haoyu Song' <[e-mail]>
Cc: Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-10.txt

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,

Thanks Matthew and authors for the update, and thanks Adrian for the timely notice before the holiday:)

I checked the new version, it solves some of my previous comments. Please find some remaining and new comments below:


The document used several terms to refer to MNA related solutions or specifications:

MNA solution

MNA solution specification

MNA specification

NAI specification  (in requirement 24)

Solutions (in requirement 42)

My feeling is they have different scopes, while different people may have different understandings about them. Thus for clarity it is suggested to only use two terms consistently: one is for the general MNA solution (the base for all network actions), and the other is for the specification of a specific network action.


MB> Yes, I agree this could be reduced to two. It would also help to define what we mean by them by adding some introductory text. Let me clean this up and propose something in the next version of the draft.



In the end of section 3, there is one sentence talking about the size of post-stack ancillary data. Do we also need some similar text about the size of ancillary data carried in-stack in the same paragraph?

MB> I think you are referring to the following:
“The size of the ancillary data carried post-stack end-to-end in a
   packet is a matter for agreement between the ingress and egress PEs,
   and is not part of these requirements.”

What exactly are you proposing to add for in-stack? For in-stack, we are explicitly talking about additions to the MPLS label stack, so I don’t think we can say that it is not part of the requirements. We already have a number of requirements covering the presence and size of in-stack data inserted by the ingress LER / PE.


Several requirements In section 3.4 (e.g. 25, 28, 33, 36, 37) are not just about the NAI operation, but also the processing of the network action and ancillary data. Not sure whether they need to be moved to other sections?

MB>
25: Agree. Scope if a property of the action, not just the indicator. We can move to Section 3.3.
28: If you can’t accept/process an NAI, then you can’t accept/process the action or associated AD, so I am not sure this needs to move.
33: Agreed this could be moved to 3.3.
36: Agreed this could be moved to 3.3.
37: This one is not really a requirement on a network action, but on the ‘clean up’ of the stack if you strip the NAI. I think it is fine where it is.



Requirement 6 and 7, I agree with Haoyu that it is better to add “by default” to the text.



MB> I am not sure this adds anything, but I can include it.



Requirement 12, suggest to change it to:



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

MB> OK but I think we should retain the second sentence in the requirement.


Requirement 20, now I can understand the text here does not preclude new operations being introduced when necessary. While my current question is, is this requirement only about the network action indicators, does it also include the insertion, parsing and processing of the associated ancillary data?

MB> I don’t see how we can limit the processing of the AD in this way.



Requirement 34, suggest to change “indictors” to NAIs. And it is not quite clear what this requirement is about. Is it about the encoding or the processing of NAI,  or both?



MB> Agree to change indicators to NAIs. I think it is really about the encoding – the NAI is not a label but had to be encoded in a way that it can sit alongside labels in the stack.





Requirement 39, this is one comment I made in pervious review: Do we allow some NAIs be carried in-stack, and the rest be carried post-stack? And for each specific NAI, where it should be carried may be described in the corresponding network action specification.



MB> I think this is more of a question to the WG. I suppose imposing both a NAS with in-stack and a NAS with post-stack on the same packet with different scopes could get extremely complex and require potentially unnecessary parsing below the BoS, although we have requirement 35, but that applies to AD and not NAIs. I would appreciate feedback from the WG on this.



Requirement 43 talks about “limiting the quantity of in-stack ancillary data”. 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.

MB> I am not sure that is consistent with 43, as I would not expect a solution to be defined that does not limit the amount of data pushed in the stack to the minimum amount required. I think what we are trying to say is that we don’t want the stack to get so big that we either hit an implementation limit at the ingress LER which means that the span of the LSP (for example in the case of SR-TE) is limited, or we unintentionally exceed the readable label stack depth at downstream LSRs. An MNA solution may use post-stack AD for use cases where this is a concern.

What about “An MNA solution MAY use post-stack ancillary data where the size of that ancillary data could prevent the coexistence of the network action with other in-use MPLS network functions.”


Requirement 44, the first half is a requirement on NAI, the second half is the requirement on ancillary data. Suggest to split it and move the first half to section 3.4.

MB> I am not sure splitting it adds anything as the AD is intimately associated with the NAI.


Requirement 47, is this requirement specific to in-stack data or ancillary data in general?

MB> This is generic. I can add that clarification.



Best regards,
Jie

From: Adrian Farrel [mailto:[e-mail]]
Sent: Thursday, February 8, 2024 1:10 AM
To: Dongjie (Jimmy) <[e-mail]>; 'Haoyu Song' <[e-mail]>
Cc: 'Matthew Bocci (Nokia' <matthew.bocci=[e-mail]>; [e-mail]
Subject: RE: [mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-10.txt

Thanks for this, Matthew.

Jie and Haoyu, if you get a chance before the New Year holiday, it would be *really* helpful if you could let Matthew know whether you still have concerns resulting from your previous comments, or if Matthew has addressed them with changes to the current revision.

If we are all good, then a 2nd WGLC can be run (with plenty of time for review and comments after New Year).

Thanks,
Adrian

From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Matthew Bocci (Nokia)
Sent: 07 February 2024 15:14
To: [e-mail]<mailto:[e-mail]>
Subject: [mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-10.txt

All

I have just posted an updated draft, hopefully addressing Tony’s comments below.

There were some outstanding comments from Jie and Haoyu, but I think that these may have been addressed to some extent by some of the resolutions to the other comments. Please could you review the draft and let me know if you still have outstanding comments.

Thanks

Matthew

From: mpls <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 7 February 2024 at 15:07
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] I-D Action: draft-ietf-mpls-mna-requirements-10.txt

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.



Internet-Draft draft-ietf-mpls-mna-requirements-10.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-10.txt
   Pages:   11
   Dates:   2024-02-07

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/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-requirements-10

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-mna-requirements-10

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls