Subject: [sfc] How to progress our control plane requirements document

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Jan 2017 13:12:03 -0500

Jim and I have been talking with Alia about this, and talking with each 
other.  Along the way we realized that we have some significant concerns 
about what we have done with this document.

We expect to discuss this next week at the interim, looking for ideas. 
And to discuss it further on the list.

The existing control plane document when viewed from the perspective of 
an implementer is hard to decompose into actionable parts. Given that 
the IETF tends to work by solving pieces of problems, rather than an 
entire control solution for all aspects, it is important that 
requriements we define be usable for such piece-wise work. Thus, we need 
to describe the requirements in ways that provide components which may 
be combined into an overall control plane solution for SFC.

While the document provides a set of control plane requirements it does 
not provide guidance on how those requirements can be successfully 
consumed into a standards compliant control plane. In particular, the 
interfaces C1 - C4 are each made up of behaviors likely to be provided 
by different solution components.  Thus, while there is an attempt to 
document a set of interfaces (C1...C4) it is not clear how an 
implementer can provide a solution component that addresses a 
well-defined set of requirements.

Given this, we need to go back and rethink the bundling of functionality 
so as to end up with bundles of requirements that are can be usefully 
addressed by IETF work while avoiding (as we have done well in the 
current version) prescribing the control plane architecture.

In addition, functional objectives are not fine grained enough to 
implement; for example, text such as "Rationalize the management of 
classification rules" is not something one can implement.

Yours,

Jim & Joel

---

From: Sumandra Majee <[email-masked]>
Date: Sat, 14 Jan 2017 00:40:57 +0000

Joel, Jim,

I am in full agreement with this. Having gone thru a implementation of quasi controller ( I am sure so has others) , I can say that the document was not very effective for implementers. While the concept laid out might be useful but it doesn’t translate into anything meaningful. 

I am actually wondering if there is a need control plane document, however there is a need for defining the API/Schema etc. 

Sumandra

On 1/13/17, 10:12 AM, "sfc on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    Yours,
    
    Jim & Joel
    
    _______________________________________________
    sfc mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Tue, 24 Jan 2017 09:34:51 +0000

Hi Joel, all, 

We discussed at length this topic during the interim meeting, but I would like to make some comments on the mailing list too. 

Ideas to better structure the document are always welcome.

As you know, the document was built without making any assumption that (1) one or multiple protocols will be used to fulfil the requirements, (2) the same or distinct protocols can be used to implement each of the interfaces identified in the document, while (3) avoiding overloading the document with deployment-specific considerations.

Further, the main target audience for this document are protocols designers. Because control protocols (extensions) are likely to be defined in other WG, this document defines the minimum set of requirements that the SFC WG agreed that need to be supported. Solutions documents need to comply with the requirements in this draft in order to be stamped as SFC-compliant solution. I agree that it is easy to check the compliancy for solutions that target one single CP interface, a set of CP interfaces of all the CP interfaces defined in the CP architecture. It is indeed more difficult to assess the compliancy for solutions that target a subset of functional requirements that are invoking the various interfaces (e.g., SFC forwarding control, context data control, etc.). Let's discuss how some (functional) would help here.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
> Envoyé : vendredi 13 janvier 2017 19:12
> À : [email-masked]
> Objet : [sfc] How to progress our control plane requirements document
> 

[Med] The text about "Rationalize the management of classification rules" is not a requirement per se, but a reminder of an objective of the SFC effort; the text says explicitly 

"..some functional objectives that can be achieved
   thanks to the invocation of this interface:"

"Rationalize the management of classification rules" is listed to remind that this interface is meant to solve a problem that was called out in the SFC Problem Statement RFC : https://tools.ietf.org/html/rfc7498#section-2.10:

==
   Classification occurs at each service function, independent from
   previously applied service functions since there are limited
   mechanisms to share the detailed classification information between
   services.  The classification functionality often differs between
   service functions, and service functions may not leverage the
   classification results from other service functions.
==

---

From: <[email-masked]>
Date: Tue, 24 Jan 2017 09:57:37 +0000

Dear Sumandra, 

Thank you for sharing your thoughts. 

An implementer that manages both the "controller(s)" and "controlled function" can always implement what it wants without referring to an external requirements document. That’s fair. Nevertheless, standardized protocols (extensions) are needed for interoperability purposes. To get there, this document groups the set of CP requirements that the SFC WG requires to be supported to interact with various implementation points.  

Given that you have an implementation, may I ask you the following non-exhaustive questions:

* What is the information that is needed for your controller at bootstrap? 
* Does your controller require a permanent session to be maintained with the SFC controlled device?
* Does your controller allow to instruct the underlying SFC-aware node about the transport encapsulation to be used?  
* Does your implementation allow to control the semantic of context information, their scope, and how it should be consumed/supplied?
* Does your implementation allow a classifier to auto-clean its entries by means of a lifetime?
* Does your implementation allow to remove stale classification entries?
* Does your implementation allow to retrieve the list of SFs that are attached to a given SFF?
* Does your implementation allow to instruct an SFF about the list of SFs it can service?
* Does your implementation instruct the classifier about the tie-break rules to be followed when more than one classification entry is matched? 
* Does your implementation allow an SFF to remove stale entries without the help of the controller?
* Does your implementation allow to detect the liveness of SFs?
* Does your implementation allow to control the behavior when an SF is to be withdrawn?
* ...   

Thank you.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Sumandra Majee
> Envoyé : samedi 14 janvier 2017 01:41
> À : Joel M. Halpern; [email-masked]
> Objet : Re: [sfc] How to progress our control plane requirements document
> 
> Joel, Jim,
> 
> I am in full agreement with this. Having gone thru a implementation of
> quasi controller ( I am sure so has others) , I can say that the document
> was not very effective for implementers. While the concept laid out might
> be useful but it doesn’t translate into anything meaningful.
> 
> I am actually wondering if there is a need control plane document, however
> there is a need for defining the API/Schema etc.
> 
> Sumandra
> 
> On 1/13/17, 10:12 AM, "sfc on behalf of Joel M. Halpern" <sfc-
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 31 Jan 2017 14:15:30 -0500

I believe the control plane requirements document should be abandoned by 
the WG.

The document attempts to describe the information needed by the various 
components (e.g., SF, SFF, classifier) of the architecture. However, RFC 
7665 and draft-ietf-sfc-nsh already describe the information needed by 
the components, and the control plane requirements document does not add 
anything of substance.

The requirements document attempts to organize the information into four 
"interface reference points", but as other have pointed out already, 
this method of organization just is not particularly useful, and is not 
helpful when designing a control plane architecture.  These reference 
points do not correspond to anything real.   If the document advances, 
someone will ask questions like "is this protocol element  part of the 
implementation of interface C2 or is it part of the implementation of 
interface C3?", and the answer will often be "well, you could think of 
it as part of C2, or you could think of it as part of C3, or maybe as 
part of both, depending on your deployment scenario, but really it 
doesn't matter".  In this way, the document creates extra work without 
adding extra value.

When I first looked at the document, I thought it was going to provide a 
set of APIs allowing one to build an SF without knowing what the control 
plane would be.  That might be useful (if it is even possible), but the 
document does not seem to provide any such thing.

There is important information that is absent from the prior documents, 
such as the information needed to support the interaction of the service 
layer components with the underlying transport, but that information is 
also absent from the requirements document.

I don't think this sort of requirements document is helpful when 
attempting to design a control plane solution, it just gets in the way.

---

From: Sumandra Majee <[email-masked]>
Date: Wed, 1 Feb 2017 02:56:07 +0000

Med,

Sorry for the delay, I guess new year started with a bang ☹. 
Before we go into detail I agree that that a common/standardized interface to an entity (you call it controller and I call it manager) is very much required. There should be a set of interface that is absolutely necessary, for example the interface (think C2) between Controller to SFF in order to distribute path/nexthop information. I would like to see a schema etc. for that interface so we all can implement it and expect to work with any controller.

The classifier may or may not be part of SFC controller domain. Yes, there needs to be a mapping of <RULE> to <CHAIN> but a classifier may choose to acquire this rule
- From PCRF
- SDN Controller
- REST/SOAP name your interface API
- Old style CLI 
- In this particular case it is sometimes a script that sets the binding. 

In fact, our experience is that every deployment has different need, different automation need. One may choose to use cloud formation template. 
So some of your questions below could nop. I think it will be good topic for discussion as well some presentation.

Once we separate out the classifier and SFF/SF then the set of interfaces are smaller (and the classifier complexity and richness can be tuned for the deployment. Yes it does support priority order, embedded script, app identification and all that in advanced form or it could as dumb as pkt matching acl in switch hw. I may need speed only sometimes). 

** [Med]Does your implementation allow to detect the liveness of SFs?
Yes it does. But do I need controller to do this, not always. This could have been built into the root of the chain, can be done from the SF proxy (if it is present, it often is). A SF able reply Hello doesn’t mean it is actually serving user traffic. The point of view from controller is not what a user traffic is going thru. However, a controller is the right place to provide a single view of whole chain.

On 1/24/17, 1:57 AM, "[email-masked]" <[email-masked]> wrote:

    Dear Sumandra, 

    

    Thank you.
    
    Cheers,
    Med