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

Hi Lloyd,

I believe that Xiaohu means that we need a way to *indicate* that metadata
follows the bottom of the MPLS label stack. There are multiple ways to do
that and as Robert quite rightly pointed out some mechanisms already exist
such as reserved labels, special-purpose labels, context labels, my old
draft (which FYI has expired) etc.

On 7/17/14, 11:22 PM, "l.wood@surrey.ac.uk" <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