Subject: Re: [sfc] SFC encapsulation chain ID

From: "[email-masked]" <[email-masked]>
Date: Tue, 1 Apr 2014 18:50:16 -0400

In this case, it is still a hop.  The LB VM still has to process (and "balance") the packets, which incurs a larger penalty than the 500ns (or so) of a physical network hop.  Additionally, the "hop" that you say is mitigated is only mitigated if you colocate all of the VMs behind a LB instance with the LB itself, which is not very elastic, requiring one to create multiple instances of LBs for the same SF, which requires either having instances chosen by an SFC classifier (which you are trying to avoid) or introducing a LB in a different location to balance between multiple local LBs (fronting the SF VM instances), which simply re-introduces the hops that you were trying to mitigate in the first place.  I suppose you could implement this in such a way that you had a LB in front of your SFC Classifier, but I'd have to wrap my head around that some more to see if it even makes sense.  Either way, I don't think this solves what you think it solves.

Why can't we simply say that the SFC classifier chooses the SFC Path (specific SF instances) and as a matter of implementation, if you would like, you may construct your chain to be a chain of SF LBs, each with a single instance?  That would allow you to scale at the cost of the incremental latency that inherently comes with scaling, but also allow a smaller implementation to forgo the LBs and perform the distribution function at the Classifier.

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>,Ron Parker<[email-masked]>,Joel Halpern Direct<[email-masked]>,Joel M. Halpern<[email-masked]>,Erik Nordmark<[email-masked]>,Kevin J Ma<[email-masked]>,Dave Dolson<[email-masked]>,Sumandra Majee<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Wednesday, March 26, 2014
Subject: Re: [sfc] SFC encapsulation chain ID

Hops can be mitigated by running the LB in the same location as those SF VMs 
The connection from LB to those SF VMs is local, not hops. 

Cathy

-----Original Message-----

From: NAPIERALA, MARIA H [mailto:[email-masked]] Sent: Wednesday, March 26, 2014 10:57 AMTo: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra MajeeCc: [email-masked]: RE: [sfc] SFC encapsulation chain ID> > If case 1 poses a scalability problem (eg. there are hundreds of VMs> for a service function), the scalability issue can be solved by> transforming case 1 into case 2> through placing a local LB before these VMs and only the LB is viewed> in the chain. Introducing additional hop is a service chain translates to delay and cost. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain becomes 10-hop chain. In fact, if the LB is a virtual appliance it might have similar scalability issue as the original SF.> In some other deployment scenario, case 1 might not pose> a scalability issue, and> thus solution/architecture wise, we should not exclude case 1. To put> it another way, case 1 is only usable in small-scale scenario.> > Cathy> > -----Original Message-----> From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H> Sent: Wednesday, March 26, 2014 8:48 AM> To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark;> Kevin J Ma; Dave Dolson; Sumandra Majee> Cc: [email-masked]> Subject: Re: [sfc] SFC encapsulation chain ID> > Ron,> > I would consider a solution which scales only with assumptions 2. and> 3. (clusters with internal LB) as limited.> > Maria> > > -----Original Message-----> > From: Ron Parker [mailto:[email-masked]]> > Sent: Wednesday, March 26, 2014 11:44 AM> > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; Erik> > Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee> > Cc: [email-masked]> > Subject: RE: [sfc] SFC encapsulation chain ID> >> > Maria,> >> > I agree with you that case 1. will only practically scale up to some> > point.    Perhaps, as a service provider, you'd choose to avoid the> > whole problem and only deploy service functions along the lines of> case> > 2 or case 3.    But, that doesn't invalidate the utility of case 1> for> > some other network with some other requirements and constraints.> >> >    Ron> >> >> > -----Original Message-----> > From: NAPIERALA, MARIA H [mailto:[email-masked]]> > Sent: Wednesday, March 26, 2014 11:39 AM> > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark;> > Kevin J Ma; Dave Dolson; Sumandra Majee> > Cc: [email-masked]> > Subject: RE: [sfc] SFC encapsulation chain ID> >> > >> > > 1.  A service function is realized by multiple VM's where each VM> has> > > its own IP address.   In this case the classifier/PDP sees each VM> as> > a> > > service function instance.> > >> >> > I don't think this will scale. It was pointed out that the number of> > service paths grows exponentially.> >> >> > > 2. A service function, as above, but some subset of VM's is front-> > ended> > > by a load balancer.   There are multiple such subsets and therefore> > > multiple load balancers.   Each load balancer has its own IP> address> > > and hides the VM IP addresses behind it.   In this case, the> > > classifier/PDP sees each load balancer as a service function> > instance.> >> > No issue here.> >> > > 3.  A service function is realized by a set of VM's that perform> > > internal load balancing.   The set of VM's presents a single IP> > address> > > to the outside to hide the IP addresses of the individual VMs.> The> > > network has multiple such clusters.   The classifier/PDP sees each> > > cluster as a service function instance.> >> >> >> > >> > >> > > -----Original Message-----> > > From: NAPIERALA, MARIA H [mailto:[email-masked]]> > > Sent: Wednesday, March 26, 2014 11:17 AM> > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J> Ma;> > > Ron Parker; Dave Dolson; Sumandra Majee> > > Cc: [email-masked]> > > Subject: RE: [sfc] SFC encapsulation chain ID> > >> > > Joel,> > >> > > > The point of the distinction was between on the one hand load> > > > balancing as part of the chain for the purpose of selecting an> > > > instance of the actually addressed destination (i.e. the load> > > balancer> > > > is visible to the tenant and is there for the purpose the tenant> > > > request; and on the other hand a load balancer which is known to> > the> > > > service chaining infrastructure, but whose purpose to balance> > across> > > > isntances of services whose multiplicity is not of concern to the> > > > tenant, only the functionality.> > > >> > > > Put differently, it is between load balancing as an explicit> > service> > > > and load balancing to enable some service within the service> > > chaining.> > > >> > >> > >> > > Thanks for clarification.> > > My concern is about the latter, i.e., SFC solution must support> load> > > balancing to multiple service instantiations (e.g., VMs) of a> single> > > service at the intermediate service hops. In fact, we need the> latter> > > to support the former..> > >> > > Maria> > >> > > >> > > > On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote:> > > > >> > > > >> 1) given the range of load balancing behaviors, supprting> > > > >> explicit> > > > load> > > > >> balancers in the service chaining (as distinct from supporting> > > load> > > > >> balancers for end users), is significantly complicate> > > > >> > > > > I am not sure I understand this point. Could you explain what> you> > > > mean by "explicit" load balancer vs. load balancer "for the end> > > users"?> > _______________________________________________> sfc mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Apr 2014 16:33:56 -0700

On 3/26/14 8:43 AM, NAPIERALA, MARIA H wrote:
> The issue is scaling service chaining where many (potentially 100's) of instances of a single service are present and where there is no internal load balancing per service function.
> Is this being addressed in the SFC?

Maria,

I think SFC can at best address a subset of that problem space.

The SF might contain operational/run-time state tied to a particular 
flow/subscriber/tenant. The details of how such state is checkpointed or 
shared between different instances of the SF (e.g., for HA) is out of 
scope of SFC AFAIK.

In some cases the rules for which packets need to be sent to which 
instances (that has the above state) can be expressed in the SFC 
classifier, but in other cases it might not. (In the old web world we 
had cases like HTTP cookies in SSL encrypted traffic - a load balancer 
needed to be a SSL termination point to be able to use the HTTP cookie 
to choose the server. I don't know if there are similar cases in NfV 
which would require something more than DPI to do correct load balancing.)

SFC should be able to handle 100's of instances, but if the SFC needs to 
respond to the actual load on the instances, then some additional 
protocol mechanisms (with scaling considerations) might be needed. 
Sending 1/100 of flows/subscriber to each instance can be done by SFC in 
isolation, but if different flow's/subscriber's packets generate 
radically different load on the instances that might not be sufficient. 
For instance, the SF instances might need to report their load to the 
SFC load balancer.

Regards,
    Erik

> Maria
>> From: Joel M. Halpern [mailto:[email-masked]]
>> Sent: Wednesday, March 26, 2014 11:25 AM
>> To: NAPIERALA, MARIA H; Erik Nordmark; Kevin J Ma; Ron Parker; Dave
>> Dolson; Sumandra Majee
>> Cc: [email-masked]
>> Given that we have mechanisms which allow service functions to direct
>> modification of the service chain identification (preferably through
>> metadata, but that is still under discussion) then it follows that the
>> current proposals allow a load balancer which directs the chaining, and
>> which modifies the packet if needed to affect external targeting.
>>
>> While I would prefer and expect that to be rarely used, it is allowed.
>> And I do not expect the documents to express a preference (for or
>> against my personal preference.)
>>
>> Given that you agree that we can also do internal load balancing, I
>> don't understand what changes you are requesting.
>>
>> Yours,
>> Joel
>>
>> On 3/26/14, 11:16 AM, NAPIERALA, MARIA H wrote:
>>> Joel,
>>>
>>>> The point of the distinction was between on the one hand load
>> balancing
>>>> as part of the chain for the purpose of selecting an instance of the
>>>> actually addressed destination (i.e. the load balancer is visible to
>>>> the
>>>> tenant and is there for the purpose the tenant request; and on the
>>>> other
>>>> hand a load balancer which is known to the service chaining
>>>> infrastructure, but whose purpose to balance across isntances of
>>>> services whose multiplicity is not of concern to the tenant, only
>> the
>>>> functionality.
>>>>
>>>> Put differently, it is between load balancing as an explicit service
>>>> and
>>>> load balancing to enable some service within the service chaining.
>>>>
>>>
>>> Thanks for clarification.
>>> My concern is about the latter, i.e., SFC solution must support load
>> balancing to multiple service instantiations (e.g., VMs) of a single
>> service at the intermediate service hops. In fact, we need the latter
>> to support the former..
>>> Maria
>>>
>>>> On 3/26/14, 10:56 AM, NAPIERALA, MARIA H wrote:
>>>>>> 1) given the range of load balancing behaviors, supprting explicit
>>>> load
>>>>>> balancers in the service chaining (as distinct from supporting
>> load
>>>>>> balancers for end users), is significantly complicate
>>>>> I am not sure I understand this point. Could you explain what you
>>>> mean by "explicit" load balancer vs. load balancer "for the end
>> users"?

---

From: Dave Dolson <[email-masked]>
Date: Thu, 3 Apr 2014 13:24:02 +0000

There is another (degenerate?) case that can be made to work.
(c) any given instance of the service function only processes traffic for one chain.  (i.e., the forwarding rules are the same for all packets)
In this case, for example, new flows can be created and the SFF knows what to do with them.
This might not be as crazy as it sounds, given the world of NFV.

(d) Physical interfaces can indicate chain. Two-interface transparent proxies will keep track of whether packets are travelling right-to-left or left-to-right. In this case, two chains can be supported (for one bidirectional chain). The interface indicates to the SFF which forwarding rules to use.

(e) Other existing transparent proxies can intersect a VLAN trunk and keep track of packet context in VLAN terms. In this case, an SFF can provide a service chain per VLAN tag per physical interface.

Probably many of you will feel these are obvious, but they are not represented by the (a) and (b) constraints below.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Wednesday, March 26, 2014 4:45 PM
To: Sumandra Majee; Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Sumandra,

I don't think that all service functions could be or should be made to work in an SFC environment with no changes.   In a previous airing of this issue, we concluded that only service functions that satisfied certain constraints could be made to work in an SFC environment with no changes.   In fact, Joel H. and I had a disagreement whether it was proper to state that service functions that satisfied those constraints were "simple" service functions -- I withdrew my characterization of them as such.   Those constraints were a) the service function must not change the key fields of the IP header (i.e., 5-tuple) and b) must not launch separate flows (e.g., many HTTP transparent proxy implementations).   Otherwise, that service function is not a candidate to operate under SFC without change.    Sure, it can and does operate under pre-existing ways of doing things, but that isn't the point of our exercise.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sumandra Majee
Sent: Wednesday, March 26, 2014 4:13 PM
To: Surendra Kumar (smkumar); Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Surendra,

At the risk of repeating myself, I say AGREE.

However me, you and rest agreeing means zilch to the application developers.  What I am saying is that the architecture should take a stand that the existing Service Function will work as is.  Currently the stand is that if the application does not work then go Fix it.  

Did we give this enough thought in a collective way?

There are existing service chain solutions that doesn't mandate any form of change in the existing service interface. Would it be nice to have as a goal?

Regards,

Sumandra
________________________________________
From: Surendra Kumar (smkumar) [[email-masked]]
Sent: Wednesday, March 26, 2014 12:19 PM
To: Sumandra Majee; Joel M. Halpern; Lucy yong; [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Sumandra,

This seems like whether a specific SF is SFC compatible or not ? If compatible, how much, based on the requirement language in SFC.
That is why it is all the more important to have a simple, clean & short service header - may have greater chance of adoption.

Surendra.

On 3/26/14 12:07 PM, "Sumandra Majee" <[email-masked]> wrote:

>
>
>On 3/26/14, 11:59 AM, "Joel M. Halpern" <[email-masked]> wrote:
>
>>If the service function preserves the transport header and the serice 
>>chaining header, then even though the packet header has been changed, 
>>the transport and / or the SFC header will direct the packet onwards 
>>along the intended path.  Since this is needed for preserving metadata 
>>anyway, this is our targeted mode as I understand it.  Which simply 
>>works with your SF_VO case below.
>
>[SM] Yes. However I am not sure if the architecture can count on the 
>preservation part.
>I as a network engineer at times often misjudged the application 
>developer restriction and requirement.
>SFC in a way would need to bridge this gap (or be aware what works and 
>what doesn¹t).
>
>Regards.
>
>Sumandra
>
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

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

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

---

From: Cathy Zhang <[email-masked]>
Date: Thu, 3 Apr 2014 22:30:13 +0000

Just come back from my PTO. Please see inline.

Thanks,
Cathy

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 01, 2014 3:50 PM
To: Cathy Zhang
Cc: [email-masked]
Subject: Re: [sfc] SFC encapsulation chain ID

Cathy> It depends on what is meant by “a hop”. The semantics of the “still a hop” is different from the physical network hop which was meant in my previous reply.
BTW, network hop latency could be larger than 500ns and worse than local processing latency if the network has congestion.
Yes, the “hop” is only mitigated if the VM instance cluster associated with the same service function is not large and is collocated with the LB.
For scenarios that VM instances associated with a service function are of large size and widely distributed, multiple LBs might be needed to front-end the VMs and
the classifier needs to be aware of these LBs.  Or some other better mechanism needs to be sorted out to solve the scalability issue (too many service paths with permutations of service instances).
Yes, we are in sync that front ending VM cluster with a LB incurs extra processing and latency.
As discussed in this email thread before, everything has a scale limit and scalability enhancement mechanisms usually incur some cost and application limitation.

Cathy> Sure, I am fine with the saying except that the chain can be a combination of “SF LBs and service instances” instead of “a chain of SF LBs”.

________________________________

Cathy

-----Original Message-----

From: NAPIERALA, MARIA H [mailto:[email-masked]]
Sent: Wednesday, March 26, 2014 10:57 AM
To: Cathy Zhang; Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
Cc: [email-masked]
Subject: RE: [sfc] SFC encapsulation chain ID

>
> If case 1 poses a scalability problem (eg. there are hundreds of VMs
> for a service function), the scalability issue can be solved by
> transforming case 1 into case 2
> through placing a local LB before these VMs and only the LB is viewed
> in the chain.

Introducing additional hop is a service chain translates to delay and cost. Imagine a 5 hop chain, each fronted with an external LB SF. 5-hop chain becomes 10-hop chain.
In fact, if the LB is a virtual appliance it might have similar scalability issue as the original SF.

> In some other deployment scenario, case 1 might not pose
> a scalability issue, and
> thus solution/architecture wise, we should not exclude case 1. To put
> it another way, case 1 is only usable in small-scale scenario.
>
> Cathy
>
> From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
> Sent: Wednesday, March 26, 2014 8:48 AM
> To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark;
> Kevin J Ma; Dave Dolson; Sumandra Majee
> Cc: [email-masked]
> Ron,
> I would consider a solution which scales only with assumptions 2. and
> 3. (clusters with internal LB) as limited.
>
> Maria
>
> > From: Ron Parker [mailto:[email-masked]]
> > Sent: Wednesday, March 26, 2014 11:44 AM
> > To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern; Erik
> > Nordmark; Kevin J Ma; Dave Dolson; Sumandra Majee
> > Cc: [email-masked]
> > Subject: RE: [sfc] SFC encapsulation chain ID
> >
> > Maria,
> >
> > I agree with you that case 1. will only practically scale up to some
> > point.    Perhaps, as a service provider, you'd choose to avoid the
> > whole problem and only deploy service functions along the lines of
> case
> > 2 or case 3.    But, that doesn't invalidate the utility of case 1
> for
> > some other network with some other requirements and constraints.
> >
> >    Ron
> >
> >
> > From: NAPIERALA, MARIA H [mailto:[email-masked]]
> > Sent: Wednesday, March 26, 2014 11:39 AM
> > To: Ron Parker; Joel Halpern Direct; Joel M. Halpern; Erik Nordmark;
> > Kevin J Ma; Dave Dolson; Sumandra Majee
> > Cc: [email-masked]
> > Subject: RE: [sfc] SFC encapsulation chain ID
> >
> > >
> > > 1. A service function is realized by multiple VM's where each VM
> has
> > > its own IP address.   In this case the classifier/PDP sees each VM
> as
> > a
> > > service function instance.
> > >
> >
> > I don't think this will scale. It was pointed out that the number of
> > service paths grows exponentially.
> >
> >
> > > 2. A service function, as above, but some subset of VM's is front-
> > ended
> > > by a load balancer.   There are multiple such subsets and therefore
> > > multiple load balancers.   Each load balancer has its own IP
> address
> > > and hides the VM IP addresses behind it.   In this case, the
> > > classifier/PDP sees each load balancer as a service function
> > instance.
> >
> > No issue here.
> >
> > > 3. A service function is realized by a set of VM's that perform
> > > internal load balancing.   The set of VM's presents a single IP
> > address
> > > to the outside to hide the IP addresses of the individual VMs.
> The
> > > network has multiple such clusters.   The classifier/PDP sees each
> > > cluster as a service function instance.
> >
> >
> >
> > >
> > >
> > > From: NAPIERALA, MARIA H [mailto:[email-masked]]
> > > Sent: Wednesday, March 26, 2014 11:17 AM
> > > To: Joel Halpern Direct; Joel M. Halpern; Erik Nordmark; Kevin J
> Ma;
> > > Ron Parker; Dave Dolson; Sumandra Majee
> > > Cc: [email-masked]
> > > Subject: RE: [sfc] SFC encapsulation chain ID
> > >
> > > Joel,
> > >
> > > > balancing as part of the chain for the purpose of selecting an
> > > > instance of the actually addressed destination (i.e. the load
> > > balancer
> > > > is visible to the tenant and is there for the purpose the tenant
> > > > request; and on the other hand a load balancer which is known to
> > the
> > > > service chaining infrastructure, but whose purpose to balance
> > across
> > > > isntances of services whose multiplicity is not of concern to the
> > > > tenant, only the functionality.
> > > >
> > > > and load balancing to enable some service within the service
> > > chaining.
> > > >
> > >
> > >

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Apr 2014 18:55:26 -0400

sounds like we are more or less in agreement.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Thursday, April 3, 2014
Subject: RE: [sfc] SFC encapsulation chain ID

Thanks,
Cathy

To: Cathy Zhang

Cc: [email-masked]

In this case, it is still a hop.  The LB VM still has to process (and "balance") the packets, which incurs a larger penalty than the 500ns (or so) of a physical network hop.
  Additionally, the "hop" that you say is mitigated is only mitigated if you colocate all of the VMs behind a LB instance with the LB itself, which is not very elastic, requiring one to create multiple instances of LBs for the same SF, which requires either
 having instances chosen by an SFC classifier (which you are trying to avoid) or introducing a LB in a different location to balance between multiple local LBs (fronting the SF VM instances), which simply re-introduces the hops that you were trying to mitigate
 in the first place.  I suppose you could implement this in such a way that you had a LB in front of your SFC Classifier, but I'd have to wrap my head around that some more to see if it even makes sense.  Either way, I don't think this solves what you think
 it solves.

 

Why can't we simply say that the SFC classifier chooses the SFC Path (specific SF instances) and as a matter of implementation, if you would like,
 you may construct your chain to be a chain of SF LBs, each with a single instance?  That would allow you to scale at the cost of the incremental latency that inherently comes with scaling, but also allow a smaller implementation to forgo the LBs and perform
 the distribution function at the Classifier.

To: NAPIERALA, MARIA H<[email-masked]>,Ron Parker<[email-masked]>,Joel Halpern Direct<[email-masked]>,Joel M. Halpern<[email-masked]>,Erik Nordmark<[email-masked]>,Kevin J Ma<[email-masked]>,Dave Dolson<[email-masked]>,Sumandra
 Majee<[email-masked]>

Cathy

-----Original Message-----

Cc: [email-masked]

> Ma
;

> > > > Put differently, it is between load balancing as an explicit

> > service

> > > My concern is about the latter, i.e., SFC solution must support

> > > balancing to multiple service instantiations (e.g., VMs) of a

> single

> > > service at the intermediate service hops. In fact, we need the

> latter

> > > > >> 1) given the range of load balancing behaviors, supprting

> > > > >> explicit

> > > > > I am not sure I understand this point. Could you explain what

> you

sfc mailing list

[email-masked]