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

From: Loa Andersson <[email-masked]>
Date: Thu, 5 Aug 2021 16:51:02 +0200

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 
([email-masked]).

We plan to keep the consensus call open until 2021-08-20.

/Loa
Open DT Co-ordinator / MPLS wg co-chair

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 5 Aug 2021 17:23:23 +0200

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:
> "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 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.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

-- 
---
[email-masked]

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 5 Aug 2021 10:02:54 -0700

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.

---

From: Haoyu Song <[email-masked]>
Date: Thu, 5 Aug 2021 23:08:47 +0000

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.

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.

Haoyu

-----Original Message-----
From: mpls <[email-masked]> On Behalf Of Toerless Eckert
Sent: Thursday, August 5, 2021 8:23 AM
To: Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

Thanks, Loa

2.1) indicator

   Definition:

   Definition:

Cheers
    Toerless

On Thu, Aug 05, 2021 at 04:51:02PM +0200, Loa Andersson wrote:
> 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.
> 
> 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.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac
> .ietf.org%2Ftrac%2Fmpls%2Fwiki%2F2021-07-22-agenda&amp;data=04%7C01%7C
> haoyu.song%40futurewei.com%7C183d588a603f495378c908d9582504ff%7C0fee8f
> f2a3b240189c753a1d5591fedc%7C1%7C0%7C637637738310870911%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=smLy6%2FB22H0iajFXb3%2BHKK2HEoFtoDP1T04PZF9yGD
> k%3D&amp;reserved=0
> 
> Please review the proposed text and comment on the MPLS wg mailing 
> list ([email-masked]).
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40f
> uturewei.com%7C183d588a603f495378c908d9582504ff%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637637738310870911%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=Mog2DWGvX7Qim12rBRm%2BnYf2xTMf%2FzdCeBORLC7%2B0Xg%3D&amp;res
> erved=0

--
---
[email-masked]

_______________________________________________
mpls mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C183d588a603f495378c908d9582504ff%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637637738310870911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Mog2DWGvX7Qim12rBRm%2BnYf2xTMf%2FzdCeBORLC7%2B0Xg%3D&amp;reserved=0

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 01:21:47 +0200

> 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 som…

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.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Thu, 5 Aug 2021 23:38:58 +0000

inline

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Thursday, August 5, 2021 4:22 PM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

> 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...

> 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 som…

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

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

> > 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.
> > 
> uturewei.com%7Ca1c2c2fbe35543b42ed208d95867cf1a%7C0fee8ff2a3b240189c75
> 3a1d5591fedc%7C1%7C0%7C637638025173690995%7CUnknown%7CTWFpbGZsb3d8eyJW
> amp;sdata=Egt79gVWyupYRvySfntyFzv2Chk64ne8N45EOl7j8OY%3D&amp;reserved=
> 0

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 01:48:26 +0200

I didn't see any inline replies from you ??

-- 
---
[email-masked]

---

From: Haoyu Song <[email-masked]>
Date: Thu, 5 Aug 2021 23:50:56 +0000

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: Thursday, August 5, 2021 4:48 PM
To: Haoyu Song <[email-masked]>
Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; DetNet Chairs <[email-masked]>
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:38:58PM +0000, Haoyu Song wrote:
> Cc: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; 
> [email-masked]; DetNet Chairs <[email-masked]>
> > > "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 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.
> > > 
> > > 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
> > > 
> > > 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
> > 
> > --
> > ---
> > [email-masked]
> > 

--
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 6 Aug 2021 02:15:24 +0200

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

-- 
---
[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Fri, 6 Aug 2021 14:15:22 +0200

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:
> 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 
>   * 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.
> 
> 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.
> 
> 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
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

/Loa
> 
> 
> On Thu, Aug 5, 2021 at 7:52 AM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     text
>     <https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda>
> 
>     ([email-masked] <mailto:[email-masked]>).
> 
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mpls>
> 

--

---

From: <[email-masked]>
Date: Fri, 6 Aug 2021 12:49:05 +0000

Thanks for the work on the proposed summary.

Looks good to me. 

1 comment

>    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.

I think it would be easier to demonstrate the interference with a single example, rather than requiring a formal demonstration that their can't be interference.
https://en.wikipedia.org/wiki/Burden_of_proof_(philosophy)#Proving_a_negative

IOW, if one believes that there is interference, please explicit the case.

Could this be rephrased along this line?

Thanks,
--Bruno

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Thursday, August 5, 2021 4:51 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; DetNet Chairs <detnet-
> [email-masked]>
> Subject: [mpls] Review and Consensus call on text from the MPLS Open DT on in-
> stack indicators
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 6 Aug 2021 10:00:40 -0400

Hi WG,

One comment on the following text with <RG>:

   multiple ACHs in the same MPLS packet. *GAL/GACH will only be an OAM or
   user-traffic. *

<RG> The last sentence needs some clarification. The packet with GAL is
punted out of the fast path in forwarding, so user-traffic does not carry
it, so it makes sense. However, packets could carry GACH without GAL. The
user-traffic could also carry a GACH without GAL if use-case makes sense. I
am not sure we are ready to add this restriction just yet.

Thanks,
Rakesh

---

From: tom petch <[email-masked]>
Date: Fri, 6 Aug 2021 16:12:00 +0000

From: mpls <[email-masked]> on behalf of Loa Andersson <[email-masked]>
Sent: 05 August 2021 15:51

<tp>

In earlier discussions,the issue arose as to whether or not more than one label could be flagged as Bottom of Stack.

This text seems to assume that there can only be one, in which case, that is an assumption worth stating in m view.

Tom Petch

/Loa

--

---

From: <[email-masked]>
Date: Sat, 7 Aug 2021 06:22:12 +0800 (CST)

Hi Loa,

many thanks to all who contributed to the text. I have a suggestion and a comment to the following sentence:

GAL/GACH will only be an OAM or instrumentation tool and will not be used to carry meta-data with user-traffic.

As I understand how GAL/G-ACh (and ACH in PWs) have been used, I think that by OAM, we mean active OAM (per RFC 7799 classification of OAM measurement methods). I believe that it would be helpful to explicitly refer here to the active OAM and differentiate from, for example, IAOM, which is classified as a hybrid OAM method.

And to my comment. In PWs, using GAL is optional in PWs, MPLS-TP, and non-MPLS-TP (RFC 6423), and ACH can be used without GAL. It has been understood that all G-ACh channel types are also applicable to PW ACH (and vice versa). Let us be mindful of that when discussing the future use of GAL/G-ACh.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: LoaAndersson
To: [email-masked];
CC: [email-masked];[email-masked];DetNet Chairs;
Date: 2021/08/05 07:52
Subject: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

 

 

/Loa

--

---

From: <[email-masked]>
Date: Sat, 7 Aug 2021 06:33:58 +0800 (CST)

Hi Rakesh,

I don't think any IETF document dictates that an MPLS packet with GAL/G-ACh must be "punted out of the fast path in forwarding". I always thought that how a packet is processed is entirely implementation detail, which is also applicable to packets with GAL/G-ACh. For example, for many years now, BFD is supported using HW, whether over IP or MPLS data planes. I can imagine that in an MPLS-TP environment with non-IP encapsulation, BFD control messages over the Continuity Check G-ACh channel (0x0022), still be processed in HW without being punted to the slow-path processing.

Regards,

Greg Mirsky

Original Mail

Sender: RakeshGandhi
To: Loa Andersson;
CC: [email-masked];[email-masked];[email-masked];DetNet Chairs;
Date: 2021/08/06 07:01
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

Hi WG,

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. 

<RG> The last sentence needs some clarification. The packet with GAL is punted out of the fast path in forwarding, so user-traffic does not carry it, so it makes sense. However, packets could carry GACH without GAL. The user-traffic could also carry a GACH without GAL if use-case makes sense. I am not sure we are ready to add this restriction just yet.

Thanks,
Rakesh

 

 

 
 /Loa

 --

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 7 Aug 2021 01:33:11 +0200

Not rejecting or applauding this proposal yet,
but would like to see a motivation/justification.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 9 Aug 2021 07:42:38 +0100

> On 6 Aug 2021, at 23:33, [email-masked] wrote:
> 
> Hi Rakesh,
> 
> I don't think any IETF document dictates that an MPLS packet with GAL/G-ACh must be "punted out of the fast path in forwarding”.
> 
Correct as far as I know also.
> I always thought that how a packet is processed is entirely implementation detail, which is also applicable to packets with GAL/G-ACh.
> 

Also correct although it is a simplification that I understand that at least one major vendor adopted.

- Stewart
> For example, for many years now, BFD is supported using HW, whether over IP or MPLS data planes. I can imagine that in an MPLS-TP environment with non-IP encapsulation, BFD control messages over the Continuity Check G-ACh channel (0x0022), still be processed in HW without being punted to the slow-path processing.
> 
> 
> 
> Regards,
> 
> Greg Mirsky
> 
> 
> 
> E: [email-masked] <mailto:[email-masked]> 
> www.zte.com.cn <http://www.zte.com.cn/>
> Original Mail
> Sender: RakeshGandhi
> To: Loa Andersson;
> On Thu, Aug 5, 2021 at 10:52 AM Loa Andersson <[email-masked] <mailto:[email-masked]>> wrote:
> https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda <https://trac.ietf.org/trac/mpls/wiki/2021-07-22-agenda>
> 
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>