Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

["Dongjie (Jimmy)" <[e-mail]>]

Hi Tony,

Please find inline with [Jie #3]:

From: Tony Li [mailto:[e-mail]] On Behalf Of Tony Li
Sent: Tuesday, April 19, 2022 2:35 PM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Loa Andersson <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements


Hi Jie,




[Jie #2] I don’t remember this was ever discussed on the DT meetings, nor there is any consensus on obsoleting ADI.


This was presented as part of the update to the framework document, which was posted to the group mailing list on 4/4 and we discussed in the open DT meeting on 4/7.

Our document development process has never required (rough) consensus before making changes, especially for documents that have not been accepted as working group documents.  We propose text. We debate it, we modify it, and we move forward.

[Jie #3] There was discussion about the new terminologies introduced in the updated framework draft, people expressed different opinions on the changes, and that discussion will continue in the DT or possible a separate thread on the list.

In this thread we are talking about the adoption of the requirement document, thus (rough) consensus is required before it is adopted.


[Jie #2] Then how do you indicate whether there is any network action carried in the packet or not? The previous discussion shows that a unified indicator (e.g. bSPL) is needed, and clearly it is NOT the indicator of any specific network action, thus it is not the NAI.


That’s correct. As stated in section 2 of the framework document, an NAS is introduced by a special label. At this point, a bSPL is one alternative, but the framework does not require a bSPL.

[Jie #3] As you mentioned, a bSPL or its equivalent is needed to indicate the existence of a set of information (including both the action types and the optional action specific data) in the packet. My point is it is not an action-specific indicator.

I understand you want to have a term for the data associated with a specific network action, but this is not what the term ancillary data is introduced for, maybe we can introduce a new term "network action data"?
The term is ancillary data, as we’ve been using it all along.

[Jie #2] It would be clearer if we have separate terms for the whole set of ancillary data and the per-network action data.


Please feel free to propose terms and definitions if you feel that they would be helpful. What you’re describing sounds a lot like an NAS to me, but perhaps there’s some nuance that I’m missing.

[Jie #3] 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.


[Jie #2] Signaling based mechanism may be one direction of the solution, while backward compatibility is a general requirement regardless of which solution will be chosen.  And even if signaling is used, we still need to consider whether the transit nodes which are not required to process the ancillary data can be legacy devices or not.


There are a variety of options available, some of which might be practical.

[Jie #3] Agreed, and before touching the solutions, the requirement draft needs to consider the backward compatibility in all the possible options.


[Jie #2] This is also a general requirement we usually have in IETF requirements document: we should try to reuse what we already have, and be cautious in introducing new tools to solve an solved problem.

Since we are talking about extensions based on MPLS, the existing MPLS architecture, mechanism and limitation have to be taken into consideration. Otherwise a new protocol would provide more space for innovation and optimization.


The operative word is ’try’, which is never a good thing to have in a requirements document.  Did you ’try’?  And how hard?

Requirements should be quantifiable.  Either you met the requirement or you did not.

[Jie #3] “MUST”is used in my suggested text to the requirement draft. Here I was explaining that reusing existing mechanism is a general requirement we usually have.

Please note that in the MPLS-TP requirements RFC 5654, reuse existing mechanism is also one of the general requirements:

“The MPLS-TP design SHOULD as far as reasonably possible reuse existing MPLS standards.”


[Jie #2] The reuse of IOAM data format is just one example, do you think it is reasonable? This requirement is about the alignment in the encoding and processing of the network action specific data in general. Why do you think it would prevent us from an optimal result?



I don’t think that’s a good thing to put into the requirements document, no.

As I outlined in my discussion with Haoyu, there is a considerable advantage to not having separate MNA and ELI in the same label stack. Precluding that is not a sensible requirement.

[Jie #3] The example I gave is about reusing the IOAM data format in draft-ietf-ippm-ioam-data-17, which was designed to be encapsulated in different data plane. It is not related to the ELI discussion.


[Jie #2] The intention was not to exclude any solution. These are the general requirements (backward compatibility, reuse what we have) when extensions are to be made to an existing protocol. A good solution follows these as guidance, not the opposite (which is the solution leads the requirements).


What you’re proposing are not requirements on the solution. They are your personal design philosophy. I probably even agree with them, but they are subjective, not objective, not absolute, and as such should not be listed with a MUST.

[Jie #3] Indeed these are my proposals to this document as an individual IETF participant, and it is good if you agree with them. But I don’t quite follow your reason of not using “MUST”, and what requirement key word in RFC2119 do you think would be appropriate?

Best regards,
Jie

Tony