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

+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=
40huawei.com@dmarc.ietf.org> 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:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
> > Sent: Wednesday, April 13, 2022 5:29 PM
> > To: mpls@ietf.org; draft-bocci-mpls-miad-adi-requirements@ietf.org
> > Cc: pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs
> > <detnet-chairs@ietf.org>
> > 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 (mpls@ietf.org). 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: loa@pi.nu
> > Senior MPLS Expert                          loa.pi.nu@gmail.com
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*