Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

[Kireeti Kompella <[e-mail]>]

Hi Loa,

[moving chairs to bcc]

As a "member" of the Open DT, I agreed to the text (reproduced below).
However, I think it can be tightened up (in [kk:] below).  Also, in the
discussion at the IETF, it became clearer that "ancillary data" refers to
data past the EoS; I use it that way in the comments below, and use
"in-stack data" for data carried in the label stack.  Note: what follows
below in [] are my own comments regarding this text.

The design team agrees on the following:

   - We want to limit the number of new assignments of base special purpose
   labels (bSPLs) as much as possible.


   - We have a standardized associated channel, the GAL/GACH. We are not
   going to change the associated channel in anyway that breaks existing
   implementations. The ACH is found immediately after the label carrying the
   Bottom of Stack (BoS) bit. Currently, there is no defined method to carry
   multiple ACHs in the same MPLS packet. GAL/GACH will only be an OAM or
   instrumentation tool and will not be used to carry meta-data with
   user-traffic.

[kk: there was some discussion to begin to deprecate the GAL/GACH and
incorporate its contents into newer methods of carrying ancillary data. I
agree with this idea; if there is consensus on this, words to that effect
should be added here.]


   - Any new mechanism to carry meta-data needs to have a well defined
   method of handling types/versions that are not understood or supported by a
   receiving router.


   - We need a mechanism to indicate presence of meta-data or actions on an
   MPLS packet. We therefore need an in-stack method to serve this purpose.
   Any in-stack method is in scope.

[kk: we also need a way to carry data _in-stack_; there is precedent for
this and there is value in this. We also need criteria for when data should
be "in-stack" vs. "after BoS"]

   - One proposal is to "re-purpose" an existing bSPL to serve this
   purpose. However, in order to do this it must be shown that there is no
   potential interference with the current role of the bSPL.


   - If we can't demonstrate the non-interference then we should assign
   specific forwarding action indicator base special purpose label.

[kk: reuse can be problematic; allocating a new label, and working on
deprecating old ones, may be more pragmatic]

   - Multiple actions may need to be indicated by the same bSPL.

[kk: equally, multiple types of in-stack data may need to be indicated by a
bSPL]

   - The coexistence of OAM mechanisms and ancillary data encodings needs
   to be designed in the new mechanism.


On Thu, Aug 5, 2021 at 7:52 AM Loa Andersson <[e-mail]> wrote:

> Working Group, MPLS Open DT,
>
> The week before IETF 111 the Open DT met and agreed upon a text on
> "indicators". The terminology we use is that somewhere in the label
> stack there is an indicator tell the processing node that a specific
> packet needs a certain set of Forwarding Actions, for example some iOAM
> action might be required. To support the forwarding action there is
> often ancillary data with the packet.
>
> The text the DT produced is about the indicators, a companion text on
> ancillary data will follow.
>
> The text was discussed in the Joint meeting and reported to the MPLS
> working group at IETF 111. The Open DT itself can only propose, the text
> is therefore now sent out to the working group for review and consensus
> call.
>
> The proposed text is found at:
> https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda
>
> Please review the proposed text and comment on the MPLS wg mailing list
> ([e-mail])
>
> We plan to keep the consensus call open until 2021-08-20.
>
> /Loa
> Open DT Co-ordinator / MPLS wg co-chair
>
>
> --
>
> 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
>