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

[Tony Li <[e-mail]>]

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.

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



> 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://www.ietf.org/id/draft-andersson-mpls-mna-fwk-00.html#RFC4221>] 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://trac.ietf.org/trac/mpls/wiki/MIAD>
>  
> 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.


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


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


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

Tony