Hi Med, editors, et al,

Please see inline below.

> 
> Hi Med, et al,
> 
> Joel, Andy Malis, and I had some offline discussions of the 
> interworking concern and what text should be added in NSH doc. and 
> control plane requirement doc. to address the concern. Here is the discussed text:
> 
> Add following text in Section 3.4 of NSH doc.
> 
> This specification allows defining different semantics of metadata 
> type 1 related mandatory context headers, but the NSH header does not 
> convey that semantic in the context headers. An SF MUST receive the 
> data extraction schema first in order to get the data placed in the 
> mandatory context headers. How an SF gets the data extraction schema 
> for the mandatory context headers is outside the scope of this 
> specification and the specification does not make any assumption about 
> the content placed in the mandatory context headers. Upon receiving an 
> SFC packet with metadata type
> 1 present, if an SF does not yet receive the data extraction schema 
> for the mandatory context headers, it SHOULD process the packet as of 
> no metadata and MUST log this error.

[Med] I like the last sentence which is IMHO in the good direction to soften some interoperability issues. Some comments here:
(1) Because 4 MD#1 context headers are present, and in order to be aligned with the spec, the sentence would be written to not treat them as a single field but as individual ones, i.e., indicate what to do if the semantic of at least one field is not supplied...but this is not my preference.  
[Lucy] see your point.
(2) My preference is to merge the 4 fields in one single field. I still don't understand why 4 fields. I'm even puzzled if the semantic is not defined. If this option is adopted, then your text is good (modulo my comment 3). This modification will be required to be added to the NSH Spec:
[Lucy] Agree. MD#1 only means 16bytes existence after SFI header and these 16bytes are used for carrying metadata. I support following change.

OLD: 

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Service Path Identifer               | Service Index |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Ver|O|C|R|R|R|R|R|R|   Length  |  MD type=0x1  | Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Service Path Identifer               | Service Index |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    |                                                               |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(3) Because these fields are called "MANDATORY Context Header", I'm tempted to suggest "MUST NOT process + Log" instead of "SHOULD process + Log" 
[Lucy] how about: Upon receiving an SFC packet with metadata type 1 present, if an SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context header, it MUST NOT process the packet and MUST log this error.
(4) Please change "SF" to "SFC-aware SF"  
[Lucy] ack.
> 
> Add following text to control plane requirement doc.
> 
> SFC encapsulation protocol [NSH] includes metadata type 1 with 
> mandatory context headers that can be used to convey metadata along an 
> SFC path. The protocol allows defining different semantics in the 
> context headers but the NSH header does not convey that semantics in 
> the context header. The protocol requires an SF using the data placed 
> in the MD#1 mandatory context headers to use information external to 
> the NSH data plane to understand the semantics of the context data. 
> Therefore, control plane solutions for SFC must include capabilities 
> to provide such context semantics, including any suitable scoping 
> information about the scoping, to the SF.

[Med] Unless there are objections, this text will be included in the CP requirements draft. Thank you.
[Lucy] Great!

Thanks,
Lucy

> 
> Will that acceptable? Comment and improvement suggestion are welcome.
> 
> Regards,
> Lucy
> 
> 
> 
> 
> -----Original Message-----
> From: mohamed.boucadair@orange.com 
> [mailto:mohamed.boucadair@orange.com]
> Sent: Wednesday, October 19, 2016 7:23 AM
> To: Lucy yong; Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron 
> Parker; sfc@ietf.org
> Subject: RE: [sfc] metadata type 1 constraint
> 
> Hi Lucy,
> 
> I like your proposed text. Here is some minor modifications:
> 
> 
>    OLD:
> 
>    NSH allows defining different semantics on MD#1 field but the NSH
>    header on an SFC packet does not convey the semantics on the MD#1
>    field.  For a SFC that uses MD#1, the control plane MUST define a
>    MD#1 semantics for the SFC, and it MUST inform the corresponding data
>    extraction scheme to individual SFs in the SFC that are required to
>    use data placed in the MD#1 field.  Note: two SFs in a SFC may use
>    same or different data placed in MD#1 field.
> 
>    NEW:
> 
>    This specification allows defining different semantics of MD#1
>    related mandatory context headers, but the NSH header does not convey
>    that semantic.  For an SFC-enabled domain that uses MD#1, the control
>    plane MUST communicate the semantic of the mandatory context headers
>    together with their scope (per chain, per domain, etc.) to the
>    underlying SFC-aware SFs.  Note that SFC-aware SFs in a given chain
>    may use the same or different data placed in MD#1 mandatory context
>    headers.  This document does not make any assumption about the data
>    to be conveyed in context headers nor whether the same data structure
>    is used along a given chain.  Those considerations are deployment-
>    specific.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : sfc [mailto:sfc-bounces@ietf.org] De la part de Lucy yong 
> > Envoyé
> > : mercredi 19 octobre 2016 13:53 À : Joel M. Halpern; Van De Velde, 
> > Gunter (Nokia - BE); Ron Parker; sfc@ietf.org Objet : Re: [sfc] 
> > metadata type 1 constraint
> >
> > Hi Joel and all,
> >
> > Our current approach is to allow definition of allocation schemes, 
> > but not to mandate any specific allocation scheme for MD-1.
> > [Lucy] In other words, NSH allows defining different semantics on 
> > MD#1 field but the NSH header on an SFC packet does not convey the 
> > semantics on the MD#1 field. Thus, I propose adding this text to 
> > section 3.4. - NSH allows defining different semantics on MD#1 field 
> > but the NSH header on an SFC packet does not convey the semantics on 
> > the MD#1 field. For a SFC that uses MD#1, the control plane MUST 
> > define a MD#1 semantics for the SFC, and it MUST inform the 
> > corresponding data extraction scheme to individual SFs in the SFC 
> > that
> are required to use data placed in the MD#1 field. Note:
> > two SFs in a SFC may use same or different data placed in MD#1 field.
> > -
> >
> > That seems to me to be a good approach, workable, and what we have 
> > agreed and documented.
> > [Lucy] Let's not reopen what has been agreed and documented and 
> > think of what to add to address the interworking concern. Will above 
> > text
> help?
> >
> > Regards,
> > Lucy
> >
> >
> >
> > Yours,
> > Joel
> >
> > On 10/18/16 12:09 PM, Van De Velde, Gunter (Nokia - BE) wrote:
> > > If NSH MD Type-1 defines for the metadata to be Opaque, then we 
> > > should
> > not make an effort to define it, and just tread it as Opaque content 
> > imo and live with the consequences…and in that case use MD Type-2 
> > for these types of well known metadata transport mechanisms.
> > >
> > > If however, we decide to define the allocation schemes, then we 
> > > should
> > also architect an indicator for the used allocation scheme.
> > > At this point in time, there models were suggested (overload 
> > > Length,
> > overload MD type, use few bits of MD context data).
> > > I strongly believe there is value in having the metadata 
> > > allocation
> > structure signalled within the NSH itself, even for MD Type-1.
> > > (It avoids control plane signalling and creates state which needs 
> > > to be
> > maintained, and that sounds as a very expensive operation).
> > >
> > > Alternate is to just say as Lucy suggests, and restrict MD Type-1
> > Service Chain SF’s per allocation scheme. This is a solution that 
> > works, albeit it is a very impacting restriction for flexibility and 
> > resource sharing).
> > >
> > > G/
> > >
> > >
> > > On 18/10/2016, 16:49, "sfc on behalf of Lucy yong"
> > > <sfc-bounces@ietf.org
> > on behalf of lucy.yong@huawei.com> wrote:
> > >
> > >     Comment on "Allocating a nibble or byte within the 32 bytes
> > (probably the first nibble or byte) is yet another."
> > >
> > >     Lucy: Technically We can do this on MD#1, but NSH already 
> > > defines
> > MD#2. Is the variable length the only feature that hardware can't 
> > deal with?
> > >
> > >     Lucy
> > >
> > >     -----Original Message-----
> > >     From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
> > >     Sent: Tuesday, October 18, 2016 10:05 AM
> > >     To: Lucy yong; Joel M. Halpern; sfc@ietf.org
> > >     Subject: RE: [sfc] metadata type 1 constraint
> > >
> > >     Even though the interpretation of metadata is dependent on 
> > > control
> > plane interaction, where I think the original proposal has value is 
> > that there might be multiple separate interpretations simultaneously
> within the
> > same administrative domain.   A way to describe, on the wire, which of
> > those interpretations is in force for that particular SFP seems valuable
> > to me.   You could definitely argue that the control plane could install
> > the interpretation locally on a per SFP basis;  also being explicit 
> > on the wire will likely enhance interoperability and debuggability.
> > >
> > >     The value would be locally significant within the 
> > > administrative
> > domain (i.e., metadata schema 1, metatadata schema 2, etc.).
> Overloading
> > length is one way.   Overloading MD-type is another.   Allocating a
> nibble
> > or byte within the 32 bytes (probably the first nibble or byte) is 
> > yet another.
> > >
> > >        Ron
> > >
> > >
> > >     -----Original Message-----
> > >     From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Lucy yong
> > >     Sent: Tuesday, October 18, 2016 10:27 AM
> > >     To: Joel M. Halpern <jmh@joelhalpern.com>; sfc@ietf.org
> > >     Subject: Re: [sfc] metadata type 1 constraint
> > >
> > >     Joel,
> > >
> > >     Lucy, while your two text proposals are not wrong, I do not 
> > > see them
> > as adding any clarity to the document.  The sections are very short 
> > and clearly define only the syntax.
> > >     [Lucy] True. However, for this document, readers expect 
> > > Section
> > > 3 to
> > describe NSH syntax and semantics. Section 3.1-3.3 do both. If 
> > section
> > 3.4 and 3.5 just specify the syntax, from documenting perspective, 
> > it is important to explicitly state the two text out.
> > >
> > >     With regard to SF and MD-1 support, there is absolutely 
> > > nothing that
> > requires an SF to support only one MD-1 structure.  Rather, the 
> > control mechanisms will tell the SF how to extract the data it needs 
> > from the MD-1 header.
> > >     [Lucy] This puts much uncertainty for a single SF on what to
> > implement, which causes people's concern. IMO, if we don't have a 
> > way to address this challenge here (you stated in interim meeting), 
> > pushing it to another place does not solve/address it. For example, 
> > will the control mechanisms tell an SF how to extract the data it 
> > needs from the MD-1 header per a SFP, or per a SFC, or for all SFC 
> > packets, or per payload flow, or combination of them? This will 
> > significantly impact SF implementation. The reason having MD type 1 
> > is
> that is hardware friendly.
> > Leaving these uncertainty open, not sure if the reason still makes a 
> > sense.
> > >
> > >     Lucy
> > >     I believe there is already text in the control plane 
> > > requirements
> > document that describes the need for this control functionality.
> > >
> > >
> > >
> > >     Yours,
> > >     Joel
> > >
> > >     On 10/17/16 11:07 AM, Lucy yong wrote:
> > >     > Suggestions:
> > >     >
> > >     > Section 3.4 should mention that this section only defines MD 
> > > type
> > 1
> > >     > format. The semantics of MD Type 1 is outside the scope of this
> > >     > document. Thus, the use of MD type 1 is outside the scope of
> this
> > >     > document.
> > >     >
> > >     > Section 3.5 should mention that this section only defines 
> > > MEF type
> > 2
> > >     > format. The semantics of MD type 2 is outside the scope of this
> > >     > document. Thus, the use of MD type 2 is outside the scope of
> this
> > >     > documents.
> > >     >
> > >     > IMO: these statements are important for the sections.
> > >     >
> > >     > Joel, MD semantics is critical for SFs. More than one 
> > > semantics of
> > MD
> > >     > type 1 MUST NOT be specified for a SF. This should be a
> > requirement in
> > >     > the SFC arch. as a result of NSH design's, but the 
> > > architecture
> is
> > >     > already published. Maybe control plane requirement is the 
> > > place
> to
> > >     > state this out as the result of SFC arch and NSH design.
> > >     >
> > >     > Thanks, Lucy
> > >     >
> > >     > -----Original Message----- From: sfc 
> > > [mailto:sfc-bounces@ietf.org]
> > On
> > >     > Behalf Of Joel M. Halpern Sent: Sunday, October 16, 2016 
> > > 8:39 PM
> > To:
> > >     > Lucy yong; sfc@ietf.org Subject: Re: [sfc] metadata type 1
> > constraint
> > >     >
> > >     > A) I woud not want to state any such constraint in the NSH
> > document,
> > >     > because B) In fact, the SFP ID is in every NSH header.  So 
> > > yes,
> > there
> > >     > is context if it is needed
> > >     >
> > >     > It is true that MD-2 is more flexible than MD-1.  I don't 
> > > think
> > anyone
> > >     > disagrees with that.
> > >     >
> > >     > Yours, Joel
> > >     >
> > >     > On 10/16/16 3:25 PM, Lucy yong wrote:
> > >     >> RFC7665 (SFC architecture) states  "This architecture 
> > > allows an
> > SF to
> > >     >> be part of multiple SFPs and SFCs."
> > >     >>
> > >     >>
> > >     >>
> > >     >> NSH just specifies MD type1 with a 16 bytes field, and  NSH
> doc.
> > >     >> states
> > >     >>
> > >     >> 3.  NSH provides a mechanism to carry shared metadata between
> > >     >>
> > >     >> participating entities and service functions.  The semantics of
> > >     >>
> > >     >> the shared metadata is communicated via a control plane, 
> > > which
> is
> > >     >>
> > >     >> outside the scope of this document, to participating nodes.
> > >     >>
> > >     >>
> > >     >>
> > >     >> Comments: this mean: when an SF that is part of multiple 
> > > SFCs and
> > MD
> > >     >> type 1 is used in some of SFCs, these SFCs MUST have the same
> > >     >> metadata semantics.  This is because that NSH does not 
> > > convey
> SFC
> > >     >> identifier. For MD type 2, different SFCs may insert 
> > > different
> > list
> > >     >> of TLVs and each TLV has a type and specified semantics 
> > > along
> > (the
> > >     >> TLVs will be specified in different doc.).
> > >     >>
> > >     >>
> > >     >>
> > >     >> Should we state out this constraint in NSH doc.
> > >     >>
> > >     >>
> > >     >>
> > >     >> Lucy
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >>
> > >     >> _______________________________________________ sfc mailing
> list
> > >     >> sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
> > >     >>
> > >     >
> > >     > _______________________________________________ sfc mailing list
> > >     > sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
> > >     >
> > >
> > >     _______________________________________________
> > >     sfc mailing list
> > >     sfc@ietf.org
> > >     https://www.ietf.org/mailman/listinfo/sfc
> > >
> > >     _______________________________________________
> > >     sfc mailing list
> > >     sfc@ietf.org
> > >     https://www.ietf.org/mailman/listinfo/sfc
> > >
> > >
> > _______________________________________________
> > sfc mailing list
> > sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc