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

[Greg Mirsky <[e-mail]>]

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