Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 8 Nov 2016 18:01:23 +0000

Dear SFC WG:

After much discussion on the list with regard to ticket #21 the following text has been proposed to help clarify metadata semantics and so forth. Please review and indicate support (or not) so that the chairs can determine consensus and update the ticket accordingly.

Thank you!

Jim & Joel

##########

NEW for section 3.4:
This specification does not make any assumption about the content placed in the mandatory context field of the NSH header, and does not describe the structure or meaning of the included metadata.

An SFC-aware SF MUST receive the data semantics first in order to process the data placed in the mandatory context field.  The data semantics include both the allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of this specification.

Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured for mandatory use of metadata but has not yet received the data semantics for the mandatory context field, it MUST NOT process the packet and MUST log this error.

[dcalloc] and [broadalloc] provide sample examples to associate a meaning with the data conveyed in the mandatory context field.

NEW for end of section 3.5.1:
This specification does not make any assumption about TLVs that are mandatory-to-implement or those that are mandatory-to-process.  These considerations are deployment-specific.  However, the control plane can instruct SFC-aware SFs with the data structure of TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).

Upon receipt of a packet that belong to a given SFP, if a mandatory-to-process TLV is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log this error.

If multiple mandatory-to-process TLVs are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these TLVs.  If no instructions are provided, the SFC-aware SF MUST process these TLVs in the order they appear in the NSH packet.

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log this error.

---

From: Ron Parker <[email-masked]>
Date: Tue, 8 Nov 2016 18:16:38 +0000

Hi Jim.

I support the text.

One editorial nit – “Upon receipt of a packet that belong” --> “Upon receipt of a packet that belongs”.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, November 8, 2016 1:01 PM
To: [email-masked]
Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

If multiple mandatory-to-process TLVs are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these TLVs.  If no instructions are provided, the SFC-aware SF MUST process these TLVs in the order they
appear in the NSH packet.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 8 Nov 2016 18:44:49 +0000

Seems reasonable to me.

Paul

On Nov 8, 2016, at 1:01 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log this error.
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Tue, 8 Nov 2016 19:05:20 +0000

In several places, the text says, “… and MUST log this error.”

(a)    Must log what exactly?

(b)   I don’t think it is good practice to log something for every packet received. What is required is not logging, rather counting.

(c)    Better to make this “… and SHOULD provide diagnostics.” ?

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, November 08, 2016 1:01 PM
To: [email-masked]
Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 8 Nov 2016 21:59:37 -0000

Dave is right.
 
"MUST log" would be a DoS vector.
 
Adrian
 
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: 08 November 2016 19:05
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

 
 
Dear SFC WG:

Thank you!
 
Jim & Joel
 
##########
 
NEW for section 3.4:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Nov 2016 00:43:28 -0500

I think I understand your point.
At the same time, without a log entry it will be next to impossible to 
determine what arriving value caused the drop.  In this context, that 
ability seems important, but I could be missing something.

Yours,
Joel

On 11/8/16 2:05 PM, Dave Dolson wrote:
> (b)   I don’t think it is good practice to log something for every
> packet received. What is required is not logging, rather counting.
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* Tuesday, November 08, 2016 1:01 PM
> *To:* [email-masked]
> *Subject:* [sfc] https://trac.ietf.org/trac/sfc/ticket/21
>
>
>
> Dear SFC WG:
>
>
>
> After much discussion on the list with regard to ticket #21 the
> following text has been proposed to help clarify metadata semantics and
> so forth. Please review and indicate support (or not) so that the chairs
> can determine consensus and update the ticket accordingly.
>
>
>
> Thank you!
>
>
>
> Jim & Joel
>
>
>
> ##########
>
>
>
> *NEW for section 3.4*:
>
> This specification does not make any assumption about the content placed
> in the mandatory context field of the NSH header, and does not describe
> the structure or meaning of the included metadata.
>
>
>
> An SFC-aware SF MUST receive the data semantics first in order to
> process the data placed in the mandatory context field.  The data
> semantics include both the allocation schema and the meaning of the
> included data. How an SFC-aware SF gets the data semantics is outside
> the scope of this specification.
>
>
>
> Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is
> configured for mandatory use of metadata but has not yet received the
> data semantics for the mandatory context field, it MUST NOT process the
> packet and MUST log this error.
>
>
>
> [dcalloc] and [broadalloc] provide sample examples to associate a
> meaning with the data conveyed in the mandatory context field.
>
>
>
> *NEW for end of section 3.5.1*:
>
> This specification does not make any assumption about TLVs that are
> mandatory-to-implement or those that are mandatory-to-process.  These
> considerations are deployment-specific.  However, the control plane can
> instruct SFC-aware SFs with the data structure of TLVs together with
> their scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).
>
>
>
> Upon receipt of a packet that belong to a given SFP, if a
> mandatory-to-process TLV is missing in that packet, the SFC-aware SF
> MUST NOT process the packet and MUST log this error.
>
>
>
> If multiple mandatory-to-process TLVs are required for a given SFP, the
> control plane MAY instruct the SFC-aware SF with the order to consume
> these TLVs.  If no instructions are provided, the SFC-aware SF MUST
> process these TLVs in the order they
>
> If multiple instances of the same TLV are included in an NSH packet, but
> the definition of that TLV does not allow for it, the SFC-aware SF MUST
> NOT process the packet and MUST log this error.
>
>
>
> [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Nov 2016 06:12:41 +0000

Hi Jim, all,

I support this change.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mardi 8 novembre 2016 19:01
À : [email-masked]
Objet : [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 9 Nov 2016 08:21:27 -0000

I think the usual formulation is "SHOULD log and MUST apply rate limiting to any
logging"

A

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 09 November 2016 05:43
> To: Dave Dolson; Jim Guichard (jguichar); [email-masked]
> > In several places, the text says, ". and MUST log this error."
> >
> > (b)   I don't think it is good practice to log something for every
> > (c)    Better to make this ". and SHOULD provide diagnostics." ?
> >
> >
> >
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Wed, 9 Nov 2016 12:02:34 +0000

Hi Adrian, all,

I do prefer the "MUST log .." wording because it is critical to detect when a mandatory piece is missing to deliver the service.

The proposed text is about SFC-aware SFs. If the attack vector is a DoS, it is likely that the border nodes/classifiers will be the first victims. Implementing measures to protect against DoS at the boundaries would be a first guard. 

If the DoS is from within the SFC domain, despite this is a valid threat vector and misbehaving nodes may happen (software bugs, etc.), I thought the security model of NSH assumes that all involved nodes are trusted. 

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : mercredi 9 novembre 2016 09:21
> À : 'Joel M. Halpern'; 'Dave Dolson'; 'Jim Guichard (jguichar)';
> [email-masked]
> Objet : Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Nov 2016 14:38:47 +0000

Some have interpreted MUST log as on a per-packet basis.   I interpreted it more loosely.   Perhaps we could say "MUST log in an appropriate manner..."

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, November 9, 2016 7:03 AM
To: [email-masked]; 'Joel M. Halpern' <[email-masked]>; 'Dave Dolson' <[email-masked]>; 'Jim Guichard (jguichar)' <[email-masked]>; [email-masked]
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Hi Adrian, all,

Cheers,
Med

> Envoyé : mercredi 9 novembre 2016 09:21 À : 'Joel M. Halpern'; 'Dave 
> Dolson'; 'Jim Guichard (jguichar)'; [email-masked] Objet : Re: [sfc] 
> https://trac.ietf.org/trac/sfc/ticket/21
> 
> I think the usual formulation is "SHOULD log and MUST apply rate 
> limiting to any logging"
> 
> A
> 
> > At the same time, without a log entry it will be next to impossible 
> > to determine what arriving value caused the drop.  In this context, 
> > that ability seems important, but I could be missing something.
> >
> > Yours,
> > Joel
> >
> > > following text has been proposed to help clarify metadata 
> > > semantics
> and
> > > semantics include both the allocation schema and the meaning of 
> > > the included data. How an SFC-aware SF gets the data semantics is 
> > > outside the scope of this specification.
> > >
> > >
> > >
> > > configured for mandatory use of metadata but has not yet received 
> > > the data semantics for the mandatory context field, it MUST NOT 
> > > process
> the
> > > This specification does not make any assumption about TLVs that 
> > > are mandatory-to-implement or those that are mandatory-to-process.  
> > > These considerations are deployment-specific.  However, the 
> > > control plane
> can
> > > instruct SFC-aware SFs with the data structure of TLVs together 
> > > with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).
> > >
> > >
> > >
> > > mandatory-to-process TLV is missing in that packet, the SFC-aware 
> > > SF MUST NOT process the packet and MUST log this error.
> > >
> > >
> > >
> > > If multiple mandatory-to-process TLVs are required for a given 
> > > SFP,
> the
> > > control plane MAY instruct the SFC-aware SF with the order to 
> > > consume these TLVs.  If no instructions are provided, the 
> > > SFC-aware SF MUST process these TLVs in the order they
> > >
> > > If multiple instances of the same TLV are included in an NSH 
> > > packet,
> but

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Nov 2016 10:03:32 -0500

That works for me.
Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Wed, 9 Nov 2016 19:03:55 +0000

I support following text for the sections and agree that some minor tweak is necessary to make it more clear.

Thanks,
Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, November 08, 2016 12:01 PM
To: [email-masked]
Subject: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

---

From: [email-masked]
Date: Thu, 10 Nov 2016 10:45:28 +0800

Dear Jim & Joel,

   The text said: 'the data semantics include both the allocation schema 
and the meaning of the included data.' 
   I agree with 'the allocation schema' can help the SFC-aware SF to know 
how to interpret the mandatory context field. However,
   Could you clarify what is 'the meaning of the included data' and how to 
describe' the meaning of the included data'? 

   Thanks very much :)

BRs
Linda Wang

"Jim Guichard (jguichar)" <[email-masked]> 
发件人:  "sfc" <[email-masked]>
2016/11/09 02:01

收件人
"[email-masked]" <[email-masked]>, 
抄送

主题
[sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear SFC WG:

After much discussion on the list with regard to ticket #21 the following 
text has been proposed to help clarify metadata semantics and so forth. 
Please review and indicate support (or not) so that the chairs can 
determine consensus and update the ticket accordingly. 

Thank you!

Jim & Joel

##########

NEW for section 3.4:

An SFC-aware SF MUST receive the data semantics first in order to process 
the data placed in the mandatory context field.  The data semantics 
include both the allocation schema and the meaning of the included data. 
How an SFC-aware SF gets the data semantics is outside the scope of this 
specification.

Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured 
for mandatory use of metadata but has not yet received the data semantics 
for the mandatory context field, it MUST NOT process the packet and MUST 
log this error.

[dcalloc] and [broadalloc] provide sample examples to associate a meaning 
with the data conveyed in the mandatory context field.

NEW for end of section 3.5.1:
This specification does not make any assumption about TLVs that are 
mandatory-to-implement or those that are mandatory-to-process.  These 
considerations are deployment-specific.  However, the control plane can 
instruct SFC-aware SFs with the data structure of TLVs together with their 
scoping (See Section 3.3.3 of [I-D.ietf-sfc-control-plane]).

Upon receipt of a packet that belong to a given SFP, if a 
mandatory-to-process TLV is missing in that packet, the SFC-aware SF MUST 
NOT process the packet and MUST log this error.

If multiple mandatory-to-process TLVs are required for a given SFP, the 
control plane MAY instruct the SFC-aware SF with the order to consume 
these TLVs.  If no instructions are provided, the SFC-aware SF MUST 
process these TLVs in the order they appear in the NSH packet.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 10 Nov 2016 13:15:32 +0000

Hi Linda,

By this we mean how the SF is to interpret the data carried within the metadata. For example, the allocation schema might say “tenant-id carried at offset <blah>…” but then the SF needs to understand what the extracted value from the metadata corresponds to in terms of which tenant e.g. value 101 might mean “coke”. “coke” in this example is not carried within the metadata so the SF needs to map the value from the metadata to a meaningful tenant identification.

Hope this clarifies ..

Jim

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 9, 2016 at 9:45 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, sfc <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Dear Jim & Joel,

   The text said: 'the data semantics include both the allocation schema and the meaning of the included data.'
   I agree with 'the allocation schema' can help the SFC-aware SF to know how to interpret the mandatory context field. However,
   Could you clarify what is 'the meaning of the included data' and how to describe' the meaning of the included data'?

   Thanks very much :)

BRs
Linda Wang

"Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
发件人:  "sfc" <[email-masked]<mailto:[email-masked]>>

2016/11/09 02:01

收件人
        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
抄送

主题

Dear SFC WG:

Thank you!

Jim & Joel

##########

NEW for section 3.4:

If multiple instances of the same TLV are included in an NSH packet, but the definition of that TLV does not allow for it, the SFC-aware SF MUST NOT process the packet and MUST log this error._______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Nov 2016 10:42:56 -0500

(This is the case where even the chairs meant slightly different things, 
so thanks for making sure we are clear.)

Personally, I think that the mapping between value and meaning is going 
to be handled via indirection.  I do not think that the control system 
will ever say that value 101 means "coke".  Rather, I think that the 
control system will provide enough information that the SF can determine 
how to interpret 101.  The difference is that what the SF needs to know 
is not "coke", but rather what data set it can use the given value as a 
key into, and what mechanism (pre-provisioned data set 3, radius, 
diameter, LDAP, ...) it can use to get the information it needs to do 
its job using that key.

While for some SF, being told "use DC allocation" will be sufficient, I 
expect in many cases that what the SF needs to be told is that bytes 7 - 
9 are the index it needs to use as the key for getting the subscribers 
content filtering policy.  So we have to allow both the general and the 
specific representation.

Yours,
Joel

On 11/10/16 8:15 AM, Jim Guichard (jguichar) wrote:
> Hi Linda,
>
> By this we mean how the SF is to interpret the data carried within the
> metadata. For example, the allocation schema might say “tenant-id
> carried at offset <blah>…” but then the SF needs to understand what the
> extracted value from the metadata corresponds to in terms of which
> tenant e.g. value 101 might mean “coke”. “coke” in this example is not
> carried within the metadata so the SF needs to map the value from the
> metadata to a meaningful tenant identification.
>
> Hope this clarifies ..
>
> Jim
>
> From: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> To: Jim Guichard <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, sfc <[email-masked]
> <mailto:[email-masked]>>
>    I agree with 'the allocation schema' can help the SFC-aware SF to
> know how to interpret the mandatory context field. However,
>    Could you clarify what is 'the meaning of the included data' and how
> to describe' the meaning of the included data'?
>
>    Thanks very much :)
>
> BRs
> Linda Wang
>
>
>
>
>
>
> *"Jim Guichard (jguichar)" <[email-masked] <mailto:[email-masked]>>*
> 发件人:  "sfc" <[email-masked] <mailto:[email-masked]>>
>
> 2016/11/09 02:01
>
> 	
> 收件人
> 	"[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
> 抄送
> 	
> 主题
> NOT process the packet and MUST log this
> error._______________________________________________
> sfc mailing list
> [email-masked] <mailto:[email-masked]>

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Nov 2016 17:10:30 +0000

"While for some SF, being told "use DC allocation" will be sufficient, I expect in many cases that what the SF needs to be told is that bytes 7 -
9 are the index it needs to use as the key for getting the subscribers content filtering policy.  So we have to allow both the general and the specific representation."

Agree.
Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, November 10, 2016 9:43 AM
To: Jim Guichard (jguichar); [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

(This is the case where even the chairs meant slightly different things, so thanks for making sure we are clear.)

Personally, I think that the mapping between value and meaning is going to be handled via indirection.  I do not think that the control system will ever say that value 101 means "coke".  Rather, I think that the control system will provide enough information that the SF can determine how to interpret 101.  The difference is that what the SF needs to know is not "coke", but rather what data set it can use the given value as a key into, and what mechanism (pre-provisioned data set 3, radius, diameter, LDAP, ...) it can use to get the information it needs to do its job using that key.

While for some SF, being told "use DC allocation" will be sufficient, I expect in many cases that what the SF needs to be told is that bytes 7 -
9 are the index it needs to use as the key for getting the subscribers content filtering policy.  So we have to allow both the general and the specific representation.

Yours,
Joel

On 11/10/16 8:15 AM, Jim Guichard (jguichar) wrote:
> carried at offset <blah>…” but then the SF needs to understand what 
> the extracted value from the metadata corresponds to in terms of which 
>    The text said: 'the data semantics include both the allocation 
> schema and the meaning of the included data.'
>    Could you clarify what is 'the meaning of the included data' and 
> how to describe' the meaning of the included data'?
>
>    Thanks very much :)
>
> BRs
> Linda Wang
>
>
>
>
>
>
> following text has been proposed to help clarify metadata semantics 
> and so forth. Please review and indicate support (or not) so that the 
> chairs can determine consensus and update the ticket accordingly.
>
> Thank you!
>
> Jim & Joel
>
> ##########
>
> *NEW for section 3.4*:
> This specification does not make any assumption about the content 
> placed in the mandatory context field of the NSH header, and does not 
> describe the structure or meaning of the included metadata.
>
> data semantics for the mandatory context field, it MUST NOT process 
> the packet and MUST log this error.
>
> considerations are deployment-specific.  However, the control plane 
> can instruct SFC-aware SFs with the data structure of TLVs together 
> If multiple mandatory-to-process TLVs are required for a given SFP, 
> the control plane MAY instruct the SFC-aware SF with the order to 
> consume these TLVs.  If no instructions are provided, the SFC-aware SF 
> MUST process these TLVs in the order they appear in the NSH packet.
>
> If multiple instances of the same TLV are included in an NSH packet, 
> but the definition of that TLV does not allow for it, the SFC-aware SF 
> MUST NOT process the packet and MUST log this

---

From: [email-masked]
Date: Fri, 11 Nov 2016 17:23:59 +0800

Dear Joel & Jim,

  Thanks for your clarification.
  Yes, you are right. i missed some other cases. All these cases are 
side-by-side. 
So both the general and the specific representation should be allowed.

   However, as there are slightly different understanding about 'the 
meaning of the included data',
are there any possible to clarify it in the proposed text?

BRs,
Linda Wang

"Joel M. Halpern" <[email-masked]> 
发件人:  "sfc" <[email-masked]>
2016/11/10 23:42

收件人
"Jim Guichard (jguichar)" <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
Re: [sfc] https://trac.ietf.org/trac/sfc/ticket/21

Yours,
Joel

the