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

Toerless Eckert <tte@cs.fau.de> Fri, 06 August 2021 00:15 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1215B3A12CA; Thu, 5 Aug 2021 17:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STE-VD_LX3RW; Thu, 5 Aug 2021 17:15:32 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7433A12C7; Thu, 5 Aug 2021 17:15:31 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3E693548042; Fri, 6 Aug 2021 02:15:24 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3CB694E7C55; Fri, 6 Aug 2021 02:15:24 +0200 (CEST)
Date: Fri, 6 Aug 2021 02:15:24 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
Message-ID: <20210806001524.GK57091@faui48e.informatik.uni-erlangen.de>
References: <1cfaeafc-7d2c-7e04-c6e2-767feb6e8364@pi.nu> <20210805152323.GZ57091@faui48e.informatik.uni-erlangen.de> <BY3PR13MB4787A2508068920EAD4C2F4C9AF29@BY3PR13MB4787.namprd13.prod.outlook.com> <20210805232146.GG57091@faui48e.informatik.uni-erlangen.de> <BY3PR13MB478726B9FCA37087E09E7D3A9AF29@BY3PR13MB4787.namprd13.prod.outlook.com> <20210805234826.GI57091@faui48e.informatik.uni-erlangen.de> <BY3PR13MB478768E92635AA392E809F189AF29@BY3PR13MB4787.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BY3PR13MB478768E92635AA392E809F189AF29@BY3PR13MB4787.namprd13.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/AqfS1rMXDKOnGDO_BYpMbFSahlo>
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 00:15:38 -0000

really depends on how much different our extensions will be from IP.

On Thu, Aug 05, 2021 at 11:50:56PM +0000, Haoyu Song wrote:
> Sorry I didn't label it clearly. Here it is:
> >>> I don't think anybody would be confused between IPv6 Extension Header and MPLS Extension Header, it just like nobody will be confused between IPv6 Header and IPv4 Header. A header is a header. Other terms are confusing and inaccurate.
> 
> -----Original Message-----
> From: Toerless Eckert <tte@cs.fau.de> 
> Sent: Thursday, August 5, 2021 4:48 PM
> To: Haoyu Song <haoyu.song@futurewei.com>
> Cc: Loa Andersson <loa@pi.nu>nu>; mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators
> 
> I didn't see any inline replies from you ??
> 
> On Thu, Aug 05, 2021 at 11:38:58PM +0000, Haoyu Song wrote:
> > inline
> > 
> > -----Original Message-----
> > From: Toerless Eckert <tte@cs.fau.de>
> > Sent: Thursday, August 5, 2021 4:22 PM
> > To: Haoyu Song <haoyu.song@futurewei.com>
> > Cc: Loa Andersson <loa@pi.nu>nu>; mpls@ietf.org; pals-chairs@ietf.org; 
> > mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> > Subject: Re: [mpls] Review and Consensus call on text from the MPLS 
> > Open DT on in-stack indicators
> > 
> > On Thu, Aug 05, 2021 at 11:08:47PM +0000, Haoyu Song wrote:
> > > Toerless and Loa,
> > > 
> > > 1. IMHO, I think an indicator should only be used to tell what a packet have, but not be used to tell what a node should do. There's a big difference between the two.
> > 
> > I guess if we do introduce also a term for in-stack meta/ancillary data than we could agree. Aka: the flags in Kireetis proposal may not have below-bottom-of-stack ancillary data, but they also might not be considered to be part of the indicator, just sit in the same LSE that has an indicator...
> > 
> > Generalizing terminology is difficult ;-)
> > 
> > > 2.  I agree we should normalize the terms, but I feel the term "ancillary data" not accurate at all. To be sure, what's needed is not "data" or "ancillary data" or "meta data". What's needed is some headers representing some in-network services or functions which may comprise instructions and, if needed,  some "meta data".  The term "extension header" is accurate and familiar to IETF which I believe we should use.
> > 
> > I think "extension header" will be thought of as behaving exactly like it does in IPv6, whereas we just have started to brainstorm how we would want to do it.
> > I am very much a fan of this "stuff" to be self-typing within the context of MPLS, as opposed to just be decodeable if you have a next-header-type field referring to it. When we have any such differences over IPv6 extension headers ultimately, i think we should use a different term.
> > 
> > extension foobar
> >  foobar = block, token, cell, (meta, ancillary, acction)- data...
> > 
> > Aka: extension would tie into what IETF'er know from IP(v6) and then the rest being different would make them aware that there will be differences over how IPv6 does it.
> > 
> > >>> I don't think anybody would be confused between IPv6 Extension Header and MPLS Extension Header, it just like nobody will be confused between IPv6 Header and IPv4 Header. A header is a header. Other terms are confusing and inaccurate. 
> > 
> > Cheers
> >     Toerless
> > 
> > > Haoyu
> > > 
> > > -----Original Message-----
> > > From: mpls <mpls-bounces@ietf.org> On Behalf Of Toerless Eckert
> > > Sent: Thursday, August 5, 2021 8:23 AM
> > > To: Loa Andersson <loa@pi.nu>
> > > Cc: mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org; 
> > > DetNet Chairs <detnet-chairs@ietf.org>
> > > Subject: Re: [mpls] Review and Consensus call on text from the MPLS 
> > > Open DT on in-stack indicators
> > > 
> > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > tr
> > > > ac
> > > > .ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2021-07-22-agenda&amp;data=04%7C0
> > > > 1%
> > > > 7C
> > > > haoyu.song%40futurewei.com%7C183d588a603f495378c908d9582504ff%7C0f
> > > > ee
> > > > 8f
> > > > f2a3b240189c753a1d5591fedc%7C1%7C0%7C637637738310870911%7CUnknown%
> > > > 7C
> > > > TW
> > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > VC
> > > > I6
> > > > Mn0%3D%7C1000&amp;sdata=smLy6%2FB22H0iajFXb3%2BHKK2HEoFtoDP1T04PZF
> > > > 9y
> > > > GD
> > > > k%3D&amp;reserved=0
> > > > 
> > > > Please review the proposed text and comment on the MPLS wg mailing 
> > > > list (mpls@ietf.org).
> > > > 
> > > > We plan to keep the consensus call open until 2021-08-20.
> > > > 
> > > > /Loa
> > > > Open DT Co-ordinator / MPLS wg co-chair
> > > > 
> > > > 
> > > > --
> > > > 
> > > > 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > > ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song
> > > > %4
> > > > 0f
> > > > uturewei.com%7C183d588a603f495378c908d9582504ff%7C0fee8ff2a3b24018
> > > > 9c
> > > > 75
> > > > 3a1d5591fedc%7C1%7C0%7C637637738310870911%7CUnknown%7CTWFpbGZsb3d8
> > > > ey
> > > > JW
> > > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> > > > 00
> > > > 0&
> > > > amp;sdata=Mog2DWGvX7Qim12rBRm%2BnYf2xTMf%2FzdCeBORLC7%2B0Xg%3D&amp
> > > > ;r
> > > > es
> > > > erved=0
> > > 
> > > --
> > > ---
> > > tte@cs.fau.de
> > > 
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%4
> > > 0f
> > > uturewei.com%7Ca1c2c2fbe35543b42ed208d95867cf1a%7C0fee8ff2a3b240189c
> > > 75 
> > > 3a1d5591fedc%7C1%7C0%7C637638025173690995%7CUnknown%7CTWFpbGZsb3d8ey
> > > JW 
> > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> > > 0& 
> > > amp;sdata=Egt79gVWyupYRvySfntyFzv2Chk64ne8N45EOl7j8OY%3D&amp;reserve
> > > d=
> > > 0
> > 
> > --
> > ---
> > tte@cs.fau.de
> 
> --
> ---
> tte@cs.fau.de

-- 
---
tte@cs.fau.de