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