Opened 6 years ago

Last modified 6 years ago

#13 new enhancement

Sumandra Majee's comments

Reported by: mohamed.boucadair@… Owned by: draft-ietf-sfc-control-plane@…
Priority: minor Milestone:
Component: control-plane Version:
Severity: - Keywords:
Cc:

Description

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. SFC Classification policy entry should be bound to one single service
  4. 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

Change History (3)

comment:1 Changed 6 years ago by mohamed.boucadair@…

  • Component changed from architecture to control-plane
  • Owner changed from draft-ietf-sfc-architecture@… to draft-ietf-sfc-control-plane@…

comment:2 Changed 6 years ago by mohamed.boucadair@…

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 sfc-bounces@… De la part de Sumandra Majee
Envoyé : samedi 15 août 2015 04:43
À : Jim Guichard (jguichar); sfc@…
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.”

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

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

comment:3 Changed 6 years ago by mohamed.boucadair@…

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:

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.

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.

Note: See TracTickets for help on using tickets.