Subject: [sfc] metadata type 1 constraint

From: Lucy yong <[email-masked]>
Date: Sun, 16 Oct 2016 19:25:53 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Oct 2016 21:39:19 -0400

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.”
>
>
>
> 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.).
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 15:07:42 +0000

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:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Sunday, October 16, 2016 8:39 PM
To: Lucy yong; [email-masked]
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

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 16:44:05 +0000

Lucy>  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.

GV> This means that for each type of allocation type there is need for a different unique SF. For example for a Firewall service I would need to deploy more as a single one just because the NSH MD allocation type is different? Do you believe such constraint makes sense? It sounds more logical that the NSH contains the right amount of info for the SF to decide how to service the packet.

G/

----------------
On 17/10/2016, 17:07, "sfc on behalf of Lucy yong" <[email-masked] on behalf of [email-masked]> wrote:

    Suggestions:

    

    Thanks,
    Lucy 
    
    -----Original Message-----
    From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Sunday, October 16, 2016 8:39 PM
    To: Lucy yong; [email-masked]
    Subject: Re: [sfc] metadata type 1 constraint

    
    Yours,
    Joel

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 16:51:24 +0000

-----Original Message-----
From: Van De Velde, Gunter (Nokia - BE) [mailto:[email-masked]] 
Sent: Monday, October 17, 2016 11:44 AM
To: Lucy yong; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

GV> This means that for each type of allocation type there is need for a different unique SF. For example for a Firewall service I would need to deploy more as a single one just because the NSH MD allocation type is different? Do you believe such constraint makes sense? It sounds more logical that the NSH contains the right amount of info for the SF to decide how to service the packet.
[Lucy] This is for the context of MD type 1. Do you want an SF to support different semantics for MD type 1? If yes, the SF has to have state to know which SFP ID use which MD semantics. I don't think that this is SFC design intention.

Lucy

G/

----------------

    Suggestions:

    

    Thanks,
    Lucy 
    
    -----Original Message-----
    From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
    Sent: Sunday, October 16, 2016 8:39 PM
    To: Lucy yong; [email-masked]
    Subject: Re: [sfc] metadata type 1 constraint

    
    Yours,
    Joel

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Mon, 17 Oct 2016 16:57:43 +0000

GV2> The main issue I see within this is that to understand the NSH MD Type-1 context info, there is need to have state based information instead of all info being stateless readable… 

G/

On 17/10/2016, 18:51, "sfc on behalf of Lucy yong" <[email-masked] on behalf of [email-masked]> wrote:

    -----Original Message-----
    From: Van De Velde, Gunter (Nokia - BE) [mailto:[email-masked]] 
    Sent: Monday, October 17, 2016 11:44 AM
    To: Lucy yong; Joel M. Halpern; [email-masked]
    Subject: Re: [sfc] metadata type 1 constraint

    
    Lucy
    
    G/

    ----------------
    
        Suggestions:

        

        Thanks,
        Lucy 
        
        -----Original Message-----
        From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
        Sent: Sunday, October 16, 2016 8:39 PM
        To: Lucy yong; [email-masked]
        Subject: Re: [sfc] metadata type 1 constraint

        
        Yours,
        Joel

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 17:01:57 +0000

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Monday, October 17, 2016 11:58 AM
To: Lucy yong; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

GV2> The main issue I see within this is that to understand the NSH MD Type-1 context info, there is need to have state based information instead of all info being stateless readable… 
[Lucy] an SF will have some state, e.g. per flow. Why does it need the state per a SFP (unless this case)?

Lucy

G/

    
    -----Original Message-----
    From: Van De Velde, Gunter (Nokia - BE) [mailto:[email-masked]] 
    Sent: Monday, October 17, 2016 11:44 AM
    To: Lucy yong; Joel M. Halpern; [email-masked]
    Subject: Re: [sfc] metadata type 1 constraint

    
    Lucy
    
    G/

    ----------------
    
        Suggestions:

        

        Thanks,
        Lucy 
        
        -----Original Message-----
        From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
        Sent: Sunday, October 16, 2016 8:39 PM
        To: Lucy yong; [email-masked]
        Subject: Re: [sfc] metadata type 1 constraint

        
        Yours,
        Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 17 Oct 2016 17:06:08 +0000

Hi, Lucy,

On Oct 16, 2016, at 3:25 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

RFC7665 (SFC architecture) states  “This architecture allows an SF to be part of multiple SFPs and SFCs.”

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.

No, it doesn’t. The SPI provides context for this determination.

 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.).

No, as per above.

Thanks,

— Carlos.

Lucy

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Lucy yong <[email-masked]>
Date: Mon, 17 Oct 2016 17:10:23 +0000

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, October 17, 2016 12:06 PM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Hi, Lucy,

No, it doesn’t. The SPI provides context for this determination.
[Lucy] We are giving SPI multiple roles.

Lucy

No, as per above.

Thanks,

— Carlos.

Lucy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Oct 2016 21:49:14 -0400

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.

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.
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.
>
> 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:[email-masked]] On
> Behalf Of Joel M. Halpern Sent: Sunday, October 16, 2016 8:39 PM To:
> Lucy yong; [email-masked] 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
>
> Yours, Joel
>> 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.).
>>
>>
>>
>> _______________________________________________ sfc mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>>
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Tue, 18 Oct 2016 14:27:12 +0000

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:
> 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 
> Lucy yong; [email-masked] Subject: Re: [sfc] metadata type 1 constraint
>
>> type 1 is used in some of SFCs, these SFCs MUST have the same

---

From: Ron Parker <[email-masked]>
Date: Tue, 18 Oct 2016 15:04:30 +0000

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:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, October 18, 2016 10:27 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Joel,

Lucy

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Tue, 18 Oct 2016 15:49:11 +0000

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:[email-masked]] 
Sent: Tuesday, October 18, 2016 10:05 AM
To: Lucy yong; Joel M. Halpern; [email-masked]
Subject: RE: [sfc] metadata type 1 constraint

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Tuesday, October 18, 2016 10:27 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Joel,

Lucy

Yours,
Joel

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Tue, 18 Oct 2016 16:09:07 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    
    Lucy
    
    -----Original Message-----
    From: Ron Parker [mailto:[email-masked]] 
    Sent: Tuesday, October 18, 2016 10:05 AM
    To: Lucy yong; Joel M. Halpern; [email-masked]
    Subject: RE: [sfc] metadata type 1 constraint

    
       Ron

    -----Original Message-----
    From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
    Sent: Tuesday, October 18, 2016 10:27 AM
    To: Joel M. Halpern <[email-masked]>; [email-masked]
    Subject: Re: [sfc] metadata type 1 constraint
    
    Joel,

    
    Lucy

    Yours,
    Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Oct 2016 20:14:47 -0400

Our current approach is to allow definition of allocation schemes, but 
not to mandate any specific allocation scheme for MD-1.
That seems to me to be a good approach, workable, and what we have 
agreed and documented.

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 19 Oct 2016 11:53:14 +0000

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

---

From: <[email-masked]>
Date: Wed, 19 Oct 2016 12:22:52 +0000

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:[email-masked]] De la part de Lucy yong
> Envoyé : mercredi 19 octobre 2016 13:53
> À : Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron Parker;
> [email-masked]
> 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. -
> 
> [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
> 
> > 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" <[email-masked]
> on behalf of [email-masked]> 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
> >
> >     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
> >
> >
> >     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
> >     [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.
> >
> 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
> >     >> RFC7665 (SFC architecture) states  "This architecture allows an
> SF to
> >     >> be part of multiple SFPs and SFCs."
> >     >>
> >     >>
> >     >>
> MD

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 19 Oct 2016 14:33:15 +0000

Joel,

I agree with you: the current approach is simple and workable.  The allocation scheme are simply information examples.

Paul

> On Oct 18, 2016, at 8:14 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 19 Oct 2016 14:38:39 +0000

Hi Med,

Your text is better. Think more on this. Maybe some text is good to put into SFC-CP requirement document. NSH needs to reference it. We can consider adding this text to NSH section 3.4, and other text into SFC-CP req. doc.

This specification allows defining different semantics of MD#1 related mandatory context headers, but the NSH header does not convey
that semantics in the context header. The use of MD#1 mandatory context header to convey data in an SFC-enabled domain is specified in [SFC-CPREQ] and is outside the scope of this document.

Any thought on this?

Thanks,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 7:23 AM
To: Lucy yong; Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron Parker; [email-masked]
Subject: RE: [sfc] metadata type 1 constraint

Hi Lucy, 

   OLD:

   NEW:

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Lucy yong Envoyé 
> : mercredi 19 octobre 2016 13:53 À : Joel M. Halpern; Van De Velde, 
> Gunter (Nokia - BE); Ron Parker; [email-masked] Objet : Re: [sfc] 
> metadata type 1 constraint
> 
> Hi Joel and all,
> 
> 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:
> [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
> 
> 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.
> >
> 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/
> >
> >
> plane interaction, where I think the original proposal has value is 
> that there might be multiple separate interpretations simultaneously within the
> the interpretation locally on a per SFP basis;  also being explicit on 
> the wire will likely enhance interoperability and debuggability.
> >
> as adding any clarity to the document.  The sections are very short 
> and clearly define only the syntax.
> 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.
> >
> 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.
> 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.
> >     > Section 3.4 should mention that this section only defines MD 
> > type
> 1
> >     > Section 3.5 should mention that this section only defines MEF 
> > type
> 2
> >     > Joel, MD semantics is critical for SFs. More than one 
> > semantics of
> MD
> >     > -----Original Message----- From: sfc 
> > [mailto:[email-masked]]
> On
> >     > Behalf Of Joel M. Halpern Sent: Sunday, October 16, 2016 8:39 
> > PM
> To:
> >     > because B) In fact, the SFP ID is in every NSH header.  So 
> > yes,
> there
> >     > It is true that MD-2 is more flexible than MD-1.  I don't 
> > think
> anyone
> >     > disagrees with that.
> >     >
> >     > Yours, Joel
> >     >
> >     >> identifier. For MD type 2, different SFCs may insert 
> > different
> list

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 19 Oct 2016 15:22:14 +0000

It is sad that we significantly increase the operational burden for allocation scheme signalling for MD#1. I am dazzled the WG believes stateful signalling is easier for deployment compared with a stateless solution for MD#1. The imposed operational complexity is significant with current proposal.

G/

On 19/10/2016, 15:33, "sfc on behalf of Paul Quinn (paulq)" <[email-masked] on behalf of [email-masked]> wrote:

    Joel,

    Paul

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Oct 2016 15:44:01 +0000

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.

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.

Will that acceptable? Comment and improvement suggestion are welcome.

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 7:23 AM
To: Lucy yong; Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron Parker; [email-masked]
Subject: RE: [sfc] metadata type 1 constraint

Hi Lucy, 

   OLD:

   NEW:

Cheers,
Med

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Oct 2016 11:29:20 -0500

Hi Lucy,

Regarding semantics of metadata 1 and 2, that type of information
should be defined separately in the documents defining any new
metadata type 1 or 2 and standardized, as we discussed during the
interim.

The nsh doc, only defines the syntax that should be used in defining
so-called MD1 MD2.
Specific metadata will be defined in other documents. The semantics
refers to what is to be defined in those documents.

I just don't understand what is the point with these modifications you
are proposing?

Behcet

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Oct 2016 16:41:00 +0000

Hi Behcet,

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, October 20, 2016 11:29 AM
To: Lucy yong
Cc: [email-masked]; Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron Parker; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Hi Lucy,

Regarding semantics of metadata 1 and 2, that type of information should be defined separately in the documents defining any new metadata type 1 or 2 and standardized, as we discussed during the interim.
[Lucy] The key difference between two is that whatever information will be defined for MD-1, it will not be carried in the NSH header. This is what WG agreed and documented. MD-2 is not.

The nsh doc, only defines the syntax that should be used in defining so-called MD1 MD2.
Specific metadata will be defined in other documents. The semantics refers to what is to be defined in those documents.
[Lucy] The text we proposed is for MD1. I think we will need some text for MD2 as well. But let's agree on the text for MD1 first.

I just don't understand what is the point with these modifications you are proposing?
[Lucy] It puts some requirements for SFC-aware SF implementation and control plane solutions, which is important for the interworking. 

Lucy

Behcet

On Thu, Oct 20, 2016 at 10:44 AM, Lucy yong <[email-masked]> wrote:
>> 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 
>> MD#2. Is the variable length the only feature that hardware can't 
>> deal with?
>> >
>> >     Lucy
>> >
>> the interpretation locally on a per SFP basis;  also being explicit 
>> on the wire will likely enhance interoperability and debuggability.
>> >
>> or byte within the 32 bytes (probably the first nibble or byte) is 
>> yet another.
>> >
>> >        Ron
>> >
>> >
>> >     >> of TLVs and each TLV has a type and specified semantics 
>> > along
>> (the

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Oct 2016 15:17:19 -0500

On Thu, Oct 20, 2016 at 11:41 AM, Lucy yong <[email-masked]> wrote:
> [Lucy] The key difference between two is that whatever information will be defined for MD-1, it will not be carried in the NSH header.

Of course. That's why I am pointing to the document that defines the
metadata not the document that defines the so-called nsh protocol,
i.e.

draft-ietf-sfc-nsh.

Behcet

<span class="sewbz6ae5c8iuox"><br></span>
> This is what WG agreed and documented. MD-2 is not.
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 20 Oct 2016 20:49:32 +0000

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, October 20, 2016 3:17 PM
To: Lucy yong
Cc: [email-masked]; Joel M. Halpern; Van De Velde, Gunter (Nokia - BE); Ron Parker; [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

On Thu, Oct 20, 2016 at 11:41 AM, Lucy yong <[email-masked]> wrote:
> Cc: [email-masked]; Joel M. Halpern; Van De Velde, 
> Gunter (Nokia - BE); Ron Parker; [email-masked]

Of course. That's why I am pointing to the document that defines the metadata not the document that defines the so-called nsh protocol, i.e.

draft-ietf-sfc-nsh.
[Lucy] We are across each other here. Will the document you are pointing define one structure or multiple for MD-1? The interim meeting, people stated that there are many SFC applications that will use metadata to pass different contents. Therefore, MD-1 is designed to allow defining different data structure on the mandatory context headers (i.e. 16 bytes). As a result, each SFC can have their own metadata semantics for the MD#1 context headers. When an SF receives an SFC packet, NSH header does not tell what data structure is used in the context headers, to get or insert a data to the context header correctly, the SF has to get the information about that semantics for the context headers first.   

If we can have only one semantics for MD-1 to support all SFC applications, we do not need to design this way. Just specify one semantics and standardize it. All SFs will know the semantics on the context headers (because there is only one), which will be no interworking issue.

Hope this explanation helps. 

Lucy

Behcet

>>> Envoyé
>>> [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
>>>
>>> imo and live with the consequences…and in that case use MD Type-2 
>>> for these types of well known metadata transport mechanisms.
>>> >
>>> >     [Lucy] True. However, for this document, readers expect 
>>> > Section
>>> > 3 to
>>> 3.4 and 3.5 just specify the syntax, from documenting perspective, 
>>> it is important to explicitly state the two text out.
>>> >
>>> implement, which causes people's concern. IMO, if we don't have a 
>>> way to address this challenge here (you stated in interim meeting), 
>>> >     > Section 3.5 should mention that this section only defines 
>>> > MEF type
>>> 2
>>> >     > Behalf Of Joel M. Halpern Sent: Sunday, October 16, 2016 
>>> > 8:39 PM
>>> To:

---

From: <[email-masked]>
Date: Fri, 21 Oct 2016 06:33:09 +0000

Hi Lucy, 

Please see inline.

Cheers,
Med

> De : Lucy yong [mailto:[email-masked]]
> Envoyé : jeudi 20 octobre 2016 17:44
> À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Van De Velde, Gunter
> (Nokia - BE); Ron Parker; [email-masked]
> Objet : RE: [sfc] metadata type 1 constraint
> 
> 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:
> 
> 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.  
(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:

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" 
(4) Please change "SF" to "SFC-aware SF"  

> 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.

> > corresponding data extraction scheme to individual SFs in the SFC that
> are required to use data placed in the MD#1 field. Note:
> > >     >> NSH just specifies MD type1 with a 16 bytes field, and  NSH
> doc.
> > >     >> states
> > >     >>

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Fri, 21 Oct 2016 12:33:39 +0000

The good news is that draft draft-quinn-sfc-nsh-tlv-02.txt now has a fix suggesting context allocation scheme encoding:

https://tools.ietf.org/rfcdiff?
  url1=https://tools.ietf.org/id/draft-quinn-sfc-nsh-tlv-01.txt
  &url2=https://tools.ietf.org/id/draft-quinn-sfc-nsh-tlv-02.txt

However, if the intent is that MD#1 is Opaque, then why even try to suggest encodings for it? Opaque info is opaque info… either you define it, or you do not define it… anything else is confusing and contradicting from operational and implementation perspective.

I would prefer to see that both “Data Center Allocation” and “Mobility/Broadband Allocation” drafts are written with intended main usage in a MD#2, instead of MD#1 as then it is a complete and interoperable allocation scheme usage with significantly reduced operational overhead and restrictions. Assuming the length of these allocation blobs fixed at 16 octets for potentially stuffing them in a MD#1 sounds fine. 

G/

On 19/10/2016, 17:22, "sfc on behalf of Van De Velde, Gunter (Nokia - BE)" <[email-masked] on behalf of [email-masked]> wrote:

    G/

    
    
        Joel,

        Paul

---

From: "Vigoureux, Martin (Nokia - FR)" <[email-masked]>
Date: Fri, 21 Oct 2016 12:56:17 +0000

>From the latest discussion I wonder if the allocation drafts shouldn't in fact define their own MD type (3, 4, ...).

If there is a need/use for that, a TLV for framing these MDs in MD2 could be defined, as sfc-nsh-tlv now does.

I'd in any case prefer to avoid duplicating specifications across documents, and as such sfc-nsh-tlv should only reference the encodings, not replicate them.

-m

-------- Message d'origine --------
De : "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date :21/10/2016 14:36 (GMT+01:00)
À : "Paul Quinn (paulq)" <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Cc : [email-masked]
Objet : Re: [sfc] metadata type 1 constraint

G/

    G/

        Joel,

        Paul

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Oct 2016 16:02:05 +0000

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:
> 
> 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: 

NEW:

(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.
> 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.

[Lucy] Great!

Thanks,
Lucy

> > think of what to add to address the interworking concern. Will above 
> > text
> help?
> >
> > Regards,
> > Lucy
> >
> >
> >
> > Yours,
> > Joel
> >
> > significantly impact SF implementation. The reason having MD type 1 
> > is
> that is hardware friendly.
> > >     > the SFC arch. as a result of NSH design's, but the 
> > > architecture
> is
> > >     > already published. Maybe control plane requirement is the 
> > > place
> to
> > >     >> the shared metadata is communicated via a control plane, 
> > > which
> is
> > >     >>
> > >     >> metadata semantics.  This is because that NSH does not 
> > > convey
> SFC

---

From: Lucy yong <[email-masked]>
Date: Fri, 21 Oct 2016 22:48:56 +0000

If we intend to standardize metadata structure per an SFC application, I wonder why NSH needs MD#1? MD#2 can support all SFC needs. MD#2 even support expert review metadata class, experimental metadata class as well. Should consider removing MD#1?

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Vigoureux, Martin (Nokia - FR)
Sent: Friday, October 21, 2016 7:56 AM
To: Van De Velde, Gunter (Nokia - BE); Paul Quinn (paulq); Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

-m

-------- Message d'origine --------
De : "Van De Velde, Gunter (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>
Date :21/10/2016 14:36 (GMT+01:00)
À : "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] metadata type 1 constraint
The good news is that draft draft-quinn-sfc-nsh-tlv-02.txt now has a fix suggesting context allocation scheme encoding:

However, if the intent is that MD#1 is Opaque, then why even try to suggest encodings for it? Opaque info is opaque info... either you define it, or you do not define it... anything else is confusing and contradicting from operational and implementation perspective.

I would prefer to see that both "Data Center Allocation" and "Mobility/Broadband Allocation" drafts are written with intended main usage in a MD#2, instead of MD#1 as then it is a complete and interoperable allocation scheme usage with significantly reduced operational overhead and restrictions. Assuming the length of these allocation blobs fixed at 16 octets for potentially stuffing them in a MD#1 sounds fine.

G/

On 19/10/2016, 17:22, "sfc on behalf of Van De Velde, Gunter (Nokia - BE)" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

    G/

    On 19/10/2016, 15:33, "sfc on behalf of Paul Quinn (paulq)" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

        Joel,

        Paul

        > On Oct 18, 2016, at 8:14 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> 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.
        >>
        >> 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" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:
        >>
        >>    To: Lucy yong; Joel M. Halpern; [email-masked]<mailto:[email-masked]>
        >>    To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
        >>    > Lucy yong; [email-masked]<mailto:[email-masked]> Subject: Re: [sfc] metadata type 1 constraint
        >>    >
        >>    >> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
        >>    >>
        >>    >
        >>    > [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
        >>    >
        >>

---

From: <[email-masked]>
Date: Mon, 24 Oct 2016 05:39:59 +0000

Hi Lucy, 

I'm fine with the proposed text. 

Thank you.

Cheers,
Med

> Envoyé : vendredi 21 octobre 2016 18:02
> [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:
> 
> (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.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 24 Oct 2016 21:22:39 +0000

Hi Lucy,

The value of a fixed size header as a MUST is significant from many perspectives, including but not limited to:

Implementations, including software implementations, benefit form the predictability of a fixed size header. One only needs to look at the lack of widely deployed variable length data plane protocols to see this in practice.

From an operational perspective, having a bounded (small) number of metadata to work with helps to bound the policy expression, which after all is the main use of the metadata.

There are existing implementations that demonstrate the applicability of MD Type 1 to a wide-range of use cases, and those implementation reap the benefits of the two aforementioned points.

Paul

On Oct 21, 2016, at 6:48 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

Lucy

Cc: [email-masked]<mailto:[email-masked]>

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: Dave Dolson <[email-masked]>
Date: Mon, 24 Oct 2016 22:20:26 +0000

Paul,
IPv4 has a variable-length header, and I would call it widely deployed.

The greatest issue, in my opinion, is agreeing on metadata allocation. In my experience the packet syntax is the easy part of any protocol stack, and semantics the hard part.

As Lucy indicates, there seems to be a clearer way forward to interop with the ‎TLVs of MD2.

‎Without some standard MD1 allocation, MD1 is not a useful standard.
Multiple choices of allocations is not useful.

-Dave

From: Paul Quinn (paulq)
Sent: Monday, October 24, 2016 5:22 PM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 24 Oct 2016 22:41:37 +0000

On Oct 24, 2016, at 3:20 PM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Paul,

Dave, on the contrary, IPv4 options -- i.e. the variable portion of IPv4 -- are almost never used due to the the cost of this support.

Further, simply saying: "support TLV" obscures what support means: how many, what orders, etc.  All this ambiguity, or if you prefer, flexibility, furthers the cost of TLV data plane deployments.

---

From: Lucy yong <[email-masked]>
Date: Tue, 25 Oct 2016 01:04:23 +0000

Paul,

If NSH has to support MD-1 with 16-bytes datablock,  please consider adding the additional text we proposed, which addresses interworking concern.

I think that for the MD-2, it also needs to add some rules about when a SFC-aware SF is configured to use metadata and receives MD-2, if it does not understand the MD class and/or type, it MUST NOT process the packet, et al.

Lucy

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Monday, October 24, 2016 4:23 PM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [sfc] metadata type 1 constraint

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Tue, 25 Oct 2016 07:52:47 +0000

I agree with Lucy and Dave regarding the futile usefulness of MD#1.

The value of a fixed and predictable MD size is clear, however the lack of signalling to indicate in stateless manner the used NSH MD#1 allocation scheme makes this type of NSH header only marginally useable when interoperability of Service function behaviour is required or when a single SF needs to service packets of different NSH MD#1 allocation scheme’s.

The text proposed for adding to MD#1 is not fixing this, however it is making it more clear to the user that MD#1 is from interoperability perspective rather dubious and adds significant operational complexity.

If the intent is to make MD#1 more valuable and if we desire to bank upon the benefits of a fixed size 16 octets context field, then maybe a compromise needs to be made, and some effort be explored to add into the NSH MD#1 a context allocation scheme indication? Or, we create MD#3, MD#4, etc each having a fixed 16-octet size and a formally documented and standardized allocation scheme.

G/

From: sfc <[email-masked]> on behalf of Lucy yong <[email-masked]>
Date: Tuesday, 25 October 2016 at 03:04
To: "Paul Quinn (paulq)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] metadata type 1 constraint

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: Ron Parker <[email-masked]>
Date: Tue, 25 Oct 2016 13:02:57 +0000

Well said, Gunter.   This has been the elephant in the room from the beginning of the SFC WG.    Some might recall that we offered a competitive draft to NSH called SCH and the resulting compromise was to create MD-1 from the original NSH and MD-2 taken from SCH.

Regarding the benefits to hardware, as a former hardware developer I do have a view on this.   The primary ease in hardware is when a length field appears in a known offset so that the uninteresting aspects of the header can be easily skipped past (note that IPv6 does not have this and still appears to be supportable in hardware with some number of additional gates and memory accesses).   However, stating that said length field has only 1 allowable value, as is the case with MD-1 (and it has been pointed out is superfluous information) does not provide significant incremental ease for the hardware.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE)
Sent: Tuesday, October 25, 2016 3:53 AM
To: Lucy yong <[email-masked]>; Paul Quinn (paulq) <[email-masked]>
Cc: [email-masked]
Subject: [GRAYMAIL] Re: [sfc] metadata type 1 constraint

G/

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 25 October 2016 at 03:04
To: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] metadata type 1 constraint

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 25 Oct 2016 14:37:56 +0000

Gunter,

There's clearly a trade off and a set of pros and cons for having a header being self-describing versus non-self-describing. Similarly, there's a balance in where we place state.

However, you are making some bold statements below, and I'd like to understand some more. I'm not pushing a position, I just seem to be missing something from your argument.

Saying that a non-self-describing packet / non stateless SF hurts interoperability to the point of uselessness, is attaching that description to MPLS Labels or L2TPv3 encapsulation. Those don't have explicit indications.

You are advocating for an indication of allocation type in the packet. That's not unreasonable in itself, it is a sensible question.

But that is not "stateless" as you call it, because the SF still holds state indexed by SPI, and in any case would need to hold state on what each allocation type means, which implicitly happens without an allocation type. Both need state, both need a control plane to work.

In other words, it seems to me that both (with or without an allocation type) have the *exact* same interoperability requirements and characteristics. The details are different of course, but below seems like FUD.

So, without pushing for any particular method, I'd really would like to understand your technical rational in more details.

You say "marginally useable when interoperability", "dubious usefulness and adds significant operational complexity", and "a formally standardized allocation scheme". The latter should exist in both cases (whether you put it in the packet or not). And while I understand your preference of an explicit allocation type, I still do not understand why.

How exactly the current approach with interoperable running code hurts interoperability?

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 25, 2016, at 00:55, Van De Velde, Gunter (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: Sumandra Majee <[email-masked]>
Date: Tue, 25 Oct 2016 20:17:34 +0000

Reading thru all these interesting discussion, I think there is a rough agreement that semantics of context hdr should be known to rcving entity. The disagreement is around how part,

a)       One suggestion I had seen (not mine) to use SPI which means an external controller must be setting this up a priori. It also assumes that the semantics of the context hdr doesn’t change for a given flow, which is perhaps true for majority of the case but it may not be true for proxy devices.

b)       The other suggestion is that if we treat MD1 context hdr as yet another TLV, where Length is fixed. It is not signaling but it is about providing schema ID for the rcving entity. It doesn’t require a control plane to populate these schemas.

I do think there is a value in having way to attach schema ID/annotation in the NSH hdr.  However, I think the subtypes should be a few, there is MD-2 type if anybody wants to go wild. How about reserving 2-3 bits in the beginning of context hdr for type?

From: sfc <[email-masked]> on behalf of "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Tuesday, October 25, 2016 at 12:52 AM
To: Lucy yong <[email-masked]>, "Paul Quinn (paulq)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] metadata type 1 constraint

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 25 Oct 2016 20:38:03 +0000

Dear SFC WG:

[Chair hat on] ..

While this discussion has been interesting, a protracted debate on a problem for which a workable control plane solution exists is unfortunate.

As a WG we need to make progress with the SFC encapsulation. I would make the following observations:

  *   The NSH document has already completed WG LC and is waiting for chair approval to submit to IESG for publication.
  *   There is no way to call consensus for a specific change as there are so many alternatives on the table.

I would like to give this discussion the rest of the week to reach a single proposal that has enough WG agreement so that the chairs may reasonably ask for WG consensus or disagreement. In the absence of WG agreement to a change then we will proceed with the known workable solution and forward the NSH document to the IESG for publication.

Thanks!

Jim

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 25, 2016 at 10:37 AM
To: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>
Cc: Paul Quinn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] metadata type 1 constraint

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 26 Oct 2016 09:24:24 +0000

From the below I understand that during IETF97 the topic will be placed on the agenda as Linda suggested, correct?

G/

From: sfc <[email-masked]> on behalf of "Jim Guichard (jguichar)" <[email-masked]>
Date: Tuesday, 25 October 2016 at 22:38
To: "Carlos Pignataro (cpignata)" <[email-masked]>, "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Cc: "Paul Quinn (paulq)" <[email-masked]>, Lucy yong <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] metadata type 1 constraint

Dear SFC WG:

[Chair hat on] ..

Thanks!

Jim

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: <[email-masked]>
Date: Wed, 26 Oct 2016 09:30:10 +0000

Hi Jim,

Unless I’ mistaken, there are pending issues that are not addressed as part of the last WGLC.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mardi 25 octobre 2016 22:38
À : Carlos Pignataro (cpignata); Van De Velde, Gunter (Nokia - BE)
Cc : Paul Quinn (paulq); Lucy yong; [email-masked]
Objet : Re: [sfc] metadata type 1 constraint

Dear SFC WG:

[Chair hat on] ..

Thanks!

Jim

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Wed, 26 Oct 2016 10:23:22 +0000

Hi Carlos,

Appreciate your perspective.
Interoperability is achieved by creating implementations based upon standard documents, and not based upon informational documents.

There are some aspects in the existing NSH document I agree with:

MD#1:
Fixed length and will carry 16-octets of Opaque Data
As result: The SFC WG should not attempt to define the Opaque structure, as that would make it not Opaque anymore.
It sounds confusing and even a bit schizophrenic from IETF to do such a thing

MD#2:
Has Variable length, carries TLVs and includes standardized context allocation identification.
The existing 16-octet “informational” allocation schemes for Broadband, Mobile and DC fit in here perfectly and the context allocation is carried within the NSH.
Going down the path of defining allocation scheme for broadband, mobile and DC would potentially upgrade these currently “informational” docs to proposed standards, doing better justice to the value these documents.

Conclusion:
For interoperability, should we not aim for allocation schemes based upon full standards instead of ‘informational’ documents?
And defining structure for something that is equally defined as being opaque is asking for misunderstanding and confusion.

G/

From: sfc <[email-masked]> on behalf of "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tuesday, 25 October 2016 at 16:37
To: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Cc: "Paul Quinn (paulq)" <[email-masked]>, "[email-masked]" <[email-masked]>, Lucy yong <[email-masked]>
Subject: Re: [sfc] metadata type 1 constraint

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 11:41:52 +0000

Hi Med,

Yes, you are correct that there are a few open tickets (from the WGLC) that need to be closed before the chairs forward the document to the IESG. However, this particular topic is not one of them and unless a consensus is reached by the WG on any new proposal, no changes will be made.

Jim

Sent from my iPhone

On Oct 26, 2016, at 5:30 AM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jim,

Cheers,
Med

Cc : Paul Quinn (paulq); Lucy yong; [email-masked]<mailto:[email-masked]>

Dear SFC WG:

[Chair hat on] ..

Thanks!

Jim

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 11:43:58 +0000

Hi Gunter,

That is incorrect. The WG agreed upon the currently documented solution and unless a consensus call is made to change it the document will move forward as is.

Jim

Sent from my iPhone

G/

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 25 October 2016 at 22:38
To: "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "Van De Velde, Gunter (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] metadata type 1 constraint

Dear SFC WG:

[Chair hat on] ..

Thanks!

Jim

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 26 Oct 2016 12:37:51 +0000

Hi Lucy,

[Chair hat off] .. One comment.

>[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 co…
Jim> the “MANDATORY Context Header” means that it is MANDATORY to carry them in a type-1 NSH packet but it does not mean that they will be populated with any data, nor does it imply any particular allocation schema; hence it seems incorrect to “MUST NOT process” the packet. I would suggest that it is important for the SF to log an error but I would argue that it should continue forwarding the packet down the service chain.

Jim

---

From: <[email-masked]>
Date: Wed, 26 Oct 2016 13:02:01 +0000

Jim, 

The sentence starts with "if an SFC-aware SF is configured to use metadata..": if an SF is configured so, this means that the consumption of the data included in the "Mandatory Context Header" is required for proper SFC operation. "MUST NOT + LOG" is an incentive to fix the configuration problem and supply the missing semantic. 

BTW, ignoring the metadata + process the packet in such case does not mean that the service will be delivered. The SFC will be broken somehow (because a data required for SF consumption is missing), but the operator may not have hints why the SFC outcome does not match the SFC expected objective.

Cheers,
Med

> De : Jim Guichard (jguichar) [mailto:[email-masked]]
> Envoyé : mercredi 26 octobre 2016 14:38
> À : Lucy yong; BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Van De Velde,
> On 10/21/16, 12:02 PM, "sfc on behalf of Lucy yong" <[email-masked]
> Jim> the “MANDATORY Context Header” means that it is MANDATORY to carry
> them in a type-1 NSH packet but it does not mean that they will be
> populated with any data, nor does it imply any particular allocation
> schema; hence it seems incorrect to “MUST NOT process” the packet. I would
> suggest that it is important for the SF to log an error but I would argue
> that it should continue forwarding the packet down the service chain.
> 
> Jim

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 26 Oct 2016 16:52:01 +0000

Thanks for the clarification, Gunter!

— Carlos

On Oct 26, 2016, at 3:23 AM, Van De Velde, Gunter (Nokia - BE) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

MD#1:

MD#2:

Conclusion:

G/

Cc: "Paul Quinn (paulq)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lucy yong <[email-masked]<mailto:[email-masked]>>

Gunter,

G/

Paul,

Lucy

Hi Lucy,

Paul

Lucy

-m

-------- Message d'origine --------

G/

    G/

        Joel,

        Paul