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

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

Hi Tony, 

Please see some response inline: 

> -----Original Message-----
> From: Tony Li [mailto:[e-mail]] On Behalf Of Tony Li
> Sent: Saturday, April 16, 2022 6:26 AM
> To: Dongjie (Jimmy) <[e-mail]>
> Cc: Loa Andersson <[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,
> 
> > 1. It is a good start that the requirements are classified into 3 categories:
> >
> > 	- General Requirements
> > 	- Requirements on ADIs
> > 	- Requirements on Ancillary Data
> >
> > Since the requirements are driven by the use cases, rather than the on-going
> framework or candidate solutions, it is important and reasonable to keep using
> the general terms "Ancillary Data Indicator" and "Ancillary Data" in the
> requirements, and remove the solution specific terms (such as ISD, PSD, NAS)
> from this document.
> 
> 
> The terms ISD, PSD, and NAS are not solution specific and are intentionally
> solution independent and conceptual.  A solution is not required to implement
> any of them.

According to the use cases collected, their common requirement is to carry ancillary data in the data packet to affect the packet forwarding or processing behavior, or the network states. There is no specific requirement on where the ancillary data should be put in the packet. Thus in the requirement document it would be clear enough to just mention ancillary data and its indicator (ADI).

The term ISD, PSD and NAS are used in the discussion and comparison of the candidate solutions. They may be discussed and compared in the framework draft, or in an solution analysis draft. 


> > 2. In this version the term "Ancillary Data Indicator" is changed to "Network
> Action Indicator". While there is some difference between the definition of the
> two terms:
> >
> > Ancillary Data Indicator (ADI): A indicator in the MPLS label stack that ancillary
> data exists in this packet.  It MAY also indicate the specific type of the ancillary
> data.
> >
> > Network Action Indication (NAI): An indication in the packet that a certain
> network action is to be performed.  There may be associated ancillary data in
> the packet.
> >
> > The above definition shows that ADI firstly is the indicator of the existence of
> the ancillary data, and optionally can be the indicator of specific type of ancillary
> data.  While NAI is only the indicator of a certain type of network action.
> >
> > Thus NAI cannot replace ADI directly in this document. I'd suggest to add the
> ADI back to the terminology section, and change all the NAI in section 3.2 back to
> ADI. If needed, the requirements on NAI can be added as separate items.
> 
> 
> 
> The problem with the term ADI is exemplified by NFFRR.  Here we have a
> network action that requires no ancillary data.  Yet, to indicate the function we
> would invoke an ‘Ancillary Data Indication’ that does not indicate ancillary data.
> The semantics do not match the words. This is pretty clearly poor terminology.

As I mentioned in my mail to John, NFFRR is one type of network action with no additional action-specific data. But the network action type "NFFRR" itself is considered as the ancillary data, as it is used to "affect the forwarding or other processing of that packet". 

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

> 
> NAI is an indicator of an action.  It MAY also indicate that there is ancillary data
> associated with this action. The amount of ancillary data must be specified in the
> definition of the NAI.

Agree that NAI is the indicator of an action. The action can have network action specific data, or it can just be the indicator itself.

> 
> 
> > 3. For backward compatibility and consistency, It is suggested to add the below
> items to section 3.1 as general requirements:
> >
> > 1) Solutions meeting the requirements set out in this document MUST be
> compatible with existing MPLS mechanisms.
> 
> 
> That requirement would prevent all changes.

That was not the intention. This requirement is about backward compatibility, it is to ensure that the legacy nodes which only support existing MPLS mechanisms will not misbehave on the packets with the new extensions. 


> 
> > 2) Solutions meeting the requirements set out in this document MUST reuse
> existing MPLS mechanisms when possible.
> 
> 
> That requirement is overly stringent.  For example, that would require that all
> solutions not incorporate EL in MNA, which would be a performance penalty.
> See today’s conversation with Haoyu for details.

This requirement is not specific to any existing mechanism, what it says is basically "do not reinvent the wheels unless there is a good reason for it". 

And it is about functionality rather than performance. If the analysis shows that performance will degrade severely due to "not reinventing the wheel", it might be a reason or just we have some problem to solve. 


> 
> > 3) For network actions which are developed or under development in IETF, the
> encoding and processing of the network action data MUST be reused.
> 
> 
> I’m not quite sure I understand the intent here. Network actions are new.
> What is there to be reused?

Some network actions are related to the work in other WGs in IETF, e.g., the format of iOAM data has been defined in IPPM. It would be reasonable to use it for all types of data plane. 

> 
> If you’re suggesting a requirement that mandates the use of ELI, no, we are not
> going to require that. At the same time, this requirement would require that we
> reuse ELI encoding verbatim, so that would preclude Bruno’s and Jags’
> solutions.

As I said above, it is not specific to ELI/EL, it is a generic requirement. Also the requirement document should not mandate the use of any specific solution. 

Best regards,
Jie


> 
> Regards,
> Tony
>