Subject: Re: [sfc] #13 (control-plane): Sumandra Majee's comments

From: "sfc issue tracker" <[email-masked]>
Date: Mon, 09 Nov 2015 14:00:04 -0000

#13: Sumandra Majee's comments

Comment (by [email-masked]):

 A proposal to handle the comments from Sumandra. No feedback was received
 since then.

 ===
 De : BOUCADAIR Mohamed IMT/OLN
 Envoyé : mercredi 16 septembre 2015 16:44
 À : 'Sumandra Majee'
 Objet : Your comments (was RE: [sfc] WG call for adoption of draft-ww-sfc-
 control-plane-06)

 Hi Sumandra,

 Thank you for the comments.

 I recorded your comments in the issue tracker so that we don’t miss them.

 Please see inline.

 Cheers,
 Med

 De : sfc [mailto:[email-masked]] De la part de Sumandra Majee
 Envoyé : samedi 15 août 2015 04:43
 À : Jim Guichard (jguichar); [email-masked]
 Objet : Re: [sfc] WG call for adoption of draft-ww-sfc-control-plane-06

 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.

 [Med] What about adding this sentence to section 4.7:
 “Local failure detect and repair mechanisms may be enabled by SFC-aware
 nodes. Control Elements may be fed directly or indirectly with inputs from
 these mechanisms.”

 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.

 [Med] The purpose is to provide a non-exhaustive list of counters to
 illustrate which kind of information we are talking about. I don’t think
 it is harmful to maintain this list. The text already states “(but not
 limited to)”. If you think this is confusing, I can change the text to
 make it more clear.

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

 [Med] The full sentence is :

    SFC Classification policy entry should be bound to one single service
    function chain (or one single SFP); when an incoming packet matches
    more than one classification entry, tie-breaking criteria should be
    specified (e.g., priority).  Such tie-breaking criteria should be
    instructed by the control plane.

 The purpose of the sentence is to ensure that the classifier can be fed by
 the control plane with appropriate information for the sake of
 deterministic behaviors. When a packet matches several classification
 entries, further instructions are needed to decide which processing is to
 be followed. I hope this makes sense to you.
 ====

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-sfc-
  [email-masked]       |  [email-masked]
     Type:  enhancement              |      Status:  new
 Priority:  minor                    |   Milestone:
Component:  control-plane            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/13#comment:2>
sfc <http://tools.ietf.org/sfc/>

---

From: "sfc issue tracker" <[email-masked]>
Date: Wed, 25 Nov 2015 10:34:19 -0000

The following changes are made in -01:

 * Add this text in Section 4.7:

 NEW:
    Local failure detect and repair mechanisms may be enabled by SFC-
    aware nodes.  Control Elements may be fed directly or indirectly with
    inputs from these mechanisms.

 * In section 3.3.1:

 OLD:

 NEW:
    When an incoming packet matches more than one classification entry,
    tie-breaking criteria should be followed (e.g., priority).  Such tie-
    breaking criteria should be instructed by the control plane.

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/13#comment:3>
sfc <http://tools.ietf.org/sfc/>