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

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

Hi Jie (and adding back in the MPLS list).

Thanks for the follow-up. Please see below.

Matthew

From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Date: Tuesday, 27 February 2024 at 15:21
To: 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 Matthew and Adrian,

Thanks for the reminder and sorry for the delayed response.

Please see replies inline with [Jie]:

Best regards,
Jie

[snip]

From: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: 19 February 2024 11:42
To: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'Haoyu Song' <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [mpls] FW: I-D Action: draft-ietf-mpls-mna-requirements-10.txt

Hi Jie and Haoyu

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

Matthew

From: Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:jie.dong=[e-mail]>>
Date: Thursday, 8 February 2024 at 07:50
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, 'Haoyu Song' <[e-mail]<mailto:[e-mail]>>
Cc: Matthew Bocci (Nokia) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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.

[Jie] Thanks. I will check the updated text in next version.



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.”

[Jie] Yes.

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.

[Jie] My point is since the text in the beginning paragraphs of section 3 is general, it may cover both ISD and PSD.  The quoted text currently only mentions the size of post-stack ancillary data end-to-end is not part of the requirement, for completeness maybe there also needs some general considerations about the size of in-stack ancillary data and per-hop post-stack ancillary data, maybe something like:

Since in-stack ancillary data and per-hop post-stack data need to be parsed and processed by transit LSRs along the LSP, requirements on the size of such ancillary data are documented in the following sections.


MB2> OK I can add that.



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.

[Jie] Thanks for considering my suggestion on the classification. It is OK to leave 28 and 37 as is.

MB2> Thanks


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.



[Jie] I saw your latest response on top of this mail, and I agree adding “by default” may not be the best way. I’m not a native English speaker, but my feeling (not sure if it is just me?) with requirements 6 and 7 is that as requirements they are very strange: basically what they say is that a specific MNA function (ISD or PSD) must not be required to be supported by an implementation, unless...



On one side, this is too apparent to be considered a requirement: an implementation can always choose which part in an IETF specification it supports or not support, as long as this does not impact the interoperability of the feature it aims to provide. On the other side, the use of the RFC 2119 language “MUST NOT” is so strong that it makes me wonder whether there could be some exception here. If “by default” is added per Haoyu’s comment, maybe “MUST NOT” needs to be replaced by “SHOULD NOT”?



But I don’t have better suggestion on this. Or do you (to both Matthew and Adrian) think they can be removed directly without impacting the implementations’ choice?



MB2> Per the discussion off-line, I do not think we should change/soften this requirement.



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.

[Jie] Yes, of course the second sentence should be retained.

MB2> Thanks


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.

[Jie] Since the AD may needs to be inserted, parsed and processed together with the NAI, I’m not sure whether it is sufficient to talk about the data plane operation of NAI alone. For example, should in-stack ancillary data make use of existing MPLS data plane operations or not?


MB2> I don’t think you can mandate using existing MPLS data plane operations unless this document explicitly spells them out (by which I think we mean things such as push/pop/swap or exception handling or matching on specific bits or marking/remarking, etc)  based on the example use cases that we have.  And that assumes we always process in-stack ancillary data in the data plane.
We could add something like the following to Section 3.5:
“If in-stack ancillary data is processed in the data plane to complete a network action, then the processing  of the AD SHOULD make use of existing MPLS data plane operations.”
I do not think this needs to be a MUST because the fact that an LSR supports the network action in the first place implies any excessive processing requirements, but the SHOULD makes it clear that the network action solution design should try to leverage existing operations.
I also do not think we need to add anything further about insertion/extraction because that is covered by (42) and (44).


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.



[Jie] OK. It would be better to make it clear that it is about the encoding.



 MB2> OK thanks.



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.



[Jie] Agree some feedback from the WG may be needed. My consideration is since there is indication of PSD in the label stack, maybe the action indicators associated with the PSD can also be carried post-stack. This may help to reduce the size of NAS in the label stack in some cases.



 MB2> What about modifying 39 as follows:

39.  An MNA solution MUST specify where NAIs are to be placed in the

        Packet and how an LSR can determine their location i.e. in-stack or post-stack.







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.

MB2> 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.”

[Jie] By “MNA solution” I guess you are talking about the solution for a specific network action. Then the proposed text looks good to me, can we replace “MAY” with “SHOULD”?

MB2> Agreed


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.

[Jie] Agree, just it seems this requirement does not fully belong to section 3.5. And the must should be capitalized.

MB2> I agree the must should be MUST.


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

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

[Jie] OK, thanks.



Best regards,
Jie

From: Adrian Farrel [mailto:[e-mail]]
Sent: Thursday, February 8, 2024 1:10 AM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; 'Haoyu Song' <[e-mail]<mailto:[e-mail]>>
Cc: 'Matthew Bocci (Nokia' <matthew.bocci=[e-mail]<mailto:matthew.bocci=[e-mail]>>; [e-mail]<mailto:[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