Hi Ron, I would be very very carefull to place matadata inband (ie embed it in customer data packets) of data plane.
Few reasons for consideration: - Adding anything over hundred bytes may become pretty overwhelming for small size customer packets - Adding anything over already maxed size packet may cause MTU issues and fragmentation (which in many cases is not possible in the middle of the network). Keep in mind also encrypted data. - Anything which is variable length in the data plane and which is opaque to the data plane causes additional data plane requirements which a lot of hardware may have a hard time to deal with - Inband transport provides no option to pre-populate the state at the backup devices / backup paths where no active traffic is traversing before any network event affecting primary path - A lot of appliances may not be able to be transparent to opaque variable length metadata resulting in metadata information loss. For all of the above reasons (and I am sure many more not listed above) I would keep customer data packets alone and when needed limit only insertion of a pointer to metadata context learned out-of-band. (Out-of-band is a bit misleading term here as metadata can happily travel via the same set of links as customer data. What it really means is out-of-customer-data-packets). Best regards, R. On Fri, Jul 18, 2014 at 2:05 PM, Ron Parker <ron_par...@affirmednetworks.com > wrote: > Robert, > > > > Inband is one way -- it simplifies things at the cost of packet growth. > Out-of-band (i.e., signaling) is another way – it adds complexity but > doesn’t grow the data plane packets. Congruent out-of-band is a variation > on out-of-band that may partially reduce out-of-band complexity. I think > many opinions on the thread have been that all are in scope, > architecturally. Draft-zhang-sfc-sch (I am a co-author), for example, > defines inband metadata explicitly, but states in text that out-of-band is > possible, too. I’m sure this will be a topic of discussion when we start > discussing control plane requirements. > > > > Ron > > > > *From:* sfc [mailto:sfc-boun...@ietf.org] *On Behalf Of *Robert Raszuk > > *Sent:* Friday, July 18, 2014 3:27 AM > *To:* Xuxiaohu; s...@ietf.org > *Cc:* m...@ietf.org; <spring@ietf.org> > *Subject:* Re: [sfc] [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
