Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/

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

Hi Kyle, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Kyle Larose [mailto:[email-masked]]
> Envoyé : lundi 30 janvier 2017 15:59
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : RE: Some comments on draft-ietf-sfc-control-plane/
> 
> Hey Med, sorry for taking so long to get back to you. The last few days
> have been fairly hectic for me.
> 
> Please see inline.
> 
> Thanks,
> 
> Kyle
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Wednesday, January 25, 2017 2:58 AM
> > To: Kyle Larose
> > Cc: [email-masked]
> > Subject: RE: Some comments on draft-ietf-sfc-control-plane/
> >
> > Hi Kyle,
> >
> > Thank you for the comments.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Kyle Larose [mailto:[email-masked]] Envoyé : mardi 24
> > > janvier 2017 17:32 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked]
> > > Objet : Some comments on draft-ietf-sfc-control-plane/
> > >
> > > Hello Mohamed,
> > >
> > >
> > > I'm starting to look into developing a control plane protocol for
> > > classifiers (C1 in the draft), so I've taken a look at the sfc
> > control
> > > plane draft. I have a few comments on it. I'll start with the
> > issue
> > > that stood out the most for me.
> > >
> > > First, thanks for authoring this draft. It definitely captured a
> > bunch
> > > of concepts and ideas that I'll need to think about.
> >
> > [Med] Thanks.
> >
> > >
> > > Back to the issue: after reading through the document, I had some
> > > concerns regarding separation of responsibility among the
> > interfaces.
> > > In particular, some information and actions, which I felt belonged
> > in
> > > C2 were in C1, and vice versa. I used the SFC Architecture, RFC
> > 7665,
> > > as a guide in deciding which interface should be responsible for
> > what.
> > > My concerns could be based entirely on my narrow interpretation of
> > it.
> > > Please let me know if I've taken too narrow a view. :)
> > >
> > > As an example of something belonging in C2, but not C1:
> > >
> > > 	Section 3.3.1:
> > > 	" The classifier may be notified (regularly or upon eventual
> > change)
> > > by
> > > 	the control plane about the available SFs (including the SFFs
> > they
> > > 	are attached to) or be part of the service function discovery
> > > 	procedure.
> > > 	"
> > >
> > > What is the purpose behind this?
> >
> > [Med] This is an **optional** feature that was requested by the WG
> > participants to support an SFC distributed model (Ron may further
> > elaborate as he asked for it). For example, this feature allows a
> > classifier to bind flows as a function of the available paths and SF
> > instances. Then, packets can be bound to a fully or partially
> > constrained path accordingly. Also, the discovery information
> > provided to a classifier may be used for load distribution purposes.
> >
> 
> [Kyle] I didn't really think of that use-case. The load distribution one
> in particular is interesting.
> I see the classifier as a mapper of packets to paths, so I've been
> thinking of C1 as an interface for mapping packet information to paths.
> Mapping packets to service functions and from there to paths seems like a
> higher level concept. On the one hand, I think that keeping C1 purely
> about "packet -> path" will lead to simpler protocols. On the other hand,
> to allow the use-case you suggested, we'd need to add new interfaces, and
> as you've said below, you don't really want to do that.
> 
> But, I could ask this: if we constrain C1 to talk about only "packet ->
> path", then it can probably be fairly well defined, and it should be easy
> to reason about. However, if we relax it to allow other information such
> as service functions just to support a few use-cases, why not relax it to
> allow all information that could be relevant to SFC? I'm sure some smart
> people could think of many use cases for that. Then again, as I say below,
> I could very well just be approaching this document from the wrong
> perspective entirely,
> 

[Med] Your observation are really fair one. As an individual, I'm for restricting the classifier to the "packet/flow==>path", but as an editor of the document I integrated comments from the WG participants that wanted to have such feature included as optional one.   

> > Of course, those cases may be implemented without involving the
> > classifier by invoking C2 as recorded in Section 3.3.2:
> >
> >   " This interface is also used by the SFF to report the
> > connectivity to
> >    their attached (including embedded) SFs.  Local means may be
> > enabled
> >    between the SFC-aware SFs and SFFs to allow for the dynamic
> >    attachment of SFs to an SFF and/or discovery of SFs by an SFF"
> >
> >
> >  Given that the classifiers are not
> > > conceptually "attached" to SFs on the data plane, doesn't it seem
> > > wrong to have the classifiers be aware of the SFs on the control
> > plane?
> >
> > [Med] See above. The idea is to allow for a distributed model to
> > adjust paths (and implement other policies at the classifier).
> >
> > > I understand the classifiers may be co-located with SFs, but I
> > don't
> > > see how their functionality would, or should, depend on the
> > > availability of SFs in the data plane.
> >
> > [Med] The SF/SFF discovery information is not MANDATORY to be
> > provided to a classifier, but may help in some deployment cases
> > (such as those mentioned above).
> >
> > >
> > > One use-case I could see for this is having the classifier map a
> > > packet to an explicit set of SFs. However, the classifier maps
> > packets
> > > to paths, not SFs. Should the logic of mapping of packet to an SF
> > not
> > > be performed by conjoining C1 and C2 at the controller itself?
> >
> > [Med] That's indeed possible. See the excerpt of Section 3.3.2
> > provided above.
> >
> >  Using C1 to indicate SF
> > > mapping seems to blur the lines between C1 and C2.
> > >
> > > After writing the above, I saw section 4.10.2. It seems to kind of
> > > match what I proposed above. But, I still ask: is this truly the
> > > responsibility of the classifier, or something which may be co-
> > located
> > > with it? If the latter, should it not be a different interface?
> >
> > [Med] Good point. We can always decompose a single interface into a
> > set of interfaces following some functional rationale, but the
> > reasons why I prefer to not add a new one are the following:
> > * Maintain the SFC control plane architecture as simple as possible.
> > * How a classifier decides to bind flows/packets to a given chain is
> > completely policy-based and deployment-specific. There may be simple
> > policies that do not require a feedback from the SFC-enabled domain
> > (e.g., blindly bind a flow to a chain based on the transport
> > coordinates) and advanced policies that require additional
> > information to be enforced (e.g., bind a flow to a chain as a
> > function of available paths, bind a flow to a chain as a function of
> > available SF instances, bind a flow to a chian while avoiding to
> > cross a given network region, etc.).
> >
> 
> [Kyle] I guess one of my challenges here is that I'm thinking as a
> protocol developer, and I'm seeing stuff I would never want to put into my
> protocol.
> So, maybe I just need to think of this from a different perspective.
> Rather than saying what must or must not be in a protocol implementing C1,
> this document is just providing suggestions and things to think about?

[Med] The document calls out things that must be supported and others that are "nice to have".

> My concern is that if this is actually trying to put down requirements for
> a set of protocols implement C1, a large number of optional requirements
> aren't really going to provide a lot of guidance.
> 

[Med] Perhaps, the WG needs to check the language to make sure that must/should/may are really justified for each item.  

> > >
> > >
> > > Further, section 3.3.3 has an example of something belonging in
> > C1,
> > > but not C2:
> > >
> > > 	" SF execution status: Some SFs may need to send information
> > to the
> > >  	control plane to fine tune SFPs.  For example, a threat-
> > detecting
> > >   	SF can periodically send the threat characteristics via this
> > >   	interface, such as high probability of threat with packet of a
> > >   	given size.  The control plane can then add an appropriate
> > >   	matching criteria to SFF to steer traffic to a scrubbing
> > center."
> > >
> > > Should this information not be fed back to the classifier via C1,
> > > rather than C2?
> >
> > [Med] It can of course! Please note that the text starts with "For
> > example, ". If the decision is to use a distinct service path, then
> > a classifier is likely to be invoked by means of C1. But if the
> > entity managing the SFC domain does not want to alter the service
> > path, a local policy can be provisioned to an SFF via C2 to redirect
> > subsequent packets to a scrubbing center.
> >
> 
> [Kyle] Is it not altering the path, though? It feels like we're just
> defining a path through a sideways channel -- we're moving a packet to a
> path which isn't specified through the normal mechanisms. If it were
> specified normally, I.e. through classify in C1, specify forwarding logic
> in C2, then the SF could just reclassify the packet,

[Med] An SF cannot reclassify a packet.

 or somehow indicate
> that it wants reclassification (for example, via metadata).

[Med] Yes, but this would require that a classifier will be on path upstream... and immediately after that SF's service is consumed. 

 This
> reclassification would not alter the previous path of the packet, since
> the new path already existed. In that case, C2 would just need to allow
> for indicating the information that would lead to reclassification, and
> the complex packet information necessary to do the classification could be
> transmitted in C1. Of course, perhaps the information I'm suggesting being
> indicated in C2 is no less complicated than what is being moved to C1. :)

[Med] :)

---

From: Ron Parker <[email-masked]>
Date: Fri, 17 Feb 2017 19:23:06 +0000

Kyle,

The partially constrained service path concept is a companion to the Rendered Service Path (RSP) concept.   Only RSP is guaranteed to be fully specified.    The whole concept allows for distributed load balancing and late binding of the RSP.    If the SFP allows for this loose binding, then an SFF is expected to choose amongst an eligible (policy wise) SF instance.    Another property of this allowed behavior is the ability to perform local repair of failures.   An SFF that hosts multiple instances of an SF and is allowed to make the selection is therefore also allowed to choose an alternate upon failure detection.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 17, 2017 1:33 AM
To: Kyle Larose <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] Some comments on draft-ietf-sfc-control-plane/

Hi Kyle, 

Please see inline. 

Cheers,
Med

> De : Kyle Larose [mailto:[email-masked]] Envoyé : lundi 30 
> janvier 2017 15:59 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked] 
> Hey Med, sorry for taking so long to get back to you. The last few 
> days have been fairly hectic for me.
> 
> Please see inline.
> 
> Thanks,
> 
> Kyle
> 
> [Kyle] I didn't really think of that use-case. The load distribution 
> one in particular is interesting.
> Mapping packets to service functions and from there to paths seems 
> like a higher level concept. On the one hand, I think that keeping C1 
> purely about "packet -> path" will lead to simpler protocols. On the 
> other hand, to allow the use-case you suggested, we'd need to add new 
> interfaces, and as you've said below, you don't really want to do that.
> 
> But, I could ask this: if we constrain C1 to talk about only "packet 
> -> path", then it can probably be fairly well defined, and it should 
> be easy to reason about. However, if we relax it to allow other 
> information such as service functions just to support a few use-cases, 
> why not relax it to allow all information that could be relevant to 
> SFC? I'm sure some smart people could think of many use cases for 
> that. Then again, as I say below, I could very well just be 
> approaching this document from the wrong perspective entirely,
> 

> protocol developer, and I'm seeing stuff I would never want to put 
> into my protocol.
> Rather than saying what must or must not be in a protocol implementing 
> C1, this document is just providing suggestions and things to think about?

> My concern is that if this is actually trying to put down requirements 
> for a set of protocols implement C1, a large number of optional 
> requirements aren't really going to provide a lot of guidance.
> 

> defining a path through a sideways channel -- we're moving a packet to 
> a path which isn't specified through the normal mechanisms. If it were 
> specified normally, I.e. through classify in C1, specify forwarding 
> logic in C2, then the SF could just reclassify the packet,

 or somehow indicate

 This
> reclassification would not alter the previous path of the packet, 
> since the new path already existed. In that case, C2 would just need 
> to allow for indicating the information that would lead to 
> reclassification, and the complex packet information necessary to do 
> the classification could be transmitted in C1. Of course, perhaps the 
> information I'm suggesting being indicated in C2 is no less 
> complicated than what is being moved to C1. :)

[Med] :)

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