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

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<mailto: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<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring