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

From: <[email-masked]>
Date: Fri, 17 Feb 2017 06:54:33 +0000

Hi Sumandra, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Sumandra Majee [mailto:[email-masked]]
> Envoyé : mercredi 1 février 2017 03:56
> À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; [email-masked]
> Objet : Re: [sfc] How to progress our control plane requirements document
> 
> 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)

[Med] Great! BTW, the sfc-control document does not call for a single central entity; section 3.2 says: 

   The SFC control plane can be (logically) centralized, distributed or
   a combination thereof.  Whether one or multiple SFC Control Elements
   are enabled is deployment-specific.  

 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.

[Med] Fair comment. 

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

[Med] Agree. This is really deployment-specific.

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

[Med] Thank you for sharing the information. What you described is aligned with the current expected behavior included in the CP requirements draft: 

* "I need controller to do this"    

   In particular, the control plane must allow to dynamically detect
   that an SF instance is out of service and notify the relevant Control
   Element accordingly.  The liveness information may be acquired
   directly from SFs or indirectly from other management and control
   systems in the operational environment.

* ".., not always"

   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.

 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.

[Med] Fully agreed. This is the intent of this text in the draft: 

   Because a node embedding an SF can be responsive from a reachability
   standpoint (e.g., IP level) while the function it provides may be
   broken (e.g., a NAT module may be down), additional means to assess
   whether an SF is up and running are required.  These means may be
   service-specific.

 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.

[Med] Agree. 

[Med] Thank you for your kind answer. This is exactly the discussion I was seeking fro when I sent this set of questions. None of the points you provided and those in my initial set of questions are covered in other SFC documents. I do still think there is a need to have those covered and a common understanding of the expected behavior described.

* 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?
* ...

---

From: <[email-masked]>
Date: Fri, 17 Feb 2017 14:15:25 +0000

Hi Eric, 

Thank you for sharing your thoughts. 

I have comments to some of the points you mentioned in your message, but I will reply to only one of them. 

You said, "These reference points do not correspond to anything real.". I'm afraid I disagree here. If you take for example, the interface to classifiers, this is something that exists even in current deployments. Think about PCRF/PCEF in a 3GPP PCC architecture and the like. 

I have no problem to abandon the draft if this is what the WG wants, but I'm afraid we need a document to define the minimum set of capabilities to be honored by a solution that claims to address SFC control. 

For example, I checked your BGP CP draft to check if it addresses the CP requirement in the SFC CP draft. Many of these CP requirements are included in your proposal but many others are missing, e.g.,

* I don't see how classification rules are installed/removed/updated.
* I don't see any features to associate classification and forwarding entries with validity lifetime.
* I don't see how the CP sets the SI at classifiers
* I don't see how the CP set the semantic of a metadata per each chain, scope, etc.
* I don't see how the CP indicates the behavior to follow when a metadata is consumed
* I don't see how an SFC proxy in instructed to insert/supply metadata on behalf of SFC-unaware SFs
* I don't see the CP behavior when an SF is to be withdrawn
* I don't see how an SFC proxy is instructed about the SFs to service.
* Etc. 

Thank you.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Eric C Rosen
> Envoyé : mardi 31 janvier 2017 20:16
> À : Joel M. Halpern; [email-masked]
> 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.
> 
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Feb 2017 11:29:15 -0500

Med, let me try to restate the point Eric and others made in the 
interim, which the chairs and ADs consider cogent.

Yes, the BGP control plane draft perfroms some of the functions you 
identify.  It provides a coherent piece of a control plane solution. 
This (the BESS SFC draft) does not attempt to solve all control plane 
problems for SFC.  And we would not expect it to.

The result is that there is no meaningful question we can ask of the 
BESS SFC draft using the existing control plane document reference 
points.  It does not provide all of C1, C2, C3, or C4.  Once we looked 
at that, we realized that any given protocol effort on the control plane 
side was likely to run into the same thing.

The purpose of the control plane requirements document, as we understand 
it, is not to tell the SFC WG or SFC dta plane implementors what they 
need to implement to talk to control.  it is to tell control protocl 
designers and implementors what they need to provide, in terms of 
capabilities, to have solutions that work with SFC.  Therefore, the 
decomposition in the control plane document needs to correspond to a 
meaningful grouping in the control plane.

If all we have is a list of requriements that control plane efforts have 
to pick and choose among, it will not help them any.
That may mean that we have no useful way to present these points.  That 
would be unfortunate.
But we need to avoid pretending something is useful when we have been 
told multiple times that it is not.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Feb 2017 16:30:19 -0000

Hi Med,

I'm not convinced that this draft should address the CP requirements in your
draft. It seems more important to build a functional system(i.e., one that works
and delivers the operational function that makes an SFC network work).

Therefore, in reviewing the draft it may be more helpful to say:
- this doesn't work
- I need to achieve this function
- this could be done better.

But for completeness, here are some answers to your points:

> For example, I checked your BGP CP draft to check if it addresses the CP
> requirement in the SFC CP draft. Many of these CP requirements are included in
> your proposal but many others are missing, e.g.,
> 

Section 7.5

> * I don't see any features to associate classification and forwarding entries
with
> validity lifetime.

I don't believe this to be a useful feature.
But it could be added at some point.

> * I don't see how the CP sets the SI at classifiers

Section 7.5

> * I don't see how the CP set the semantic of a metadata per each chain, scope,

It would be premature to define a control plane for something that hasn't been
properly specified in the forwarding plane.
But it seems to me that most SFs will not be so programmable: they will look for
specific TLVs in metadata and ignore (forward) the rest, and they will add
specific TLVs to the metadata.
Sending CP messages will not change the behavior of SFs in this regard.
Attempting to do so would be adding unnecessary complexity to the system.

> * I don't see how the CP indicates the behavior to follow when a metadata is

Ditto the above only more so!
An SF is an SF and is not CP-programmable.

> * I don't see how an SFC proxy in instructed to insert/supply metadata on
behalf
> of SFC-unaware SFs

An SFC proxy is, in that respect, no different from the metadata component of an
SF that can handle metadata.

But you *have* pointed to an interesting "hole" in the architecture if it is
assumed that the SFC proxy can somehow know about the state in the SFC-unaware
SF and shape metadata accordingly.

> * I don't see the CP behavior when an SF is to be withdrawn

I don't even know what it means to "withdraw an SF". 
Do you mean "to take an SFI gracefully out of service"? If so, you would simply
withdraw the SFIR and the route would go (as is normal in BGP).
Or do you mean "to remove an SF from an SFP"? If so, 4.5.1.

> * I don't see how an SFC proxy is instructed about the SFs to service.

Are you asking how a proxy that severs more than one SF knows to which SF to
route packets?
If you are, then my answer is "don't do that!" Proxies are cheap. You can
virtualise a proxy at any location. 

> * Etc.

See section, oh... :-)

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 20 Feb 2017 07:20:31 +0000

Hi Joel, 

I'm not defending the draft in its current form; that is evident.

In the meantime, I'm still convinced there is a need to have a document to capture what the SFC WG expects from the CP designers. 

Cheers,
Med

> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : vendredi 17 février 2017 17:29
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> > You said, "These reference points do not correspond to anything real.".
> I'm afraid I disagree here. If you take for example, the interface to
> classifiers, this is something that exists even in current deployments.
> Think about PCRF/PCEF in a 3GPP PCC architecture and the like.
> >
> > I have no problem to abandon the draft if this is what the WG wants, but
> I'm afraid we need a document to define the minimum set of capabilities to
> be honored by a solution that claims to address SFC control.
> >
> requirement in the SFC CP draft. Many of these CP requirements are
> included in your proposal but many others are missing, e.g.,
> >

---

From: <[email-masked]>
Date: Mon, 20 Feb 2017 07:26:32 +0000

Hi Adrian,

Please see inline.

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : vendredi 17 février 2017 17:30
> À : BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. Halpern';
> [email-masked]
> Objet : RE: [sfc] How to progress our control plane requirements document
> 
> Hi Med,
> 
> draft. 

[Med] That's fine by me. It is perfectly fine to address a subset of requirements, but what I'm less comfortable with is to call a proposal (The) "Control plane for SFC".

It seems more important to build a functional system(i.e., one that
> works
[Med] I confess this wasn't my perspective when reading the mackie draft.  

> included in
[Med] Sorry. Thank you for the pointer.

> I don't believe this to be a useful feature.

[Med] Programming a state that is not limited in time may be a source of troubles from a manageability standpoint. Means to help the classifier to automatically clean its table without an explicit action from a third party (controllers) are useful, IMO.    

> But it could be added at some point.
[Med] Sure. BGP is powerful enough :) 

> > * I don't see how the CP set the semantic of a metadata per each chain,
> scope,
> > etc.
> 

[Med] I understand your argument about the weakness of the DP plane spec in this regards, but I do think that is (hopefully) fixed with the new text (https://trac.ietf.org/trac/sfc/ticket/21) 

> specific TLVs to the metadata.

[Med] I don't know what is/will be a default behavior of an SFC-ware SF. For example, I don't see based on which criteria a CGN or firewall SF will decide that it must look for particular TLVs. Also, I don't see based on which criteria a classifier implementation will decide to inject a given set of TLVs, etc. There is a void that needs to be fulfilled by the CP.

> Sending CP messages will not change the behavior of SFs in this regard.
[Med] There is a need to communicate SFC instructions to underlying SFC-aware nodes. 

> > * I don't see how the CP indicates the behavior to follow when a
> metadata is
> > consumed
> 

[Med] We are not talking about SFs in general, but about SFC-aware SFs. Of course, SF-specific control is not of interest here. 

> SF that can handle metadata.

[Med] ... except that the proxy does not know what TLVs are to be inserted/stripped/modified per attached SF (and per chain). 

> I don't even know what it means to "withdraw an SF".

[Med]  What I meant is, for example, when an SF is decommissioned or when now instance is available to deliver the service. Does the solution allows to maintain the installed SFPs but with a bypass of that SF or it imposes to reinstall new paths.   

> Are you asking how a proxy that severs more than one SF knows to which SF

[Med] This is more about checking that only entitled SFs are authorized to be serviced by a proxy.

> virtualise a proxy at any location.

[Med] Will read that section SOON ;-)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Feb 2017 09:22:46 -0500

Thank you Med.

Speaking personally, I would like to see a document that captures these 
expectations.  And I appreciate the efforts you have put in to try to 
achieve that.

The challenge I see is finding an effective structuring for that document.

So I am hoping for engagement from others here with ideas on how to 
structure such a document.  (I hate saying 'problem' without being able 
to suggest a path forward, but in this case, that is where I find myself.)

Yours,
Joel

---

From: Sumandra Majee <[email-masked]>
Date: Thu, 23 Feb 2017 02:18:33 +0000

[SM] The API and associated information element should be part of *a* document. I don't think one can capture all the possibilities in oe single document anyway.

________________________________
From: sfc <[email-masked]> on behalf of Eric C Rosen <[email-masked]>
Sent: Tuesday, January 31, 2017 11:15:30 AM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] How to progress our control plane requirements document