Subject: Re: [sfc] WG call for adoption of draft-ww-sfc-control-plane-06

From: Sumandra Majee <[email-masked]>
Date: Sat, 15 Aug 2015 02:42:52 +0000

Support the adoption.

Following are my comments and we should be able to discuss this before the last call.

  1.  4.7 SF liveliness detection:  An inband liveliness also should be considered and this control point should be the only recipient of this information. In a large distributed system this architecture may have a) scalability issues b) issues with reaction time.  If node#1 has the health information for node#2 it can (sometimes) independently take local decision. This will scale well. Furthermore attributes like latency etc. are measured at the local node, and this makes the feedback loop between observer and corresponding local control point much shorter.  This is in addition to what is described in draft.
  2.  4.8 Monitoring and counters: Yes it is needed, but I am not sure this needs to be part of this draft. Either way the list of attributes are best incomplete and it will be always be like that. Why bother with this section at all.
  3.
  4.

SFC Classification policy entry should be bound to one single service
   function chain (or one single SFP)

             The above appears to be unnecessary, if I create a policy object I would rather refer it to multiple places. Can you describe a case or thought process behind this assertion.

Regards

Sumandra

From: "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 12, 2015 at 9:49 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sfc] WG call for adoption of draft-ww-sfc-control-plane-06

Greetings WG:

This message begins a 2 week call for WG adoption of the document https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ ending 26th August 2015.

Please respond to the SFC mailing list with any statements of approval or disapproval.

As always please note the following:

  1.  This is not a WG last call. The document is not final, and the WG is expected to modify the document's content until there is WG consensus that the content is solid. Therefore, please do not oppose adoption just because you want to see changes to its content.
  2.  If you have objections to adoption of the document, please state your reasons why, and explain what it would take to address your concerns.
  3.  If you have issues with the content, by all means raise those issues and we can begin a dialog about how best to address them.

Finally, now is also a good time to poll for knowledge of any IPR that applies to this draft, in line with the IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this email (to the chairs) whether or not you are aware of any relevant IPR.

Jim & Thomas