Subject: [sfc] How to carry metadata/context in an MPLS packet

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 01:58:51 +0000

Hi all,

I'm now considering how to carry metadata/context in an MPLS packet. I just noticed that draft-guichard-mpls-metadata-00 (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes a way to carry metadata/context in an MPLS packet (see below):

"3.  Metadata Channel Header Format

   The presence of metadata within an MPLS packet must be indicated in
   the encapsulation.  This document defines that the G-ACh Generic
   Associated Channel Label (GAL) [RFC5586] with label value 13 is
   utilized for this purpose.  The GAL label provides a method to
   identify that a packet contains an "Associated Channel Header (ACH)"
   followed by a non-service payload.

   [RFC5586] identifies the G-ACh Generic Associated Channel by setting
   the first nibble of the ACH that immediately follows the bottom label
   in the stack if the GAL label is present, to 0001b.  Further
   [RFC5586] expects that the ACH not be used to carry user data
   traffic.  This document proposes an extension to allow the first
   nibble of the ACH to be set to 0000b and, when following the GAL, be
   interpreted using the semantics defined in
   [I-D.guichard-metadata-header] to allow metadata to be carried
   through the G-ACh channel."

However, it seems that the special usage of the GAL as mentioned above still conflicts with the following statement quoted from [RFC5586]:

"  The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST NOT
   appear more than once in the label stack."

I wonder whether the special usage of the GAL as proposed in the above draft would result in any backward compatibility issue. In addition, I wonder whether it's worthwhile to reconsider the possibility of introducing a Protocol Type (PT) field immediately after the bottom of the MPLS label stack. With such PT field, any kind of future MPLS payload (e.g., metadata header or NSH) can be easily identified.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 03:17:51 +0000

The presence of metadata within an MPLS packet must be indicated in the encapsulation. I think that's the "why" you may want to know.

Best regards,
Xiaohu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 18, 2014 11:11 AM
> To: Xuxiaohu; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: How to carry metadata/context in an MPLS packet
> 
> How? A better question is "why?"
> 
> What has to be done in MPLS that cannot be done outside it?
> 
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: mpls <[email-masked]> on behalf of Xuxiaohu
> <[email-masked]>
> Sent: Friday, 18 July 2014 11:58 AM
> To: [email-masked]
> Cc: <[email-masked]>; [email-masked]
> Subject: [mpls] How to carry metadata/context in an MPLS packet
> 
> Hi all,
> 
> I'm now considering how to carry metadata/context in an MPLS packet. I just
> noticed that draft-guichard-mpls-metadata-00
> (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6) proposes
> a way to carry metadata/context in an MPLS packet (see below):
> 
> However, it seems that the special usage of the GAL as mentioned above still
> conflicts with the following statement quoted from [RFC5586]:
> 
> I wonder whether the special usage of the GAL as proposed in the above draft
> would result in any backward compatibility issue. In addition, I wonder whether
> it's worthwhile to reconsider the possibility of introducing a Protocol Type (PT)
> field immediately after the bottom of the MPLS label stack. With such PT field,
> any kind of future MPLS payload (e.g., metadata header or NSH) can be easily
> identified.
> 
> Best regards,
> Xiaohu
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 06:33:09 +0000

> Sent: Friday, July 18, 2014 11:22 AM
> No, my "why" is "why have metadata in the MPLS header at all"?

You could choose to carry the metadata context instead of the metadata itself in the data packet (See section 3.5 of the following draft (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8)).

> Why does this have to be done inband?

It doesn't have to be done inband. However, since In-band marking (see section 3.1 of the following draft (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8)) ) is one of the approaches of metadata sharing, I'm just considering how to realize that in-band approach in the MPLS case.

Best regards,
Xiaohu

> I am questioning the basis for doing this. There is no "must" here.
> 
> Lloyd Wood
> From: Xuxiaohu <[email-masked]>
> Sent: Friday, 18 July 2014 1:17 PM
> To: Wood L  Dr (Electronic Eng); [email-masked]
> The presence of metadata within an MPLS packet must be indicated in the
> encapsulation. I think that's the "why" you may want to know.
> 
> Best regards,
> Xiaohu
> 
> > I'm now considering how to carry metadata/context in an MPLS packet. I
> > just noticed that draft-guichard-mpls-metadata-00
> > (http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6)
> > proposes a way to carry metadata/context in an MPLS packet (see below):
> >
> > However, it seems that the special usage of the GAL as mentioned above
> > still conflicts with the following statement quoted from [RFC5586]:
> >
> > I wonder whether the special usage of the GAL as proposed in the above
> > draft would result in any backward compatibility issue. In addition, I
> > wonder whether it's worthwhile to reconsider the possibility of
> > introducing a Protocol Type (PT) field immediately after the bottom of
> > the MPLS label stack. With such PT field, any kind of future MPLS
> > payload (e.g., metadata header or NSH) can be easily identified.
> >
> > Best regards,
> > Xiaohu
> >

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 06:41:55 +0000

> From: Xuxiaohu
> Sent: Friday, July 18, 2014 2:33 PM
> To: [email-masked]'; [email-masked]
> You could choose to carry the metadata context instead of the metadata itself in
> the data packet (See section 3.5 of the following draft
> (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-
> 8)).
> 
> It doesn't have to be done inband. However, since In-band marking (see section
> 3.1 of the following draft
> (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-
> 8)) ) is one of the approaches of metadata sharing, I'm just considering how to
> realize that in-band approach in the MPLS case.
> 
> Best regards,
> Xiaohu
> 

By the way, you are right that carrying metadata or metadata context within data packets is optional, rather than mandatory.

Best regards,
Xiaohu

> > the encapsulation. I think that's the "why" you may want to know.
> >
> > Best regards,
> > Xiaohu
> >
> > > I'm now considering how to carry metadata/context in an MPLS packet.
> > > I just noticed that draft-guichard-mpls-metadata-00
> > > However, it seems that the special usage of the GAL as mentioned
> > > above still conflicts with the following statement quoted from [RFC5586]:
> > >
> > > I wonder whether the special usage of the GAL as proposed in the
> > > above draft would result in any backward compatibility issue. In
> > > addition, I wonder whether it's worthwhile to reconsider the
> > > possibility of introducing a Protocol Type (PT) field immediately
> > > after the bottom of the MPLS label stack. With such PT field, any
> > > kind of future MPLS payload (e.g., metadata header or NSH) can be easily
> identified.
> > >
> > > Best regards,
> > > Xiaohu
> > >

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Jul 2014 09:26:52 +0200

All,

Is the idea of using data plane to carry complete metadata is "the way" or
"a way" of approaching the problem ? Has this been already discussed ?

I would rather consider to carry metadata in control plane and only attach
a reference_id (and only when it is needed) to the data plane.

Rgs,
R.

On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <[email-masked]> wrote:

> just noticed that draft-guichard-mpls-metadata-00 (
> http://tools.ietf.org/html/draft-guichard-mpls-metadata-00#page-6)
> wonder whether it's worthwhile to reconsider the possibility of introducing
> a Protocol Type (PT) field immediately after the bottom of the MPLS label
> stack. With such PT field, any kind of future MPLS payload (e.g., metadata
> header or NSH) can be easily identified.
>
> Best regards,
> Xiaohu
>
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 07:43:06 +0000

Hi Robert,

It seems that the concept of “reference_id” looks much similar with the concept of “correlator” as defined in section 3.3 of (http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8). That’s the context ID of the metadata I meant.

If that  “reference_id” is attached to the MPLS packet, it seems that you still need some way to indicate the presence of that “reference_id” in the MPLS packet.

Best regards,
Xiaohu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, July 18, 2014 3:27 PM
To: Xuxiaohu; [email-masked]
Cc: [email-masked]; <[email-masked]>
Subject: Re: [spring] How to carry metadata/context in an MPLS packet

All,

Is the idea of using data plane to carry complete metadata is "the way" or "a way" of approaching the problem ? Has this been already discussed ?

I would rather consider to carry metadata in control plane and only attach a reference_id (and only when it is needed) to the data plane.

Rgs,
R.

On Fri, Jul 18, 2014 at 3:58 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards,
Xiaohu

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Jul 2014 09:55:28 +0200

Hi Xu,

Yes indeed I do consider proposal from Bruno and Jerome as exact match to
what I had in mind with their "correlator" to mine "reference_id". Just
terminology nit.

Except it is not section 3.3 but 3.5 ...

"3.5. Hybrid in-band marking and out-of-band signaling

Metadata can be signaled using a hybrid approach combining in-band marking
and out-of-band signaling.

Each data packet can carry a small fixed-length field which serves as a
"correlator".  An out-of-band signaling protocol can then be used to map
the correlator value to the actual metadata value(s)."

> If that  “reference_id” is attached to the MPLS
> packet, it seems that you still need some way to
> indicate the presence of that “reference_id” in
> the MPLS packet.

I am not sure we need yet another point solution indicator.

We already have two general purpose mechanism which seems like possible
indicators which could be used here:

* RFC 5331 - MPLS Upstream Label Assignment and Context-Specific Label Space

* RFC 7274 - Allocating and Retiring Special-Purpose MPLS Labels

Rgs,
r.

On Fri, Jul 18, 2014 at 9:43 AM, Xuxiaohu <[email-masked]> wrote:

>  Hi Robert,
>
>
>
> It seems that the concept of “reference_id” looks much similar with the
> concept of “correlator” as defined in section 3.3 of (
> http://tools.ietf.org/html/draft-rijsman-sfc-metadata-considerations-00#page-8).
> That’s the context ID of the metadata I meant.
>
>
>
> If that  “reference_id” is attached to the MPLS packet, it seems that you
> still need some way to indicate the presence of that “reference_id” in the
> MPLS packet.
>
>
>
> Best regards,
>
> Xiaohu
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, July 18, 2014 3:27 PM
> *To:* Xuxiaohu; [email-masked]
> *Cc:* [email-masked]; <[email-masked]>
> *Subject:* Re: [spring] How to carry metadata/context in an MPLS packet
>
>
>
> All,
>
>
>

---

From: <[email-masked]>
Date: Fri, 18 Jul 2014 03:10:56 +0000

Lloyd Wood
From: mpls <[email-masked]> on behalf of Xuxiaohu <[email-masked]>

Hi all,

Best regards,
Xiaohu

---

From: <[email-masked]>
Date: Fri, 18 Jul 2014 03:22:26 +0000

Lloyd Wood

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Jul 2014 12:31:59 +0200

Hi Lloyd,

I think and I do hope that we see only mpls centric proposals as this is
one encapsulation used in the networks.

I hope other proposals will also address v6 encapsulations and that any
encapsulation will use same metadata control plane.

Best,
R.
On Jul 18, 2014 12:23 PM, <[email-masked]> wrote:

> just
> proposes
> still
> draft
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Fri, 18 Jul 2014 12:05:32 +0000

Robert,

Inband is one way -- it simplifies things at the cost of packet growth.   Out-of-band (i.e., signaling) is another way – it adds complexity but doesn’t grow the data plane packets.   Congruent out-of-band is a variation on out-of-band that may partially reduce out-of-band complexity.    I think many opinions on the thread have been that all are in scope, architecturally.    Draft-zhang-sfc-sch (I am a co-author), for example, defines inband metadata explicitly, but states in text that out-of-band is possible, too.    I’m sure this will be a topic of discussion when we start discussing control plane requirements.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, July 18, 2014 3:27 AM
To: Xuxiaohu; [email-masked]
Cc: [email-masked]; <[email-masked]>
Subject: Re: [sfc] [spring] How to carry metadata/context in an MPLS packet

All,

Rgs,
R.

Best regards,
Xiaohu

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Jul 2014 16:43:30 +0200

Hi Ron,

I would be very very carefull to place matadata inband (ie embed it in
customer data packets) of data plane.

Few reasons for consideration:

- Adding anything over hundred bytes may become pretty overwhelming for
small size customer packets

- Adding anything over already maxed size packet may cause MTU issues and
fragmentation (which in many cases is not possible in the middle of the
network). Keep in mind also encrypted data.

- Anything which is variable length in the data plane and which is opaque
to the data plane causes additional data plane requirements which a lot of
hardware may have a hard time to deal with

- Inband transport provides no option to pre-populate the state at the
backup devices / backup paths where no active traffic is traversing before
any network event affecting primary path

- A lot of appliances may not be able to be transparent to opaque variable
length metadata resulting in metadata information loss.

For all of the above reasons (and I am sure many more not listed above) I
would keep customer data packets alone and when needed limit only insertion
of a pointer to metadata context learned out-of-band. (Out-of-band is a bit
misleading term here as metadata can happily travel via the same set of
links as customer data. What it really means is
out-of-customer-data-packets).

Best regards,
R.

On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker <[email-masked]
> wrote:

>  Robert,
>
>
>
> Inband is one way -- it simplifies things at the cost of packet growth.
> Out-of-band (i.e., signaling) is another way – it adds complexity but
> doesn’t grow the data plane packets.   Congruent out-of-band is a variation
> on out-of-band that may partially reduce out-of-band complexity.    I think
> many opinions on the thread have been that all are in scope,
> architecturally.    Draft-zhang-sfc-sch (I am a co-author), for example,
> defines inband metadata explicitly, but states in text that out-of-band is
> possible, too.    I’m sure this will be a topic of discussion when we start
> discussing control plane requirements.
>
>
>
>    Ron
>
>
>
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
>
> *Sent:* Friday, July 18, 2014 3:27 AM
> *Subject:* Re: [sfc] [spring] How to carry metadata/context in an MPLS
> packet
>
>
>
> All,
>
>
>