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

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 <xuxiaohu@huawei.com> 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:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, July 18, 2014 3:27 PM
> *To:* Xuxiaohu; sfc@ietf.org
> *Cc:* mpls@ietf.org; <spring@ietf.org>
> *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 <xuxiaohu@huawei.com> wrote:
>
> 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
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
>