Subject: [sfc] AD review of draft-ietf-sfc-control-plane-06

From: Alia Atlas <[email-masked]>
Date: Tue, 23 Aug 2016 18:35:54 -0400

As is customary, I have done my AD review of
draft-ietf-sfc-control-plane-06.
First, I would like to thank the editor, Mohamed, and all the contributors
for their
work on this document.

Normally, when I review a draft, it is easy to read for what is in the
document and provide detailed comments on the text or technical issues.
This document is different because some of the concerns are about what is
missing as well as the structure and purpose of this.   Please regard this
as the start of a conversation.

a) First, while this document tries to clarify the control plane, it is not
something is describing a particular architecture or even providing enough
detail that I could go and
consider how to develop a control plane protocol or data-models to handle
any of the cases.  It isn't implementable, it doesn't provide guidance for
evaluating options, and
it makes very few choices - even to narrow down between very different
design alternatives.

Can you please clarify what you see as the purpose and usefulness of this
document?  It has a lot of interesting information in it - but it doesn't
feel directed towards a particular purpose.

b) When we talk about a networking architecture, there are multiple
different planes and aspects discussed.   This document says that it is
about the control-plane, but I don't find that there is a clean separation
between what would be at the management plane and even the OAM and
monitoring aspects and what is the control-plane.

For instance, there are several references to learning the load of an SF .
Even Section 4.8 describes counters and statistics to be provided via the
control plane interfaces.   Similarly, the information at bootstrapping
doesn't distinguish between management information (what the SFCs are, what
traffic is to be directed to them) and information that should be
dynamically learned from the network, so that changes can also be
discovered.

c)  The dynamics of the control plane aren't discussed at all.  There is no
indication of the needed timeliness of the interfaces.   I'm not even
poking at the scalability of these - but questions about what type of
responsiveness or change rates are anticipated.

d) The interfaces are described largely statically in terms of information
to be passed, but not the dynamics of the life-cycle of the pieces of
functionality.  For instance, I might expect something along the lines of:

  "A Control-Plane entity is provided by the management system with an SFC
to be created and a set of SFs to be followed.   To create an SFC, the
Control-Plane Entity
must determine the meta-data required by each SF and that can be generated
by each SF.  Then the Control-Plane Entity must determine the specific SFP
to be used.
An SFP can be created via head-end signaling or by direct communication
from the Control-Plane Entity.  To create an SFP, it is necessary to
specify the sequence of SFs and SFFs, what metadata to be added or removed
by each SF and how that metadata is to be carried in the encapsulation.  If
the specific transport used between SFFs is significant, then that may also
be specified.

In addition to creation, a Control-Plane Entity must handle modification
and removal of an SFP. "  Then there could be different options - either
 "When modification is done, it needs to be done from the end of the SFP to
the start to avoid stranding traffic." or   "A make-before-break mechanism
can be used where a new SFP is allocated, set up, tested, the traffic is
migrated to it, and finally the old SFP is removed."

In Sec 4.9, the concept of Validity lifetimes is introduced.  I don't know
if that applies just to the classification rules or the SFPs as well, but
if it does, information about where & how it is refreshed is needed.

e) Similarly to the life-cycle of objects created and managed by the
control-plane, I'd also expect to see a section talking about discovery of
information and what needs to be able to learn that information.  For
instance, how are the locators of SFFs, SFs,classifiers, etc. learned?
What needs to learn about them?  Is information about what transport each
supports something that is dynamically discovered?  Is information about
what formats of metadata can be handled dynamically discovered?  What
entities need to learn when an SF or SFF is overloaded?  If the
control-plane entity doesn't compute the specific detailed SFs to be used
and the head-end of the SFP needs to do computation, then presumably, the
head-end also needs to be aware of when an SF or SFF is overloaded.

f) For more minor comments, the lack of introductory text introducing
Figure 1 is unfortunate.  It doesn't give the reader context when reading
the further sections.  The written description around C1/C2/C3 has a lot of
redundancy and doesn't highlight what are the differences between the
interfaces.  This would be much better showing the information that needs
to generally be communicated and then the nuances added.

g) There are scattered comments around liveness and monitoring - but how
that is to be done, what it reports back to, how the control-plane entity
or head-end handles it, is simply not described.

This feels like a document that badly needs a set of folks to walk through
the life-cycle and event flows.   As written, I can't tell whether a
discovery/flooding protocol is needed.  It's very hard to peel apart what
work needs to be done.  It's quite clear that describing the interfaces to
SFFs, SFs, etc. and a "control-plane entity" misses a number of needed
communications.

I don't currently see how this document provides a basis for moving forward
on control-plane work.

Regards,
Alia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Aug 2016 18:59:04 -0400

Thank you fro a careful review Alia.  What follows is my personal take 
on the document.

On 8/23/16 6:35 PM, Alia Atlas wrote:
> First, I would like to thank the editor, Mohamed, and all the
> contributors for their
> work on this document.
>
>   This document is different because some of the concerns are about what
> is missing as well as the structure and purpose of this.   Please regard
> this as the start of a conversation.
>
> a) First, while this document tries to clarify the control plane, it is
> not something is describing a particular architecture or even providing
> enough detail that I could go and
> consider how to develop a control plane protocol or data-models to
> handle any of the cases.  It isn't implementable, it doesn't provide
> guidance for evaluating options, and
> Can you please clarify what you see as the purpose and usefulness of
> this document?  It has a lot of interesting information in it - but it
> doesn't feel directed towards a particular purpose.

For me, the purpose of this document is to lay out the expectations the 
data plane has of the control plane.  It is a place to capture, for 
future work, the behaviors and constraints any control plane solution 
for SFC must exhibit / meet.  It is not an effort to make design or 
architecture choices.  The SFC charter is very clear that we are to work 
on those requirements.

> about the control-plane, but I don't find that there is a clean
> separation between what would be at the management plane and even the
> OAM and monitoring aspects and what is the control-plane.

Given the above stated goal, I do not want the document to care about 
the differences between "classical control" and "management" or 
"orchestration".  From the point of view of the SFC data plane, it does 
not matter what kind of mechanism is used to achieve the goals.

>
> For instance, there are several references to learning the load of an SF
> .  Even Section 4.8 describes counters and statistics to be provided via
> the control plane interfaces.   Similarly, the information at
> bootstrapping doesn't distinguish between management information (what
> the SFCs are, what traffic is to be directed to them) and information
> that should be dynamically learned from the network, so that changes can
> also be discovered.

We probably do need to be clear, in describing the information needs, 
about what information (in either direction) is dynamic as opposed to 
largely unchanging.  This will help folks avoid using static operational 
protocols for dynamic information.

>
> c)  The dynamics of the control plane aren't discussed at all.  There is
> no indication of the needed timeliness of the interfaces.   I'm not even

This is probably a good point that we should address.

>
> d) The interfaces are described largely statically in terms of
> information to be passed, but not the dynamics of the life-cycle of the
> pieces of functionality.  For instance, I might expect something along
> the lines of:
>
>   "A Control-Plane entity is provided by the management system with an
> SFC to be created and a set of SFs to be followed.   To create an SFC,
> the Control-Plane Entity
> must determine the meta-data required by each SF and that can be
> generated by each SF.  Then the Control-Plane Entity must determine the
> specific SFP to be used.
> specify the sequence of SFs and SFFs, what metadata to be added or
> removed by each SF and how that metadata is to be carried in the
> encapsulation.  If the specific transport used between SFFs is
> significant, then that may also be specified.
>
>  "When modification is done, it needs to be done from the end of the SFP
> to the start to avoid stranding traffic." or   "A make-before-break
> mechanism can be used where a new SFP is allocated, set up, tested, the
> traffic is migrated to it, and finally the old SFP is removed."

As noted above, I don't think that this document should attempt to 
differentiate among classical control, management, and orchestration. 
As such, it is not useful to talk about information moving between 
components within the control space.
This is particularly apropos as we are not trying to specify the design 
or architecture of the control components, so we are not picking such flows.

>
> In Sec 4.9, the concept of Validity lifetimes is introduced.  I don't
> know if that applies just to the classification rules or the SFPs as
> well, but if it does, information about where & how it is refreshed is
> needed.

Sounds reasonable.

> control-plane, I'd also expect to see a section talking about discovery
> of information and what needs to be able to learn that information.  For
> What needs to learn about them?  Is information about what transport
> each supports something that is dynamically discovered?  Is information
> about what formats of metadata can be handled dynamically discovered?
> What entities need to learn when an SF or SFF is overloaded?  If the
> control-plane entity doesn't compute the specific detailed SFs to be
> used and the head-end of the SFP needs to do computation, then
> presumably, the head-end also needs to be aware of when an SF or SFF is
> overloaded.

Discovery is a complex topic as we are allowing for both situations 
where existing elements are discovered, and for situations where the 
control infrastructure creates elements and thus has no need to discover 
them.  As such, the data plane does not require discovery, although some 
control architectures will have such requirements.

> Figure 1 is unfortunate.  It doesn't give the reader context when
> reading the further sections.  The written description around C1/C2/C3
> has a lot of redundancy and doesn't highlight what are the differences
> between the interfaces.  This would be much better showing the
> information that needs to generally be communicated and then the nuances
> added.

This sounds like helpful explication.

> that is to be done, what it reports back to, how the control-plane
> entity or head-end handles it, is simply not described.

This document does not describe how, only what is required / expected.

>
> This feels like a document that badly needs a set of folks to walk
> through the life-cycle and event flows.   As written, I can't tell
> whether a discovery/flooding protocol is needed.  It's very hard to peel
> apart what work needs to be done.  It's quite clear that describing the
> interfaces to SFFs, SFs, etc. and a "control-plane entity" misses a
> number of needed communications.

I think you are asking for something that is well beyond our intent.

>
> I don't currently see how this document provides a basis for moving
> forward on control-plane work.

To restate, the goal here as I understand it is to provide a set of 
minimums that any control plane work must meet.  Anything more than that 
is a different can of worms.

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

---

From: <[email-masked]>
Date: Wed, 24 Aug 2016 08:02:19 +0000

Dear Alia, all, 

Many thanks for the review. 

I second what has been mentioned by Joel. 

The document focuses on "requirements for conveying information between control or management elements and SFC implementation points" (SFC Charter). The document defines what is meant by these "SFC implementation points" in reference to the SFC data plane architecture. Distinct interfaces are defined to distinguish among the information that is needed to be conveyed to each SFC data plane element.

It is not a goal of this document to make choices between alternate options. Also, it does not aim to specify protocols or protocol extensions. Those aspects are clearly out of the scope. Note that the charter is not clear whether one or many "protocol extension work resulting from these requirements" (SFC Charter) will be defined in the future. Such effort, if any, will be "under a revised charter" (SFC Charter).

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : mercredi 24 août 2016 00:59
> À : Alia Atlas; [email-masked]; [email-masked]
> Objet : Re: [sfc] AD review of draft-ietf-sfc-control-plane-06
> 
[Med] Agree.

> not matter what kind of mechanism is used to achieve the goals.

[Med] The document is constrained by the scope defined in the WG charter : "requirements for conveying information between control or management elements and SFC implementation points"

> > that should be dynamically learned from the network, so that changes can

[Med] The bootstrapping section distinguishes between two 'kinds" of information:
* The one with service instructions (first set of bullets): This one is clearly out of scope. 
* The second set of information gathered from the network: I'd personally recommend those to be discovered dynamically but the outcome of the discussion we had in the WG is that discovery is out of scope. For this reason, I included this sentence into the draft "How this information is collected is left unspecified in this document" and 
" This can be achieved using a
   variety if mechanisms such as static configuration or the activation
   of a service discovery mechanism.  The exact specification of how
   this provisioning is achieved is out of scope. " (Section 4.1)

The document discusses also information that is needed for "dynamically" adjusting SFPs (e.g., Sections 3.3.2 and 3.3.4), "dynamic attachment of SFs to a SFF and/or discovery of SFs by a SFF" (Section 3.3.2), or notifying changes (e.g., Sections 4.6 and 4.7). 

> protocols for dynamic information.

[Med] The current text uses "unsolicited", "dynamically", "service function discovery procedure", "dynamic attachment", "notified", to characterize some information that is needed to be dynamic. 

> This is probably a good point that we should address.

[Med] Good point. Will update the text with such information whenever appropriate.

> > pieces of functionality.  For instance, I might expect something along

[Med] I understand your point.. but it is not easy to write such text because there are several options to realize the same task. This is exactly why we are focusing on the information to be passed not how it is passed. 

See for example some alternate options to the flow you are proposing. 

> > SFC to be created and a set of SFs to be followed.

[Med] One may argue that the set of SFs to be followed in the context of a given SFC may be a local decision of the CP, service decision engine, or statically configured. 

   To create an SFC,
> > generated by each SF.

[Med] One would argue that the CP is not required to **determine** which metadata is required for each service chain, but it may be responsible for receiving such instruction from a service decision engine and translate it into instructions to underlying SFC DP elements.

  Then the Control-Plane Entity must determine the
> > from the Control-Plane Entity.

[Med] ...Or may be dynamically computed. 

  To create an SFP, it is necessary to
> > specify the sequence of SFs and SFFs

[Med] The set of SFFs is not required to be fully specified, for example.

, what metadata to be added or
> > significant, then that may also be specified.

[Med] Already covered in Section 2.3.

> > traffic is migrated to it, and finally the old SFP is removed."

[Med] SFP modification and removal are mentioned in Section 4.5. How this is actually enforced is deployment-specific. 

> > well, but if it does, information about where & how it is refreshed is

[Med] I see some value in associating a validity lifetime to the entries of the SFP Forwarding Policy Table maintained by SFFs. The lifetime of such entries can be set of a control plane element or via a signaling protocol during the setup of an SFP (case of RSPs). I can add some to reflect those in the draft.    

> > instance, how are the locators of SFFs, SFs,classifiers, etc. learned?

[Med] The per-domain discovery is out of scope of this document. Nevertheless, the documents mentions what information is needed to be discovered. Also, it even hints that some information can be dynamically discovered (e.g., SF attachment to SFFs, CP Control Element). 

> > each supports something that is dynamically discovered? 

[Med] We only focus on the required behavior once that information is gathered (see Section 2.3).

 Is information
> > about what formats of metadata can be handled dynamically discovered?

[Med] Good point. I will update the text to reflect this point.  

> > What entities need to learn when an SF or SFF is overloaded?

[Med] This point is explicitly mentioned in various places of the document (search for "load").

  If the
> > presumably, the head-end also needs to be aware of when an SF or SFF is

[Med] I can update Section 4.10.2 if you think this is useful. 

> > information that needs to generally be communicated and then the nuances

[Med] Will update the text.

> I think you are asking for something that is well beyond our intent.

[Med] Exactly.