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

From: Loa Andersson <[email-masked]>
Date: Wed, 13 Apr 2022 17:28:57 +0800

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 ([email-masked]). 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: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 13 Apr 2022 07:15:07 -0400

I support adopting this draft. It's a good summary of the requirements
developed by the MPLS open design team.

Cheers,
Andy

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Apr 2022 13:51:10 +0000

Support

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> From: mpls <[email-masked]> On Behalf Of Loa Andersson
> Sent: Wednesday, April 13, 2022 5:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; DetNet Chairs <detnet-
> [email-masked]>
> Subject: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-
> requirements
> 
> [External Email. Be cautious of content]
> 
> 
> Working Group,
> 
> This is to start a two week poll on adopting poll on draft-bocci-mpls-miad-adi-
> requirements
> 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 ([email-masked]). 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.
> 
> The both authors have stated on the MPLS wg mailing list that they are unaware
> of any IPRs that relates to this document.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!!
> NEt6yMaO-
> gk!VLs5EDcXl5mUmMaIjKWHG4vrJT2tyRe9jYUzJ6rl7_wbLneS2UQe23oLWnPhif
> U$

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 13 Apr 2022 07:03:04 -0700

Dear All,
I support the adoption of this draft by the MPLS WG.
Below, please find my non-blocking notes (clearly editorial):

   - Use of the normative language, Terminology section in particular. For
   example, in "There may be associated ancillary data in the packet."
   - Network Action Sub-Stack is abbreviated as NAS. I think that
   abbreviating as NASS or presenting the extended term as Network Action
   Sub-stack improves correlation between the full form and acronym. Also,
   I've noticed that NAS is not used throughout the document. It might not be
   useful after all.
   - Perhaps a typo in the first requirement Section 3.2 s/and/an/
   - It is not clear what "NAI is delivered to a node" might mean in the
   requirement 5 of Section 3.2. Perhaps the next requirement is sufficient
   and #5 can be removed from the document. Also, #5 seems like it has some
   extra wording. Perhaps s/in the way in a way/in a way/?

Regards,
Greg

On Wed, Apr 13, 2022 at 2:29 AM Loa Andersson <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Tony Li <[email-masked]>
Date: Wed, 13 Apr 2022 07:47:07 -0700

Support. This is a fine starting point.

T

> On Apr 13, 2022, at 2:28 AM, Loa Andersson <[email-masked]> wrote:
> 
> Working Group,
> 
> THough we normally do two weeks pretty stric, in this case I have allowed a couple of extra days due to holliday season.
>

---

From: Haoyu Song <[email-masked]>
Date: Wed, 13 Apr 2022 16:24:47 +0000

WG,

I support the adoption. Thanks!

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Loa Andersson
Sent: Wednesday, April 13, 2022 2:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
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.

Please send your comments (support/not support) to the mpls working group mailing list ([email-masked]). 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.

The both authors have stated on the MPLS wg mailing list that they are unaware of any IPRs that relates to this document.

/Loa

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C9284ef0afb3c4335022f08da1d301b5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637854389717188022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&amp;sdata=ai1SgriUEBWbzgeaW%2BDZ2iAr%2Bpmg%2FBYr%2FCCX8srsUXg%3D&amp;reserved=0

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 10:23:51 +0800 (CST)

Hi Loa,

I support wg adoption of this draft.
It's a well-written document and a good starting point.

Best Regards,
Xiao Min
------------------原始邮件------------------
发件人：LoaAndersson
收件人：[email-masked];[email-masked];
抄送人：[email-masked];[email-masked];DetNet Chairs;
日 期 ：2022年04月13日 17:29
主 题 ：[mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
Working Group,

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 14 Apr 2022 13:34:56 -0700

Hi,

I've reviewed this draft and support the adoption of the draft.

One thing I'm debating is whether draft-bryant-mpls-dev-primer-01 - A
Primer on the Development of MPLS (ietf.org)
<https://datatracker.ietf.org/doc/draft-bryant-mpls-dev-primer/> should be
merged with this draft?

Thanks,
Yingzhen

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 14 Apr 2022 23:19:37 +0200

Yes/support 

Cheers,
Jeff

> On Apr 13, 2022, at 11:29, Loa Andersson <[email-masked]> wrote:
> 
> Working Group,
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 14 Apr 2022 20:17:31 -0400

I support WG Adoption.

I think this draft is a very good starting point introducing terminology
 to build a set of requirements for ADI to extend the MPLS data plane.

I think this draft will really help hone in all the proposals being
developed so they all meet the set of requirements defined in this draft.

Thanks

Gyan
On Thu, Apr 14, 2022 at 5:20 PM Jeff Tantsura <[email-masked]>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 15 Apr 2022 03:12:51 +0000

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

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Wednesday, April 13, 2022 5:29 PM

---

From: Haoyu Song <[email-masked]>
Date: Fri, 15 Apr 2022 16:17:38 +0000

+1

I didn't realize so much modifications were done after our last DT meeting review. The issues need to be resolved before the actual adoption. 

Best,
Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, April 14, 2022 8:13 PM
To: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi all,

	- General Requirements
	- Requirements on ADIs

Best regards,
Jie

> group mailing list ([email-masked]). 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.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=05%7C01%7Chaoyu.song%40f
> uturewei.com%7C3101661cf62c4daa96b108da1e8de341%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637855892012130003%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
> 7C%7C%7C&amp;sdata=uiYRVWlOPmYPZglX8AKvG3WCBa8I0KdM%2FTk3opwoHx0%3D&am
> p;reserved=0

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=05%7C01%7Chaoyu.song%40futurewei.com%7C3101661cf62c4daa96b108da1e8de341%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637855892012130003%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uiYRVWlOPmYPZglX8AKvG3WCBa8I0KdM%2FTk3opwoHx0%3D&amp;reserved=0

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Apr 2022 17:18:08 -0400

+1

Jie

Very good point noticed.

Dear MPLS, PAL, DETNET WGs

I think for all discussions we need to have commonality on terminology for
consistency to help with having a level playing field for standardization
of new proposals.  Mixing terms makes this effort that much more difficult
and confusing to the reader as well prolong making progress and coming up
with a viable solution for MPLS extensibility.

I agree with Jie that ADI should be kept and not replaced with NAI.

I firmly agree with all the points made by Jie especially the most critical
point and I think the sole purpose of this draft is bullet 2 that all
solutions MUST meet the requirements as stated in the document.

I think one more critical point should be added to the document regarding
the controversy with reuse of fields within  a MPLS shim such as the TTL
and other fields.  This is a crucial as Bruno’s as well as
others proposals would like to reuse this field and there maybe others.
This draft should address the technical aspects of reusing TTL and issues
if they exist regarding feasibility and impact to entropy label RFC 6790
and 8662 and MPLS RFCs 3031 and 3022 protocol stack related to the value
must be 0 and being ignored but then also the possibility of being used for
forwarding if not set to 0 if EL was exposed possibility and impact.  The
TTL as well as other fields should be throughly analyzed by the WG MPLS
experts and provide feedback to this draft on viability and if so that
conclusion should be stated in this draft.  If the reuse of TTL and other
fields are not possible then all proposals MUST abide by the conclusions
stated in the draft being a consensus among WG MPLS experts.

Kind Regards

Gyan

On Thu, Apr 14, 2022 at 11:13 PM Dongjie (Jimmy) <jie.dong=
[email-masked]> 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.
>
> 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.
>
> 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
>
> allowed a
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Apr 2022 17:51:53 -0400

The reuse of fields is covered very well in the framework draft.

This draft can just focus on requirements for solutions space.

https://datatracker.ietf.org/doc/html/draft-andersson-mpls-mna-fwk-00#section-3.2

Thanks

Gyan

On Fri, Apr 15, 2022 at 5:18 PM Gyan Mishra <[email-masked]> wrote:

> I firmly agree with all the points made by Jie especially the most
> critical point and I think the sole purpose of this draft is bullet 2 that
> all solutions MUST meet the requirements as stated in the document.
>
>> group

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Li <[email-masked]>
Date: Fri, 15 Apr 2022 15:25:53 -0700

Hi Jie,

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

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.

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

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.

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.

> 1) Solutions meeting the requirements set out in this document MUST be compatible with existing MPLS mechanisms. 

That requirement would prevent all changes.

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

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

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.

Regards,
Tony

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 Apr 2022 17:32:43 -0700

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 Apr 2022 17:03:04 +0200

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.

---

From: John E Drake <[email-masked]>
Date: Sun, 17 Apr 2022 15:53:59 +0000

Robert,

Please see Tony's email below:

Hi Jie,

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

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.

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

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

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.

Regards,
Tony

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]> On Behalf Of Robert Raszuk
Sent: Sunday, April 17, 2022 11:03 AM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]; Dongjie (Jimmy) <jie.dong=[email-masked]>; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

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.

Best,
Robert.

On Sat, 16 Apr 2022 at 02:33, Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

        - General Requirements
        - Requirements on ADIs

Best regards,
Jie

> From: mpls [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Loa Andersson
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; DetNet Chairs
> <[email-masked]<mailto:[email-masked]>>
> mailing list ([email-masked]<mailto:[email-masked]>). Please give a technical motivation for your
> Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UshHjb0xUsHesOTjVxYbzpTaC3G7IiM5TnvlLEC9VC8NccC7_3bzmS_TC1eVJ0M$>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UshHjb0xUsHesOTjVxYbzpTaC3G7IiM5TnvlLEC9VC8NccC7_3bzmS_TC1eVJ0M$>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UshHjb0xUsHesOTjVxYbzpTaC3G7IiM5TnvlLEC9VC8NccC7_3bzmS_TC1eVJ0M$>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 17 Apr 2022 18:11:11 +0200

Hi John,

While terminology is really the least of my worries - here the below seems
missing my point.

> The problem with the term ADI is exemplified by NFFRR.  Here we have a
> network action that requires no ancillary data.
>

The definition provided seems very clear -

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

So this tells me that action is in itself an ancillary data from MPLS stack
POV. Therefore permit FRR or deny FRR would be an AD irrespective if
it requires additional parameters, arguments or metadata.

Yours,
Robert.

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 17 Apr 2022 14:56:48 -0700

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 <[email-masked]> wrote:

> 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.
>
>>> 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:
>>>
>>> 2) Solutions meeting the requirements set out in this document MUST
>>> reuse existing MPLS mechanisms when possible.
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Apr 2022 00:03:22 +0200

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 <[email-masked]> wrote:

> certain network action is to be perfomed. There may be associated ancillary
> data in the packet.
>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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
>>>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 18 Apr 2022 10:37:12 +0000

Hi Greg and Robert,

Thanks for the discussion. I agree with Robert’s interpretation and analysis here.

It is also my understanding that the definition of ADI and NAI are different.  ADI is used to indicate that there is information in addition to the legacy label stack in the packet, while NAI is used to indicate a certain type of network action. The existence of NAI and the optional data associated with the action need an indicator, which is the ADI.

Best regards,
Jie
From: Robert Raszuk [mailto:[email-masked]]
Sent: Monday, April 18, 2022 6:03 AM
To: Greg Mirsky <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi Greg,

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.

Cheers,
R.

On Sun, 17 Apr 2022 at 23:57, Greg Mirsky <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Best,
Robert.

What do you think?

Regards,
Greg

        - General Requirements
        - Requirements on ADIs

Best regards,
Jie

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2022 12:23:47 +0000

Jimmy,

I think it was Matthew who noted that the requirements draft initially focused too much on ancillary data rather than on network actions and that ancillary data is actually a characteristic of a network action.  I.e., when you define a network action, you define, among other things, whether it has ancillary data, what is that ancillary data, and whether the ancillary data is in-stack or post-stack.  Given this, there is no need for an ancillary data indicator and we should probably retire the term.

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Monday, April 18, 2022 6:37 AM
To: Robert Raszuk <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi Greg and Robert,

Thanks for the discussion. I agree with Robert's interpretation and analysis here.

Best regards,
Jie

From: Robert Raszuk [mailto:[email-masked]]
Sent: Monday, April 18, 2022 6:03 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; DetNet Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi Greg,

Cheers,
R.

Regards,
Greg

Best,
Robert.

What do you think?

Regards,
Greg

        - General Requirements
        - Requirements on ADIs

Best regards,
Jie

> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>

---

From: John E Drake <[email-masked]>
Date: Mon, 18 Apr 2022 14:02:18 +0000

Hi,

I just checked and the term 'ancillary data indicator (ADI)' is *not* used in the requirements draft.

Yours Irrespectively,

John

Juniper Business Use Only
From: John E Drake
Sent: Monday, April 18, 2022 8:24 AM
To: Dongjie (Jimmy) <jie.dong=[email-masked]>; Robert Raszuk <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Jimmy,

Yours Irrespectively,

John

Juniper Business Use Only
From: mpls <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: Monday, April 18, 2022 6:37 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; DetNet Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi Greg and Robert,

Best regards,
Jie

Hi Greg,

Cheers,
R.

Regards,
Greg

Best,
Robert.

What do you think?

Regards,
Greg

        - General Requirements
        - Requirements on ADIs

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 18 Apr 2022 15:23:10 +0000

Hi John,

The diffs show that the term ADI was in the previous versions of the requirements document, and just replaced by NAI in the latest version:

https://www.ietf.org/rfcdiff?url2=draft-bocci-mpls-miad-adi-requirements-04.txt

And the draft name still shows that the requirements were originally on ADI.

As Robert and I mentioned, the term ancillary data is generic and refers to all types network actions information, including those with and without additional action data.  Thus NAI can be considered as one type of ancillary data.

And ADI is the indicator of the presence of ANY non-label information in the MPLS packet. Following it there may be indicators of each specific network action. And my understanding is the requirements in section 3.2 was mainly on the ADI.

Best regards,
Jie

From: John E Drake [mailto:jdrake=[email-masked]]
Sent: Monday, April 18, 2022 10:02 PM
To: Dongjie (Jimmy) <[email-masked]>; Robert Raszuk <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi,

Yours Irrespectively,

John

To: Dongjie (Jimmy) <jie.dong=[email-masked]<mailto:jie.dong=[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>

Jimmy,

Yours Irrespectively,

John

Hi Greg and Robert,

Best regards,
Jie

Hi Greg,

Cheers,
R.

Regards,
Greg

Best,
Robert.

What do you think?

Regards,
Greg

        - General Requirements
        - Requirements on ADIs

Best regards,
Jie