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

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" <sfc-bounces@ietf.org<mailto:sfc-bounces@ietf.org> on behalf of mls.ietf@gmail.com<mailto:mls.ietf@gmail.com>> wrote:

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 sfc@ietf.org<mailto:sfc@ietf.org> list.

Regards,

   Martin (SFC co-chair)

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc