Hi Lloyd, I think and I do hope that we see only mpls centric proposals as this is one encapsulation used in the networks.
I hope other proposals will also address v6 encapsulations and that any encapsulation will use same metadata control plane. Best, R. On Jul 18, 2014 12:23 PM, <[email protected]> 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 <[email protected]> > Sent: Friday, 18 July 2014 1:17 PM > To: Wood L Dr (Electronic Eng); [email protected] > Cc: [email protected]; [email protected] > 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: [email protected] [mailto:[email protected]] > > Sent: Friday, July 18, 2014 11:11 AM > > To: Xuxiaohu; [email protected] > > Cc: [email protected]; [email protected] > > 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 <[email protected]> on behalf of Xuxiaohu > > <[email protected]> > > Sent: Friday, 18 July 2014 11:58 AM > > To: [email protected] > > Cc: <[email protected]>; [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
