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

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