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

[Toerless Eckert <[e-mail]>]

Thanks, Loa

1) From the proposed text:

"We need a mechanism to indicate presence of meta-data or actions on an MPLS packet"

I think this is not correct.
  We need a mechanism to indicate to a processing LSR what actions to perform.
  We need a mechanism to indiciate if/what (post-stack) ancillary data to examine.

See below how IMHO this can best be captured.

2) I sugest that a better way to structure what we have is to start with
   definitions of the terms we use, because at least with how i would propose
   to define them, we would IMHO more clearly capture where we are than the
   current text. 

2.1) indicator

   Definition:
     An indicator is a semantic of an LSE to
     a) indicate to one or more LSR to perform a particular (set of) action(s).
     b) indicate to one or more LSR the presence of (a set of) ancillary data block
        they need to examine and potentially act upon.

   The indicator semantic of the LSE can be derived from special LSE encodings and/or
   be control-plane assigned (unless we explicitly rule out specific options, which
   we could then enumerate as dropped options).

1.2) meta-data / ancillary-data

   Note: the text uses both terms interchangably right now. I have no strong
   opinion about which term to finally use. Maybe we just continue to use
   them interchangably ight now so more participants can make up their mind which
   term we finally agree on as the "winner".

   Definition:
     A block of data beyond BoS required for an LSR to perform a specific action.
     For processing, it requires one or more mechanisms for an LSR to
     a) determine its presence/starting-offset in the packet
     b) identify that it needs to be processed by this LSR
     Note: a) and b) can be the same or different mechanisms.

   Note that this definition would not necessarily be 100% inclusive of all options
   of Stewarts (et.al.) proposal in so far that it also allows to point to ancillary
   data inside the stack, but i would argue that that hopefully is an option
   that could be ignored for the benefit of having a clearer distinction between
   meta/ancillary data and indicators.

Cheers
    Toerless

On Thu, Aug 05, 2021 at 04:51:02PM +0200, Loa Andersson 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

-- 
---
[e-mail]