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: mpls <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, April 28, 2022 10:41 AM
To: 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 Tony,


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


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 do not understand why we need another term.  We have not had a situation where we wanted to refer to "NAS + PSD" and lacked a term for it.

[Jie] Let me put it this way:

By definition, NAS contains: ADI, Optional NAI and Optional ISD.

While what we want to refer to with the term is: Optional NAI Optional ISD and Optional PSD.  Note it does not include the ADI.

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

That said, please feel free to propose a term and a definition.

[Jie] My first proposal would be Ancillary Data (no surprise), while I'm open to other proposals as long as it can be used to refer to both ISD and PSD.

[JD]  We are already using ancillary data for this purpose

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!R7VhsuOeJF6SucCINQ0-_QziFARqdkopgE2rNU27I7aIp3QEPAbZ-6vpCF7c6fM$>] 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!R7VhsuOeJF6SucCINQ0-_QziFARqdkopgE2rNU27I7aIp3QEPAbZ-6vpJT5OnB0$>

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.



The definition of Ancillary Data in the framework document is normative.  The Wiki is not and is outdated.  Please feel free to update the Wiki if that would be helpful.

[Jie] The descriptions in the wiki align with the Ancillary Data Definition. As in the implicit case, "action indicators" IS used to affect the forwarding or other processing of that packet. Thus it will just be an clarification, not a change. Also the framework document itself is still a draft and changes are expected before its publication.


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

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


Nothing in that discussion suggested an indicator that was more than an LSE.  Could you please provide an explicit reference, or better yet, a quote?

AFAICT, everything in that discussion assumed NAI in the NAS, with some NAI indicating the presence of PSD.

[Jie] My reading is that the first nibble is considered as part of the indicator of the PSD for MIAD/MNA.

Section 2.1.4. the main reason for creating a First Nibble registry is to document the types of post-stack headers that may follow a label stack, and to simplify their parsing.


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.


That statement is correct.  It indicates the presence of a NAS.  The NAS in turn indicates the presence of PSD.  John has explained this.

[Jie] OK, it is clear that NAS can indicate the presence of PSD, while PSD is not included in the NAS, only the indicator.

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?


That would certainly allow us more leeway and thus it would be more acceptable as a requirement.

[Jie] This sounds good.

Best regards,
Jie

Tony