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

[Robert Raszuk <[e-mail]>]

Hi Greg,

Yes indeed both definitions are very different.

AD definition treats anything new to the current label stack as an optional
add-on == ancillary while NAI treats only optional parameters or metadata
associated with newly defined actions as ancillary.

Basically two different perspectives :)

Cheers,
R.



On Sun, 17 Apr 2022 at 23:57, Greg Mirsky <[e-mail]> wrote:

> Hi Robert,
> thank you for sharing your understanding of these terms. I believe, quite
> strongly, that synchronizing our interpretations of terms, building a clear
> unambiguous dictionary is essential to progressing any collaborative
> project. Let's see how this discussion goes.
> There may be some further tightening of the dictionary in the framework
> document as NAI(ADI) defined as follows:
>
> Network Action Indication (NAI): An indication in the packet that a
> certain network action is to be perfomed. There may be associated ancillary
> data in the packet.
>
> That definition led me to my understanding of the relationship between
> indicators and ancillary data.
>
> Regards,
> Greg
>
> On Sun, Apr 17, 2022 at 8:01 AM Robert Raszuk <[e-mail]> wrote:
>
>> Hi Greg,
>>
>> > As I understand it, some network actions may not have ancillary data
>> associated.
>>
>> I was under the impression reading Jie's note that actions *itself* are
>> the Ancillary Data. Your definition of "Ancillary Data" seems to be limited
>> to action parameters or metadata which is likely why you draw such
>> conclusions.
>>
>> See the definition which clearly supports my understanding of it:
>>
>> 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] 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).
>>
>>
>> Best,
>> Robert.
>>
>>
>> On Sat, 16 Apr 2022 at 02:33, Greg Mirsky <[e-mail]> wrote:
>>
>>> Hi Jie,
>>> thank you for your detailed analysis. I have a question about the use of
>>> ADI vs. NAI in our documents. As I understand it, some network actions may
>>> not have ancillary data associated. If that is correct, referring to these
>>> actions as Ancillary Data Indicators might be confusing to a reader. Should
>>> these network actions be referred to as no-Ancillary Data Indicators
>>> (NADI)? That seems confusing to me even more. I find NAI being a logical
>>> generic term that clearly characterizes network actions that don't have
>>> ancillary data associated as well as network actions that have associated
>>> ancillary data. In my opinion, it is the definition of the particular
>>> network action that defines the required behavior and associates it with
>>> any data that we refer to as ancillary data. I am supporting the change in
>>> terminology and using NAI in our documents, including the requirements
>>> draft.
>>>
>>> What do you think?
>>>
>>> Regards,
>>> Greg
>>>
>>> On Thu, Apr 14, 2022 at 8:13 PM Dongjie (Jimmy) <jie.dong=
>>> [e-mail]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Thanks to the authors for the effort on this document. I believe this
>>>> is useful work which will help to guide the framework and solution design.
>>>>
>>>> Compared to the previous version (-03), there are many changes in the
>>>> recent update, which takes some time to give it a review. And I suggest
>>>> people to also check the diffs from the previous version.
>>>>
>>>> Please find below some of my comments and suggestions to this document,
>>>> and I'd appreciate the authors' thoughts.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 2) Solutions meeting the requirements set out in this document MUST
>>>> reuse existing MPLS mechanisms when possible.
>>>>
>>>> 3) For network actions which are developed or under development in
>>>> IETF, the encoding and processing of the network action data MUST be reused.
>>>>
>>>> Best regards,
>>>> Jie
>>>>
>>>> > -----Original Message-----
>>>> > From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
>>>> > Sent: Wednesday, April 13, 2022 5:29 PM
>>>> > To: [e-mail]; [e-mail]
>>>> > Cc: [e-mail]; [e-mail]; DetNet Chairs
>>>> > <[e-mail]>
>>>> > Subject: [mpls] working group adoption poll on
>>>> > draft-bocci-mpls-miad-adi-requirements
>>>> >
>>>> > Working Group,
>>>> >
>>>> > This is to start a two week poll on adopting poll on
>>>> > draft-bocci-mpls-miad-adi-requirements
>>>> > as a MPLS working group document.
>>>> >
>>>> > THough we normally do two weeks pretty stric, in this case I have
>>>> allowed a
>>>> > couple of extra days due to holliday season.
>>>> >
>>>> > Please send your comments (support/not support) to the mpls working
>>>> group
>>>> > mailing list ([e-mail]). Please give a technical motivation for
>>>> your
>>>> > support/not support, especially if you think that the document should
>>>> not be
>>>> > adopted as a working group document.
>>>> >
>>>> > There is no IPRs disclosure against this document.
>>>> >
>>>> > The both authors have stated on the MPLS wg mailing list that they are
>>>> > unaware of any IPRs that relates to this document.
>>>> >
>>>> > The working group adoption poll ends May 2, 2022.
>>>> >
>>>> > /Loa
>>>> > --
>>>> > Loa Andersson                        email: [e-mail]
>>>> > Senior MPLS Expert                          [e-mail]
>>>> > Bronze Dragon Consulting             phone: [phone]
>>>> >
>>>> > _______________________________________________
>>>> > mpls mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>> _______________________________________________
>>> mpls mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>