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

[Loa Andersson <[e-mail]>]

Kireeti,

What I tried to with the circulated text was to discuss "indicators" 
only, and address data that accompanies in a text we produce as a next 
step. Starting on the meeting August 12.

I understand that the distinction between what we need to say about 
"indicators" and ancillary data" is fuzzy, so I tried to minimize the 
scope of the circulatedd text.

See inline please, I say for some of your comments "will be addressed in 
an upcoming text", this is more of an agreement than not. I just want to 
find a rather simple starting point to work from.

On 05/08/2021 19:02, Kireeti Compelled wrote:
> 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.]
I think it is that such a discussion is at hand. even though in the Open 
DT meetings it has not been pushed very hard.

My take on this is that, yes we need to have the discussion, but even if 
we say that just now, a deprecation process takes several years. This 
means that for that time we need to live with that for packets that 
carry the GAL, the ACH will ocupy the place immediately after the label 
carrying the BoS.

My suggestion would be to discuss deprecting the GAL/GACH in parallel to 
the text we are now working on.
> 
>   * 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"]
True, but this "will be addressed in an upcoming text".
> 
>   * 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]
I see this as an agreement of the two bullets above.
> 
>   * 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]
Again,  this "will be addressed in an upcoming text".
> 
>   * The coexistence of OAM mechanisms and ancillary data encodings needs
>     to be designed in the new mechanism.

/Loa
> 
> 
> On Thu, Aug 5, 2021 at 7:52 AM Loa Andersson <[e-mail] 
> <mailto:[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
>     <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] <mailto:[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] <mailto:[e-mail]>
>     Senior MPLS Expert [e-mail] <mailto:[e-mail]>
>     Bronze Dragon Consulting             phone: [phone]
> 
>     _______________________________________________
>     mpls mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mpls
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]