Subject: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

From: Martin Stiemerling <[email-masked]>
Date: Wed, 27 Apr 2016 06:29:04 +0200

Dear all,

This is the start of the Working Group Last Call (WGLC) for

draft-ietf-sfc-control-plane-04.txt

The WGLC lasts for 2 weeks and will end May 11th at 10 pm PDT.

Please send your comments and reviews to the [email-masked] list.

Regards,

   Martin (SFC co-chair)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 27 Apr 2016 07:45:24 -0400

Martin,

As a contributor, I support publication of this draft.

Thanks,
Andy

On Wed, Apr 27, 2016 at 12:29 AM, Martin Stiemerling <[email-masked]>
wrote:

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

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 27 Apr 2016 14:17:35 +0000

Hi Martin & WG:

A few comments that I would like to see addressed in the document before it can move forward to the next step.

  *   Section 2.2 SFC Control Plane Bootstrapping.

This section is too wishy washy. It makes the statement "this document assumes the SFC control plane is provided with a set of information that is required for proper SFC operation" but then goes on to list bullets that are likely to be provided or may be provided. It does not actually provide any information on what is required for proper SFC operation. In the list of likely information there is no indication of whether this information must exist in the network prior to bootstrapping the SFC control plane element; this is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actually function although it is reasonable to assume that it can bootstrap without any information (albeit it can't actually do anything). On this point I would argue that several of the may elements are actually required such as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the SFC control plane element, or may be added later through some control interface.

Minor point -> typo in bullet point 6 - SFP proxy should read SFC proxy

  *   Section 2.3 Coherent Setup of an SFC-enabled Domain

What does the sentence "various transport encapsulation schemes and/or variations of SFC header implementations may be supported" actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or something else ? Note that there is only one SFC header implementation based on the WG charter so if we are referring to different SFC formats (meaning metadata) then please make this clear in the text, and if not, please remove this sentence.

  *   Section 3.1 Reference Architecture

Second bullet point "mapping between service function chains and SFPs" - this is a general comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs - in fact RSP is mentioned only once in the entire document. The architecture is explicit in that the SFP when rendered into the network is an RSP and therefore the SFC control plane element needs to have information on currently deployed RSPs.

Additionally there is no interface specified for communication between the SFC Control Plane Element and SF management systems. This is an important aspect as many SF's may require that SFC information be communicated to their management systems that will be responsible for communicating directly with their respective SF's.

  *   Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier

The sentence "The control plane may instruct the classifier about the initial values of the Service Index (SI)" should be changed to say MUST as otherwise if a classifier chooses whatever value it wants then that may not align with what is programmed into the SFFs by the SFC Control Plane element.

  *   Section 4.10.4. Encoding the Exact SFF/SF Sequence in Data Packets

This section does not actually provide any meaning or indication of relationship with the SFC Control Plane element. Furthermore,  there has been no WG consensus to carry source routes within the SFC encapsulation. Therefore this entire section should be removed from the document.

  *   Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP

Figure 2 lists 3 different SFP-id's whereas the text mentions only SFP-id #1. Is this simply a typo or are you trying to convey something else ?

Further you state that "the steering policies to a SFF node for service function chain depends on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific" -  this is an inaccurate statement as the combination of the SFP-id and service-index determines the forwarding behavior (as specified in section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

Jim

On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Please send your comments and reviews to the [email-masked]<mailto:[email-masked]> list.

Regards,

   Martin (SFC co-chair)

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Apr 2016 10:42:18 -0400

Jim, I agree with most of your comments below.  However, I think your 
comment regarding RSP is incorrect.  Given the way teh architecture is 
written, the control plane is not required to know the RSP, and in fact 
the architecture and the NSH header allow for implementations in which 
the control plane knows the possible paths, but not the RSP that a given 
flow takes.

As such, regarding RSP I believe the document is correct, and the fact 
that there are almost no reference to RSP is a feature, not a bug.

Yours,
Joel

On 4/27/16 10:17 AM, Jim Guichard (jguichar) wrote:
> This section is too wishy washy. It makes the statement “this document
> assumes the SFC control plane is provided with a set of information that
> is _required_ for proper SFC operation” but then goes on to list bullets
> that are _likely_ to be provided or _may_ be provided. It does not
> actually provide any information on what _is required for proper SFC
> operation_. In the list of _likely_ information there is no indication
> of whether this information must exist in the network prior to
> bootstrapping the SFC control plane element; this is true also for the
> list of _may_ information. Surely we should provide guidelines on what
> _must_ be available before the SFC control plane element can actually
> function although it is reasonable to assume that it can bootstrap
> without any information (albeit it can’t actually do anything). On this
> point I would argue that several of the _may_ elements are actually
> required such as SFF, SF, SFC-proxy locators and may exist prior to
> bootstrapping the SFC control plane element, or may be added later
> through some control interface.
>
> Minor point -> typo in bullet point 6 – SFP proxy should read *SFC* proxy
>
> What does the sentence “various transport encapsulation schemes and/or
> variations of SFC header implementations may be supported” actually mean
> ? Are we referring to the fact that the SFC header may carry type-1 or
> type-2 metadata or something else ? Note that there is only *one *SFC
> header implementation based on the WG charter so if we are referring to
> different SFC formats (meaning metadata) then please make this clear in
> the text, and if not, please remove this sentence.
>
> Second bullet point “mapping between service function chains and SFPs” -
> this is a general comment for the entire document but applies here also.
> There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned
> only once in the entire document. The architecture is explicit in that
> the SFP when rendered into the network is an RSP and therefore the SFC
> control plane element needs to have information on currently deployed RSPs.
>
> Additionally there is no interface specified for communication between
> the SFC Control Plane Element and SF management systems. This is an
> important aspect as many SF’s may require that SFC information be
> communicated to their management systems that will be responsible for
> communicating directly with their respective SF’s.
>
> The sentence “The control plane may instruct the classifier about the
> initial values of the Service Index (SI)” should be changed to say
> *MUST* as otherwise if a classifier chooses whatever value it wants then
> that may not align with what is programmed into the SFFs by the SFC
> Control Plane element.
>
> This section does not actually provide any meaning or indication of
> relationship with the SFC Control Plane element. Furthermore,  there has
> been no WG consensus to carry source routes within the SFC
> encapsulation. Therefore this entire section should be removed from the
> document.
>
> Figure 2 lists 3 different SFP-id’s whereas the text mentions only
> SFP-id #1. Is this simply a typo or are you trying to convey something
> else ?
>
> Further you state that “the steering policies to a SFF node for service
> function chain depends on if the packet comes from previous SFF or comes
> from a specific SF i.e., the SFP Forwarding Table entries have to be
> ingress port specific” -  this is an inaccurate statement as the
> combination of the SFP-id and service-index determines the forwarding
> behavior (as specified in section 3.3 & section 7 of
> draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.
>
> Jim
>
>
>
> On 4/27/16, 12:29 AM, "sfc on behalf of Martin Stiemerling"
> <[email-masked] <mailto:[email-masked]> on behalf of
> [email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 27 Apr 2016 16:02:26 +0000

Martin,

Thanks,
Linda

On Wed, Apr 27, 2016 at 12:29 AM, Martin Stiemerling <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Regards,

  Martin (SFC co-chair)

---

From: Ron Parker <[email-masked]>
Date: Wed, 27 Apr 2016 16:05:43 +0000

+1

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, April 27, 2016 12:02 PM
To: Martin Stiemerling <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Martin,

Thanks,
Linda

Regards,

  Martin (SFC co-chair)

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 27 Apr 2016 16:14:42 +0000

Yes you make a good point and I agree.

Jim

On 4/27/16, 10:42 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> This section is too wishy washy. It makes the statement ³this document
>> is _required_ for proper SFC operation² but then goes on to list bullets
>> without any information (albeit it can¹t actually do anything). On this
>> Minor point -> typo in bullet point 6  SFP proxy should read *SFC*
>>proxy
>>
>> What does the sentence ³various transport encapsulation schemes and/or
>> variations of SFC header implementations may be supported² actually mean
>> Second bullet point ³mapping between service function chains and SFPs² -
>> There is no mention of mapping SFPs -> RSPs  in fact RSP is mentioned
>> important aspect as many SF¹s may require that SFC information be
>> communicating directly with their respective SF¹s.
>>
>> The sentence ³The control plane may instruct the classifier about the
>> initial values of the Service Index (SI)² should be changed to say
>> Figure 2 lists 3 different SFP-id¹s whereas the text mentions only
>> Further you state that ³the steering policies to a SFF node for service
>> ingress port specific² -  this is an inaccurate statement as the

---

From: "Huangyong (Oliver)" <[email-masked]>
Date: Thu, 28 Apr 2016 01:05:45 +0000

Dear Martin,

    As the early version author of the draft.  I support publication of this draft.

BR
Oliver

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Martin Stiemerling
发送时间: 2016年4月27日 12:29
收件人: [email-masked]
主题: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: <[email-masked]>
Date: Thu, 28 Apr 2016 06:58:41 +0000

Hi Jim,

Thank you for the review.

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 27 avril 2016 16:18
À : Martin Stiemerling; [email-masked]
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Martin & WG:

[Med] Fair point. I suggest to make these modifications:

(1)

OLD:
   The following information that is likely to be provided to the SFC
   control plane at bootstrapping includes (non-exhaustive list):

NEW:

   The following information that is RECOMMENDED to be provided to the SFC

   control plane prior to bootstrapping includes:

(2)

Remove this bullet from the list and insert it right after the list.

   o  Optionally, (traffic/CPU/memory) load balancing objectives at the

      SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis.

[Med] Fixed. Thanks.

[Med] That sentence is related to the rich set of transport encapsulation schemes, but also that nsh header includes a version number.

The current nsh spec does not specify how nodes with distinct nsh versions are supposed to behave. Also, we don't know in 2016 (because there is no nsh v2) whether v0 and v2 will be backward compatible. If these versions are not backward compatible, this will lead to failures when two adjacent elements in a service chain do not support the same version.

The cp is key to ensure coherent setup of an SFC-domain to avoid failures that are due to unsupported version and/or unsupported transport encapsulation.

[Med] I agree RSP is not explicitly mentioned in Section 3.1, but the point you raised is what is under this bullet:

   o  Determine a forwarding path in the context of a centralized

      deployment model (see Section 3.2<https://tools.ietf.org/html/draft-ietf-sfc-control-plane-04#section-3.2>).

Section 3.2 states the following:

      For some traffic engineering proposes, the SFP may be constrained

      by the control plane; as such, some SFPs can be fully specified

      (i.e., list all the SFF/SFs that need to be solicited) or

      partially specified (e.g., exclude some nodes, explicitly select

      which instance of a given SF needs to be invoked, etc.).

Do you think a change is still needed to the text?

[Med] Good point. I suggest this change in Section 3.3.3 that I believe is sufficient to take into account this comment:

OLD:

   The SFC control plane uses this interface to interact with SFC-aware

   SFs.

NEW:

   The SFC control plane uses this interface to interact with SFC-aware

   SFs. This interaction may be direct or via dedicated SF management systems.

[Med] Makes sense. I made the change in my local copy.

[Med] FWIW, there was a call about this section (https://www.ietf.org/mail-archive/web/sfc/current/msg03756.html). This section does not recommend nor exclude source routes.

[Med] I will defer to Linda/Andrew to clarify this part of that text.

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 28 Apr 2016 13:57:26 +0000

Hi Med,

Inline ..

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 28, 2016 at 2:58 AM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, Martin Stiemerling <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Jim,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 27 avril 2016 16:18
À : Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Martin & WG:

  *   Section 2.2 SFC Control Plane Bootstrapping.
This section is too wishy washy. It makes the statement “this document assumes the SFC control plane is provided with a set of information that is required for proper SFC operation” but then goes on to list bullets that are likely to be provided or may be provided. It does not actually provide any information on what is required for proper SFC operation. In the list of likely information there is no indication of whether this information must exist in the network prior to bootstrapping the SFC control plane element; this is true also for the list of may information. Surely we should provide guidelines on what must be available before the SFC control plane element can actually function although it is reasonable to assume that it can bootstrap without any information (albeit it can’t actually do anything). On this point I would argue that several of the may elements are actually required such as SFF, SF, SFC-proxy locators and may exist prior to bootstrapping the SFC control plane element, or may be added later through some control interface.

(1)

OLD:

NEW:

(2)

Jim> that seems fine.

Minor point -> typo in bullet point 6 – SFP proxy should read SFC proxy
[Med] Fixed. Thanks.

  *   Section 2.3 Coherent Setup of an SFC-enabled Domain
What does the sentence “various transport encapsulation schemes and/or variations of SFC header implementations may be supported” actually mean ? Are we referring to the fact that the SFC header may carry type-1 or type-2 metadata or something else ? Note that there is only one SFC header implementation based on the WG charter so if we are referring to different SFC formats (meaning metadata) then please make this clear in the text, and if not, please remove this sentence.

The current nsh spec does not specify how nodes with distinct nsh versions are supposed to behave. Also, we don’t know in 2016 (because there is no nsh v2) whether v0 and v2 will be backward compatible. If these versions are not backward compatible, this will lead to failures when two adjacent elements in a service chain do not support the same version.

Jim> maybe just replace “variations” with “versions” so that it is clear what is being talked about ?

  *   Section 3.1 Reference Architecture
Second bullet point “mapping between service function chains and SFPs” - this is a general comment for the entire document but applies here also. There is no mention of mapping SFPs -> RSPs – in fact RSP is mentioned only once in the entire document. The architecture is explicit in that the SFP when rendered into the network is an RSP and therefore the SFC control plane element needs to have information on currently deployed RSPs.

Jim> no I am fine with the text as it stands.

Additionally there is no interface specified for communication between the SFC Control Plane Element and SF management systems. This is an important aspect as many SF’s may require that SFC information be communicated to their management systems that will be responsible for communicating directly with their respective SF’s.

OLD:

   SFs.

NEW:

Jim> that looks good.

  *   Section 3.1.1. C1: Interface between SFC Control Plane & SFC Classifier
The sentence “The control plane may instruct the classifier about the initial values of the Service Index (SI)” should be changed to say MUST as otherwise if a classifier chooses whatever value it wants then that may not align with what is programmed into the SFFs by the SFC Control Plane element.

Jim> the title of the section is “Encoding the exact SFF/SF sequence in data packets” which is pretty clear what that means. The only encoding of the SFF/SF sequence supported by the SFC encapsulation (taking type-2 metadata out of the equation) is the SPI + SI (which is actually a reference to the placement within the service path rather than an encoding directly of a service sequence in the data plane) hence again I think this section should be removed from the document.

Jim

  *   Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
Figure 2 lists 3 different SFP-id’s whereas the text mentions only SFP-id #1. Is this simply a typo or are you trying to convey something else ?

Further you state that “the steering policies to a SFF node for service function chain depends on if the packet comes from previous SFF or comes from a specific SF i.e., the SFP Forwarding Table entries have to be ingress port specific” -  this is an inaccurate statement as the combination of the SFP-id and service-index determines the forwarding behavior (as specified in section 3.3 & section 7 of draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 28 Apr 2016 10:11:00 -0400

Jim,

Regarding your comments on section 4.10.5:

>
>    - Section 4.10.5. Fully Controlled SFF/SF Sequence for a SFP
>
> Figure 2 lists 3 different SFP-id’s whereas the text mentions only SFP-id
> #1. Is this simply a typo or are you trying to convey something else ?
>

Figure 2 is meant as an example of a set of steering policies. You’re
right, it’s confusing to refer to just #1, when we really don’t need to. I
think we can improve the introductory sentence above the figure by just
saying:

For illustration purposes, an example set of steering policies for an SFF
is depicted in Figure 2.

> draft-ietf-sfc-nsh-04).  This sentence should be removed from the text.
 I agree, thanks for spotting!

Cheers,
Andy

---

From: <[email-masked]>
Date: Thu, 28 Apr 2016 14:45:49 +0000

Re-,

I made the required change in my local copy to address this comment:

Jim> maybe just replace "variations" with "versions" so that it is clear what is being talked about ?

The only pending point is about Section 4.10.4. I'm neutral on this point.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : jeudi 28 avril 2016 15:57
À : BOUCADAIR Mohamed IMT/OLN; Martin Stiemerling; [email-masked]
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Med,

Inline ..

Hi Jim,

Please see inline.

Cheers,
Med

Hi Martin & WG:

(1)

OLD:

NEW:

(2)

Jim> that seems fine.

Jim> maybe just replace "variations" with "versions" so that it is clear what is being talked about ?

OLD:

   SFs.

NEW:

Jim> that looks good.

Jim> the title of the section is "Encoding the exact SFF/SF sequence in data packets" which is pretty clear what that means. The only encoding of the SFF/SF sequence supported by the SFC encapsulation (taking type-2 metadata out of the equation) is the SPI + SI (which is actually a reference to the placement within the service path rather than an encoding directly of a service sequence in the data plane) hence again I think this section should be removed from the document.

Jim

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 18:43:01 +0000

Further to Jim's points about section 4.10.5, do I read it correctly that the SFF can be configured to steer traffic on the basis of these?
   o  Destination MAC address
   o  Source MAC address
   o  VLAN-ID,
   o  Destination IP address
   o  Source IP address
   o  Source port number
   o  Destination port number
   o  DSCP
   o  Packet size, etc., or any combination thereof.

This comes totally unexpected to me, thinking that the SFF steers traffic based exclusively on Service Path Identifier and Service Index (SPI/SI), which oddly aren't in the above list.

I can guess that maybe this is about reclassification, but "classification" isn't mentioned in 4.10.5.
Can someone explain?

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; [email-masked]
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Martin & WG:

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 28 Apr 2016 19:02:34 +0000

Dave,
I would also concur that SFF is a forwarding entity that uses pathID/SI to find the next-hop/next-sf/next-sff. This is how our SFF works.

It is absolutely possible that co resident classifier to further classify based on  l3/l4/l7/python_code and change the path. But logically that is another classification and list below is certainly not exhaustive.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 28, 2016 at 11:43 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Further to Jim’s points about section 4.10.5, do I read it correctly that the SFF can be configured to steer traffic on the basis of these?
   o  Destination MAC address
   o  Source MAC address
   o  VLAN-ID,
   o  Destination IP address
   o  Source IP address
   o  Source port number
   o  Destination port number
   o  DSCP
   o  Packet size, etc., or any combination thereof.

This comes totally unexpected to me, thinking that the SFF steers traffic based exclusively on Service Path Identifier and Service Index (SPI/SI), which oddly aren’t in the above list.

I can guess that maybe this is about reclassification, but “classification” isn’t mentioned in 4.10.5.
Can someone explain?

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, April 27, 2016 10:18 AM
To: Martin Stiemerling; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Hi Martin & WG:

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: Henry Fourie <[email-masked]>
Date: Thu, 28 Apr 2016 21:28:13 +0000

All,
    Comments:

1.      There is one sentence on OAM in 3.1. This probably deserves a sub-section in section 4 that covers fault management, alarms, error reporting, switchovers...

Note, the SFC control plane must be able to invoke SFC OAM mechanisms, and to determine the results of OAM operations.

2.      There is no mention of metadata in the document. Use of the term 'metadata' may make some text clearer.
For example, there should be a sentence in the 3.3.x sections for SFC controller to request a particular component to insert/remove/report packet metadata.

3.      Last para of 3.3.2: change 'An SFF can be instructed...' to 'An SFF must be instructed...'

4.      3.3.3: This paragraph does not read well:

This interface is also used to instruct an SFC-aware SF about any
context information it needs to supply in the context of a given SFC.
Suggest:
This interface may also be used to instruct an SFC-aware SF to insert, remove or
report metadata information for a given SFC.

5.      3.3.3: In several paragraphs the term 'contexts' is used. It may be clearer if 'metadata' is used instead.

6.      Suggest moving this paragraph from 4.10.5 to 3.4.4 as it relates specifically to

SFC Proxy functionality. Reworded, this can replace the last sentence in 3.3.4:

The C4 interface may also include information to map the SFP
Identifier carried in the packet header to a locally significant link
identifier, e.g., VLAN-ID, and a method to construct and encapsulate
the SFC header back to the packets when they come back from the attached SFs.

7.      Last para of 4.10.5 typo: classier -> classifier

8.      Last para of 4.10.5: This could be clearer on what the problem is. Not sure what SFF A and SFF B are? Would it not be better to recommend a procedure in which the SFC Controller updates downstream SFFs before upstream SFFs when constructing a new SFP. Insertion of a SF into a SFP should have only local impact on the SFF it is connected to.

-        Louis

From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Thursday, April 28, 2016 12:03 PM
To: Dave Dolson; [email-masked]
Cc: Jim Guichard (jguichar)
Subject: Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Dave,

-Dave

Hi Martin & WG:

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: <[email-masked]>
Date: Fri, 29 Apr 2016 07:46:42 +0000

Dear Louis,

Please see inline.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Henry Fourie
Envoyé : jeudi 28 avril 2016 23:28
À : Sumandra Majee; Dave Dolson; [email-masked]
Cc : Jim Guichard (jguichar)
Objet : Re: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

All,
    Comments:

[Med] We used to have a dedicated OAM section but the WG decided to move that text from the draft (see https://trac.tools.ietf.org/wg/sfc/trac/ticket/12). The points you mentioned are good ones but they should be handled in the OAM

document.

[Med] The document uses "context information" (that is called out in https://datatracker.ietf.org/wg/sfc/charter/). I made a change to indicate that "context information" is also known as "metadata".

3.       Last para of 3.3.2: change 'An SFF can be instructed...' to 'An SFF must be instructed...'
[Med] Looks reasonable to me.

[Med] The modification mixes several aspects that are covered in other parts of this section. I made this change:

   This interface is also used to instruct an SFC-aware SF about any
   context information (a.k.a., metadata) it needs to supply for a given SFC.

[Med] See above.

[Med] There is already this text in Section 3.4.4:

   This interface may also be used to instruct the SFC proxy about the

   state and information to maintain for proper handling of packets

   received back from an SFC-unaware SF.

7.       Last para of 4.10.5 typo: classier -> classifier
[Med] Thank you for catching this. Fixed.

8.       Last para of 4.10.5: This could be clearer on what the problem is.

[Med] The problem is detailed in the example: "For example, if the SFF "A" and SFF "C" get flow

   steering policies at slightly different times, some packets might not

   be directed to some service functions on a chain."

Can you please indicate what is not clear in that text? Thank you.

Not sure what SFF A and SFF B are?
[Med] These are SFF examples to illustrate the problem.

Would it not be better to recommend a procedure in which the SFC Controller updates downstream SFFs before upstream SFFs when constructing a new SFP. Insertion of a SF into a SFP should have only local impact on the SFF it is connected to.
[Med] The notion of upstream and downstream SFF depends the chain under consideration. So following the recommendation you propose may not be possible if SFF provisioning/control is achieved for all chains at once, not per each chain. This decision is deployment-specific.

-          Louis

To: Dave Dolson; [email-masked]<mailto:[email-masked]>

Dave,

-Dave

Hi Martin & WG:

Jim

Dear all,

Regards,

   Martin (SFC co-chair)

---

From: Qin Wu <[email-masked]>
Date: Fri, 29 Apr 2016 07:53:44 +0000

+1.
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Huangyong (Oliver)
发送时间: 2016年4月28日 9:06
收件人: Martin Stiemerling; [email-masked]
主题: [sfc] 答复: WGLC for draft-ietf-sfc-control-plane-04.txt

Dear Martin,

BR
Oliver

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Martin Stiemerling
发送时间: 2016年4月27日 12:29
收件人: [email-masked]
主题: [sfc] WGLC for draft-ietf-sfc-control-plane-04.txt

Dear all,

Regards,

   Martin (SFC co-chair)