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

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

Hi Greg,

Thanks for your questions.

My reading of draft-ietf-ippm-ioam-data is that both the IOAM headers and IOAM data elements are defined as generic data blocks and can be encapsulated in different data plane.

Thus for the IOAM use case in MIAD, IMO it is reasonable to follow this approach to reuse both the IOAM headers and data elements in MPLS data plane. This way we simply treat IOAM as one application and does not need to touch the details of the IOAM data.

draft-gandhi-mpls-ioam reuses the data fields defined in IPPM IOAM document, which aligns with my proposal.

Best regards,
Jie

From: Greg Mirsky [mailto:[e-mail]]
Sent: Wednesday, April 27, 2022 4:41 AM
To: Dongjie (Jimmy) <[e-mail]>
Cc: Tony Li <[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,
I was reading through the discussion with a great deal of interest. Thank you for sharing your thoughts and posting questions for clarification. I've several questions for one of your proposals:
[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.
In my understanding, draft-ietf-ippm-ioam-data defines multiple contracts that can be placed in two major categories:

  *   IOAM Header
  *   IOAM data elements
In the first category are IOAM headers for:

  *   Pre-allocated and Incremental Trace
  *   Edge to Edge Trace
  *   Proof of Transit
In addition, two IOAM headers defined:

  *   IOAM Direct Export in draft-ietf-ippm-ioam-direct-export<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export>
  *   IOAM Hybrid Two-Step in draft-mirsky-ippm-hybrid-two-step<https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>
IOAM data elements defined in Section 5.4.2 of draft-ietf-ippm-ioam-data.
Hence my questions:

  *   Are you proposing re-using IOAM headers or IOAM data element formats?
  *   What is the benefit of re-using IOAM format outside of IOAM with MPLS data plane?
  *   How is your proposal different from draft-gandhi-mpls-ioam?
Thank you for sharing your opinion.

Regards,
Greg

On Tue, Apr 19, 2022 at 11:46 PM Dongjie (Jimmy) <jie.dong=[e-mail]<mailto:[e-mail]>> wrote:
Hi Tony,

Please find inline with [Jie #3]:

From: Tony Li [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Tony Li
Sent: Tuesday, April 19, 2022 2:35 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: Loa Andersson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; DetNet Chairs <[e-mail]<mailto:[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


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