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

[Tony Li <[e-mail]>]

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.


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


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


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

Tony