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

From: <[email-masked]>
Date: Wed, 25 Jan 2017 07:58:02 +0000

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.  

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

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

 I thought the classifier was supposed to be where complex
> matching logic runs, with the SFF being a simple forwarder. If we allow
> the SFF to run complex matching logic,
>  (i.e. if this condition, then take this next hop), is it not really
> acting as a classifier or reclassifier?
> 
> To be clear, RFC 7665 states:
> 
> 	"A service function forwarder is
> 	responsible for forwarding traffic to one or more connected
> 	service functions according to information carried in the SFC
> 	encapsulation"
> 
> I do not think that the packet size, for example, is a property of the
> encapsulation. As such, I do not think C2 should carry this type of
> information.

[Med] An SFF executes forwarding actions following the instructions contained in its SFC Forwarding Policy Table. An SFF can forward based on instructions that are compliant with its capabilities. The CP is required to be aware of what an SFF is capable to do priori to programming the forwarding table or to enable some protocols (e.g., PCE).  The draft is clear about this:

   An SFF node may not support some of the matching criteria listed
   above.  It is important that SFC control plane can retrieve the
   supported matching criteria by SFF nodes.  

> 
> Building on that point, section 4.10.4 states:
> 
> 	"The matching criteria for SFF can be more sophisticated.  For
> 	example, it could be the SFP-id carried within the SFC encapsulation
> 	with any fields in the data packets, such as (non-exhaustive list)"
> 
> As with my comment in 3.3.3, I don't like the statement that any field in
> the data packet can be used to qualify the next hop. It really should come
> entirely from the encapsulation. That encapsulation *could* very well be
> an IP header. However, we should be clear about that.

[Med] This text was the result of WG discussion. As an editor of the document, I can change the text as you propose if there is no objection from the WG.

> 
> Now, I could see using the information listed here to make a decision as
> to which specific instance of an SF to send the packet to, for example
> when load-balancing. However, it does not seem  correct to choose the next
> service function (e.g. Firewall vs content cache) based packet data.
> 
> I have a few more nits/concerns. I can send them in a separate email
> thread once we've worked through this one.

[Med] Please share those. 

> Thanks!
> Kyle

---

From: Kyle Larose <[email-masked]>
Date: Mon, 30 Jan 2017 14:59:28 +0000

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,
> 
> > De : Kyle Larose [mailto:[email-masked]] Envoyé : mardi 24
> > janvier 2017 17:32 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked]
> > 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. :)
> >
> [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, 

> Of course, those cases may be implemented without involving the
> classifier by invoking C2 as recorded in Section 3.3.2:
> 
> > 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?
> 
> > 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:
> * 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?
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. 

> >
> >
> > Further, section 3.3.3 has an example of something belonging in
> C1,
> > but not C2:
> >
> > 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, or somehow indicate that it wants reclassification (for example, via metadata). 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. :)

> > matching logic runs, with the SFF being a simple forwarder. If we
> > allow the SFF to run complex matching logic,  (i.e. if this
> condition,
> > then take this next hop), is it not really acting as a classifier
> or
> > reclassifier?
> >
> [Med] An SFF executes forwarding actions following the instructions
> contained in its SFC Forwarding Policy Table. An SFF can forward
> based on instructions that are compliant with its capabilities. The
> CP is required to be aware of what an SFF is capable to do priori to
> programming the forwarding table or to enable some protocols (e.g.,
> PCE).  The draft is clear about this:
> 
> > As with my comment in 3.3.3, I don't like the statement that any
> field
> > in the data packet can be used to qualify the next hop. It really
> > should come entirely from the encapsulation. That encapsulation
> > *could* very well be an IP header. However, we should be clear
> about that.
> 
> [Med] This text was the result of WG discussion. As an editor of the
> document, I can change the text as you propose if there is no
> objection from the WG.

[Kyle] I guess this point was a little bit of a nitpick, since I'm really complaining about the language. I'd like to see it change to fit my interpretation of 7665. That said, if my interpretation is wrong, feel free to keep it as is.

> 
> >
> > Now, I could see using the information listed here to make a
> decision
> > as to which specific instance of an SF to send the packet to, for
> > example when load-balancing. However, it does not seem  correct to
> > choose the next service function (e.g. Firewall vs content cache)
> based packet data.
> >