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

[John E Drake <[e-mail]>]

Hi,

Comments inline below.

Yours Irrespectively,

John



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Sent: Thursday, April 28, 2022 10:52 AM
To: John E Drake <[e-mail]>; Tony Li <[e-mail]>
Cc: [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

[External Email. Be cautious of content]

Hi John,

From: John E Drake [mailto:jdrake=[e-mail]]
Sent: Wednesday, April 27, 2022 8:56 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>; Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: [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

Jie,

The network actions sub-stack contains, at a minimum a sub-stack indicator and a list of requested network actions.  As I have stated many times, when defining a network action it is necessary, among other things, to define whether that network action requires ancillary data, what is that ancillary data, and whether that ancillary data is in-stack or post-stack.

[Jie] Understood. While I agree NAS may contain the indicator of PSD, this term cannot be used to refer to the PSD. We cannot say PSD is "one implementation of NAS".

[JD]  We use the term 'post-stack ancillary data'

So, even if we were to define every network action to either have no ancillary data or post-stack ancillary data, i.e., there will never be in-stack ancillary data,  a network actions sub-stack is still required.  This was a point that Haoyu made in our discussion of post-stack NSH.

[Jie] If there is no in-stack ancillary data, what we need in the label stack would be just the indicator. Then it has its own term does not need to be called a sub-stack.

[JD]  The network action sub-stack contains  a network action sub-stack indicator, network action indicators, and any in-stack ancillary data (as defined by the specified network actions)

As I have also stated many times, if a network action is related to forwarding, e.g., its ancillary data indicates a network resource partition, putting its ancillary data post-stack doesn't make much sense.  This is particularly true if transit nodes can't find the bottom of stack.

[Jie] I see you have asked the same question to Tianran, and basically I agree with his answer.

Best regards,
Jie

Yours Irrespectively,

John



Juniper Business Use Only
From: mpls <[e-mail]<mailto:[e-mail]>> On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, April 26, 2022 11:02 PM
To: Tony Li <[e-mail]<mailto:[e-mail]>>
Cc: [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

[External Email. Be cautious of content]

Hi Tony,

Please see inline with [Jie #5]:

From: Tony Li [mailto:[e-mail]] On Behalf Of Tony Li
Sent: Wednesday, April 27, 2022 1:22 AM
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,


First, NAS is general. Even if all data is pushed to PSD, then we still have a special label. That is a degenerate case of a single LSE NAS.

[Jie #4] Although its degenerate case can be a single special label, according to its definition, the semantic of NAS is composite, it can cover a special label, and can also cover optionally the NAIs and the action specific data if they are carried as ISD in the label stack. And it is not clear to me whether NAS can cover the PSD or not.


As discussed, a NAS can include actions that indicate that there is PSD.

[Jie #5] Thus NAS is not general enough to cover the PSD. What we need is a generic term to cover all the possible cases of ancillary data. Furthermore, the indicator and the ancillary data would need separate terms anyway and does not need to be coupled under one term.


 I welcome the suggestion that NAI be more specific and that we also have a generic term.

ADI does not seem like a good term for a generic indicator. What if there is no ancillary data?

[Jie #4] So we agreed that two separate terms are needed for the two types of indicators.

My reading of the Ancillary Data definition is that it is generic and covers both the action indicators and the optional action-specific data. Maybe it can be called Ancillary Information to avoid the confusion.


Ancillary Data does not include the action indicators.  Let's look at that definition:

*    Ancillary Data (AD): Data relating to the MPLS packet that may be used to affect the forwarding or other processing of that packet, either at an Label Edge Router (LER) [RFC4221<https://urldefense.com/v3/__https:/www.ietf.org/id/draft-andersson-mpls-mna-fwk-00.html*RFC4221__;Iw!!NEt6yMaO-gk!ToUjiWJLl_-j5aHfu-L6gEU0KQqWWkdAz0bH6aIOyxcr0jBydwRxqvLhg2omXWE$>] or Label Switching Router (LSR). This data may be encoded within a network action sub-stack (see below) (in-stack data), and/or after the bottom of the label stack (post-stack data).
Indicators are NOT mentioned here.

[Jie #5] Please find the description of ancillary data in the DT wiki: https://trac.ietf.org/trac/mpls/wiki/MIAD<https://urldefense.com/v3/__https:/trac.ietf.org/trac/mpls/wiki/MIAD__;!!NEt6yMaO-gk!ToUjiWJLl_-j5aHfu-L6gEU0KQqWWkdAz0bH6aIOyxcr0jBydwRxqvLhkVM4RKE$>

The ancillary data can be:

1.      implicit ("no-data");

2.      within the label stack, encoded as labels ("in-stack data" or ISD);

3.      after the BoS ("post-stack data" or PSD) of this label stack;

4.      within the payload (not considered further here).

For the first case "implicit", the action indicator is "used to affect the forwarding or other processing of that packet". According to the above definition, action indicators can be considered as part of the ancillary data.

That said, the definition of Ancillary Data could be clarified with some text to cover the "implicit data" case.

I propose Network Action Sub-stack Indcator (NSI) for this purpose.  Proposed definition:

   An LSE used to indicate the presence of a Network Action Sub-stack.

We should also revise the definition of NAS to use this.

[Jie #4] First of all, the requirement document should not restrict the indicator to an LSE. It is one possible solution, but there can be other options.


Please suggest a credible indicator that does not fit in an LSE.

[Jie #5] Please see the recent discussion on draft-kbbma-mpls-1stnibble.

Another problem is, for the case where the indicator is to indicate the presence of PSD only, can we call the PSD a Network action sub-stack? I don't think this complies with the NAS definition.


PSD is PSD.  NAS is NAS. They are not the same.  NAS may indicate the presence of PSD.

[Jie #5] OK, it is clear that NAS does not include the PSD only ancillary data, thus the statement "An LSE used to indicate the presence of a Network Action Sub-stack" is not generic enough to cover the PSD case.

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


The requirement that you wrote is general and not specific to IOAM. As a general requirement, it could and would apply to other situations such as ELI.  I think that is NOT the result that we want, so I disagree with the requirement.

[Jie #4] So you think this requirement applies to the IOAM case, but not the ELI case? Perhaps we need some criteria to classify the use cases?



Again, you wrote a general requirement.  You cite IOAM as an example. However, as written, the requirement can also be applied to ELI, which would preclude us from incorporating ELI/EL in MNA.  I don't think we want that.

[Jie #5] As you said, it is a general requirement, and would apply to most cases. I see what you want is to allow exception when really needed, can this be met by changing the MUST to SHOULD in the requirement?



[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?


SHOULD would allow us to apply them and consider trade-offs.

[Jie #4] Whether to use MUST or SHOULD in the requirement language can be discussed in the DT and WG, if it is agreed that these general requirements will be added to the requirements document.


This *IS* that discussion.

[Jie #5] Indeed, and we can hear other people's opinion about this.

Best regards,
Jie

Tony