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

[Tony Li <[e-mail]>]

Hi Jie,



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


Again, the term ADI is now obsolete.  That means that we’re not going to use it anymore.


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


No, it’s a network action. We have a network action indicator to indicate its presence. It has no associated ancillary data. An NAI is not ancillary data.


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


The term is ancillary data, as we’ve been using it all along.


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


Then please reword your proposal to say that.  

Note that we seem to VERY much be heading for a slightly different direction: signaling will be used to avoid legacy nodes.  Requiring backwards compatibility without signaling deeply limits what we can do, and most folks seem to find that unacceptable.


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


I’m objecting to the proposed requirement as you’ve stated it because the implications of the requirement give us a sub-optimal solution, IMHO.

If you feel that the intent of your requirement is more specific than how I’ve interpreted it, please feel to reword it more specifically.  We have a pretty good reason for including EL under MNA.


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


Again, if you have specifics that you want to place requirements on, please word this accordingly.  The blanket ‘MUST’ requirement would prevent us from an optimal result, so that’s not a requirement that we should incorporate.


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


As stated it mandates that we exclude ELI/EL.  The requirements document should not exclude good solutions.

Tony