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

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, <l.wood@surrey.ac.uk> wrote:

> No, my "why" is "why have metadata in the MPLS header at all"?
>
> Why does this have to be done inband?
>
> I am questioning the basis for doing this. There is no "must" here.
>
> Lloyd Wood
> http://about.me/lloydwood
> ________________________________________
> From: Xuxiaohu <xuxiaohu@huawei.com>
> Sent: Friday, 18 July 2014 1:17 PM
> To: Wood L  Dr (Electronic Eng); mpls@ietf.org
> Cc: spring@ietf.org; sfc@ietf.org
> Subject: RE: How to carry metadata/context in an MPLS packet
>
> 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: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk]
> > Sent: Friday, July 18, 2014 11:11 AM
> > To: Xuxiaohu; mpls@ietf.org
> > Cc: spring@ietf.org; sfc@ietf.org
> > 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 <mpls-bounces@ietf.org> on behalf of Xuxiaohu
> > <xuxiaohu@huawei.com>
> > Sent: Friday, 18 July 2014 11:58 AM
> > To: mpls@ietf.org
> > Cc: <spring@ietf.org>; sfc@ietf.org
> > 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):
> >
> > "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
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>