Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

From: "Ken Gray (kegray)" <[email-masked]>
Date: Tue, 8 Jul 2014 22:33:08 +0000

Hi, guys.

I found the document a little confusing (could be me).  I think you're
trying to describe elasticity, but I don't think it connects well.

A comment fairly common for the flurry of drafts that just came out Š your
SFIC is a new item not in any of the main documents.  If we're to expand
our lexicon even for local discussion, I think the term Component is
unnecessary.  Instance is fine.

In the definition and throughout the document, I think you mix simple
elasticity and the function of a load_balancer/ADC (an SFF with
non-publicly visible instances behind it) with directly addressable
instances of the same function as well as overlook anycast IP for
stateless functions.  So, your scenarios need to be much more explicit,
IMO, so they can be validated.

In section 4.1 the scenario described in "It is also possible to have
multiple identical SFICs attached to one Service Function Forwarder (SFF)
node, especially in a Network Function Virtualization (NFV)
environment where each SFIC is a virtual service function instance with
limited capacity." seems unlikely to me.  It seems that it would be more
likely that solution to the problem described would be to spawn the SFC
with more resources instead of more instances UNLESS you are getting down
to the ultimate resource limit of bandwidth out of a NIC (10G limit) in
which case you would probably drop back to a load balancing scenario?

A minor nit to the section " At the functional level, the order of service
functions, e.g.
Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which
SFIC of the Service Function "s1" is selected for the Chain #1 is not."
If it's a stateful function, it probably does matter.

On " The benefit of encoding the exact path in every data packet is less
contention when there the Service Chain Instance Path changes.", I would
have to say that the benefits I see in encoding the path are that the
traversed path is captured in the flow for debugging and other use and you
are passing metadata along with it (optionally).  I don't see how the path
encoding helps with contention if the path changes.  Can you explain what
you mean by contention and how this mitigates?

On " However, there are major drawbacks, such as
- extra packet header fields are needed to carry the exact
instance path, that can increase the likelihood of packet
fragmentation due to MTU size, and
- extra encapsulation processing load at the head end Service
Chain classifier node.", I'D venture that this is a bit speculative and
perhaps temporal (limited to some scenarios and the capabilities of
existing hardware).  We have endured header expansion and encapsulation
changes before, what makes this one so hard to cope with in the long term
or are you only talking about short term (in which case, is it major)?

For " Packet fragmentation and reassembly is very processor and memory
intensive. Good practice is to avoid packet fragmentation and
reassembly as much as possible. Carry an exact instance path in every
packet might be possible if service function instances can be
represented by compact labels, similar to the MPLS label stack.", I think
our our IPv6 brethren might find that a parochial view.

Generally, for most of section 4, it seems to me that the problems
described are essentially handled by elasticity controls, and abstraction
(e.g. anycast IP or a load balance function).  The entities are normally
managed (open source tools are available) in a feedback loop Š in short,
this is a very addressable and well known problem with existing products
and methodologies to mitigate, are you suggesting a unique solution or the
general scenario of how elasticity works Š if the latter, I think you need
to make that clear?

Section 5 displays the amount of detail that these simple abstractions
should actually hide from classification and that we made explicit example
of in earlier documents (these things shouldn't cause an explosion in the
number of discrete service chains).  That is kind of amplified in the
earlier text

 " If each Service Function has a large number of SFICs, it scales
better if the Service Chain classifier only identifies the service
chain at the functional level, and there is another entity managing
the detailed service instance path."

Can you explain this in more depth?  This is where I think you're actually
trying to describe what we discussed as "should be avoided and
unnecessary" Šthat is the explosion of paths in the face of elasticity.

Section 6, Are you talking about discretely addressable functions or non?
If non, and the SFF is responsible for "distribution", the numbering of
the instances is really irrelevant and is again a back end elasticity
function known only to the SFF Š and, to me, it's really unlikely that you
would track or move a discrete element from behind one SFF that provides
such a distribution function to another and still consider it the same
element.  Rather, it is "one of many".

On 7/4/14 4:48 PM, "Linda Dunbar" <[email-masked]> wrote:

>Hi, 
>
>This draft describes the framework of protection and restoration of
>   Service Chain Instance Path when some instances on the path fail or
>   need to be replaced.
>
>Appreciate to hear your comments or suggestions.
>
>Linda & Andy
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, April 30, 2014 11:25 AM
>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
>Subject: New Version Notification for
>draft-dunbar-sfc-fun-instances-restoration-00.txt
>
>
>A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt
>has been successfully submitted by Linda Dunbar and posted to the IETF
>repository.
>
>Name:		draft-dunbar-sfc-fun-instances-restoration
>Revision:	00
>Title:		Framework for Service Function Instances Restoration
>Document date:	2014-04-29
>Group:		Individual Submission
>Pages:		12
>URL:            
>http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-restora
>tion-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restoratio
>n/
>Htmlized:       
>http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00
>
>
>Abstract:
>   This draft describes the framework of protection and restoration of
>   Service Chain Instance Path when some instances on the path fail or
>   need to be replaced.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 12 Jul 2014 19:50:37 +0000

Ken,

Thank you very much for the comments and suggestions.

Replies are inserted below:

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 5:33 PM
To: Linda Dunbar; [email-masked]'
Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, guys.

I found the document a little confusing (could be me).  I think you're trying to describe elasticity, but I don't think it connects well.

A comment fairly common for the flurry of drafts that just came out Š your SFIC is a new item not in any of the main documents.  If we're to expand our lexicon even for local discussion, I think the term Component is unnecessary.  Instance is fine.

      [Linda] Thanks for the suggestion. I will use the "instance" instead. For a service function with different functional instantiations, e.g. one instantiation applies policy-set-A (NAT44-A) and other applies policy-set-B (NAT44-B), they are considered as two different service functions."

In the definition and throughout the document, I think you mix simple elasticity and the function of a load_balancer/ADC (an SFF with non-publicly visible instances behind it) with directly addressable instances of the same function as well as overlook anycast IP for stateless functions.  So, your scenarios need to be much more explicit, IMO, so they can be validated.

      [Linda] What is your definition of "simple elasticity"?
      On routers/switches, ECMP is commonly used to describe balancing among multiple links, whereas ADC have very different connotation, most often referring to balancing  based on L4-L7 context. Since SFF is more likely to be a forwarding device, I would prefer to avoid using "ADC" terminology to refer SFF balancing among  multiple instances of one same function directly attached. Those instances in the draft can be publicly visible. For the ones not publicly visible, it is internal decision with the SFF.

In section 4.1 the scenario described in "It is also possible to have multiple identical SFICs attached to one Service Function Forwarder (SFF) node, especially in a Network Function Virtualization (NFV) environment where each SFIC is a virtual service function instance with limited capacity." seems unlikely to me.  It seems that it would be more likely that solution to the problem described would be to spawn the SFC with more resources instead of more instances UNLESS you are getting down to the ultimate resource limit of bandwidth out of a NIC (10G limit) in which case you would probably drop back to a load balancing scenario?

      [Linda] The scenario in my mind is that there could be multiple vFW instances instantiated on VMs attached to a ToR (the SFF). Each vFW instance only has 1G throughput.
      Why it is not possible?

A minor nit to the section " At the functional level, the order of service functions, e.g.
Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which SFIC of the Service Function "s1" is selected for the Chain #1 is not."
If it's a stateful function, it probably does matter.

      [Linda] Thanks for pointing out this. For the stateful service function, I should add that the instances selected for a chain should not be changed for a flow.

On " The benefit of encoding the exact path in every data packet is less contention when there the Service Chain Instance Path changes.", I would have to say that the benefits I see in encoding the path are that the traversed path is captured in the flow for debugging and other use and you are passing metadata along with it (optionally).  I don't see how the path encoding helps with contention if the path changes.  Can you explain what you mean by contention and how this mitigates?

      [Linda] If the Controller sends the updated steering criteria for the updated instance path directly to the relevant SFF nodes, we might need a mechanism to guarantee that all relevant SFF nodes have installed the updated steering policies before packets arrive.

      Another approach is to drop packets (like MPLS FRR approach)until all SFF nodes complete installing the updated steering criteria.

On " However, there are major drawbacks, such as
- extra packet header fields are needed to carry the exact instance path, that can increase the likelihood of packet fragmentation due to MTU size, and
- extra encapsulation processing load at the head end Service Chain classifier node.", I'D venture that this is a bit speculative and perhaps temporal (limited to some scenarios and the capabilities of existing hardware).  We have endured header expansion and encapsulation changes before, what makes this one so hard to cope with in the long term or are you only talking about short term (in which case, is it major)?

For " Packet fragmentation and reassembly is very processor and memory intensive. Good practice is to avoid packet fragmentation and reassembly as much as possible. Carry an exact instance path in every packet might be possible if service function instances can be represented by compact labels, similar to the MPLS label stack.", I think our our IPv6 brethren might find that a parochial view.

Generally, for most of section 4, it seems to me that the problems described are essentially handled by elasticity controls, and abstraction (e.g. anycast IP or a load balance function).  The entities are normally managed (open source tools are available) in a feedback loop Š in short, this is a very addressable and well known problem with existing products and methodologies to mitigate, are you suggesting a unique solution or the general scenario of how elasticity works Š if the latter, I think you need to make that clear?

      [Linda] What do you mean by "elasticity controls"?  When multiple instances are attached to different SFFs, it is "global LB".

Section 5 displays the amount of detail that these simple abstractions should actually hide from classification and that we made explicit example of in earlier documents (these things shouldn't cause an explosion in the number of discrete service chains).  That is kind of amplified in the earlier text

 " If each Service Function has a large number of SFICs, it scales better if the Service Chain classifier only identifies the service chain at the functional level, and there is another entity managing the detailed service instance path."

Can you explain this in more depth?  This is where I think you're actually trying to describe what we discussed as "should be avoided and unnecessary" Šthat is the explosion of paths in the face of elasticity.

Section 6, Are you talking about discretely addressable functions or non?
If non, and the SFF is responsible for "distribution", the numbering of the instances is really irrelevant and is again a back end elasticity function known only to the SFF Š and, to me, it's really unlikely that you would track or move a discrete element from behind one SFF that provides such a distribution function to another and still consider it the same element.  Rather, it is "one of many".

On 7/4/14 4:48 PM, "Linda Dunbar" <[email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
>[email-masked]<mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Sat, 12 Jul 2014 22:22:53 +0000

Linda,

I think you are expressing some assumptions around SFF that are definitely shared by some, but not all of the participants on this thread:

"The scenario in my mind is that there could be multiple vFW instances instantiated on VMs attached to a ToR (the SFF)"

It is totally natural that all of us bring different assumptions and perceptions to the problem space and this is why we have these lengthy but ultimately constructive threads :).

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Saturday, July 12, 2014 3:51 PM
To: Ken Gray (kegray); Linda Dunbar; [email-masked]'
Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Ken,

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]]
Sent: Tuesday, July 08, 2014 5:33 PM
To: Linda Dunbar; [email-masked]'
Subject: Re: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, guys.