Subject: [sfc] Service Chains, Paths, and Load Balancers

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Jul 2014 22:39:48 -0400

I have been trying to figure out how to clearly answer a number of 
comments that have been made about the proposed merged archtiecture 
draft.  Assuming we can get working group agreement on the intent, we 
will work to improve the wording so that readers who have not 
participated in the WG discussion will understnd it the way the working 
group intends.

But what do we intend?  I will try to explain my personal view, and see 
if that helps.

In this regard, it is important to keep in mind that what we are 
defining is the data plane architecture.  We are not attempting to 
define the architecture for the entire solution for service chaining. 
That would encompass OSS/BSS, various control and policy functions, 
virtual machine and image management, and many other aspects.

As a result there are many things which clearly need to exist in the 
larger system, but which are dealt with above where we are functioning, 
and are not directly required by the work we are doing.

In order to get to service chain vs service path, as I understand them, 
I need to first discuss load balancing.  There are at least three 
different ways that load balancing can and will interact with service 
chaining.  There probably are more.  The point of the archtiecture is to 
permit all of these, but not to mandate that any particular kind be used 
in any solution.

1) Load balancing as a service provided to the end user.  This is a 
service function.  It receives user packets, and modifies them (or marks 
them, or ...) so as to choose an end user service instance to receive 
the users packet.  This is an important service function to be able to 
include in service chaining.  It's behavior may affect requirements on 
how service chaining is done.  But it has very little impact on the 
archtiecture.  From an architectural pe3rspective it is simply a service 
function which may modify the underlying packet.

2) There is internal load balancing.  That is, one can have what appears 
to the service chaining architecture as a single point of contact for a 
specific service function, but is actually delivered by a collection of 
virtual or physical machines, possibly including one or several load 
balancers (for example using VRRP-like techniques to share a MAC 
address.)  mostly, this is invisible to the service chaining data plane 
mechanisms.  It is likely that it is visible to various control 
mechanisms, such as those responsible for scale-in, scale-out, and vm 
instantiation.  The architectural impact of permitting this is largely 
that we need to be careful that our terminology does not lead readers to 
think we are prohibiting it.

3) There can also be load balancing done by selecting packet paths for 
the service chaining that direct traffic to different places.  We would 
not want to require that a given service function appear at only one 
place in the network.

It is of course the case that these may be combined.  I tend to refer to 
the collection of entities that appear to service chaining as a single 
point as a cluster.  Not because cluster is a good term.  But because I 
do not have another one.  Thus, the point of type 3 load balancing is to 
direct different subsets of traffic to different singular or clustered 
service functions in different places in the network.

Now with that said, what do I mean when I talk about service chain and 
service path/  Service chain is a sequence of logical functions to be 
applied to a subset of packets.  It is equivalent of saying that some 
subset of traffic is to get DPI, charging, content inspection, and 
firewall while a different subset is to go directly to the cache without 
visiting any other service functions.

That is not enough information to direct the packets.  A service path 
is, in some fashion, a sequence of locations in the network.  Those 
locations will be singular or clustered service function delivery 
locations.  They may be addressed by IP address.  They may be addressed 
as ports on an SFF.  There are many different ways that the locations 
may be known to the service chaining infrastructure and the transport.

 From the point of view of the work of the SFC group, we need to be able 
to talk about the high level abstraction, the service chain, which 
drives the forwarding.  And we need to talk about the actual data path 
packets will take in the network.

Several of the comments have said "but the whole path may not be known 
at the front."  This architecture deals with that issue in two ways. 
First, as noted in item (2) on load balancers above, there can be 
decisions and behaviors which are invisible to the service chaining 
mechanisms (in much the same way that bridging within a LAN is largely 
invisible to routing between LANs.)  The other provision we make is that 
reclassification can be done in mid-chain when necessary.  That will 
direct packets to a new chain.  Based on information available at the 
re-classification point.

I hope that this helps explain what we are after.  If it does, and if 
the intent is acceptable to the working group, we can figure out what 
additional words are needed to convey this.
If the working group disagree with the intent, then we will of course 
adjust to match the working group agreements.
If this is still unclear, I am not sure what to try next.

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 07:04:50 +0000

Hi Joel,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : mercredi 9 juillet 2014 04:40
>À : [email-masked]
>Objet : [sfc] Service Chains, Paths, and Load Balancers
>

[Med] OSS/BSS considerations are out of scope for sure, but the functional entity(ies) responsible for the structuring of chains should be in scope IMO. The title and the abstract of the merged draft do not exclude those:

   This document describes an architecture for the specification,
   creation, and ongoing maintenance of Service Function Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs.

>larger system,

[Med] I don't understand what you mean by the large system. 

 but which are dealt with above where we are functioning,
>permit all of these, but not to mandate that any particular kind be used

[Med] Agree. How load balancing is managed within a SFC-enabled domain is up to the responsibility of the administrative entity managing that domain. One or a mix of these flavors can co-exist. 

>That is not enough information to direct the packets. 

[Med] A service chain can also be defined as an order list of service function identifiers. I understand the examples you provide as liberal description of service chains (that I thought you considered it out of scope). A service function identifier does not necessarily hint the service offered by that SF; its purpose is to uniquely identify a SF among those present in a SFC-enabled domain.

 A service path
>is, in some fashion, a sequence of locations in the network.

[Med] so, this is an order list of service function locators. 

  Those
>at the front."

[Med] Which is true. The entity responsible for structure the service chain cannot decide in advance the actual packet of packets because of various considerations such SF-specific LBs, but also for other traffic engineering purposes such as dispatching the traffic among two service PoPs hosting the same set of SFs, etc.

  This architecture deals with that issue in two ways.
>invisible to routing between LANs.)

[Med] Which means that you cannot determine a list of locator a priori given that the decision on which SF instance will be invoked is the responsibility of that LB.

  The other provision we make is that
>reclassification can be done in mid-chain when necessary.

[Med] Re-classification is optional and is deployment-specific. Mandating re-classification to justify a design choice is odd. 

  That will
>direct packets to a new chain.  Based on information available at the

[Med] That's not optimal for some deployments that do not require to embed a classification function in these service functions. 

>
>I hope that this helps explain what we are after. 

[Med] I still disagree that an ordered list of locators can be determined in advance for all deployments. I suggest that SFC forwarding be based on the service chain itself (characterized as an order list of service function identifiers). This is more compliant with the LB constraints above: deciding which locator to use for a given flow will be a local decision not a centralized one.

 If it does, and if
>_______________________________________________
>sfc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 12:40:33 +0000

When I read this comment:

"DNS" popped into my head.    While this may be an imperfect analogy, a URL is logical location that uses an explicit mechanism to bind it to one or more actual network locators (i.e., IPv4 and/or IPv6).   Just thinking out loud here, but is there benefit in using a similar scheme?   That the SFC is truly logical with some sort of "Just-in-time" binding, a la DNS (keeping in mind that DNS clients will often locally cache so as to decrease the amount of DNS queries)?   Would that approach provide simplification and resiliency with respect to the load balancing of service functions problem -- the number of network locators for a logical service function can change at any time due to failures or due to intentional scale-in or scale-out?   Also, this wouldn't preclude the scenario where one or more located service functions are clustered, since the cluster appears as a single network locator to the "DNS-like" mechanism.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 09, 2014 3:05 AM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Joel,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 9 juillet 2014 04:40 À : [email-masked] Objet : [sfc] 
>Service Chains, Paths, and Load Balancers
>

>chaining.  There probably are more.  The point of the archtiecture is 
>to permit all of these, but not to mandate that any particular kind be 
>used in any solution.

>service function.  It receives user packets, and modifies them (or 
>marks them, or ...) so as to choose an end user service instance to 
>receive the users packet.  This is an important service function to be 
>able to include in service chaining.  It's behavior may affect 
>requirements on how service chaining is done.  But it has very little 
>impact on the archtiecture.  From an architectural pe3rspective it is 
>simply a service function which may modify the underlying packet.
>
>2) There is internal load balancing.  That is, one can have what 
>appears to the service chaining architecture as a single point of 
>contact for a specific service function, but is actually delivered by a 
>collection of virtual or physical machines, possibly including one or 
>several load balancers (for example using VRRP-like techniques to share 
>a MAC
>that we need to be careful that our terminology does not lead readers 
>to think we are prohibiting it.
>
>It is of course the case that these may be combined.  I tend to refer 
>to the collection of entities that appear to service chaining as a 
>single point as a cluster.  Not because cluster is a good term.  But 
>because I do not have another one.  Thus, the point of type 3 load 
>balancing is to direct different subsets of traffic to different 
>singular or clustered service functions in different places in the network.
>
>firewall while a different subset is to go directly to the cache 
>without visiting any other service functions.
>

 A service path

  Those
> From the point of view of the work of the SFC group, we need to be 
>able to talk about the high level abstraction, the service chain, which 

  That will

 If it does, and if

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 9 Jul 2014 13:09:43 +0000

Hi, Med,

Please see inline, all the way at the bottom.

> [Med] I still disagree that an ordered list of locators can be determined in advance for all deployments. I suggest that SFC forwarding be based on the service chain itself (characterized as an ord…

Bypassing the concept of a Service Function Path would eliminate the abstracted nature of the Chain itself, and tie the chain to a forwarding construct.

In other words, the idea of an SFC is the abstract set of service functions, whereas the SPF is the instantiation of an actual path in the service topology. This separation allows for the set of load-balancing constructs described above.

Please note that none of this talks about a centralized versus a local decision.

To take it more concrete, these are the actual definitions in draft-merged:

   Service Function Chain (SFC):  A service Function chain defines an
        ordered set of service functions that must be applied to packets
        and/or frames selected as a result of classification.  The
        implied order may not be a linear progression as the
        architecture allows for nodes that copy to more than one branch.
        The term service chain is often used as shorthand for service
        function chain.

   Service Function Path (SFP):  The instantiation of an SFC in the
        network.  Packets follow a service function path from a
        classifier through the requisite service functions

It the WG agrees with the usefulness of separating these concepts, but the text does not convey the intended meaning, let's adjust with suggestions.

Thanks,

Carlos.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 14:26:55 +0000

In line ...

>and are not directly required by the work we are doing.

<keg> Hallelujah!  

>permit all of these, but not to mandate that any particular kind be used

<keg> Nor describe in great detail how they work, please.

>think we are prohibiting it.

<keg> Bingo.  In fact, this will be a common scenario.
<keg> One of the things I've seen recur as well is the notion that somehow
the path needs to include specific instance information for when you enter
one of your clusters (which may be one of the reasons you're getting the
comment about the path not being known a priori) Š it does not Š the only
reason we would need to include that information is if it causes some
change in the subsequent chain AFTER the abstracted blob of functionality.
 In this way we avoid the explosion of path information, constant updating
of the path, etc.  Further, IF you have a scenario where the chain would
deviate, I'd venture that it was through a packet alteration that led to
reclassification (and again, no need to imbed instance information in the
path).  From a management perspective, as you point out, this information
(what instance flow matching tuple "blah" was sent to) can be gleaned (if
you desire) from the distribution agent itself.

>service functions in different places in the network.

<keg> or provide an ambiguous, already optimized location via something
like an anycast address for the service

>direct packets to a new chain.  Based on information available at the

<keg> Amen

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 9 Jul 2014 14:31:07 +0000

Hi Carlos, Joel, Med, et al,

> > [Med] I still disagree that an ordered list of locators can be determined in
> advance for all deployments. I suggest that SFC forwarding be based on the
> service chain itself (characterized as an order list of service function
> identifiers). This is more compliant with the LB constraints above: deciding
> which locator to use for a given flow will be a local decision not a
> centralized one.
> >
> >
> 
> Bypassing the concept of a Service Function Path would eliminate the
> abstracted nature of the Chain itself, and tie the chain to a forwarding
> construct.
> 
> In other words, the idea of an SFC is the abstract set of service functions,
> whereas the SPF is the instantiation of an actual path in the service topology.
> This separation allows for the set of load-balancing constructs described
> above.
> 
> It the WG agrees with the usefulness of separating these concepts, but the
> text does not convey the intended meaning, let's adjust with suggestions.

Conceptually on an SN:

@next_sf_locations = lookup_next_sf_locations($NSH);
$sf_location = load_balance(@next_fs_locations, $NSH, $original_packet);
send_to_sf_location($sf_location, $NSH, $original_packet);

Where @next_sf_locations may contain:
1. location1, active
2. location2, active
3. location3, not-reachable, diag: continuity check failed

This model looks to be useful (for resiliency purpose) whether the SN is hosting a load-balancer SF or a non-load-balancer SF.

Thus:

I see SFC to be a list of SFs.
I see SFP to be the actual list of SF locations that packet traversed.

So I agree with the usefulness of separating the terms SFC and SFC, but ...

[snip from Section 2.3]
   When an SFC is instantiated into the network it is necessary to
   select the specific instances of SFs that will be used, and to create
   the service topology for that SFC using SF's network locator.  Thus,
   instantiation of the SFC results in the creation of a Service
   Function Path (SFP) and is used for forwarding packets through the
   SFC.  In other words, an SFP is the instantiation of the defined SFC.
[snip]

As Med indicated above, perhaps we do not want to restrict SFP to always be pre-determined at the time of SFC creation.

Thanks!

-Nobo

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 14:40:04 +0000

Ron,

I'm not asking to revive RFC1383 ;-)

More seriously, SF locators can be provisioned or whatever to the SFF to perform its operations. This does not require an external lookup unless you decide to use a name as a locator, then a resolution will be needed of course.. but this is deployment-specific.

Cheers,
Med

>De : Ron Parker [mailto:[email-masked]]
>Envoyé : mercredi 9 juillet 2014 14:41
>À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; [email-masked]
>Objet : RE: [sfc] Service Chains, Paths, and Load Balancers
>
>	[Med] I still disagree that an ordered list of locators can be
>determined in advance for all deployments. I suggest that SFC forwarding be
>based on the service chain itself (characterized as an order list of
>service function identifiers). This is more compliant with the LB
>constraints above: deciding which locator to use for a given flow will be a
>local decision not a centralized one.
>
>
>"DNS" popped into my head.    While this may be an imperfect analogy, a URL
>is logical location that uses an explicit mechanism to bind it to one or
>more actual network locators (i.e., IPv4 and/or IPv6).   Just thinking out
>loud here, but is there benefit in using a similar scheme?   That the SFC
>is truly logical with some sort of "Just-in-time" binding, a la DNS
>(keeping in mind that DNS clients will often locally cache so as to
>decrease the amount of DNS queries)?   Would that approach provide
>simplification and resiliency with respect to the load balancing of service
>functions problem -- the number of network locators for a logical service
>function can change at any time due to failures or due to intentional
>scale-in or scale-out?   Also, this wouldn't preclude the scenario where
>one or more located service functions are clustered, since the cluster
>appears as a single network locator to the "DNS-like" mechanism.
>
>   Ron
>
>
>[Med] OSS/BSS considerations are out of scope for sure, but the functional
>entity(ies) responsible for the structuring of chains should be in scope
>IMO. The title and the abstract of the merged draft do not exclude those:
>
>[Med] Agree. How load balancing is managed within a SFC-enabled domain is
>up to the responsibility of the administrative entity managing that domain.
>One or a mix of these flavors can co-exist.
>
>>
>[Med] A service chain can also be defined as an order list of service
>function identifiers. I understand the examples you provide as liberal
>description of service chains (that I thought you considered it out of
>scope). A service function identifier does not necessarily hint the service
>offered by that SF; its purpose is to uniquely identify a SF among those
>present in a SFC-enabled domain.
>
> A service path
>[Med] Which is true. The entity responsible for structure the service chain
>cannot decide in advance the actual packet of packets because of various
>considerations such SF-specific LBs, but also for other traffic engineering
>purposes such as dispatching the traffic among two service PoPs hosting the
>same set of SFs, etc.
>
>[Med] Which means that you cannot determine a list of locator a priori
>given that the decision on which SF instance will be invoked is the
>responsibility of that LB.
>
>
>[Med] Re-classification is optional and is deployment-specific. Mandating
>re-classification to justify a design choice is odd.
>
>  That will
>[Med] That's not optimal for some deployments that do not require to embed
>a classification function in these service functions.
>
>>
>[Med] I still disagree that an ordered list of locators can be determined
>in advance for all deployments. I suggest that SFC forwarding be based on
>the service chain itself (characterized as an order list of service
>function identifiers). This is more compliant with the LB constraints
>above: deciding which locator to use for a given flow will be a local
>decision not a centralized one.
>
>
> If it does, and if

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 14:42:17 +0000

While I can see using anycast for some generalities, I don't see us as
having to solve the problem of how elasticity works Š via any means,
including DNS (avoid requirement coupling at all costs).

I DO believe the path needs to resolve to a set of next-hops and can't be
generic function widgets descriptors (the chain), primarily because of the
on-the-fly overhead to the classifier (resolution) and the traceability
(should you log the packets path as a debugging tool, what WERE the DNS
records at that time if all you have are the chain).

I don't think the load balancing scenario is a great example of not
knowing the destination in the path a priori, so I disagree with Med and
agree wholeheartedly with Joel.

BUT, the fundamental point of an abstraction is to hide detail.  We have a
destination IP for the coupled LB and it's scaled-out function via the LB
abstraction (anycast, specific, whatever) Š why do you NEED to resolve
what is inside that abstraction and put it in the path?

On 7/9/14 8:40 AM, "Ron Parker" <[email-masked]> wrote:

>determined in advance for all deployments. I suggest that SFC forwarding
>be based on the service chain itself (characterized as an order list of
>constraints above: deciding which locator to use for a given flow will be
>a local decision not a centralized one.
>
>
>"DNS" popped into my head.    While this may be an imperfect analogy, a
>URL is logical location that uses an explicit mechanism to bind it to one
>or more actual network locators (i.e., IPv4 and/or IPv6).   Just thinking
>out loud here, but is there benefit in using a similar scheme?   That the
>SFC is truly logical with some sort of "Just-in-time" binding, a la DNS
>simplification and resiliency with respect to the load balancing of
>service functions problem -- the number of network locators for a logical
>service function can change at any time due to failures or due to
>intentional scale-in or scale-out?   Also, this wouldn't preclude the
>scenario where one or more located service functions are clustered, since
>the cluster appears as a single network locator to the "DNS-like"
>mechanism.
>
>   Ron
>
>
>[Med] OSS/BSS considerations are out of scope for sure, but the
>functional entity(ies) responsible for the structuring of chains should
>be in scope IMO. The title and the abstract of the merged draft do not
>exclude those:
>
>up to the responsibility of the administrative entity managing that
>domain. One or a mix of these flavors can co-exist.
>
>>
>scope). A service function identifier does not necessarily hint the
>service offered by that SF; its purpose is to uniquely identify a SF
>among those present in a SFC-enabled domain.
>
> A service path
>[Med] Which is true. The entity responsible for structure the service
>chain cannot decide in advance the actual packet of packets because of
>various considerations such SF-specific LBs, but also for other traffic
>engineering purposes such as dispatching the traffic among two service
>PoPs hosting the same set of SFs, etc.
>
>[Med] That's not optimal for some deployments that do not require to
>embed a classification function in these service functions.
>
>>

---

From: <[email-masked]>
Date: Wed, 9 Jul 2014 15:01:00 +0000

Hi Carlos, 

Please see inline.

Cheers,
Med

>De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
>Envoyé : mercredi 9 juillet 2014 15:10
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : Joel M. Halpern; [email-masked]
>Objet : Re: [sfc] Service Chains, Paths, and Load Balancers
>
>Hi, Med,
>

[Med] Not sure to understand the causality effect here. We have 2 levels of abstraction in fact: 
(1) the one which is represented as a the set of SFs to be invoked to deliver a service. 
(2) the one which reflects the actual forwarding path of a packet bound to chain: i.e., the actual SF instances invoked when forwarding the packet in the context of a given chain. Multiple paths can correspond to a single chain. 

>
>In other words, the idea of an SFC is the abstract set of service
>functions, whereas the SPF is the instantiation of an actual path in the
>service topology. This separation allows for the set of load-balancing
>constructs described above.

[Med] I don't have a problem with the separation but to assume that path is pre-determined. I'm saying that what should be determined is the chain itself, not the actual path. The path may not be known in advance because of various reasons mentioned in another message. That's what I'm for relying one service chain itself to achieve forwarding. How that information is translated to a path is all about details.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 15:08:30 +0000

Joel,

> think we are prohibiting it.

I would make a stronger statement here: that any SFC solution not only does not prohibit it but makes it possible.  Any SFC solution has to make it possible for a service in a service chain to scale horizontally to 10 or even 100s of instances. 
 
> not want to require that a given service function appear at only one

Yes, this is also very important.  Ideally, one would like to have the same solution for (2) and (3).

Maria

---

From: "Zarny, Myo" <[email-masked]>
Date: Wed, 9 Jul 2014 13:59:37 -0400

I agree with Nobo and Med. But I do have questions of my own, which may already have been discussed. (Apologies if that's the case.)

1.      I don't see how it's possible to predetermine the SFP with load balancers in the middle - IF an SFP is defined as the entire path between the client and the end server (whatever that end server happens to be. See my point 2.)
o       Load balancers, by definition, choose the next backend entity to load balance to, based on the configured LB algorithm (e.g., round robin, least response time, etc.), which can be overridden by persistence/stickiness requirements (as well as other custom methods).
*       How does the "system" know in advance which backend needs to be selected? If it does take on that role in some fashion, the system has taken on the role of the load balancer.
*       Even if the system somehow knows which backend entity the load balancer will choose the first time, subsequent connections may be overridden.
o       And let's not forget the return path. (I haven't seen any discussions on it; though it's possible I may have missed it.) Many load balancers are TCP (in many cases HTTP/SSL) proxys. This requires the return traffic to traverse the same LB. So when we talk about creating the service "path", or service "chain", we'll also need to ensure that the return traffic somehow gets back to the original LB.

2.      But must we define the SFP as such-in an expansive way? Why can't the SFP be shorter (say, demarcated at the 5-tuple level)? E.g., why can't we have an SFP between the client and the LB, and another SFP between the LB and the server?

3.      If we define the SFP as the entire end-to-end flow, then, we must first define what that means! What's the demarcation? When does an SFP end? If SFPs can be shorter, then can't we have correspondingly scoped SFCs as well? Wouldn't we then be able to bypass some of the complications introduced by the middle boxes like load balancers?

Myo

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Nobo Akiya (nobo)
Sent: 9 July 2014 10:31 AM
To: Carlos Pignataro (cpignata); Med Boucadair
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

> > determined in
> advance for all deployments. I suggest that SFC forwarding be based on
> abstracted nature of the Chain itself, and tie the chain to a
> forwarding construct.
>
> functions, whereas the SPF is the instantiation of an actual path in the service topology.
> This separation allows for the set of load-balancing constructs
> described above.
>
> It the WG agrees with the usefulness of separating these concepts, but
> the text does not convey the intended meaning, let's adjust with suggestions.

Conceptually on an SN:

@next_sf_locations = lookup_next_sf_locations($NSH); $sf_location = load_balance(@next_fs_locations, $NSH, $original_packet); send_to_sf_location($sf_location, $NSH, $original_packet);

Thus:

[snip from Section 2.3]

Thanks!

-Nobo

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

---

From: Ian Smith <[email-masked]>
Date: Wed, 9 Jul 2014 18:54:21 +0000

1. You don't have to know the particular service function instances to define the service function chain.  Example:

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

Translation:  send to instances of these 4 services in this order.

2. You don't have to know the ip address of a service function instance to define that an instance does exist.  Example:

service-function url-filter {
         dns _http._tcp.url-filter.example.com
         fallback bypass
}

Translation:  query DNS for the address and use it, if you can't resolve an address, skip this function.

3. You may define a service function conditionally.  Example:

service-function web-optimizer {
         if { [class match [HTTP::url] eq optimizable-content] } {
            ip 2001:db8:0:22::137.80
         } else {
            service-function firewall
         }
} 

Translation:  if the url is known to be optimizable, use this IP address, otherwise skip this function and go directly to the firewall.

4. You may pre-select a load balancing decision at the time that the Service Function Path is being selected.  Example:

service-function web-cache {
         lb carp [HTTP::url] @2001:db8:0:21::224.80
}  

Translation: instruct the load balancer at the given virtual address to make a load balancing decision using the carp hash of the url and expect us to send it traffic.

5. You may load balance directly in the path selection process.  Example:

service-function firewall {
         pool {
              least-connections {urn:oid:[Firewall.connections.active] || local:active_connections}
              ip 2001:db8:23::130
              ip 2001:db8:23::131
              ip 2001:db8:23::132
              ip 2001:db8:23::133
         }              
}

Translation:  using either the snmp query to the given oid, or our own internal counters, pick the ip address from this list that has the least amount of current connections.

6. You may just declare that the service function is a complex of servers behind a screening device (like a nat or load balancer).  Example:

service-function url-filter {
         opaque
         dns _http._tcp.url-filter.example.com
}

Translation: use dns to select the instance, but know that there will be a hidden service function path segment inserted before the next link in the service function chain.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 19:06:27 +0000

> which locator to use for a given flow will be a local decision not a

Absolutely. I cannot imagine how else it can be done.

Maria

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 09 Jul 2014 15:40:56 -0400

The archtiecture allows for this local decision, while still having the 
global decision that is directing the traffic.  That is, the global 
decision directs the traffic to places in the network.  Those places may 
be singular or clusters.  If they are clusters, those clusters can use 
any number of algorithms to distribute the traffic internally, without 
any effect on service chaining.  (And yes, this can be done in such a 
way that return traffic, if delivered globally to the same place, can 
then be delivered to the right internal state.)

The definition of the service path is about how service chaining will 
direct the traffic.  it is not about how the internal load balancing is 
doen, as there are MANY ways to do that, and they can give the same 
external interface.

We could write the architecture pretending that it always addresses 
singular instances, but knowing that reality would allow load balanced 
clusters at those locations.  But that would be a misleading 
architectural description and might be read to outlaw some solutions 
that fall within the goal the WG wishes to meet.

Yours,
Joel

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 19:42:10 +0000

I think you have to go back to Joel's original description of a chain and
a path:

Service chain is a sequence of logical functions to be
applied to a subset of packets.

Šwhich I fully agree is a reasonable definition.  You do need a locator to
find the device in the chain in the network and you better know what that
is when you classify the traffic.  That applies even when the device
locator is an abstraction for thousands of devices that it manages locally
as "function X".  What I have been saying is that you do NOT need to know
the address of whatever instance X is managing as long as the next
function in the chain is not a divergent locator after that point of
abstraction (because then you do have different discrete chains and paths).

In this respect, I don't think LB/ADC applies as an example of not knowing
the full path a priori.

On 7/9/14 3:06 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>>the

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 19:46:21 +0000

I think the discussion point, in my mind, is around architecturally, where and how is the chain resolved to a set of sequential next hops?    Is it done centrally, distributed, or some combination?   Does it hold for the life of a fully qualified flow, barring failures and reclassification?   What happens when there are failures?   How is scale-out/scale-in handled?

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Wednesday, July 09, 2014 3:42 PM
To: NAPIERALA, MARIA H; [email-masked]; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I think you have to go back to Joel's original description of a chain and a path:

Service chain is a sequence of logical functions to be applied to a subset of packets.

That is not enough information to direct the packets.  A service path is, in some fashion, a sequence of locations in the network.

Šwhich I fully agree is a reasonable definition.  You do need a locator to find the device in the chain in the network and you better know what that is when you classify the traffic.  That applies even when the device locator is an abstraction for thousands of devices that it manages locally as "function X".  What I have been saying is that you do NOT need to know the address of whatever instance X is managing as long as the next function in the chain is not a divergent locator after that point of abstraction (because then you do have different discrete chains and paths).

In this respect, I don't think LB/ADC applies as an example of not knowing the full path a priori.

On 7/9/14 3:06 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>>determined in  advance for all deployments. I suggest that SFC 
>>forwarding be based on the  service chain itself (characterized as an 
>>order list of service function  identifiers). This is more compliant 
>>with the LB constraints above:
>>deciding

---

From: "Zarny, Myo" <[email-masked]>
Date: Wed, 9 Jul 2014 15:46:55 -0400

Hi Ian,

Thanks for the write-up.

Just to confirm I get this right: You're saying the SFC is a collection of abstracted desired service functions (your point 1) while the actual path a given application flow traverses is determined by the service functions themselves? E.g., your examples in points (2, 3, 4 and 5)?

In your examples, the actual flows (say, TCP connections between the same pair of endpoints) can traverse different SF paths-nothing wrong with that-even if they follow the same exact SF chain. This mean the SFP isn't predetermined (since it's the actual entities that decide the next service function).

Do I get that right?

Myo

PS: Btw, no one has tackled my reverse path question.

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

service-function web-cache {
         lb carp [HTTP::url] @2001:db8:0:21::224.80 }

service-function url-filter {
         opaque
         dns _http._tcp.url-filter.example.com }

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 9 Jul 2014 16:02:30 -0400

Is anyone still questioning the difference between SF Chain and SF Path?  Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.  

If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 20:00:37 +0000

I had in mind singular instances, say, 20 virtual firewall instances somewhere in the middle of a chain. Are you saying that you will decide (make a load balancing decision) at the entry to the chain which of those 20 firewalls will be used by a particular flow?

Maria

> From: sfc [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
> Sent: Wednesday, July 09, 2014 3:41 PM
> To: NAPIERALA, MARIA H; [email-masked]; [email-masked]
> in

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Jul 2014 16:26:00 -0400

I am saying that if the 20 virtual firewalls are deployed separately, 
then the service chaining infrastructure would treat them as such, and 
would use distinct service paths.
Alternative, if you as the operator choose to deploy them as a cluster, 
with sutiable load balancing, such that they appear as a single place 
for service chaining, then there would be one service path.

And the operator could choose a hybrid, for exanmple, deploying two 
clusters of 10 each, requiring two service paths.

Typically, different clusters would be used to provide geographic 
diversity or because there was a policy reason to distinguish them. 
While clusters would typically be used to allow the scale-in and 
scale-out to occur without affecting service chaining.

The architecture is structured to allow this range.

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 20:48:55 +0000

> would use distinct service paths.

If I have a 4 hop service chain with 20 instances at each hop, then I have to globally manage 160,000 service paths (for one chain)? Well, we have yet to see a solution that work this way and scales..

Maria

> > I had in mind singular instances, say, 20 virtual firewall instances
> somewhere in the middle of a chain. Are you saying that you will decide
> (make a load balancing decision) at the entry to the chain which of those 20
> firewalls will be used by a particular flow?
> >
> > Maria
> >
> determined

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 9 Jul 2014 20:59:28 +0000

Hi Joel,

I'm starting to get your definition of SFP.

So the locator can be an SN or a cluster ingress where the job of the cluster ingress is to distribute the packets/frames to the actual SNs within the cluster.

Couple of questions from "failure" point of view.

How do you protect the cluster ingress (or reachability to the cluster ingress) being a single point of failure? Usage of anycast, VRRP-like or triggering path-protection to switchover the entire SFC to another SFP?

If an SN can resolve the next SF to multiple locators, then wouldn't it be easier to perform local protections (w/o depending on anycast, VRRP-like or path-protection)?

Thanks!

Nobo

> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Wednesday, July 09, 2014 4:26 PM
> I am saying that if the 20 virtual firewalls are deployed separately, then the
> service chaining infrastructure would treat them as such, and would use
> distinct service paths.
> Alternative, if you as the operator choose to deploy them as a cluster, with
> sutiable load balancing, such that they appear as a single place for service
> chaining, then there would be one service path.
> 
> Typically, different clusters would be used to provide geographic diversity
> or because there was a policy reason to distinguish them.
> While clusters would typically be used to allow the scale-in and scale-out to
> occur without affecting service chaining.
> 
> >> The archtiecture allows for this local decision, while still having
> >> the global decision that is directing the traffic.  That is, the
> >> global decision directs the traffic to places in the network.  Those
> >> places may be singular or clusters.  If they are clusters, those
> >> clusters can use any number of algorithms to distribute the traffic
> >> internally, without any effect on service chaining.  (And yes, this
> >> can be done in such a way that return traffic, if delivered globally
> >> to the same place, can then be delivered to the right internal
> >> state.)
> >>
> >> direct the traffic.  it is not about how the internal load balancing
> >> is doen, as there are MANY ways to do that, and they can give the
> >> same external interface.
> >>
> >> singular instances, but knowing that reality would allow load
> >> balanced clusters at those locations.  But that would be a misleading
> >>>> service chain itself (characterized as an order list of service
> above:
> >>>> which locator to use for a given flow will be a local decision not
> >>>> a centralized one.
> >>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 21:05:40 +0000

Hi Maria,

Absolutely and categorically no! If you have 20 instances at each hop then you can choose to load balance among them locally resulting in exactly 4 paths. What Joel is saying is that if for some very odd and certainly not recommended reason you want to treat each instance separately then the architecture does not prevent it.

Sent from my iPhone

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 21:07:28 +0000

Hi Jim,

When you say "locally", where is it?

Maria

> From: Jim Guichard (jguichar) [mailto:[email-masked]]
> Sent: Wednesday, July 09, 2014 5:06 PM
> To: NAPIERALA, MARIA H
> Cc: Joel M. Halpern; [email-masked]; [email-masked]
> Absolutely and categorically no! If you have 20 instances at each hop then
> you can choose to load balance among them locally resulting in exactly 4
> paths. What Joel is saying is that if for some very odd and certainly not
> recommended reason you want to treat each instance separately then the
> architecture does not prevent it.
> 
> Sent from my iPhone
> 
> > If I have a 4 hop service chain with 20 instances at each hop, then I have
> to globally manage 160,000 service paths (for one chain)? Well, we have yet
> to see a solution that work this way and scales..
> >
> > Maria
> >

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 21:07:58 +0000

Typo in previous .. 1 path

Sent from my iPhone

> On Jul 9, 2014, at 5:05 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:
> 
> Hi Maria,
>

---

From: Sharon <[email-masked]>
Date: Wed, 9 Jul 2014 14:10:58 -0700

If we translate the draft standards literally to products this way we will end up chaining a bunch of load balancers, that's it.
These will in-turn need to figure what function to chain for this punt. That's not enough progress in most cases over stitching load balancers with vlans. Perhaps we need to draft an informational on how to build one distributed - interoperable load balancer using the SFC spec ?

--szb

> On Jul 9, 2014, at 1:26 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> I am saying that if the 20 virtual firewalls are deployed separately, then the service chaining infrastructure would treat them as such, and would use distinct service paths.
> Alternative, if you as the operator choose to deploy them as a cluster, with sutiable load balancing, such that they appear as a single place for service chaining, then there would be one service path.
> 
> And the operator could choose a hybrid, for exanmple, deploying two clusters of 10 each, requiring two service paths.
> 
> Typically, different clusters would be used to provide geographic diversity or because there was a policy reason to distinguish them. While clusters would typically be used to allow the scale-in and scale-out to occur without affecting service chaining.
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 21:11:36 +0000

At the node through which the 20 instances are reachable. IOW you don't have to individually address packets to each and every instance.

Sent from my iPhone

> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:
> 
> Hi Jim,
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 21:17:32 +0000

Jim,

There may not be a single node through which all of the instances can be reached (at some reasonable limit of L2 or L3 hops).

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, July 09, 2014 5:12 PM
To: NAPIERALA, MARIA H
Cc: Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

>> Absolutely and categorically no! If you have 20 instances at each hop 
>> then you can choose to load balance among them locally resulting in 
>> exactly 4 paths. What Joel is saying is that if for some very odd and 
>> certainly not recommended reason you want to treat each instance 
>> separately then the architecture does not prevent it.
>> 
>> Sent from my iPhone
>> 
>>>> I am saying that if the 20 virtual firewalls are deployed 
>>>> separately, then the service chaining infrastructure would treat 
>>>> them as such, and would use distinct service paths.
>>> 
>> to globally manage 160,000 service paths (for one chain)? Well, we 
>> have yet to see a solution that work this way and scales..
>>> 
>>> Maria
>>> 
>>>> somewhere in the middle of a chain. Are you saying that you will 
>>>> decide (make a load balancing decision) at the entry to the chain 
>>>> which of those
>> 20
>>>>>> The archtiecture allows for this local decision, while still 
>>>>>> having the global decision that is directing the traffic.  That 
>>>>>> is, the global decision directs the traffic to places in the 
>>>>>> network.  Those places may be singular or clusters.  If they are 
>>>>>> clusters, those clusters can use any number of algorithms to 
>>>>>> distribute the traffic internally, without any effect on service 
>>>>>> chaining.  (And yes, this can be done in such a way that return 
>>>>>> traffic, if delivered globally to the same place, can then be 
>>>>>> delivered to the right internal state.)
>>>>>> 
>>>>>> The definition of the service path is about how service chaining 
>>>>>> will direct the traffic.  it is not about how the internal load 
>>>>>> balancing is doen, as there are MANY ways to do that, and they 
>>>>>> can give the same external interface.
>>>>>> 
>>>>>> We could write the architecture pretending that it always 
>>>>>> addresses singular instances, but knowing that reality would 
>>>>>> allow load balanced clusters at those locations.  But that would 
>>>>>> be a misleading architectural description and might be read to 
>>>>>> outlaw some solutions that fall within the goal the WG wishes to meet.
>>>>>> 
>>>>>> Yours,
>>>>>> Joel
>>>>>> 
>>>>>>>> advance for all deployments. I suggest that SFC forwarding be 
>>>>>>>> based
>>>> on
>>>>>> the
>>>>>>>> function identifiers). This is more compliant with the LB constraints above:
>>>>>> deciding
>>>>>>>> which locator to use for a given flow will be a local decision 
>>>>>>>> not a centralized one.
>>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 21:28:35 +0000

Well of course not; in that case you load balance up a level between those nodes and then locally.

Sent from my iPhone

> On Jul 9, 2014, at 5:17 PM, "Ron Parker" <[email-masked]> wrote:
> 
> Jim,
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 21:31:27 +0000

Agreed.   But is that in scope for SFC or out of scope for SFC?

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 5:29 PM
To: Ron Parker
Cc: NAPIERALA, MARIA H; Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

>>> Absolutely and categorically no! If you have 20 instances at each 
>>> hop then you can choose to load balance among them locally resulting 
>>> in exactly 4 paths. What Joel is saying is that if for some very odd 
>>> and certainly not recommended reason you want to treat each instance 
>>>>>>> From: sfc [mailto:[email-masked]] On Behalf Of Joel 
>>>>>>> Halpern
>>> Direct
>>>>>>>>> service chain itself (characterized as an order list of 
>>>>>>>>> service function identifiers). This is more compliant with the LB constraints above:
>>>>>>> deciding

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Wed, 9 Jul 2014 21:32:14 +0000

In case of network overlay, this is pretty clear, these are all the nodes that constitute a previous hop.  
In any case, this is how we started this thread, i.e., by saying that it is hop-by-hop load balancing. 

Maria

> At the node through which the 20 instances are reachable. IOW you don't
> have to individually address packets to each and every instance.
> 
> Sent from my iPhone
> 
> then
> decide
> >>>> (make a load balancing decision) at the entry to the chain which of
> those
> >> 20
> balanced
> function

---

From: Ian Smith <[email-masked]>
Date: Wed, 9 Jul 2014 21:35:33 +0000

Mostly.

I've been defining things like this:

  *   Service Function Domain as the logical area in which Service Function Chains are defined.  There are various names for them but basically all the architectures define an "ingress" and an "egress" node that anchors a chain at each end - this is the space between them.
  *   Service Function Chain as "an ordered sequence of a finite number of functions"
  *   Service Function Path as "an ordered sequence of particular instances of service functions within a Service Function Chain".
  *   Service Function as an abstract thing - "URL Filter"
  *   Service Function Node as the physical piece of hardware that houses the Service Function - "this server"
  *   Service Function Instance as a particular instance of a service function - "this URL Filter on this Service Function Node" - and it can be a virtual machine, a container, or just an instance of software on the SFN.

This is consistent with material presented at IETF89 and it didn't seem a matter of debate there.  I may have incorrectly believed this to be a case of settled meaning.

Where the Service Function Path is defined is, in my mind, somewhat irrelevant to the architecture.  It does exist, and by definition it exists because packets are moving along it.  In the most rudimentary case, you are passing from node to node to some destination far away using only their default gateway; the SFI is the agglomeration of their default gateways.  This easily evolves to IP Source Routes, MPLS lable stacks, and other in-packet mechanisms, but it just as easily evolves to an orchestration system inserting policy routes into nodes in a "just in time" fashion or tying the client IP to a pre-existing policy that includes the next hop.  The latter case is what my previous example showed.

You could enter each of those example config stanzas onto a single node (that might happen to be an NFVi platform), or you could enter them each on a different piece of networking hardware and tie them together with some sort of "magic thread" like an header field that says "I belong on this Service Function Path (and if you don't have that path defined, recurse through the id to find the Service Function Chain to make whatever evaluation is required by you to send me on my way.)" or a orchestration system.  I confess to geekishly liking the idea of using the IPX+ address schema for this.

Example:

6 byte SFD:4 byte SFC:6 byte SFP
aabbccddeeff:0123:6e01e1f421d3

(I concede it is too indulgent for most people, but it delivers massive amounts of address space with scale out in domains, chains, and paths while still being human readable and relatively easy to shim into lots of places in a packet or in control plane systems and make referential queries using existing mechanisms.)

You could assume that all of the metadata and orchestration stuff that the WG is not covering will deal with how to propagate a policy, and that once it is distributed and installed in the nodes, it takes care of itself.  This is perhaps too plainly stated, but it is easy and seems to be the path we are chartered to take.

So, you ask if the path can vary between SFIs and if that is ok as long as the SFC requirement is met.  I think that is not what people are asking for.  What I think people are asking for is a method for channelizing services on packet switched networks, which I understand to mean that I should disaggregate flows at the boundary of a SFD, and force them into channels according to some external policy, keep them in their channel all the way through the domain, and then reaggregate them on the other side.  And to give the people what they want, I think you do have to say something like, "the path may vary but only amongst the SFIs that are defined by the SFC and once an SFI is selected for use by a flow, it stays selected until dismissed or it fails" which  to me implies that you MUST select the chain, and you MAY select as many instances within that chain that the policy allows, but you MUST respect conditional elements of the chain and to do that you have to, in essence, select all the possible instances implied by the chain.  (I don't know if calling it a Markov chain problem helps, but it is an apt description in my mind.)

That, I hope, explains why my answer to your question about predetermination is that it is possible in the initial state, but not important.  Once you evaluate the conditional requirements however, then the path is set and it SHOULD remain fixed until an input to the conditional requirements changes.  I would expect that change to come from four principal areas:  Failure, packet inspection, content switching, or policy update.  There could be more, but those seem to be the main archetypes.  Of those two, packet inspection results and content switching are clearly the kind of conditional requirement that belong in a SFC definition, while there is a strong case that node or network failures and policy updates will be orthogonal inputs the the whole system, not something that can be clearly identified and dealt with on the data plane.

Where I perceive confusion on the list is when the Service Function Chain is in some sense "To Be Determined" because one or more of the Service Functions have discretionary rules that leave the next hop in the chain indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the Service Function itself MUST be declared before we can select (by any means) a Service Function Instance.  And once in the midst of evaluating the conditional requirement, we have a finite set of "next Service Functions".  I can define a completely deterministic conditional statement, and we should permit such things and leave them to the implementers to restrict if they want, but my gut says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluation (eg. if this, then that, else that2) in which case the SPI is not indeterminate (that is, entirely unknown until evaluation), merely uncertain (that is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is the example from my first email in this thread.

How we deal with them, as a matter of architecture, really has to do with how much we want to talk about what I called earlier "the magic thread".  If we don't what to get into that at all, then it is sufficient to say that a SFC definition MUST include a way to identify all potential SFI's for included SF's, and that implementations SHOULD resolve as many of the possible SFI's implied by a SFC before making an assignment and that if there are conditional rules in the SFC, then implementations MUST resolv all of the possible SFI's and, by use of the magic thread, tell them all that they should be prepared to participate in SFI-x for client-A.

I'll follow up my earlier example with this example of how I might query for the service function path from a network console that has a suitable omniscient view to actually tell me the answer.

Example:

show service-chain client 2001:db8:0::abc:123:def:456 all

service-chain 100 path da29c34de0af:0123:6e01e1f421d3

FUNCTION        INSTANCE                    DESCRIPTION
url-filter      2001:db8:0:20::80.45.80     opaque
web-cache       2001:db8:0:21::80.224.80    carp {http://gothamist.com/2014/07/09/cooler_weather_arrives_on_the_anniv.php}
web-optimizer   2001:db8:0:22::80.137.80    conditional match
firewall        2001:db8:0:23::80.132       current-conns 3245 {3992,4503,3389}

service-chain 109 path da29c34de0af:0134:6e01e1f421d3

FUNCTION        INSTANCE                    DESCRIPTION
dns-filter      2001:db8:0:100::53:98.53    passed
dns-cache       2001:db8:0:100::53:129.53   miss
dns-switch      2001:db8:0:100::53:223.53   off-net, icann tld
dns-server      2001:db8:0:99::53:23.53     SOA 2001:db8:fa99:e8b4:123:abcd:4567:ef01.53

Translation:  The client at 2001:db8:0::abc:123:def:456 currently has Service Function Paths active in two Service Function Chains - 100 and 109  - with the particular Service Function Instances listed in correspondence to the Service Function and any information reported by the SFI pertaining to the state of the SFP.

You could imagine that variations on the same command might yield all the clients using a particular chain, or all the chains where a particular instance is present, or where a particular descriptor exists.

________________________________
From: Zarny, Myo [[email-masked]]
Sent: Wednesday, July 09, 2014 3:46 PM
To: Ian Smith; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Hi Ian,

Thanks for the write-up.

Just to confirm I get this right: You’re saying the SFC is a collection of abstracted desired service functions (your point 1) while the actual path a given application flow traverses is determined by the service functions themselves? E.g., your examples in points (2, 3, 4 and 5)?

In your examples, the actual flows (say, TCP connections between the same pair of endpoints) can traverse different SF paths—nothing wrong with that—even if they follow the same exact SF chain. This mean the SFP isn’t predetermined (since it’s the actual entities that decide the next service function).

Do I get that right?

Myo

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 21:47:38 +0000

I would say that's implementation.

Sent from my iPhone

> On Jul 9, 2014, at 5:31 PM, "Ron Parker" <[email-masked]> wrote:
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 22:00:18 +0000

Jim,

Respectfully, I'm not comfortable with that.   While it is easy to say that this is a layered problem and that load balancing belongs at a lower level, it seems to me that load balancing of the service functions (not load balancer as a service function) should be an explicit consideration of the SFC architecture.    I say this not only from a scale perspective, but also with resiliency in mind.

   Ron

-----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2014 5:48 PM
To: Ron Parker
Cc: Joel M. Halpern; [email-masked]; [email-masked]; NAPIERALA, MARIA H
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

>>>> hop then you can choose to load balance among them locally 
>>>> resulting in exactly 4 paths. What Joel is saying is that if for 
>>>> some very odd and certainly not recommended reason you want to 
>>>> treat each instance separately then the architecture does not prevent it.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>>>>> network.  Those places may be singular or clusters.  If they 
>>>>>>>> are clusters, those clusters can use any number of algorithms 
>>>>>>>> to distribute the traffic internally, without any effect on 
>>>>>>>> service chaining.  (And yes, this can be done in such a way 
>>>>>>>> that return traffic, if delivered globally to the same place, 
>>>>>>>> can then be delivered to the right internal state.)
>>>>>>>> 
>>>>>>>> The definition of the service path is about how service 
>>>>>>>> chaining will direct the traffic.  it is not about how the 
>>>>>>>> internal load balancing is doen, as there are MANY ways to do 
>>>>>>>> that, and they can give the same external interface.
>>>>>>>> 
>>>>>>>> allow load balanced clusters at those locations.  But that 
>>>>>>>> would be a misleading architectural description and might be 
>>>>>>>> read to outlaw some solutions that fall within the goal the WG wishes to meet.
>>>>>>>> 
>>>>>>>> Yours,
>>>>>>>> Joel
>>>>>>>> 
>>>>>>>>>> which locator to use for a given flow will be a local

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 22:16:38 +0000

Exactly. 

On 7/9/14 5:28 PM, "Jim Guichard (jguichar)" <[email-masked]> wrote:

>> There may not be a single node through which all of the instances can
>>be reached (at some reasonable limit of L2 or L3 hops).
>> 
>>   Ron
>> 
>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 9 Jul 2014 22:17:20 +0000

I should clarify that my statement was made as a personal opinion and it is up to the WG to evaluate if there exists anything at the architectural level that is new and therefore needs to be addressed.

Sent from my iPhone

> On Jul 9, 2014, at 6:01 PM, "Ron Parker" <[email-masked]> wrote:
> 
> Jim,
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 9 Jul 2014 22:39:06 +0000

The whole idea of dynamic elasticity control is to hide this detail from
you and to make the instances ephemeral.

When you send a packet from your classifier to my elastic firewall, the
component(s) that make it elastic are what you address Š the elastic
control of my elastic firewall picks the instance based on it's own local
policy or higher level orchestration/policy control at an
out-of-scope-above-the-line-for-sfc layer.

Yes, I can layer this abstraction to scale to a very, very large number of
instances and still present a single addressable point of distribution.

The very scale problem you mention is what the scheme addresses, yet we
seem to be wanting to peel that away.

As Jim stated, IF you want to separately address each instance (with
either the explosion of paths or the huge feedback loop from orchestration
and control, central micro-flow control, volume of changes to your
classifiers, etc.) - go for it.  The architecture allows it.  Has to.
Some people might deploy that way.

The very basic point made in the original argument is "you don't have to
do that".

This is readily demonstrable (I or a number of other vendors can send a
sales guy to do a demo).

What I won't agree to here is that elasticity somehow creates an
unknowable path element.  It shouldn't unless you did it wrong.  Maybe
there's a better example that might justify substituting the chain for the
path (and then dynamically resolving this in the background adding huge
scale considerations) Šbut it's not elasticity.

On 7/9/14 6:00 PM, "Ron Parker" <[email-masked]> wrote:

>Jim,
>
>Respectfully, I'm not comfortable with that.   While it is easy to say
>that this is a layered problem and that load balancing belongs at a lower
>level, it seems to me that load balancing of the service functions (not
>load balancer as a service function) should be an explicit consideration
>of the SFC architecture.    I say this not only from a scale perspective,
>but also with resiliency in mind.
>
>   Ron
>
>
>>> At the node through which the 20 instances are reachable. IOW you
>>>don't have to individually address packets to each and every instance.
>>> 
>>> Sent from my iPhone
>>>

---

From: "Zarny, Myo" <[email-masked]>
Date: Wed, 9 Jul 2014 19:20:29 -0400

Thanks so much for the detailed explanation, Ian. Please see below.

..."predetermination is that it is possible in the initial state, but not important"...

"Where I perceive confusion on the list is when the Service Function Chain is in some sense "To Be Determined" because one or more of the Service Functions have discretionary rules that leave the next hop in the chain indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the Service Function itself MUST be declared before we can select (by any means) a Service Function Instance.  And once in the midst of evaluating the conditional requirement, we have a finite set of "next Service Functions".  I can define a completely deterministic conditional statement, and we should permit such things and leave them to the implementers to restrict if they want, but my gut says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluation (eg. if this, then that, else that2) in which case the SPI is not indeterminate (that is, entirely unknown until evaluation), merely uncertain (that is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is the example from my first email in this thread."

I see that in some cases, some omniscient system could foresee the backend server (next-hop) a given app flow should go to, in the initial state. Say, if the load balancing algorithm is "round-robin" on the load balancer. But not everything can be foreseen. How would it work for those load balancing algorithms that use real-time metrics like "least number of connections", "least amount of response time", "least bandwidth"? The omniscient system will have to predict what the load balancer will be seeing by the time the first packets show up at the load balancer, and put the predicted server in the SFP?

So while I agree that predetermination is possible is some cases, I'd argue that it's not possible in all cases. The issue is how to deal with those "to be determined" cases. I'm still digesting your "magic thread" explanation.

Regards,

From: sfc [mailto:[email-masked]] On Behalf Of Ian Smith
Sent: 9 July 2014 5:36 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Mostly.

Example:

Example:

Thanks for the write-up.

Do I get that right?

Myo

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

---

From: Ron Parker <[email-masked]>
Date: Wed, 9 Jul 2014 23:28:18 +0000

Ken,

As I pointed out in my previous email, my concern is more about resiliency than elasticity.   I understand the benefits of layered load balancing, but what about when this is hierarchical?   Maria spoke of 20 instances, and the prevailing thinking seems to be that the top-level behavior of the SFC shouldn't care.   But what if the front-end entity fails?   What if its internal redundancy, if any, fails to perform when called upon?   Might the network designer choose to divide the 20 instances into 2 groupings of 10 and have a front-end entity for each grouping?   So now the top-level behavior of the SFC must choose amongst 2 rather than 20 for this particular logical service function.   But a choice still needs to be made.   Is this, too, outside the scope of SFC?   If not, is the architecture going to explicitly address it, or leave it as an implementation issue?

   Ron

________________________________________
From: Ken Gray (kegray) [[email-masked]]
Sent: Wednesday, July 09, 2014 6:39 PM
To: Ron Parker; Jim Guichard (jguichar)
Cc: Joel M. Halpern; [email-masked]; NAPIERALA,  MARIA H; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

---

From: Dave Dolson <[email-masked]>
Date: Wed, 9 Jul 2014 23:52:30 +0000

Ken,
When you say, "hide the detail from you", who is it being hidden from?

You seem to be saying the classifier doesn't need the details. 

I've been thinking the classifier is part of the SFC system and would therefore reasonably be aware of all of the paths. 

In fact, if you want to hide the details from the classifier, you need another classifier-like thing within the system that knows the details. This is a hierarchical implementation. 

So I'm led in the direction that it is ok for all path complexities to be known in the system. 
As soon as you hide stuff, that is creating a hierarchy, which is OK, recognizing it as such.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Jul 2014 22:08:13 -0400

THere are multiple ways that the internal redundancy with the load 
balancers can be implemented.  Any of them can be used with the service 
chaining architecture.
There may be some aspects which need to be covered in the solution work.
For example, I would expect solutions to have to discuss how we cope 
with SFF failure.  And with failure of the linkage between the SFF and 
the SF.

We could add text to the architecture indicating that solutions will 
need to be robust in dealing with failures of service chaining 
components and linkages.  But I think we should not spell out the 
detailed mechanisms for that robustness in this document.

Would adding a small section on robustness issues help?

Yours,
Joel

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 10 Jul 2014 03:30:24 +0000

Fully agree.

Best regards,
Xiaohu

> Sent: Thursday, July 10, 2014 3:41 AM
> The archtiecture allows for this local decision, while still having the global
> decision that is directing the traffic.  That is, the global decision directs the
> traffic to places in the network.  Those places may be singular or clusters.  If
> they are clusters, those clusters can use any number of algorithms to distribute
> the traffic internally, without any effect on service chaining.  (And yes, this can
> be done in such a way that return traffic, if delivered globally to the same place,
> The definition of the service path is about how service chaining will direct the
> traffic.  it is not about how the internal load balancing is doen, as there are
> MANY ways to do that, and they can give the same external interface.
> 
> We could write the architecture pretending that it always addresses singular
> instances, but knowing that reality would allow load balanced clusters at those
> locations.  But that would be a misleading architectural description and might
> be read to outlaw some solutions that fall within the goal the WG wishes to
> meet.
> 
> Yours,
> Joel
> 
> >> with the LB constraints above: deciding which locator to use for a
> >> given flow will be a local decision not a centralized one.
> >

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Jul 2014 03:34:25 +0000

I agree with med that Service function path doesn’t need to be pre-determined.
When multiple instances for the same service function in the service function chain is allowed and different instance choose different locator for the same service function, then one service chain may be corresponding to multiple service function paths. But only one service function path is mapped to service function chain at one time.

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年7月9日 15:05
收件人: Joel M. Halpern; [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Joel,

Please see inline.

Cheers,
Med

 A service path

  Those

  That will

 If it does, and if

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 05:13:05 +0000

The answer lies in the fact that there are a finite number of pool members behind the load balancer and that, at least at the initial state, they each have an equal probability of being selected.  As that decision time moves closer, the probabilities are changing, and maybe the implementation can adjust in real time, or maybe it just waits until it is at the limit (the hop where it is forced to decide) to let all of those probabilities come crashing in at the instant it makes the decision.

>From the outside looking in, I don't think the two methods look different:  you match a flow to a chain, and then you select a path within that chain, it includes a load balancer with four pool members, and at the moment the first packet enters the chain, the probability that it will use the load balancer is 100% but the probability it will go to each of those four pool members is the same - but unknown, so all four are included in the path at the same sequence point.

Example:

path {sfi0, sfi2, sfi3, {sfi4, sfi5, sfi6, sfi7}, sfi8, sfi9}

Translation:  the Service Function Path is an ordered list of Service Function Instances, but occupying position 4 in the sequence are four possible SFI's that the SFI in position 3 in the sequence is going to select one and only one to occupy position 4 in real time using the proscribed method.  The method only matters when SFI3 is actually making the decision.

Example:

path {sfi0, sfi2, sfi3, {opaque}, sfi8, sfi9}

Translation:  here the pool members behind the load balancer aren't included in the path (for whatever reason), but the path still shows that there is a segment there.  The load balancing decision gets made at sfi3, something happens, and then the flow moves to sfi8.

If you were to make a lookup using my toy cli tool, before that decision that resolves the uncertainty is made, you might see something like this:

service-chain 100 path da29c34de0af:0109:6e01e1f421d3

web-optimizer   uncertain                   2001:db8:0:22::80:[137..140].80  fastest

It shows that the Service Function Instance for the Service Function "web-optimizer" hasn't been selected.  It also shows that there are four consecutively numbered possibilities, and tells you that response time will be used to make the decision.

One "magic-thread" scenario might look something like this:  Instead of picking a path through a chain, I'm assigned a path id da29c34de0af:0109:6e01e1f421d3, some sort of multicast or anycast or ecmp scheme gets used and for each position in the sequence, I show up a random Service Function Instance.  The SFI reads my header, identifies me as user 6e01e1f421d3 and notes that the policy that should be applied is chain 0109 in domain da29c34de0af and it verifies that it knows what that policy is.  It does whatever it is supposed to do, and forwards me to the next hop as indicated in the policy.  Then it reports that da29c34de0af:0109:6e01e1f421d3 paid it a visit and was successfully sent along the chain.

It knows the policy because every policy in the Service Function Domain is known by every Service Function Instance it applies to.  Some mechanism beyond the scope of the WG is responsible to make sure that happens.  In the real world today, that is done with Diameter or NETCONF or an orchestration framework.

Certainly, there are thought experiments that will poke holes in any of these ideas:

What if you provision a new pool member after the path selection has been made, but before the decision has been made, and you are supposed to pick the least busy pool member?
  (make the right choice and report why you did so the path can be updated, just like you would if there were four pool members)

What if one of the pool members disappears in the same interval?
    (same thing)

What if a SFI doesn't know the policy for the path-id?
    (perform your default action)

There are lots of "what-if's?" that tend to be well managed by reasonable default actions.  The architecture needs to be able to handle the middle 80% of use cases and give reasonable guidance about what to do at the extremes in that liminal state between normal and catastrophe so that implementers can wrestle with them.

Sent: Wednesday, July 09, 2014 7:20 PM

…”predetermination is that it is possible in the initial state, but not important”…

“Where I perceive confusion on the list is when the Service Function Chain is in some sense "To Be Determined" because one or more of the Service Functions have discretionary rules that leave the next hop in the chain indeterminate until a packet presents itself to the Service Function Instance (mostly because of middle-boxes), but the Service Function itself MUST be declared before we can select (by any means) a Service Function Instance.  And once in the midst of evaluating the conditional requirement, we have a finite set of "next Service Functions".  I can define a completely deterministic conditional statement, and we should permit such things and leave them to the implementers to restrict if they want, but my gut says that most of the conditional rules will be of the sort where all the possible outcomes MAY be foreseen before evaluation (eg. if this, then that, else that2) in which case the SPI is not indeterminate (that is, entirely unknown until evaluation), merely uncertain (that is, which of these possible outcomes is more likely), which is significantly easier to deal with.  That is the example from my first email in this thread.”

I see that in some cases, some omniscient system could foresee the backend server (next-hop) a given app flow should go to, in the initial state. Say, if the load balancing algorithm is “round-robin” on the load balancer. But not everything can be foreseen. How would it work for those load balancing algorithms that use real-time metrics like “least number of connections”, “least amount of response time”, “least bandwidth”? The omniscient system will have to predict what the load balancer will be seeing by the time the first packets show up at the load balancer, and put the predicted server in the SFP?

So while I agree that predetermination is possible is some cases, I’d argue that it’s not possible in all cases. The issue is how to deal with those “to be determined” cases. I’m still digesting your “magic thread” explanation.

Regards,

Mostly.

I've been defining things like this:
·         Service Function Domain as the logical area in which Service Function Chains are defined.  There are various names for them but basically all the architectures define an "ingress" and an "egress" node that anchors a chain at each end - this is the space between them.
·         Service Function Chain as "an ordered sequence of a finite number of functions"
·         Service Function Path as "an ordered sequence of particular instances of service functions within a Service Function Chain".
·         Service Function as an abstract thing - "URL Filter"
·         Service Function Node as the physical piece of hardware that houses the Service Function - "this server"
·         Service Function Instance as a particular instance of a service function - "this URL Filter on this Service Function Node" - and it can be a virtual machine, a container, or just an instance of software on the SFN.

Example:

Example:

Thanks for the write-up.

Do I get that right?

Myo

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

---

From: Sharon <[email-masked]>
Date: Wed, 9 Jul 2014 22:32:39 -0700

If I understand correctly, the dilemma is that 
- on one hand there is no limit to what is meant by "load-balancing":
It may be a deep application content changing function, or a simple NAT of VIPs.
- On the other a static architecture is too rigid to scale and make highly available.

It may lead to too much "hair splitting" . 
To take it to extreme,  in a distributed overlay network with SFFs scattered in enough locations,
but not in every host, a single service-function hop can be:

SFF - NVE - NVE - SLB - NVE - NVE - NF - NVE - NVE - SFF

If implemented literally the latency-jitter and consequently utilization will be quite bad.

So a language that allows an SFF to work with balanced VNF pools,
and that allows for multi-home SFF to VNF pooling can help. 

--szb

> On Jul 9, 2014, at 19:08, "Joel M. Halpern" <[email-masked]> wrote:
> 
> THere are multiple ways that the internal redundancy with the load balancers can be implemented.  Any of them can be used with the service chaining architecture.
> For example, I would expect solutions to have to discuss how we cope with SFF failure.  And with failure of the linkage between the SFF and the SF.
> 
> We could add text to the architecture indicating that solutions will need to be robust in dealing with failures of service chaining components and linkages.  But I think we should not spell out the detailed mechanisms for that robustness in this document.
>

---

From: <[email-masked]>
Date: Thu, 10 Jul 2014 06:28:56 +0000

Joel,

I'm afraid you are making some deployment assumptions. 

How SF are deployed whether in separate physical nodes, as co-located virtual instances, separated virtual instances, ...or a mix of those is really deployment-specific. The point is that these SF instances are offering the service, as such they must be considered as bound to the same logical service (identified by a single service function identifier). For a given chain, when invoking a given SF is required, how the traffic will be directed to one of available SF instances is also deployment-specific. It is up to the taste of each operator to decide how to proceed. 

Furthermore, we should not mandate an operator how to structure its chains. For example, we should not mandate that it must declare a cluster as a SF.

The key information needed to forward traffic is the service chain itself (that is characterized as an order list of service function identifiers). The forwarding path will be the result of policies configured in a given SFC-enabled domain.

Cheers,
Med

>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mercredi 9 juillet 2014 22:26
>À : NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN; [email-masked]
>(make a load balancing decision) at the entry to the chain which of those
>20 firewalls will be used by a particular flow?
>>
>> Maria
>>

---

From: <[email-masked]>
Date: Thu, 10 Jul 2014 06:33:18 +0000

Hi Ian,

I fully agree with the following:

"Where the Service Function Path is defined is, in my mind, somewhat irrelevant to the architecture.  It does exist, and by definition it exists because packets are moving along it. "

Cheers,
Med

De : Ian Smith [mailto:[email-masked]]
Envoyé : mercredi 9 juillet 2014 23:36
À : Zarny, Myo; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; BOUCADAIR Mohamed IMT/OLN
Cc : 'Joel M. Halpern'; [email-masked]'
Objet : RE: [sfc] Service Chains, Paths, and Load Balancers

Mostly.

Example:

Example:

Thanks for the write-up.

Do I get that right?

Myo

-----Original Message-----
From: Ian Smith [mailto:[email-masked]]
Sent: 9 July 2014 2:54 PM
To: Zarny, Myo [Tech]; 'Nobo Akiya (nobo)'; 'Carlos Pignataro (cpignata)'; 'Med Boucadair'
Cc: 'Joel M. Halpern'; [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Jul 2014 06:40:33 +0000

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月9日 20:41
收件人: [email-masked]; Joel M. Halpern; [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

[Qin]: An ordered list of locators can be determined by PCE or any other path management component in the control plane after service function chain structure. 
If any locator for a logical service function changes (e.g., the first service function following classifier has multiple instance), PCE can send an updated locator associated with this logical service function to the classifier.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 09, 2014 3:05 AM
To: Joel M. Halpern; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Joel,

Please see inline.

Cheers,
Med

 A service path

  Those

  That will

 If it does, and if

---

From: Qin Wu <[email-masked]>
Date: Thu, 10 Jul 2014 06:47:30 +0000

Your second paragraph raises a very good question. But my interpretation to your last paragraph is
SFC and SFP are both needed. But SFC is first structured and then SFC need to be translated into SFP since in some cases (mentioned in this thread), one SFC may be
Corresponding to multiple SFPs.

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年7月10日 4:03
收件人: [email-masked]; [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 10 Jul 2014 06:55:23 +0000

Hi Ken,

Please see inline.

Cheers,
Med

>De : Ken Gray (kegray) [mailto:[email-masked]]
>Envoyé : mercredi 9 juillet 2014 21:42
>À : NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern;
>[email-masked]

[Med] This is not a valid argument. The current merged draft does not define what exact state information is provisioned/maintained by an SF but you can easily imagine that an SFF is configured with a list of locators of all next hops of chains it must process. It is not true that the only solution to the problem is to mandate some kind of source routing.

  A service path

---

From: <[email-masked]>
Date: Thu, 10 Jul 2014 07:05:47 +0000

Re-,

The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.

Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.

SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 9 juillet 2014 22:03
À : [email-masked]; [email-masked]
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 10 Jul 2014 11:16:02 +0000

On Jul 9, 2014, at 4:02 PM, [email-masked]<mailto:[email-masked]> wrote:

Ultimately, somewhere, the chain must be resolved into a path and that path must be identified for dataplane forwarding.  Whether this resolution occurs locally, or not is an implementation choice.

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Jul 2014 12:50:56 +0000

Sharon,

I agree with your point.   Let's all be clear -- service function chaining already exists.   The charter of this WG is to improve upon it.   Those improvements are along the lines of simplicity, efficiency, scale, flexibility, and last but not least availability.

 The architecture should allow for, but not require, discrete service function load balancer functions.   If the existence of a service function load balancer is an explicit and optional aspect of the architecture, it should be identified as such.   With or without service function load balancers, the architecture should explicitly account for any points of failure without making simplifying assumptions like involved nodes are on the same L3 subnet or on the same L2 domain.   How specific (constraining) the architecture needs to be wrt these failure domains is for further study, but the architecture should call out the overall system behavior in the event of these inevitable failures.    All of this factors heavily into the centralized vs distributed aspects of the solution and the eventual control plane requirements, if any.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Sharon
Sent: Wednesday, July 09, 2014 5:11 PM
To: Joel M. Halpern
Cc: [email-masked]; [email-masked]; NAPIERALA, MARIA H
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

--szb

>>> balancing is doen, as there are MANY ways to do that, and they can 
>>> give the same external interface.
>>> 
>>> balanced clusters at those locations.  But that would be a 
>>> misleading architectural description and might be read to outlaw 
>>> some solutions that fall within the goal the WG wishes to meet.
>>> 
>>> Yours,
>>> Joel
>>> 
>>>>> based on

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Jul 2014 13:34:23 +0000

Current definition is clear to me from architecture perspective. If some product only supports SFP or SFC, it is clearly that another product is needed to support both SFP and SFC to make them work together.  Architecture doc. should not make any constraint on it.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 6:16 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 09:57:42 -0400

I am happy to add text to the architecture pointing out failure points 
where the solutions must provide suitable robustness.  That seems to be 
architectural in nature, valuable to the working group, and accurate.

Where I get concerned is if the request is to describe in teh 
architecture how robustness and failover will be done.  There are many 
alternatives.  Some probably just won't work.  Some will likely fall 
outside the solutions the WG adopts.  And many others will interoperate 
and work with the solution(s) the working group adopts.

So I would ask folks, and particularly Sharon and Ron, what level of 
specificity they feel belongs in this document.

Yours,
Joel

On 7/10/14, 8:50 AM, Ron Parker wrote:
> Sharon,
>
> I agree with your point.   Let's all be clear -- service function
> chaining already exists.   The charter of this WG is to improve upon
> it.   Those improvements are along the lines of simplicity,
> efficiency, scale, flexibility, and last but not least availability.
>
> The architecture should allow for, but not require, discrete service
> function load balancer functions.   If the existence of a service
> function load balancer is an explicit and optional aspect of the
> architecture, it should be identified as such.   With or without
> service function load balancers, the architecture should explicitly
> account for any points of failure without making simplifying
> assumptions like involved nodes are on the same L3 subnet or on the
> same L2 domain.   How specific (constraining) the architecture needs
> to be wrt these failure domains is for further study, but the
> architecture should call out the overall system behavior in the event
> of these inevitable failures.    All of this factors heavily into the
> centralized vs distributed aspects of the solution and the eventual
> control plane requirements, if any.
>
> Ron
>
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of Sharon Sent: Wednesday, July 09, 2014 5:11 PM To: Joel M.
> Halpern Cc: [email-masked]; [email-masked]; NAPIERALA,
> MARIA H Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
>
> If we translate the draft standards literally to products this way we
> will end up chaining a bunch of load balancers, that's it. These will
> in-turn need to figure what function to chain for this punt. That's
> not enough progress in most cases over stitching load balancers with
> vlans. Perhaps we need to draft an informational on how to build one
> distributed - interoperable load balancer using the SFC spec ?
>
> --szb
>
>> them as such, and would use distinct service paths. Alternative, if
>> you as the operator choose to deploy them as a cluster, with
>> sutiable load balancing, such that they appear as a single place
>> Yours, Joel
>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: I had in mind
>>> singular instances, say, 20 virtual firewall instances somewhere
>>> in the middle of a chain. Are you saying that you will decide
>>> (make a load balancing decision) at the entry to the chain which
>>> of those 20 firewalls will be used by a particular flow?
>>>
>>> Maria
>>>
>>>> -----Original Message----- From: sfc
>>>> [mailto:[email-masked]] On Behalf Of Joel Halpern Direct
>>>> Sent: Wednesday, July 09, 2014 3:41 PM To: NAPIERALA, MARIA H;
>>>> [email-masked]; [email-masked] Subject: Re: [sfc]
>>>> Yours, Joel
>>>> _______________________________________________ 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
>
> _______________________________________________ sfc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Jul 2014 14:01:59 +0000

I am happy to add text to the architecture pointing out failure points where the solutions must provide suitable robustness.  That seems to be architectural in nature, valuable to the working group, and accurate.

[Lucy] agree.

Where I get concerned is if the request is to describe in teh architecture how robustness and failover will be done.  There are many alternatives.  Some probably just won't work.  Some will likely fall outside the solutions the WG adopts.  And many others will interoperate and work with the solution(s) the working group adopts.
[Lucy] Agree too. So the arch doc should not describe implementation choice and judge which works and which not.

Lucy

So I would ask folks, and particularly Sharon and Ron, what level of specificity they feel belongs in this document.

Yours,
Joel

On 7/10/14, 8:50 AM, Ron Parker wrote:
>> then the service chaining infrastructure would treat them as such, 
>> and would use distinct service paths. Alternative, if you as the 
>> operator choose to deploy them as a cluster, with sutiable load 
>> balancing, such that they appear as a single place for service 
>>> On 7/9/14, 4:00 PM, NAPIERALA, MARIA H wrote: I had in mind singular 
>>> instances, say, 20 virtual firewall instances somewhere in the 
>>> middle of a chain. Are you saying that you will decide (make a load 
>>> balancing decision) at the entry to the chain which of those 20 
>>>> -----Original Message----- From: sfc [mailto:[email-masked]] 
>>>> On Behalf Of Joel Halpern Direct
>>>> global decision directs the traffic to places in the network.  
>>>> Those places may be singular or clusters.  If they are clusters, 
>>>> those clusters can use any number of algorithms to distribute the 
>>>> traffic internally, without any effect on service chaining.  (And 
>>>> yes, this can be done in such a way that return traffic, if 
>>>> delivered globally to the same place, can then be delivered to the 
>>>> right internal state.)
>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 10:15:41 -0400

There are things permitted by th architecture which would be a REALLY 
BAD IDEA in practice.  As far as I can tell, all of the solutions people 
would like to use for this also have the property that there are ways to 
deploy them which would be REALLY BAD IDEAS.

To take an extreme example, any architecture and any solution we define 
for service chaining will likely allow folks to expose a cominatorial 
explosion of instances if they insist in their deployment on moving all 
selection at all levels of granularity to whatever central point the 
solution has.  Given that all solutions have some amount of central 
provisioning and control, all solutions allow such.  I presume that none 
of them would mandate such.

So observing that taken to an extreme and applied badly the archtiecture 
allows solutions with really bad properties will be true even when the 
wroking group finishes their work.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 10:20:44 -0400

The question I was asekd was about the case with 20 virtual instances. 
The archtiecture allows for an arbitrary mixture of virtual and physical 
(and any other kind you care for) service function realizations.  I have 
not assumed anything in particular about that.

The architecture does not mandate how operators structure their service 
chains.  It does not mandate how they deploy their services.

You say that the key to forwarding is the service chain.  But, as we 
have defined it in the document, the service chain does not have eough 
information for a packet forwarder to use it to forward.  If you 
provision information in the network to use a service chain name of some 
kind to drive forwarding then you are creating a 1-1 relationship 
between the service chain identification and service path 
identification.  The purpose of the separation is to allow for there to 
be multiple paths in the network for forwarding packets that are used to 
realize the service chains.
The reason for calling out the service path identification in the packet 
is that if there are multiple such realizations, the packet forwarding 
needs information to be able to tell which such forwarding path this 
packet is using.

Yours,
Joel

On 7/10/14, 2:28 AM, [email-masked] wrote:
> How SF are deployed whether in separate physical nodes, as co-located
> virtual instances, separated virtual instances, ...or a mix of those
> is really deployment-specific. The point is that these SF instances
> are offering the service, as such they must be considered as bound to
> the same logical service (identified by a single service function
> identifier). For a given chain, when invoking a given SF is required,
> how the traffic will be directed to one of available SF instances is
> also deployment-specific. It is up to the taste of each operator to
> decide how to proceed.
>
> Furthermore, we should not mandate an operator how to structure its
> chains. For example, we should not mandate that it must declare a
> cluster as a SF.
>
> The key information needed to forward traffic is the service chain
> itself (that is characterized as an order list of service function
> identifiers). The forwarding path will be the result of policies
> configured in a given SFC-enabled domain.
>
> Cheers, Med
>
>> -----Message d'origine----- De : Joel M. Halpern
>> [mailto:[email-masked]] Envoyé : mercredi 9 juillet 2014
>> 22:26 À : NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN;
>> [email-masked] Objet : Re: [sfc] Service Chains, Paths, and Load
>> Balancers
>>
>> And the operator could choose a hybrid, for exanmple, deploying
>> two clusters of 10 each, requiring two service paths.
>>
>> diversity or because there was a policy reason to distinguish
>> them. While clusters would typically be used to allow the scale-in
>> and scale-out to occur without affecting service chaining.
>>
>> which of those 20 firewalls will be used by a particular flow?
>>>
>>> Maria
>>>
>>>>>> service
>>>>>> identifiers). This is more compliant with the LB
>>>>>> constraints above:
>>>> deciding

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Jul 2014 15:04:56 +0000

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 10, 2014 2:06 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Re-,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 9 juillet 2014 22:03
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Jul 2014 15:19:46 +0000

It is architecturally significant to identify that multiple addressable instances of a service function are explicitly allowed.   Whether those instance perform some further level of load balancing is irrelevant, as has been pointed out by Joel.    It is also architecturally significant to assign responsibility for instance selection.    In particular, is the instance selection centralized, distributed, or some combination?   Which functional entities in the architecture have what responsibilities to achieve this?   In November, 2013, after IETF 88, I submitted this draft, http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner.   That was just a proposal and I am not wedded to it, by any means.    Joel asked about specificity and it is at this level that I’d like to see the architecture describe things.   It should be able to answer the question, “how does multi-instance selection work in SFC?” in a concise manner.   If the group feels that there should be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly.    Of course, that is merely one such question and there are many others that an architectural document should be able to describe.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 10, 2014 2:06 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Re-,

Cheers,
Med

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 16:02:07 +0000

One of the main problems in "service chains" is how to implement a service that is conceptually one hop but scaled horizontally as 10 or 100 different VMs.
So, IMO, if we are not addressing this problem than what are we solving.

Maria

> Sent: Wednesday, July 09, 2014 6:17 PM
> To: Ron Parker
> I should clarify that my statement was made as a personal opinion and it is
> up to the WG to evaluate if there exists anything at the architectural level
> that is new and therefore needs to be addressed.
> 
> Sent from my iPhone
> 
> > Respectfully, I'm not comfortable with that.   While it is easy to say that
> this is a layered problem and that load balancing belongs at a lower level, it
> seems to me that load balancing of the service functions (not load balancer
> as a service function) should be an explicit consideration of the SFC
> architecture.    I say this not only from a scale perspective, but also with
> resiliency in mind.
> >
> >   Ron
> >
> >
> >> Cc: NAPIERALA, MARIA H; Joel M. Halpern;
> [email-masked];
> >> [email-masked]
> >>>>> On Jul 9, 2014, at 4:50 PM, "NAPIERALA, MARIA H"
> <[email-masked]>
> >>>>> wrote:
> >>>>>

---

From: Eric Gray <[email-masked]>
Date: Thu, 10 Jul 2014 16:07:43 +0000

Maria,

Load distribution is not the same as service function chaining and - while there may be
problems to solve in this area - why would we assume that SFC is supposed to solve
them?

I think SFC should be more concerned about ensuring that function chaining solutions 
do not preclude load distribution.

--
Eric

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Thursday, July 10, 2014 12:02 PM
To: Jim Guichard (jguichar); Ron Parker
Cc: Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria

> I should clarify that my statement was made as a personal opinion and 
> it is up to the WG to evaluate if there exists anything at the 
> architectural level that is new and therefore needs to be addressed.
> 
> Sent from my iPhone
> 
> this is a layered problem and that load balancing belongs at a lower 
> level, it seems to me that load balancing of the service functions 
> (not load balancer as a service function) should be an explicit consideration of the SFC
> >> Well of course not; in that case you load balance up a level 
> >> between
> those nodes and then locally.
> >>
> >> Sent from my iPhone
> >>
> >>>>> Absolutely and categorically no! If you have 20 instances at 
> >>>>> each hop then you can choose to load balance among them locally 
> >>>>>>> separately, then the service chaining infrastructure would 
> >>>>>>> treat them as such, and would use distinct service paths.
> >>>>>>
> >>>>> to globally manage 160,000 service paths (for one chain)? Well, 
> >>>>> we have yet to see a solution that work this way and scales..
> >>>>>>
> >>>>>> Maria
> >>>>>>
> >>>>>>> somewhere in the middle of a chain. Are you saying that you 
> >>>>>>> will decide (make a load balancing decision) at the entry to 
> >>>>>>> the chain which of those
> >>>>> 20
> >>>>>>>>> having the global decision that is directing the traffic.  
> >>>>>>>>> That is, the global decision directs the traffic to places 
> >>>>>>>>> in the network.  Those places may be singular or clusters.  
> >>>>>>>>> If they are clusters, those clusters can use any number of 
> >>>>>>>>> algorithms to distribute the traffic internally, without any 
> >>>>>>>>> effect on service chaining.  (And yes, this can be done in 
> >>>>>>>>> such a way that return traffic, if delivered globally to the 
> >>>>>>>>> same place, can then be delivered to the right internal 
> >>>>>>>>> state.)
> >>>>>>>>>
> >>>>>>>>> internal load balancing is doen, as there are MANY ways to 
> >>>>>>>>> do that, and they can give the same external interface.
> >>>>>>>>>
> >>>>>>>>> read to outlaw some solutions that fall within the goal the 
> >>>>>>>>> WG
> wishes to meet.
> >>>>>>>>>
> >>>>>>>>> Yours,
> >>>>>>>>> Joel
> >>>>>>>>>
> >>>>>>>>>>> advance for all deployments. I suggest that SFC forwarding 
> >>>>>>>>>>> be based
> >>>>>>> on
> >>>>>>>>> the
> >>>>>>>>>>> service function identifiers). This is more compliant with 
> >>>>>>>>>>> the
> LB constraints above:
> >>>>>>>>> deciding

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 12:08:56 -0400

That is clearly an important problem in building a full solution to the 
service chaining needs of operators (e.g. you).  However, I could 
equally observe that if you do not have OSS/BSS capable of provisioning 
service chains, or charging systems capable of turning them into 
revenue, you can't offer them.

The SFC working group is tasked with one part of the whole service chain 
definition, construction, and deployment problem.  As I read the 
charter, general load balancing issues are not part of our scope.
Given the number of different ways there are of doing load balancing, it 
would strike me as very odd for the sfc working group to standardize a 
particular answer to the important and difficult problem you point to.

The architecture (and I believe most of the solutions) is designed to 
provide tools that help with managing that scaling, while also allowing 
for the use of other tools.
If the working group wants us to be more specific in the load balancing 
architecture, then if the chairs tell us to we will add more specific 
text.  I would be surprised personally if we had agreement on such a 
goal, or agreement on how to fill such a goal.  But Carlos and I will of 
course do what the chairs tell us the WG wants.

Yours,
Joel

---

From: Sharon <[email-masked]>
Date: Thu, 10 Jul 2014 09:10:19 -0700

Joel I agree 100%.

Unfortunately I do see both of these ("really bad") extremes in prominent industry forums dealing with inline network functions. These extremes as you stated are 1) expecting a centralized system to orchestrate an explosive amount of static permutations, truly an NP undertaking - good luck .. and 2) putting forth such fragmented solutions of vSwitches, ADC-VMs, and NF-VMs, that grantee the network back-pressures and blocks application demand.  I think this group/docs/forum can provide the better guidance.

--szb

> On Jul 10, 2014, at 7:15, "Joel M. Halpern" <[email-masked]> wrote:
> 
> There are things permitted by th architecture which would be a REALLY BAD IDEA in practice.  As far as I can tell, all of the solutions people would like to use for this also have the property that there are ways to deploy them which would be REALLY BAD IDEAS.
> 
> To take an extreme example, any architecture and any solution we define for service chaining will likely allow folks to expose a cominatorial explosion of instances if they insist in their deployment on moving all selection at all levels of granularity to whatever central point the solution has.  Given that all solutions have some amount of central provisioning and control, all solutions allow such.  I presume that none of them would mandate such.
> 
> So observing that taken to an extreme and applied badly the archtiecture allows solutions with really bad properties will be true even when the wroking group finishes their work.
> 
> Yours,
> Joel
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 16:28:46 +0000

Eric,

> problems to solve in this area - why would we assume that SFC is supposed

Because this is the fundamental problem in service chaining in virtualized environments.  
I would be cautious to leave it just to implementation because if fundamentals are wrong implementation might not be able to help.

> do not preclude load distribution.

How would you ensure it?

> One of the main problems in "service chains" is how to implement a service
> that is conceptually one hop but scaled horizontally as 10 or 100 different
> VMs.
> > Cc: Joel M. Halpern; [email-masked]; NAPIERALA,
> MARIA H;
> > [email-masked]

---

From: "Changcheng Huang" <[email-masked]>
Date: Thu, 10 Jul 2014 09:31:19 -0700

I agree with Ron’s comments. Service functions should make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network. If a service function chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants, it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this issue in a more general architecture. Hope it can be helpful for this discussion.

Chang 

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

   Ron

Lucy

Re-,

Cheers,

Med

 

  _____  

From: [email-masked] <mailto:[email-masked][email-masked]> <[email-masked]>
To: [email-masked] <mailto:[email-masked][email-masked]> <[email-masked]>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Jul 2014 16:47:52 +0000

From Ron: It should be able to answer the question, “how does multi-instance selection work in SFC?” in a concise manner.

How about: The architecture allows implementing single SFP or multiple SFPs to support SF multi-instances in SFC. In the first case, instance selection is opaque to the SFP; in latter case, instance selection, in turn, becomes SFP selection.

Lucy
From: Changcheng Huang [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 11:31 AM
To: 'Ron Parker'; Lucy yong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Chang

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Thursday, July 10, 2014 8:20 AM
To: Lucy yong; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, July 10, 2014 11:05 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 10 Jul 2014 16:50:58 +0000

Joel,

I concur.  The goal here is to address the issues associated with generic service function deployment and should enable localized decisions such as load balancing (perhaps more accurately load distribution).  Clearly we sound’t codify how load distribution works.  

In order to enable load distribution, for example, the right abstractions been to be clearly defined in the architecture, a key one bering the distinction between path vs. chain.

Paul

On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <[email-masked]> wrote:

> That is clearly an important problem in building a full solution to the service chaining needs of operators (e.g. you).  However, I could equally observe that if you do not have OSS/BSS capable of provisioning service chains, or charging systems capable of turning them into revenue, you can't offer them.
> 
> The SFC working group is tasked with one part of the whole service chain definition, construction, and deployment problem.  As I read the charter, general load balancing issues are not part of our scope.
> Given the number of different ways there are of doing load balancing, it would strike me as very odd for the sfc working group to standardize a particular answer to the important and difficult problem you point to.
> 
> The architecture (and I believe most of the solutions) is designed to provide tools that help with managing that scaling, while also allowing for the use of other tools.
> If the working group wants us to be more specific in the load balancing architecture, then if the chairs tell us to we will add more specific text.  I would be surprised personally if we had agreement on such a goal, or agreement on how to fill such a goal.  But Carlos and I will of course do what the chairs tell us the WG wants.
> 
> Yours,
> Joel
>

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 17:01:12 +0000

>Service functions should make the decision about which instances will be used

I think it is sufficient for the architecture to say,

"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

But you also say need to say,

"Service Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

and,

"External orchestration frameworks MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

All three result in a Service Function Path being selected, and they aren't necessarily exclusive of one another if you have rules for resolving conflicts; the details of those rules are not architectural.

IMO, the architecture needs to err on the side of being descriptive over being proscriptive when there is a conflict between the two.

________________________________
From: sfc [[email-masked]] on behalf of Changcheng Huang [[email-masked]]
Sent: Thursday, July 10, 2014 12:31 PM
To: 'Ron Parker'; 'Lucy yong'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Chang

   Ron

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 14:34:10 -0400

Is it service function that makes that decision? or the service function instance?

From: [email-masked]<[email-masked]>
To: Changcheng Huang<[email-masked]>,'Ron Parker'<[email-masked]>,'Lucy yong'<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

P {margin-top:0;margin-bottom:0;}

>Service
 functions should make the decision about which instances will be used

"Service
 Function Classifiers (or SNF's or SFF's, as the case may be) MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

and, 

"External
 orchestration frameworks MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."

All
 three result in a Service Function Path being selected, and they aren't necessarily exclusive of one another if you have rules for resolving conflicts; the details of those rules are not architectural.

 

I agree with Ron’s comments. Service functions should make the decision about which instances will be used. It can be different hop-by-hop (e.g. in a tree
 topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network. If a service function chain wants to use multiple SFPs,
 it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants, it does need to identify different tenants. Our recent
 contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) has discussed this issue in a more general architecture.
 Hope it can be helpful for this discussion.
 
Chang

From: sfc [mailto:[email-masked]]
On Behalf Of Ron Parker

 
It is architecturally significant to identify that multiple addressable instances of a service function are explicitly allowed.   Whether those instance perform
 some further level of load balancing is irrelevant, as has been pointed out by Joel.    It is also architecturally significant to assign responsibility for instance selection.    In particular, is the instance selection centralized, distributed, or some combination?
   Which functional entities in the architecture have what responsibilities to achieve this?   In November, 2013, after IETF 88, I submitted this draft,

http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner.   That was just a proposal and I am not wedded to it, by any
 means.    Joel asked about specificity and it is at this level that I’d like to see the architecture describe things.   It should be able to answer the question, “how does multi-instance selection work in SFC?” in a concise manner.   If the group feels that
 there should be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly.    Of course, that is merely one such question and there are many others that an architectural document
 should be able to describe.
 
   Ron

From: sfc [mailto:[email-masked]]
On Behalf Of Lucy yong

To: [email-masked];
[email-masked]; 
[email-masked]; [email-masked]

 
 
Lucy

From: sfc [mailto:[email-masked]]
On Behalf Of [email-masked]

To: [email-masked];
[email-masked]; 
[email-masked]

 
Re-,

Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various
 deployment contexts.
 
SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How
 that information is used to infer forwarding actions is a solution-oriented discussion.
 
Cheers,
Med

De : sfc [mailto:[email-masked]]
De la part de [email-masked]

À : [email-masked];
[email-masked]

 

Is anyone still questioning the difference between SF Chain and SF Path?  Other than clarifying the definition so that it's clear to those not familiar with the draft, it
 seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the
 path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.  

If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting
 SFP and others only supporting SFC.

 

group intends.

if that helps.

in any solution.

place in the network.

re-classification point.

Yours,

Joel

sfc mailing list

[email-masked]

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Jul 2014 18:36:52 +0000

Hi, Mike.

Between service function and service function instance, I think it would have to be the instance, since the former is conceptual.    But, in a distributed path selection approach, might it make sense to assign this duty to the service function forwarder (SFF)?

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 10, 2014 2:34 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Changcheng Huang<[email-masked]<mailto:[email-masked]>>,'Ron Parker'<[email-masked]<mailto:[email-masked]>>,'Lucy yong'<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

and,

From: sfc [[email-masked]<mailto:[email-masked]>] on behalf of Changcheng Huang [[email-masked]<mailto:[email-masked]>]
To: 'Ron Parker'; 'Lucy yong'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 18:40:07 +0000

I personally think that the service function is an abstract idea - "url filter" and the service function instance is the instantiation of that idea - "this url-filter".

But the OP I was responding to is part of a thread where Service Function was being used to mean that some functionality within the service function presents a common end-point and then  distributes traffic to particular instances in an opaque way that sounds like a load-balancer or ipv6 anycast end-point.

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, July 10, 2014 2:34 PM
To: Ian Smith; [email-masked]
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

and,

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 14:55:12 -0400

I've stated before that I think we should differentiate between load balancing and load distribution where load balancing refers to the standard service function that we all know and love (outside of SFC) and load distribution refers to the selection of an SFI (i.e. Chain -> Path mapping).  Not using different terms to distinguish between these leads to confusion.

e.g. a SF Chain* might exist whose SFs consist only of load balancers.  But you might still want SFC* to distribute load to multiple load balancer instances.

*trying to distinguish between SFC as "Service Function Chaining" and a single "Service Function Chain".

From: [email-masked]<[email-masked]>
To: Joel M. Halpern<[email-masked]>
cc: Jim Guichard (jguichar)<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,Ron Parker<[email-masked]>,NAPIERALA,
 MARIA H<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Joel,

Paul

On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <[email-masked]> wrote:> That is clearly an important problem in building a full solution to the service chaining needs of operators (e.g. you).  However, I could equally observe that if you do not have OSS/BSS capable of provisioning service chains, or charging systems capable of turning them into revenue, you can't offer them.> > The SFC working group is tasked with one part of the whole service chain definition, construction, and deployment problem.  As I read the charter, general load balancing issues are not part of our scope.> Given the number of different ways there are of doing load balancing, it would strike me as very odd for the sfc working group to standardize a particular answer to the important and difficult problem you point to.> > The architecture (and I believe most of the solutions) is designed to provide tools that help with managing that scaling, while also allowing for the use of other tools.> If the working group wants us to be more specific in the load balancing architecture, then if the chairs tell us to we will add more specific text.  I would be surprised personally if we had agreement on such a goal, or agreement on how to fill such a goal.  But Carlos and I will of course do what the chairs tell us the WG wants.> > Yours,> Joel> > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote:>> One of the main problems in "service chains" is how to implement a service that is conceptually one hop but scaled horizontally as 10 or 100 different VMs.>> So, IMO, if we are not addressing this problem than what are we solving.>> >> Maria>> > > _______________________________________________> sfc mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 15:01:56 -0400

The term "load distribution" works for me.  I agree that there is value 
in differentiating the functions, and using different words usually 
helps such differentiation.

Yours,
Joel

On 7/10/14, 2:55 PM, [email-masked] wrote:
> I've stated before that I think we should differentiate between load
> balancing and load distribution where load balancing refers to the
> standard service function that we all know and love (outside of SFC) and
> load distribution refers to the selection of an SFI (i.e. Chain -> Path
> mapping).  Not using different terms to distinguish between these leads
> to confusion.
>
> e.g. a SF Chain* might exist whose SFs consist only of load balancers.
>   But you might still want SFC* to distribute load to multiple load
> balancer instances.
>
> ------------------------------------------------------------------------
> *From: [email-masked]<[email-masked]>
> *To: *Joel M. Halpern<[email-masked]>
> *cc: *Jim Guichard
> (jguichar)<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,Ron
> Parker<[email-masked]>,NAPIERALA, MARIA H<[email-masked]>
> *Sent: *Thursday, July 10, 2014
> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Joel,
>
> I concur. The goal here is to address the issues associated with generic
> service function deployment and should enable localized decisions such
> as load balancing (perhaps more accurately load distribution). Clearly
> we sound’t codify how load distribution works.
>
> In order to enable load distribution, for example, the right
> abstractions been to be clearly defined in the architecture, a key one
> bering the distinction between path vs. chain.
>
> Paul
>
>
>
>  > That is clearly an important problem in building a full solution to
> the service chaining needs of operators (e.g. you). However, I could
>  > The SFC working group is tasked with one part of the whole service
> chain definition, construction, and deployment problem. As I read the
>  > Given the number of different ways there are of doing load balancing,
> it would strike me as very odd for the sfc working group to standardize
> a particular answer to the important and difficult problem you point to.
>  >
>  > If the working group wants us to be more specific in the load
> balancing architecture, then if the chairs tell us to we will add more
> specific text. I would be surprised personally if we had agreement on
> such a goal, or agreement on how to fill such a goal. But Carlos and I
> will of course do what the chairs tell us the WG wants.
>  >
>  > Yours,
>  > Joel
>  >
>  >> One of the main problems in "service chains" is how to implement a
> service that is conceptually one hop but scaled horizontally as 10 or
> 100 different VMs.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 10 Jul 2014 19:02:37 +0000

Lucy,

Overall I concur, as you say: a path ID drives the forwarding.  I’d make the minor change: the path identifier can be used to derive the needed forwarding and associated transport.

It is _not_ the transport, but rather is used to simply identify the service path (or graph) that packets must traverse.  By having a path identifier, the exact indirection that people seem to be asking for on this thread can be simply be implemented.  The path identifier provides nothing more than a lookup, that lookup can result in a one or more (equal or weighted) transport next hop(s).

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: Changcheng Huang <[email-masked]>
Date: Thu, 10 Jul 2014 12:55:26 -0700

As defined in the problem statement document, a service function is not 
a concept. Here is the quote from the document "A Service Function can 
be a virtual instance or be embedded in a physical network element." 
This means a service function is a virtual entity.

A virtual machine (VM), for example, can decide which process to run 
first. Similarly a service function can decide how a packet being 
processed and forwarded to the next service function hop.

Chang

On 07/10/2014 11:36 AM, Ron Parker wrote:
>
> Hi, Mike.
>
> Between service function and service function instance, I think it 
> would have to be the instance, since the former is conceptual.    But, 
> in a distributed path selection approach, might it make sense to 
> assign this duty to the service function forwarder (SFF)?
>
> Ron
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of [email-masked]
> *Sent:* Thursday, July 10, 2014 2:34 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> "Service Functions MAY make the decision about which Service Function 
> Instances will be used when selecting the Service Function Path."
>
> *From: [email-masked]<[email-masked] 
> <mailto:[email-masked][email-masked]>>
> *To: *Changcheng Huang<[email-masked] 
> <mailto:[email-masked]>>,'Ron 
> Parker'<[email-masked] 
> <mailto:[email-masked]>>,'Lucy 
> yong'<[email-masked] 
> <mailto:[email-masked]>>,[email-masked]<[email-masked] 
> <mailto:[email-masked]>>,[email-masked]<[email-masked] 
> <mailto:[email-masked]>>,[email-masked]<[email-masked] 
> <mailto:[email-masked]>>,[email-masked]<[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *RE: [sfc] Service Chains, Paths, and Load Balancers
>
> "Service Functions MAY make the decision about which Service Function 
> Instances will be used when selecting the Service Function Path."
>
> "Service Function Classifiers (or SNF's or SFF's, as the case may be) 
> MAY make the decision about which Service Function Instances will be 
> used when selecting the Service Function Path."
>
> and,
>
> "External orchestration frameworks MAY make the decision about which 
> Service Function Instances will be used when selecting the Service 
> Function Path."
>
> All three result in a Service Function Path being selected, and they 
> aren't necessarily exclusive of one another if you have rules for 
> resolving conflicts; the details of those rules are not architectural.
>
> IMO, the architecture needs to err on the side of being descriptive 
> over being proscriptive when there is a conflict between the two.
>
>
> *From:*sfc [[email-masked] <mailto:[email-masked]>] on 
> behalf of Changcheng Huang [[email-masked] 
> <mailto:[email-masked]>]
> *Sent:* Thursday, July 10, 2014 12:31 PM
> *To:* 'Ron Parker'; 'Lucy yong'; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> I agree with Ron's comments. Service functions should make the 
> decision about which instances will be used. It can be different 
> hop-by-hop (e.g. in a tree topology). In order to do so, it is 
> important a physical network makes a service function chain aware of 
> the available instances. These is no need to identify each possible 
> SFP by a physical network. If a service function chain wants to use 
> multiple SFPs, it should provide the identifier for each flow that 
> uses a particular SFP and the corresponding forwarding rules (i.e. 
> next hop). Nevertheless, because a physical network need to support 
> multiple tenants, it does need to identify different tenants. Our 
> recent contribution 
> (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ 
> ) has discussed this issue in a more general architecture. Hope it can 
> be helpful for this discussion.
>
> Chang
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ron Parker
> *Sent:* Thursday, July 10, 2014 8:20 AM
> *To:* Lucy yong; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> It is architecturally significant to identify that multiple 
> addressable instances of a service function are explicitly allowed. 
> Whether those instance perform some further level of load balancing is 
> irrelevant, as has been pointed out by Joel. It is also 
> architecturally significant to assign responsibility for instance 
> selection. In particular, is the instance selection centralized, 
> distributed, or some combination? Which functional entities in the 
> architecture have what responsibilities to achieve this? In November, 
> 2013, after IETF 88, I submitted this draft, 
> http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which 
> proposed that the instance selection was made hop by hop by the 
> service functions themselves, in a fully distributed manner. That was 
> just a proposal and I am not wedded to it, by any means. Joel asked 
> about specificity and it is at this level that I'd like to see the 
> architecture describe things. It should be able to answer the 
> question, "how does multi-instance selection work in SFC?" in a 
> concise manner. If the group feels that there should be more than one 
> answer to that question, so be it, but we should be able to describe 
> the high level mechanism and rationale for each succinctly. Of course, 
> that is merely one such question and there are many others that an 
> architectural document should be able to describe.
>
> Ron
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Lucy yong
> *Sent:* Thursday, July 10, 2014 11:05 AM
> *To:* [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Agree. The arch. doc should not mandate only use of the service path 
> identifier to drive the forwarding actions.
>
> Lucy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of 
> [email-masked] <mailto:[email-masked]>
> *Sent:* Thursday, July 10, 2014 2:06 AM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Re-,
>
> The merged draft calls out explicitly a service path identifier. I 
> object to use that identifier to derive forwarding actions.
>
> Requiring a SFC system to have the full knowledge of every available 
> SFC forwarding paths within an SFC-enabled domain is not 
> required/justified nor possible in various deployment contexts.
>
> SFC forwarding actions should rely on the piece of information that 
> will be present in all deployments: that is the one required to 
> structure a service chain. How that information is used to infer 
> forwarding actions is a solution-oriented discussion.
>
> Cheers,
>
> Med
>
> *De :*sfc [mailto:[email-masked]] *De la part de* 
> [email-masked] <mailto:[email-masked]>
> *Envoyé :* mercredi 9 juillet 2014 22:03
> *À :* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Objet :* Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Is anyone still questioning the difference between SF Chain and SF 
> Path? Other than clarifying the definition so that it's clear to those 
> not familiar with the draft, it seems that everyone agrees on these terms.
>
> To me, the one point that is still unclear is whether it is the intent 
> of this draft to ultimately specify what the ID of the SFC Header 
> should reference (the chain or the path), or if this draft simply 
> intends to leave that ambiguous, allowing other drafts to dictate the 
> mechanisms for forwarding based on chain or path and the choice of 
> chain or path to be negotiated in the control-plane.
>
> If the latter (ambiguous), then the draft would have require that both 
> SFP and SFC be supported (or make one required and the other optional) 
> to avoid some vendors only supporting SFP and others only supporting SFC.
>
> *From: [email-masked]<[email-masked] 
> <mailto:[email-masked][email-masked]>>
> *To: [email-masked]<[email-masked] <mailto:[email-masked][email-masked]>>
> *Sent: *Tuesday, July 8, 2014
> *Subject: *[sfc] Service Chains, Paths, and Load Balancers
>
> [email-masked] <mailto:[email-masked]>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 15:54:22 -0400

agreed.  Just wanted to verify.  It might make sense for the SFF to do the instance selection.  The further toward the classifier you push that decision, the less resilient you are to SFI failures, but the more resources are required on the devices making that decision.  In the case of SFF, each SFF would need to know about all SFIs of all SFs.  If, however, the decision were made by the SFI (or proxy for SFC-unaware SFs), then each would only need to worry about all of the SFIs for each of the SFs that are next in each chain for which it is a member.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Hi, Mike.
 
Between service function and service function instance, I think it would have to be the instance, since the former is conceptual.    But, in a distributed path
 selection approach, might it make sense to assign this duty to the service function forwarder (SFF)?
 
   Ron

From: sfc [mailto:[email-masked]]
On Behalf Of [email-masked]

 

 

and, 

From: sfc [[email-masked]]
 on behalf of Changcheng Huang [[email-masked]]

To: 'Ron Parker'; 'Lucy yong'; 
[email-masked]; [email-masked];
[email-masked]; 
[email-masked]

I agree with Ron’s comments. Service functions should make the decision about which instances will
 be used. It can be different hop-by-hop (e.g. in a tree topology). In order to do so, it is important a physical network makes a service function chain aware of the available instances. These is no need to identify each possible SFP by a physical network.
 If a service function chain wants to use multiple SFPs, it should provide the identifier for each flow that uses a particular SFP and the corresponding forwarding rules (i.e. next hop). Nevertheless, because a physical network need to support multiple tenants,
 it does need to identify different tenants. Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/ ) has
 discussed this issue in a more general architecture. Hope it can be helpful for this discussion.
Chang

From:
 sfc [mailto:[email-masked]] On Behalf Of
Ron Parker

To: Lucy yong; [email-masked];
[email-masked]; 
[email-masked]; [email-masked]

It is architecturally significant to identify that multiple addressable instances of a service function
 are explicitly allowed. Whether those instance perform some further level of load balancing is irrelevant, as has been pointed out by Joel. It is also architecturally significant to assign responsibility for instance selection. In particular, is the instance
 selection centralized, distributed, or some combination? Which functional entities in the architecture have what responsibilities to achieve this? In November, 2013, after IETF 88, I submitted this draft,

http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which proposed that the instance selection was made hop by hop by the service functions themselves, in a fully distributed manner. That was just a proposal and I am not wedded to it, by any means.
 Joel asked about specificity and it is at this level that I’d like to see the architecture describe things. It should be able to answer the question, “how does multi-instance selection work in SFC?” in a concise manner. If the group feels that there should
 be more than one answer to that question, so be it, but we should be able to describe the high level mechanism and rationale for each succinctly. Of course, that is merely one such question and there are many others that an architectural document should be
 able to describe.
Ron

From: sfc
 [mailto:[email-masked]]
On Behalf Of Lucy yong

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding
 actions.
Lucy

From: sfc
 [mailto:[email-masked]]
On Behalf Of [email-masked]

To: [email-masked];
[email-masked]; 
[email-masked]

Re-,
The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive
 forwarding actions. 
Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled
 domain is not required/justified nor possible in various deployment contexts.
SFC forwarding actions should rely on the piece of information that will be present in all deployments: that
 is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
Cheers,
Med

De :
 sfc [mailto:[email-masked]]
De la part de [email-masked]

À : [email-masked];
[email-masked]

Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition
 so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify
 what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated
 in the control-plane. 

If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make
 one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.

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

group intends.

if that helps.

in any solution.

place in the network.

re-classification point.

Yours,

Joel

sfc mailing list

[email-masked]

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 20:06:18 +0000

Paul,

How many path identifiers there will be for a 4 hop service chain with 20 instances at each hop?

Maria

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Overall I concur, as you say: a path ID drives the forwarding.  I'd make the minor change: the path identifier can be used to derive the needed forwarding and associated transport.

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "Zarny, Myo" <[email-masked]>
Date: Thu, 10 Jul 2014 16:08:54 -0400

Using the term load distribution to refer to load balancer selection will be lost to a lot of people. Many people call it global sever load balancing.

Plus, there could be multiple layers of "load distribution" / LB selection. Not just two. For example, select a region from a global pool; once the region is selected, select a data center in that region; in that DC, which DC LB instance to go to; and then we have the traditional LB which selects the end server.

In sum, (1) path selection could happen at more than 2 different tiers; (2) "load" isn't the only criterion in those selections. I see the rationale for wanting the differentiation but is load distribution the best term for it? 

Regards,

----- Original Message -----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 10 Jul 2014 20:13:48 +0000

1 assuming load is distributed among the 20 instances at each service hop.

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <[email-masked]<mailto:[email-masked]>> wrote:

Paul,

Maria

From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Thursday, July 10, 2014 3:03 PM
To: Lucy yong
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy,

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 16:15:49 -0400

The architecture allows a range of deployments, from 1 service path to 
160000 service paths.  I would hope that operators are prepared for the 
complexities if they choose to avoid any use of local load balancing and 
in stead provision 160,000 service paths.

Yours,
Joel

On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Paul Quinn (paulq)
> *Sent:* Thursday, July 10, 2014 3:03 PM
> *To:* Lucy yong
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Overall I concur, as you say: a path ID drives the forwarding.  I’d make
> the minor change: the path identifier can be used to derive the needed
> forwarding and associated transport.
>
> It is _not_ the transport, but rather is used to simply identify the
> service path (or graph) that packets must traverse.  By having a path
> identifier, the exact indirection that people seem to be asking for on
> this thread can be simply be implemented.  The path identifier provides
> nothing more than a lookup, that lookup can result in a one or more
> (equal or weighted) transport next hop(s).
>
> Paul
>
> *From:*sfc [mailto:[email-masked]]*On Behalf
> [email-masked] <mailto:[email-masked]>
> *Sent:*Thursday, July 10, 2014 2:06 AM
> *To:[email-masked] <mailto:[email-masked]>;[email-masked]
> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Re-,
>
> Requiring a SFC system to have the full knowledge of every available SFC
> forwarding paths within an SFC-enabled domain is not required/justified
> nor possible in various deployment contexts.
>
> SFC forwarding actions should rely on the piece of information that will
> be present in all deployments: that is the one required to structure a
> service chain. How that information is used to infer forwarding actions
> is a solution-oriented discussion.
>
> Cheers,
>
> Med
>
> *De :*sfc [mailto:[email-masked]]*De la part [email-masked]
> <mailto:[email-masked]>
> *Envoyé :*mercredi 9 juillet 2014 22:03
> *À :[email-masked] <mailto:[email-masked]>;[email-masked]
> <mailto:[email-masked]>
> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers
>
> Is anyone still questioning the difference between SF Chain and SF Path?
>   Other than clarifying the definition so that it's clear to those not
> familiar with the draft, it seems that everyone agrees on these terms.
>
> of this draft to ultimately specify what the ID of the SFC Header should
> reference (the chain or the path), or if this draft simply intends to
> leave that ambiguous, allowing other drafts to dictate the mechanisms
> for forwarding based on chain or path and the choice of chain or path to
> be negotiated in the control-plane.
>
> *From:[email-masked]<[email-masked]
> *To:[email-masked]<[email-masked] <mailto:[email-masked][email-masked]>>
> *Sent:*Tuesday, July 8, 2014
> *Subject:*[sfc] Service Chains, Paths, and Load Balancers
>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 20:17:33 +0000

Does it mean one path identifier?

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 4:14 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

Maria

Lucy,

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Thu, 10 Jul 2014 20:23:37 +0000

Let's take the case where front end load balancing does not occur.  If you assume that there needs to be a full end to end path identification before the packet is progressed from the classifier, then there are indeed 160000 permutations in this example.  But, can't we question that assumption in our architectural musings?   Perhaps, in an alternate realization, the classifier had 2 distinct jobs -- select the abstract chain and then select one of 20 instances representing the first service function in the chain.  The selected instance, once having completed its processing, knows the next abstract service function by way of the chain is and picks from one of the 20 instances.  And perhaps it was the SFF rather than the SFI that did this. 

   Ron

> On Jul 10, 2014, at 4:16 PM, "Joel M. Halpern" <[email-masked]> wrote:
> 
> The architecture allows a range of deployments, from 1 service path to 160000 service paths.  I would hope that operators are prepared for the complexities if they choose to avoid any use of local load balancing and in stead provision 160,000 service paths.
> 
> Yours,
> Joel
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 16:25:35 -0400

Perhaps we should reword that, then, to include a definition of Service Function Instance and make sure we are consistent when referring to these entities..  Based on most of the comments I've seen, it seems to make a lot of sense to consider a Service Function more of an abstract entity that has one or more instances.  An abstract Service Function with only a single instance might appear as overkill, however it would normalize much of the conversation and allow for clearer discussions about what happens when and where &c.

>From the problem statement:
> The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.

seems to indicate that the instance is the thing that is being chained.  Of course, if the classifier only specifies chooses a chain ({SFn}) and not a path ({SFIn}), relinquishing the decision of which instantiation to another process, then there technically is never an actual completed "ordered set of instances" produced (because SFI(n) is only chosen sometime after being delivered to SFI(n-1)) rendering the SFP an abstract-ish conceptual thing.

Then again, it could be I've read too many of these today and my brain is now full.

From: [email-masked]<[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

    As defined in the problem statement document, a service function is
    not a concept. Here is the quote from the document "A Service
    Function can be a virtual instance or be embedded in a physical
    network element." This means a service function is a virtual entity.

    Chang

On 07/10/2014 11:36 AM, Ron Parker
      wrote:

      
      
        Hi,
            Mike.
         
        Between
            service function and service function instance, I think it
            would have to be the instance, since the former is
            conceptual.    But, in a distributed path selection
            approach, might it make sense to assign this duty to the
            service function forwarder (SFF)?

            Ron

        From:

            Subject: Re: [sfc] Service Chains, Paths, and Load
            Balancers

          "Service
              Functions MAY make the decision about which Service
              Function Instances will be used when selecting the Service
              Function Path." 

          Is
              it service function that makes that decision? or the
              service function instance?

          To: Changcheng Huang<[email-masked]>,'Ron
          Parker'<[email-masked]>,'Lucy
          yong'<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>

          Subject: RE: [sfc] Service Chains, Paths, and Load
          Balancers

          >Service
              functions should make the decision about which instances
              will be used

              "Service Functions MAY make the decision about which
              Service Function Instances will be used when selecting the
              Service Function Path."

              "Service Function Classifiers (or SNF's or SFF's, as the
              case may be) MAY make the decision about which Service
              Function Instances will be used when selecting the Service
              Function Path."

              and, 

            "External
              orchestration frameworks MAY make the decision about which
              Service Function Instances will be used when selecting the
              Service Function Path."

              All three result in a Service Function Path being
              selected, and they aren't necessarily exclusive of one
              another if you have rules for resolving conflicts; the
              details of those rules are not architectural.

              IMO, the architecture needs to err on the side of being
              descriptive over being proscriptive when there is a
              conflict between the two.

          

            
              From:
                  sfc [[email-masked]]
                  on behalf of Changcheng Huang [[email-masked]]

                  
                    [email-masked]

                  Subject: Re: [sfc] Service Chains, Paths, and
                  Load Balancers

                I
                    agree with Ron’s comments. Service functions should
                    make the decision about which instances will be
                    used. It can be different hop-by-hop (e.g. in a tree
                    topology). In order to do so, it is important a
                    physical network makes a service function chain
                    aware of the available instances. These is no need
                    to identify each possible SFP by a physical network.
                    If a service function chain wants to use multiple
                    SFPs, it should provide the identifier for each flow
                    that uses a particular SFP and the corresponding
                    forwarding rules (i.e. next hop). Nevertheless,
                    because a physical network need to support multiple
                    tenants, it does need to identify different tenants.
                    Our recent contribution (https://datatracker.ietf.org/doc/draft-huang-sfc-use-case-recursive-service/
                    ) has discussed this issue in a more general
                    architecture. Hope it can be helpful for this
                    discussion.
                Chang

                    From:
                        On Behalf Of
                        Ron Parker

                        

                        Subject: Re: [sfc] Service Chains, Paths,
                        and Load Balancers

                It
                    is architecturally significant to identify that
                    multiple addressable instances of a service function
                    are explicitly allowed. Whether those instance
                    perform some further level of load balancing is
                    irrelevant, as has been pointed out by Joel. It is
                    also architecturally significant to assign
                    responsibility for instance selection. In
                    particular, is the instance selection centralized,
                    distributed, or some combination? Which functional
                    entities in the architecture have what
                    responsibilities to achieve this? In November, 2013,
                    after IETF 88, I submitted this draft,
                    
http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00, which
                    proposed that the instance selection was made hop by
                    hop by the service functions themselves, in a fully
                    distributed manner. That was just a proposal and I
                    am not wedded to it, by any means. Joel asked about
                    specificity and it is at this level that I’d like to
                    see the architecture describe things. It should be
                    able to answer the question, “how does
                    multi-instance selection work in SFC?” in a concise
                    manner. If the group feels that there should be more
                    than one answer to that question, so be it, but we
                    should be able to describe the high level mechanism
                    and rationale for each succinctly. Of course, that
                    is merely one such question and there are many
                    others that an architectural document should be able
                    to describe.
                Ron

                    From:

                        Subject: Re: [sfc] Service Chains, Paths,
                        and Load Balancers

                Agree.
                    The arch. doc should not mandate only use of the
                    service path identifier to drive the forwarding
                    actions.
                Lucy

                    From:

                        To: [email-masked];
                        [email-masked]; 
                          [email-masked]

                        Subject: Re: [sfc] Service Chains, Paths,
                        and Load Balancers

                Re-,
                The merged draft calls out
                    explicitly a service path identifier. I object to
                    use that identifier to derive forwarding actions. 
                Requiring a SFC system to
                    have the full knowledge of every available SFC
                    forwarding paths within an SFC-enabled domain is not
                    required/justified nor possible in various
                    deployment contexts.
                SFC forwarding actions
                    should rely on the piece of information that will be
                    present in all deployments: that is the one required
                    to structure a service chain. How that information
                    is used to infer forwarding actions is a
                    solution-oriented discussion.
                Cheers,
                Med

                          À : [email-masked];
                          [email-masked]

                          Objet : Re: [sfc] Service Chains,
                          Paths, and Load Balancers

                    Is
                        anyone still questioning the difference between
                        SF Chain and SF Path? Other than clarifying the
                        definition so that it's clear to those not
                        familiar with the draft, it seems that everyone
                        agrees on these terms.

                    To
                        me, the one point that is still unclear is
                        whether it is the intent of this draft to
                        ultimately specify what the ID of the SFC Header
                        should reference (the chain or the path), or if
                        this draft simply intends to leave that
                        ambiguous, allowing other drafts to dictate the
                        mechanisms for forwarding based on chain or path
                        and the choice of chain or path to be negotiated
                        in the control-plane. 

                    If
                        the latter (ambiguous), then the draft would
                        have require that both SFP and SFC be supported
                        (or make one required and the other optional) to
                        avoid some vendors only supporting SFP and
                        others only supporting SFC.

                  
                  From:

                      Subject: [sfc] Service Chains, Paths, and
                      Load Balancers

                      I have been trying to figure out how to clearly
                      answer a number of 

                      comments that have been made about the proposed
                      merged archtiecture 

                      draft. Assuming we can get working group agreement
                      on the intent, we 

                      will work to improve the wording so that readers
                      who have not 

                      participated in the WG discussion will understnd
                      it the way the working 

                      group intends.

                      But what do we intend? I will try to explain my
                      personal view, and see 

                      if that helps.

                      In this regard, it is important to keep in mind
                      that what we are 

                      defining is the data plane architecture. We are
                      not attempting to 

                      define the architecture for the entire solution
                      for service chaining. 

                      That would encompass OSS/BSS, various control and
                      policy functions, 

                      virtual machine and image management, and many
                      other aspects.

                      As a result there are many things which clearly
                      need to exist in the 

                      larger system, but which are dealt with above
                      where we are functioning, 

                      and are not directly required by the work we are
                      doing.

                      In order to get to service chain vs service path,
                      as I understand them, 

                      I need to first discuss load balancing. There are
                      at least three 

                      different ways that load balancing can and will
                      interact with service 

                      chaining. There probably are more. The point of
                      the archtiecture is to 

                      permit all of these, but not to mandate that any
                      particular kind be used 

                      in any solution.

                      1) Load balancing as a service provided to the end
                      user. This is a 

                      service function. It receives user packets, and
                      modifies them (or marks 

                      them, or ...) so as to choose an end user service
                      instance to receive 

                      the users packet. This is an important service
                      function to be able to 

                      include in service chaining. It's behavior may
                      affect requirements on 

                      how service chaining is done. But it has very
                      little impact on the 

                      archtiecture. From an architectural pe3rspective
                      it is simply a service 

                      2) There is internal load balancing. That is, one
                      can have what appears 

                      to the service chaining architecture as a single
                      point of contact for a 

                      specific service function, but is actually
                      delivered by a collection of 

                      virtual or physical machines, possibly including
                      one or several load 

                      balancers (for example using VRRP-like techniques
                      to share a MAC 

                      address.) mostly, this is invisible to the service
                      chaining data plane 

                      mechanisms. It is likely that it is visible to
                      various control 

                      mechanisms, such as those responsible for
                      scale-in, scale-out, and vm 

                      instantiation. The architectural impact of
                      permitting this is largely 

                      that we need to be careful that our terminology
                      does not lead readers to 

                      3) There can also be load balancing done by
                      selecting packet paths for 

                      the service chaining that direct traffic to
                      different places. We would 

                      not want to require that a given service function
                      appear at only one 

                      place in the network.

                      It is of course the case that these may be
                      combined. I tend to refer to 

                      the collection of entities that appear to service
                      chaining as a single 

                      point as a cluster. Not because cluster is a good
                      term. But because I 

                      do not have another one. Thus, the point of type 3
                      load balancing is to 

                      direct different subsets of traffic to different
                      singular or clustered 

                      service functions in different places in the
                      network.

                      Now with that said, what do I mean when I talk
                      about service chain and 

                      service path/ Service chain is a sequence of
                      logical functions to be 

                      applied to a subset of packets. It is equivalent
                      of saying that some 

                      subset of traffic is to get DPI, charging, content
                      inspection, and 

                      firewall while a different subset is to go
                      directly to the cache without 

                      That is not enough information to direct the
                      packets. A service path 

                      is, in some fashion, a sequence of locations in
                      the network. Those 

                      locations will be singular or clustered service
                      function delivery 

                      locations. They may be addressed by IP address.
                      They may be addressed 

                      as ports on an SFF. There are many different ways
                      that the locations 

                      may be known to the service chaining
                      infrastructure and the transport.

                      >From the point of view of the work of the SFC
                      group, we need to be able 

                      to talk about the high level abstraction, the
                      service chain, which 

                      drives the forwarding. And we need to talk about
                      the actual data path 

                      Several of the comments have said "but the whole
                      path may not be known 

                      at the front." This architecture deals with that
                      issue in two ways. 

                      First, as noted in item (2) on load balancers
                      above, there can be 

                      decisions and behaviors which are invisible to the
                      service chaining 

                      mechanisms (in much the same way that bridging
                      within a LAN is largely 

                      invisible to routing between LANs.) The other
                      provision we make is that 

                      reclassification can be done in mid-chain when
                      necessary. That will 

                      direct packets to a new chain. Based on
                      information available at the 

                      re-classification point.

                      the intent is acceptable to the working group, we
                      can figure out what 

                      If the working group disagree with the intent,
                      then we will of course 

                      If this is still unclear, I am not sure what to
                      try next.

                      Yours,

                      Joel

                      sfc mailing list

                      [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 16:28:37 -0400

Ron, I believe that the only difference in our descriptions is that you 
are drawing the service path as extending into the specific SFI that is 
selected by the local load balancing.  This makes the description of the 
service path very confusing.

Instead, the archtiecture document describes the service path as 
reaching to the SFF.  The SFF delivers the packets to the instances. 
Those "instances", may be single instances, a load balanced set managed 
by the SFF in a fashion outside of our purview, or a (set of) load 
balancers and instances behind the SFF, again outside of our purview. 
The only requirement is tha tthe packet comes back to the service path 
cleanly, so the SFF can do its job (particularly if it is a proxy.)

Thus, i believe we agree on what needs to be suppored, but not on the 
description for it.

As I said in my previous note, this allows us to use 1 service path, 
with local load balancing.  Or to couple that with global load 
distribution and multiple chains, either to subsets of those functions 
(giving 16 to 81 service paths) or absurdly fine grained global load 
distribution to 160,000 service paths.  That is a deplyment call rather 
than an architecture call.

Yours,
Joel

---

From: Changcheng Huang <[email-masked]>
Date: Thu, 10 Jul 2014 13:36:58 -0700

If you need to support 100 service chains, it will mean 16,000,000 
paths. That is larger than the routing table of a core router.

Chang

On 07/10/2014 01:15 PM, Joel M. Halpern wrote:
> 160000 service paths.  I would hope that operators are prepared for 
> the complexities if they choose to avoid any use of local load 
> balancing and in stead provision 160,000 service paths.
>
> Yours,
> Joel
>
>> able

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 16:37:07 -0400

Well, Global Server Load Balancing is a very specific thing dealing with DNS.  That's why it's important to define the terms and then use them consistently.

I don't think that multiple tiers of load distribution changes anything assuming it all happens inside the SFC domain.   I was imagining that "load distribution" would be narrowly defined as the selection of an instance of a service function.  Anything outside of that definition would be load balancing or whatever you feel like calling it and should be beyond the scope of SFC.  In the case of the chains of load balancers fronting service functions, the load balancer would be the SF in the chain and SFC would be unaware of what happens between that load balancer and the consuming service.  But that might be getting too much into use cases.

From: [email-masked]<[email-masked]>
To: [email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>
cc: [email-masked]'<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Regards,

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

From: Joel M. Halpern [mailto:[email-masked]]Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard TimeTo: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>Cc: [email-masked] <[email-masked]>Subject: Re: [sfc] Service Chains, Paths, and Load BalancersThe term "load distribution" works for me.  I agree that there is value in differentiating the functions, and using different words usually helps such differentiation.Yours,JoelOn 7/10/14, 2:55 PM, [email-masked] wrote:> I've stated before that I think we should differentiate between load> balancing and load distribution where load balancing refers to the> standard service function that we all know and love (outside of SFC) and> load distribution refers to the selection of an SFI (i.e. Chain -> Path> mapping).  Not using different terms to distinguish between these leads> to confusion.>> e.g. a SF Chain* might exist whose SFs consist only of load balancers.>   But you might still want SFC* to distribute load to multiple load> balancer instances.>> *trying to distinguish between SFC as "Service Function Chaining" and a> single "Service Function Chain".>>>>>>>> ------------------------------------------------------------------------> *From: [email-masked]<[email-masked]>> *To: *Joel M. Halpern<[email-masked]>> *cc: *Jim Guichard> (jguichar)<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,Ron> Parker<[email-masked]>,NAPIERALA, MARIA H<[email-masked]>> *Sent: *Thursday, July 10, 2014> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>> Joel,>> I concur. The goal here is to address the issues associated with generic> service function deployment and should enable localized decisions such> as load balancing (perhaps more accurately load distribution). Clearly> we sound’t codify how load distribution works.>> In order to enable load distribution, for example, the right> abstractions been to be clearly defined in the architecture, a key one> bering the distinction between path vs. chain.>> Paul>>>> On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <[email-masked]> wrote:>>  > That is clearly an important problem in building a full solution to> the service chaining needs of operators (e.g. you). However, I could> equally observe that if you do not have OSS/BSS capable of provisioning> service chains, or charging systems capable of turning them into> revenue, you can't offer them.>  >>  > The SFC working group is tasked with one part of the whole service> chain definition, construction, and deployment problem. As I read the> charter, general load balancing issues are not part of our scope.>  > Given the number of different ways there are of doing load balancing,> it would strike me as very odd for the sfc working group to standardize> a particular answer to the important and difficult problem you point to.>  >>  > The architecture (and I believe most of the solutions) is designed to> provide tools that help with managing that scaling, while also allowing> for the use of other tools.>  > If the working group wants us to be more specific in the load> balancing architecture, then if the chairs tell us to we will add more> specific text. I would be surprised personally if we had agreement on> such a goal, or agreement on how to fill such a goal. But Carlos and I> will of course do what the chairs tell us the WG wants.>  >>  > Yours,>  > Joel>  >>  > On 7/10/14, 12:02 PM, NAPIERALA, MARIA H wrote:>  >> One of the main problems in "service chains" is how to implement a> service that is conceptually one hop but scaled horizontally as 10 or> 100 different VMs.>  >> So, IMO, if we are not addressing this problem than what are we solving.>  >>>  >> Maria>  >>>  >>  > _______________________________________________>  > 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>_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 16:39:42 -0400

Agree that maybe 'load distribution' isn't the best name.  What is important is that it is distinguished from load balancing (which is also a poor name).

Maybe "Traffic Distribution' or 'Traffic Balancing' or do those names already carry other significance?

Regards,

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 20:40:09 +0000

agreed.

________________________________
From: sfc [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Thursday, July 10, 2014 4:25 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

As defined in the problem statement document, a service function is not a concept. Here is the quote from the document "A Service Function can be a virtual instance or be embedded in a physical network element." This means a service function is a virtual entity.

A virtual machine (VM), for example, can decide which process to run first. Similarly a service function can decide how a packet being processed and forwarded to the next service function hop.

Chang

On 07/10/2014 11:36 AM, Ron Parker wrote:
Hi, Mike.
Between service function and service function instance, I think it would have to be the instance, since the former is conceptual. But, in a distributed path selection approach, might it make sense to assign this duty to the service function forwarder (SFF)?
Ron
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 10, 2014 2:34 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
"Service Functions MAY make the decision about which Service Function Instances will be used when selecting the Service Function Path."
Is it service function that makes that decision? or the service function instance?
________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: Changcheng Huang<[email-masked]<mailto:[email-masked]>>,'Ron Parker'<[email-masked]<mailto:[email-masked]>>,'Lucy yong'<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

and,

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 16:46:42 -0400

Jim, 

Technically, wouldn't this be a Chain Identifier if the next instance is chosen at each hop?  In this case, there wouldn't be any Path Identifier at all.

But it is the difference between a classifier needing to track the health, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tracking 20 SFIs of the next-hop for the chains of which they are members vs each SFF in the entire domain tracking all 80 SFIs vs something else.

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>
cc: Paul Quinn (paulq)<[email-masked]>,Lucy yong<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

On Jul 10, 2014, at 4:07 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

Paul,

Maria

From: sfc [mailto:[email-masked]]
On Behalf Of Paul Quinn (paulq)

To: Lucy yong

Cc: [email-masked]; 
[email-masked]; [email-masked];
[email-masked]

 
Lucy, 

 

It is _not_ the transport, but rather is used to simply identify the service path (or graph) that packets must traverse.  By having a path identifier, the exact indirection that people seem to be asking for on this thread can be simply
 be implemented.  The path identifier provides nothing more than a lookup, that lookup can result in a one or more (equal or weighted) transport next hop(s).  

Paul

On Jul 10, 2014, at 11:04 AM, Lucy yong <[email-masked]> wrote:

 

Lucy

From: sfc
 [mailto:[email-masked]] On Behalf Of [email-masked]

 

Re-,

 

 

SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that
 information is used to infer forwarding actions is a solution-oriented discussion.

Cheers,

Med

De : sfc
 [mailto:[email-masked]] De la part de [email-masked]

 

Is anyone still questioning the difference between SF Chain and SF Path?  Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems
 that everyone agrees on these terms.

 

 

 

group intends.

if that helps.

in any solution.

place in the network.

re-classification point.

Yours,

Joel

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

 

sfc mailing list

[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 16:46:47 -0400

No, it will mean that if someone tries to deploy the archtieture 
particularly badly, they will exceed the limits of their devices.
The architecture does not require such absurd use of service paths.
Since I can not figure out how to write architectural words to prohibit 
it, the architecture does permit such abuse.

Please do not read my saying that the archtiecture permits something as 
saying it is either deisred or required by the work.  It isn't.

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 16:57:42 -0400

Yes.  Many protocols allow you to do stupid things, but don't prohibit them as they may make sense in smaller deployments.  

e.g. I could build a global 2000 node OSPF network all in area 0, redistributing all links as external LSAs, and still not violate the standard.

From: [email-masked]<[email-masked]>
To: <[email-masked]>,<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

On 7/10/14, 4:36 PM, Changcheng Huang wrote:

> If you need to support 100 service chains, it will mean 16,000,000> paths. That is larger than the routing table of a core router.>> Chang>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>> The architecture allows a range of deployments, from 1 service path to>> 160000 service paths.  I would hope that operators are prepared for>> the complexities if they choose to avoid any use of local load>> balancing and in stead provision 160,000 service paths.>>>> Yours,>> Joel>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>>> Paul,>>>>>> How many path identifiers there will be for a 4 hop service chain with>>> 20 instances at each hop?>>>>>> Maria>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Paul Quinn>>> (paulq)>>> *Sent:* Thursday, July 10, 2014 3:03 PM>>> *To:* Lucy yong>>> *Cc:* [email-masked]; [email-masked]; [email-masked];>>> [email-masked]>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>> Lucy,>>>>>> Overall I concur, as you say: a path ID drives the forwarding. I’d make>>> the minor change: the path identifier can be used to derive the needed>>> forwarding and associated transport.>>>>>> It is _not_ the transport, but rather is used to simply identify the>>> service path (or graph) that packets must traverse.  By having a path>>> identifier, the exact indirection that people seem to be asking for on>>> this thread can be simply be implemented.  The path identifier provides>>> nothing more than a lookup, that lookup can result in a one or more>>> (equal or weighted) transport next hop(s).>>>>>> Paul>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong <[email-masked]>>> <mailto:[email-masked]>> wrote:>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the service path>>> identifier to drive the forwarding actions.>>>>>> Lucy>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>>> [email-masked] <mailto:[email-masked]>>>> *Sent:*Thursday, July 10, 2014 2:06 AM>>> *To:[email-masked] <mailto:[email-masked]>;[email-masked]>>> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>> Re-,>>>>>> The merged draft calls out explicitly a service path identifier. I>>> object to use that identifier to derive forwarding actions.>>>>>> Requiring a SFC system to have the full knowledge of every available SFC>>> forwarding paths within an SFC-enabled domain is not required/justified>>> nor possible in various deployment contexts.>>>>>> SFC forwarding actions should rely on the piece of information that will>>> be present in all deployments: that is the one required to structure a>>> service chain. How that information is used to infer forwarding actions>>> is a solution-oriented discussion.>>>>>> Cheers,>>>>>> Med>>>>>> *De :*sfc [mailto:[email-masked]]*De la part [email-masked]>>> <mailto:[email-masked]>>>> *Envoyé :*mercredi 9 juillet 2014 22:03>>> *À :[email-masked] <mailto:[email-masked]>;[email-masked]>>> <mailto:[email-masked]>>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>> Is anyone still questioning the difference between SF Chain and SF Path?>>>   Other than clarifying the definition so that it's clear to those not>>> familiar with the draft, it seems that everyone agrees on these terms.>>>>>> To me, the one point that is still unclear is whether it is the intent>>> of this draft to ultimately specify what the ID of the SFC Header should>>> reference (the chain or the path), or if this draft simply intends to>>> leave that ambiguous, allowing other drafts to dictate the mechanisms>>> for forwarding based on chain or path and the choice of chain or path to>>> be negotiated in the control-plane.>>>>>> If the latter (ambiguous), then the draft would have require that both>>> SFP and SFC be supported (or make one required and the other optional)>>> to avoid some vendors only supporting SFP and others only supporting>>> SFC.>>>>>> ------------------------------------------------------------------------>>>>>> *From:[email-masked]<[email-masked]>>> <mailto:[email-masked][email-masked]>>>>> *To:[email-masked]<[email-masked] <mailto:[email-masked][email-masked]>>>>> *Sent:*Tuesday, July 8, 2014>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers>>>>>> I have been trying to figure out how to clearly answer a number of>>> comments that have been made about the proposed merged archtiecture>>> draft. Assuming we can get working group agreement on the intent, we>>> will work to improve the wording so that readers who have not>>> participated in the WG discussion will understnd it the way the working>>> group intends.>>>>>> But what do we intend? I will try to explain my personal view, and see>>> if that helps.>>>>>> In this regard, it is important to keep in mind that what we are>>> defining is the data plane architecture. We are not attempting to>>> define the architecture for the entire solution for service chaining.>>> That would encompass OSS/BSS, various control and policy functions,>>> virtual machine and image management, and many other aspects.>>>>>> As a result there are many things which clearly need to exist in the>>> larger system, but which are dealt with above where we are functioning,>>> and are not directly required by the work we are doing.>>>>>> In order to get to service chain vs service path, as I understand them,>>> I need to first discuss load balancing. There are at least three>>> different ways that load balancing can and will interact with service>>> chaining. There probably are more. The point of the archtiecture is to>>> permit all of these, but not to mandate that any particular kind be used>>> in any solution.>>>>>> 1) Load balancing as a service provided to the end user. This is a>>> service function. It receives user packets, and modifies them (or marks>>> them, or ...) so as to choose an end user service instance to receive>>> the users packet. This is an important service function to be able to>>> include in service chaining. It's behavior may affect requirements on>>> how service chaining is done. But it has very little impact on the>>> archtiecture. From an architectural pe3rspective it is simply a service>>> function which may modify the underlying packet.>>>>>> 2) There is internal load balancing. That is, one can have what appears>>> to the service chaining architecture as a single point of contact for a>>> specific service function, but is actually delivered by a collection of>>> virtual or physical machines, possibly including one or several load>>> balancers (for example using VRRP-like techniques to share a MAC>>> address.) mostly, this is invisible to the service chaining data plane>>> mechanisms. It is likely that it is visible to various control>>> mechanisms, such as those responsible for scale-in, scale-out, and vm>>> instantiation. The architectural impact of permitting this is largely>>> that we need to be careful that our terminology does not lead readers to>>> think we are prohibiting it.>>>>>> 3) There can also be load balancing done by selecting packet paths for>>> the service chaining that direct traffic to different places. We would>>> not want to require that a given service function appear at only one>>> place in the network.>>>>>> It is of course the case that these may be combined. I tend to refer to>>> the collection of entities that appear to service chaining as a single>>> point as a cluster. Not because cluster is a good term. But because I>>> do not have another one. Thus, the point of type 3 load balancing is to>>> direct different subsets of traffic to different singular or clustered>>> service functions in different places in the network.>>>>>> Now with that said, what do I mean when I talk about service chain and>>> service path/ Service chain is a sequence of logical functions to be>>> applied to a subset of packets. It is equivalent of saying that some>>> subset of traffic is to get DPI, charging, content inspection, and>>> firewall while a different subset is to go directly to the cache without>>> visiting any other service functions.>>>>>> That is not enough information to direct the packets. A service path>>> is, in some fashion, a sequence of locations in the network. Those>>> locations will be singular or clustered service function delivery>>> locations. They may be addressed by IP address. They may be addressed>>> as ports on an SFF. There are many different ways that the locations>>> may be known to the service chaining infrastructure and the transport.>>>>>>  >From the point of view of the work of the SFC group, we need to be>>> able>>> to talk about the high level abstraction, the service chain, which>>> drives the forwarding. And we need to talk about the actual data path>>> packets will take in the network.>>>>>> Several of the comments have said "but the whole path may not be known>>> at the front." This architecture deals with that issue in two ways.>>> First, as noted in item (2) on load balancers above, there can be>>> decisions and behaviors which are invisible to the service chaining>>> mechanisms (in much the same way that bridging within a LAN is largely>>> invisible to routing between LANs.) The other provision we make is that>>> reclassification can be done in mid-chain when necessary. That will>>> direct packets to a new chain. Based on information available at the>>> re-classification point.>>>>>> I hope that this helps explain what we are after. If it does, and if>>> the intent is acceptable to the working group, we can figure out what>>> additional words are needed to convey this.>>> If the working group disagree with the intent, then we will of course>>> adjust to match the working group agreements.>>> If this is still unclear, I am not sure what to try next.>>>>>> Yours,>>> Joel>>>>>> _______________________________________________>>> sfc mailing list>>> [email-masked] <mailto:[email-masked]>>>> https://www.ietf.org/mailman/listinfo/sfc>>>>>> _______________________________________________>>> sfc mailing list>>> [email-masked] <mailto:[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>_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:01:05 +0000

I disagree.  

We routinely have stateful devices that manage tens of millions of concurrent flows in both access network and data center environments today.  You can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to have small numbers of service chains with equally small numbers of active service paths?  

Your sounds too much like "no one will ever need more than 64K" for comfort.

________________________________________
From: sfc [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]
Sent: Thursday, July 10, 2014 4:46 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 10 Jul 2014 17:04:10 -0400

Ian, I don't think you disagree with me at all in this regard.
I am not requesting the the architecture or the solution prohibit 
deployments in the specific fashion.
I am objecting to Huang's reading of my note as saying that such 
deployments are required they by the archtiecture.

As I have said repeatedly, I am not trying to prohibit such things. 
Whether they are a good idea or not depends upon many factors outside of 
the scope of the WG.  I happen to think that they are usually a bad idea.

But the archtiecture si carefully avoiding attempting to know what is 
and is not eployable.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 10 Jul 2014 21:07:27 +0000

Yes.

Sent from my iPhone

On Jul 10, 2014, at 4:18 PM, "NAPIERALA, MARIA H" <[email-masked]<mailto:[email-masked]>> wrote:

Maria

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 4:14 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

Maria

Lucy,

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 21:04:32 +0000

Good catch.

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 10, 2014 4:26 PM
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Chang

and,

Yours,
Joel

sfc mailing list

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:14:58 +0000

Actually, I think I am disagreeing.

If the possibility of medium-scale deployments (and that is what 16 million flows is in my world) of service chains is preconceived as an absurd idea, then the architecture burdened with that preconception. 

There has to be some point of aim, some degree of aspiration to scale that is appropriate for the lifespan of the architecture - you don't have to know what it is, but by saying that an arbitrary number is "too far", you're creating - even if it isn't intentional - a limit that influences decisions that have lasting impacts regarding scale-out, failure mitigation, elasticity, address space... all kinds of things.  That is a problem I'm not particularly eager to deal with.

________________________________________
From: Joel Halpern Direct [[email-masked]]
Sent: Thursday, July 10, 2014 5:04 PM
To: Ian Smith; Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 21:33:19 +0000

Managing millions of 5-tuple flows in a single appliance is not the same as managing (globally) millions of service paths which are essentially logical networks. And 16 million was an arbitrary number for just 100 service chains. 100 service chains is very little. Image this number be two or more orders of magnitude higher...

> Sent: Thursday, July 10, 2014 5:15 PM
> To: Joel Halpern Direct; Joel M. Halpern; [email-masked];
> [email-masked]
> If the possibility of medium-scale deployments (and that is what 16 million
> flows is in my world) of service chains is preconceived as an absurd idea,
> then the architecture burdened with that preconception.
> 
> There has to be some point of aim, some degree of aspiration to scale that
> is appropriate for the lifespan of the architecture - you don't have to know
> what it is, but by saying that an arbitrary number is "too far", you're
> creating - even if it isn't intentional - a limit that influences decisions that
> have lasting impacts regarding scale-out, failure mitigation, elasticity,
> address space... all kinds of things.  That is a problem I'm not particularly
> eager to deal with.
> 
> 
> 
> 
> > We routinely have stateful devices that manage tens of millions of
> concurrent flows in both access network and data center environments
> today.  You can't seriously believe that in the
> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to
> have small numbers of service chains with equally small numbers of active
> service paths?
> >
> >>>> Overall I concur, as you say: a path ID drives the forwarding. I'd make
> >>>> *To:[email-masked]
> <mailto:[email-masked]>;[email-masked]
> SFC
> required/justified
> will
> >>>> *À :[email-masked]
> Path?
> should
> >>>> to avoid some vendors only supporting SFP and others only
> supporting
> >>>> SFC.
> >>>>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 21:35:06 +0000

Good!

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 5:07 PM
To: NAPIERALA, MARIA H
Cc: Paul Quinn (paulq); Lucy yong; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yes.

Sent from my iPhone

Maria

Sent from my iPhone

Maria

Lucy,

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 10 Jul 2014 21:36:23 +0000

Hi Maria,

Assuming that for each SF, all instance are to be viewed as equal, then 1 SFC encap service path identifier.  At each SFF, a local decision will be made about how to distribute the load to the attached SFs.

Paul

On Jul 10, 2014, at 4:06 PM, NAPIERALA, MARIA H <[email-masked]<mailto:[email-masked]>> wrote:

Paul,

Maria

Lucy,

Paul

Lucy

Re-,

Cheers,
Med

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:37:53 +0000

A service path isn't a logical network; it is  - quite literally - a path _though_ a network.  

________________________________________
From: NAPIERALA, MARIA H [[email-masked]]
Sent: Thursday, July 10, 2014 5:33 PM
To: Ian Smith; Joel Halpern Direct; Joel M. Halpern; [email-masked]; [email-masked]
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 17:43:36 -0400

First, sorry, I should not have put words in your mouth.  You said you 
disagreed.

My point is that the archtiecture takes no stance on whether the right 
level of multiplicity at the Service path level for handling multiple 
instantiations is one path, O(100) paths, or O(1,000,000) paths.  We 
each have biasis about what we think is reasonable for supporting each 
service combination that the operator is offering.

Maria has clearly said that she wants to deploy with O(1).  Fine, the 
archtiecture allows that.  I expect that the solution will as well.

You have said that you consider a much larger number of service paths 
for the same service chain to be reasonable.  The architecture permits 
that.  While I have biases in this regard, I hope that the architecture 
does not.  Given the range of possible deployments, and as you alude to 
the potential changes in technology to support them) I hope we are 
allowing the range, while stillhaving a useful architecture.

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 21:44:10 +0000

For me it is a logical or virtual network over a common physical network. However you view it is not something that stays within a single device.

> From: Ian Smith [mailto:[email-masked]]
> Sent: Thursday, July 10, 2014 5:38 PM
> To: NAPIERALA, MARIA H; Joel Halpern Direct; Joel M. Halpern;
> [email-masked]; [email-masked]
> Managing millions of 5-tuple flows in a single appliance is not the same as
> managing (globally) millions of service paths which are essentially logical
> networks. And 16 million was an arbitrary number for just 100 service
> chains. 100 service chains is very little. Image this number be two or more
> orders of magnitude higher...
> 
> > >>>> How many path identifiers there will be for a 4 hop service chain
> with
> > >>>> 20 instances at each hop?
> > >>>>
> > >>>> Maria
> > >>>>
> > >>>> for forwarding based on chain or path and the choice of chain or
> path
> > to
> to
> marks
> appears
> to

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:50:26 +0000

> However you view it is not something that stays within a single device.

Agreed.  But I'm not asserting that it does.  What I am asserting is that the scale of what a single device can do today matters when thinking about how to do almost exactly what that device does in a distributed manner.

Picking channelized paths through packet switched networks is making the network stateful, so if you can, for example be stateful to the order of 50 or 100 million flows in an existing single node, then you should _at the very least_ expect to have 50 to 100 million flows in the distributed system that takes its place. 

Sent: Thursday, July 10, 2014 5:44 PM

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:52:40 +0000

I think that what you just defined is the Service Function Chain.

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 21:54:45 +0000

Thanks.

I'm  relieved.
________________________________________
From: Joel M. Halpern [[email-masked]]
Sent: Thursday, July 10, 2014 5:43 PM
To: Ian Smith; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 10 Jul 2014 18:10:49 -0400

I don't see anything in the arch draft that suggests any sort of limit.  However, it does seem to indicate that the entire path (all SFIs) must be chosen at SFC instantiation.  I believe this means either at the classifier or maybe the classifier chooses a SF Chain and the NF or at the latest the first SFF.  In any case, the language does seem to prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1) hop.  According to the draft, this behavior would be considered "branching" to a new SFP as opposed to choosing and then forwarding to the selected instance of the next-hop of the current SFC.
draft-merged-sfc-architecture-00:>  When an SFC is instantiated into the network it is necessary to
>  The SFC architecture supports reclassification (or non-initial
>  classification) as well.  As packets traverse an SFP,
>  reclassification may occur - typically performed by a classification
>  function co-resident with a service function.  Reclassification may
>  result in the selection of a new SFP, an update of the associated
>  metadata, or both.  This is referred to as "branching".

From: [email-masked]<[email-masked]>
To: Joel Halpern Direct<[email-masked]>,Joel M. Halpern<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

From: Joel Halpern Direct [[email-masked]]Sent: Thursday, July 10, 2014 5:04 PMTo: Ian Smith; Joel M. Halpern; [email-masked]; [email-masked]: Re: [sfc] Service Chains, Paths, and Load BalancersIan, I don't think you disagree with me at all in this regard.I am not requesting the the architecture or the solution prohibitdeployments in the specific fashion.I am objecting to Huang's reading of my note as saying that suchdeployments are required they by the archtiecture.As I have said repeatedly, I am not trying to prohibit such things.Whether they are a good idea or not depends upon many factors outside ofthe scope of the WG.  I happen to think that they are usually a bad idea.But the archtiecture si carefully avoiding attempting to know what isand is not eployable.Yours,JoelOn 7/10/14, 5:01 PM, Ian Smith wrote:> I disagree.>> We routinely have stateful devices that manage tens of millions of concurrent flows in both access network and data center environments today.  You can't seriously believe that in the Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going to have small numbers of service chains with equally small numbers of active service paths?>> Your sounds too much like "no one will ever need more than 64K" for comfort.>>> ________________________________________> From: sfc [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]> Sent: Thursday, July 10, 2014 4:46 PM> To: [email-masked]; [email-masked]> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> No, it will mean that if someone tries to deploy the archtieture> particularly badly, they will exceed the limits of their devices.> The architecture does not require such absurd use of service paths.> Since I can not figure out how to write architectural words to prohibit> it, the architecture does permit such abuse.>> Please do not read my saying that the archtiecture permits something as> saying it is either deisred or required by the work.  It isn't.>> Yours,> Joel>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>> If you need to support 100 service chains, it will mean 16,000,000>> paths. That is larger than the routing table of a core router.>>>> Chang>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>>> The architecture allows a range of deployments, from 1 service path to>>> 160000 service paths.  I would hope that operators are prepared for>>> the complexities if they choose to avoid any use of local load>>> balancing and in stead provision 160,000 service paths.>>>>>> Yours,>>> Joel>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>>>> Paul,>>>>>>>> How many path identifiers there will be for a 4 hop service chain with>>>> 20 instances at each hop?>>>>>>>> Maria>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Paul Quinn>>>> (paulq)>>>> *Sent:* Thursday, July 10, 2014 3:03 PM>>>> *To:* Lucy yong>>>> *Cc:* [email-masked]; [email-masked]; [email-masked];>>>> [email-masked]>>>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>> Lucy,>>>>>>>> Overall I concur, as you say: a path ID drives the forwarding. I’d make>>>> the minor change: the path identifier can be used to derive the needed>>>> forwarding and associated transport.>>>>>>>> It is _not_ the transport, but rather is used to simply identify the>>>> service path (or graph) that packets must traverse.  By having a path>>>> identifier, the exact indirection that people seem to be asking for on>>>> this thread can be simply be implemented.  The path identifier provides>>>> nothing more than a lookup, that lookup can result in a one or more>>>> (equal or weighted) transport next hop(s).>>>>>>>> Paul>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong <[email-masked]>>>> <mailto:[email-masked]>> wrote:>>>>>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the service path>>>> identifier to drive the forwarding actions.>>>>>>>> Lucy>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>>>> [email-masked] <mailto:[email-masked]>>>>> *Sent:*Thursday, July 10, 2014 2:06 AM>>>> *To:[email-masked] <mailto:[email-masked]>;[email-masked]>>>> <mailto:[email-masked]>;[email-masked] <mailto:[email-masked]>>>>> *Subject:*Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>> Re-,>>>>>>>> The merged draft calls out explicitly a service path identifier. I>>>> object to use that identifier to derive forwarding actions.>>>>>>>> Requiring a SFC system to have the full knowledge of every available SFC>>>> forwarding paths within an SFC-enabled domain is not required/justified>>>> nor possible in various deployment contexts.>>>>>>>> SFC forwarding actions should rely on the piece of information that will>>>> be present in all deployments: that is the one required to structure a>>>> service chain. How that information is used to infer forwarding actions>>>> is a solution-oriented discussion.>>>>>>>> Cheers,>>>>>>>> Med>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part [email-masked]>>>> <mailto:[email-masked]>>>>> *Envoyé :*mercredi 9 juillet 2014 22:03>>>> *À :[email-masked] <mailto:[email-masked]>;[email-masked]>>>> <mailto:[email-masked]>>>>> *Objet :*Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>> Is anyone still questioning the difference between SF Chain and SF Path?>>>>    Other than clarifying the definition so that it's clear to those not>>>> familiar with the draft, it seems that everyone agrees on these terms.>>>>>>>> To me, the one point that is still unclear is whether it is the intent>>>> of this draft to ultimately specify what the ID of the SFC Header should>>>> reference (the chain or the path), or if this draft simply intends to>>>> leave that ambiguous, allowing other drafts to dictate the mechanisms>>>> for forwarding based on chain or path and the choice of chain or path to>>>> be negotiated in the control-plane.>>>>>>>> If the latter (ambiguous), then the draft would have require that both>>>> SFP and SFC be supported (or make one required and the other optional)>>>> to avoid some vendors only supporting SFP and others only supporting>>>> SFC.>>>>>>>> ------------------------------------------------------------------------>>>>>>>> *From:[email-masked]<[email-masked]>>>> <mailto:[email-masked][email-masked]>>>>>> *To:[email-masked]<[email-masked] <mailto:[email-masked][email-masked]>>>>>> *Sent:*Tuesday, July 8, 2014>>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers>>>>>>>> I have been trying to figure out how to clearly answer a number of>>>> comments that have been made about the proposed merged archtiecture>>>> draft. Assuming we can get working group agreement on the intent, we>>>> will work to improve the wording so that readers who have not>>>> participated in the WG discussion will understnd it the way the working>>>> group intends.>>>>>>>> But what do we intend? I will try to explain my personal view, and see>>>> if that helps.>>>>>>>> In this regard, it is important to keep in mind that what we are>>>> defining is the data plane architecture. We are not attempting to>>>> define the architecture for the entire solution for service chaining.>>>> That would encompass OSS/BSS, various control and policy functions,>>>> virtual machine and image management, and many other aspects.>>>>>>>> As a result there are many things which clearly need to exist in the>>>> larger system, but which are dealt with above where we are functioning,>>>> and are not directly required by the work we are doing.>>>>>>>> In order to get to service chain vs service path, as I understand them,>>>> I need to first discuss load balancing. There are at least three>>>> different ways that load balancing can and will interact with service>>>> chaining. There probably are more. The point of the archtiecture is to>>>> permit all of these, but not to mandate that any particular kind be used>>>> in any solution.>>>>>>>> 1) Load balancing as a service provided to the end user. This is a>>>> service function. It receives user packets, and modifies them (or marks>>>> them, or ...) so as to choose an end user service instance to receive>>>> the users packet. This is an important service function to be able to>>>> include in service chaining. It's behavior may affect requirements on>>>> how service chaining is done. But it has very little impact on the>>>> archtiecture. From an architectural pe3rspective it is simply a service>>>> function which may modify the underlying packet.>>>>>>>> 2) There is internal load balancing. That is, one can have what appears>>>> to the service chaining architecture as a single point of contact for a>>>> specific service function, but is actually delivered by a collection of>>>> virtual or physical machines, possibly including one or several load>>>> balancers (for example using VRRP-like techniques to share a MAC>>>> address.) mostly, this is invisible to the service chaining data plane>>>> mechanisms. It is likely that it is visible to various control>>>> mechanisms, such as those responsible for scale-in, scale-out, and vm>>>> instantiation. The architectural impact of permitting this is largely>>>> that we need to be careful that our terminology does not lead readers to>>>> think we are prohibiting it.>>>>>>>> 3) There can also be load balancing done by selecting packet paths for>>>> the service chaining that direct traffic to different places. We would>>>> not want to require that a given service function appear at only one>>>> place in the network.>>>>>>>> It is of course the case that these may be combined. I tend to refer to>>>> the collection of entities that appear to service chaining as a single>>>> point as a cluster. Not because cluster is a good term. But because I>>>> do not have another one. Thus, the point of type 3 load balancing is to>>>> direct different subsets of traffic to different singular or clustered>>>> service functions in different places in the network.>>>>>>>> Now with that said, what do I mean when I talk about service chain and>>>> service path/ Service chain is a sequence of logical functions to be>>>> applied to a subset of packets. It is equivalent of saying that some>>>> subset of traffic is to get DPI, charging, content inspection, and>>>> firewall while a different subset is to go directly to the cache without>>>> visiting any other service functions.>>>>>>>> That is not enough information to direct the packets. A service path>>>> is, in some fashion, a sequence of locations in the network. Those>>>> locations will be singular or clustered service function delivery>>>> locations. They may be addressed by IP address. They may be addressed>>>> as ports on an SFF. There are many different ways that the locations>>>> may be known to the service chaining infrastructure and the transport.>>>>>>>>   >From the point of view of the work of the SFC group, we need to be>>>> able>>>> to talk about the high level abstraction, the service chain, which>>>> drives the forwarding. And we need to talk about the actual data path>>>> packets will take in the network.>>>>>>>> Several of the comments have said "but the whole path may not be known>>>> at the front." This architecture deals with that issue in two ways.>>>> First, as noted in item (2) on load balancers above, there can be>>>> decisions and behaviors which are invisible to the service chaining>>>> mechanisms (in much the same way that bridging within a LAN is largely>>>> invisible to routing between LANs.) The other provision we make is that>>>> reclassification can be done in mid-chain when necessary. That will>>>> direct packets to a new chain. Based on information available at the>>>> re-classification point.>>>>>>>> I hope that this helps explain what we are after. If it does, and if>>>> the intent is acceptable to the working group, we can figure out what>>>> additional words are needed to convey this.>>>> If the working group disagree with the intent, then we will of course>>>> adjust to match the working group agreements.>>>> If this is still unclear, I am not sure what to try next.>>>>>>>> Yours,>>>> Joel>>>>>>>> _______________________________________________>>>> sfc mailing list>>>> [email-masked] <mailto:[email-masked]>>>>> https://www.ietf.org/mailman/listinfo/sfc>>>>>>>> _______________________________________________>>>> sfc mailing list>>>> [email-masked] <mailto:[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>>>> _______________________________________________> sfc mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/sfc>_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 10 Jul 2014 18:15:41 -0400

The way the architecture models the case of SF1 needing to influence the 
chain is that one would do reclassification at the exit from SF1.

Part of the goal is to keep the different functions logically separate 
so that solutions can clearly describe how they choose to compose them 
for "service" delivery.

Yours,
Joel

On 7/10/14, 6:10 PM, [email-masked] wrote:
> I don't see anything in the arch draft that suggests any sort of limit.
>   However, it does seem to indicate that the entire path (all SFIs) must
> be chosen at SFC instantiation.  I believe this means either at the
> classifier or maybe the classifier chooses a SF Chain and the NF or at
> the latest the first SFF.  In any case, the language does seem to
> prohibit a more dynamic SFP where SFI(n) is determined at the SFI(n-1)
> hop.  According to the draft, this behavior would be considered
> "branching" to a new SFP as opposed to choosing and then forwarding to
> the selected instance of the next-hop of the current SFC.
>
> draft-merged-sfc-architecture-00:
> *From: [email-masked]<[email-masked]>
> *To: *Joel Halpern Direct<[email-masked]>,Joel M.
> Halpern<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
> If the possibility of medium-scale deployments (and that is what 16
> million flows is in my world) of service chains is preconceived as an
> absurd idea, then the architecture burdened with that preconception.
>
> There has to be some point of aim, some degree of aspiration to scale
> that is appropriate for the lifespan of the architecture - you don't
> have to know what it is, but by saying that an arbitrary number is "too
> far", you're creating - even if it isn't intentional - a limit that
> influences decisions that have lasting impacts regarding scale-out,
> failure mitigation, elasticity, address space... all kinds of things.
> That is a problem I'm not particularly eager to deal with.
>
>
>
>
> have small numbers of service chains with equally small numbers of
> active service paths?
>  >
> path to

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 22:11:49 +0000

> Agreed.  But I'm not asserting that it does.  What I am asserting is that the
> scale of what a single device can do today matters when thinking about
> how to do almost exactly what that device does in a distributed manner.

> Picking channelized paths through packet switched networks is making the
> network stateful, so if you can, for example be stateful to the order of 50 or
> 100 million flows in an existing single node, then you should _at the very
> least_ expect to have 50 to 100 million flows in the distributed system that
> takes its place.

I wonder what scale we would have achieved if we were managing TCP/IP flows in Internet core network routers.

> For me it is a logical or virtual network over a common physical network.
> > A service path isn't a logical network; it is  - quite literally - a path
> _though_
> > a network.
> >
> >
> >
> > To: Ian Smith; Joel Halpern Direct; Joel M. Halpern;
> [email-masked];
> > [email-masked]
> > million
> > that
> > > Whether they are a good idea or not depends upon many factors
> outside
> > of
> active
> > > >>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Paul
> Quinn
> > > >>>> (paulq)
> > > >>>> be present in all deployments: that is the one required to
> structure
> > a
> > > >>>> draft. Assuming we can get working group agreement on the
> intent,
> > > we
> > > >>>> do not have another one. Thus, the point of type 3 load balancing
> is
> > > to
> > > >>>> Now with that said, what do I mean when I talk about service
> chain
> > > and
> > > >>>> Several of the comments have said "but the whole path may not
> be
> > > known

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 22:22:06 +0000

I'm not saying creating stateful service channels on packet networks is a good thing, but it is what people are asking for, and if we are going to do it we should do it right.

If you want stateless service chains, you would do it with IP source routing

Sent: Thursday, July 10, 2014 6:11 PM

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 22:25:05 +0000

> I'm not saying creating stateful service channels on packet networks is a
> good thing, but it is what people are asking for, and if we are going to do it
> we should do it right.

Who is asking? 

> If you want stateless service chains, you would do it with IP source routing

Why source routing? Is this is the only choice? 
 
> > > > Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only
> going
> > to
> > > > > Your sounds too much like "no one will ever need more than 64K"
> for
> > > > comfort.
> > > > >
> > > > >
> > > > > Please do not read my saying that the archtiecture permits
> something
> > > as
> > > > >>> The architecture allows a range of deployments, from 1 service
> path
> > > to
> > > > >>>> But what do we intend? I will try to explain my personal view,
> and
> > > see
> > > > >>>> if that helps.
> > > > >>>>
> > > > >>>> permit all of these, but not to mandate that any particular kind
> be
> > > > used
> > > > >>>> in any solution.
> > > > >>>>
> > > > >>>> to the service chaining architecture as a single point of contact
> for
> > a
> > > > >>>> mechanisms, such as those responsible for scale-in, scale-out,
> and
> > > vm
> > > > >>>> 3) There can also be load balancing done by selecting packet
> paths
> > > for
> > > > >>>> point as a cluster. Not because cluster is a good term. But
> because
> > I
> > > > >>>>   >From the point of view of the work of the SFC group, we need
> to
> > > be
> > > > >>>> able
> > > > >>>> invisible to routing between LANs.) The other provision we make
> is
> > > > that

---

From: "Zarny, Myo" <[email-masked]>
Date: Thu, 10 Jul 2014 18:33:12 -0400

I brought up GSLB only to illustrate that next-hop selection can be done in some other way. But I think you get my point.

To me, "traffic distribution" is an improvement over "load distribution" only because it's not too close to load balancing. But I'm not wedded to it. I'll be fine with any term that is less loaded and less likely to cause confusion.

Myo

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard Time
To: Zarny, Myo [Tech]; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Regards,

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

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Thu, 10 Jul 2014 22:55:58 +0000

> Who is asking?
There have been large rooms packed with people at IETF87, IETF88, and IETF89 asking for it.

> Why source routing? 

Other than IP source routes are by definition solving the same problem as Service Function Chains and are already part of a standard?  No reason.
Unfortunately router companies have optimized their chips and os for destination routing and it is easily spoofed if you don't use AH, so it's gotten a bum rap.  In our collective wisdom, we actually deprecated the IPv6 Type 0 Routing Header in 2007 (rfc5095) and then created a whole new one from scratch in 2012 for the IoT (rfc6554) when we realized we actually needed it.

> Is this is the only choice?

No.  You could use MPLSoIP. If there was good MPLS networking in the Linux kernel, I suppose you could use MPLSoE (servers have to be able to talk to the network).  Or you could use an elastic infrastructure to just provision instances of services that have the next link in the chain as their next-hop gateway (technically that is moving the state out of the data plane, although I probably wouldn't call it stateless).  Anything that either takes the next hop decision away by making it the default or carrying it along with the packet that doesn't also require distributing a referential policy has a strong case for statelessness.

The early drafts of the problem statement had a section where these kinds of solutions were ruled out as having too many barriers to implementation (IIRC), so we are doing circuit switching over packet networks. 

Sent: Thursday, July 10, 2014 6:25 PM

Who is asking?

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Thu, 10 Jul 2014 22:58:11 +0000

If this is indeed the case (as Mike pointed out) that in the proposed architecture the SFI(n) cannot be determined at the SFI(n-1) hop (except by changing the service path) then clearly the choice of, say, which one of 20 service instances of one service hop has to be done at the entry to the chain.  We have just discussed it, and it was stated that it is not the case. Can the authors clarify?

Maria

> Sent: Thursday, July 10, 2014 6:16 PM
> To: [email-masked]; [email-masked]; [email-masked]
> > be used
> > for a
> > is to

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 19:08:04 -0400

The choice of which instance of SF-X is to be used for a given packet on 
Service Path Y is made either at or behind thee SFF serving SF-X.  The 
Service Path determines which SFF the packet will get to.  If there are 
multiple instances behind that SFF, then either the SFF includes a load 
balancer, or it talks to a (or a redundant pair of) load balancers.  It 
is the load balancer function which selects the  actual instance to 
receive the packet.

Thus, there is one service path, directing packets to a sequence of SFF 
which are tasked with delivering the packets to specific service 
functions.  Each SFF may be delivering to a single Service Function, a 
redundant pair, a load balanced cluster, or any other service delivery 
architecture.  Whether the load balancing is stateful, lightly stateful 
(whatever that happens to mean) or stateless depends upon what is 
deployed and what is needed by the service function instances.  It is 
not determined by the SFC architecture, and I don't expect the SFC 
solution to mandate a particular answer either.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Fri, 11 Jul 2014 01:38:43 +0000

This is the crux of my issue.   Is the end to end selection of (top-level) instances performed centrally (perhaps by the classifier) or hop-by-hop (perhaps by the classifier and subsequently the SFFs)?   Such selection is not equivalent to reclassification.   And surely, this is an architectural issue and not relegated to "implementation".   

My own view is to favor the distributed approach even though a greater amount of data (chain definitions and perhaps local selection policy) is required at those distributed decision points.   This approach does not require an end-to-end path id at all.    My rationale for favoring this approach is primarily driven by increased resiliency over the global path id approach.   With a global path id approach, consider failure of an instance and needing to alter the global path ID table for each and every affected end-to-end path.

   Ron

________________________________________
From: sfc [[email-masked]] on behalf of Joel Halpern Direct [[email-masked]]
Sent: Thursday, July 10, 2014 6:15 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Fri, 11 Jul 2014 01:40:02 +0000

"next-service-hop selection" ?

________________________________
From: sfc [[email-masked]] on behalf of Zarny, Myo [[email-masked]]
Sent: Thursday, July 10, 2014 6:33 PM
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Myo

Regards,

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

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 21:45:24 -0400

This is an architectural issue.  And one that I would prefer we actually
decide, rather than trying to allow all possible implementations.
Because it does have a major effect on the control requirements and the
functionality of SFFs.

For me, the amount of information about service instances that needs to
be widely distributed and maintained, potentially even across data
centers within an administrative scope, is large enough and complex
enough that trying to get that into each SFF seems like a difficult
architecture to realize.

Yours,
Joel

But it is a fair question.

On 7/10/14, 9:38 PM, Ron Parker wrote:
> This is the crux of my issue.   Is the end to end selection of
> (top-level) instances performed centrally (perhaps by the classifier)
> or hop-by-hop (perhaps by the classifier and subsequently the SFFs)?
> Such selection is not equivalent to reclassification.   And surely,
> this is an architectural issue and not relegated to
> "implementation".
>
> My own view is to favor the distributed approach even though a
> greater amount of data (chain definitions and perhaps local selection
> policy) is required at those distributed decision points.   This
> approach does not require an end-to-end path id at all.    My
> rationale for favoring this approach is primarily driven by increased
> resiliency over the global path id approach.   With a global path id
> approach, consider failure of an instance and needing to alter the
> global path ID table for each and every affected end-to-end path.
>
> Ron
>
> ________________________________________ From: sfc
> [[email-masked]] on behalf of Joel Halpern Direct
> [[email-masked]] Sent: Thursday, July 10, 2014 6:15 PM
> To: [email-masked]; [email-masked]; [email-masked] Subject: Re:
> [sfc] Service Chains, Paths, and Load Balancers
>
> The way the architecture models the case of SF1 needing to influence
> the chain is that one would do reclassification at the exit from
> SF1.
>
> Part of the goal is to keep the different functions logically
> separate so that solutions can clearly describe how they choose to
> compose them for "service" delivery.
>
> Yours, Joel
>
>> I don't see anything in the arch draft that suggests any sort of
>> limit. However, it does seem to indicate that the entire path (all
>> SFIs) must be chosen at SFC instantiation.  I believe this means
>> either at the classifier or maybe the classifier chooses a SF Chain
>> and the NF or at the latest the first SFF.  In any case, the
>> language does seem to prohibit a more dynamic SFP where SFI(n) is
>> determined at the SFI(n-1) hop.  According to the draft, this
>> behavior would be considered "branching" to a new SFP as opposed to
>> choosing and then forwarding to the selected instance of the
>> next-hop of the current SFC.
>>
>>> select the specific instances of SFs that will be used, and to
>>> create the service topology for that SFC using SF's network
>>> locator.  Thus, instantiation of the SFC results in the creation
>>> of a Service Function Path (SFP) and is used for forwarding
>>> packets through the SFC. In other words, an SFP is the
>>> instantiation of the defined SFC.
>>>
>>> reclassification may occur - typically performed by a
>>> classification function co-resident with a service function.
>>> Reclassification may result in the selection of a new SFP, an
>>> update of the associated metadata, or both.  This is referred to
>>> as "branching".
>>
>>
>>
>> If the possibility of medium-scale deployments (and that is what
>> 16 million flows is in my world) of service chains is preconceived
>> as an absurd idea, then the architecture burdened with that
>> preconception.
>>
>> There has to be some point of aim, some degree of aspiration to
>> scale that is appropriate for the lifespan of the architecture -
>> you don't have to know what it is, but by saying that an arbitrary
>> number is "too far", you're creating - even if it isn't intentional
>> - a limit that influences decisions that have lasting impacts
>> regarding scale-out, failure mitigation, elasticity, address
>> space... all kinds of things. That is a problem I'm not
>> particularly eager to deal with.
>>
>>
>>
>>
>> From: Joel Halpern Direct [[email-masked]] Sent:
>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;
>> [email-masked]; [email-masked] Subject: Re: [sfc] Service
>> Chains, Paths, and Load Balancers
>>
>> Ian, I don't think you disagree with me at all in this regard. I am
>> not requesting the the architecture or the solution prohibit
>> deployments in the specific fashion. I am objecting to Huang's
>> reading of my note as saying that such deployments are required
>> they by the archtiecture.
>>
>> As I have said repeatedly, I am not trying to prohibit such
>> things. Whether they are a good idea or not depends upon many
>> factors outside of the scope of the WG. I happen to think that they
>> are usually a bad idea.
>>
>> But the archtiecture si carefully avoiding attempting to know what
>> is and is not eployable.
>>
>> Yours, Joel
>>
>> concurrent flows in both access network and data center
>> environments today. You can't seriously believe that in the
>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only going
>> to have small numbers of service chains with equally small numbers
>> of active service paths?
>>>
>>> ________________________________________ From: sfc
>>> [[email-masked]] on behalf of Joel M. Halpern
>> [[email-masked]]
>>> Sent: Thursday, July 10, 2014 4:46 PM To: [email-masked];
>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths, and Load
>>> Balancers
>>>
>>> particularly badly, they will exceed the limits of their
>>> devices. The architecture does not require such absurd use of
>>> service paths. Since I can not figure out how to write
>>> architectural words to prohibit it, the architecture does permit
>>> such abuse.
>>>
>>> something as saying it is either deisred or required by the work.
>>> It isn't.
>>>
>>> Yours, Joel
>>>
>>>> If you need to support 100 service chains, it will mean
>>>> 16,000,000 paths. That is larger than the routing table of a
>>>> core router.
>>>>
>>>> Chang
>>>>
>>>>> The architecture allows a range of deployments, from 1
>>>>> service path to 160000 service paths. I would hope that
>>>>> operators are prepared for the complexities if they choose to
>>>>> avoid any use of local load balancing and in stead provision
>>>>> 160,000 service paths.
>>>>>
>>>>> Yours, Joel
>>>>>
>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03
>>>>>> PM *To:* Lucy yong *Cc:* [email-masked];
>>>>>> [email-masked] *Subject:* Re: [sfc] Service Chains,
>>>>>> Overall I concur, as you say: a path ID drives the
>>>>>> forwarding. I’d
>> make
>>>>>> the minor change: the path identifier can be used to derive
>>>>>> the needed forwarding and associated transport.
>>>>>>
>>>>>> It is _not_ the transport, but rather is used to simply
>>>>>> identify the service path (or graph) that packets must
>>>>>> traverse. By having a path identifier, the exact
>>>>>> indirection that people seem to be asking for on this
>>>>>> thread can be simply be implemented. The path identifier
>>>>>> provides nothing more than a lookup, that lookup can result
>>>>>> in a one or more (equal or weighted) transport next
>>>>>> hop(s).
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong
>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Agree. The arch. doc should not mandate only use of the
>>>>>> service path identifier to drive the forwarding actions.
>>>>>>
>>>>>> Lucy
>>>>>>
>>>>>> [email-masked]
>>>>>> <mailto:[email-masked]> *Sent:*Thursday, July
>>>>>> 10, 2014 2:06 AM *To:[email-masked]
>>>>>> <mailto:[email-masked]>;[email-masked]
>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service Chains,
>>>>>> The merged draft calls out explicitly a service path
>>>>>> identifier. I object to use that identifier to derive
>>>>>> forwarding actions.
>>>>>>
>>>>>> SFC forwarding actions should rely on the piece of
>>>>>> information
>> that will
>>>>>> structure a service chain. How that information is used to
>>>>>> infer forwarding
>> actions
>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9 juillet
>>>>>> 2014 22:03 *À :[email-masked]
>>>>>> <mailto:[email-masked]>;[email-masked]
>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service Chains,
>>>>>> To me, the one point that is still unclear is whether it is
>>>>>> the intent of this draft to ultimately specify what the ID
>>>>>> of the SFC Header
>> should
>>>>>> reference (the chain or the path), or if this draft simply
>>>>>> intends to leave that ambiguous, allowing other drafts to
>>>>>> dictate the mechanisms for forwarding based on chain or
>>>>>> path and the choice of chain or
>> path to
>>>>>> If the latter (ambiguous), then the draft would have
>>>>>> require that both SFP and SFC be supported (or make one
>>>>>> required and the other optional) to avoid some vendors only
>>>>>> supporting SFP and others only supporting SFC.
>>>>>>
>>>>>>
>>>>>> *To:[email-masked]<[email-masked]
>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July
>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load
>>>>>> Balancers
>>>>>>
>>>>>> I have been trying to figure out how to clearly answer a
>>>>>> number of comments that have been made about the proposed
>>>>>> merged archtiecture draft. Assuming we can get working
>>>>>> group agreement on the intent, we will work to improve the
>>>>>> wording so that readers who have not participated in the WG
>>>>>> discussion will understnd it the way the
>> working
>>>>>> group intends.
>>>>>>
>>>>>> But what do we intend? I will try to explain my personal
>>>>>> view, and see if that helps.
>>>>>>
>>>>>> In this regard, it is important to keep in mind that what
>>>>>> we are defining is the data plane architecture. We are not
>>>>>> attempting to define the architecture for the entire
>>>>>> solution for service chaining. That would encompass
>>>>>> OSS/BSS, various control and policy functions, virtual
>>>>>> machine and image management, and many other aspects.
>>>>>>
>>>>>> As a result there are many things which clearly need to
>>>>>> exist in the larger system, but which are dealt with above
>>>>>> where we are
>> functioning,
>>>>>> In order to get to service chain vs service path, as I
>>>>>> understand
>> them,
>>>>>> I need to first discuss load balancing. There are at least
>>>>>> three different ways that load balancing can and will
>>>>>> interact with service chaining. There probably are more.
>>>>>> The point of the archtiecture is to permit all of these,
>>>>>> but not to mandate that any particular kind
>> be used
>>>>>> in any solution.
>>>>>>
>>>>>> 1) Load balancing as a service provided to the end user.
>>>>>> This is a service function. It receives user packets, and
>>>>>> modifies them (or
>> marks
>>>>>> them, or ...) so as to choose an end user service instance
>>>>>> to receive the users packet. This is an important service
>>>>>> function to be able to include in service chaining. It's
>>>>>> behavior may affect requirements on how service chaining is
>>>>>> done. But it has very little impact on the archtiecture.
>>>>>> From an architectural pe3rspective it is simply a
>> service
>>>>>> virtual or physical machines, possibly including one or
>>>>>> several load balancers (for example using VRRP-like
>>>>>> techniques to share a MAC address.) mostly, this is
>>>>>> invisible to the service chaining data plane mechanisms. It
>>>>>> is likely that it is visible to various control mechanisms,
>>>>>> such as those responsible for scale-in, scale-out, and vm
>>>>>> instantiation. The architectural impact of permitting this
>>>>>> is largely that we need to be careful that our terminology
>>>>>> does not lead
>> readers to
>>>>>> 3) There can also be load balancing done by selecting
>>>>>> packet paths for the service chaining that direct traffic
>>>>>> to different places. We would not want to require that a
>>>>>> given service function appear at only one place in the
>>>>>> network.
>>>>>>
>>>>>> It is of course the case that these may be combined. I tend
>>>>>> to
>> refer to
>>>>>> the collection of entities that appear to service chaining
>>>>>> as a single point as a cluster. Not because cluster is a
>>>>>> good term. But because I do not have another one. Thus, the
>>>>>> point of type 3 load balancing
>> is to
>>>>>> direct different subsets of traffic to different singular
>>>>>> or clustered service functions in different places in the
>>>>>> network.
>>>>>>
>>>>>> Now with that said, what do I mean when I talk about
>>>>>> service chain and service path/ Service chain is a sequence
>>>>>> of logical functions to be applied to a subset of packets.
>>>>>> It is equivalent of saying that some subset of traffic is
>>>>>> to get DPI, charging, content inspection, and firewall
>>>>>> while a different subset is to go directly to the cache
>> without
>>>>>> That is not enough information to direct the packets. A
>>>>>> service path is, in some fashion, a sequence of locations
>>>>>> in the network. Those locations will be singular or
>>>>>> clustered service function delivery locations. They may be
>>>>>> addressed by IP address. They may be addressed as ports on
>>>>>> an SFF. There are many different ways that the locations
>>>>>> able to talk about the high level abstraction, the service
>>>>>> chain, which drives the forwarding. And we need to talk
>>>>>> about the actual data path packets will take in the
>>>>>> network.
>>>>>>
>>>>>> Several of the comments have said "but the whole path may
>>>>>> not be known at the front." This architecture deals with
>>>>>> that issue in two ways. First, as noted in item (2) on load
>>>>>> balancers above, there can be decisions and behaviors which
>>>>>> are invisible to the service chaining mechanisms (in much
>>>>>> the same way that bridging within a LAN is largely
>>>>>> invisible to routing between LANs.) The other provision we
>>>>>> make is
>> that
>>>>>> That will direct packets to a new chain. Based on
>>>>>> information available at the re-classification point.
>>>>>>
>>>>>> I hope that this helps explain what we are after. If it
>>>>>> does, and if the intent is acceptable to the working group,
>>>>>> we can figure out what additional words are needed to
>>>>>> convey this. If the working group disagree with the intent,
>>>>>> then we will of course adjust to match the working group
>>>>>> agreements. If this is still unclear, I am not sure what to
>>>>>> try next.
>>>>>>
>>>>>> Yours, Joel
>>>>>>
>>>>>> list [email-masked] <mailto:[email-masked]>
>>>>>> list [email-masked] <mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Fri, 11 Jul 2014 01:56:56 +0000

Joel,

The administrative scope issue is common to both the centralized and distributed next-service-hop approaches in terms of difficulty in gathering the required data.   Once acquired, distribution of that data to fewer entities (ingress nodes) or more entities (ingress nodes plus SFFs) does not seem to be a deal breaker.   Especially since SFF is a construct of our invention with responsibilities determined at our whim.

   Ron

From: Joel M. Halpern [[email-masked]]
Sent: Thursday, July 10, 2014 9:45 PM
To: Ron Parker; Joel Halpern Direct; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Ian Smith <[email-masked]>
Date: Fri, 11 Jul 2014 01:58:25 +0000

>enough that trying to get that into each SFF seems like a difficult

I'm curious as to why that is more complicated than dynamic routing, hyper-scale data center orchestration, or DNS, all of which are bigger problems that have been profitably and stably implemented?

It also seems that if it really is more complicated, that is a good sign that it is too complicated.

To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian Smith; [email-masked]

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 22:06:22 -0400

Part of my personal view is that I am trying to make this work sensibly 
in a more orchestrated environment.  I expect that the service 
functions, and over time probably the SFF capabilities, will be 
orchestrated and installed.  I expect the service chains to be driven by 
BSS tools that define offerings to clients, and enable self-selection 
from these.  I expect service paths to be heavily policy drive.

I can see how to make all of that work in an archtiecture driven by 
initial classification to described service paths.  It is harder to see 
how to make it work (but it can be done) when we allow more dynamicity 
in the network behavior.

Having said that, most of that perspective I described is outside of the 
scope of the working group.  it is not something we are tasked to agree 
on.
So I do not claim that vision means we have to do it a certain way.  it 
is just the perspective that drives my preferences.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 02:24:44 +0000

Inline

Sent from my iPhone

> On Jul 10, 2014, at 9:38 PM, "Ron Parker" <[email-masked]> wrote:
> 

Jim> not at all necessary and any designer worth their salt would design resiliency into their deployment; for example no reason that a backup next-hop SF could not be specified as part of the forwarding logic.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 02:31:46 +0000

Mike,
No as the SPI would be used along with the index to identify which SF needs to be applied and then the SFF would make a local decision as to which of the 20 instances should retrieve the traffic for a given flow received from the SFP.

Sent from my iPhone

On Jul 10, 2014, at 4:46 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Jim,

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>
cc: Paul Quinn (paulq)<[email-masked]<mailto:[email-masked]>>,Lucy yong<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sent from my iPhone

Paul,

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.
Lucy
From: sfc [<mailto:[email-masked]>mailto:[email-masked]] On Behalf Of <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 10, 2014 2:06 AM
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
Re-,
The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.
Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.
SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
Cheers,
Med
De : sfc [<mailto:[email-masked]>mailto:[email-masked]] De la part de <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 9 juillet 2014 22:03
À : <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers
Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.
To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.
If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.
________________________________
From: <mailto:[email-masked][email-masked]> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: <mailto:[email-masked][email-masked]> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

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

---

From: Qin Wu <[email-masked]>
Date: Fri, 11 Jul 2014 02:46:59 +0000

If one service chain can corresponding to multiple service function paths,e .g., in case of all active reduncy,
I think using chain identifier is more reasonable choice since path id is not unique in this case.

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年7月11日 4:47
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

Jim,

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>
cc: Paul Quinn (paulq)<[email-masked]<mailto:[email-masked]>>,Lucy yong<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
1 assuming load is distributed among the 20 instances at each service hop.

Sent from my iPhone

Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Fri, 11 Jul 2014 03:14:13 +0000

-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月11日 9:39
收件人: Joel Halpern Direct; [email-masked]; [email-masked]; [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

[Qin]: If SFC is defined as an ordered list of service function identifiers while SFP is defined as an ordered list of locators of
   each service function that belongs to a service function chain.  Then the service function path can be static or pre-determined
   using specific SF instances, or dynamic - choosing the locators of service explicit SF instances at the time of delivering traffic to
   the SF. It doesn't matter whether it is centralized approach or distributed approached. Centralized approach can be used for better traffic engineering reason.
   In addition, when one SFC can be translated into multiple SFPs in some cases, what we more need is global chain ID instead of path ID since path can be
   Identified by a set of locators allocated to each service function instance that is invoked for a given chain.

   Ron

The way the architecture models the case of SF1 needing to influence the chain is that one would do reclassification at the exit from SF1.

Part of the goal is to keep the different functions logically separate so that solutions can clearly describe how they choose to compose them for "service" delivery.

Yours,
Joel

On 7/10/14, 6:10 PM, [email-masked] wrote:
>   However, it does seem to indicate that the entire path (all SFIs) 
> must be chosen at SFC instantiation.  I believe this means either at 
> the classifier or maybe the classifier chooses a SF Chain and the NF 
> or at the latest the first SFF.  In any case, the language does seem 
> to prohibit a more dynamic SFP where SFI(n) is determined at the 
> SFI(n-1) hop.  According to the draft, this behavior would be 
> considered "branching" to a new SFP as opposed to choosing and then 
> forwarding to the selected instance of the next-hop of the current SFC.
>
> create  >  the service topology for that SFC using SF's network 
> locator.  Thus,  >  instantiation of the SFC results in the creation 
> of a Service  >  Function Path (SFP) and is used for forwarding 
> packets through the  >  SFC. In other words, an SFP is the instantiation of the defined SFC.
>  >
>  >  The SFC architecture supports reclassification (or non-initial  >  
> classification) as well.  As packets traverse an SFP,  >  
> have to know what it is, but by saying that an arbitrary number is 
> "too far", you're creating - even if it isn't intentional - a limit 
> that influences decisions that have lasting impacts regarding 
> scale-out, failure mitigation, elasticity, address space... all kinds of things.
> Whether they are a good idea or not depends upon many factors outside 
> of the scope of the WG. I happen to think that they are usually a bad idea.
>
>  > From: sfc [[email-masked]] on behalf of Joel M. Halpern 
> [[email-masked]]  > Sent: Thursday, July 10, 2014 4:46 PM  > To: 
> [email-masked]; [email-masked]  > Subject: Re: [sfc] Service 
> Chains, Paths, and Load Balancers  >  > No, it will mean that if 
> someone tries to deploy the archtieture  > particularly badly, they 
> will exceed the limits of their devices.
>  > Since I can not figure out how to write architectural words to 
> prohibit  > it, the architecture does permit such abuse.
>  >
> something as  > saying it is either deisred or required by the work. It isn't.
>  >
>  > Yours,
>  > Joel
>  >
> path to  >>> 160000 service paths. I would hope that operators are 
> prepared for  >>> the complexities if they choose to avoid any use of 
> local load  >>> balancing and in stead provision 160,000 service paths.
>  >>>
>  >>> Yours,
>  >>> Joel
>  >>>
>  >>>> How many path identifiers there will be for a 4 hop service 
> chain with  >>>> 20 instances at each hop?
>  >>>>
>  >>>> Maria
>  >>>>
> Quinn  >>>> (paulq)  >>>> *Sent:* Thursday, July 10, 2014 3:03 PM  
> >>>> *To:* Lucy yong  >>>> *Cc:* [email-masked]; 
> [email-masked]; [email-masked];  >>>> [email-masked]  
> >>>>  >>>> Lucy,  >>>>  >>>> Overall I concur, as you say: a path ID 
> drives the forwarding. I’d make  >>>> the minor change: the path 
> identifier can be used to derive the needed  >>>> forwarding and 
> associated transport.
>  >>>>
>  >>>> It is _not_ the transport, but rather is used to simply identify 
> the  >>>> service path (or graph) that packets must traverse. By 
> having a path  >>>> identifier, the exact indirection that people seem 
> to be asking for on  >>>> this thread can be simply be implemented. 
> The path identifier provides  >>>> nothing more than a lookup, that 
> lookup can result in a one or more  >>>> (equal or weighted) transport next hop(s).
>  >>>>
>  >>>> Paul
>  >>>>
>  >>>> Agree. The arch. doc should not mandate only use of the service 
> path  >>>> identifier to drive the forwarding actions.
>  >>>>
>  >>>> Lucy
>  >>>>
>  >>>> *From:*sfc [mailto:[email-masked]]*On Behalf  >>>> 
>  >>>> *Sent:*Thursday, July 10, 2014 2:06 AM  >>>> 
> >>>>  >>>> Re-,  >>>>  >>>> The merged draft calls out explicitly a 
> service path identifier. I  >>>> object to use that identifier to 
> derive forwarding actions.
>  >>>>
>  >>>> Requiring a SFC system to have the full knowledge of every 
> available SFC  >>>> forwarding paths within an SFC-enabled domain is 
> not required/justified  >>>> nor possible in various deployment 
> contexts.
>  >>>>
>  >>>> SFC forwarding actions should rely on the piece of information 
> that will  >>>> be present in all deployments: that is the one 
> required to structure a  >>>> service chain. How that information is 
> used to infer forwarding actions  >>>> is a solution-oriented 
> discussion.
>  >>>>
>  >>>> Cheers,
>  >>>>
>  >>>> Med
>  >>>>
>  >>>> *De :*sfc [mailto:[email-masked]]*De la part 
> [email-masked]  >>>> <mailto:[email-masked]>  >>>> *Envoyé 
> :*mercredi 9 juillet 2014 22:03  >>>> *À :[email-masked] 
>  >>>> To me, the one point that is still unclear is whether it is the 
> intent  >>>> of this draft to ultimately specify what the ID of the 
> SFC Header should  >>>> reference (the chain or the path), or if this 
> draft simply intends to  >>>> leave that ambiguous, allowing other 
> drafts to dictate the mechanisms  >>>> for forwarding based on chain 
> or path and the choice of chain or path to  >>>> be negotiated in the 
> control-plane.
>  >>>>
>  >>>> If the latter (ambiguous), then the draft would have require 
> that both  >>>> SFP and SFC be supported (or make one required and the 
> other optional)  >>>> to avoid some vendors only supporting SFP and 
> others only supporting  >>>> SFC.
>  >>>>
>  >>>>
> <mailto:[email-masked][email-masked]>>
>  >>>> *Subject:*[sfc] Service Chains, Paths, and Load Balancers  >>>>  
> >>>> I have been trying to figure out how to clearly answer a number 
> of  >>>> comments that have been made about the proposed merged 
> archtiecture  >>>> draft. Assuming we can get working group agreement 
> on the intent, we  >>>> will work to improve the wording so that 
> readers who have not  >>>> participated in the WG discussion will 
> understnd it the way the working  >>>> group intends.
>  >>>>
> and see  >>>> if that helps.
>  >>>>
>  >>>> That would encompass OSS/BSS, various control and policy 
> functions,  >>>> virtual machine and image management, and many other aspects.
>  >>>>
>  >>>> As a result there are many things which clearly need to exist in 
> the  >>>> larger system, but which are dealt with above where we are 
> functioning,  >>>> and are not directly required by the work we are 
> doing.
>  >>>>
> understand them,  >>>> I need to first discuss load balancing. There 
> are at least three  >>>> different ways that load balancing can and 
> will interact with service  >>>> chaining. There probably are more. 
> The point of the archtiecture is to  >>>> permit all of these, but not 
> to mandate that any particular kind be used  >>>> in any solution.
>  >>>>
>  >>>> 1) Load balancing as a service provided to the end user. This is 
> a  >>>> service function. It receives user packets, and modifies them 
> (or marks  >>>> them, or ...) so as to choose an end user service 
> instance to receive  >>>> the users packet. This is an important 
> service function to be able to  >>>> include in service chaining. It's 
> behavior may affect requirements on  >>>> how service chaining is 
> done. But it has very little impact on the  >>>> archtiecture. From an 
> architectural pe3rspective it is simply a service  >>>> function which 
> may modify the underlying packet.
>  >>>>
> appears  >>>> to the service chaining architecture as a single point 
> of contact for a  >>>> specific service function, but is actually 
> delivered by a collection of  >>>> virtual or physical machines, 
> possibly including one or several load  >>>> balancers (for example 
> using VRRP-like techniques to share a MAC  >>>> address.) mostly, this 
> is invisible to the service chaining data plane  >>>> mechanisms. It 
> is likely that it is visible to various control  >>>> mechanisms, such 
> as those responsible for scale-in, scale-out, and vm  >>>> 
> >>>> that we need to be careful that our terminology does not lead 
> readers to  >>>> think we are prohibiting it.
>  >>>>
> paths for  >>>> the service chaining that direct traffic to different 
> places. We would  >>>> not want to require that a given service 
> function appear at only one  >>>> place in the network.
>  >>>>
>  >>>> It is of course the case that these may be combined. I tend to 
> refer to  >>>> the collection of entities that appear to service 
> chaining as a single  >>>> point as a cluster. Not because cluster is 
> a good term. But because I  >>>> do not have another one. Thus, the 
> point of type 3 load balancing is to  >>>> direct different subsets of 
> traffic to different singular or clustered  >>>> service functions in 
> different places in the network.
>  >>>>
> chain and  >>>> service path/ Service chain is a sequence of logical 
> functions to be  >>>> applied to a subset of packets. It is equivalent 
> of saying that some  >>>> subset of traffic is to get DPI, charging, 
> content inspection, and  >>>> firewall while a different subset is to 
> go directly to the cache without  >>>> visiting any other service 
> functions.
>  >>>>
>  >>>> That is not enough information to direct the packets. A service 
> path  >>>> is, in some fashion, a sequence of locations in the 
> network. Those  >>>> locations will be singular or clustered service 
> function delivery  >>>> locations. They may be addressed by IP 
> address. They may be addressed  >>>> as ports on an SFF. There are 
> many different ways that the locations  >>>> may be known to the service chaining infrastructure and the transport.
>  >>>>
>  >>>> to talk about the high level abstraction, the service chain, 
> which  >>>> drives the forwarding. And we need to talk about the 
> actual data path  >>>> packets will take in the network.
>  >>>>
>  >>>> Several of the comments have said "but the whole path may not be 
> known  >>>> at the front." This architecture deals with that issue in two ways.
>  >>>> First, as noted in item (2) on load balancers above, there can 
> be  >>>> decisions and behaviors which are invisible to the service 
> chaining  >>>> mechanisms (in much the same way that bridging within a 
> LAN is largely  >>>> invisible to routing between LANs.) The other 
> provision we make is that  >>>> reclassification can be done in 
> mid-chain when necessary. That will  >>>> direct packets to a new 
> chain. Based on information available at the  >>>> re-classification 
> point.
>  >>>>
>  >>>> I hope that this helps explain what we are after. If it does, 
> and if  >>>> the intent is acceptable to the working group, we can 
> figure out what  >>>> additional words are needed to convey this.
>  >>>> If the working group disagree with the intent, then we will of 
> course  >>>> adjust to match the working group agreements.
>  >>>> [email-masked] <mailto:[email-masked]>  >>>> 
>  >>>> [email-masked] <mailto:[email-masked]>  >>>>

---

From: Ian Smith <[email-masked]>
Date: Fri, 11 Jul 2014 03:41:56 +0000

That is the same way I'm looking at it.

I do see a possible way to make conditional service function paths that don't need to rely on SNF or SFF.  And I see away possible way to make composite or federated SFI assignments to a service function path from multiple policy agencies to support things like roaming or tenant controlled service function domains within .

I don't think that we need to be proscriptive about how the inputs to the service function path selection get there, because that is going to vary.  No matter how this is provisioned, we know a few things:

If something triggers a service function chain selection (how a selection is triggered doesn't matter):
 - A service function chain must be selected (how is an implementation detail).  
 - A service function instance in position 1 in the service function path must be selected to arrive at the initial state (how is an implementation detail).
- To move from position 1 to position 2 the location of position 2 must be identified (how is an implementation detail).
 
Therefore, we can say that in general, to move from position n to position n+1 the location of position n+2 must be identified.   If position n+1 cannot be identified, then position n executes it's fallback contingency.

That is enough architecture to build a sophisticated system if we are ignoring the policy and orchestration plane.     

________________________________________ 
From: Joel M. Halpern [[email-masked]
Sent: Thursday, July 10, 2014 10:06 PM
To: Ian Smith; Ron Parker; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

On 7/10/14, 9:58 PM, Ian Smith wrote:
>>>>>>> chain with 20 instances at each hop?
>>>>>>>
>>>>>>> Maria
>>>>>>>
>>> available SFC
>>> [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Jul 2014 23:53:25 -0400

Ron, thinking about this, I realized another major problem with the your 
proposal as I understand it.  (And I readily admit I may not understand it.)

The proposal has each SFF serve as the load balancer for the next 
service function that follows it (not the one it delivers to), in every 
service chain that goes through it.

Since it has to be able to work with all services, that means that every 
SFF would have to be a full, flow sensitive and stateful load balancer.
I ahve no problem if some SFF are flow sensitive, and / or stateful. 
But having the architecture require that every SFF be a full, flow 
sensitive, stateful, load balancer seems to me to be an acceptable 
imposition.

Yours,
Joel

On 7/10/14, 10:06 PM, Joel M. Halpern wrote:
> scope of the working group.  it is not something we are tasked to agree on.
>> I'm curious as to why that is more complicated than dynamic routing,
>> hyper-scale data center orchestration, or DNS, all of which are bigger
>> problems that have been profitably and stably implemented?
>>

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 07:49:49 +0000

Hi Joel,

This is one possible approach, but what several of us are trying to clarify is this is one approach among others, not possible in some contexts, more complex to ensure resiliency, etc.  Below some of my concerns about your approach:

(1) Having an entity that maintains a large set of service paths in a given domain is more like creating circuits...I thought distributed routing has shown its efficiency. 
(2) Policies are everywhere in the network , not only at the SFC structuring system.
(3) Path selection is dynamic by nature because it depends on various heuristics and policies that are distributed in the network (including those of SFs and others).
(4) Having a stateful function that maintains the full list of available paths may not be that resilient. This must assess frequently (very short cycle)  valid and serviceable paths among available ones. Ensuring the same level of resilience would require additional features to be supported by to that entity maintaining the full set of path, and also SFs.
(5) Load-balancing at a centralized entity is deployment-specific; as such it is not required nor possible in those contexts. Deciding the forwarding path a priori contradicts LB requirements. I know your answer about re-classification, but IMHO the architecture should not mandate an optional feature only because of some design choices. Re-classification should be avoided as much for the same of performance and also because this one of the complexity vector for this work. 
(6) There are a bunch of solutions that achieve differentiated forwarding without requiring a pre-computation/pre-determination of a path: think about ToS-based routing, multi-topology routing, etc. 

I could live with an optional capability that a path can be pre-determined, but this must not be the rule. 

Forwarding within an SFC-enabled domain is primarily inferred by the service function chain itself. How this information is used to drive forwarding actions is all about details. 

Cheers,
Med

>Envoyé : vendredi 11 juillet 2014 04:06
>À : Ian Smith; Ron Parker; [email-masked]; [email-masked]
>>>>>>>> forwarding. I'd

---

From: "Russ White" <[email-masked]>
Date: Fri, 11 Jul 2014 06:56:17 -0400

> I think SFC should be more concerned about ensuring that function chaining
> solutions do not preclude load distribution.

Correct -- SFC cannot ensure load is distributed properly, as that is
(should be) a local policy. All we can do in SFC is to make certain the
tools are place to allow service chains to be built to multiple instances of
the same service, and let the policy mechanisms decide which flows should be
routed to which instances of which services where.

:-)

Russ

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 08:07:42 -0400

And it was pointed out to me that I made a two letter major typo.

I was trying to say that I felt that such a requirement on all SFF would 
be an UNacceptable imposition.

Yours,
Joel

On 7/10/14, 11:53 PM, Joel M. Halpern wrote:
> I ahve no problem if some SFF are flow sensitive, and / or stateful. But
> having the architecture require that every SFF be a full, flow

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 12:30:33 +0000

Disagree. And "requiring" that SFC central system does all of it is "acceptable", let me add, "achievable"?
 As many of us pointed out already "distribution" is the only way to make it work. Med in one his recent e-mail pointed the difficulties in doing it centrally. 

Maria 

> Sent: Friday, July 11, 2014 8:08 AM
> To: Ron Parker; [email-masked]
> list
> list
> list
> list

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 11 Jul 2014 08:37:10 -0400

Med, several of your points are well-taken, and already allowed for in
the proposed architecture.

However, I disagree with a couple of them in important ways.

Path selection is not, from what I have seen, dynamic in nature.  There 
has been expressed repeatedly a requirement that all the packets of a 
given flow go through the same service instances.  Dynamic routing 
simply does not do that.

More importantly, one of the goals of the archtiecture is to separate 
service function concerns from the network service chaining concerns. 
As such, service chaining policy is not the puriew of servie functions. 
  There are various ways that service functions can indicate that a 
given set of packets (usually flow, but maybe subscriber, ...) should 
get tied to a different service chain.  But that is not the same as an 
SF having policy about how the network delivers service chaining or 
where it delivers packets to do that.

And as has been said repeatedly, the archtiecture proposed does not 
require that load balancing be done entirely at the central point.  As 
far as I can tell any solution compliant with the proposed archtiecture 
allows for both centralized control of some traffic distribution, and 
local load balancing within that.  I would expect most deployments would 
use both.

Yours,
Joel

On 7/11/14, 3:49 AM, [email-masked] wrote:
> Hi Joel,
>
> This is one possible approach, but what several of us are trying to
> clarify is this is one approach among others, not possible in some
> contexts, more complex to ensure resiliency, etc.  Below some of my
> concerns about your approach:
>
> (1) Having an entity that maintains a large set of service paths in a
> given domain is more like creating circuits...I thought distributed
> routing has shown its efficiency. (2) Policies are everywhere in the
> network , not only at the SFC structuring system. (3) Path selection
> is dynamic by nature because it depends on various heuristics and
> policies that are distributed in the network (including those of SFs
> and others). (4) Having a stateful function that maintains the full
> list of available paths may not be that resilient. This must assess
> frequently (very short cycle)  valid and serviceable paths among
> available ones. Ensuring the same level of resilience would require
> additional features to be supported by to that entity maintaining the
> full set of path, and also SFs. (5) Load-balancing at a centralized
> entity is deployment-specific; as such it is not required nor
> possible in those contexts. Deciding the forwarding path a priori
> contradicts LB requirements. I know your answer about
> re-classification, but IMHO the architecture should not mandate an
> optional feature only because of some design choices.
> Re-classification should be avoided as much for the same of
> performance and also because this one of the complexity vector for
> this work. (6) There are a bunch of solutions that achieve
> differentiated forwarding without requiring a
> pre-computation/pre-determination of a path: think about ToS-based
> routing, multi-topology routing, etc.
>
> I could live with an optional capability that a path can be
> pre-determined, but this must not be the rule.
>
> Forwarding within an SFC-enabled domain is primarily inferred by the
> service function chain itself. How this information is used to drive
> forwarding actions is all about details.
>
> Cheers, Med
>
>> -----Message d'origine----- De : sfc [mailto:[email-masked]]
>> De la part de Joel M. Halpern Envoyé : vendredi 11 juillet 2014
>> 04:06 À : Ian Smith; Ron Parker; [email-masked]; [email-masked]
>> Part of my personal view is that I am trying to make this work
>> sensibly in a more orchestrated environment.  I expect that the
>> service functions, and over time probably the SFF capabilities,
>> will be orchestrated and installed.  I expect the service chains to
>> be driven by BSS tools that define offerings to clients, and enable
>> self-selection from these.  I expect service paths to be heavily
>> policy drive.
>>
>> I can see how to make all of that work in an archtiecture driven
>> by initial classification to described service paths.  It is harder
>> to see how to make it work (but it can be done) when we allow more
>> dynamicity in the network behavior.
>>
>> Having said that, most of that perspective I described is outside
>> of the scope of the working group.  it is not something we are
>> tasked to agree on. So I do not claim that vision means we have to
>> do it a certain way.  it is just the perspective that drives my
>> preferences.
>>
>> Yours, Joel
>>
>>>> For me, the amount of information about service instances that
>>>> needs to be widely distributed and maintained, potentially even
>>>> across data centers within an administrative scope, is large
>>>> enough and complex enough that trying to get that into each SFF
>>>> seems like a difficult architecture to realize.
>>>
>> hyper-scale data center orchestration, or DNS, all of which are
>> bigger problems that have been profitably and stably implemented?
>>>
>>> It also seems that if it really is more complicated, that is a
>>> good sign
>> that it is too complicated.
>>>
>>> ________________________________________ From: Joel M. Halpern
>>> [[email-masked]] Sent: Thursday, July 10, 2014 9:45 PM To:
>>> Ron Parker; Joel Halpern Direct; [email-masked]; Ian Smith;
>> [email-masked]
>>> This is an architectural issue.  And one that I would prefer we
>>> actually decide, rather than trying to allow all possible
>>> implementations. Because it does have a major effect on the
>>> control requirements and the functionality of SFFs.
>>>
>>> For me, the amount of information about service instances that
>>> needs to be widely distributed and maintained, potentially even
>>> across data centers within an administrative scope, is large
>>> enough and complex enough that trying to get that into each SFF
>>> seems like a difficult architecture to realize.
>>>
>>> Yours, Joel
>>>
>>>> (top-level) instances performed centrally (perhaps by the
>>>> classifier) or hop-by-hop (perhaps by the classifier and
>>>> subsequently the SFFs)? Such selection is not equivalent to
>>>> reclassification.   And surely, this is an architectural issue
>>>> and not relegated to "implementation".
>>>>
>>>> greater amount of data (chain definitions and perhaps local
>>>> selection policy) is required at those distributed decision
>>>> points.   This approach does not require an end-to-end path id
>>>> at all.    My rationale for favoring this approach is primarily
>>>> driven by increased resiliency over the global path id
>>>> approach.   With a global path id approach, consider failure of
>>>> an instance and needing to alter the global path ID table for
>>>> each and every affected end-to-end path.
>>>>
>>>> Ron
>>>>
>>>> [[email-masked]] Sent: Thursday, July 10, 2014 6:15
>>>> PM To: [email-masked]; [email-masked]; [email-masked] Subject:
>>>> Re: [sfc] Service Chains, Paths, and Load Balancers
>>>>
>>>> The way the architecture models the case of SF1 needing to
>>>> influence the chain is that one would do reclassification at
>>>> the exit from SF1.
>>>>
>>>> separate so that solutions can clearly describe how they choose
>>>> to compose them for "service" delivery.
>>>>
>>>> Yours, Joel
>>>>
>>>>> I don't see anything in the arch draft that suggests any sort
>>>>> of limit. However, it does seem to indicate that the entire
>>>>> path (all SFIs) must be chosen at SFC instantiation.  I
>>>>> believe this means either at the classifier or maybe the
>>>>> classifier chooses a SF Chain and the NF or at the latest the
>>>>> first SFF.  In any case, the language does seem to prohibit a
>>>>> more dynamic SFP where SFI(n) is determined at the SFI(n-1)
>>>>> hop.  According to the draft, this behavior would be
>>>>> considered "branching" to a new SFP as opposed to choosing
>>>>> and then forwarding to the selected instance of the next-hop
>>>>> of the current SFC.
>>>>>
>>>>>> When an SFC is instantiated into the network it is
>>>>>> necessary to select the specific instances of SFs that will
>>>>>> be used, and to create the service topology for that SFC
>>>>>> using SF's network locator.  Thus, instantiation of the SFC
>>>>>> results in the creation of a Service Function Path (SFP)
>>>>>> and is used for forwarding packets through the SFC. In
>>>>>> other words, an SFP is the instantiation of the defined
>>>>>> SFC.
>>>>>>
>>>>>> The SFC architecture supports reclassification (or
>>>>>> non-initial classification) as well.  As packets traverse
>>>>>> an SFP, reclassification may occur - typically performed by
>>>>>> a classification function co-resident with a service
>>>>>> function. Reclassification may result in the selection of a
>>>>>> new SFP, an update of the associated metadata, or both.
>>>>>> This is referred to as "branching".
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------------------------
>>
>>>>>
-
>> Halpern<[email-masked]>,[email-masked]<[email-masked]>,s
>>
>>
[email-masked]<[email-masked]>
>>>>> If the possibility of medium-scale deployments (and that is
>>>>> what 16 million flows is in my world) of service chains is
>>>>> preconceived as an absurd idea, then the architecture
>>>>> burdened with that preconception.
>>>>>
>>>>> There has to be some point of aim, some degree of aspiration
>>>>> to scale that is appropriate for the lifespan of the
>>>>> architecture - you don't have to know what it is, but by
>>>>> saying that an arbitrary number is "too far", you're creating
>>>>> - even if it isn't intentional - a limit that influences
>>>>> decisions that have lasting impacts regarding scale-out,
>>>>> failure mitigation, elasticity, address space... all kinds of
>>>>> things. That is a problem I'm not particularly eager to deal
>>>>> with.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M.
>>>>> Halpern; [email-masked]; [email-masked] Subject: Re:
>>>>> Ian, I don't think you disagree with me at all in this
>>>>> regard. I am not requesting the the architecture or the
>>>>> solution prohibit deployments in the specific fashion. I am
>>>>> objecting to Huang's reading of my note as saying that such
>>>>> things. Whether they are a good idea or not depends upon
>>>>> many factors outside of the scope of the WG. I happen to
>>>>> think that they are usually a bad idea.
>>>>>
>>>>> But the archtiecture si carefully avoiding attempting to know
>>>>> what is and is not eployable.
>>>>>
>>>>> Yours, Joel
>>>>>
>>>>> going to have small numbers of service chains with equally
>>>>> small numbers of active service paths?
>>>>>>
>>>>>> Your sounds too much like "no one will ever need more than
>>>>>> 64K" for
>>>>> comfort.
>>>>>>
>>>>>>
>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To:
>>>>>> [email-masked]; [email-masked] Subject: Re: [sfc]
>>>>>> No, it will mean that if someone tries to deploy the
>>>>>> archtieture particularly badly, they will exceed the limits
>>>>>> of their devices. The architecture does not require such
>>>>>> absurd use of service paths. Since I can not figure out how
>>>>>> to write architectural words to prohibit it, the
>>>>>> architecture does permit such abuse.
>>>>>>
>>>>>> something as saying it is either deisred or required by the
>>>>>> work. It isn't.
>>>>>>
>>>>>> Yours, Joel
>>>>>>
>>>>>>> 16,000,000 paths. That is larger than the routing table
>>>>>>> of a core router.
>>>>>>>
>>>>>>> Chang
>>>>>>>
>>>>>>>> service path to 160000 service paths. I would hope
>>>>>>>> that operators are prepared for the complexities if
>>>>>>>> they choose to avoid any use of local load balancing
>>>>>>>> and in stead provision 160,000 service paths.
>>>>>>>>
>>>>>>>> Yours, Joel
>>>>>>>>
>>>>>>>>> How many path identifiers there will be for a 4 hop
>>>>>>>>> service chain with 20 instances at each hop?
>>>>>>>>>
>>>>>>>>> Maria
>>>>>>>>>
>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf
>>>>>>>>> Of *Paul Quinn (paulq) *Sent:* Thursday, July 10,
>>>>>>>>> 2014 3:03 PM *To:* Lucy yong *Cc:*
>>>>>>>>> [email-masked]; [email-masked];
>>>>>>>>> [email-masked]; [email-masked] *Subject:* Re: [sfc]
>>>>>>>>> the minor change: the path identifier can be used to
>>>>>>>>> derive the needed forwarding and associated
>>>>>>>>> transport.
>>>>>>>>>
>>>>>>>>> It is _not_ the transport, but rather is used to
>>>>>>>>> simply identify the service path (or graph) that
>>>>>>>>> packets must traverse. By having a path identifier,
>>>>>>>>> the exact indirection that people seem to be asking
>>>>>>>>> for on this thread can be simply be implemented. The
>>>>>>>>> path identifier provides nothing more than a lookup,
>>>>>>>>> that lookup can result in a one or more (equal or
>>>>>>>>> weighted) transport next hop(s).
>>>>>>>>>
>>>>>>>>> Paul
>>>>>>>>>
>>>>>>>>> Agree. The arch. doc should not mandate only use of
>>>>>>>>> the service path identifier to drive the forwarding
>>>>>>>>> actions.
>>>>>>>>>
>>>>>>>>> Lucy
>>>>>>>>>
>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service
>>>>>>>>> identifier. I object to use that identifier to
>>>>>>>>> be present in all deployments: that is the one
>>>>>>>>> required to structure a service chain. How that
>>>>>>>>> information is used to infer forwarding
>>>>> actions
>>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9
>>>>>>>>> juillet 2014 22:03 *À :[email-masked]
>>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service
>>>>>>>>> Other than clarifying the definition so that it's
>>>>>>>>> clear to
>>>>> those not
>>>>>>>>> To me, the one point that is still unclear is whether
>>>>>>>>> it is the intent of this draft to ultimately specify
>>>>>>>>> what the ID of the SFC Header
>>>>> should
>>>>>>>>> reference (the chain or the path), or if this draft
>>>>>>>>> simply intends to leave that ambiguous, allowing
>>>>>>>>> other drafts to dictate the mechanisms for forwarding
>>>>>>>>> based on chain or path and the choice of chain or
>>>>> path to
>>>>>>>>> require that both SFP and SFC be supported (or make
>>>>>>>>> one required and the other optional) to avoid some
>>>>>>>>> vendors only supporting SFP and others only
>>>>>>>>> supporting SFC.
>>>>>>>>>
>>>>>>>>>
>>>>> -----------------------------------------------------------------------
>>
>>>>>
-
>>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday,
>>>>>>>>> July 8, 2014 *Subject:*[sfc] Service Chains, Paths,
>>>>>>>>> and Load Balancers
>>>>>>>>>
>>>>>>>>> answer a number of comments that have been made about
>>>>>>>>> the proposed merged archtiecture draft. Assuming we
>>>>>>>>> can get working group agreement on the intent, we
>>>>>>>>> will work to improve the wording so that readers who
>>>>>>>>> have not participated in the WG discussion will
>>>>>>>>> understnd it the way the
>>>>> working
>>>>>>>>> group intends.
>>>>>>>>>
>>>>>>>>> personal view, and see if that helps.
>>>>>>>>>
>>>>>>>>> In this regard, it is important to keep in mind that
>>>>>>>>> what we are defining is the data plane architecture.
>>>>>>>>> We are not attempting to define the architecture for
>>>>>>>>> the entire solution for service chaining. That would
>>>>>>>>> encompass OSS/BSS, various control and policy
>>>>>>>>> functions, virtual machine and image management, and
>>>>>>>>> many other aspects.
>>>>>>>>>
>>>>>>>>> As a result there are many things which clearly need
>>>>>>>>> to exist in the larger system, but which are dealt
>>>>>>>>> with above where we are
>>>>> functioning,
>>>>>>>>> In order to get to service chain vs service path, as
>>>>>>>>> I understand
>>>>> them,
>>>>>>>>> I need to first discuss load balancing. There are at
>>>>>>>>> least three different ways that load balancing can
>>>>>>>>> and will interact with service chaining. There
>>>>>>>>> probably are more. The point of the archtiecture is
>>>>>>>>> to permit all of these, but not to mandate that any
>>>>>>>>> particular kind
>>>>> be used
>>>>>>>>> in any solution.
>>>>>>>>>
>>>>>>>>> user. This is a service function. It receives user
>>>>>>>>> packets, and modifies them (or
>>>>> marks
>>>>>>>>> instance to receive the users packet. This is an
>>>>>>>>> important service function to be able to include in
>>>>>>>>> service chaining. It's behavior may affect
>>>>>>>>> requirements on how service chaining is done. But it
>>>>>>>>> has very little impact on the archtiecture. From an
>>>>>>>>> architectural pe3rspective it is simply a
>>>>> service
>>>>>>>>> point of contact
>>>>>>>>> specific service function, but is actually delivered
>>>>>>>>> by a
>>>>> collection of
>>>>>>>>> virtual or physical machines, possibly including one
>>>>>>>>> or several load balancers (for example using
>>>>>>>>> VRRP-like techniques to share a MAC address.) mostly,
>>>>>>>>> this is invisible to the service chaining data plane
>>>>>>>>> various control mechanisms, such as those responsible
>>>>>>>>> for scale-in, scale-out, and vm instantiation. The
>>>>>>>>> architectural impact of permitting this is largely
>>>>>>>>> selecting packet paths for the service chaining that
>>>>>>>>> direct traffic to different places. We would not want
>>>>>>>>> to require that a given service function appear at
>>>>>>>>> only one place in the network.
>>>>>>>>>
>>>>>>>>> chaining as a single point as a cluster. Not because
>>>>>>>>> cluster is a good term. But because I do not have
>>>>>>>>> another one. Thus, the point of type 3 load
>>>>>>>>> balancing
>>>>> is to
>>>>>>>>> service chain and service path/ Service chain is a
>>>>>>>>> sequence of logical functions to be applied to a
>>>>>>>>> subset of packets. It is equivalent of saying that
>>>>>>>>> some subset of traffic is to get DPI, charging,
>>>>>>>>> content inspection, and firewall while a different
>>>>>>>>> subset is to go directly to the cache
>>>>> without
>>>>>>>>> A service path is, in some fashion, a sequence of
>>>>>>>>> locations in the network. Those locations will be
>>>>>>>>> singular or clustered service function delivery
>>>>>>>>> locations. They may be addressed by IP address. They
>>>>>>>>> may be addressed as ports on an SFF. There are many
>>>>>>>>> different ways that the locations may be known to the
>>>>>>>>> service chaining infrastructure and the transport.
>>>>>>>>>
>>>>>>>>> able to talk about the high level abstraction, the
>>>>>>>>> service chain, which drives the forwarding. And we
>>>>>>>>> need to talk about the actual data path packets will
>>>>>>>>> take in the network.
>>>>>>>>>
>>>>>>>>> Several of the comments have said "but the whole path
>>>>>>>>> may not be known at the front." This architecture
>>>>>>>>> deals with that issue in two ways. First, as noted in
>>>>>>>>> item (2) on load balancers above, there can be
>>>>>>>>> service chaining mechanisms (in much the same way
>>>>>>>>> that bridging within a LAN is largely invisible to
>>>>>>>>> routing between LANs.) The other provision we make
>>>>>>>>> is
>>>>> that
>>>>>>>>> necessary. That will direct packets to a new chain.
>>>>>>>>> Based on information available at the
>>>>>>>>> re-classification point.
>>>>>>>>>
>>>>>>>>> I hope that this helps explain what we are after. If
>>>>>>>>> it does, and if the intent is acceptable to the
>>>>>>>>> working group, we can figure out what additional
>>>>>>>>> words are needed to convey this. If the working group
>>>>>>>>> disagree with the intent, then we will of course
>>>>>>>>> adjust to match the working group agreements. If this
>>>>>>>>> is still unclear, I am not sure what to try next.
>>>>>>>>>
>>>>>>>>> Yours, Joel
>>>>>>>>>
>>>>>>>>> _______________________________________________ sfc
>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>>> _______________________________________________ sfc
>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>> _______________________________________________ sfc
>>>>>>>> mailing list [email-masked]
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [email-masked]
>>>>>> list [email-masked]

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 12:40:27 +0000

Joel,

The architecture has to make NO assumptions on the actual configuration/behavior of SFFs (whether none, some, or all of them are stateful, flow-aware co-located with LBs/etc.). This is deployment-specific.

Cheers,
Med

>Envoyé : vendredi 11 juillet 2014 14:08
>À : Ron Parker; [email-masked]
>actually

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 12:41:54 +0000

Absolutely correct.

Maria

> Sent: Friday, July 11, 2014 8:40 AM
> To: Joel M. Halpern; Ron Parker; [email-masked]
> The architecture has to make NO assumptions on the actual
> configuration/behavior of SFFs (whether none, some, or all of them are
> stateful, flow-aware co-located with LBs/etc.). This is deployment-specific.
> 
> Cheers,
> Med
> 
> needs
> mailing
> mailing
> mailing list

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 12:53:03 +0000

Re-,

Please see inline.

Cheers,
Med

>De : Joel Halpern Direct [mailto:[email-masked]]
>Envoyé : vendredi 11 juillet 2014 14:37
>À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Ian Smith; Ron Parker;
>[email-masked]; [email-masked]
>Path selection is not, from what I have seen, dynamic in nature.

[Med] Really?! Given we are talking in this thread about path selection, I will provide an example with it. A load balancing heuristic that dispatch the traffic among several instances that may not be reachable with the same IP address is not more than a dynamic forwarding. When you put all these heuristic that can be invoked in a forwarding path, you have a dynamic path selection. Of course, these heuristics allows to same instance for subsequent flows matching the same criteria. 

  There
>given flow go through the same service instances.  Dynamic routing

[Med] This is why I used in my initial message "dynamic path selection" and not dynamic routing!

>local load balancing within that.  I would expect most deployments would

[Med] It seems we are not reading the same document. I won't repeat what I have mentioned in other messages.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 12:53:55 +0000

> given flow go through the same service instances.  Dynamic routing

And you believe it is possible and scalable to ensure it centrally but not in a distributed manner?
 
> local load balancing within that.  I would expect most deployments would

Well, it was just discussed that the wording in architecture document precludes a hop at SFI(n-1) to determine SFI(n). 
Which means that SFC system determines SFI(n) centrally, which, in turn, means that load balancing is done centrally.

Maria

Maria

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 11 Jul 2014 08:58:30 -0400

And that is exactly what it does Med.  It permits but does not require 
load balancers inside or adjacent to the SFF.

The problem is that the behavior Ron described would require that every 
SFF were a full, stateful, load balancer.  I agree with you that such a 
requirement is unacceptable.

So let me say again:  the curent archtiecture proposal meets the 
requirement you state.  It allows for, but does not require central laod 
balancing.  It allows for, but does not require, local load balancing of 
various kinds at or with the SFF.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:07:54 +0000

Hi Mike,

There still seems to be some confusion around this topic so let me try to provide a more detailed explanation as to how I believe this should work and why what I explained earlier is in fact a path identifier and not a chain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as described within our charter which says “3. Generic SFC encapsulation: This document will describe a single service-level data plane encapsulation format that indicates the sequence of service functions that make up the Service Function Chain; specifies the Service Function Path”. The wording here is very important and shows that the intent is that the sequence of SF’s be indicated within the SFC encapsulation e.g. not carried – this is not source routing, and  specifies the SFP, hence the path identifier.

For my example let’s assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let’s call it “SFC-1”

It is possible that each of those SF’s be directly addressable (i.e. provide SFF functionality) or reachable through some other network device that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 relies on a connected switch to provide the needed SFF functionality. Connected to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3 network locators from which to choose in order to reach the required SF’s; let’s call them SF1-loc1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locators are selected to construct the path, and a path identifier is allocated. In this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2 -> SF3-loc3 and it has a path identifier “100”. This information is distributed to the relevant network devices basically saying “if you receive an SFC encapsulated packet with path identifier “100” then use the path identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there”.

So traffic flows through the SFP with path identifier “100”, via a network transport (the path identifier is encapsulated). It reaches SF1-loc1 which uses the path identifier to determine that it is in fact the SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next service and its reachable at next-hop SF2-loc2. The needed transport (for example VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of the 20 instances of SF2 it should forward the traffic to. It forwards the traffic to the selected instance. SF2 is applied and then another lookup occurs on the path identifier, which results in the needed transport being imposed to reach the next service hop SF3-loc3 .. And so on and so forth.

So with this example we have exactly 1 SFP.

Jim (as a WG participant, not a chair).

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 10, 2014 at 4:46 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Jim,

Sent from my iPhone

Paul,

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.
Lucy
From:sfc [<mailto:[email-masked]>mailto:[email-masked]]On Behalf Of <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 10, 2014 2:06 AM
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
Re-,
The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.
Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.
SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
Cheers,
Med
De :sfc [<mailto:[email-masked]>mailto:[email-masked]]De la part de <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 9 juillet 2014 22:03
À : <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers
Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.
To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.
If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.
________________________________
From:<mailto:[email-masked][email-masked]>[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: <mailto:[email-masked][email-masked]> [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 11 Jul 2014 09:08:13 -0400

There is a VERY large difference both architecturally and in terms of 
solutions and implementations between saying that the SFI does not make 
decisions about next SFI and saying that there is no local load balancing.

Yes, the archteicture states that the service functions themselves do 
not direct the forwarding.  That is a matter of separation of concerns.
It also says that the SFF is responsible for delivery to the SF.  That 
explicitly allows for the SFF to perform laod balancing to its local 
Service Functions, or to be delivering to local load balancers, or 
likely other methods that have not occurred to any of us.

What the architecture prohbits in this regard is having SFF make global 
decisions about how service paths are realized, and in particular how 
load is delivered to instances supported by other SFF.

For example, depending upon the transport and the solution specifics, it 
is consonant with the archtiecture for the SFF to be a distributed 
computation engine so that delivery to it is always a nearby tranfer 
from the previous SFF, and then the SFF does stateful load balancing, 
using shared computation within itself, to deliver packets to the 
correct software image.

That is permitted by the architecture, but not required.

Having SFI make decisions about next SFI means that we have coupled 
network forwarding with the actual service functions.  That complicates 
construction of service functions, and requires them to deliver 
additional functionality.  If a service function developer wants to 
include an SFF in what he delivers, that is permitted by the 
architecture.  We are describing logical components, not the package 
developers or vendors choose to use.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:11:08 +0000

Qin,

Which is precisely what one wants as the multiple SFP’s allow traffic to be distributed through the network so that the same abstracted chain can be served without traffic for that chain taking the exact same path through the network for multiple flows.

From: Qin Wu <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 10, 2014 at 10:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2014年7月11日 4:47
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

Jim,

Sent from my iPhone

Agree. The arch. doc should not mandate only use of the service path identifier to drive the forwarding actions.
Lucy
From:sfc [mailto:[email-masked]]On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, July 10, 2014 2:06 AM
To: [email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers
Re-,
The merged draft calls out explicitly a service path identifier. I object to use that identifier to derive forwarding actions.
Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible in various deployment contexts.
SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service chain. How that information is used to infer forwarding actions is a solution-oriented discussion.
Cheers,
Med
De :sfc [mailto:[email-masked]]De la part de [email-masked]<mailto:[email-masked]>
Envoyé : mercredi 9 juillet 2014 22:03
À : [email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Service Chains, Paths, and Load Balancers
Is anyone still questioning the difference between SF Chain and SF Path? Other than clarifying the definition so that it's clear to those not familiar with the draft, it seems that everyone agrees on these terms.
To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path), or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.
If the latter (ambiguous), then the draft would have require that both SFP and SFC be supported (or make one required and the other optional) to avoid some vendors only supporting SFP and others only supporting SFC.
________________________________
From:[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, July 8, 2014
Subject: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:09:17 +0000

> various kinds at or with the SFF.

We have discussed it yesterday that the language in the current architecture proposal precludes local load balancing. 
And that re-classification is not "it".

Maria
 
> needs to
> selection
> influence
> 64K"

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:21:00 +0000

> decisions about next SFI and saying that there is no local load balancing.

Noticed: I said that a *hop* at SFI(n-1) to determine SFI(n), and not that SFI(n-1)  determines SFI(n),

Agree.

> likely other methods that have not occurred to any of us.

What about if SFIs at hop "n" are attached to different SFFs?

> load is delivered to instances supported by other SFF.

I am not sure what you mean by "how the service paths are realized". 
If you mean SFF at n-1 is load balancing to SFFs at n, it should not be prohibited.

> using shared computation within itself, to deliver packets to the

This sounds like only "local" load balancing which is not sufficient.
> developers or vendors choose to use.

I agree with that.
> > Well, it was just discussed that the wording in architecture document
> precludes a hop at SFI(n-1) to determine SFI(n).
> > Which means that SFC system determines SFI(n) centrally, which, in turn,
> means that load balancing is done centrally.
> >
> > Maria
> >
> >
> >
> > Maria
> >>

---

From: "Zarny, Myo" <[email-masked]>
Date: Fri, 11 Jul 2014 09:24:42 -0400

I'm good with that.

From: Ron Parker [mailto:[email-masked]]
Sent: 10 July 2014 9:40 PM
To: Zarny, Myo [Tech]; [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Myo

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 04:39 PM Eastern Standard Time
To: Zarny, Myo [Tech]; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

________________________________
From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
To: [email-masked]'<[email-masked]<mailto:[email-masked]>>,[email-masked]'<[email-masked]<mailto:[email-masked]>>,[email-masked]'<[email-masked]<mailto:[email-masked]>>
cc: [email-masked]'<[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 10, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Regards,

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

From: Joel M. Halpern [mailto:[email-masked]]
Sent: Thursday, July 10, 2014 03:01 PM Eastern Standard Time
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

On 7/10/14, 2:55 PM, [email-masked]<mailto:[email-masked]> wrote:
> *From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
> *To: *Joel M. Halpern<[email-masked]<mailto:[email-masked]>>
> *cc: *Jim Guichard
> (jguichar)<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>,Ron
> Parker<[email-masked]<mailto:[email-masked]>>,NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>
> we sound't codify how load distribution works.
>
> On Jul 10, 2014, at 12:08 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:27:15 +0000

Well I think it is even worse than that if I have understood the proposal
correctly as it would require full knowledge of every single SF within the
entire SFC domain at every single SFF as there is no way to know a priori
which SFC¹s a given SFF will need to service at any given point in time.

On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>>>>>>>> forwarding. I¹d

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 09:29:12 -0400

The architecture permits (and I would say even encourages) local load 
balancing between an SFF and the actual service functions to which it is 
delivering packets.

The architecture prohibits service functions from adjusting the service 
delivery directly.
And it prohibits an SFF from over-riding the decision of another SFF 
about how to do local load balancing to its local service functions.

That leaves the possibility of having one SFF have some flexibility 
about which next SFF it delivers packets to.  I am trying to see if 
there is a way to thread our way through the combination of constraints 
and still add some of the flexibility you suggest.
We need to allow for a level of meaningful central decision.
We need to allow for SFF which are not full stateful load balancers 
relative to other SFF.
But you would like to allow the flexibility to include those.
And we want an architecture that actually says something.

I can not currently see how to write useful words that meet those 
constraints.
But I will think about it.  If we can allow for this flexibility without 
mandating every SFF to have such capability, then it seems worth allowing.

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:37:36 +0000

> balancing between an SFF and the actual service functions to which it is

Local (i.e., to locally attached SFIs) load balancing is of very limited value. Mostly because, for resiliency, one would want to spread SFIs across different SFFs.

Yes.

> about how to do local load balancing to its local service functions.

OK.

> about which next SFF it delivers packets to.  I am trying to see if

An SFF should have full flexibility to choose next SFF hop.

> We need to allow for SFF which are not full stateful load balancers

As Med pointed out it is implementation decision. 

> > We have discussed it yesterday that the language in the current
> architecture proposal precludes local load balancing.
> >>>>> proposal as I understand it.  (And I readily admit I may not
> understand
> >>>>> it.)
> >>>>>
> But
> sensibly
> bigger
> >>>>>>> To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian
> Smith;
> >>>>>>> [email-masked]
> >>>>>>> Because it does have a major effect on the control requirements
> and
> >> the
> >>>>>>> functionality of SFFs.
> >>>>>>>
> classifier)
> PM
> >>>>>>>>> language does seem to prohibit a more dynamic SFP where
> SFI(n)
> >> is
> many
> >>>>>>>>>> We routinely have stateful devices that manage tens of
> millions
> >>>>>>>>>> of
> [email-masked];
> work.
> *Sent:*Thursday,
> >> July
> >>>>>>>>>>>>> may be known to the service chaining infrastructure and
> the
> >>>>>>>>>>>>> transport.
> >>>>>>>>>>>>>
> may

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:48:33 +0000

Absolutely not. Service chains can be instantiated only in relevant SFFs when they "arrive". 

> Sent: Friday, July 11, 2014 9:27 AM
> >>>>>Halpern<[email-masked]>,[email-masked]<huang@sce.
> carleton.
> >>>>>ca>,[email-masked]<[email-masked]>
> >>>>>
> >>>>>
> >>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:49:27 +0000

Hi Maria,

Question inline ..

On 7/11/14, 9:37 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>Local (i.e., to locally attached SFIs) load balancing is of very limited
>value. Mostly because, for resiliency, one would want to spread SFIs
>across different SFFs.
>
>> 

Jim> are you saying that if there are 100 SFF¹s located somewhere in the
network that provide a given SF then the local SFF must have all 100
next-hops to reach said remote SFF¹s within its forwarding logic so that
it may independently choose which SF it will use for the next required
service of a given flow?

>> >>>>> Ron, thinking about this, I realized another major problem with
>>the
>> >> your
>> >>>>>> orchestrated and installed.  I expect the service chains to be
>>driven
>> by
>>by
>> >>>>>> Having said that, most of that perspective I described is
>>outside of
>> the
>> >>>>>> So I do not claim that vision means we have to do it a certain
>>way.
>> it
>>good
>> >>>>>>> sign that it is too complicated.
>> >>>>>>>
>> >>>>>>>> resiliency over the global path id approach.   With a global
>>path
>> id
>>non-initial
>>what
>>Halpern;
>>regard. I am
>>archtieture
>>derive
>> >>>>>>>>>>>>> Is anyone still questioning the difference between SF
>>Chain
>> >>>>>>>>>>>>> and SF
>> >>>>>>>>> Path?
>>sequence
>> >>>>>>>>>>>>>>    From the point of view of the work of the SFC group,
>>we
>> >>>>>>>>>>>>>> need to be

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 13:54:06 +0000

Then I misunderstand the proposal ;-) .. However, it seems to me that if
you allow an SFF to make a decision as to which remote SFF it will use for
a given flow to reach the next SF within the chain then you better make
sure that that remote SFF has the necessary forwarding logic to reach the
next-next-SF for the chain as otherwise you are in deep trouble.

On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>>driven by
>>>>>>>--------------------------------------------------------------------
>>>>>>>--
>> >>>>>--
>> >>>>>
>> >>>>>
>> >>>>>
>>>>>>>--------------------------------------------------------------------
>>>>>>>--
>> >>>>>--
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 09:55:49 -0400

Hmm.  Would it meet your goals Maria if all packets that arrived at 
SFF-X with SFP-Y were (after local SF processing) forwarded to some 
specific SFF-Z?  Where SFF-Z was selected when the first packet with 
SFP-Y arrived at SFF-X?

While that is more easily met, that does not seem likely to produce the 
scale flexibility you asked for.  And if SFF-X may forward packets with 
SFP-Y to SFF-Z1 and SFF-Z2 then SFF-X has to be stateful and have the 
capability to ensure that a given flow continues to go to the same next 
SFF even when SFF-Z3 is added to the mix.

Yours,
Joel

> Absolutely not. Service chains can be instantiated only in relevant SFFs when they "arrive".
...

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:55:24 +0000

> it may independently choose which SF it will use for the next required

I assume you mean "may independently choose which *SFI* it will use for the next required service of a given flow".
Then yes.  
 
> >> >>>>>>>>> factors outside of the scope of the WG. I happen to think
> that
> >> they
> >> >>>>>>>>> are usually a bad idea.
> >> >>>>>>>>>
> >> >>>>>>>>>>>> operators are prepared for the complexities if they
> choose
> >> to
> one
> >> >>>>>>>>>>>>> wording so that readers who have not participated in
> the
> >> WG
> >> >>>>>>>>>>>>> behavior may affect requirements on how service
> chaining
> >> is
> >> >>>>>>>>>>>>> good term. But because I do not have another one.
> Thus,
> >> the
> >> >>>>>>>>>>>>> addressed by IP address. They may be addressed as
> ports
> >> on
> necessary.
> sfc
> sfc
> sfc

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 13:58:50 +0000

Absolutely. 

> Sent: Friday, July 11, 2014 9:54 AM
> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]
> >> >>>>> behavior would be considered "branching" to a new SFP as
> opposed
> >> to

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 14:07:50 +0000

Joel,

Yes.
> scale flexibility you asked for.  And if SFF-X may forward packets with

Why not?

> SFF even when SFF-Z3 is added to the mix.

Precisely.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 10:17:50 -0400

Just to check, I am going to get pedantic.
We have SFF-X, is supporting (possibly via local load balancing) some 
collection of local service function instances.
When packets on a given service function path (SFP-Y) arrive, they are 
processed by theose service functions, and SFF-X then has to forward the 
packets (with suitable transport) to a next SFF, who may locally balance 
among his service function instances.

For SFF-X handling SFP-Y, the next SFF is (possibly generically) SFF-Z.

We consider first the state at time T0 when a packet arrives as SFF-X on 
SFP-Y with no prior special state in SFF-X (obviously, there is some 
state about SFP-Y, as we do not want policy lookups at packet handling 
times.)  At this time T0, there exist in the network SFF-Z1 and SFF-Z2. 
  If I understand your request, you want SFF-X to pick one of those two 
SFF, say SFF-Z1.  And send all the packets for SFP-Y on to SFF-Z1.  Even 
if SFF-Z3 is added to the network, all packets for all flows using SFP-Y 
at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1.  The only 
time SFF-X would change that is if discovered or was told that SFF-Z1 
was down or unreachable.  In that case, it would pick a new one from 
among the known choices.

Maria, if that is what you would like, I believe that either is 
currently allowed by the architecture or can easily be added.  And I am 
happy to do so.  I believe we can describe that in the resilience and 
failure recovery section that we need to add.

But I want to be really sure that is what you want.  I don't think that 
meets Ron's request.

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 14:18:14 +0000

Ok but where in the architecture specifically is this functionality
prohibited? If you want to distribute *all* next-hops to *all* SFF’s
within the SFC domain and then let the path identifier point to a lookup
into those next-hops to reach the next SF in the chain, I am not sure how
the architecture prevents that?

On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> >Absolutely not. Service chains can be instantiated only in relevant
>>SFFs
>> >when they "arrive".
>> >
>> >> correctly as it would require full knowledge of every single SF
>>within
>> >>the
>> >> >> initial classification to described service paths.  It is harder
>>to
>> >>see
>> >>am

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 14:30:58 +0000

Re-,

For what I can say at best this is not described clearly in the draft. 

Mandating a service path identifier is in itself a hint that the full distributed model is not allowed.

Several voices in this thread indicated that the service chain itself should be provided instead.

Cheers,
Med 

>De : sfc [mailto:[email-masked]] De la part de Jim Guichard
>(jguichar)
>Envoyé : vendredi 11 juillet 2014 16:18
>À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]

---

From: <[email-masked]>
Date: Fri, 11 Jul 2014 14:41:31 +0000

Please see inline.

>À : NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; [email-masked]
>When packets on a given service function path (SFP-Y) arrive,

[Med] s/When packets on a given service function path (SFP-Y) arrive/When packets bound to a given Service Function Chain arrive

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 14:58:56 +0000

Ditto.

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Friday, July 11, 2014 10:31 AM
> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron
> Parker; [email-masked]
> chaining is

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 14:56:50 +0000

> Just to check, I am going to get pedantic.

NP

> among his service function instances.

Similar comment to Med's (I will use his expression as it does reflect it correctly): "if packets bound to a given Service Function Chain arrive", etc.
This applies to the text below also.

> SFF, say SFF-Z1.  

 Yes.

> And send all the packets for SFP-Y on to SFF-Z1.  Even

This could be per-destination load balancing, for example, to get a better load distribution.

> at SFF-X (even new flows) will get sent by SFF-X to SFF-Z1.  The only

Existing flows go to SFF-Z1. New flows may go to SFF-Z3.

Yes.

OK.

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 11 Jul 2014 11:13:22 -0400

In order to allow for SFFs which do not have ability to resolve an SFC 
to the set of next SFFs, we need to do one level of mapping from the 
abstract SFC to the more resolved SFP.
In addition to allowing for a range of SFF deployments, this also allows 
for a degree of centralized traffic control to be used in conjunction 
with the distributed behavior you are requesting.  If we only used an 
identifier of the service chain in the packet we would be prohibiting 
that important alternative deployment.

The SFF still has the ability to map the SFP to the transport 
information, which allows it to have a collection of next SFFs which it 
uses for redundancy or load balancing.

If we structure it this way, we can allow the SFF to have a collection 
of next-SFFs for a given SFP.  And we can allow it to pick one, or to 
balance as it chooses subject to the constraint that a given flow must 
continue to use a given next-SFF as long as that is available.

If we write it that way, the architecture will not mandate full load 
balancing.  It will allow that a given SFF uses a single next-SFF hope. 
  Or that it does whatever degree of load balncing it chooses among the 
set of next-SFF it is aware of for use with a given service path (SFP). 
  Whether that knowledge of next-SFFs is static or dynamic, provisioned 
or discovered, is outside the scope of the architecture, and probably 
outside the scope of any solution this WG develops.

Can you live with this compromise?
(If so, and if the WG is comfortable with this, Carlos and I can add 
this to the slides for presentation in Toronto, and then add text to the 
next version of the document.)

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 15:14:47 +0000

I’m sorry but I really don’t understand why a service path identifier
prevents full distribution of SF next-hops or why calling it a service
chain identifier makes any difference?

On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> Mandating a service path identifier is in itself a hint that the full
>>distributed
>> model is not allowed.
>> 
>> Several voices in this thread indicated that the service chain itself
>>should be
>> provided instead.
>> 
>> Cheers,
>> Med
>> 
>> >>> you allow an SFF to make a decision as to which remote SFF it will
>>use
>> >>>for
>> >>> sure that that remote SFF has the necessary forwarding logic to
>>reach
>> >>>the
>> >>> >> entire SFC domain at every single SFF as there is no way to know
>>a
>> >>> >>priori
>> >>> >> which SFC¹s a given SFF will need to service at any given point
>>in
>> >>>time.
>> >>> >>
>> >>> >> >service function that follows it (not the one it delivers to),
>>in
>> >>>every
>> >>> >> >Since it has to be able to work with all services, that means
>>that
>> >>> >>every
>> >>> >> >> scope of the working group.  it is not something we are
>>tasked to
>> >>> >>agree
>> >>> >> >>on.
>> >>> >> >>>> be widely distributed and maintained, potentially even
>>across
>> >>>data
>> >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently
>>the
>> >>> >>SFFs)?
>> >>> >> >>>> approach, consider failure of an instance and needing to
>>alter
>> >>>the
>> >>> >> >>>>> limit. However, it does seem to indicate that the entire
>>path
>> >>>(all
>> >>> >> >>>>> either at the classifier or maybe the classifier chooses a
>>SF
>> >>> >>Chain
>>necessary
>> >>> >> >>>>>> update of the associated metadata, or both.  This is
>>referred
>> >>>to
>> >>> >> >>>>>> as "branching".
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >>
>> >>>
>> 
>>>>>>>>>>>>---------------------------------------------------------------
>>>>>>>>>>>>---
>> >>>>>>>>>>--
>> >>> >>>>>>>--
>> >>> >> >>>>>--
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>> scale that is appropriate for the lifespan of the
>>architecture
>> >>>-
>>Sent:
>>regard.
>>of a
>> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone agrees
>>on
>> >>> >> >>>>>>>>> these terms.
>> >>> >> >>>>>>>>>
>>it is
>>simply
>>>>>>>>>>>>---------------------------------------------------------------
>>>>>>>>>>>>---
>> >>>>>>>>>>--
>> >>> >>>>>>>--
>> >>> >> >>>>>--
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>>>
>>least
>>user.
>>instance
>> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one can
>>have
>> >>> >> >>>>>>>>> what
>> >>> >> >>>>> appears
>> >>> >> >>>>>>>>> to the service chaining architecture as a single point
>>of
>> >>> >> >>>>>>>>> contact
>> >>> >> >>>>> for a
>> >>> >> >>>>>>>>> invisible to the service chaining data plane
>>mechanisms.
>> It
>>singular

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 15:26:52 +0000

Jim,

Could you tell us what is the definition of a "service path" and a "service path identifier"?
If a service path means that all SF instances are chosen apriori  (which is my current understanding) then it is not SFF's local decision which next-hop SFF to pick.  It is a centralized decision.

Maria

> Sent: Friday, July 11, 2014 11:15 AM
> To: NAPIERALA, MARIA H; [email-masked]; Joel M.
> Halpern; Ron Parker; [email-masked]
> >> >>> >> >>>> My own view is to favor the distributed approach even
> though
> >> a
> Subject:
> >> Re:
> >> >>> >> >>>>> *To: *Joel Halpern
> Direct<[email-masked]>,Joel
> >> M.
> >> >>> >> >>>>>
> >> >>> >>
> >> >>>
> >>
> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you
> are
> >> only
> >> >>> >> going
> >> >>> >> >>>>>> devices. The architecture does not require such absurd
> use
> >> of
> Of
> required
> >> >>> >> >>>>>>>>> required and the other optional) to avoid some
> vendors
> >> only
> *Sent:*Tuesday,
> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to
> improve
> >> the
> >> >>> >> >>>>>>>>> to different places. We would not want to require
> that
> >>a
> A
> provision

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 11:34:54 -0400

I agree that the current text treats the SFP is selecting a specific 
sequence of SFFs.
Note that the selection is still mediated by the configuration in the 
SFFs which act on the service path information in the header.

So what I am suggesting, to address your concern, is that we relax the 
(implicit) requirement that the mapping to the next-SFF be singular.  We 
will describe how it can be multiple sufficiently equivalent next-SFFs. 
  Jim's reading of the document is that such multiplicity was already 
allowed.  By making it explicit, we will avoid any confusion.

This should then allow:
Some traffic distribution management by service path selection
Some traffic distribution management by load balancing between the SFF 
and the actual service functions it is connecting.
And some traffic distribution management by the use of multiple next-SFF 
at some SFF, in a variety of fashions.

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 11:44:14 -0400

When you say "20 instances of the SF2 SF" are "Connected to that SFF" do you mean physically?  I had always just assumed that if I had 20 instances of a SF, that they would be diverse.  Even if within the same datacenter, they would be not near each other.  It also seems like you are saying that there is only a single SFF for SF2 and that your traffic path requires traversing SF2 as a separate hop from the SF2 instance.  Ideally, the traffic would flow from SF1 instance to SF2 instance over the best path without the need for an intermediary hop.

*In my statements above, I assuming that each SF Instance is SFC aware to simplify the text.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>
cc: [email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Mike,

There still seems to be some confusion around this topic so let me try to provide a more detailed explanation as to how I believe this should work and why what I explained earlier is in fact a path identifier and not a chain identifier. Note that my explanation
 assumes that the SFC encapsulation will contain a path identifier as described within our charter which says “3. Generic SFC encapsulation: This document will describe a single service-level data plane encapsulation format that
indicates the sequence of service functions that make up the Service Function Chain;
specifies the Service Function Path”. The wording here is very important and shows that the intent is that the sequence of SF’s be indicated within the SFC encapsulation e.g. not carried – this is
not source routing, and  specifies the SFP, hence the path identifier.

In this example, SF1 and SF3 provide direct SFF functionality and SF2 relies on a connected switch to provide the needed SFF functionality. Connected to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3 network locators from which
 to choose in order to reach the required SF’s; let’s call them SF1-loc1, SF2-loc2, and SF3-loc3. 

When an operator instantiates SFC-1 into the network, specific locators are selected to construct the path, and a path identifier is allocated. In this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2 -> SF3-loc3 and it has a path
 identifier “100”. This information is distributed to the relevant network devices basically saying “if you receive an SFC encapsulated packet with path identifier “100” then use the path identifier and index to perform a lookup in a data structure that will
 tell you which SF to forward the traffic to and how to get there”.

So traffic flows through the SFP with path identifier “100”, via a network transport (the path identifier is encapsulated). It reaches SF1-loc1 which uses the path identifier to determine that it is in fact the SF that should be applied. It applies SF1
 SF and then uses the path identifier to determine that SF2 is the next service and its reachable at next-hop SF2-loc2. The needed transport (for example VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It uses the path identifier to determine
 that SF2 should be applied. It uses a local decision to determine which of the 20 instances of SF2 it should forward the traffic to. It forwards the traffic to the selected instance. SF2 is applied and then another lookup occurs on the path identifier, which
 results in the needed transport being imposed to reach the next service hop SF3-loc3 .. And so on and so forth. 

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

To: Jim Guichard <[email-masked]>, "[email-masked]" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>

Jim, 

But it is the difference between a classifier needing to track the health, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80 instances tracking 20 SFIs of the next-hop for the chains of which they are members vs each SFF in the entire domain
 tracking all 80 SFIs vs something else.

Sent from my iPhone

Paul,

Maria

To: Lucy yong

Cc: [email-masked]; 

Lucy, 

It is _not_ the transport, but rather is used to simply identify the service path (or graph) that packets must traverse. By having a path identifier, the exact indirection that people seem to be asking for on this thread can be simply be
 implemented. The path identifier provides nothing more than a lookup, that lookup can result in a one or more (equal or weighted) transport next hop(s).

Paul

Lucy

From:sfc
 [mailto:[email-masked]]On Behalf Of
[email-masked]

To: [email-masked];[email-masked];[email-masked]

Re-,

Requiring a SFC system to have the full knowledge of every available SFC forwarding paths within an SFC-enabled domain is not required/justified nor possible
 in various deployment contexts.

SFC forwarding actions should rely on the piece of information that will be present in all deployments: that is the one required to structure a service
 chain. How that information is used to infer forwarding actions is a solution-oriented discussion.

Cheers,

Med

De :sfc
 [mailto:[email-masked]]De la part de
[email-masked]

À : [email-masked];[email-masked]

To me, the one point that is still unclear is whether it is the intent of this draft to ultimately specify what the ID of the SFC Header should reference (the chain or the path),
 or if this draft simply intends to leave that ambiguous, allowing other drafts to dictate the mechanisms for forwarding based on chain or path and the choice of chain or path to be negotiated in the control-plane.

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

group intends.

if that helps.

in any solution.

place in the network.

re-classification point.

Yours,

Joel

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 15:54:56 +0000

Maria,

I think of it this way. The service path identifier is simply a pointer to
a data structure that contains SF to next-hop mappings. When you define a
chain, let’s say S1 ->S2-> S3, you *might* when creating the SFP specify
the specific next-hops that you want traffic to flow through for that SFP.
However, you do *not* have to do this from an architectural standpoint (I
will argue that you should but you don’t have to architecturally). You
could simply assign a service path identifier to point to a given SFC and
then push that information into the network. At the SFF it will have a
service path identifier to SFC mapping and said mapping would contain the
next-hops available for each of the SF’s within the SFC - how you learn
those next-hops is up to you. You could push them down from a centralized
controller, configure them through CLI, learn them dynamically through
some protocol exchange, whatever .. So, given this it is not correct to
say that the service path means that all SF instances are chosen a priori
although it is perfectly acceptable (and some would say recommended) to do
so.

Let’s take an example to hopefully make this clear:

I define an SFC (let’s refer to it as SFC-1) S1->S2->S3. For arguments
sake let’s say I want it to be fully dynamic e.g. I don’t want to specify
specific instances of S1, S2, and S3 (or some combination thereof). I
assign a service path identifier “100” that basically points to S1->S2->S3
and then push this into the network so that the SFF data structures are
populated with this information. Now at a given SFF, when traffic arrives
with service path identifier 100, the SFF will look this up in the data
structure and find that it points to S1->S2->S3 and the index in the SFC
encapsulation will tell it exactly where it is in the chain. Let’s say we
are at S2 in the chain. The SFF will now have to resolve the next-hop to
S3 and will do a lookup to determine where S3 is reachable.

On 7/11/14, 11:26 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>If a service path means that all SF instances are chosen apriori  (which
>is my current understanding) then it is not SFF's local decision which
>next-hop SFF to pick.  It is a centralized decision.
>
>Maria
>
>
>> >> >into those next-hops to reach the next SF in the chain, I am not
>>sure
>> >>how
>> >> >>> a given flow to reach the next SF within the chain then you
>>better
>> >>make
>> >> >>> >> From: sfc [mailto:[email-masked]] On Behalf Of Jim
>>Guichard
>> >> >>> >>(jguichar)
>> >> >>> >> Well I think it is even worse than that if I have understood
>>the
>> >> >>> >>proposal
>> >> >>> >> >> functions, and over time probably the SFF capabilities,
>>will
>> >>be
>> >> >>> >> >>>> centers within an administrative scope, is large enough
>>and
>> >> >>> complex
>> >> >>> >> >>> I'm curious as to why that is more complicated than
>>dynamic
>> >> >>> routing,
>> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of
>>which
>> >>are
>> >> >>> >>bigger
>> >> >>> >> >>> It also seems that if it really is more complicated, that
>>is
>> >>a
>> >> >>>good
>> >> >>> >> >>> This is an architectural issue.  And one that I would
>>prefer
>> >>we
>> >> >>> >> >>>actually
>> >> >>> >> >>> centers within an administrative scope, is large enough
>>and
>> >> >>>complex
>> >> >>> >> >>>> This is the crux of my issue.   Is the end to end
>>selection
>> >>of
>> >> >>> >> >>>> Such selection is not equivalent to reclassification.
>>And
>> >> >>>surely,
>> >> >>> >> >>>> rationale for favoring this approach is primarily driven
>>by
>> >> >>> >>increased
>> >> >>> >> >>>> global path ID table for each and every affected
>>end-to-end
>> >> >>>path.
>> >> >>> >> >>>>
>> >> >>> >> >>>> Ron
>> >> >>> >> >>>>
>> >> >>> >> >>>> [[email-masked]] Sent: Thursday, July 10,
>>2014
>> >> 6:15
>> >> >>> PM
>> >> >>> >> >>>> the chain is that one would do reclassification at the
>>exit
>> >>from
>> >> >>> >> >>>> SF1.
>> >> >>> >> >>>>
>> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation.  I believe
>>this
>> >> >>>means
>> >> >>> >> >>>>> to have small numbers of service chains with equally
>>small
>> >> >>> numbers
>> >> >>> >> >>>>> of active service paths?
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths,
>>and
>> >> >>>Load
>> >> >>> >> >>>>>> Balancers
>> >> >>> >> >>>>>>
>> >> >>> >> >>>>>> architectural words to prohibit it, the architecture
>>does
>> >> >>>permit
>> >> >>> >> >>>>>> such abuse.
>> >> >>> >> >>>>>>
>>agrees
>> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other
>>drafts
>> >>to
>>answer
>> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. We
>>are
>> >> not
>>as I
>> >> >>> >> >>>>>>>>> This is a service function. It receives user
>>packets,
>> >>and
>> >> >>> >> >>>>>>>>> modifies them (or
>> >> >>> >> >>>>> marks
>>can
>>point
>>one or
>> >> >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, 
>>and
>> >>vm
>>permitting
>> >>this
>>selecting
>>combined. I
>> >> tend
>> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster 
>>is
>> >>a
>> >> >>> >> >>>>>>>>> or clustered service functions in different places 
>>in
>> >>the
>> >> >>> >> >>>>>>>>> network.
>> >> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of 
>>traffic
>> >>is
>>packets.
>> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) 
>>on
>> >>load
>> >> >>> >> >>>>>>>>> balancers above, there can be decisions and 
>>behaviors
>> >> which
>>If it

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 11:55:08 -0400

> I can not currently see how to write useful words that meet those > constraints.
> But I will think about it. If we can allow for this flexibility without > mandating every SFF to have such capability, then it seems worth allowing.
Could you negotiate this in the control plane?  Make one way required and the other optional.  It could even be negotiated per-chain.  If you install devices that don't support certain features, then you simple can't use those features, but if the devices do, then they can be configured to operate one way or another.

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>,[email-masked]<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

>>>>>>> sign that it is too complicated.
From: Joel M. Halpern [[email-masked]]>>>>>>> Sent: Thursday, July 10, 2014 9:45 PM>>>>>>> To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian Smith;>>>>>>> [email-masked]>>>>>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>>>>>>>> This is an architectural issue.  And one that I would prefer we>>>> actually>>>>>>> decide, rather than trying to allow all possible implementations.>>>>>>> Because it does have a major effect on the control requirements and>> the>>>>>>> functionality of SFFs.>>>>>>>>>>>>>> For me, the amount of information about service instances that>> needs to>>>>>>> be widely distributed and maintained, potentially even across data>>>>>>> centers within an administrative scope, is large enough and complex>>>>>>> enough that trying to get that into each SFF seems like a difficult>>>>>>> architecture to realize.>>>>>>>>>>>>>> Yours,>>>>>>> Joel>>>>>>>>>>>>>> But it is a fair question.>>>>>>>>>>>>>> On 7/10/14, 9:38 PM, Ron Parker wrote:>>>>>>>> This is the crux of my issue.   Is the end to end selection of>>>>>>>> (top-level) instances performed centrally (perhaps by the classifier)>>>>>>>> or hop-by-hop (perhaps by the classifier and subsequently the>> SFFs)?>>>>>>>> Such selection is not equivalent to reclassification.   And surely,>>>>>>>> this is an architectural issue and not relegated to>>>>>>>> "implementation".>>>>>>>>>>>>>>>> My own view is to favor the distributed approach even though a>>>>>>>> greater amount of data (chain definitions and perhaps local>> selection>>>>>>>> policy) is required at those distributed decision points.   This>>>>>>>> approach does not require an end-to-end path id at all.    My>>>>>>>> rationale for favoring this approach is primarily driven by increased>>>>>>>> resiliency over the global path id approach.   With a global path id>>>>>>>> approach, consider failure of an instance and needing to alter the>>>>>>>> global path ID table for each and every affected end-to-end path.>>>>>>>>>>>>>>>> Ron>>>>>>>>>>>>>>>> ________________________________________ From: sfc>>>>>>>> [[email-masked]] on behalf of Joel Halpern Direct>>>>>>>> [[email-masked]] Sent: Thursday, July 10, 2014 6:15 PM>>>>>>>> To: [email-masked]; [email-masked]; [email-masked] Subject: Re:>>>>>>>> [sfc] Service Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>> The way the architecture models the case of SF1 needing to>> influence>>>>>>>> the chain is that one would do reclassification at the exit from>>>>>>>> SF1.>>>>>>>>>>>>>>>> Part of the goal is to keep the different functions logically>>>>>>>> separate so that solutions can clearly describe how they choose to>>>>>>>> compose them for "service" delivery.>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>> On 7/10/14, 6:10 PM, [email-masked] wrote:>>>>>>>>> I don't see anything in the arch draft that suggests any sort of>>>>>>>>> limit. However, it does seem to indicate that the entire path (all>>>>>>>>> SFIs) must be chosen at SFC instantiation.  I believe this means>>>>>>>>> either at the classifier or maybe the classifier chooses a SF Chain>>>>>>>>> and the NF or at the latest the first SFF.  In any case, the>>>>>>>>> language does seem to prohibit a more dynamic SFP where SFI(n)>> is>>>>>>>>> determined at the SFI(n-1) hop.  According to the draft, this>>>>>>>>> behavior would be considered "branching" to a new SFP as>> opposed to>>>>>>>>> choosing and then forwarding to the selected instance of the>>>>>>>>> next-hop of the current SFC.>>>>>>>>>>>>>>>>>> draft-merged-sfc-architecture-00:>>>>>>>>>> When an SFC is instantiated into the network it is necessary to>>>>>>>>>> select the specific instances of SFs that will be used, and to>>>>>>>>>> create the service topology for that SFC using SF's network>>>>>>>>>> locator.  Thus, instantiation of the SFC results in the creation>>>>>>>>>> of a Service Function Path (SFP) and is used for forwarding>>>>>>>>>> packets through the SFC. In other words, an SFP is the>>>>>>>>>> instantiation of the defined SFC.>>>>>>>>>>>>>>>>>>>> The SFC architecture supports reclassification (or non-initial>>>>>>>>>> classification) as well.  As packets traverse an SFP,>>>>>>>>>> reclassification may occur - typically performed by a>>>>>>>>>> classification function co-resident with a service function.>>>>>>>>>> Reclassification may result in the selection of a new SFP, an>>>>>>>>>> update of the associated metadata, or both.  This is referred to>>>>>>>>>> as "branching".>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------------->>>> --->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *From: [email-masked]<[email-masked]>>>>>>>>>> *To: *Joel Halpern Direct<[email-masked]>,Joel M.>>>>>>>>>>>>>>> Halpern<[email-masked]>,[email-masked]<[email-masked]>> on.ca>,s>>>> [email-masked]<[email-masked]>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *Sent: *Thursday, July 10, 2014>>>>>>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>>>> Actually, I think I am disagreeing.>>>>>>>>>>>>>>>>>> If the possibility of medium-scale deployments (and that is what>>>>>>>>> 16 million flows is in my world) of service chains is preconceived>>>>>>>>> as an absurd idea, then the architecture burdened with that>>>>>>>>> preconception.>>>>>>>>>>>>>>>>>> There has to be some point of aim, some degree of aspiration to>>>>>>>>> scale that is appropriate for the lifespan of the architecture ->>>>>>>>> you don't have to know what it is, but by saying that an arbitrary>>>>>>>>> number is "too far", you're creating - even if it isn't intentional>>>>>>>>> - a limit that influences decisions that have lasting impacts>>>>>>>>> regarding scale-out, failure mitigation, elasticity, address>>>>>>>>> space... all kinds of things. That is a problem I'm not>>>>>>>>> particularly eager to deal with.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ________________________________________>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Joel Halpern Direct [[email-masked]] Sent:>>>>>>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;>>>>>>>>> [email-masked]; [email-masked] Subject: Re: [sfc] Service>>>>>>>>> Chains, Paths, and Load Balancers>>>>>>>>>>>>>>>>>> Ian, I don't think you disagree with me at all in this regard. I am>>>>>>>>> not requesting the the architecture or the solution prohibit>>>>>>>>> deployments in the specific fashion. I am objecting to Huang's>>>>>>>>> reading of my note as saying that such deployments are required>>>>>>>>> they by the archtiecture.>>>>>>>>>>>>>>>>>> As I have said repeatedly, I am not trying to prohibit such>>>>>>>>> things. Whether they are a good idea or not depends upon many>>>>>>>>> factors outside of the scope of the WG. I happen to think that they>>>>>>>>> are usually a bad idea.>>>>>>>>>>>>>>>>>> But the archtiecture si carefully avoiding attempting to know what>>>>>>>>> is and is not eployable.>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>>>>>>>>>> I disagree.>>>>>>>>>>>>>>>>>>>> We routinely have stateful devices that manage tens of millions>>>>>>>>>> of>>>>>>>>> concurrent flows in both access network and data center>>>>>>>>> environments today. You can't seriously believe that in the>>>>>>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only>> going>>>>>>>>> to have small numbers of service chains with equally small>> numbers>>>>>>>>> of active service paths?>>>>>>>>>>>>>>>>>>>> Your sounds too much like "no one will ever need more than>> 64K">>>>>>>>>> for>>>>>>>>> comfort.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ________________________________________ From: sfc>>>>>>>>>> [[email-masked]] on behalf of Joel M. Halpern>>>>>>>>> [[email-masked]]>>>>>>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: [email-masked];>>>>>>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths, and Load>>>>>>>>>> Balancers>>>>>>>>>>>>>>>>>>>> No, it will mean that if someone tries to deploy the archtieture>>>>>>>>>> particularly badly, they will exceed the limits of their>>>>>>>>>> devices. The architecture does not require such absurd use of>>>>>>>>>> service paths. Since I can not figure out how to write>>>>>>>>>> architectural words to prohibit it, the architecture does permit>>>>>>>>>> such abuse.>>>>>>>>>>>>>>>>>>>> Please do not read my saying that the archtiecture permits>>>>>>>>>> something as saying it is either deisred or required by the work.>>>>>>>>>> It isn't.>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>>>>>>>>>>> If you need to support 100 service chains, it will mean>>>>>>>>>>> 16,000,000 paths. That is larger than the routing table of a>>>>>>>>>>> core router.>>>>>>>>>>>>>>>>>>>>>> Chang>>>>>>>>>>>>>>>>>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>>>>>>>>>>>> The architecture allows a range of deployments, from 1>>>>>>>>>>>> service path to 160000 service paths. I would hope that>>>>>>>>>>>> operators are prepared for the complexities if they choose to>>>>>>>>>>>> avoid any use of local load balancing and in stead provision>>>>>>>>>>>> 160,000 service paths.>>>>>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>>>>>>>>>>>>> Paul,>>>>>>>>>>>>>>>>>>>>>>>>>> How many path identifiers there will be for a 4 hop service>>>>>>>>>>>>> chain with 20 instances at each hop?>>>>>>>>>>>>>>>>>>>>>>>>>> Maria>>>>>>>>>>>>>>>>>>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of>>>>>>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>>>>>>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked];>>>>>>>>>>>>> [email-masked]; [email-masked];>>>>>>>>>>>>> [email-masked] *Subject:* Re: [sfc] Service Chains,>>>>>>>>>>>>> Paths, and Load Balancers>>>>>>>>>>>>>>>>>>>>>>>>>> Lucy,>>>>>>>>>>>>>>>>>>>>>>>>>> Overall I concur, as you say: a path ID drives the>>>>>>>>>>>>> forwarding. I'd>>>>>>>>> make>>>>>>>>>>>>> the minor change: the path identifier can be used to derive>>>>>>>>>>>>> the needed forwarding and associated transport.>>>>>>>>>>>>>>>>>>>>>>>>>> It is _not_ the transport, but rather is used to simply>>>>>>>>>>>>> identify the service path (or graph) that packets must>>>>>>>>>>>>> traverse. By having a path identifier, the exact>>>>>>>>>>>>> indirection that people seem to be asking for on this>>>>>>>>>>>>> thread can be simply be implemented. The path identifier>>>>>>>>>>>>> provides nothing more than a lookup, that lookup can result>>>>>>>>>>>>> in a one or more (equal or weighted) transport next>>>>>>>>>>>>> hop(s).>>>>>>>>>>>>>>>>>>>>>>>>>> Paul>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>>>>>>>>>>>>>>> wrote:>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Agree. The arch. doc should not mandate only use of the>>>>>>>>>>>>> service path identifier to drive the forwarding actions.>>>>>>>>>>>>>>>>>>>>>>>>>> Lucy>>>>>>>>>>>>>>>>>>>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>>>>>>>>>>>>> [email-masked]>>>>>>>>>>>>> <mailto:[email-masked]> *Sent:*Thursday,>> July>>>>>>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]>>>>>>>>>>>>> <mailto:[email-masked]>;[email-masked]>>>>>>>>>>>>> <mailto:[email-masked]>;[email-masked]>>>>>>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service Chains,>>>>>>>>>>>>> Paths, and Load Balancers>>>>>>>>>>>>>>>>>>>>>>>>>> Re-,>>>>>>>>>>>>>>>>>>>>>>>>>> The merged draft calls out explicitly a service path>>>>>>>>>>>>> identifier. I object to use that identifier to derive>>>>>>>>>>>>> forwarding actions.>>>>>>>>>>>>>>>>>>>>>>>>>> Requiring a SFC system to have the full knowledge of every>>>>>>>>> available SFC>>>>>>>>>>>>> forwarding paths within an SFC-enabled domain is not>>>>>>>>> required/justified>>>>>>>>>>>>> nor possible in various deployment contexts.>>>>>>>>>>>>>>>>>>>>>>>>>> SFC forwarding actions should rely on the piece of>>>>>>>>>>>>> information>>>>>>>>> that will>>>>>>>>>>>>> be present in all deployments: that is the one required to>>>>>>>>>>>>> structure a service chain. How that information is used to>>>>>>>>>>>>> infer forwarding>>>>>>>>> actions>>>>>>>>>>>>> is a solution-oriented discussion.>>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,>>>>>>>>>>>>>>>>>>>>>>>>>> Med>>>>>>>>>>>>>>>>>>>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part>>>>>>>>> [email-masked]>>>>>>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9 juillet>>>>>>>>>>>>> 2014 22:03 *À :[email-masked]>>>>>>>>>>>>> <mailto:[email-masked]>;[email-masked]>>>>>>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service Chains,>>>>>>>>>>>>> Paths, and Load Balancers>>>>>>>>>>>>>>>>>>>>>>>>>> Is anyone still questioning the difference between SF Chain>>>>>>>>>>>>> and SF>>>>>>>>> Path?>>>>>>>>>>>>> Other than clarifying the definition so that it's clear to>>>>>>>>> those not>>>>>>>>>>>>> familiar with the draft, it seems that everyone agrees on>>>>>>>>>>>>> these terms.>>>>>>>>>>>>>>>>>>>>>>>>>> To me, the one point that is still unclear is whether it is>>>>>>>>>>>>> the intent of this draft to ultimately specify what the ID>>>>>>>>>>>>> of the SFC Header>>>>>>>>> should>>>>>>>>>>>>> reference (the chain or the path), or if this draft simply>>>>>>>>>>>>> intends to leave that ambiguous, allowing other drafts to>>>>>>>>>>>>> dictate the mechanisms for forwarding based on chain or>>>>>>>>>>>>> path and the choice of chain or>>>>>>>>> path to>>>>>>>>>>>>> be negotiated in the control-plane.>>>>>>>>>>>>>>>>>>>>>>>>>> If the latter (ambiguous), then the draft would have>>>>>>>>>>>>> require that both SFP and SFC be supported (or make one>>>>>>>>>>>>> required and the other optional) to avoid some vendors only>>>>>>>>>>>>> supporting SFP and others only supporting SFC.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --------------------------------------------------------------------->>>> --->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *From:[email-masked]<[email-masked]>>>>>>>>>>>>> <mailto:[email-masked][email-masked]>>>>>>>>>>>>>>> *To:[email-masked]<[email-masked]>>>>>>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July>>>>>>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load>>>>>>>>>>>>> Balancers>>>>>>>>>>>>>>>>>>>>>>>>>> I have been trying to figure out how to clearly answer a>>>>>>>>>>>>> number of comments that have been made about the>> proposed>>>>>>>>>>>>> merged archtiecture draft. Assuming we can get working>>>>>>>>>>>>> group agreement on the intent, we will work to improve the>>>>>>>>>>>>> wording so that readers who have not participated in the WG>>>>>>>>>>>>> discussion will understnd it the way the>>>>>>>>> working>>>>>>>>>>>>> group intends.>>>>>>>>>>>>>>>>>>>>>>>>>> But what do we intend? I will try to explain my personal>>>>>>>>>>>>> view, and see if that helps.>>>>>>>>>>>>>>>>>>>>>>>>>> In this regard, it is important to keep in mind that what>>>>>>>>>>>>> we are defining is the data plane architecture. We are not>>>>>>>>>>>>> attempting to define the architecture for the entire>>>>>>>>>>>>> solution for service chaining. That would encompass>>>>>>>>>>>>> OSS/BSS, various control and policy functions, virtual>>>>>>>>>>>>> machine and image management, and many other aspects.>>>>>>>>>>>>>>>>>>>>>>>>>> As a result there are many things which clearly need to>>>>>>>>>>>>> exist in the larger system, but which are dealt with above>>>>>>>>>>>>> where we are>>>>>>>>> functioning,>>>>>>>>>>>>> and are not directly required by the work we are doing.>>>>>>>>>>>>>>>>>>>>>>>>>> In order to get to service chain vs service path, as I>>>>>>>>>>>>> understand>>>>>>>>> them,>>>>>>>>>>>>> I need to first discuss load balancing. There are at least>>>>>>>>>>>>> three different ways that load balancing can and will>>>>>>>>>>>>> interact with service chaining. There probably are more.>>>>>>>>>>>>> The point of the archtiecture is to permit all of these,>>>>>>>>>>>>> but not to mandate that any particular kind>>>>>>>>> be used>>>>>>>>>>>>> in any solution.>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Load balancing as a service provided to the end user.>>>>>>>>>>>>> This is a service function. It receives user packets, and>>>>>>>>>>>>> modifies them (or>>>>>>>>> marks>>>>>>>>>>>>> them, or ...) so as to choose an end user service instance>>>>>>>>>>>>> to receive the users packet. This is an important service>>>>>>>>>>>>> function to be able to include in service chaining. It's>>>>>>>>>>>>> behavior may affect requirements on how service chaining is>>>>>>>>>>>>> done. But it has very little impact on the archtiecture.>>>>>>>>>>>>>    From an architectural pe3rspective it is simply a>>>>>>>>> service>>>>>>>>>>>>> function which may modify the underlying packet.>>>>>>>>>>>>>>>>>>>>>>>>>> 2) There is internal load balancing. That is, one can have>>>>>>>>>>>>> what>>>>>>>>> appears>>>>>>>>>>>>> to the service chaining architecture as a single point of>>>>>>>>>>>>> contact>>>>>>>>> for a>>>>>>>>>>>>> specific service function, but is actually delivered by a>>>>>>>>> collection of>>>>>>>>>>>>> virtual or physical machines, possibly including one or>>>>>>>>>>>>> several load balancers (for example using VRRP-like>>>>>>>>>>>>> techniques to share a MAC address.) mostly, this is>>>>>>>>>>>>> invisible to the service chaining data plane mechanisms. It>>>>>>>>>>>>> is likely that it is visible to various control mechanisms,>>>>>>>>>>>>> such as those responsible for scale-in, scale-out, and vm>>>>>>>>>>>>> instantiation. The architectural impact of permitting this>>>>>>>>>>>>> is largely that we need to be careful that our terminology>>>>>>>>>>>>> does not lead>>>>>>>>> readers to>>>>>>>>>>>>> think we are prohibiting it.>>>>>>>>>>>>>>>>>>>>>>>>>> 3) There can also be load balancing done by selecting>>>>>>>>>>>>> packet paths for the service chaining that direct traffic>>>>>>>>>>>>> to different places. We would not want to require that a>>>>>>>>>>>>> given service function appear at only one place in the>>>>>>>>>>>>> network.>>>>>>>>>>>>>>>>>>>>>>>>>> It is of course the case that these may be combined. I tend>>>>>>>>>>>>> to>>>>>>>>> refer to>>>>>>>>>>>>> the collection of entities that appear to service chaining>>>>>>>>>>>>> as a single point as a cluster. Not because cluster is a>>>>>>>>>>>>> good term. But because I do not have another one. Thus, the>>>>>>>>>>>>> point of type 3 load balancing>>>>>>>>> is to>>>>>>>>>>>>> direct different subsets of traffic to different singular>>>>>>>>>>>>> or clustered service functions in different places in the>>>>>>>>>>>>> network.>>>>>>>>>>>>>>>>>>>>>>>>>> Now with that said, what do I mean when I talk about>>>>>>>>>>>>> service chain and service path/ Service chain is a sequence>>>>>>>>>>>>> of logical functions to be applied to a subset of packets.>>>>>>>>>>>>> It is equivalent of saying that some subset of traffic is>>>>>>>>>>>>> to get DPI, charging, content inspection, and firewall>>>>>>>>>>>>> while a different subset is to go directly to the cache>>>>>>>>> without>>>>>>>>>>>>> visiting any other service functions.>>>>>>>>>>>>>>>>>>>>>>>>>> That is not enough information to direct the packets. A>>>>>>>>>>>>> service path is, in some fashion, a sequence of locations>>>>>>>>>>>>> in the network. Those locations will be singular or>>>>>>>>>>>>> clustered service function delivery locations. They may be>>>>>>>>>>>>> addressed by IP address. They may be addressed as ports on>>>>>>>>>>>>> an SFF. There are many different ways that the locations>>>>>>>>>>>>> may be known to the service chaining infrastructure and the>>>>>>>>>>>>> transport.>>>>>>>>>>>>>>>>>>>>>>>>>>>    From the point of view of the work of the SFC group, we>>>>>>>>>>>>>> need to be>>>>>>>>>>>>> able to talk about the high level abstraction, the service>>>>>>>>>>>>> chain, which drives the forwarding. And we need to talk>>>>>>>>>>>>> about the actual data path packets will take in the>>>>>>>>>>>>> network.>>>>>>>>>>>>>>>>>>>>>>>>>> Several of the comments have said "but the whole path may>>>>>>>>>>>>> not be known at the front." This architecture deals with>>>>>>>>>>>>> that issue in two ways. First, as noted in item (2) on load>>>>>>>>>>>>> balancers above, there can be decisions and behaviors which>>>>>>>>>>>>> are invisible to the service chaining mechanisms (in much>>>>>>>>>>>>> the same way that bridging within a LAN is largely>>>>>>>>>>>>> invisible to routing between LANs.) The other provision we>>>>>>>>>>>>> make is>>>>>>>>> that>>>>>>>>>>>>> reclassification can be done in mid-chain when necessary.>>>>>>>>>>>>> That will direct packets to a new chain. Based on>>>>>>>>>>>>> information available at the re-classification point.>>>>>>>>>>>>>>>>>>>>>>>>>> I hope that this helps explain what we are after. If it>>>>>>>>>>>>> does, and if the intent is acceptable to the working group,>>>>>>>>>>>>> we can figure out what additional words are needed to>>>>>>>>>>>>> convey this. If the working group disagree with the intent,>>>>>>>>>>>>> then we will of course adjust to match the working group>>>>>>>>>>>>> agreements. If this is still unclear, I am not sure what to>>>>>>>>>>>>> try next.>>>>>>>>>>>>>>>>>>>>>>>>>> Yours, Joel>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ sfc>> mailing>>>>>>>>>>>>> list [email-masked] <mailto:[email-masked]>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ sfc>> mailing>>>>>>>>>>>>> list [email-masked] <mailto:[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>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ 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>>>>>>>>>>>>>>>> _______________________________________________ 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>>>>>>>>>>>>> _______________________________________________>>>> 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 [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 15:57:26 +0000

No they do not have to be physically connected but they are hidden behind an SFF in this case but do not have to be.

Date: Friday, July 11, 2014 at 11:44 AM

________________________________
From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
cc: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi Mike,

Jim,

Sent from my iPhone

Paul,

From:sfc [<mailto:[email-masked]>mailto:[email-masked]]On Behalf Of<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
De :sfc [<mailto:[email-masked]>mailto:[email-masked]]De la part de<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

Yours,
Joel

---

From: Sharon <[email-masked]>
Date: Fri, 11 Jul 2014 09:00:20 -0700

We can reference other standard ID-Location mapping mechanisms (local or distributed) for matching SF-SFF. These can be leveraged by SFFs for load distribution and dynamic failure recovery not based on centralized orchestration.

--szb

> On Jul 11, 2014, at 8:34, "Joel M. Halpern" <[email-masked]> wrote:
> 
> I agree that the current text treats the SFP is selecting a specific sequence of SFFs.
> Note that the selection is still mediated by the configuration in the SFFs which act on the service path information in the header.
> 
> So what I am suggesting, to address your concern, is that we relax the (implicit) requirement that the mapping to the next-SFF be singular.  We will describe how it can be multiple sufficiently equivalent next-SFFs.  Jim's reading of the document is that such multiplicity was already allowed.  By making it explicit, we will avoid any confusion.
> 
> This should then allow:
> Some traffic distribution management by load balancing between the SFF and the actual service functions it is connecting.
> And some traffic distribution management by the use of multiple next-SFF at some SFF, in a variety of fashions.
> 
> Yours,
> Joel
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:02:57 -0400

heh.  well, if it did not, then you should not do it like that.  e.g. I'm not going to configure real servers on a server load balancer that are not reachable.  e.g. I'm not going to configure my BGP to announce prefixes for which I cannot provide connectivity.  If you do things like that, then you are doing it wrong.

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>,Joel M. Halpern<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

>> -----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard>>(jguichar)>> Sent: Friday, July 11, 2014 9:27 AM>> To: Joel M. Halpern; Ron Parker; [email-masked]>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >> Well I think it is even worse than that if I have understood the>>proposal>> correctly as it would require full knowledge of every single SF within>>the>> entire SFC domain at every single SFF as there is no way to know a>>priori>> which SFC¹s a given SFF will need to service at any given point in time.>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]> wrote:>> >> >Ron, thinking about this, I realized another major problem with the>>your>> >proposal as I understand it.  (And I readily admit I may not understand>> >it.)>> >>> >The proposal has each SFF serve as the load balancer for the next>> >service function that follows it (not the one it delivers to), in every>> >service chain that goes through it.>> >>> >Since it has to be able to work with all services, that means that>>every>> >SFF would have to be a full, flow sensitive and stateful load balancer.>> >I ahve no problem if some SFF are flow sensitive, and / or stateful.>> >But having the architecture require that every SFF be a full, flow>> >sensitive, stateful, load balancer seems to me to be an acceptable>> >imposition.>> >>> >Yours,>> >Joel>> >>> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>> >> Part of my personal view is that I am trying to make this work>>sensibly>> >> in a more orchestrated environment.  I expect that the service>> >> functions, and over time probably the SFF capabilities, will be>> >> orchestrated and installed.  I expect the service chains to be>>driven by>> >> BSS tools that define offerings to clients, and enable self-selection>> >> from these.  I expect service paths to be heavily policy drive.>> >>>> >> I can see how to make all of that work in an archtiecture driven by>> >> initial classification to described service paths.  It is harder to>>see>> >> how to make it work (but it can be done) when we allow more>> dynamicity>> >> in the network behavior.>> >>>> >> Having said that, most of that perspective I described is outside of>>the>> >> scope of the working group.  it is not something we are tasked to>>agree>> >>on.>> >> So I do not claim that vision means we have to do it a certain way.>>it>> >> is just the perspective that drives my preferences.>> >>>> >> Yours,>> >> Joel>> >>>> >> On 7/10/14, 9:58 PM, Ian Smith wrote:>> >>>> For me, the amount of information about service instances that>>needs>> >>>>to>> >>>> be widely distributed and maintained, potentially even across data>> >>>> centers within an administrative scope, is large enough and complex>> >>>> enough that trying to get that into each SFF seems like a difficult>> >>>> architecture to realize.>> >>>>> >>> I'm curious as to why that is more complicated than dynamic routing,>> >>> hyper-scale data center orchestration, or DNS, all of which are>>bigger>> >>> problems that have been profitably and stably implemented?>> >>>>> >>> It also seems that if it really is more complicated, that is a good>> >>> sign that it is too complicated.>> >>>>> >>> ________________________________________>> >>> From: Joel M. Halpern [[email-masked]]>> >>> Sent: Thursday, July 10, 2014 9:45 PM>> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian Smith;>> >>> [email-masked]>> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >>>>> >>> This is an architectural issue.  And one that I would prefer we>> >>>actually>> >>> decide, rather than trying to allow all possible implementations.>> >>> Because it does have a major effect on the control requirements and>> the>> >>> functionality of SFFs.>> >>>>> >>> For me, the amount of information about service instances that needs>> to>> >>> be widely distributed and maintained, potentially even across data>> >>> centers within an administrative scope, is large enough and complex>> >>> enough that trying to get that into each SFF seems like a difficult>> >>> architecture to realize.>> >>>>> >>> Yours,>> >>> Joel>> >>>>> >>> But it is a fair question.>> >>>>> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>> >>>> This is the crux of my issue.   Is the end to end selection of>> >>>> (top-level) instances performed centrally (perhaps by the>>classifier)>> >>>> or hop-by-hop (perhaps by the classifier and subsequently the>>SFFs)?>> >>>> Such selection is not equivalent to reclassification.   And surely,>> >>>> this is an architectural issue and not relegated to>> >>>> "implementation".>> >>>>>> >>>> My own view is to favor the distributed approach even though a>> >>>> greater amount of data (chain definitions and perhaps local>>selection>> >>>> policy) is required at those distributed decision points.   This>> >>>> approach does not require an end-to-end path id at all.    My>> >>>> rationale for favoring this approach is primarily driven by>>increased>> >>>> resiliency over the global path id approach.   With a global path>>id>> >>>> approach, consider failure of an instance and needing to alter the>> >>>> global path ID table for each and every affected end-to-end path.>> >>>>>> >>>> Ron>> >>>>>> >>>> ________________________________________ From: sfc>> >>>> [[email-masked]] on behalf of Joel Halpern Direct>> >>>> [[email-masked]] Sent: Thursday, July 10, 2014 6:15 PM>> >>>> To: [email-masked]; [email-masked]; [email-masked] Subject: Re:>> >>>> [sfc] Service Chains, Paths, and Load Balancers>> >>>>>> >>>> The way the architecture models the case of SF1 needing to>>influence>> >>>> the chain is that one would do reclassification at the exit from>> >>>> SF1.>> >>>>>> >>>> Part of the goal is to keep the different functions logically>> >>>> separate so that solutions can clearly describe how they choose to>> >>>> compose them for "service" delivery.>> >>>>>> >>>> Yours, Joel>> >>>>>> >>>> On 7/10/14, 6:10 PM, [email-masked] wrote:>> >>>>> I don't see anything in the arch draft that suggests any sort of>> >>>>> limit. However, it does seem to indicate that the entire path (all>> >>>>> SFIs) must be chosen at SFC instantiation.  I believe this means>> >>>>> either at the classifier or maybe the classifier chooses a SF>>Chain>> >>>>> and the NF or at the latest the first SFF.  In any case, the>> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is>> >>>>> determined at the SFI(n-1) hop.  According to the draft, this>> >>>>> behavior would be considered "branching" to a new SFP as opposed>> to>> >>>>> choosing and then forwarding to the selected instance of the>> >>>>> next-hop of the current SFC.>> >>>>>>> >>>>> draft-merged-sfc-architecture-00:>> >>>>>> When an SFC is instantiated into the network it is necessary to>> >>>>>> select the specific instances of SFs that will be used, and to>> >>>>>> create the service topology for that SFC using SF's network>> >>>>>> locator.  Thus, instantiation of the SFC results in the creation>> >>>>>> of a Service Function Path (SFP) and is used for forwarding>> >>>>>> packets through the SFC. In other words, an SFP is the>> >>>>>> instantiation of the defined SFC.>> >>>>>>>> >>>>>> The SFC architecture supports reclassification (or non-initial>> >>>>>> classification) as well.  As packets traverse an SFP,>> >>>>>> reclassification may occur - typically performed by a>> >>>>>> classification function co-resident with a service function.>> >>>>>> Reclassification may result in the selection of a new SFP, an>> >>>>>> update of the associated metadata, or both.  This is referred to>> >>>>>> as "branching".>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>-------------------------------------------------------------------->>>>>>>-->> >>>>>-->> >>>>>>> >>>>>>> >>>>>>> >>> *From: [email-masked]<[email-masked]>>> >>>>> *To: *Joel Halpern Direct<[email-masked]>,Joel M.>> >>>>>>> >>>>>Halpern<[email-masked]>,[email-masked]<huang@sce.>> carleton.>> >>>>>ca>,[email-masked]<[email-masked]>>> >>>>>>> >>>>>>> >>>>>>> >>> *Sent: *Thursday, July 10, 2014>> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>> >>>>>>> >>>>> Actually, I think I am disagreeing.>> >>>>>>> >>>>> If the possibility of medium-scale deployments (and that is what>> >>>>> 16 million flows is in my world) of service chains is preconceived>> >>>>> as an absurd idea, then the architecture burdened with that>> >>>>> preconception.>> >>>>>>> >>>>> There has to be some point of aim, some degree of aspiration to>> >>>>> scale that is appropriate for the lifespan of the architecture ->> >>>>> you don't have to know what it is, but by saying that an arbitrary>> >>>>> number is "too far", you're creating - even if it isn't>>intentional>> >>>>> - a limit that influences decisions that have lasting impacts>> >>>>> regarding scale-out, failure mitigation, elasticity, address>> >>>>> space... all kinds of things. That is a problem I'm not>> >>>>> particularly eager to deal with.>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> ________________________________________>> >>>>>>> >>>>>>> >>>>> From: Joel Halpern Direct [[email-masked]] Sent:>> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;>> >>>>> [email-masked]; [email-masked] Subject: Re: [sfc] Service>> >>>>> Chains, Paths, and Load Balancers>> >>>>>>> >>>>> Ian, I don't think you disagree with me at all in this regard. I>>am>> >>>>> not requesting the the architecture or the solution prohibit>> >>>>> deployments in the specific fashion. I am objecting to Huang's>> >>>>> reading of my note as saying that such deployments are required>> >>>>> they by the archtiecture.>> >>>>>>> >>>>> As I have said repeatedly, I am not trying to prohibit such>> >>>>> things. Whether they are a good idea or not depends upon many>> >>>>> factors outside of the scope of the WG. I happen to think that>>they>> >>>>> are usually a bad idea.>> >>>>>>> >>>>> But the archtiecture si carefully avoiding attempting to know what>> >>>>> is and is not eployable.>> >>>>>>> >>>>> Yours, Joel>> >>>>>>> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>> >>>>>> I disagree.>> >>>>>>>> >>>>>> We routinely have stateful devices that manage tens of millions>> >>>>>> of>> >>>>> concurrent flows in both access network and data center>> >>>>> environments today. You can't seriously believe that in the>> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only>> going>> >>>>> to have small numbers of service chains with equally small numbers>> >>>>> of active service paths?>> >>>>>>>> >>>>>> Your sounds too much like "no one will ever need more than 64K">> >>>>>> for>> >>>>> comfort.>> >>>>>>>> >>>>>>>> >>>>>> ________________________________________ From: sfc>> >>>>>> [[email-masked]] on behalf of Joel M. Halpern>> >>>>> [[email-masked]]>> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: [email-masked];>> >>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths, and Load>> >>>>>> Balancers>> >>>>>>>> >>>>>> No, it will mean that if someone tries to deploy the archtieture>> >>>>>> particularly badly, they will exceed the limits of their>> >>>>>> devices. The architecture does not require such absurd use of>> >>>>>> service paths. Since I can not figure out how to write>> >>>>>> architectural words to prohibit it, the architecture does permit>> >>>>>> such abuse.>> >>>>>>>> >>>>>> Please do not read my saying that the archtiecture permits>> >>>>>> something as saying it is either deisred or required by the work.>> >>>>>> It isn't.>> >>>>>>>> >>>>>> Yours, Joel>> >>>>>>>> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>> >>>>>>> If you need to support 100 service chains, it will mean>> >>>>>>> 16,000,000 paths. That is larger than the routing table of a>> >>>>>>> core router.>> >>>>>>>>> >>>>>>> Chang>> >>>>>>>>> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>> >>>>>>>> The architecture allows a range of deployments, from 1>> >>>>>>>> service path to 160000 service paths. I would hope that>> >>>>>>>> operators are prepared for the complexities if they choose to>> >>>>>>>> avoid any use of local load balancing and in stead provision>> >>>>>>>> 160,000 service paths.>> >>>>>>>>>> >>>>>>>> Yours, Joel>> >>>>>>>>>> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>> >>>>>>>>> Paul,>> >>>>>>>>>>> >>>>>>>>> How many path identifiers there will be for a 4 hop service>> >>>>>>>>> chain with 20 instances at each hop?>> >>>>>>>>>>> >>>>>>>>> Maria>> >>>>>>>>>>> >>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of>> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked];>> >>>>>>>>> [email-masked]; [email-masked];>> >>>>>>>>> [email-masked] *Subject:* Re: [sfc] Service Chains,>> >>>>>>>>> Paths, and Load Balancers>> >>>>>>>>>>> >>>>>>>>> Lucy,>> >>>>>>>>>>> >>>>>>>>> Overall I concur, as you say: a path ID drives the>> >>>>>>>>> forwarding. I¹d>> >>>>> make>> >>>>>>>>> the minor change: the path identifier can be used to derive>> >>>>>>>>> the needed forwarding and associated transport.>> >>>>>>>>>>> >>>>>>>>> It is _not_ the transport, but rather is used to simply>> >>>>>>>>> identify the service path (or graph) that packets must>> >>>>>>>>> traverse. By having a path identifier, the exact>> >>>>>>>>> indirection that people seem to be asking for on this>> >>>>>>>>> thread can be simply be implemented. The path identifier>> >>>>>>>>> provides nothing more than a lookup, that lookup can result>> >>>>>>>>> in a one or more (equal or weighted) transport next>> >>>>>>>>> hop(s).>> >>>>>>>>>>> >>>>>>>>> Paul>> >>>>>>>>>>> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>> >>>>>>>>> <[email-masked] <mailto:[email-masked]>>>> >>>>>>>>> wrote:>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> Agree. The arch. doc should not mandate only use of the>> >>>>>>>>> service path identifier to drive the forwarding actions.>> >>>>>>>>>>> >>>>>>>>> Lucy>> >>>>>>>>>>> >>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>> >>>>>>>>> [email-masked]>> >>>>>>>>> <mailto:[email-masked]> *Sent:*Thursday,>> July>> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]>> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service Chains,>> >>>>>>>>> Paths, and Load Balancers>> >>>>>>>>>>> >>>>>>>>> Re-,>> >>>>>>>>>>> >>>>>>>>> The merged draft calls out explicitly a service path>> >>>>>>>>> identifier. I object to use that identifier to derive>> >>>>>>>>> forwarding actions.>> >>>>>>>>>>> >>>>>>>>> Requiring a SFC system to have the full knowledge of every>> >>>>> available SFC>> >>>>>>>>> forwarding paths within an SFC-enabled domain is not>> >>>>> required/justified>> >>>>>>>>> nor possible in various deployment contexts.>> >>>>>>>>>>> >>>>>>>>> SFC forwarding actions should rely on the piece of>> >>>>>>>>> information>> >>>>> that will>> >>>>>>>>> be present in all deployments: that is the one required to>> >>>>>>>>> structure a service chain. How that information is used to>> >>>>>>>>> infer forwarding>> >>>>> actions>> >>>>>>>>> is a solution-oriented discussion.>> >>>>>>>>>>> >>>>>>>>> Cheers,>> >>>>>>>>>>> >>>>>>>>> Med>> >>>>>>>>>>> >>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part>> >>>>> [email-masked]>> >>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9 juillet>> >>>>>>>>> 2014 22:03 *À :[email-masked]>> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service Chains,>> >>>>>>>>> Paths, and Load Balancers>> >>>>>>>>>>> >>>>>>>>> Is anyone still questioning the difference between SF Chain>> >>>>>>>>> and SF>> >>>>> Path?>> >>>>>>>>> Other than clarifying the definition so that it's clear to>> >>>>> those not>> >>>>>>>>> familiar with the draft, it seems that everyone agrees on>> >>>>>>>>> these terms.>> >>>>>>>>>>> >>>>>>>>> To me, the one point that is still unclear is whether it is>> >>>>>>>>> the intent of this draft to ultimately specify what the ID>> >>>>>>>>> of the SFC Header>> >>>>> should>> >>>>>>>>> reference (the chain or the path), or if this draft simply>> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to>> >>>>>>>>> dictate the mechanisms for forwarding based on chain or>> >>>>>>>>> path and the choice of chain or>> >>>>> path to>> >>>>>>>>> be negotiated in the control-plane.>> >>>>>>>>>>> >>>>>>>>> If the latter (ambiguous), then the draft would have>> >>>>>>>>> require that both SFP and SFC be supported (or make one>> >>>>>>>>> required and the other optional) to avoid some vendors only>> >>>>>>>>> supporting SFP and others only supporting SFC.>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>-------------------------------------------------------------------->>>>>>>-->> >>>>>-->> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> *From:[email-masked]<[email-masked]>> >>>>>>>>> <mailto:[email-masked][email-masked]>>>> >>>>>>>>> *To:[email-masked]<[email-masked]>> >>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July>> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load>> >>>>>>>>> Balancers>> >>>>>>>>>>> >>>>>>>>> I have been trying to figure out how to clearly answer a>> >>>>>>>>> number of comments that have been made about the proposed>> >>>>>>>>> merged archtiecture draft. Assuming we can get working>> >>>>>>>>> group agreement on the intent, we will work to improve the>> >>>>>>>>> wording so that readers who have not participated in the WG>> >>>>>>>>> discussion will understnd it the way the>> >>>>> working>> >>>>>>>>> group intends.>> >>>>>>>>>>> >>>>>>>>> But what do we intend? I will try to explain my personal>> >>>>>>>>> view, and see if that helps.>> >>>>>>>>>>> >>>>>>>>> In this regard, it is important to keep in mind that what>> >>>>>>>>> we are defining is the data plane architecture. We are not>> >>>>>>>>> attempting to define the architecture for the entire>> >>>>>>>>> solution for service chaining. That would encompass>> >>>>>>>>> OSS/BSS, various control and policy functions, virtual>> >>>>>>>>> machine and image management, and many other aspects.>> >>>>>>>>>>> >>>>>>>>> As a result there are many things which clearly need to>> >>>>>>>>> exist in the larger system, but which are dealt with above>> >>>>>>>>> where we are>> >>>>> functioning,>> >>>>>>>>> and are not directly required by the work we are doing.>> >>>>>>>>>>> >>>>>>>>> In order to get to service chain vs service path, as I>> >>>>>>>>> understand>> >>>>> them,>> >>>>>>>>> I need to first discuss load balancing. There are at least>> >>>>>>>>> three different ways that load balancing can and will>> >>>>>>>>> interact with service chaining. There probably are more.>> >>>>>>>>> The point of the archtiecture is to permit all of these,>> >>>>>>>>> but not to mandate that any particular kind>> >>>>> be used>> >>>>>>>>> in any solution.>> >>>>>>>>>>> >>>>>>>>> 1) Load balancing as a service provided to the end user.>> >>>>>>>>> This is a service function. It receives user packets, and>> >>>>>>>>> modifies them (or>> >>>>> marks>> >>>>>>>>> them, or ...) so as to choose an end user service instance>> >>>>>>>>> to receive the users packet. This is an important service>> >>>>>>>>> function to be able to include in service chaining. It's>> >>>>>>>>> behavior may affect requirements on how service chaining is>> >>>>>>>>> done. But it has very little impact on the archtiecture.>> >>>>>>>>>  From an architectural pe3rspective it is simply a>> >>>>> service>> >>>>>>>>> function which may modify the underlying packet.>> >>>>>>>>>>> >>>>>>>>> 2) There is internal load balancing. That is, one can have>> >>>>>>>>> what>> >>>>> appears>> >>>>>>>>> to the service chaining architecture as a single point of>> >>>>>>>>> contact>> >>>>> for a>> >>>>>>>>> specific service function, but is actually delivered by a>> >>>>> collection of>> >>>>>>>>> virtual or physical machines, possibly including one or>> >>>>>>>>> several load balancers (for example using VRRP-like>> >>>>>>>>> techniques to share a MAC address.) mostly, this is>> >>>>>>>>> invisible to the service chaining data plane mechanisms. It>> >>>>>>>>> is likely that it is visible to various control mechanisms,>> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm>> >>>>>>>>> instantiation. The architectural impact of permitting this>> >>>>>>>>> is largely that we need to be careful that our terminology>> >>>>>>>>> does not lead>> >>>>> readers to>> >>>>>>>>> think we are prohibiting it.>> >>>>>>>>>>> >>>>>>>>> 3) There can also be load balancing done by selecting>> >>>>>>>>> packet paths for the service chaining that direct traffic>> >>>>>>>>> to different places. We would not want to require that a>> >>>>>>>>> given service function appear at only one place in the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> It is of course the case that these may be combined. I tend>> >>>>>>>>> to>> >>>>> refer to>> >>>>>>>>> the collection of entities that appear to service chaining>> >>>>>>>>> as a single point as a cluster. Not because cluster is a>> >>>>>>>>> good term. But because I do not have another one. Thus, the>> >>>>>>>>> point of type 3 load balancing>> >>>>> is to>> >>>>>>>>> direct different subsets of traffic to different singular>> >>>>>>>>> or clustered service functions in different places in the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> Now with that said, what do I mean when I talk about>> >>>>>>>>> service chain and service path/ Service chain is a sequence>> >>>>>>>>> of logical functions to be applied to a subset of packets.>> >>>>>>>>> It is equivalent of saying that some subset of traffic is>> >>>>>>>>> to get DPI, charging, content inspection, and firewall>> >>>>>>>>> while a different subset is to go directly to the cache>> >>>>> without>> >>>>>>>>> visiting any other service functions.>> >>>>>>>>>>> >>>>>>>>> That is not enough information to direct the packets. A>> >>>>>>>>> service path is, in some fashion, a sequence of locations>> >>>>>>>>> in the network. Those locations will be singular or>> >>>>>>>>> clustered service function delivery locations. They may be>> >>>>>>>>> addressed by IP address. They may be addressed as ports on>> >>>>>>>>> an SFF. There are many different ways that the locations>> >>>>>>>>> may be known to the service chaining infrastructure and the>> >>>>>>>>> transport.>> >>>>>>>>>>> >>>>>>>>>>  From the point of view of the work of the SFC group, we>> >>>>>>>>>> need to be>> >>>>>>>>> able to talk about the high level abstraction, the service>> >>>>>>>>> chain, which drives the forwarding. And we need to talk>> >>>>>>>>> about the actual data path packets will take in the>> >>>>>>>>> network.>> >>>>>>>>>>> >>>>>>>>> Several of the comments have said "but the whole path may>> >>>>>>>>> not be known at the front." This architecture deals with>> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load>> >>>>>>>>> balancers above, there can be decisions and behaviors which>> >>>>>>>>> are invisible to the service chaining mechanisms (in much>> >>>>>>>>> the same way that bridging within a LAN is largely>> >>>>>>>>> invisible to routing between LANs.) The other provision we>> >>>>>>>>> make is>> >>>>> that>> >>>>>>>>> reclassification can be done in mid-chain when necessary.>> >>>>>>>>> That will direct packets to a new chain. Based on>> >>>>>>>>> information available at the re-classification point.>> >>>>>>>>>>> >>>>>>>>> I hope that this helps explain what we are after. If it>> >>>>>>>>> does, and if the intent is acceptable to the working group,>> >>>>>>>>> we can figure out what additional words are needed to>> >>>>>>>>> convey this. If the working group disagree with the intent,>> >>>>>>>>> then we will of course adjust to match the working group>> >>>>>>>>> agreements. If this is still unclear, I am not sure what to>> >>>>>>>>> try next.>> >>>>>>>>>>> >>>>>>>>> Yours, Joel>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ sfc>> mailing>> >>>>>>>>> list [email-masked] <mailto:[email-masked]>>> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ sfc>> mailing>> >>>>>>>>> list [email-masked] <mailto:[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>> >>>>>>>>> >>>>>>>> >>>>>> _______________________________________________ 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>> >>>>>> >>>> _______________________________________________ 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>> >> _______________________________________________>> sfc mailing list>> [email-masked]>> https://www.ietf.org/mailman/listinfo/sfc_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:02:16 +0000

Joel,

I saw your latest e-mail but I am responding to this one because it is more comprehensive.

I have a hard time understanding why an SFF will not have ability to resolve an SFC to the set of next SFFs. Then what kind of "forwarder" is it if it cannot deal with next-hops.
Second, if we do it as you suggest, what is the definition of a service path and why it is even needed? For me a service path is more of an abstract concept that is meant to denote one actual path (among many) that a service chain traffic will take.

Maria

> Sent: Friday, July 11, 2014 11:13 AM
> To: NAPIERALA, MARIA H; Joel M. Halpern; Jim Guichard (jguichar); Ron
> Parker; [email-masked]
> > Similar comment to Med's (I will use his expression as it does reflect it
> correctly): "if packets bound to a given Service Function Chain arrive", etc.

---

From: "Zarny, Myo" <[email-masked]>
Date: Fri, 11 Jul 2014 12:09:16 -0400

I don’t understand. (I’m sure I’m misunderstanding…)

Your backend servers could go down, be unreachable or be unable to server more.

Route health injection (RHI) is a perfectly fine, accepted, way of indicating the health of the backend services to the network. You’re not saying that’s wrong, are you?

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 11 July 2014 12:03 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>

>> -----Original Message-----

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard
>> To: Joel M. Halpern; Ron Parker; [email-masked]<mailto:[email-masked]>
>> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]<mailto:[email-masked]>; Ian Smith;
>> >>>> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re:
>> >>>> On 7/10/14, 6:10 PM, [email-masked]<mailto:[email-masked]> wrote:
>> >>> *From: [email-masked]<[email-masked]<mailto:[email-masked][email-masked]>>
>> >>>>> *To: *Joel Halpern Direct<[email-masked]<mailto:[email-masked]>>,Joel M.
>> >>>>>
>> >>>>>Halpern<[email-masked]<mailto:[email-masked]>>,[email-masked]<huang@sce.
<mailto:huang@sce.%0b>>> carleton.
>> >>>>>ca>,[email-masked]<[email-masked]<mailto:[email-masked]>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> Subject: Re: [sfc] Service
>> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: [email-masked]<mailto:[email-masked]>;
>> >>>>>> [email-masked]<mailto:[email-masked]> Subject: Re: [sfc] Service Chains, Paths, and Load
>> >>>>>> Balancers
>> >>>>>>
>> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked]<mailto:[email-masked]>;
>> >>>>>>>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>> >>>>>>>>> [email-masked]<mailto:[email-masked]> *Subject:* Re: [sfc] Service Chains,
>> >>>>>>>>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> [email-masked]<mailto:[email-masked]>
>> >>>>> [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]%0b>>> >>>>>>>>> <mailto:[email-masked][email-masked]>>
>> >>>>>>>>> *To:[email-masked]<[email-masked]
<mailto:[email-masked]%0b>>> >>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July
>> >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>>> list [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> >>>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>>>>
>> >>>>>>
>> >>>>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>>>
>> >>>>>
>> >>>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>
>> >>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>
>> >>>> [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>> >>>>
>> >>>
>> >>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:09:23 -0400

The arch should not prevent this, but "(even new flows)" is hardly ideal.  I can make the case for "(only existing flows)" (stateful) and for "SFF-Z1 is eligible for all flows, even existing ones" (stateless).

I don't see anything currently in the arch draft that would prohibit any of these.

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>,Jim Guichard (jguichar)<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:09:37 +0000

Agree Mike; I think my wider point was that in order to satisfy this type of distribution you will need to keep a lot of state at every SFF in the SFC domain so as to avoid situations where traffic is forwarded from one SFF to another that does not have the required state.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 at 12:02 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>

>> >>> From: Joel M. Halpern [[email-masked]<mailto:[email-masked]>]
>> >>>> [[email-masked]<mailto:[email-masked]>] on behalf of Joel Halpern Direct
>> >>>> [[email-masked]<mailto:[email-masked]>] Sent: Thursday, July 10, 2014 6:15 PM
>> >>> *From: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
>> >>>>>Halpern<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><huang@sce.
>> carleton.
>> >>>>>ca>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From: Joel Halpern Direct [[email-masked]<mailto:[email-masked]>] Sent:
>> >>>>>> [[email-masked]<mailto:[email-masked]>] on behalf of Joel M. Halpern
>> >>>>> [[email-masked]<mailto:[email-masked]>]
>> >>>>>>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]<mailto:[email-masked]>
>> >>>>>>>>> 2014 22:03 *À :[email-masked]<mailto:[email-masked]>
>> >>>>>>>>> *From:[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>
>> >>>>>>>>> *To:[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:11:48 -0400

Yes, the draft seems to indicate that if you want this distributed behavior, you need to re-classify onto a new SFP.  If that is not the intent of the draft, then it is unclear.

From: [email-masked]<[email-masked]>
To: Jim Guichard (jguichar)<[email-masked]>,NAPIERALA, MARIA H<[email-masked]>,Joel M. Halpern<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Re-,

Cheers,
Med 

>>Ok but where in the architecture specifically is this functionality>prohibited? If you want to distribute *all* next-hops to *all* SFF’s>within the SFC domain and then let the path identifier point to a lookup>into those next-hops to reach the next SF in the chain, I am not sure how>the architecture prevents that?>>On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:>>>Absolutely.>>>>> -----Original Message----->>> From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard>>>(jguichar)>>> Sent: Friday, July 11, 2014 9:54 AM>>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]>>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>>>>> Then I misunderstand the proposal ;-) .. However, it seems to me that if>>> you allow an SFF to make a decision as to which remote SFF it will use>>>for>>> a given flow to reach the next SF within the chain then you better make>>> sure that that remote SFF has the necessary forwarding logic to reach>>>the>>> next-next-SF for the chain as otherwise you are in deep trouble.>>>>>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:>>>>>> >Absolutely not. Service chains can be instantiated only in relevant>>>SFFs>>> >when they "arrive".>>> >>>> >> -----Original Message----->>> >> From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard>>> >>(jguichar)>>> >> Sent: Friday, July 11, 2014 9:27 AM>>> >> To: Joel M. Halpern; Ron Parker; [email-masked]>>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>> >>>>> >> Well I think it is even worse than that if I have understood the>>> >>proposal>>> >> correctly as it would require full knowledge of every single SF>>>within>>> >>the>>> >> entire SFC domain at every single SFF as there is no way to know a>>> >>priori>>> >> which SFC¹s a given SFF will need to service at any given point in>>>time.>>> >>>>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]> wrote:>>> >>>>> >> >Ron, thinking about this, I realized another major problem with the>>> >>your>>> >> >proposal as I understand it.  (And I readily admit I may not>>>understand>>> >> >it.)>>> >> >>>> >> >The proposal has each SFF serve as the load balancer for the next>>> >> >service function that follows it (not the one it delivers to), in>>>every>>> >> >service chain that goes through it.>>> >> >>>> >> >Since it has to be able to work with all services, that means that>>> >>every>>> >> >SFF would have to be a full, flow sensitive and stateful load>>>balancer.>>> >> >I ahve no problem if some SFF are flow sensitive, and / or stateful.>>> >> >But having the architecture require that every SFF be a full, flow>>> >> >sensitive, stateful, load balancer seems to me to be an acceptable>>> >> >imposition.>>> >> >>>> >> >Yours,>>> >> >Joel>>> >> >>>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>>> >> >> Part of my personal view is that I am trying to make this work>>> >>sensibly>>> >> >> in a more orchestrated environment.  I expect that the service>>> >> >> functions, and over time probably the SFF capabilities, will be>>> >> >> orchestrated and installed.  I expect the service chains to be>>> >>driven by>>> >> >> BSS tools that define offerings to clients, and enable>>>self-selection>>> >> >> from these.  I expect service paths to be heavily policy drive.>>> >> >>>>> >> >> I can see how to make all of that work in an archtiecture driven>>>by>>> >> >> initial classification to described service paths.  It is harder>>>to>>> >>see>>> >> >> how to make it work (but it can be done) when we allow more>>> >> dynamicity>>> >> >> in the network behavior.>>> >> >>>>> >> >> Having said that, most of that perspective I described is outside>>>of>>> >>the>>> >> >> scope of the working group.  it is not something we are tasked to>>> >>agree>>> >> >>on.>>> >> >> So I do not claim that vision means we have to do it a certain>>>way.>>> >>it>>> >> >> is just the perspective that drives my preferences.>>> >> >>>>> >> >> Yours,>>> >> >> Joel>>> >> >>>>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote:>>> >> >>>> For me, the amount of information about service instances that>>> >>needs>>> >> >>>>to>>> >> >>>> be widely distributed and maintained, potentially even across>>>data>>> >> >>>> centers within an administrative scope, is large enough and>>> complex>>> >> >>>> enough that trying to get that into each SFF seems like a>>>difficult>>> >> >>>> architecture to realize.>>> >> >>>>>> >> >>> I'm curious as to why that is more complicated than dynamic>>> routing,>>> >> >>> hyper-scale data center orchestration, or DNS, all of which are>>> >>bigger>>> >> >>> problems that have been profitably and stably implemented?>>> >> >>>>>> >> >>> It also seems that if it really is more complicated, that is a>>>good>>> >> >>> sign that it is too complicated.>>> >> >>>>>> >> >>> ________________________________________>>> >> >>> From: Joel M. Halpern [[email-masked]]>>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM>>> >> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian>>>Smith;>>> >> >>> [email-masked]>>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>>> >> >>>>>> >> >>> This is an architectural issue.  And one that I would prefer we>>> >> >>>actually>>> >> >>> decide, rather than trying to allow all possible implementations.>>> >> >>> Because it does have a major effect on the control requirements>>>and>>> >> the>>> >> >>> functionality of SFFs.>>> >> >>>>>> >> >>> For me, the amount of information about service instances that>>> needs>>> >> to>>> >> >>> be widely distributed and maintained, potentially even across>>>data>>> >> >>> centers within an administrative scope, is large enough and>>>complex>>> >> >>> enough that trying to get that into each SFF seems like a>>>difficult>>> >> >>> architecture to realize.>>> >> >>>>>> >> >>> Yours,>>> >> >>> Joel>>> >> >>>>>> >> >>> But it is a fair question.>>> >> >>>>>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>>> >> >>>> This is the crux of my issue.   Is the end to end selection of>>> >> >>>> (top-level) instances performed centrally (perhaps by the>>> >>classifier)>>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the>>> >>SFFs)?>>> >> >>>> Such selection is not equivalent to reclassification.   And>>>surely,>>> >> >>>> this is an architectural issue and not relegated to>>> >> >>>> "implementation".>>> >> >>>>>>> >> >>>> My own view is to favor the distributed approach even though a>>> >> >>>> greater amount of data (chain definitions and perhaps local>>> >>selection>>> >> >>>> policy) is required at those distributed decision points.   This>>> >> >>>> approach does not require an end-to-end path id at all.    My>>> >> >>>> rationale for favoring this approach is primarily driven by>>> >>increased>>> >> >>>> resiliency over the global path id approach.   With a global>>>path>>> >>id>>> >> >>>> approach, consider failure of an instance and needing to alter>>>the>>> >> >>>> global path ID table for each and every affected end-to-end>>>path.>>> >> >>>>>>> >> >>>> Ron>>> >> >>>>>>> >> >>>> ________________________________________ From: sfc>>> >> >>>> [[email-masked]] on behalf of Joel Halpern Direct>>> >> >>>> [[email-masked]] Sent: Thursday, July 10, 2014 6:15>>> PM>>> >> >>>> To: [email-masked]; [email-masked]; [email-masked] Subject: Re:>>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers>>> >> >>>>>>> >> >>>> The way the architecture models the case of SF1 needing to>>> >>influence>>> >> >>>> the chain is that one would do reclassification at the exit from>>> >> >>>> SF1.>>> >> >>>>>>> >> >>>> Part of the goal is to keep the different functions logically>>> >> >>>> separate so that solutions can clearly describe how they choose>>>to>>> >> >>>> compose them for "service" delivery.>>> >> >>>>>>> >> >>>> Yours, Joel>>> >> >>>>>>> >> >>>> On 7/10/14, 6:10 PM, [email-masked] wrote:>>> >> >>>>> I don't see anything in the arch draft that suggests any sort>>>of>>> >> >>>>> limit. However, it does seem to indicate that the entire path>>>(all>>> >> >>>>> SFIs) must be chosen at SFC instantiation.  I believe this>>>means>>> >> >>>>> either at the classifier or maybe the classifier chooses a SF>>> >>Chain>>> >> >>>>> and the NF or at the latest the first SFF.  In any case, the>>> >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n)>>> is>>> >> >>>>> determined at the SFI(n-1) hop.  According to the draft, this>>> >> >>>>> behavior would be considered "branching" to a new SFP as>>> opposed>>> >> to>>> >> >>>>> choosing and then forwarding to the selected instance of the>>> >> >>>>> next-hop of the current SFC.>>> >> >>>>>>>> >> >>>>> draft-merged-sfc-architecture-00:>>> >> >>>>>> When an SFC is instantiated into the network it is necessary>>>to>>> >> >>>>>> select the specific instances of SFs that will be used, and to>>> >> >>>>>> create the service topology for that SFC using SF's network>>> >> >>>>>> locator.  Thus, instantiation of the SFC results in the>>>creation>>> >> >>>>>> of a Service Function Path (SFP) and is used for forwarding>>> >> >>>>>> packets through the SFC. In other words, an SFP is the>>> >> >>>>>> instantiation of the defined SFC.>>> >> >>>>>>>>> >> >>>>>> The SFC architecture supports reclassification (or non-initial>>> >> >>>>>> classification) as well.  As packets traverse an SFP,>>> >> >>>>>> reclassification may occur - typically performed by a>>> >> >>>>>> classification function co-resident with a service function.>>> >> >>>>>> Reclassification may result in the selection of a new SFP, an>>> >> >>>>>> update of the associated metadata, or both.  This is referred>>>to>>> >> >>>>>> as "branching".>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>>>>>>>>>>>>>>------------------------------------------------------------------>>>>>>>>>>-->>> >>>>>>>-->>> >> >>>>>-->>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>> *From: [email-masked]<[email-masked]>>>> >> >>>>> *To: *Joel Halpern Direct<[email-masked]>,Joel M.>>> >> >>>>>>>> >>>>> >>>>>Halpern<[email-masked]>,[email-masked]<huang@sce.>>> >> carleton.>>> >> >>>>>ca>,[email-masked]<[email-masked]>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>> *Sent: *Thursday, July 10, 2014>>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>>> >> >>>>>>>> >> >>>>> Actually, I think I am disagreeing.>>> >> >>>>>>>> >> >>>>> If the possibility of medium-scale deployments (and that is>>>what>>> >> >>>>> 16 million flows is in my world) of service chains is>>>preconceived>>> >> >>>>> as an absurd idea, then the architecture burdened with that>>> >> >>>>> preconception.>>> >> >>>>>>>> >> >>>>> There has to be some point of aim, some degree of aspiration to>>> >> >>>>> scale that is appropriate for the lifespan of the architecture>>>->>> >> >>>>> you don't have to know what it is, but by saying that an>>>arbitrary>>> >> >>>>> number is "too far", you're creating - even if it isn't>>> >>intentional>>> >> >>>>> - a limit that influences decisions that have lasting impacts>>> >> >>>>> regarding scale-out, failure mitigation, elasticity, address>>> >> >>>>> space... all kinds of things. That is a problem I'm not>>> >> >>>>> particularly eager to deal with.>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> ________________________________________>>> >> >>>>>>>> >> >>>>>>>> >> >>>>> From: Joel Halpern Direct [[email-masked]] Sent:>>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;>>> >> >>>>> [email-masked]; [email-masked] Subject: Re: [sfc] Service>>> >> >>>>> Chains, Paths, and Load Balancers>>> >> >>>>>>>> >> >>>>> Ian, I don't think you disagree with me at all in this regard.>>>I>>> >>am>>> >> >>>>> not requesting the the architecture or the solution prohibit>>> >> >>>>> deployments in the specific fashion. I am objecting to Huang's>>> >> >>>>> reading of my note as saying that such deployments are required>>> >> >>>>> they by the archtiecture.>>> >> >>>>>>>> >> >>>>> As I have said repeatedly, I am not trying to prohibit such>>> >> >>>>> things. Whether they are a good idea or not depends upon many>>> >> >>>>> factors outside of the scope of the WG. I happen to think that>>> >>they>>> >> >>>>> are usually a bad idea.>>> >> >>>>>>>> >> >>>>> But the archtiecture si carefully avoiding attempting to know>>>what>>> >> >>>>> is and is not eployable.>>> >> >>>>>>>> >> >>>>> Yours, Joel>>> >> >>>>>>>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>>> >> >>>>>> I disagree.>>> >> >>>>>>>>> >> >>>>>> We routinely have stateful devices that manage tens of>>>millions>>> >> >>>>>> of>>> >> >>>>> concurrent flows in both access network and data center>>> >> >>>>> environments today. You can't seriously believe that in the>>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only>>> >> going>>> >> >>>>> to have small numbers of service chains with equally small>>> numbers>>> >> >>>>> of active service paths?>>> >> >>>>>>>>> >> >>>>>> Your sounds too much like "no one will ever need more than>>> 64K">>> >> >>>>>> for>>> >> >>>>> comfort.>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>> ________________________________________ From: sfc>>> >> >>>>>> [[email-masked]] on behalf of Joel M. Halpern>>> >> >>>>> [[email-masked]]>>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To:>>>[email-masked];>>> >> >>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths, and>>>Load>>> >> >>>>>> Balancers>>> >> >>>>>>>>> >> >>>>>> No, it will mean that if someone tries to deploy the>>>archtieture>>> >> >>>>>> particularly badly, they will exceed the limits of their>>> >> >>>>>> devices. The architecture does not require such absurd use of>>> >> >>>>>> service paths. Since I can not figure out how to write>>> >> >>>>>> architectural words to prohibit it, the architecture does>>>permit>>> >> >>>>>> such abuse.>>> >> >>>>>>>>> >> >>>>>> Please do not read my saying that the archtiecture permits>>> >> >>>>>> something as saying it is either deisred or required by the>>>work.>>> >> >>>>>> It isn't.>>> >> >>>>>>>>> >> >>>>>> Yours, Joel>>> >> >>>>>>>>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>>> >> >>>>>>> If you need to support 100 service chains, it will mean>>> >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a>>> >> >>>>>>> core router.>>> >> >>>>>>>>>> >> >>>>>>> Chang>>> >> >>>>>>>>>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>>> >> >>>>>>>> The architecture allows a range of deployments, from 1>>> >> >>>>>>>> service path to 160000 service paths. I would hope that>>> >> >>>>>>>> operators are prepared for the complexities if they choose>>>to>>> >> >>>>>>>> avoid any use of local load balancing and in stead provision>>> >> >>>>>>>> 160,000 service paths.>>> >> >>>>>>>>>>> >> >>>>>>>> Yours, Joel>>> >> >>>>>>>>>>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>>> >> >>>>>>>>> Paul,>>> >> >>>>>>>>>>>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop service>>> >> >>>>>>>>> chain with 20 instances at each hop?>>> >> >>>>>>>>>>>> >> >>>>>>>>> Maria>>> >> >>>>>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of>>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked];>>> >> >>>>>>>>> [email-masked]; [email-masked];>>> >> >>>>>>>>> [email-masked] *Subject:* Re: [sfc] Service Chains,>>> >> >>>>>>>>> Paths, and Load Balancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> Lucy,>>> >> >>>>>>>>>>>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the>>> >> >>>>>>>>> forwarding. I¹d>>> >> >>>>> make>>> >> >>>>>>>>> the minor change: the path identifier can be used to derive>>> >> >>>>>>>>> the needed forwarding and associated transport.>>> >> >>>>>>>>>>>> >> >>>>>>>>> It is _not_ the transport, but rather is used to simply>>> >> >>>>>>>>> identify the service path (or graph) that packets must>>> >> >>>>>>>>> traverse. By having a path identifier, the exact>>> >> >>>>>>>>> indirection that people seem to be asking for on this>>> >> >>>>>>>>> thread can be simply be implemented. The path identifier>>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can result>>> >> >>>>>>>>> in a one or more (equal or weighted) transport next>>> >> >>>>>>>>> hop(s).>>> >> >>>>>>>>>>>> >> >>>>>>>>> Paul>>> >> >>>>>>>>>>>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>>> >> >>>>>>>>> <[email-masked] <mailto:[email-masked]>>>>> >> >>>>>>>>> wrote:>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the>>> >> >>>>>>>>> service path identifier to drive the forwarding actions.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Lucy>>> >> >>>>>>>>>>>> >> >>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>>> >> >>>>>>>>> [email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]>>>> *Sent:*Thursday,>>> >> July>>> >> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service Chains,>>> >> >>>>>>>>> Paths, and Load Balancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> Re-,>>> >> >>>>>>>>>>>> >> >>>>>>>>> The merged draft calls out explicitly a service path>>> >> >>>>>>>>> identifier. I object to use that identifier to derive>>> >> >>>>>>>>> forwarding actions.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every>>> >> >>>>> available SFC>>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not>>> >> >>>>> required/justified>>> >> >>>>>>>>> nor possible in various deployment contexts.>>> >> >>>>>>>>>>>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of>>> >> >>>>>>>>> information>>> >> >>>>> that will>>> >> >>>>>>>>> be present in all deployments: that is the one required to>>> >> >>>>>>>>> structure a service chain. How that information is used to>>> >> >>>>>>>>> infer forwarding>>> >> >>>>> actions>>> >> >>>>>>>>> is a solution-oriented discussion.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Cheers,>>> >> >>>>>>>>>>>> >> >>>>>>>>> Med>>> >> >>>>>>>>>>>> >> >>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part>>> >> >>>>> [email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9 juillet>>> >> >>>>>>>>> 2014 22:03 *À :[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service Chains,>>> >> >>>>>>>>> Paths, and Load Balancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> Is anyone still questioning the difference between SF Chain>>> >> >>>>>>>>> and SF>>> >> >>>>> Path?>>> >> >>>>>>>>> Other than clarifying the definition so that it's clear to>>> >> >>>>> those not>>> >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on>>> >> >>>>>>>>> these terms.>>> >> >>>>>>>>>>>> >> >>>>>>>>> To me, the one point that is still unclear is whether it is>>> >> >>>>>>>>> the intent of this draft to ultimately specify what the ID>>> >> >>>>>>>>> of the SFC Header>>> >> >>>>> should>>> >> >>>>>>>>> reference (the chain or the path), or if this draft simply>>> >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to>>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or>>> >> >>>>>>>>> path and the choice of chain or>>> >> >>>>> path to>>> >> >>>>>>>>> be negotiated in the control-plane.>>> >> >>>>>>>>>>>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have>>> >> >>>>>>>>> require that both SFP and SFC be supported (or make one>>> >> >>>>>>>>> required and the other optional) to avoid some vendors only>>> >> >>>>>>>>> supporting SFP and others only supporting SFC.>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>> >>>>>>>>>>>>>>>------------------------------------------------------------------>>>>>>>>>>-->>> >>>>>>>-->>> >> >>>>>-->>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> *From:[email-masked]<[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked][email-masked]>>>>> >> >>>>>>>>> *To:[email-masked]<[email-masked]>>> >> >>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July>>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load>>> >> >>>>>>>>> Balancers>>> >> >>>>>>>>>>>> >> >>>>>>>>> I have been trying to figure out how to clearly answer a>>> >> >>>>>>>>> number of comments that have been made about the>>> proposed>>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get working>>> >> >>>>>>>>> group agreement on the intent, we will work to improve the>>> >> >>>>>>>>> wording so that readers who have not participated in the WG>>> >> >>>>>>>>> discussion will understnd it the way the>>> >> >>>>> working>>> >> >>>>>>>>> group intends.>>> >> >>>>>>>>>>>> >> >>>>>>>>> But what do we intend? I will try to explain my personal>>> >> >>>>>>>>> view, and see if that helps.>>> >> >>>>>>>>>>>> >> >>>>>>>>> In this regard, it is important to keep in mind that what>>> >> >>>>>>>>> we are defining is the data plane architecture. We are not>>> >> >>>>>>>>> attempting to define the architecture for the entire>>> >> >>>>>>>>> solution for service chaining. That would encompass>>> >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual>>> >> >>>>>>>>> machine and image management, and many other aspects.>>> >> >>>>>>>>>>>> >> >>>>>>>>> As a result there are many things which clearly need to>>> >> >>>>>>>>> exist in the larger system, but which are dealt with above>>> >> >>>>>>>>> where we are>>> >> >>>>> functioning,>>> >> >>>>>>>>> and are not directly required by the work we are doing.>>> >> >>>>>>>>>>>> >> >>>>>>>>> In order to get to service chain vs service path, as I>>> >> >>>>>>>>> understand>>> >> >>>>> them,>>> >> >>>>>>>>> I need to first discuss load balancing. There are at least>>> >> >>>>>>>>> three different ways that load balancing can and will>>> >> >>>>>>>>> interact with service chaining. There probably are more.>>> >> >>>>>>>>> The point of the archtiecture is to permit all of these,>>> >> >>>>>>>>> but not to mandate that any particular kind>>> >> >>>>> be used>>> >> >>>>>>>>> in any solution.>>> >> >>>>>>>>>>>> >> >>>>>>>>> 1) Load balancing as a service provided to the end user.>>> >> >>>>>>>>> This is a service function. It receives user packets, and>>> >> >>>>>>>>> modifies them (or>>> >> >>>>> marks>>> >> >>>>>>>>> them, or ...) so as to choose an end user service instance>>> >> >>>>>>>>> to receive the users packet. This is an important service>>> >> >>>>>>>>> function to be able to include in service chaining. It's>>> >> >>>>>>>>> behavior may affect requirements on how service chaining is>>> >> >>>>>>>>> done. But it has very little impact on the archtiecture.>>> >> >>>>>>>>>  From an architectural pe3rspective it is simply a>>> >> >>>>> service>>> >> >>>>>>>>> function which may modify the underlying packet.>>> >> >>>>>>>>>>>> >> >>>>>>>>> 2) There is internal load balancing. That is, one can have>>> >> >>>>>>>>> what>>> >> >>>>> appears>>> >> >>>>>>>>> to the service chaining architecture as a single point of>>> >> >>>>>>>>> contact>>> >> >>>>> for a>>> >> >>>>>>>>> specific service function, but is actually delivered by a>>> >> >>>>> collection of>>> >> >>>>>>>>> virtual or physical machines, possibly including one or>>> >> >>>>>>>>> several load balancers (for example using VRRP-like>>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is>>> >> >>>>>>>>> invisible to the service chaining data plane mechanisms. It>>> >> >>>>>>>>> is likely that it is visible to various control mechanisms,>>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm>>> >> >>>>>>>>> instantiation. The architectural impact of permitting this>>> >> >>>>>>>>> is largely that we need to be careful that our terminology>>> >> >>>>>>>>> does not lead>>> >> >>>>> readers to>>> >> >>>>>>>>> think we are prohibiting it.>>> >> >>>>>>>>>>>> >> >>>>>>>>> 3) There can also be load balancing done by selecting>>> >> >>>>>>>>> packet paths for the service chaining that direct traffic>>> >> >>>>>>>>> to different places. We would not want to require that a>>> >> >>>>>>>>> given service function appear at only one place in the>>> >> >>>>>>>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> It is of course the case that these may be combined. I tend>>> >> >>>>>>>>> to>>> >> >>>>> refer to>>> >> >>>>>>>>> the collection of entities that appear to service chaining>>> >> >>>>>>>>> as a single point as a cluster. Not because cluster is a>>> >> >>>>>>>>> good term. But because I do not have another one. Thus, the>>> >> >>>>>>>>> point of type 3 load balancing>>> >> >>>>> is to>>> >> >>>>>>>>> direct different subsets of traffic to different singular>>> >> >>>>>>>>> or clustered service functions in different places in the>>> >> >>>>>>>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Now with that said, what do I mean when I talk about>>> >> >>>>>>>>> service chain and service path/ Service chain is a sequence>>> >> >>>>>>>>> of logical functions to be applied to a subset of packets.>>> >> >>>>>>>>> It is equivalent of saying that some subset of traffic is>>> >> >>>>>>>>> to get DPI, charging, content inspection, and firewall>>> >> >>>>>>>>> while a different subset is to go directly to the cache>>> >> >>>>> without>>> >> >>>>>>>>> visiting any other service functions.>>> >> >>>>>>>>>>>> >> >>>>>>>>> That is not enough information to direct the packets. A>>> >> >>>>>>>>> service path is, in some fashion, a sequence of locations>>> >> >>>>>>>>> in the network. Those locations will be singular or>>> >> >>>>>>>>> clustered service function delivery locations. They may be>>> >> >>>>>>>>> addressed by IP address. They may be addressed as ports on>>> >> >>>>>>>>> an SFF. There are many different ways that the locations>>> >> >>>>>>>>> may be known to the service chaining infrastructure and the>>> >> >>>>>>>>> transport.>>> >> >>>>>>>>>>>> >> >>>>>>>>>>  From the point of view of the work of the SFC group, we>>> >> >>>>>>>>>> need to be>>> >> >>>>>>>>> able to talk about the high level abstraction, the service>>> >> >>>>>>>>> chain, which drives the forwarding. And we need to talk>>> >> >>>>>>>>> about the actual data path packets will take in the>>> >> >>>>>>>>> network.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Several of the comments have said "but the whole path may>>> >> >>>>>>>>> not be known at the front." This architecture deals with>>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load>>> >> >>>>>>>>> balancers above, there can be decisions and behaviors which>>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in much>>> >> >>>>>>>>> the same way that bridging within a LAN is largely>>> >> >>>>>>>>> invisible to routing between LANs.) The other provision we>>> >> >>>>>>>>> make is>>> >> >>>>> that>>> >> >>>>>>>>> reclassification can be done in mid-chain when necessary.>>> >> >>>>>>>>> That will direct packets to a new chain. Based on>>> >> >>>>>>>>> information available at the re-classification point.>>> >> >>>>>>>>>>>> >> >>>>>>>>> I hope that this helps explain what we are after. If it>>> >> >>>>>>>>> does, and if the intent is acceptable to the working group,>>> >> >>>>>>>>> we can figure out what additional words are needed to>>> >> >>>>>>>>> convey this. If the working group disagree with the intent,>>> >> >>>>>>>>> then we will of course adjust to match the working group>>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to>>> >> >>>>>>>>> try next.>>> >> >>>>>>>>>>>> >> >>>>>>>>> Yours, Joel>>> >> >>>>>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc>>> >> mailing>>> >> >>>>>>>>> list [email-masked] <mailto:[email-masked]>>>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>>> >> >>>>>>>>>>>> >> >>>>>>>>> _______________________________________________ sfc>>> >> mailing>>> >> >>>>>>>>> list [email-masked] <mailto:[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>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>> _______________________________________________ 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>>> >> >>>>>>> >> >>>> _______________________________________________ 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>>> >>>>> >> _______________________________________________>>> >> 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_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:11:45 +0000

Yes, this goes without saying, so to speak.

To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>,Jim Guichard (jguichar)<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<[email-masked]<mailto:[email-masked]>>

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:18:45 -0400

I think this is the root of the confusion:

> I don’t want to specify> specific instances of S1, S2, and S3 (or some combination thereof). I> assign a service path identifier “100” that basically points to S1->S2->S3> and then push this into the network

By definition, I understood a "service path" to be an ordered list of specific SF instances.  In the statement above, you use a "service path identifier" to refer to a service *chain* that specifically "[does not] specify specific instances".

From: [email-masked]<[email-masked]>
To: NAPIERALA, MARIA H<[email-masked]>,[email-masked]<[email-masked]>,Joel M. Halpern<[email-masked]>,Ron Parker<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria,

>> -----Original Message-----
From: Jim Guichard (jguichar) [mailto:[email-masked]]>> Sent: Friday, July 11, 2014 11:15 AM>> To: NAPIERALA, MARIA H; [email-masked]; Joel M.>> Halpern; Ron Parker; [email-masked]>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >> I’m sorry but I really don’t understand why a service path identifier>> prevents full distribution of SF next-hops or why calling it a service>> chain identifier makes any difference?>> >> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:>> >> >Ditto.>> >>> >> -----Original Message----->> >> From: [email-masked]>> >> [mailto:[email-masked]]>> >> Sent: Friday, July 11, 2014 10:31 AM>> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; Ron>> >> Parker; [email-masked]>> >> Subject: RE: [sfc] Service Chains, Paths, and Load Balancers>> >>>> >> Re-,>> >>>> >> For what I can say at best this is not described clearly in the>>draft.>> >>>> >> Mandating a service path identifier is in itself a hint that the full>> >>distributed>> >> model is not allowed.>> >>>> >> Several voices in this thread indicated that the service chain itself>> >>should be>> >> provided instead.>> >>>> >> Cheers,>> >> Med>> >>>> >> >-----Message d'origine----->> >> >De : sfc [mailto:[email-masked]] De la part de Jim Guichard>> >> >(jguichar)>> >> >Envoyé : vendredi 11 juillet 2014 16:18>> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]>> >> >Objet : Re: [sfc] Service Chains, Paths, and Load Balancers>> >> >>> >> >Ok but where in the architecture specifically is this functionality>> >> >prohibited? If you want to distribute *all* next-hops to *all* SFF’s>> >> >within the SFC domain and then let the path identifier point to a>> >>lookup>> >> >into those next-hops to reach the next SF in the chain, I am not>>sure>> >>how>> >> >the architecture prevents that?>> >> >>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <[email-masked]>>> wrote:>> >> >>> >> >>Absolutely.>> >> >>>> >> >>> -----Original Message----->> >> >>> From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard>> >> >>>(jguichar)>> >> >>> Sent: Friday, July 11, 2014 9:54 AM>> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >> >>>>> >> >>> Then I misunderstand the proposal ;-) .. However, it seems to me>> >>that if>> >> >>> you allow an SFF to make a decision as to which remote SFF it>>will>> >>use>> >> >>>for>> >> >>> a given flow to reach the next SF within the chain then you>>better>> >>make>> >> >>> sure that that remote SFF has the necessary forwarding logic to>> >>reach>> >> >>>the>> >> >>> next-next-SF for the chain as otherwise you are in deep trouble.>> >> >>>>> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <[email-masked]>>> >> wrote:>> >> >>>>> >> >>> >Absolutely not. Service chains can be instantiated only in>>relevant>> >> >>>SFFs>> >> >>> >when they "arrive".>> >> >>> >>> >> >>> >> -----Original Message----->> >> >>> >> From: sfc [mailto:[email-masked]] On Behalf Of Jim>>Guichard>> >> >>> >>(jguichar)>> >> >>> >> Sent: Friday, July 11, 2014 9:27 AM>> >> >>> >> To: Joel M. Halpern; Ron Parker; [email-masked]>> >> >>> >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>> >> >>> >>>> >> >>> >> Well I think it is even worse than that if I have understood>>the>> >> >>> >>proposal>> >> >>> >> correctly as it would require full knowledge of every single>>SF>> >> >>>within>> >> >>> >>the>> >> >>> >> entire SFC domain at every single SFF as there is no way to>>know>> >>a>> >> >>> >>priori>> >> >>> >> which SFC¹s a given SFF will need to service at any given>>point>> >>in>> >> >>>time.>> >> >>> >>>> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]>>> >> wrote:>> >> >>> >>>> >> >>> >> >Ron, thinking about this, I realized another major problem>>with>> >>the>> >> >>> >>your>> >> >>> >> >proposal as I understand it.  (And I readily admit I may not>> >> >>>understand>> >> >>> >> >it.)>> >> >>> >> >>> >> >>> >> >The proposal has each SFF serve as the load balancer for the>> >>next>> >> >>> >> >service function that follows it (not the one it delivers>>to),>> >>in>> >> >>>every>> >> >>> >> >service chain that goes through it.>> >> >>> >> >>> >> >>> >> >Since it has to be able to work with all services, that means>> >>that>> >> >>> >>every>> >> >>> >> >SFF would have to be a full, flow sensitive and stateful load>> >> >>>balancer.>> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and / or>> >>stateful.>> >> >>> >> >But having the architecture require that every SFF be a full,>> >>flow>> >> >>> >> >sensitive, stateful, load balancer seems to me to be an>> >>acceptable>> >> >>> >> >imposition.>> >> >>> >> >>> >> >>> >> >Yours,>> >> >>> >> >Joel>> >> >>> >> >>> >> >>> >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>> >> >>> >> >> Part of my personal view is that I am trying to make this>>work>> >> >>> >>sensibly>> >> >>> >> >> in a more orchestrated environment.  I expect that the>>service>> >> >>> >> >> functions, and over time probably the SFF capabilities,>>will>> >>be>> >> >>> >> >> orchestrated and installed.  I expect the service chains>>to be>> >> >>> >>driven by>> >> >>> >> >> BSS tools that define offerings to clients, and enable>> >> >>>self-selection>> >> >>> >> >> from these.  I expect service paths to be heavily policy>> >>drive.>> >> >>> >> >>>> >> >>> >> >> I can see how to make all of that work in an archtiecture>> >>driven>> >> >>>by>> >> >>> >> >> initial classification to described service paths.  It is>> >>harder>> >> >>>to>> >> >>> >>see>> >> >>> >> >> how to make it work (but it can be done) when we allow more>> >> >>> >> dynamicity>> >> >>> >> >> in the network behavior.>> >> >>> >> >>>> >> >>> >> >> Having said that, most of that perspective I described is>> >>outside>> >> >>>of>> >> >>> >>the>> >> >>> >> >> scope of the working group.  it is not something we are>> >>tasked to>> >> >>> >>agree>> >> >>> >> >>on.>> >> >>> >> >> So I do not claim that vision means we have to do it a>>certain>> >> >>>way.>> >> >>> >>it>> >> >>> >> >> is just the perspective that drives my preferences.>> >> >>> >> >>>> >> >>> >> >> Yours,>> >> >>> >> >> Joel>> >> >>> >> >>>> >> >>> >> >> On 7/10/14, 9:58 PM, Ian Smith wrote:>> >> >>> >> >>>> For me, the amount of information about service instances>> >> that>> >> >>> >>needs>> >> >>> >> >>>>to>> >> >>> >> >>>> be widely distributed and maintained, potentially even>> >>across>> >> >>>data>> >> >>> >> >>>> centers within an administrative scope, is large enough>>and>> >> >>> complex>> >> >>> >> >>>> enough that trying to get that into each SFF seems like a>> >> >>>difficult>> >> >>> >> >>>> architecture to realize.>> >> >>> >> >>>>> >> >>> >> >>> I'm curious as to why that is more complicated than>>dynamic>> >> >>> routing,>> >> >>> >> >>> hyper-scale data center orchestration, or DNS, all of>>which>> >>are>> >> >>> >>bigger>> >> >>> >> >>> problems that have been profitably and stably implemented?>> >> >>> >> >>>>> >> >>> >> >>> It also seems that if it really is more complicated, that>>is>> >>a>> >> >>>good>> >> >>> >> >>> sign that it is too complicated.>> >> >>> >> >>>>> >> >>> >> >>> ________________________________________>> >> >>> >> >>> From: Joel M. Halpern [[email-masked]]>> >> >>> >> >>> Sent: Thursday, July 10, 2014 9:45 PM>> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; [email-masked];>>Ian>> >> >>>Smith;>> >> >>> >> >>> [email-masked]>> >> >>> >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load>>Balancers>> >> >>> >> >>>>> >> >>> >> >>> This is an architectural issue.  And one that I would>>prefer>> >>we>> >> >>> >> >>>actually>> >> >>> >> >>> decide, rather than trying to allow all possible>> >>implementations.>> >> >>> >> >>> Because it does have a major effect on the control>> >>requirements>> >> >>>and>> >> >>> >> the>> >> >>> >> >>> functionality of SFFs.>> >> >>> >> >>>>> >> >>> >> >>> For me, the amount of information about service instances>> >>that>> >> >>> needs>> >> >>> >> to>> >> >>> >> >>> be widely distributed and maintained, potentially even>> across>> >> >>>data>> >> >>> >> >>> centers within an administrative scope, is large enough>>and>> >> >>>complex>> >> >>> >> >>> enough that trying to get that into each SFF seems like a>> >> >>>difficult>> >> >>> >> >>> architecture to realize.>> >> >>> >> >>>>> >> >>> >> >>> Yours,>> >> >>> >> >>> Joel>> >> >>> >> >>>>> >> >>> >> >>> But it is a fair question.>> >> >>> >> >>>>> >> >>> >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>> >> >>> >> >>>> This is the crux of my issue.   Is the end to end>>selection>> >>of>> >> >>> >> >>>> (top-level) instances performed centrally (perhaps by the>> >> >>> >>classifier)>> >> >>> >> >>>> or hop-by-hop (perhaps by the classifier and subsequently>> >>the>> >> >>> >>SFFs)?>> >> >>> >> >>>> Such selection is not equivalent to reclassification.>>And>> >> >>>surely,>> >> >>> >> >>>> this is an architectural issue and not relegated to>> >> >>> >> >>>> "implementation".>> >> >>> >> >>>>>> >> >>> >> >>>> My own view is to favor the distributed approach even>> though>> >> a>> >> >>> >> >>>> greater amount of data (chain definitions and perhaps>>local>> >> >>> >>selection>> >> >>> >> >>>> policy) is required at those distributed decision points.>> >>This>> >> >>> >> >>>> approach does not require an end-to-end path id at all.>> >>My>> >> >>> >> >>>> rationale for favoring this approach is primarily driven>>by>> >> >>> >>increased>> >> >>> >> >>>> resiliency over the global path id approach.   With a>>global>> >> >>>path>> >> >>> >>id>> >> >>> >> >>>> approach, consider failure of an instance and needing to>> >>alter>> >> >>>the>> >> >>> >> >>>> global path ID table for each and every affected>>end-to-end>> >> >>>path.>> >> >>> >> >>>>>> >> >>> >> >>>> Ron>> >> >>> >> >>>>>> >> >>> >> >>>> ________________________________________ From: sfc>> >> >>> >> >>>> [[email-masked]] on behalf of Joel Halpern Direct>> >> >>> >> >>>> [[email-masked]] Sent: Thursday, July 10,>>2014>> >> 6:15>> >> >>> PM>> >> >>> >> >>>> To: [email-masked]; [email-masked]; [email-masked]>> Subject:>> >> Re:>> >> >>> >> >>>> [sfc] Service Chains, Paths, and Load Balancers>> >> >>> >> >>>>>> >> >>> >> >>>> The way the architecture models the case of SF1 needing>>to>> >> >>> >>influence>> >> >>> >> >>>> the chain is that one would do reclassification at the>>exit>> >>from>> >> >>> >> >>>> SF1.>> >> >>> >> >>>>>> >> >>> >> >>>> Part of the goal is to keep the different functions>> >>logically>> >> >>> >> >>>> separate so that solutions can clearly describe how they>> >> choose>> >> >>>to>> >> >>> >> >>>> compose them for "service" delivery.>> >> >>> >> >>>>>> >> >>> >> >>>> Yours, Joel>> >> >>> >> >>>>>> >> >>> >> >>>> On 7/10/14, 6:10 PM, [email-masked] wrote:>> >> >>> >> >>>>> I don't see anything in the arch draft that suggests any>> >>sort>> >> >>>of>> >> >>> >> >>>>> limit. However, it does seem to indicate that the entire>> >>path>> >> >>>(all>> >> >>> >> >>>>> SFIs) must be chosen at SFC instantiation.  I believe>>this>> >> >>>means>> >> >>> >> >>>>> either at the classifier or maybe the classifier>>chooses a>> >>SF>> >> >>> >>Chain>> >> >>> >> >>>>> and the NF or at the latest the first SFF.  In any case,>> >>the>> >> >>> >> >>>>> language does seem to prohibit a more dynamic SFP where>> >> SFI(n)>> >> >>> is>> >> >>> >> >>>>> determined at the SFI(n-1) hop.  According to the draft,>> >>this>> >> >>> >> >>>>> behavior would be considered "branching" to a new SFP as>> >> >>> opposed>> >> >>> >> to>> >> >>> >> >>>>> choosing and then forwarding to the selected instance of>> >>the>> >> >>> >> >>>>> next-hop of the current SFC.>> >> >>> >> >>>>>>> >> >>> >> >>>>> draft-merged-sfc-architecture-00:>> >> >>> >> >>>>>> When an SFC is instantiated into the network it is>> >>necessary>> >> >>>to>> >> >>> >> >>>>>> select the specific instances of SFs that will be used,>> >>and to>> >> >>> >> >>>>>> create the service topology for that SFC using SF's>> >>network>> >> >>> >> >>>>>> locator.  Thus, instantiation of the SFC results in the>> >> >>>creation>> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used for>> >>forwarding>> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP is the>> >> >>> >> >>>>>> instantiation of the defined SFC.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> The SFC architecture supports reclassification (or>> >>non-initial>> >> >>> >> >>>>>> classification) as well.  As packets traverse an SFP,>> >> >>> >> >>>>>> reclassification may occur - typically performed by a>> >> >>> >> >>>>>> classification function co-resident with a service>> >>function.>> >> >>> >> >>>>>> Reclassification may result in the selection of a new>> >>SFP, an>> >> >>> >> >>>>>> update of the associated metadata, or both.  This is>> >>referred>> >> >>>to>> >> >>> >> >>>>>> as "branching".>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>> >>>>>>>>>>>>>>------------------------------------------------------------->>>>>>>>>>>>>>-->> >>>>>>>>>>>>--->> >> >>>>>>>>>>-->> >> >>> >>>>>>>-->> >> >>> >> >>>>>-->> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>> *From: [email-masked]<[email-masked]>>> >> >>> >> >>>>> *To: *Joel Halpern>> Direct<[email-masked]>,Joel>> >> M.>> >> >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>> >>>>>Halpern<[email-masked]>,[email-masked]<huang@sce.>> >> >>> >> carleton.>> >> >>> >> >>>>>ca>,[email-masked]<[email-masked]>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>> *Sent: *Thursday, July 10, 2014>> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load>> >>Balancers>> >> >>> >> >>>>>>> >> >>> >> >>>>> Actually, I think I am disagreeing.>> >> >>> >> >>>>>>> >> >>> >> >>>>> If the possibility of medium-scale deployments (and>>that is>> >> >>>what>> >> >>> >> >>>>> 16 million flows is in my world) of service chains is>> >> >>>preconceived>> >> >>> >> >>>>> as an absurd idea, then the architecture burdened with>> that>> >> >>> >> >>>>> preconception.>> >> >>> >> >>>>>>> >> >>> >> >>>>> There has to be some point of aim, some degree of>> >>aspiration>> >> to>> >> >>> >> >>>>> scale that is appropriate for the lifespan of the>> >>architecture>> >> >>>->> >> >>> >> >>>>> you don't have to know what it is, but by saying that an>> >> >>>arbitrary>> >> >>> >> >>>>> number is "too far", you're creating - even if it isn't>> >> >>> >>intentional>> >> >>> >> >>>>> - a limit that influences decisions that have lasting>> >>impacts>> >> >>> >> >>>>> regarding scale-out, failure mitigation, elasticity,>> >>address>> >> >>> >> >>>>> space... all kinds of things. That is a problem I'm not>> >> >>> >> >>>>> particularly eager to deal with.>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>> ________________________________________>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>> From: Joel Halpern Direct [[email-masked]]>> >>Sent:>> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M.>> >> Halpern;>> >> >>> >> >>>>> [email-masked]; [email-masked] Subject: Re: [sfc]>> >>Service>> >> >>> >> >>>>> Chains, Paths, and Load Balancers>> >> >>> >> >>>>>>> >> >>> >> >>>>> Ian, I don't think you disagree with me at all in this>> >>regard.>> >> >>>I>> >> >>> >>am>> >> >>> >> >>>>> not requesting the the architecture or the solution>> >>prohibit>> >> >>> >> >>>>> deployments in the specific fashion. I am objecting to>> >>Huang's>> >> >>> >> >>>>> reading of my note as saying that such deployments are>> >> required>> >> >>> >> >>>>> they by the archtiecture.>> >> >>> >> >>>>>>> >> >>> >> >>>>> As I have said repeatedly, I am not trying to prohibit>>such>> >> >>> >> >>>>> things. Whether they are a good idea or not depends upon>> >> many>> >> >>> >> >>>>> factors outside of the scope of the WG. I happen to>>think>> >>that>> >> >>> >>they>> >> >>> >> >>>>> are usually a bad idea.>> >> >>> >> >>>>>>> >> >>> >> >>>>> But the archtiecture si carefully avoiding attempting to>> >>know>> >> >>>what>> >> >>> >> >>>>> is and is not eployable.>> >> >>> >> >>>>>>> >> >>> >> >>>>> Yours, Joel>> >> >>> >> >>>>>>> >> >>> >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>> >> >>> >> >>>>>> I disagree.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> We routinely have stateful devices that manage tens of>> >> >>>millions>> >> >>> >> >>>>>> of>> >> >>> >> >>>>> concurrent flows in both access network and data center>> >> >>> >> >>>>> environments today. You can't seriously believe that in>>the>> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you>> are>> >> only>> >> >>> >> going>> >> >>> >> >>>>> to have small numbers of service chains with equally>>small>> >> >>> numbers>> >> >>> >> >>>>> of active service paths?>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Your sounds too much like "no one will ever need more>> than>> >> >>> 64K">> >> >>> >> >>>>>> for>> >> >>> >> >>>>> comfort.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> ________________________________________ From: sfc>> >> >>> >> >>>>>> [[email-masked]] on behalf of Joel M. Halpern>> >> >>> >> >>>>> [[email-masked]]>> >> >>> >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To:>> >> >>>[email-masked];>> >> >>> >> >>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths,>>and>> >> >>>Load>> >> >>> >> >>>>>> Balancers>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> No, it will mean that if someone tries to deploy the>> >> >>>archtieture>> >> >>> >> >>>>>> particularly badly, they will exceed the limits of>>their>> >> >>> >> >>>>>> devices. The architecture does not require such absurd>> use>> >> of>> >> >>> >> >>>>>> service paths. Since I can not figure out how to write>> >> >>> >> >>>>>> architectural words to prohibit it, the architecture>>does>> >> >>>permit>> >> >>> >> >>>>>> such abuse.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Please do not read my saying that the archtiecture>> permits>> >> >>> >> >>>>>> something as saying it is either deisred or required by>> >>the>> >> >>>work.>> >> >>> >> >>>>>> It isn't.>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> Yours, Joel>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>> >> >>> >> >>>>>>> If you need to support 100 service chains, it will>>mean>> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the routing>>table>> >>of a>> >> >>> >> >>>>>>> core router.>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>> Chang>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>> >> >>> >> >>>>>>>> The architecture allows a range of deployments, from>>1>> >> >>> >> >>>>>>>> service path to 160000 service paths. I would hope>>that>> >> >>> >> >>>>>>>> operators are prepared for the complexities if they>> >>choose>> >> >>>to>> >> >>> >> >>>>>>>> avoid any use of local load balancing and in stead>> >> provision>> >> >>> >> >>>>>>>> 160,000 service paths.>> >> >>> >> >>>>>>>>>> >> >>> >> >>>>>>>> Yours, Joel>> >> >>> >> >>>>>>>>>> >> >>> >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>> >> >>> >> >>>>>>>>> Paul,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> How many path identifiers there will be for a 4 hop>> >> service>> >> >>> >> >>>>>>>>> chain with 20 instances at each hop?>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Maria>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf>> Of>> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014>> >>3:03>> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked];>> >> >>> >> >>>>>>>>> [email-masked]; [email-masked];>> >> >>> >> >>>>>>>>> [email-masked] *Subject:* Re: [sfc] Service>> Chains,>> >> >>> >> >>>>>>>>> Paths, and Load Balancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Lucy,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID drives the>> >> >>> >> >>>>>>>>> forwarding. I¹d>> >> >>> >> >>>>> make>> >> >>> >> >>>>>>>>> the minor change: the path identifier can be used to>> >> derive>> >> >>> >> >>>>>>>>> the needed forwarding and associated transport.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is used to>>simply>> >> >>> >> >>>>>>>>> identify the service path (or graph) that packets>>must>> >> >>> >> >>>>>>>>> traverse. By having a path identifier, the exact>> >> >>> >> >>>>>>>>> indirection that people seem to be asking for on>>this>> >> >>> >> >>>>>>>>> thread can be simply be implemented. The path>> >> identifier>> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup can>> >> result>> >> >>> >> >>>>>>>>> in a one or more (equal or weighted) transport next>> >> >>> >> >>>>>>>>> hop(s).>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Paul>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>> >> >>> >> >>>>>>>>> <[email-masked]>> >> <mailto:[email-masked]>>>> >> >>> >> >>>>>>>>> wrote:>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only use of>> the>> >> >>> >> >>>>>>>>> service path identifier to drive the forwarding>> >>actions.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Lucy>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>> >> >>> >> >>>>>>>>> [email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>>> >> >>> *Sent:*Thursday,>> >> >>> >> July>> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service>> >>Chains,>> >> >>> >> >>>>>>>>> Paths, and Load Balancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Re-,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a service path>> >> >>> >> >>>>>>>>> identifier. I object to use that identifier to>>derive>> >> >>> >> >>>>>>>>> forwarding actions.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge of>> >> every>> >> >>> >> >>>>> available SFC>> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not>> >> >>> >> >>>>> required/justified>> >> >>> >> >>>>>>>>> nor possible in various deployment contexts.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the piece of>> >> >>> >> >>>>>>>>> information>> >> >>> >> >>>>> that will>> >> >>> >> >>>>>>>>> be present in all deployments: that is the one>> required>> >> to>> >> >>> >> >>>>>>>>> structure a service chain. How that information is>> >>used to>> >> >>> >> >>>>>>>>> infer forwarding>> >> >>> >> >>>>> actions>> >> >>> >> >>>>>>>>> is a solution-oriented discussion.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Cheers,>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Med>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part>> >> >>> >> >>>>> [email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9>> >> juillet>> >> >>> >> >>>>>>>>> 2014 22:03 *À :[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service>> >>Chains,>> >> >>> >> >>>>>>>>> Paths, and Load Balancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Is anyone still questioning the difference between>>SF>> >> Chain>> >> >>> >> >>>>>>>>> and SF>> >> >>> >> >>>>> Path?>> >> >>> >> >>>>>>>>> Other than clarifying the definition so that it's>> >>clear to>> >> >>> >> >>>>> those not>> >> >>> >> >>>>>>>>> familiar with the draft, it seems that everyone>>agrees>> >>on>> >> >>> >> >>>>>>>>> these terms.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> To me, the one point that is still unclear is>>whether>> >>it is>> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify what>> >>the ID>> >> >>> >> >>>>>>>>> of the SFC Header>> >> >>> >> >>>>> should>> >> >>> >> >>>>>>>>> reference (the chain or the path), or if this draft>> >>simply>> >> >>> >> >>>>>>>>> intends to leave that ambiguous, allowing other>>drafts>> >>to>> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on chain>> or>> >> >>> >> >>>>>>>>> path and the choice of chain or>> >> >>> >> >>>>> path to>> >> >>> >> >>>>>>>>> be negotiated in the control-plane.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft would have>> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported (or make>> >> one>> >> >>> >> >>>>>>>>> required and the other optional) to avoid some>> vendors>> >> only>> >> >>> >> >>>>>>>>> supporting SFP and others only supporting SFC.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>> >> >>> >>>> >> >>>>> >>>> >>>>>>>>>>>>>>------------------------------------------------------------->>>>>>>>>>>>>>-->> >>>>>>>>>>>>--->> >> >>>>>>>>>>-->> >> >>> >>>>>>>-->> >> >>> >> >>>>>-->> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>>>> *From:[email-masked]<[email-masked]>> >> >>> >> >>>>>>>>>>> >> <mailto:[email-masked][email-masked]>>>> >> >>> >> >>>>>>>>> *To:[email-masked]<[email-masked]>> >> >>> >> >>>>>>>>> <mailto:[email-masked][email-masked]>>>> *Sent:*Tuesday,>> >> July>> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and>>Load>> >> >>> >> >>>>>>>>> Balancers>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> I have been trying to figure out how to clearly>>answer>> >>a>> >> >>> >> >>>>>>>>> number of comments that have been made about the>> >> >>> proposed>> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can get>> working>> >> >>> >> >>>>>>>>> group agreement on the intent, we will work to>> improve>> >> the>> >> >>> >> >>>>>>>>> wording so that readers who have not participated in>> >>the>> >> WG>> >> >>> >> >>>>>>>>> discussion will understnd it the way the>> >> >>> >> >>>>> working>> >> >>> >> >>>>>>>>> group intends.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> But what do we intend? I will try to explain my>> >>personal>> >> >>> >> >>>>>>>>> view, and see if that helps.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> In this regard, it is important to keep in mind that>> >>what>> >> >>> >> >>>>>>>>> we are defining is the data plane architecture. We>>are>> >> not>> >> >>> >> >>>>>>>>> attempting to define the architecture for the entire>> >> >>> >> >>>>>>>>> solution for service chaining. That would encompass>> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy functions,>>virtual>> >> >>> >> >>>>>>>>> machine and image management, and many other>> >> aspects.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> As a result there are many things which clearly need>> to>> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt with>> >>above>> >> >>> >> >>>>>>>>> where we are>> >> >>> >> >>>>> functioning,>> >> >>> >> >>>>>>>>> and are not directly required by the work we are>> doing.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> In order to get to service chain vs service path,>>as I>> >> >>> >> >>>>>>>>> understand>> >> >>> >> >>>>> them,>> >> >>> >> >>>>>>>>> I need to first discuss load balancing. There are at>> >>least>> >> >>> >> >>>>>>>>> three different ways that load balancing can and>>will>> >> >>> >> >>>>>>>>> interact with service chaining. There probably are>> >>more.>> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all of>> >>these,>> >> >>> >> >>>>>>>>> but not to mandate that any particular kind>> >> >>> >> >>>>> be used>> >> >>> >> >>>>>>>>> in any solution.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to the end>> >>user.>> >> >>> >> >>>>>>>>> This is a service function. It receives user>>packets,>> >>and>> >> >>> >> >>>>>>>>> modifies them (or>> >> >>> >> >>>>> marks>> >> >>> >> >>>>>>>>> them, or ...) so as to choose an end user service>> >>instance>> >> >>> >> >>>>>>>>> to receive the users packet. This is an important>> >>service>> >> >>> >> >>>>>>>>> function to be able to include in service chaining.>> >>It's>> >> >>> >> >>>>>>>>> behavior may affect requirements on how service>> >> chaining is>> >> >>> >> >>>>>>>>> done. But it has very little impact on the>> >>archtiecture.>> >> >>> >> >>>>>>>>>  From an architectural pe3rspective it is simply a>> >> >>> >> >>>>> service>> >> >>> >> >>>>>>>>> function which may modify the underlying packet.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That is, one>>can>> >>have>> >> >>> >> >>>>>>>>> what>> >> >>> >> >>>>> appears>> >> >>> >> >>>>>>>>> to the service chaining architecture as a single>>point>> >>of>> >> >>> >> >>>>>>>>> contact>> >> >>> >> >>>>> for a>> >> >>> >> >>>>>>>>> specific service function, but is actually delivered>> >>by a>> >> >>> >> >>>>> collection of>> >> >>> >> >>>>>>>>> virtual or physical machines, possibly including>>one or>> >> >>> >> >>>>>>>>> several load balancers (for example using VRRP-like>> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly, this is>> >> >>> >> >>>>>>>>> invisible to the service chaining data plane>> >>mechanisms.>> >> It>> >> >>> >> >>>>>>>>> is likely that it is visible to various control>> >>mechanisms,>> >> >>> >> >>>>>>>>> such as those responsible for scale-in, scale-out, >>and>> >>vm>> >> >>> >> >>>>>>>>> instantiation. The architectural impact of >>permitting>> >>this>> >> >>> >> >>>>>>>>> is largely that we need to be careful that our>> >>terminology>> >> >>> >> >>>>>>>>> does not lead>> >> >>> >> >>>>> readers to>> >> >>> >> >>>>>>>>> think we are prohibiting it.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> 3) There can also be load balancing done by >>selecting>> >> >>> >> >>>>>>>>> packet paths for the service chaining that direct>> >>traffic>> >> >>> >> >>>>>>>>> to different places. We would not want to require>> that>> >>a>> >> >>> >> >>>>>>>>> given service function appear at only one place in >>the>> >> >>> >> >>>>>>>>> network.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> It is of course the case that these may be >>combined. I>> >> tend>> >> >>> >> >>>>>>>>> to>> >> >>> >> >>>>> refer to>> >> >>> >> >>>>>>>>> the collection of entities that appear to service>> >>chaining>> >> >>> >> >>>>>>>>> as a single point as a cluster. Not because cluster >>is>> >>a>> >> >>> >> >>>>>>>>> good term. But because I do not have another one.>> Thus,>> >> the>> >> >>> >> >>>>>>>>> point of type 3 load balancing>> >> >>> >> >>>>> is to>> >> >>> >> >>>>>>>>> direct different subsets of traffic to different>> >>singular>> >> >>> >> >>>>>>>>> or clustered service functions in different places >>in>> >>the>> >> >>> >> >>>>>>>>> network.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Now with that said, what do I mean when I talk about>> >> >>> >> >>>>>>>>> service chain and service path/ Service chain is a>> >> sequence>> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset of>> >>packets.>> >> >>> >> >>>>>>>>> It is equivalent of saying that some subset of >>traffic>> >>is>> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, and >>firewall>> >> >>> >> >>>>>>>>> while a different subset is to go directly to the >>cache>> >> >>> >> >>>>> without>> >> >>> >> >>>>>>>>> visiting any other service functions.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> That is not enough information to direct the >>packets.>> A>> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence of>> >>locations>> >> >>> >> >>>>>>>>> in the network. Those locations will be singular or>> >> >>> >> >>>>>>>>> clustered service function delivery locations. They>> >>may be>> >> >>> >> >>>>>>>>> addressed by IP address. They may be addressed as>> ports>> >> on>> >> >>> >> >>>>>>>>> an SFF. There are many different ways that the>> >>locations>> >> >>> >> >>>>>>>>> may be known to the service chaining infrastructure>> and>> >> the>> >> >>> >> >>>>>>>>> transport.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>  From the point of view of the work of the SFC >>group,>> >> we>> >> >>> >> >>>>>>>>>> need to be>> >> >>> >> >>>>>>>>> able to talk about the high level abstraction, the>> >>service>> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need to>> talk>> >> >>> >> >>>>>>>>> about the actual data path packets will take in the>> >> >>> >> >>>>>>>>> network.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Several of the comments have said "but the whole>> path>> >> may>> >> >>> >> >>>>>>>>> not be known at the front." This architecture deals>> >>with>> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in item (2) >>on>> >>load>> >> >>> >> >>>>>>>>> balancers above, there can be decisions and >>behaviors>> >> which>> >> >>> >> >>>>>>>>> are invisible to the service chaining mechanisms (in>> >>much>> >> >>> >> >>>>>>>>> the same way that bridging within a LAN is largely>> >> >>> >> >>>>>>>>> invisible to routing between LANs.) The other>> provision>> >> we>> >> >>> >> >>>>>>>>> make is>> >> >>> >> >>>>> that>> >> >>> >> >>>>>>>>> reclassification can be done in mid-chain when>> >> necessary.>> >> >>> >> >>>>>>>>> That will direct packets to a new chain. Based on>> >> >>> >> >>>>>>>>> information available at the re-classification >>point.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> I hope that this helps explain what we are after. >>If it>> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the working>> >> group,>> >> >>> >> >>>>>>>>> we can figure out what additional words are needed>> to>> >> >>> >> >>>>>>>>> convey this. If the working group disagree with the>> >> intent,>> >> >>> >> >>>>>>>>> then we will of course adjust to match the working>> >>group>> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not sure>> >>what to>> >> >>> >> >>>>>>>>> try next.>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>> Yours, Joel>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> _______________________________________________>> >> sfc>> >> >>> >> mailing>> >> >>> >> >>>>>>>>> list [email-masked] <mailto:[email-masked]>>> >> >>> >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>> >> >>> >> >>>>>>>>>>> >> >>> >> >>>>>>>>>>> _______________________________________________>> >> sfc>> >> >>> >> mailing>> >> >>> >> >>>>>>>>> list [email-masked] <mailto:[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>> >> >>> >> >>>>>>>>> >> >>> >> >>>>>>>> >> >>> >> >>>>>> _______________________________________________>> 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>> >> >>> >> >>>>>> >> >>> >> >>>> _______________________________________________ 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>> >> >>> >>>> >> >>> >> _______________________________________________>> >> >>> >> 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>_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 12:20:17 -0400

If one declares that every SFC is realized by only one SFP (i.e each 
service chain is always realized by only one directive to the network 
forwarders, which then make choices based on that directive), then 
indeed the SFP does not add value.  I would call what results from such 
an equivalence and SFP, but if we were to accept such a limit, we could 
call it either one.

However, we also indicated we want to allow a degree of central 
arbitrarition and central control of traffic distribution.  So we need a 
layer of indirection to represent that.  The SFP represents the decision 
by the control plane and entry as to which initial subset is to be used. 
  This does not prevent there from being further load balancing (as 
discussed in the emails) within that envelop.

If there is no SFP distinct from the SFC then there is no envelop.

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:21:01 -0400

but it still sounds like there is a single SFF entity tied to the 20 instances through which ALL traffic destined for any of the 20 instances MUST traverse.  While this should surely not be prohibited, it shouldn't be mandated.

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

When you say "20 instances of the SF2 SF" are "Connected to that SFF" do you mean physically?  I had always just assumed that if I had 20 instances of a SF, that they would be diverse.  Even if within the same datacenter, they would be not near each other.
  It also seems like you are saying that there is only a single SFF for SF2 and that your traffic path requires traversing SF2 as a separate hop from the SF2 instance.  Ideally, the traffic would flow from SF1 instance to SF2 instance over the best path without
 the need for an intermediary hop.

Hi Mike,

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

Jim, 

Sent from my iPhone

Paul,

Maria

To: Lucy yong

Cc: [email-masked]; 

Lucy, 

Paul

Lucy

From:sfc
 [mailto:[email-masked]]On Behalf [email-masked]

Re-,

Cheers,

Med

De :sfc
 [mailto:[email-masked]]De la part [email-masked]

group intends.

if that helps.

in any solution.

place in the network.

re-classification point.

Yours,

Joel

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

sfc mailing list

[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 12:23:13 -0400

I am looking for a compromise whereby we add some flexibility to what is 
documented, retain the capabilities that are already included, and 
improve the clarity.

Yours,
Joel

On 7/11/14, 12:11 PM, [email-masked] wrote:
> Yes, the draft seems to indicate that if you want this distributed
> behavior, you need to re-classify onto a new SFP.  If that is not the
> intent of the draft, then it is unclear.
>
>
>
>
>
> *From: [email-masked]<[email-masked]>
> *To: *Jim Guichard (jguichar)<[email-masked]>,NAPIERALA, MARIA
> H<[email-masked]>,Joel M. Halpern<[email-masked]>,Ron
> Parker<[email-masked]>,[email-masked]<[email-masked]>
> *Sent: *Friday, July 11, 2014
> distributed model is not allowed.
>
> should be provided instead.
>
> Cheers,
> Med
>
> Subject: Re:
> the WG
> mechanisms. It
> Thus, the
>  >>> >> >>>>>>>>> may be known to the service chaining infrastructure
> and the
>  >>> >> >>>>>>>>> transport.
>  >>> >> >>>>>>>>>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:23:42 +0000

it’s just an example where the 20 instances are hidden behind the SFF but they do not have to be; if you wanted to address them individually then the architecture does not prevent that.

Date: Friday, July 11, 2014 at 12:21 PM

Hi Mike,

Jim,

Sent from my iPhone

Paul,

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 12:25:08 -0400

I meant as a design principle when everything is working.  I was trying to come up with a concise example of configuring a network such that it does not work that would be analogous to configuring SFC such that "that remote SFF has the necessary forwarding logic to reach the next-next-SF".

From: [email-masked]<[email-masked]>
To: [email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>
Sent: Friday, July 11, 2014
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

I don’t understand. (I’m sure I’m misunderstanding…) Your backend servers could go down, be unreachable or be unable to server more. Route health injection (RHI) is a perfectly fine, accepted, way of indicating the health of the backend services to the network. You’re not saying that’s wrong, are you?  

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 11 July 2014 12:03 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers heh.  well, if it did not, then you should not do it like that.  e.g. I'm not going to configure real servers on a server load balancer that are not reachable.  e.g. I'm not going to configure my BGP to announce prefixes for which I cannot provide connectivity.  If you do things like that, then you are doing it wrong.

>> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]; Ian Smith
;>> >>> [email-masked]
>> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern
;>> >>>>> [email-masked]; [email-masked] Subject: Re: [sfc] Service
>> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To: [email-masked]
;>> >>>>>> [email-masked] Subject: Re: [sfc] Service Chains, Paths, and Load
>> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked]
;>> >>>>>>>>> [email-masked]; [email-masked]
;>> >>>>>>>>> [email-masked] *Subject:* Re: [sfc] Service Chains,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 12:26:30 -0400

The draft does not mandate that singular SFF for 120 SFs.
If you want only one Service Path, then it implies that there is one SFF.
The relaxation I have proposed (which arguably was already permitted, 
but was either not clear or not present) is to allow there to be 
several, with carefully limited requirements on preceding SFFs, while 
permitting more powerful SFF behavior.

The way the text was written before, you could have achieved the same 
goal with a logically singular physically distributed SFF.  But that 
would have been complicated, and it was certainly hard to see that from 
the text.

So if the behavior I described is acceptable, we can relax that far.

Getting rid of the indirection of the SFP would actually cost us 
capability, which is why I keep harping on keeping it.

Yours,
Joel

On 7/11/14, 12:21 PM, [email-masked] wrote:
> but it still sounds like there is a single SFF entity tied to the 20
> instances through which ALL traffic destined for any of the 20 instances
> MUST traverse.  While this should surely not be prohibited, it shouldn't
> be mandated.
>
>
>
>
>
> *From: [email-masked]<[email-masked]>
> *To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>
> *cc: [email-masked]<[email-masked]>
> No they do not have to be physically connected but they are hidden
> behind an SFF in this case but do not have to be.
>
> From: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> To: Jim Guichard <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> When you say "20 instances of the SF2 SF" are "Connected to that SFF" do
> you mean physically? I had always just assumed that if I had 20
> instances of a SF, that they would be diverse. Even if within the same
> datacenter, they would be not near each other. It also seems like you
> are saying that there is only a single SFF for SF2 and that your traffic
> path requires traversing SF2 as a separate hop from the SF2 instance.
> Ideally, the traffic would flow from SF1 instance to SF2 instance over
> the best path without the need for an intermediary hop.
>
> *From: [email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
> *To: [email-masked] <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
> *cc: [email-masked] <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
> There still seems to be some confusion around this topic so let me try
> to provide a more detailed explanation as to how I believe this should
> work and why what I explained earlier is in fact a path identifier and
> not a chain identifier. Note that my explanation assumes that the SFC
> encapsulation will contain a path identifier as described within our
> charter which says “3. Generic SFC encapsulation: This document will
> describe a single service-level data plane encapsulation format that
> *indicates* the sequence of service functions that make up the Service
> Function Chain; *specifies* the Service Function Path”. The wording here
> is very important and shows that the intent is that the sequence of SF’s
> be indicated within the SFC encapsulation e.g. not carried – this is not
> source routing, and specifies the SFP, hence the path identifier.
>
> It is possible that each of those SF’s be directly addressable (i.e.
> provide SFF functionality) or reachable through some other network
> device that provides the forwarding (i.e. external, but connected SFF).
>
> In this example, SF1 and SF3 provide direct SFF functionality and SF2
> relies on a connected switch to provide the needed SFF functionality.
> Connected to that SFF are 20 instances of the SF2 SF. In this case you
> have exactly 3 network locators from which to choose in order to reach
> the required SF’s; let’s call them SF1-loc1, SF2-loc2, and SF3-loc3.
>
> When an operator instantiates SFC-1 into the network, specific locators
> are selected to construct the path, and a path identifier is allocated.
> In this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 ->
> SF2-loc2 -> SF3-loc3 and it has a path identifier “100”. This
> information is distributed to the relevant network devices basically
> saying “if you receive an SFC encapsulated packet with path identifier
> “100” then use the path identifier and index to perform a lookup in a
> data structure that will tell you which SF to forward the traffic to and
> how to get there”.
>
> So traffic flows through the SFP with path identifier “100”, via a
> network transport (the path identifier is encapsulated). It reaches
> SF1-loc1 which uses the path identifier to determine that it is in fact
> the SF that should be applied. It applies SF1 SF and then uses the path
> identifier to determine that SF2 is the next service and its reachable
> at next-hop SF2-loc2. The needed transport (for example VXLAN) is
> imposed for network forwarding. Traffic reaches SF2-loc2. It uses the
> path identifier to determine that SF2 should be applied. It uses a local
> decision to determine which of the 20 instances of SF2 it should forward
> the traffic to. It forwards the traffic to the selected instance. SF2 is
> applied and then another lookup occurs on the path identifier, which
> From: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>
> To: Jim Guichard <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> Technically, wouldn't this be a Chain Identifier if the next instance is
> chosen at each hop? In this case, there wouldn't be any Path Identifier
> at all.
>
> But it is the difference between a classifier needing to track the
> health, etc of 20^4 SF Paths for a single SF Chain, vs each of the 80
> instances tracking 20 SFIs of the next-hop for the chains of which they
> are members vs each SFF in the entire domain tracking all 80 SFIs vs
> something else.
>
>
>
>
> *From: [email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
> *To: *NAPIERALA, MARIA H<[email-masked] <mailto:[email-masked]>>
> *cc: *Paul Quinn (paulq)<[email-masked] <mailto:[email-masked]>>,Lucy
> yong<[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
>> *Cc:* [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>; [email-masked]
>> Overall I concur, as you say: a path ID drives the forwarding. I’d
>> make the minor change: the path identifier can be used to derive the
>> needed forwarding and associated transport.
>>
>> *From:*sfc
>> [<mailto:[email-masked]>mailto:[email-masked]]*On Behalf
>> Of*<mailto:[email-masked]>[email-masked]
>> *To:*<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>
>> *De :*sfc
>> [<mailto:[email-masked]>mailto:[email-masked]]*De la part
>> de*<mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>> *À :*<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>;<mailto:[email-masked]>[email-masked]
>> <mailto:[email-masked]>
>> *From:*<mailto:[email-masked][email-masked]>[email-masked]
>> <mailto:[email-masked]><[email-masked]
>> <mailto:[email-masked]>>
>> *To:*<mailto:[email-masked][email-masked]>[email-masked]
>> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:26:26 +0000

Jim,

> a data structure that contains SF to next-hop mappings. When you define a

Let's park it for now.

> the specific next-hops that you want traffic to flow through for that SFP.

You are talking about traffic engineering of paths that a service chain can take. 
This surely could be done/allowed but this cannot be a requirement for all traffic. 

> could simply assign a service path identifier to point to a given SFC and

If anything, I could image a service *chain* (not path) identifier pointing to a specific SFC structure.

> although it is perfectly acceptable (and some would say recommended) to

Agree, given the above comment about *chain* vs *path* identifier.
 
> assign a service path identifier “100” that basically points to S1->S2->S3

Again, for me this is  *chain* identifier, not the  path identifier.

> >> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern"
> <[email-masked]>
> >> >> wrote:
> >> >> >>> >>
> >> >> >>> >> >> how to make it work (but it can be done) when we allow
> more
> >> >> >>> >> dynamicity
> >> >> >>> >> >> in the network behavior.
> >> >> >>> >> >>
> >> >> >>> >> >>>> For me, the amount of information about service
> instances
> >> >> that
> >> >> >>> >>needs
> >> >> >>> >> >>>>to
> >> >> >>> >> >>> For me, the amount of information about service
> instances
> >> >>that
> >> >> >>> needs
> >> >> >>> >> to
> >> >> >>> >> >>>>> choosing and then forwarding to the selected instance
> of
> >> >>the
> >> >> >>> >> >>>>>> Your sounds too much like "no one will ever need
> more
> >> than
> >> >> >>> 64K"
> >> >> >>> >> >>>>>> for
> >> >> >>> >> >>>>> comfort.
> >> >> >>> >> >>>>>>
> >> >> >>> >> >>>>>>
> >> >> >>> >> >>>>>>>> The architecture allows a range of deployments,
> from
> >>1
> >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that lookup
> can
> >> >> result
> >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full knowledge
> of
> >> >> every
> >> >> >>> >> >>>>> available SFC
> >> >> >>> >> >>>>>>>>> dictate the mechanisms for forwarding based on
> chain
> >> or
> >> >> >>> >> >>>>>>>>> number of comments that have been made about
> the
> >> >> >>> proposed
> need
> about
> infrastructure
> >> >> >>> >> >>>>>>>>> we can figure out what additional words are
> needed
> >> to

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:28:30 +0000

Your definition of service path is correct as its the forwarding path through which traffic will actually flow. The service path identifier however points to the service chain data structure and that is then resolved to specific instances based upon which next-hops to those instances are available and whatever load distribution technique is in play. When instantiating the service chain into the network you may or may not update that data structure to specify which next-hops may be used (where a single next-hop would effectively nail up the service path for that service chain) or you may simply allow some other protocol / mechanism to populate the data structure for you.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 at 12:18 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I think this is the root of the confusion:

> I don’t want to specify
> and then push this into the network

To: NAPIERALA, MARIA H<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,Joel M. Halpern<[email-masked]<mailto:[email-masked]>>,Ron Parker<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>

Maria,

>> To: NAPIERALA, MARIA H; [email-masked]<mailto:[email-masked]>; Joel M.
>> Halpern; Ron Parker; [email-masked]<mailto:[email-masked]>
>> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> >Ditto.
>> >
>> >> From: [email-masked]<mailto:[email-masked]>
>> >> Parker; [email-masked]<mailto:[email-masked]>
>> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]<mailto:[email-masked]>
>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> >> >
>> >> >>Absolutely.
>> >> >>
>> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker; [email-masked]<mailto:[email-masked]>
>> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]<mailto:[email-masked]>;
>>Ian
>> >> >>>Smith;
>> >> >>> >> >>>> [[email-masked]<mailto:[email-masked]>] Sent: Thursday, July 10,
>>2014
>> >> 6:15
>> >> >>> PM
>> >> >>> >> >>>> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> Subject:
>> >> Re:
>> Direct<[email-masked]<mailto:[email-masked]>>,Joel
>> >> M.
>> >> >>> >> >>>>>
>> >> >>> >>
>> >> >>>
>> >>
>> >> >>>[email-masked]<mailto:[email-masked]>;
>> >> >>> >> >>>>>> [email-masked]<mailto:[email-masked]> Subject: Re: [sfc] Service Chains, Paths,
>>and
>> >> >>>Load
>> >> >>> >> >>>>>> Balancers
>> >> >>> >> >>>>>>
>> >> juillet
>> >> >>> >> >>>>>>>> list [email-masked]<mailto:[email-masked]>
>> >> >>> >> >>>>>>> list [email-masked]<mailto:[email-masked]>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:31:15 +0000

Maria,

>This surely could be done/allowed but this cannot be a requirement for

Jim> that’s why I said *might* - IOW you do not have to, its a deployment
choice and is supported by the architecture.

>> >> >> >>> Then I misunderstand the proposal ;-) .. However, it seems to
>>me
>> >> >>that if
>> >> >> >>> >> correctly as it would require full knowledge of every
>>single
>> >>SF
>> >> >> >>>within
>> >> >> >>> >>the
>> >> >> >>> >> >The proposal has each SFF serve as the load balancer for
>>the
>> >> >>next
>> >> >> >>> >> >SFF would have to be a full, flow sensitive and stateful
>>load
>> >> >> >>>balancer.
>> >> >> >>> >> >But having the architecture require that every SFF be a
>>full,
>> >> >>flow
>> >> >> >>> >> >> Part of my personal view is that I am trying to make
>>this
>> >>work
>> >> >> >>> >>sensibly
>> >> >> >>> >> >> I can see how to make all of that work in an
>>archtiecture
>> >> >>driven
>> >> >> >>>by
>> >> >> >>> >> >> initial classification to described service paths.  It
>>is
>> >> >>harder
>> >> >> >>>to
>> >> >> >>> >>see
>> >> >> >>> >> >>>> enough that trying to get that into each SFF seems
>>like a
>> >> >> >>>difficult
>> >> >> >>> >> >>>> architecture to realize.
>> >> >> >>> >> >>>
>> >> >> >>> >> >>> enough that trying to get that into each SFF seems
>>like a
>> >> >> >>>difficult
>> >> >> >>> >> >>> architecture to realize.
>> >> >> >>> >> >>>
>> >> >> >>> >> >>> Yours,
>> >> >> >>> >> >>> Joel
>> >> >> >>> >> >>>
>> >> >> >>> >> >>>> policy) is required at those distributed decision
>>points.
>> >> >>This
>> >> >> >>> >> >>>> approach does not require an end-to-end path id at
>>all.
>> >> >>My
>> >> >> >>> >> >>>> The way the architecture models the case of SF1
>>needing
>> >>to
>> >> >> >>> >>influence
>> >> >> >>> >> >>>> separate so that solutions can clearly describe how
>>they
>> >> >> choose
>> >> >> >>>to
>> >> >> >>> >> >>>>> I don't see anything in the arch draft that suggests
>>any
>> >> >>sort
>> >> >> >>>of
>> >> >> >>> >> >>>>> and the NF or at the latest the first SFF.  In any
>>case,
>> >> >>the
>> >> >> >>> >> >>>>> determined at the SFI(n-1) hop.  According to the
>>draft,
>> >> >>this
>> >> >> >>> >> >>>>>> select the specific instances of SFs that will be
>>used,
>> >> >>and to
>> >> >> >>> >> >>>>>> locator.  Thus, instantiation of the SFC results in
>>the
>> >> >> >>>creation
>> >> >> >>> >> >>>>>> Reclassification may result in the selection of a
>>new
>> >> >>SFP, an
>>>>>>>>>>>>>>>>-----------------------------------------------------------
>>>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>>>--
>> >> >>>>>>>>>>>>---
>> >> >> >>>>>>>>>>--
>> >> >> >>> >>>>>>>--
>> >> >> >>> >> >>>>>--
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>> as an absurd idea, then the architecture burdened
>>with
>> >> that
>> >> >> >>> >> >>>>> preconception.
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>> you don't have to know what it is, but by saying
>>that an
>> >> >> >>>arbitrary
>> >> >> >>> >> >>>>> number is "too far", you're creating - even if it
>>isn't
>> >> >> >>> >>intentional
>> >> >> >>> >> >>>>> deployments in the specific fashion. I am objecting
>>to
>> >> >>Huang's
>> >> >> >>> >> >>>>> reading of my note as saying that such deployments
>>are
>> >> >> required
>> >> >> >>> >> >>>>> As I have said repeatedly, I am not trying to
>>prohibit
>> >>such
>> >> >> >>> >> >>>>> But the archtiecture si carefully avoiding
>>attempting to
>> >> >>know
>> >> >> >>>what
>> >> >> >>> >> >>>>> is and is not eployable.
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>> Yours, Joel
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>> environments today. You can't seriously believe that
>>in
>> >>the
>> >> >> >>> >> >>>>>> something as saying it is either deisred or
>>required by
>> >> >>the
>> >> >> >>>work.
>> >> >> >>> >> >>>>>> It isn't.
>> >> >> >>> >> >>>>>>
>> >> >> >>> >> >>>>>> Yours, Joel
>> >> >> >>> >> >>>>>>
>> >> >> >>> >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10,
>>2014
>> >> >>3:03
>> >> >> >>> >> >>>>>>>>> structure a service chain. How that information
>>is
>> >> >>used to
>> >> >> >>> >> >>>>>>>>> infer forwarding
>> >> >> >>> >> >>>>> actions
>> >> >> >>> >> >>>>>>>>> Is anyone still questioning the difference
>>between
>> >>SF
>> >> >> Chain
>> >> >> >>> >> >>>>>>>>> and SF
>> >> >> >>> >> >>>>> Path?
>> >> >> >>> >> >>>>>>>>> the intent of this draft to ultimately specify
>>what
>> >> >>the ID
>> >> >> >>> >> >>>>>>>>> of the SFC Header
>> >> >> >>> >> >>>>> should
>>>>>>>>>>>>>>>>-----------------------------------------------------------
>>>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>>>--
>> >> >>>>>>>>>>>>---
>> >> >> >>>>>>>>>>--
>> >> >> >>> >>>>>>>--
>> >> >> >>> >> >>>>>--
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>>
>> >> >> >>> >> >>>>>>>
>> >> >> >>> >> >>>>>>>>>
>> >> >> >>> >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths,
>>and
>> >>Load
>> >> >> >>> >> >>>>>>>>> Balancers
>> >> >> >>> >> >>>>>>>>>
>> >> >> >>> >> >>>>>>>>> exist in the larger system, but which are dealt 
>>with
>> >> >>above
>> >> >> >>> >> >>>>>>>>> where we are
>> >> >> >>> >> >>>>> functioning,
>> >> >> >>> >> >>>>>>>>> interact with service chaining. There probably 
>>are
>> >> >>more.
>> >> >> >>> >> >>>>>>>>> function to be able to include in service 
>>chaining.
>> >> >>It's
>>delivered
>> >> >> >>> >> >>>>>>>>> given service function appear at only one place 
>>in
>> >>the
>> >> >> >>> >> >>>>>>>>> network.
>> >> >> >>> >> >>>>>>>>>
>> >> >> >>> >> >>>>>>>>> clustered service function delivery locations. 
>>They
>> >> >>may be
>> >> >> >>> >> >>>>>>>>> chain, which drives the forwarding. And we need 
>>to
>> >> talk
>> >> >> >>> >> >>>>>>>>> not be known at the front." This architecture 
>>deals
>> >> >>with
>> >> >> >>> >> >>>>>>>>> are invisible to the service chaining mechanisms 
>>(in
>> >> >>much
>> >> >> >>> >> >>>>>>>>> does, and if the intent is acceptable to the 
>>working
>> >> >> group,
>> >> >> >>> >> >>>>>>>>> convey this. If the working group disagree with 
>>the
>> >> >> intent,
>> >> >> >>> >> >>>>>>>>> then we will of course adjust to match the 
>>working
>> >> >>group
>> >> >> >>> >> >>>>>>>>> agreements. If this is still unclear, I am not 
>>sure
>> >> >>what to
>> >> >> >>> >> >>>>>>>>> try next.
>> >> >> >>> >> >>>>>>>>>
>> >> >> >>> >> >>>>>>>>> Yours, Joel
>> >> >> >>> >> >>>>>>>>>
>> >> >> >>> >> >>>>>>>>>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:30:50 +0000

The point here, I believe, is not to use as an example something that it not realistic ;-)

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, July 11, 2014 12:24 PM
To: [email-masked]; NAPIERALA, MARIA H
Cc: [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

it's just an example where the 20 instances are hidden behind the SFF but they do not have to be; if you wanted to address them individually then the architecture does not prevent that.

Hi Mike,

There still seems to be some confusion around this topic so let me try to provide a more detailed explanation as to how I believe this should work and why what I explained earlier is in fact a path identifier and not a chain identifier. Note that my explanation assumes that the SFC encapsulation will contain a path identifier as described within our charter which says "3. Generic SFC encapsulation: This document will describe a single service-level data plane encapsulation format that indicates the sequence of service functions that make up the Service Function Chain; specifies the Service Function Path". The wording here is very important and shows that the intent is that the sequence of SF's be indicated within the SFC encapsulation e.g. not carried - this is not source routing, and specifies the SFP, hence the path identifier.

For my example let's assume the following SFC:

(SFF1)SF1 -> (SFF2)SF2 -> (SFF3)SF3 and let's call it "SFC-1"

It is possible that each of those SF's be directly addressable (i.e. provide SFF functionality) or reachable through some other network device that provides the forwarding (i.e. external, but connected SFF).

In this example, SF1 and SF3 provide direct SFF functionality and SF2 relies on a connected switch to provide the needed SFF functionality. Connected to that SFF are 20 instances of the SF2 SF. In this case you have exactly 3 network locators from which to choose in order to reach the required SF's; let's call them SF1-loc1, SF2-loc2, and SF3-loc3.

When an operator instantiates SFC-1 into the network, specific locators are selected to construct the path, and a path identifier is allocated. In this example there are 3 locators so the SFP for SFC-1 is SF1-loc1 -> SF2-loc2 -> SF3-loc3 and it has a path identifier "100". This information is distributed to the relevant network devices basically saying "if you receive an SFC encapsulated packet with path identifier "100" then use the path identifier and index to perform a lookup in a data structure that will tell you which SF to forward the traffic to and how to get there".

So traffic flows through the SFP with path identifier "100", via a network transport (the path identifier is encapsulated). It reaches SF1-loc1 which uses the path identifier to determine that it is in fact the SF that should be applied. It applies SF1 SF and then uses the path identifier to determine that SF2 is the next service and its reachable at next-hop SF2-loc2. The needed transport (for example VXLAN) is imposed for network forwarding. Traffic reaches SF2-loc2. It uses the path identifier to determine that SF2 should be applied. It uses a local decision to determine which of the 20 instances of SF2 it should forward the traffic to. It forwards the traffic to the selected instance. SF2 is applied and then another lookup occurs on the path identifier, which results in the needed transport being imposed to reach the next service hop SF3-loc3 .. And so on and so forth.

Jim,

Sent from my iPhone

From:sfc [mailto:[email-masked]]On Behalf [email-masked]<mailto:[email-masked]>
De :sfc [mailto:[email-masked]]De la part [email-masked]<mailto:[email-masked]>

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 12:34:47 -0400

The way the draft uses the terms, and the way most discussions outside 
the IETF SFC working group use the term, a service function chain is 
something that you would discuss a policy about.  Certain traffic from 
certain users is supposed to receive a certain sequence of services, the 
service chain.

At the policy level, that does not care where in the network that is 
delivered.  So as to allow control a level of influence, and to have 
flexibility to have multiple representations in the network of that 
policy construct, we have the intermediate notion of service function 
path.  If the control system does not need to apply any influence, then 
it uses one service path for the service chain.  If it needs a level of 
control, it instantiates a suitable number of service paths in the 
control system, and rules for how those are used.

Then, the mapping in the SFF is based on that path, so as to enable the 
influence of the control system.  While still allowing several other 
layers of traffic management as discussed.

Yours,
Joel

On 7/11/14, 12:25 PM, [email-masked] wrote:
> I meant as a design principle when everything is working.  I was trying
> to come up with a concise example of configuring a network such that it
> does not work that would be analogous to configuring SFC such that "that
> remote SFF has the necessary forwarding logic to reach the next-next-SF".
>
>
>
>
>
> *From: [email-masked]<[email-masked]>
> *To:
> [email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>
> Route health injection (RHI) is a perfectly fine, accepted, way of
> indicating the health of the backend services to the network. You’re not
> saying that’s wrong, are you?
>
> **
>
> [email-masked] <mailto:[email-masked]>
> *Sent:* 11 July 2014 12:03 PM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> heh. well, if it did not, then you should not do it like that. e.g. I'm
> not going to configure real servers on a server load balancer that are
> not reachable. e.g. I'm not going to configure my BGP to announce
> prefixes for which I cannot provide connectivity. If you do things like
> that, then you are doing it wrong.
>
>
>
> *From: [email-masked]<[email-masked]
> <mailto:[email-masked][email-masked]>>
> *To: *NAPIERALA, MARIA H<[email-masked] <mailto:[email-masked]>>,Joel M.
> Halpern<[email-masked] <mailto:[email-masked]>>,Ron
> Parker<[email-masked]
> <mailto:[email-masked]>>,[email-masked]
>  >> To: Joel M. Halpern; Ron Parker; [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>]
>  >> >>>> [[email-masked] <mailto:[email-masked]>] on behalf
> of Joel Halpern Direct
>  >> >>>> [[email-masked]
> <mailto:[email-masked]>] Sent: Thursday, July 10, 2014 6:15 PM
>  >> >>>> To: [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]> Subject: Re:
> <mailto:[email-masked][email-masked]>>
>  >> >>>>> *To: *Joel Halpern Direct<[email-masked]
> <mailto:[email-masked]>>,Joel M.
>  >> >>>>>
>  >> >>>>>Halpern<[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]><huang@sce.
>  >> >>>>>ca>,[email-masked] <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>
>  >> >>>>>
>  >> >>>>>
>  >> >>>>>
>  >> >>>>> From: Joel Halpern Direct [[email-masked]
> <mailto:[email-masked]>] Sent:
>  >> >>>>> [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]> Subject: Re: [sfc] Service
>  >> >>>>>> [[email-masked] <mailto:[email-masked]>] on
> behalf of Joel M. Halpern
>  >> >>>>> [[email-masked] <mailto:[email-masked]>]
> [email-masked] <mailto:[email-masked]>;
>  >> >>>>>> [email-masked] <mailto:[email-masked]> Subject: Re: [sfc] Service
> Chains, Paths, and Load
>  >> >>>>>> Balancers
>  >> >>>>>>
> <mailto:[email-masked]>;
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>  >> >>>>>>>>> [email-masked] <mailto:[email-masked]> *Subject:*
>  >> >>>>>>>>> <[email-masked] <mailto:[email-masked]
> <mailto:[email-masked]%20%3cmailto:[email-masked]>>>
>  >> >>>>>>>>> wrote:
>  >> >>>>>>>>>
>  >> >>>>>>>>>
>  >> >>>>>>>>>
> <mailto:[email-masked]>
> <mailto:[email-masked]>
>  >> >>>>> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>
>  >> >>>>>>>>> *From:[email-masked]
> <mailto:[email-masked]%0b>>> >>>>>>>>>
>  >> >>>>>>>>> *To:[email-masked] <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]%0b>>> >>>>>>>>>
>  >> >>>>>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>  >> >>>>>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:37:24 +0000

> >> a data structure that contains SF to next-hop mappings. When you
> define

Yes, I noticed, but I also noticed that you are proposing a solution based on it.

You have not comment on the rest: is it still "service *path* identifier"?

Maria

> >> >> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H"
> <[email-masked]>
> >> >> >> wrote:
> >> >> >> >>>
> >> >> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct;
> [email-masked];
> >> >>Ian
> >> >> >> >>>Smith;
> >> >> >> >>> >> >>> [email-masked]
> >> >> >> >>> >> >>>>> behavior would be considered "branching" to a new
> SFP
> >> as
> >> >> >> >>> opposed
> >> >> >> >>> >> to
> >> >> >> >>> >> >>>>>> We routinely have stateful devices that manage
> tens
> >> of
> >> >> >> >>>millions
> >> >> >> >>> >> >>>>>> of
> >> >> >> >>> >> >>>>>>>>> the minor change: the path identifier can be
> used
> >> to
> >> >> >> derive
> >> >> >> >>> >> >>>>>>>>> Agree. The arch. doc should not mandate only
> use
> >> of
> >> >> the
> >> >> >> >>> >> >>>>>>>>> forwarding paths within an SFC-enabled domain
> is
> >> not
> >> >> >> >>> >> >>>>> required/justified
> >> >> >> >>> >> >>>>>>>>> wording so that readers who have not
> participated
> >> in
> >> >> >>the
> >> >> >> WG
> >> >> >> >>> >> >>>>>>>>> machine and image management, and many
> other
> >> >> >> aspects.
> >> >> >> >>> >> >>>>>>>>>
> >> >> >> >>> >> >>>>>>>>> techniques to share a MAC address.) mostly,
> this
> >>is

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:41:50 +0000

Sharon,

> We can reference other standard ID-Location mapping mechanisms (local or distributed) for matching SF-SFF. These can be leveraged by SFFs for load distribution and dynamic failure recovery not base…

As you probably know: I think is a great example — and one I think will likely be deployed — of how service path to network next hops will be resolved.  The SFF can “ask” LISP for a locator so the service path identifiers and get back one or more based on policy and load requirements.

Paul

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:43:02 +0000

On Jul 11, 2014, at 12:34 PM, Joel M. Halpern <[email-masked]> wrote:

> The way the draft uses the terms, and the way most discussions outside the IETF SFC working group use the term, a service function chain is something that you would discuss a policy about.  Certain traffic from certain users is supposed to receive a certain sequence of services, the service chain.
> 

I fail to see the confusion around these terms.  I think your definition above put them into context.  The other way I think about it: the chain is intent, and the path is the realization of that intent. 

> At the policy level, that does not care where in the network that is delivered.  So as to allow control a level of influence, and to have flexibility to have multiple representations in the network of that policy construct, we have the intermediate notion of service function path.  If the control system does not need to apply any influence, then it uses one service path for the service chain.  If it needs a level of control, it instantiates a suitable number of service paths in the control system, and rules for how those are used.
> 
> Then, the mapping in the SFF is based on that path, so as to enable the influence of the control system.  While still allowing several other layers of traffic management as discussed.
> 
> Yours,
> Joel
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 16:43:37 +0000

I am not proposing a solution (that’s the WG’s job) but simply using my
interpretation of the architecture to move the discussion forward.

Yes, it is still a service path identifier for the reasons that Joel
mentioned in another email.

On 7/11/14, 12:37 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> >> I think of it this way. The service path identifier is simply a
>>pointer
>> >>to
>> >> >> >> To: Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M.
>>Halpern;
>> >> Ron
>> >> >> >> Parker; [email-masked]
>> >> >> >> Mandating a service path identifier is in itself a hint that
>>the
>> >>full
>> >> >> >>distributed
>> >> >> >> model is not allowed.
>> >> >> >>
>> >> >> >> >within the SFC domain and then let the path identifier point
>>to a
>> >> >> >>lookup
>> >> >> >> >>> you allow an SFF to make a decision as to which remote SFF
>>it
>> >> >>will
>> >> >> >>use
>> >> >> >> >>>for
>> >> >> >> >>> sure that that remote SFF has the necessary forwarding
>>logic
>> >>to
>> >> >> >>reach
>> >> >> >> >>>the
>> >> >> >> >>> >> entire SFC domain at every single SFF as there is no
>>way to
>> >> >>know
>> >> >> >>a
>> >> >> >> >>> >>priori
>> >> >> >> >>> >> which SFC¹s a given SFF will need to service at any
>>given
>> >> >>point
>> >> >> >>in
>> >> >> >> >>>time.
>> >> >> >> >>> >>
>> >> >> >> >>> >> >Ron, thinking about this, I realized another major
>>problem
>> >> >>with
>> >> >> >>the
>> >> >> >> >>> >>your
>> >> >> >> >>> >> >proposal as I understand it.  (And I readily admit I
>>may
>> >>not
>> >> >> >> >>>understand
>> >> >> >> >>> >> >it.)
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >service function that follows it (not the one it
>>delivers
>> >> >>to),
>> >> >> >>in
>> >> >> >> >>>every
>> >> >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and
>>/ or
>> >> >> >>stateful.
>> >> >> >> >>> >> >> in a more orchestrated environment.  I expect that
>>the
>> >> >>service
>> >> >> >> >>> >> >> orchestrated and installed.  I expect the service
>>chains
>> >> >>to be
>> >> >> >> >>> >>driven by
>> >> >> >> >>> >> >> BSS tools that define offerings to clients, and
>>enable
>> >> >> >> >>>self-selection
>> >> >> >> >>> >> >> from these.  I expect service paths to be heavily
>>policy
>> >> >> >>drive.
>> >> >> >> >>> >> >>
>> >> >> >> >>> >> >> Having said that, most of that perspective I
>>described
>> >>is
>> >> >> >>outside
>> >> >> >> >>>of
>> >> >> >> >>> >>the
>> >> >> >> >>> >> >> So I do not claim that vision means we have to do it
>>a
>> >> >>certain
>> >> >> >> >>>way.
>> >> >> >> >>> >>it
>> >> >> >> >>> >> >>>> (top-level) instances performed centrally (perhaps
>>by
>> >>the
>> >> >> >> >>> >>classifier)
>> >> >> >> >>> >> >>>> greater amount of data (chain definitions and
>>perhaps
>> >> >>local
>> >> >> >> >>> >>selection
>> >> >> >> >>> >> >>>> resiliency over the global path id approach.
>>With a
>> >> >>global
>> >> >> >> >>>path
>> >> >> >> >>> >>id
>> >> >> >> >>> >> >>>> approach, consider failure of an instance and
>>needing
>> >>to
>> >> >> >>alter
>> >> >> >> >>>the
>> >> >> >> >>> >> >>>>>> create the service topology for that SFC using
>>SF's
>> >> >> >>network
>> >> >> >> >>> >> >>>>>> packets through the SFC. In other words, an SFP
>>is
>> >>the
>> >> >> >> >>> >> >>>>>> reclassification may occur - typically performed
>>by
>> >>a
>> >> >> >> >>> >> >>>>>> classification function co-resident with a
>>service
>> >> >> >>function.
>> >> >> >> >>> >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and
>>Load
>> >> >> >>Balancers
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>> If the possibility of medium-scale deployments
>>(and
>> >> >>that is
>> >> >> >> >>>what
>> >> >> >> >>> >> >>>>> 16 million flows is in my world) of service
>>chains is
>> >> >> >> >>>preconceived
>> >> >> >> >>> >> >>>>> - a limit that influences decisions that have
>>lasting
>> >> >> >>impacts
>> >> >> >> >>> >> >>>>> regarding scale-out, failure mitigation,
>>elasticity,
>> >> >> >>address
>> >> >> >> >>> >> >>>>> space... all kinds of things. That is a problem
>>I'm
>> >>not
>> >> >> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith;
>>Joel
>> >>M.
>> >> >> >> Halpern;
>> >> >> >> >>> >> >>>>> not requesting the the architecture or the
>>solution
>> >> >> >>prohibit
>> >> >> >> >>> >> >>>>> things. Whether they are a good idea or not
>>depends
>> >> upon
>> >> >> >> many
>> >> >> >> >>> >> >>>>> factors outside of the scope of the WG. I happen
>>to
>> >> >>think
>> >> >> >>that
>> >> >> >> >>> >>they
>> >> >> >> >>> >> >>>>> are usually a bad idea.
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>> particularly badly, they will exceed the limits
>>of
>> >> >>their
>> >> >> >> >>> >> >>>>>> Please do not read my saying that the
>>archtiecture
>> >> >> permits
>> >> >> >> >>> >> >>>>>>> If you need to support 100 service chains, it
>>will
>> >> >>mean
>> >> >> >> >>> >> >>>>>>> 16,000,000 paths. That is larger than the
>>routing
>> >> >>table
>> >> >> >>of a
>> >> >> >> >>> >> >>>>>>> core router.
>> >> >> >> >>> >> >>>>>>>
>> >> >> >> >>> >> >>>>>>> Chang
>> >> >> >> >>> >> >>>>>>>
>> >> >> >> >>> >> >>>>>>>> avoid any use of local load balancing and in
>>stead
>> >> >> >> provision
>> >> >> >> >>> >> >>>>>>>> 160,000 service paths.
>> >> >> >> >>> >> >>>>>>>>
>> >> >> >> >>> >> >>>>>>>> Yours, Joel
>> >> >> >> >>> >> >>>>>>>>
>> >> >> >> >>> >> >>>>>>>>> How many path identifiers there will be for a
>>4
>> >>hop
>> >> >> >> service
>> >> >> >> >>> >> >>>>>>>>> identify the service path (or graph) that
>>packets
>> >> >>must
>> >> >> >> >>> >> >>>>>>>>> indirection that people seem to be asking for
>>on
>> >> >>this
>> >> >> >> >>> >> >>>>>>>>> The merged draft calls out explicitly a
>>service
>> >>path
>> >> >> >> >>> >> >>>>>>>>> SFC forwarding actions should rely on the
>>piece
>> >>of
>> >> >> >> >>> >> >>>>>>>>> information
>> >> >> >> >>> >> >>>>> that will
>> >> >> >> >>> >> >>>>>>>>> If the latter (ambiguous), then the draft
>>would
>> >> have
>> >> >> >> >>> >> >>>>>>>>> we are defining is the data plane 
>>architecture.
>> >>We
>> >> >>are
>> >> >> >> not
>> >> >> >> >>> >> >>>>>>>>> three different ways that load balancing can 
>>and
>> >> >>will
>> >> >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit 
>>all of
>> >> >> >>these,
>> >> >> >> >>> >> >>>>>>>>> to receive the users packet. This is an 
>>important
>> >> >> >>service
>> >> >> >> >>> >> >>>>>>>>>  From an architectural pe3rspective it is 
>>simply
>> >>a
>> >> >> >> >>> >> >>>>> service
>> >> >> >> >>> >> >>>>>>>>> is likely that it is visible to various 
>>control
>> >> >> >>mechanisms,
>> >> >> >> >>> >> >>>>>>>>> packet paths for the service chaining that 
>>direct
>> >> >> >>traffic
>> >> >> >> >>> >> >>>>>>>>> service chain and service path/ Service chain 
>>is
>> >>a
>> >> >> >> sequence
>> >> >> >> >>> >> >>>>>>>>> of logical functions to be applied to a 
>>subset of
>> >> >> >>packets.
>> >> >> >> >>> >> >>>>>>>>> while a different subset is to go directly to 
>>the
>> >> >>cache
>> >> >> >> >>> >> >>>>> without
>> >> >> >> >>> >> >>>>>>>>> service path is, in some fashion, a sequence 
>>of
>> >> >> >>locations
>> >> >> >> >>> >> >>>>>>>>>>  From the point of view of the work of the 
>>SFC
>> >> >>group,
>> >> >> >> we
>> >> >> >> >>> >> >>>>>>>>>> need to be
>> >> >> >> >>> >> >>>>>>>>> about the actual data path packets will take 
>>in
>> >>the
>> >> >> >> >>> >> >>>>>>>>> network.
>> >> >> >> >>> >> >>>>>>>>>
>> >> >> >> >>> >> >>>>>>>>> that issue in two ways. First, as noted in 
>>item
>> >>(2)
>> >> >>on
>> >> >> >>load

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:43:58 +0000

I believe Mike was making fun of your definition of service path identifier…:
“a service path identifier" to refer to a service *chain* that specifically "[does not] specify specific instances".

From: Jim Guichard (jguichar) [mailto:[email-masked]]
Sent: Friday, July 11, 2014 12:28 PM
To: [email-masked]; NAPIERALA, MARIA H; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria,

>> >>>>>Halpern<[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><huang@sce.
<mailto:huang@sce.%0b>>> >> >>> >> carleton.
>> >> >>> >> >>>>>>>>> <[email-masked]<mailto:[email-masked]>
>> >> <mailto:[email-masked]><mailto:[email-masked]%3e>>
>> >> >>> >> >>>>>>>>> wrote:
>> >> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>>
>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]<mailto:[email-masked]%3e;[email-masked]>
>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]<mailto:[email-masked]%3e;[email-masked]>
>> >> >>> >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]<mailto:[email-masked]%3e;[email-masked]>
>> >> <mailto:[email-masked][email-masked]><mailto:[email-masked][email-masked]%3e>>
>> >> >>> >> >>>>>>>>> <mailto:[email-masked][email-masked]><mailto:[email-masked][email-masked]%3e>>
>> *Sent:*Tuesday,
>> >> July

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 11 Jul 2014 16:55:12 +0000

We certainly cannot define an architecture that dictates that all SFC paths are traffic engineered.

> Sent: Friday, July 11, 2014 12:44 PM
> >> >> >> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H"
> <[email-masked]>
> >> >> >> wrote:
> >> >> >> >> >
> >> >> >> >> >>Absolutely.
> >> >> >> >> >>
> >> >> >> >> >>> >> >>>>> language does seem to prohibit a more dynamic
> SFP
> >> >> where
> >> >> >> >> SFI(n)
> >> >> >> >> >>> is
> >> >> >> >> >>> >> >>>>> There has to be some point of aim, some degree
> of
> >> >> >> >>aspiration
> >> >> >> >> to
> >> >> >> >> >>> >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of
> tomorrow
> >> >> you
> >> >> >> are
> >> >> >> >> only
> >> >> >> >> >>> >> going
> >> >> >> >> >>> >> >>>>>>>>> thread can be simply be implemented. The
> path
> >> >> >> >> identifier
> >> >> >> >> >>> >> >>>>>>>>> in a one or more (equal or weighted)
> transport
> >> >> next
> >> >> >> >> >>> >> >>>>>>>>> hop(s).
> >> >> >> >> >>> >> >>>>>>>>>
> >> >> >> >> >>> >> >>>>>>>>> Paul
> >> >> >> >> >>> >> >>>>>>>>>
> >> >> >> >> >>> >> >>>>>>>>> require that both SFP and SFC be supported
> (or
> >> >> make
> >> >> >> >> one
> >> >> >> >> >>> >> >>>>>>>>> merged archtiecture draft. Assuming we can
> get
> >> >> >> working
> >> >> >> >> >>> >> >>>>>>>>> OSS/BSS, various control and policy
> functions,
> >> >> >>virtual
> >> >> >> >> >>> >> >>>>>>>>> good term. But because I do not have
> another
> >> one.
> >> >> >> Thus,
> >> >> >> >> the
> >> >> >> >> >>> >> >>>>>>>>> an SFF. There are many different ways that
> the
> >> >> >> >>locations

---

From: Lucy yong <[email-masked]>
Date: Fri, 11 Jul 2014 17:23:44 +0000

I like to restate my opinion.

The arch doc. should not mandate only use of service path identifier to drive the forwarding actions, i.e. the forwarding lookup.

Although some solution draft proposes that and some people like Paul and Jim as co-author of the draft (nsh) explain that, that is one solution design. The arch doc clearly states that it does not propose the solutions. 

In fact, draft-nui-sfc-mechanism proposes another way to implement SFC which uses both service path identifier and SF ID in forwarding actions.

People also proposed the solution on mail discussion that does not use the service path identifier to drive the forwarding actions.  So we should not make a solution assumption in arch doc.

BTW: IMO, we should separate the forwarding actions and load balance actions. Load balancing discussed here happens when several next hops exist after forwarding lookup. (this is not about load balancing as a SF).

Lucy  

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, July 11, 2014 11:44 AM
To: NAPIERALA, MARIA H; [email-masked]; Joel M. Halpern; Ron Parker; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I am not proposing a solution (that’s the WG’s job) but simply using my interpretation of the architecture to move the discussion forward.

Yes, it is still a service path identifier for the reasons that Joel mentioned in another email.

On 7/11/14, 12:37 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> >> >> >> For what I can say at best this is not described clearly in 
>> >> >> >> the
>> >> >>draft.
>> >> >> >>
>> >> >> >> Several voices in this thread indicated that the service 
>> >> >> >> chain
>> >>itself
>> >> >> >>should be
>> >> >> >> provided instead.
>> >> >> >>
>> >> >> >> Cheers,
>> >> >> >> Med
>> >> >> >>
>> >> >> >> >-----Message d'origine----- De : sfc 
>> >> >> >> >[mailto:[email-masked]] De la part de Jim
>>Guichard
>> >> >> >> >(jguichar)
>> >> >> >> >Envoyé : vendredi 11 juillet 2014 16:18 À : NAPIERALA, 
>> >> >> >> >MARIA H; Joel M. Halpern; Ron Parker;
>> [email-masked]
>> >> >> >> >prohibited? If you want to distribute *all* next-hops to 
>> >> >> >> >*all*
>> >>SFF’s
>> >> >> >> >into those next-hops to reach the next SF in the chain, I 
>> >> >> >> >am
>>not
>> >> >>sure
>> >> >> >>how
>> >> >> >> >>> Then I misunderstand the proposal ;-) .. However, it 
>> >> >> >> >>> seems
>>to
>> >>me
>> >> >> >>that if
>> >> >> >> >>> >Absolutely not. Service chains can be instantiated only 
>> >> >> >> >>> >in
>> >> >>relevant
>> >> >> >> >>>SFFs
>> >> >> >> >>> >when they "arrive".
>> >> >> >> >>> >
>> >> >> >> >>> >> >Since it has to be able to work with all services, 
>> >> >> >> >>> >> >that
>> >>means
>> >> >> >>that
>> >> >> >> >>> >>every
>> >> >> >> >>> >> >sensitive, stateful, load balancer seems to me to be 
>> >> >> >> >>> >> >an
>> >> >> >>acceptable
>> >> >> >> >>> >> >imposition.
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >Yours,
>> >> >> >> >>> >> >Joel
>> >> >> >> >>> >> >
>> >> >> >> >>> >> >> scope of the working group.  it is not something 
>> >> >> >> >>> >> >> we
>>are
>> >> >> >>tasked to
>> >> >> >> >>> >>agree
>> >> >> >> >>> >> >>on.
>> >> >> >> >>> >> >>>> be widely distributed and maintained, 
>> >> >> >> >>> >> >>>>potentially
>> even
>> >> >> >>across
>> >> >> >> >>>data
>> >> >> >> >>> >> >>> hyper-scale data center orchestration, or DNS, 
>> >> >> >> >>> >> >>> all
>>of
>> >> >>which
>> >> >> >>are
>> >> >> >> >>> >>bigger
>> >> >> >> >>> >> >>> It also seems that if it really is more 
>> >> >> >> >>> >> >>> complicated,
>> >>that
>> >> >>is
>> >> >> >>a
>> >> >> >> >>>good
>> >> >> >> >>> >> >>> Because it does have a major effect on the 
>> >> >> >> >>> >> >>> control
>> >> >> >>requirements
>> >> >> >> >>>and
>> >> >> >> >>> >> the
>> >> >> >> >>> >> >>> functionality of SFFs.
>> >> >> >> >>> >> >>>
>> >> >> >> >>> >> >>>> this is an architectural issue and not relegated 
>> >> >> >> >>> >> >>>> to "implementation".
>> >> >> >> >>> >> >>>>
>> >> >> >> >>> >> >>>> rationale for favoring this approach is 
>> >> >> >> >>> >> >>>> primarily
>> >>driven
>> >> >>by
>> >> >> >> >>> >>increased
>> >> >> >> >>> >> >>>> [[email-masked]] Sent: Thursday, 
>> >> >> >> >>> >> >>>> July
>>10,
>> >> >>2014
>> >> >> >> 6:15
>> >> >> >> >>> PM
>> >> >> >> >>> >> >>>> the chain is that one would do reclassification 
>> >> >> >> >>> >> >>>> at
>>the
>> >> >>exit
>> >> >> >>from
>> >> >> >> >>> >> >>>> SF1.
>> >> >> >> >>> >> >>>>
>> >> >> >> >>> >> >>>> Part of the goal is to keep the different 
>> >> >> >> >>> >> >>>> functions
>> >> >> >>logically
>> >> >> >> >>> >> >>>>> limit. However, it does seem to indicate that 
>> >> >> >> >>> >> >>>>> the
>> >>entire
>> >> >> >>path
>> >> >> >> >>>(all
>> >> >> >> >>> >> >>>>> either at the classifier or maybe the 
>> >> >> >> >>> >> >>>>> classifier
>> >> >>chooses a
>> >> >> >>SF
>> >> >> >> >>> >>Chain
>> >> >> >> >>> >> >>>>>> When an SFC is instantiated into the network 
>> >> >> >> >>> >> >>>>>> it
>>is
>> >> >> >>necessary
>> >> >> >> >>>to
>> >> >> >> >>> >> >>>>>> locator.  Thus, instantiation of the SFC 
>> >> >> >> >>> >> >>>>>> results
>>in
>> >>the
>> >> >> >> >>>creation
>> >> >> >> >>> >> >>>>>> of a Service Function Path (SFP) and is used 
>> >> >> >> >>> >> >>>>>> for
>> >> >> >>forwarding
>> >> >> >> >>> >> >>>>>> classification) as well.  As packets traverse 
>> >> >> >> >>> >> >>>>>> an
>> >>SFP,
>>>>>>>>>>>>>>>>>>------------------------------------------------------
>>>>>>>>>>>>>>>>>>---
>>>>>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>>>>>--
>> >> >>>>>>>>>>>>>>--
>> >> >> >>>>>>>>>>>>---
>> >> >> >> >>>>>>>>>>--
>> >> >> >> >>> >>>>>>>--
>> >> >> >> >>> >> >>>>>--
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>> Ian, I don't think you disagree with me at all 
>> >> >> >> >>> >> >>>>> in
>> >>this
>> >> >> >>regard.
>> >> >> >> >>>I
>> >> >> >> >>> >>am
>> >> >> >> >>> >> >>>>> concurrent flows in both access network and 
>> >> >> >> >>> >> >>>>> data
>> >> center
>> >> >> >> >>> >> >>>>>> [email-masked] Subject: Re: [sfc] Service 
>> >> >> >> >>> >> >>>>>> Chains,
>> >>Paths,
>> >> >>and
>> >> >> >> >>>Load
>> >> >> >> >>> >> >>>>>> Balancers
>> >> >> >> >>> >> >>>>>>
>> >> >> >> >>> >> >>>>>> No, it will mean that if someone tries to 
>> >> >> >> >>> >> >>>>>> deploy
>>the
>> >> >> >> >>>archtieture
>> >> >> >> >>> >> >>>>>> devices. The architecture does not require 
>> >> >> >> >>> >> >>>>>> such
>> >>absurd
>> >> >> use
>> >> >> >> of
>> >> >> >> >>> >> >>>>>> service paths. Since I can not figure out how 
>> >> >> >> >>> >> >>>>>> to
>> >>write
>> >> >> >> >>> >> >>>>>>>> service path to 160000 service paths. I 
>> >> >> >> >>> >> >>>>>>>> would
>> hope
>> >> >>that
>> >> >> >> >>> >> >>>>>>>> operators are prepared for the complexities 
>> >> >> >> >>> >> >>>>>>>> if
>> >>they
>> >> >> >>choose
>> >> >> >> >>>to
>> >> >> >> >>> >> >>>>>>>>> *From:*sfc [mailto:[email-masked]] 
>> >> >> >> >>> >> >>>>>>>>> *On
>> >> Behalf
>> >> >> Of
>> >> >> >> >>> >> >>>>>>>>> [email-masked] *Subject:* Re: [sfc] 
>> >> >> >> >>> >> >>>>>>>>> Service
>> >> >> Chains,
>> >> >> >> >>> >> >>>>>>>>> Overall I concur, as you say: a path ID 
>> >> >> >> >>> >> >>>>>>>>> drives
>> >>the
>> >> >> >> >>> >> >>>>>>>>> forwarding. I¹d
>> >> >> >> >>> >> >>>>> make
>> >> >> >> >>> >> >>>>>>>>> It is _not_ the transport, but rather is 
>> >> >> >> >>> >> >>>>>>>>> used
>>to
>> >> >>simply
>> >> >> >> >>> >> >>>>>>>>> *De :*sfc [mailto:[email-masked]]*De 
>> >> >> >> >>> >> >>>>>>>>> la
>> >>part
>> >> >> >> >>> >> >>>>> [email-masked]
>> >> >> >> >>> >> >>>>>>>>> Other than clarifying the definition so 
>> >> >> >> >>> >> >>>>>>>>> that
>>it's
>> >> >> >>clear to
>> >> >> >> >>> >> >>>>> those not
>> >> >> >> >>> >> >>>>>>>>> To me, the one point that is still unclear 
>> >> >> >> >>> >> >>>>>>>>> is
>> >> >>whether
>> >> >> >>it is
>> >> >> >> >>> >> >>>>>>>>> reference (the chain or the path), or if 
>> >> >> >> >>> >> >>>>>>>>> this
>> >>draft
>> >> >> >>simply
>>>>>>>>>>>>>>>>>>------------------------------------------------------
>>>>>>>>>>>>>>>>>>---
>>>>>>>>>>>>>>>>>>--
>> >>>>>>>>>>>>>>>>--
>> >> >>>>>>>>>>>>>>--
>> >> >> >>>>>>>>>>>>---
>> >> >> >> >>>>>>>>>>--
>> >> >> >> >>> >>>>>>>--
>> >> >> >> >>> >> >>>>>--
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>
>> >> >> >> >>> >> >>>>>>>
>> >> >> >> >>> >> >>>>>>>>>
>> >> >> >> >>> >> >>>>>>>>> But what do we intend? I will try to 
>> >> >> >> >>> >> >>>>>>>>> explain
>>my
>> >> >> >>personal
>> >> >> >> >>> >> >>>>>>>>> attempting to define the architecture for 
>> >> >> >> >>> >> >>>>>>>>> the
>> >>entire
>> >> >> >> >>> >> >>>>>>>>> and are not directly required by the work 
>> >> >> >> >>> >> >>>>>>>>> we
>>are
>> >> >> doing.
>> >> >> >> >>> >> >>>>>>>>>
>> >> >> >> >>> >> >>>>>>>>> I need to first discuss load balancing. 
>> >> >> >> >>> >> >>>>>>>>> There
>> >>are at
>> >> >> >>least
>> >> >> >> >>> >> >>>>>>>>> 1) Load balancing as a service provided to 
>> >> >> >> >>> >> >>>>>>>>> the
>> >>end
>> >> >> >>user.
>> >> >> >> >>> >> >>>>>>>>> 2) There is internal load balancing. That 
>> >> >> >> >>> >> >>>>>>>>> is,
>>one
>> >> >>can
>> >> >> >>have
>> >> >> >> >>> >> >>>>>>>>> what
>> >> >> >> >>> >> >>>>> appears
>> >> >> >> >>> >> >>>>>>>>> is largely that we need to be careful that 
>> >> >> >> >>> >> >>>>>>>>> our
>> >> >> >>terminology
>> >> >> >> >>> >> >>>>>>>>> does not lead
>> >> >> >> >>> >> >>>>> readers to
>> >> >> >> >>> >> >>>>>>>>> to get DPI, charging, content inspection, 
>> >> >> >> >>> >> >>>>>>>>> and
>> >> >>firewall
>> >> >> >> >>> >> >>>>>>>>> in the network. Those locations will be
>>singular
>> >>or
>> >> >> >> >>> >> >>>>>>>>> able to talk about the high level 
>> >> >> >> >>> >> >>>>>>>>> abstraction,
>> >>the
>> >> >> >>service
>> >> >> >> >>> >> >>>>>>>>> That will direct packets to a new chain. 
>> >> >> >> >>> >> >>>>>>>>> Based
>> on
>> >> >> >> >>> >> >>>>>>>>> re-classification

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 14:46:26 -0400

Wouldn't that be called the "service chain identifier" then?  If the service chain is the ordered list of SFs and the service path is the ordered list of SF instances, then I would infer that a "service path identifier" would be an identifier for a service *path*, not a service *chain*.

Again, I think this is where the confusion keeps creeping in.  The terms "chain" and "path" seem inconsistent.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Your definition of service path is correct as its the forwarding path through which traffic will actually flow. The service path identifier however points to the service chain data structure and that is then resolved to specific instances based upon which
 next-hops to those instances are available and whatever load distribution technique is in play. When instantiating the service chain into the network you may or may not update that data structure to specify which next-hops may be used (where a single next-hop
 would effectively nail up the service path for that service chain) or you may simply allow some other protocol / mechanism to populate the data structure for you. 

From: "[email-masked]" <[email-masked]>
Date: Friday, July 11, 2014 at 12:18 PM
To: Jim Guichard <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]"
 <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]"
 <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

To: NAPIERALA, MARIA H<[email-masked]>,[email-masked]<[email-masked]>,Joel M. Halpern<[email-masked]>,Ron
 Parker<[email-masked]>,[email-masked]<[email-masked]>

Maria,

so.

>Could you tell us what is the definition of a "service path" and a

>"service path identifier"?

[email-masked];
>> >> >>> >> >>>> [[email-masked]] Sent: Thursday, July 10,
[email-masked]; [email-masked]
>> >> >>> >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M.
[email-masked] Subject: Re: [sfc]
>> >> >>> >> >>>>>>>>> [email-masked];
[email-masked];

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Jul 2014 14:55:40 -0400

It seems clear to me that we will need to adjust the precise wording in 
the document.
Fine.  We will do so.

What I have been trying to communicate is the importance of having the 
level of indirection between the policy level notion of service chain 
and the individual service function forwarders.  That level of 
indirection enables flexibility in deployment, adn avoids conflating 
data plane behavior with policy and service level descriptions.

Yours,
Joel

On 7/11/14, 2:46 PM, [email-masked] wrote:
> Wouldn't that be called the "service chain identifier" then?  If the
> service chain is the ordered list of SFs and the service path is the
> ordered list of SF instances, then I would infer that a "service path
> identifier" would be an identifier for a service *path*, not a service
> *chain*.
>
> [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
> Your definition of service path is correct as its the forwarding path
> through which traffic will actually flow. The service path identifier
> however points to the service chain data structure and that is then
> resolved to specific instances based upon which next-hops to those
> instances are available and whatever load distribution technique is in
> play. When instantiating the service chain into the network you may or
> may not update that data structure to specify which next-hops may be
> used (where a single next-hop would effectively nail up the service path
> for that service chain) or you may simply allow some other protocol /
> mechanism to populate the data structure for you.
>
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> By definition, I understood a "service path" to be an ordered list of
> specific SF instances. In the statement above, you use a "service path
> identifier" to refer to a service *chain* that specifically "[does not]
> specify specific instances".
>
>
>
>
> *To: *NAPIERALA, MARIA H<[email-masked]
> <mailto:[email-masked]>>,[email-masked]
> <mailto:[email-masked]>>,Joel M.
>>> To: NAPIERALA, MARIA H;[email-masked] <mailto:[email-masked]>; Joel M.
>>> Halpern; Ron Parker;[email-masked] <mailto:[email-masked]>
>>> On 7/11/14, 10:58 AM, "NAPIERALA, MARIA H" <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> >Ditto.
>>> >
>>> >> From:[email-masked] <mailto:[email-masked]>
>>> >> Parker;[email-masked] <mailto:[email-masked]>
>>> >> >À : NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;[email-masked] <mailto:[email-masked]>
>>> >> >On 7/11/14, 9:58 AM, "NAPIERALA, MARIA H" <[email-masked] <mailto:[email-masked]>>
>>> wrote:
>>> >> >
>>> >> >>Absolutely.
>>> >> >>
>>> >> >>> To: NAPIERALA, MARIA H; Joel M. Halpern; Ron Parker;[email-masked] <mailto:[email-masked]>
>>> >> >>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <[email-masked] <mailto:[email-masked]>>
>>> >> wrote:
>>> >> >>>
>>> >> >>> >> To: Joel M. Halpern; Ron Parker;[email-masked] <mailto:[email-masked]>
>>> >> >>> >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked] <mailto:[email-masked]>>
>>> >> wrote:
>>> >> >>> >>
>>> >> >>> >> >>> From: Joel M. Halpern [[email-masked] <mailto:[email-masked]>]
>>> >> >>> >> >>> To: Ron Parker; Joel Halpern Direct;[email-masked] <mailto:[email-masked]>;
>>>Ian
>>> >> >>>Smith;
>>> >> >>> >> >>>> [[email-masked] <mailto:[email-masked]>] on behalf of Joel
> Halpern Direct
>>> >> >>> >> >>>> [[email-masked] <mailto:[email-masked]>] Sent:
> Thursday, July 10,
>>>2014
>>> >> 6:15
>>> >> >>> PM
>>> >> >>> >> >>>> To:[email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>>> Subject:
>>> >> Re:
>>> >> >>> >> >>>> On 7/10/14, 6:10 PM,[email-masked] <mailto:[email-masked]> wrote:
>>> >> >>> >> >>> *From:[email-masked] <mailto:[email-masked]><[email-masked]
> <mailto:[email-masked]>>
>>> >> >>> >> >>>>> *To: *Joel Halpern
>>> Direct<[email-masked] <mailto:[email-masked]>>,Joel
>>> >> M.
>>> >> >>> >> >>>>>
>>> >> >>> >>
>>> >> >>>
>>> >>
>>> >>>>>Halpern<[email-masked] <mailto:[email-masked]>>,[email-masked]
>>> >> >>> >> >>>>>ca>,[email-masked] <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
>>> >> >>> >> >>>>>
>>> >> >>> >> >>>>>
>>> >> >>> >> >>>>>
>>> >> >>> >> >>>>> From: Joel Halpern Direct [[email-masked] <mailto:[email-masked]>]
>>> >>Sent:
>>> >> >>> >> >>>>>[email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]> Subject: Re: [sfc]
>>> >>Service
>>> >> >>> >> >>>>>> [[email-masked] <mailto:[email-masked]>] on behalf of Joel M.
> Halpern
>>> >> >>> >> >>>>>>[email-masked] <mailto:[email-masked]> Subject: Re: [sfc] Service Chains, Paths,
>>>and
>>> >> >>>Load
>>> >> >>> >> >>>>>> Balancers
>>> >> >>> >> >>>>>>
>>> >> >>> >> >>>>>>>>> PM *To:* Lucy yong *Cc:[email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>;
>>> >> >>> >> >>>>>>>>>[email-masked] <mailto:[email-masked]> *Subject:* Re: [sfc] Service
>>> Chains,
>>> >> >>> >> >>>>>>>>> <[email-masked] <mailto:[email-masked]>
>>> >> <mailto:[email-masked]>>
>>> >> >>> >> >>>>>>>>> wrote:
>>> >> >>> >> >>>>>>>>>
>>> >> >>> >> >>>>>>>>>
>>> >> >>> >> >>>>>>>>>
>>> >> >>> >> >>>>>>>>>[email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>>> 2014 22:03 *À :[email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>>> *From:[email-masked] <mailto:[email-masked]><[email-masked]
>>> >> >>> >> >>>>>>>>> *To:[email-masked] <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>> >> >>> >> >>>>>>>> [email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>> [email-masked] <mailto:[email-masked]>
>>> >> >>> >> >>>>>>[email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>> >> >>> >> >>>>>>
>>> >> >>> >> >>>>>
>>> >> >>> >> >>>>>[email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>> >> >>> >> >>>>
>>> >> >>> >> >>>>[email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>> >> >>> >> >>>>
>>> >> >>> >> >>>>[email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/sfc
>>> >> >>> >> >>>>
>>> >> >>> >> >>>
>>> >> >>> >> >>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 11 Jul 2014 18:57:16 +0000

No because the same abstracted chain might be referenced with different path identfiers as the next-hops that form the path to realize the chain may be different dependent upon policies.  So path identifier “100” might point to S1(@loc1)->S2(@loc2) whereas “101” might point to S1(@loc55)->S2(@loc64). They are the same chain but different paths.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 11, 2014 at 2:46 PM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

To: [email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>,[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>

Maria,

---

From: Eric Gray <[email-masked]>
Date: Fri, 11 Jul 2014 19:27:58 +0000

Maria,

So many fundamental problems.  What to do?

I didn't suggest "leaving it to implementation."  I merely suggested that each IETF
working group needs to focus on a set of problems they can solve in a reasonable
amount of time, without having to boil any oceans.

Joel suggested an architectural approach that would allow any form of distribution
you might want, without requiring every solution to support all possibilities, and
without impacting the ability of solutions to be optimized for whatever deployment
scenario may apply in any specific case.

Working out ways to optimize your particular deployment model seems to be your
problem (with support from your suppliers - whoever they might be) and - it seems
to me - the burden of making sure that the standards we define allows optimization
for that deployment falls on you (and them).

Meanwhile, other providers and other vendors may seek to ensure that whatever
we define allows at least some degree of optimization for their deployments.

This is the process.

Is the architectural proposal Joel came up with sufficient as a starting point?

--
Eric

-----Original Message-----
From: NAPIERALA, MARIA H [mailto:[email-masked]] 
Sent: Thursday, July 10, 2014 12:29 PM
To: Eric Gray; Jim Guichard (jguichar); Ron Parker
Cc: Joel M. Halpern; [email-masked]; [email-masked]
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers
Importance: High

Eric,

> Load distribution is not the same as service function chaining and - 
> while there may be problems to solve in this area - why would we 
> assume that SFC is supposed to solve them?

> I think SFC should be more concerned about ensuring that function 
> chaining solutions do not preclude load distribution.

How would you ensure it?

> > I should clarify that my statement was made as a personal opinion 
> > and it is up to the WG to evaluate if there exists anything at the 
> > >>>>> each hop then you can choose to load balance among them 
> > >>>>> locally resulting in exactly 4 paths. What Joel is saying is 
> > >>>>> that if for some very odd and certainly not recommended reason 
> > >>>>> you want to treat each instance separately then the 
> > >>>>> architecture does not
> > prevent it.
> > >>>>>
> > >>>>> Sent from my iPhone
> > >>>>>
> > >>>>> to globally manage 160,000 service paths (for one chain)? 
> > >>>>> Well, we have yet to see a solution that work this way and scales..
> > >>>>>>
> > >>>>>> Maria
> > >>>>>>
> > >>>>>>>>> The archtiecture allows for this local decision, while 
> > >>>>>>>>> still having the global decision that is directing the traffic.
> > >>>>>>>>> algorithms to distribute the traffic internally, without 
> > >>>>>>>>> any effect on service chaining.  (And yes, this can be 
> > >>>>>>>>> done in such a way that return traffic, if delivered 
> > >>>>>>>>> globally to the same place, can then be delivered to the 
> > >>>>>>>>> right internal
> > >>>>>>>>> state.)
> > >>>>>>>>>
> > >>>>>>>>> addresses singular instances, but knowing that reality 
> > >>>>>>>>> would allow load balanced clusters at those locations.  
> > >>>>>>>>> But that would be a misleading architectural description 
> > >>>>>>>>> and might be read to outlaw some solutions that fall 
> > >>>>>>>>> within the goal the WG
> > wishes to meet.
> > >>>>>>>>>
> > >>>>>>>>> Yours,
> > >>>>>>>>> Joel
> > >>>>>>>>>
> > >>>>>>>>>>> advance for all deployments. I suggest that SFC 
> > >>>>>>>>>>> forwarding be based
> > >>>>>>> on
> > >>>>>>>>> the
> > >>>>>>>>>>> service function identifiers). This is more compliant 
> > >>>>>>>>>>> with the
> > LB constraints above:
> > >>>>>>>>> deciding

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Jul 2014 16:17:47 -0400

yeah, that's pretty much the way I also understand the concepts.
What I take exception to is the inconsistent terminology.  Specifically, defining an SFP as a list of instances, but then calling something a service path identifier that does not necessarily reference a list of instances.  It feels like there's a level of indirection missing. (fwiw, this inconsistency is not necessarily present in the draft, but has been in this thread).
I have probably read over the merged arch draft way more than is probably healthy.  I have a few comments/questions:
1. I like the phrases:
  "The SFC encapsulation provides explicit information used to identify the SFP"
  and
  "The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation"
  because they allows for the encapsulation to include a path-id or chain-id or whatever it may be (see other drafts).
  It specifically does NOT dictate that the SFP-id or SFC-id be in the encapsulation, only that something in it is used to figure out what to do next. 

2. In 4.3.1, the phrase, "and if needed forwarded to another SF associated with that SFF".     Does this mean the next SF in the chain?  The next sentence says, "If there is another hop" which leads me to ask, What is a hop?  Is it a SF, SFI, or SFF?     Sounds like a hop is an SFF.  Or it the SFF as the "SFC next-hop" for an SF is analagous to the router as the BGP next-hop for a prefix.
3. It seems that the SFP is created on-the-fly as needed by the classifier.  Does this introduce a race condition if the path-id is used in the encapsulation such that the NF and SFF will not be able to perform the lookup until they are informed of this new SFP?
4. Branching.   If "instantiation of the SFC results in the creation of a Service Function Path (SFP)" and if a SF reclassifies and "alters the service path, to SFP B", then does that mean that a new SFP is created on-the-fly?
5. After exhaustively reading and re-reading the definitions, I believe that the definition of SFP in the definitions section is completely inline with the uses in most of the rest of the draft where the SFP is NOT a predetermined specific list of instances, but rather more generally "the instantiation of an SFC".   However, the explanation of SFP in section 2.3 seems to be in restrictive in comparison to the rest of the draft and in conflict with many of the comments in this email thread.

>   When an SFC is instantiated into the network it is necessary to>   select the specific instances of SFs that will be used, and to create   >   the service topology for that SFC using SF's network locator.  Thus,>   instantiation of the SFC results in the creation of a Service>   Function Path (SFP)
To me, this very clearly indicates that it is necessary to choose all SFIs in the chain on instantiation, thus eliminating the possibility of having a more distributed or dynamic distribution to SFIs without branching.
6. Item 4.8.3 (referenced below) seems in conflict with 2.3 (referenced above):

> 4.8. SFC Control Plane
> 3.  Selection of specific SF instances for a requested SFC, either
>     statically (using specific SF instances) or dynamically (using
>     service explicit SF instances at the time of delivering traffic
>     to the SF).(this text is also repeated in the 4.8 leading paragraph)

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>,<[email-masked]>,<[email-masked]>,<[email-masked]>,<[email-masked]>,<[email-masked]>
Sent: Friday, July 11, 2014
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Yours,
Joel

On 7/11/14, 12:25 PM, [email-masked] wrote:
> *
From: [email-masked]<[email-masked]>> *To:> [email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>,[email-masked]'<[email-masked]>> *Sent: *Friday, July 11, 2014> *Subject: *RE: [sfc] Service Chains, Paths, and Load Balancers>> I don’t understand. (I’m sure I’m misunderstanding…)>> Your backend servers could go down, be unreachable or be unable to> server more.>> Route health injection (RHI) is a perfectly fine, accepted, way of> indicating the health of the backend services to the network. You’re not> saying that’s wrong, are you?>> **>> *From:*sfc [mailto:[email-masked]] *On Behalf Of> [email-masked] <mailto:[email-masked]>> *Sent:* 11 July 2014 12:03 PM> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]> <mailto:[email-masked]>; [email-masked]> <mailto:[email-masked]>; [email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>> *Subject:* Re: [sfc] Service Chains, Paths, and Load Balancers>> heh. well, if it did not, then you should not do it like that. e.g. I'm> not going to configure real servers on a server load balancer that are> not reachable. e.g. I'm not going to configure my BGP to announce> prefixes for which I cannot provide connectivity. If you do things like> that, then you are doing it wrong.>>>> ------------------------------------------------------------------------>> *From: [email-masked]<[email-masked]> <mailto:[email-masked][email-masked]>>> *To: *NAPIERALA, MARIA H<[email-masked] <mailto:[email-masked]>>,Joel M.> Halpern<[email-masked] <mailto:[email-masked]>>,Ron> Parker<[email-masked]> <mailto:[email-masked]>>,[email-masked]> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>> *Sent: *Friday, July 11, 2014> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>> Then I misunderstand the proposal ;-) .. However, it seems to me that if> you allow an SFF to make a decision as to which remote SFF it will use for> a given flow to reach the next SF within the chain then you better make> sure that that remote SFF has the necessary forwarding logic to reach the> next-next-SF for the chain as otherwise you are in deep trouble.>> On 7/11/14, 9:48 AM, "NAPIERALA, MARIA H" <[email-masked]> <mailto:[email-masked]>> wrote:>>  >Absolutely not. Service chains can be instantiated only in relevant SFFs>  >when they "arrive".>  >>  >> -----Original Message----->  >>>> From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard>  >>(jguichar)>  >> Sent: Friday, July 11, 2014 9:27 AM>  >> To: Joel M. Halpern; Ron Parker; [email-masked] <mailto:[email-masked]>>  >> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>  >>>  >> Well I think it is even worse than that if I have understood the>  >>proposal>  >> correctly as it would require full knowledge of every single SF within>  >>the>  >> entire SFC domain at every single SFF as there is no way to know a>  >>priori>  >> which SFC¹s a given SFF will need to service at any given point in time.>  >>>  >> On 7/10/14, 11:53 PM, "Joel M. Halpern" <[email-masked]> <mailto:[email-masked]>> wrote:>  >>>  >> >Ron, thinking about this, I realized another major problem with the>  >>your>  >> >proposal as I understand it. (And I readily admit I may not understand>  >> >it.)>  >> >>  >> >The proposal has each SFF serve as the load balancer for the next>  >> >service function that follows it (not the one it delivers to), in every>  >> >service chain that goes through it.>  >> >>  >> >Since it has to be able to work with all services, that means that>  >>every>  >> >SFF would have to be a full, flow sensitive and stateful load balancer.>  >> >I ahve no problem if some SFF are flow sensitive, and / or stateful.>  >> >But having the architecture require that every SFF be a full, flow>  >> >sensitive, stateful, load balancer seems to me to be an acceptable>  >> >imposition.>  >> >>  >> >Yours,>  >> >Joel>  >> >>  >> >On 7/10/14, 10:06 PM, Joel M. Halpern wrote:>  >> >> Part of my personal view is that I am trying to make this work>  >>sensibly>  >> >> in a more orchestrated environment. I expect that the service>  >> >> functions, and over time probably the SFF capabilities, will be>  >> >> orchestrated and installed. I expect the service chains to be>  >>driven by>  >> >> BSS tools that define offerings to clients, and enable self-selection>  >> >> from these. I expect service paths to be heavily policy drive.>  >> >>>  >> >> I can see how to make all of that work in an archtiecture driven by>  >> >> initial classification to described service paths. It is harder to>  >>see>  >> >> how to make it work (but it can be done) when we allow more>  >> dynamicity>  >> >> in the network behavior.>  >> >>>  >> >> Having said that, most of that perspective I described is outside of>  >>the>  >> >> scope of the working group. it is not something we are tasked to>  >>agree>  >> >>on.>  >> >> So I do not claim that vision means we have to do it a certain way.>  >>it>  >> >> is just the perspective that drives my preferences.>  >> >>>  >> >> Yours,>  >> >> Joel>  >> >>>  >> >> On 7/10/14, 9:58 PM, Ian Smith wrote:>  >> >>>> For me, the amount of information about service instances that>  >>needs>  >> >>>>to>  >> >>>> be widely distributed and maintained, potentially even across data>  >> >>>> centers within an administrative scope, is large enough and complex>  >> >>>> enough that trying to get that into each SFF seems like a difficult>  >> >>>> architecture to realize.>  >> >>>>  >> >>> I'm curious as to why that is more complicated than dynamic routing,>  >> >>> hyper-scale data center orchestration, or DNS, all of which are>  >>bigger>  >> >>> problems that have been profitably and stably implemented?>  >> >>>>  >> >>> It also seems that if it really is more complicated, that is a good>  >> >>> sign that it is too complicated.>  >> >>>>  >> >>> ________________________________________>  >> >>> From: Joel M. Halpern [[email-masked]> <mailto:[email-masked]>]>  >> >>> Sent: Thursday, July 10, 2014 9:45 PM>  >> >>> To: Ron Parker; Joel Halpern Direct; [email-masked]> <mailto:[email-masked]>; Ian Smith;>  >> >>> [email-masked] <mailto:[email-masked]>>  >> >>> Subject: Re: [sfc] Service Chains, Paths, and Load Balancers>  >> >>>>  >> >>> This is an architectural issue. And one that I would prefer we>  >> >>>actually>  >> >>> decide, rather than trying to allow all possible implementations.>  >> >>> Because it does have a major effect on the control requirements and>  >> the>  >> >>> functionality of SFFs.>  >> >>>>  >> >>> For me, the amount of information about service instances that needs>  >> to>  >> >>> be widely distributed and maintained, potentially even across data>  >> >>> centers within an administrative scope, is large enough and complex>  >> >>> enough that trying to get that into each SFF seems like a difficult>  >> >>> architecture to realize.>  >> >>>>  >> >>> Yours,>  >> >>> Joel>  >> >>>>  >> >>> But it is a fair question.>  >> >>>>  >> >>> On 7/10/14, 9:38 PM, Ron Parker wrote:>  >> >>>> This is the crux of my issue. Is the end to end selection of>  >> >>>> (top-level) instances performed centrally (perhaps by the>  >>classifier)>  >> >>>> or hop-by-hop (perhaps by the classifier and subsequently the>  >>SFFs)?>  >> >>>> Such selection is not equivalent to reclassification. And surely,>  >> >>>> this is an architectural issue and not relegated to>  >> >>>> "implementation".>  >> >>>>>  >> >>>> My own view is to favor the distributed approach even though a>  >> >>>> greater amount of data (chain definitions and perhaps local>  >>selection>  >> >>>> policy) is required at those distributed decision points. This>  >> >>>> approach does not require an end-to-end path id at all. My>  >> >>>> rationale for favoring this approach is primarily driven by>  >>increased>  >> >>>> resiliency over the global path id approach. With a global path>  >>id>  >> >>>> approach, consider failure of an instance and needing to alter the>  >> >>>> global path ID table for each and every affected end-to-end path.>  >> >>>>>  >> >>>> Ron>  >> >>>>>  >> >>>> ________________________________________ From: sfc>  >> >>>> [[email-masked] <mailto:[email-masked]>] on behalf> of Joel Halpern Direct>  >> >>>> [[email-masked]> <mailto:[email-masked]>] Sent: Thursday, July 10, 2014 6:15 PM>  >> >>>> To: [email-masked] <mailto:[email-masked]>;> [email-masked] <mailto:[email-masked]>; [email-masked]> <mailto:[email-masked]> Subject: Re:>  >> >>>> [sfc] Service Chains, Paths, and Load Balancers>  >> >>>>>  >> >>>> The way the architecture models the case of SF1 needing to>  >>influence>  >> >>>> the chain is that one would do reclassification at the exit from>  >> >>>> SF1.>  >> >>>>>  >> >>>> Part of the goal is to keep the different functions logically>  >> >>>> separate so that solutions can clearly describe how they choose to>  >> >>>> compose them for "service" delivery.>  >> >>>>>  >> >>>> Yours, Joel>  >> >>>>>  >> >>>> On 7/10/14, 6:10 PM, [email-masked]> <mailto:[email-masked]> wrote:>  >> >>>>> I don't see anything in the arch draft that suggests any sort of>  >> >>>>> limit. However, it does seem to indicate that the entire path (all>  >> >>>>> SFIs) must be chosen at SFC instantiation. I believe this means>  >> >>>>> either at the classifier or maybe the classifier chooses a SF>  >>Chain>  >> >>>>> and the NF or at the latest the first SFF. In any case, the>  >> >>>>> language does seem to prohibit a more dynamic SFP where SFI(n) is>  >> >>>>> determined at the SFI(n-1) hop. According to the draft, this>  >> >>>>> behavior would be considered "branching" to a new SFP as opposed>  >> to>  >> >>>>> choosing and then forwarding to the selected instance of the>  >> >>>>> next-hop of the current SFC.>  >> >>>>>>  >> >>>>> draft-merged-sfc-architecture-00:>  >> >>>>>> When an SFC is instantiated into the network it is necessary to>  >> >>>>>> select the specific instances of SFs that will be used, and to>  >> >>>>>> create the service topology for that SFC using SF's network>  >> >>>>>> locator. Thus, instantiation of the SFC results in the creation>  >> >>>>>> of a Service Function Path (SFP) and is used for forwarding>  >> >>>>>> packets through the SFC. In other words, an SFP is the>  >> >>>>>> instantiation of the defined SFC.>  >> >>>>>>>  >> >>>>>> The SFC architecture supports reclassification (or non-initial>  >> >>>>>> classification) as well. As packets traverse an SFP,>  >> >>>>>> reclassification may occur - typically performed by a>  >> >>>>>> classification function co-resident with a service function.>  >> >>>>>> Reclassification may result in the selection of a new SFP, an>  >> >>>>>> update of the associated metadata, or both. This is referred to>  >> >>>>>> as "branching".>  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>>>>>  >>>  >>>>>>>-------------------------------------------------------------------->  >>>>>>>-->  >> >>>>>-->  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>> *From: [email-masked]<[email-masked]> <mailto:[email-masked][email-masked]>>>  >> >>>>> *To: *Joel Halpern Direct<[email-masked]> <mailto:[email-masked]>>,Joel M.>  >> >>>>>>  >> >>>>>Halpern<[email-masked]> <mailto:[email-masked]>>,[email-masked]> <mailto:[email-masked]><huang@sce.> <mailto:huang@sce.%0b>>> carleton.>  >> >>>>>ca>,[email-masked] <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]>>>  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>> *Sent: *Thursday, July 10, 2014>  >> >>>>> *Subject: *Re: [sfc] Service Chains, Paths, and Load Balancers>  >> >>>>>>  >> >>>>> Actually, I think I am disagreeing.>  >> >>>>>>  >> >>>>> If the possibility of medium-scale deployments (and that is what>  >> >>>>> 16 million flows is in my world) of service chains is preconceived>  >> >>>>> as an absurd idea, then the architecture burdened with that>  >> >>>>> preconception.>  >> >>>>>>  >> >>>>> There has to be some point of aim, some degree of aspiration to>  >> >>>>> scale that is appropriate for the lifespan of the architecture ->  >> >>>>> you don't have to know what it is, but by saying that an arbitrary>  >> >>>>> number is "too far", you're creating - even if it isn't>  >>intentional>  >> >>>>> - a limit that influences decisions that have lasting impacts>  >> >>>>> regarding scale-out, failure mitigation, elasticity, address>  >> >>>>> space... all kinds of things. That is a problem I'm not>  >> >>>>> particularly eager to deal with.>  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>>>> ________________________________________>  >> >>>>>>  >> >>>>>>  >> >>>>> From: Joel Halpern Direct [[email-masked]> <mailto:[email-masked]>] Sent:>  >> >>>>> Thursday, July 10, 2014 5:04 PM To: Ian Smith; Joel M. Halpern;>  >> >>>>> [email-masked] <mailto:[email-masked]>;> [email-masked] <mailto:[email-masked]> Subject: Re: [sfc] Service>  >> >>>>> Chains, Paths, and Load Balancers>  >> >>>>>>  >> >>>>> Ian, I don't think you disagree with me at all in this regard. I>  >>am>  >> >>>>> not requesting the the architecture or the solution prohibit>  >> >>>>> deployments in the specific fashion. I am objecting to Huang's>  >> >>>>> reading of my note as saying that such deployments are required>  >> >>>>> they by the archtiecture.>  >> >>>>>>  >> >>>>> As I have said repeatedly, I am not trying to prohibit such>  >> >>>>> things. Whether they are a good idea or not depends upon many>  >> >>>>> factors outside of the scope of the WG. I happen to think that>  >>they>  >> >>>>> are usually a bad idea.>  >> >>>>>>  >> >>>>> But the archtiecture si carefully avoiding attempting to know what>  >> >>>>> is and is not eployable.>  >> >>>>>>  >> >>>>> Yours, Joel>  >> >>>>>>  >> >>>>> On 7/10/14, 5:01 PM, Ian Smith wrote:>  >> >>>>>> I disagree.>  >> >>>>>>>  >> >>>>>> We routinely have stateful devices that manage tens of millions>  >> >>>>>> of>  >> >>>>> concurrent flows in both access network and data center>  >> >>>>> environments today. You can't seriously believe that in the>  >> >>>>> Cloud/IPv6/Mobility/Web2.0/IoT world of tomorrow you are only>  >> going>  >> >>>>> to have small numbers of service chains with equally small numbers>  >> >>>>> of active service paths?>  >> >>>>>>>  >> >>>>>> Your sounds too much like "no one will ever need more than 64K">  >> >>>>>> for>  >> >>>>> comfort.>  >> >>>>>>>  >> >>>>>>>  >> >>>>>> ________________________________________ From: sfc>  >> >>>>>> [[email-masked] <mailto:[email-masked]>] on> behalf of Joel M. Halpern>  >> >>>>> [[email-masked] <mailto:[email-masked]>]>  >> >>>>>> Sent: Thursday, July 10, 2014 4:46 PM To:> [email-masked] <mailto:[email-masked]>;>  >> >>>>>> [email-masked] <mailto:[email-masked]> Subject: Re: [sfc] Service> Chains, Paths, and Load>  >> >>>>>> Balancers>  >> >>>>>>>  >> >>>>>> No, it will mean that if someone tries to deploy the archtieture>  >> >>>>>> particularly badly, they will exceed the limits of their>  >> >>>>>> devices. The architecture does not require such absurd use of>  >> >>>>>> service paths. Since I can not figure out how to write>  >> >>>>>> architectural words to prohibit it, the architecture does permit>  >> >>>>>> such abuse.>  >> >>>>>>>  >> >>>>>> Please do not read my saying that the archtiecture permits>  >> >>>>>> something as saying it is either deisred or required by the work.>  >> >>>>>> It isn't.>  >> >>>>>>>  >> >>>>>> Yours, Joel>  >> >>>>>>>  >> >>>>>> On 7/10/14, 4:36 PM, Changcheng Huang wrote:>  >> >>>>>>> If you need to support 100 service chains, it will mean>  >> >>>>>>> 16,000,000 paths. That is larger than the routing table of a>  >> >>>>>>> core router.>  >> >>>>>>>>  >> >>>>>>> Chang>  >> >>>>>>>>  >> >>>>>>> On 07/10/2014 01:15 PM, Joel M. Halpern wrote:>  >> >>>>>>>> The architecture allows a range of deployments, from 1>  >> >>>>>>>> service path to 160000 service paths. I would hope that>  >> >>>>>>>> operators are prepared for the complexities if they choose to>  >> >>>>>>>> avoid any use of local load balancing and in stead provision>  >> >>>>>>>> 160,000 service paths.>  >> >>>>>>>>>  >> >>>>>>>> Yours, Joel>  >> >>>>>>>>>  >> >>>>>>>> On 7/10/14, 4:06 PM, NAPIERALA, MARIA H wrote:>  >> >>>>>>>>> Paul,>  >> >>>>>>>>>>  >> >>>>>>>>> How many path identifiers there will be for a 4 hop service>  >> >>>>>>>>> chain with 20 instances at each hop?>  >> >>>>>>>>>>  >> >>>>>>>>> Maria>  >> >>>>>>>>>>  >> >>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of>  >> >>>>>>>>> *Paul Quinn (paulq) *Sent:* Thursday, July 10, 2014 3:03>  >> >>>>>>>>> PM *To:* Lucy yong *Cc:* [email-masked]> <mailto:[email-masked]>;>  >> >>>>>>>>> [email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;>  >> >>>>>>>>> [email-masked] <mailto:[email-masked]> *Subject:*> Re: [sfc] Service Chains,>  >> >>>>>>>>> Paths, and Load Balancers>  >> >>>>>>>>>>  >> >>>>>>>>> Lucy,>  >> >>>>>>>>>>  >> >>>>>>>>> Overall I concur, as you say: a path ID drives the>  >> >>>>>>>>> forwarding. I¹d>  >> >>>>> make>  >> >>>>>>>>> the minor change: the path identifier can be used to derive>  >> >>>>>>>>> the needed forwarding and associated transport.>  >> >>>>>>>>>>  >> >>>>>>>>> It is _not_ the transport, but rather is used to simply>  >> >>>>>>>>> identify the service path (or graph) that packets must>  >> >>>>>>>>> traverse. By having a path identifier, the exact>  >> >>>>>>>>> indirection that people seem to be asking for on this>  >> >>>>>>>>> thread can be simply be implemented. The path identifier>  >> >>>>>>>>> provides nothing more than a lookup, that lookup can result>  >> >>>>>>>>> in a one or more (equal or weighted) transport next>  >> >>>>>>>>> hop(s).>  >> >>>>>>>>>>  >> >>>>>>>>> Paul>  >> >>>>>>>>>>  >> >>>>>>>>> On Jul 10, 2014, at 11:04 AM, Lucy yong>  >> >>>>>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]%20%3cmailto:[email-masked]>>>>  >> >>>>>>>>> wrote:>  >> >>>>>>>>>>  >> >>>>>>>>>>  >> >>>>>>>>>>  >> >>>>>>>>> Agree. The arch. doc should not mandate only use of the>  >> >>>>>>>>> service path identifier to drive the forwarding actions.>  >> >>>>>>>>>>  >> >>>>>>>>> Lucy>  >> >>>>>>>>>>  >> >>>>>>>>> *From:*sfc [mailto:[email-masked]]*On Behalf>  >> >>>>>>>>> [email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]> *Sent:*Thursday,>  >> July>  >> >>>>>>>>> 10, 2014 2:06 AM *To:[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]> *Subject:*Re: [sfc] Service Chains,>  >> >>>>>>>>> Paths, and Load Balancers>  >> >>>>>>>>>>  >> >>>>>>>>> Re-,>  >> >>>>>>>>>>  >> >>>>>>>>> The merged draft calls out explicitly a service path>  >> >>>>>>>>> identifier. I object to use that identifier to derive>  >> >>>>>>>>> forwarding actions.>  >> >>>>>>>>>>  >> >>>>>>>>> Requiring a SFC system to have the full knowledge of every>  >> >>>>> available SFC>  >> >>>>>>>>> forwarding paths within an SFC-enabled domain is not>  >> >>>>> required/justified>  >> >>>>>>>>> nor possible in various deployment contexts.>  >> >>>>>>>>>>  >> >>>>>>>>> SFC forwarding actions should rely on the piece of>  >> >>>>>>>>> information>  >> >>>>> that will>  >> >>>>>>>>> be present in all deployments: that is the one required to>  >> >>>>>>>>> structure a service chain. How that information is used to>  >> >>>>>>>>> infer forwarding>  >> >>>>> actions>  >> >>>>>>>>> is a solution-oriented discussion.>  >> >>>>>>>>>>  >> >>>>>>>>> Cheers,>  >> >>>>>>>>>>  >> >>>>>>>>> Med>  >> >>>>>>>>>>  >> >>>>>>>>> *De :*sfc [mailto:[email-masked]]*De la part>  >> >>>>> [email-masked] <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]> *Envoyé :*mercredi 9 juillet>  >> >>>>>>>>> 2014 22:03 *À :[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]>;[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> <mailto:[email-masked]> *Objet :*Re: [sfc] Service Chains,>  >> >>>>>>>>> Paths, and Load Balancers>  >> >>>>>>>>>>  >> >>>>>>>>> Is anyone still questioning the difference between SF Chain>  >> >>>>>>>>> and SF>  >> >>>>> Path?>  >> >>>>>>>>> Other than clarifying the definition so that it's clear to>  >> >>>>> those not>  >> >>>>>>>>> familiar with the draft, it seems that everyone agrees on>  >> >>>>>>>>> these terms.>  >> >>>>>>>>>>  >> >>>>>>>>> To me, the one point that is still unclear is whether it is>  >> >>>>>>>>> the intent of this draft to ultimately specify what the ID>  >> >>>>>>>>> of the SFC Header>  >> >>>>> should>  >> >>>>>>>>> reference (the chain or the path), or if this draft simply>  >> >>>>>>>>> intends to leave that ambiguous, allowing other drafts to>  >> >>>>>>>>> dictate the mechanisms for forwarding based on chain or>  >> >>>>>>>>> path and the choice of chain or>  >> >>>>> path to>  >> >>>>>>>>> be negotiated in the control-plane.>  >> >>>>>>>>>>  >> >>>>>>>>> If the latter (ambiguous), then the draft would have>  >> >>>>>>>>> require that both SFP and SFC be supported (or make one>  >> >>>>>>>>> required and the other optional) to avoid some vendors only>  >> >>>>>>>>> supporting SFP and others only supporting SFC.>  >> >>>>>>>>>>  >> >>>>>>>>>>  >> >>>>>>  >>>  >>>>>>>-------------------------------------------------------------------->  >>>>>>>-->  >> >>>>>-->  >> >>>>>>  >> >>>>>>  >> >>>>>>  >> >>>>>>>>  >> >>>>>>>>> *From:[email-masked]> <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]%0b>>> >>>>>>>>>> <mailto:[email-masked][email-masked]>>>  >> >>>>>>>>> *To:[email-masked] <mailto:[email-masked]><[email-masked]> <mailto:[email-masked]%0b>>> >>>>>>>>>> <mailto:[email-masked][email-masked]>> *Sent:*Tuesday, July>  >> >>>>>>>>> 8, 2014 *Subject:*[sfc] Service Chains, Paths, and Load>  >> >>>>>>>>> Balancers>  >> >>>>>>>>>>  >> >>>>>>>>> I have been trying to figure out how to clearly answer a>  >> >>>>>>>>> number of comments that have been made about the proposed>  >> >>>>>>>>> merged archtiecture draft. Assuming we can get working>  >> >>>>>>>>> group agreement on the intent, we will work to improve the>  >> >>>>>>>>> wording so that readers who have not participated in the WG>  >> >>>>>>>>> discussion will understnd it the way the>  >> >>>>> working>  >> >>>>>>>>> group intends.>  >> >>>>>>>>>>  >> >>>>>>>>> But what do we intend? I will try to explain my personal>  >> >>>>>>>>> view, and see if that helps.>  >> >>>>>>>>>>  >> >>>>>>>>> In this regard, it is important to keep in mind that what>  >> >>>>>>>>> we are defining is the data plane architecture. We are not>  >> >>>>>>>>> attempting to define the architecture for the entire>  >> >>>>>>>>> solution for service chaining. That would encompass>  >> >>>>>>>>> OSS/BSS, various control and policy functions, virtual>  >> >>>>>>>>> machine and image management, and many other aspects.>  >> >>>>>>>>>>  >> >>>>>>>>> As a result there are many things which clearly need to>  >> >>>>>>>>> exist in the larger system, but which are dealt with above>  >> >>>>>>>>> where we are>  >> >>>>> functioning,>  >> >>>>>>>>> and are not directly required by the work we are doing.>  >> >>>>>>>>>>  >> >>>>>>>>> In order to get to service chain vs service path, as I>  >> >>>>>>>>> understand>  >> >>>>> them,>  >> >>>>>>>>> I need to first discuss load balancing. There are at least>  >> >>>>>>>>> three different ways that load balancing can and will>  >> >>>>>>>>> interact with service chaining. There probably are more.>  >> >>>>>>>>> The point of the archtiecture is to permit all of these,>  >> >>>>>>>>> but not to mandate that any particular kind>  >> >>>>> be used>  >> >>>>>>>>> in any solution.>  >> >>>>>>>>>>  >> >>>>>>>>> 1) Load balancing as a service provided to the end user.>  >> >>>>>>>>> This is a service function. It receives user packets, and>  >> >>>>>>>>> modifies them (or>  >> >>>>> marks>  >> >>>>>>>>> them, or ...) so as to choose an end user service instance>  >> >>>>>>>>> to receive the users packet. This is an important service>  >> >>>>>>>>> function to be able to include in service chaining. It's>  >> >>>>>>>>> behavior may affect requirements on how service chaining is>  >> >>>>>>>>> done. But it has very little impact on the archtiecture.>  >> >>>>>>>>> From an architectural pe3rspective it is simply a>  >> >>>>> service>  >> >>>>>>>>> function which may modify the underlying packet.>  >> >>>>>>>>>>  >> >>>>>>>>> 2) There is internal load balancing. That is, one can have>  >> >>>>>>>>> what>  >> >>>>> appears>  >> >>>>>>>>> to the service chaining architecture as a single point of>  >> >>>>>>>>> contact>  >> >>>>> for a>  >> >>>>>>>>> specific service function, but is actually delivered by a>  >> >>>>> collection of>  >> >>>>>>>>> virtual or physical machines, possibly including one or>  >> >>>>>>>>> several load balancers (for example using VRRP-like>  >> >>>>>>>>> techniques to share a MAC address.) mostly, this is>  >> >>>>>>>>> invisible to the service chaining data plane mechanisms. It>  >> >>>>>>>>> is likely that it is visible to various control mechanisms,>  >> >>>>>>>>> such as those responsible for scale-in, scale-out, and vm>  >> >>>>>>>>> instantiation. The architectural impact of permitting this>  >> >>>>>>>>> is largely that we need to be careful that our terminology>  >> >>>>>>>>> does not lead>  >> >>>>> readers to>  >> >>>>>>>>> think we are prohibiting it.>  >> >>>>>>>>>>  >> >>>>>>>>> 3) There can also be load balancing done by selecting>  >> >>>>>>>>> packet paths for the service chaining that direct traffic>  >> >>>>>>>>> to different places. We would not want to require that a>  >> >>>>>>>>> given service function appear at only one place in the>  >> >>>>>>>>> network.>  >> >>>>>>>>>>  >> >>>>>>>>> It is of course the case that these may be combined. I tend>  >> >>>>>>>>> to>  >> >>>>> refer to>  >> >>>>>>>>> the collection of entities that appear to service chaining>  >> >>>>>>>>> as a single point as a cluster. Not because cluster is a>  >> >>>>>>>>> good term. But because I do not have another one. Thus, the>  >> >>>>>>>>> point of type 3 load balancing>  >> >>>>> is to>  >> >>>>>>>>> direct different subsets of traffic to different singular>  >> >>>>>>>>> or clustered service functions in different places in the>  >> >>>>>>>>> network.>  >> >>>>>>>>>>  >> >>>>>>>>> Now with that said, what do I mean when I talk about>  >> >>>>>>>>> service chain and service path/ Service chain is a sequence>  >> >>>>>>>>> of logical functions to be applied to a subset of packets.>  >> >>>>>>>>> It is equivalent of saying that some subset of traffic is>  >> >>>>>>>>> to get DPI, charging, content inspection, and firewall>  >> >>>>>>>>> while a different subset is to go directly to the cache>  >> >>>>> without>  >> >>>>>>>>> visiting any other service functions.>  >> >>>>>>>>>>  >> >>>>>>>>> That is not enough information to direct the packets. A>  >> >>>>>>>>> service path is, in some fashion, a sequence of locations>  >> >>>>>>>>> in the network. Those locations will be singular or>  >> >>>>>>>>> clustered service function delivery locations. They may be>  >> >>>>>>>>> addressed by IP address. They may be addressed as ports on>  >> >>>>>>>>> an SFF. There are many different ways that the locations>  >> >>>>>>>>> may be known to the service chaining infrastructure and the>  >> >>>>>>>>> transport.>  >> >>>>>>>>>>  >> >>>>>>>>>> From the point of view of the work of the SFC group, we>  >> >>>>>>>>>> need to be>  >> >>>>>>>>> able to talk about the high level abstraction, the service>  >> >>>>>>>>> chain, which drives the forwarding. And we need to talk>  >> >>>>>>>>> about the actual data path packets will take in the>  >> >>>>>>>>> network.>  >> >>>>>>>>>>  >> >>>>>>>>> Several of the comments have said "but the whole path may>  >> >>>>>>>>> not be known at the front." This architecture deals with>  >> >>>>>>>>> that issue in two ways. First, as noted in item (2) on load>  >> >>>>>>>>> balancers above, there can be decisions and behaviors which>  >> >>>>>>>>> are invisible to the service chaining mechanisms (in much>  >> >>>>>>>>> the same way that bridging within a LAN is largely>  >> >>>>>>>>> invisible to routing between LANs.) The other provision we>  >> >>>>>>>>> make is>  >> >>>>> that>  >> >>>>>>>>> reclassification can be done in mid-chain when necessary.>  >> >>>>>>>>> That will direct packets to a new chain. Based on>  >> >>>>>>>>> information available at the re-classification point.>  >> >>>>>>>>>>  >> >>>>>>>>> I hope that this helps explain what we are after. If it>  >> >>>>>>>>> does, and if the intent is acceptable to the working group,>  >> >>>>>>>>> we can figure out what additional words are needed to>  >> >>>>>>>>> convey this. If the working group disagree with the intent,>  >> >>>>>>>>> then we will of course adjust to match the working group>  >> >>>>>>>>> agreements. If this is still unclear, I am not sure what to>  >> >>>>>>>>> try next.>  >> >>>>>>>>>>  >> >>>>>>>>> Yours, Joel>  >> >>>>>>>>>>  >> >>>>>>>>> _______________________________________________ sfc>  >> mailing>  >> >>>>>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>>>>>>  >> >>>>>>>>> _______________________________________________ sfc>  >> mailing>  >> >>>>>>>>> list [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>  >> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>>>>>>  >> >>>>>>>>>  >> >>>>>>>> _______________________________________________ sfc>  >> mailing>  >> >>>>>>>> list [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>>>>>  >> >>>>>>>>  >> >>>>>>> _______________________________________________ sfc>  >> mailing>  >> >>>>>>> list [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>>>>  >> >>>>>>>  >> >>>>>> _______________________________________________ sfc mailing>  >> list>  >> >>>>>> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>>>  >> >>>>>>  >> >>>>> _______________________________________________ sfc mailing>  >> list>  >> >>>>> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>  >> >>>> _______________________________________________ sfc mailing>  >> list>  >> >>>> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>  >> >>>> _______________________________________________ sfc mailing>  >> list>  >> >>>> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>>>  >> >>>>  >> >>>  >> >> _______________________________________________>  >> >> sfc mailing list>  >> >> [email-masked] <mailto:[email-masked]>>  >> >> https://www.ietf.org/mailman/listinfo/sfc>  >> >>>  >> >>  >> >_______________________________________________>  >> >sfc mailing list>  >> >[email-masked] <mailto:[email-masked]>>  >> >https://www.ietf.org/mailman/listinfo/sfc>  >>>  >> _______________________________________________>  >> sfc mailing list>  >> [email-masked] <mailto:[email-masked]>>  >> https://www.ietf.org/mailman/listinfo/sfc>> _______________________________________________> sfc mailing list> [email-masked] <mailto:[email-masked]>> https://www.ietf.org/mailman/listinfo/sfc>>>> _______________________________________________> sfc mailing list> [email-masked]> https://www.ietf.org/mailman/listinfo/sfc>

---

From: Sharon <[email-masked]>
Date: Fri, 11 Jul 2014 18:35:34 -0700

Looks like it's almost there, no?

If each SFF behaves like a typical load-balancer for the SFs it aggregates, then all is left is for the architecture to emerge these SFFs as one distributed system:

- classify and map the flow to the right subscriber-serviceChain

- map the chain links to the SFFs signed up to execute an SF hop

- carry the context and work flow  as meta data between SFFs

Such a system unbundles proprietary service nodes for virtualized environments both in terms of capacity and in term of the functional procedures. No centralized static setup needed.

The way I read the docs it's almost there.

--szb

> On Jul 11, 2014, at 12:27 PM, Eric Gray <[email-masked]> wrote:
> 
> Maria,
>

---

From: Ron Parker <[email-masked]>
Date: Sat, 12 Jul 2014 14:15:23 +0000

Sharon,

One more item I'd add -- load balance amongst the SFFs in an overall hierarchical solution.   This gives us the hierarchical load balancing and resiliency that has been discussed on the thread.   For example, a chain has abstract service functions {A, B, C} and 2 distinct SFFs reach some number of A instances, each, 2 distinct SFFs reach some number of B instances, each, etc.    Let's further say that one of the SFF's that reaches instances of A sees that the last of its A instances has gone down.   The top-level load balancing must now avoid that SFF for purposes of invoking service function A (i.e., with different procedures, potentially for existing flows vs new flows).   Additionally, it may be beneficial for those SFF's to communicate information back to the top level path selection logic (i.e., classifier) with information that can be used for weighted load balancing.

   Ron

________________________________________
From: Sharon [[email-masked]]
Sent: Friday, July 11, 2014 9:35 PM
To: Eric Gray
Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halpern; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

--szb

---

From: Ron Parker <[email-masked]>
Date: Sat, 12 Jul 2014 14:27:52 +0000

Hi, Lucy.

I've heard next hop mentioned many times and I'm not sure that the term is really valid here.   There seems to be an assumption that routing is implicitly involved, but it is possible that the service overlay resides on a purely switched infrastructure.   Even if the service overlay resides on a routed infrastructure, that routing is abstracted in the typical layered fashion.   For SFC, the issue is to select the next SFF or select the next SFI.   Once that selection is made, routing takes over.   But knowing that SFF-B could serve as a backup to SFF-A is above the routing layer (or at least could be in some implementations).   Perhaps we could introduce a term like next-service-hop or next-SFC-hop to make this distinction?

   Ron

________________________________________
From: sfc [[email-masked]] on behalf of Lucy yong [[email-masked]]
Sent: Friday, July 11, 2014 1:23 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Lucy

---

From: Ian Smith <[email-masked]>
Date: Sat, 12 Jul 2014 15:59:33 +0000

I'd call the distinction you are making that between infrastructure load balancing (where SFFs or SNFs are the LB targets) and instance load balancing (where SFIs are the LB targets)

________________________________________
From: sfc [[email-masked]] on behalf of Ron Parker [[email-masked]]
Sent: Saturday, July 12, 2014 10:15 AM
To: Sharon; Eric Gray
Cc: Jim Guichard (jguichar); Joel M. Halpern; [email-masked]; [email-masked]; NAPIERALA, MARIA H
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Sharon,

   Ron

--szb

---

From: Sharon <[email-masked]>
Date: Sat, 12 Jul 2014 09:08:26 -0700

Agree 100% Ron. Thanks for that.
And to achieve that we need to assume there's a way to expose and act upon these KPIs globally.
So this can be by orchestration, or by a key-value store in the underlay. These specifics can be left out or referenced, depends on the authors wishes. The global architecture and desired mode of operation will be clear and open-interoperable. 

--szb

> On Jul 12, 2014, at 7:15 AM, Ron Parker <[email-masked]> wrote:
> 
> Sharon,
>

---

From: Ron Parker <[email-masked]>
Date: Sat, 12 Jul 2014 17:43:52 +0000

Ian,

I'm viewing the service overlay (i.e, SFC) as a distinct overlay layer.    It may reside on top of an IP-tunnel based overlay (i.e., commonly used definition of "SDN") or may reside directly on top of an L2 switched network or may reside directly on top of an L3 routed network or any combination of those.    Therefore, when a classifier selects an SFF or an SFF selects the next SFF, or an SFF selects an SFI, it is doing so in the service overlay, only.   That is why I find it confusing to describe the selected SFF or SFI as the "next-hop" because that term has such a strong L3 routing plane semantic.

    Ron

From: Ian Smith [[email-masked]]
Sent: Saturday, July 12, 2014 11:59 AM
To: Ron Parker; Sharon; Eric Gray
Cc: Jim Guichard (jguichar); Joel M. Halpern; [email-masked]; [email-masked]; NAPIERALA, MARIA H
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Sharon,

   Ron

--szb

---

From: Ian Smith <[email-masked]>
Date: Sat, 12 Jul 2014 18:43:15 +0000

Hmmm...   That seems to me to be to be excessively fusing over language.

I think of 'next hop' as the nomenclature in any network where there is, literally, a next hop decision.  In common usage of their respective communities of expertise there are Ethernet next hops, IP next hops, service next hops, and application next hops; it is contextual and no particular context owns it, as I'm sure the aviation and circuit radio and mathematics communities would happily argue.

In an overlay network context you are unaware of the underlay so just as the Ethernet hops are transparent to an IP ping and the IPv4 hops are transparent to my he.net tunnel broker IPv6 connections, the hypothetical 'SFC ping' is going to ignore the underlay network and only show the SFIs in the specified service function path.

But the actual point I was trying to make is that there is a consistent semantic difference between 'selecting a decider' which is what you do if you make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an actor' which is what you do when you make a next hop selection amongst SFIs, and you should differentiate between them.

On Jul 12, 2014 1:43 PM, Ron Parker <[email-masked]> wrote:
Ian,

    Ron

Sharon,

   Ron

--szb

---

From: Ron Parker <[email-masked]>
Date: Sat, 12 Jul 2014 18:47:30 +0000

I see your point.   But even selecting an actor (SFI) could, itself be an abstraction as in the "clustered SFI".  The perceived SFI, at the service overlay layer, could in actuality be another load balancing stage in-built to the cluster's functionality, thereby selecting the ultimate actor.

   Ron

________________________________
From: Ian Smith [[email-masked]]
Sent: Saturday, July 12, 2014 2:43 PM
To: Ron Parker
Cc: NAPIERALA, MARIA H; Sharon; Eric Gray; [email-masked]; [email-masked]; Joel M. Halpern; Jim Guichard (jguichar)
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

    Ron

Sharon,

   Ron

--szb

---

From: Ian Smith <[email-masked]>
Date: Sat, 12 Jul 2014 19:52:17 +0000

Perhaps, although as a practical matter, I probably would not embed a load balancer into an SFI - either the load balancers _is_ and SFI, and it makes a selection of opaque resources; or it is an SFI, and it makes a selection of other SFIs; or it is an SFF.  In most cases the difference between the first and the last is strictly semantic because the outcome is the same - the SFP includes only the SF* that is a virtual server abstracting a destination for a pool of resources.

________________________________
From: Ron Parker [[email-masked]]
Sent: Saturday, July 12, 2014 2:47 PM
To: Ian Smith
Cc: NAPIERALA, MARIA H; Sharon; Eric Gray; [email-masked]; [email-masked]; Joel M. Halpern; Jim Guichard (jguichar)
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

   Ron

    Ron

Sharon,

   Ron

--szb

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 14 Jul 2014 03:29:53 +0000

Agree that the current definition of the SFP in the arch draft is a bit confusing, just as what you had pointed out.

In my understanding, the SFP as an instantiation of an SFC in the network should be “an ordered list of service nodes and SF IDs”(see http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01). Of course, how to represent the SFP in the data packet is another thing (e.g., either through a path id or through an MPLS label stack). Here the service node means the device which contains the SFF and the NF components mandatorily while containing the SF and SF proxy components optionally. The service node could be attached or embedded with multiple SF instances and those SF instances could be of the same SF type or not.  In the case where there are multiple SF instances of the same SF type (e.g., SF X) are attached to a given service node, the service node could distribute the traffic which needs SF X among those SF instances of SF X type locally. Meanwhile, there may be multiple service nodes within a given SFC-enabled domain which are embedded or attached with the SF instances of the same SF type. In this way, the SF load-balancing would be made very flexible.

Best regards,

Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, July 12, 2014 2:46 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

To: [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]<mailto:[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]>>

Maria,

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Jul 2014 04:26:33 +0000

Exactly, it should be ”service chain identifier”.

发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年7月12日 2:46
收件人: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria,

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 14 Jul 2014 06:29:11 +0000

Well stated. Architecturally, it (SFC vs. SFP) is a very good abstraction
to bake in.

In the simplest case, an SFC may map 1:1 to an SFP and that is fine.
However, this should not limit implementation flexibility that can be had
by providing a level of indirection between SFC and SFP.  Implementations
can then exploit this indirection to suit the use cases while conforming
to the architecture.

As a *simplistic* example, a given service chain may be instantiated with
a different SFP at each classifier (assume there is no SFP explosion).
This serves to identify where classification was performed or where SFC is
originated. Similar effect can be achieved in other ways as well but
implementations are provided a choice.

Surendra.

On 7/11/14 9:20 AM, "Joel M. Halpern" <[email-masked]> wrote:

>> I have a hard time understanding why an SFF will not have ability to
>>resolve an SFC to the set of next SFFs. Then what kind of "forwarder" is
>>it if it cannot deal with next-hops.
>> Second, if we do it as you suggest, what is the definition of a service
>>path and why it is even needed? For me a service path is more of an
>>abstract concept that is meant to denote one actual path (among many)
>>that a service chain traffic will take.
>>
>> Maria
>>
>>
>>>> This could be per-destination load balancing, for example, to get a
>>>>better
>>> load distribution.
>>>>

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 12:47:10 +0000

Xiaohu,

The meaning of the SFP ID is pretty clear, at least to me – an abstract identity for the exact set of service function instances (i.e., SFP ID 1 = {SF-A-1, SF-B-3, SF-C-2}).    In some ways, it is a collapsed “label stack” – there is a single tag implying some sequence of network locations.   But, this also implies, at least to me, that there is a central point of selection for this end to end sequence (barring reclassification, of course).   I, for one, am questioning that implication.    I have been uncomfortable with that central point methodology due to real-world complexities of dynamic scale and timeliness of reaction to failures.

An alternative approach is to still use central selection to select the chain of abstract service functions (i.e., SFC ID 1 = {SF-A, SF-B, SF-C}), but allow the actual instance selection to be distributed, realized by the classifier and the SFFs.

Given a topology like:

Classifier -------  SFF-1 -------------------- SFF-2 -------------------- SFF-3-------------------SFF-4
                                 |       |                                  |       |                                   |        |                               |
                    SFF-A-1       SFF-A-2       SSF-B-1        SFF-B-2         SFF-C-1       SFF-C-2                   SFF-A-3

And assuming a newly recognized flow, the sequence could go something like this:

1 Classifier selects chain SFC ID 1 {SF-A, SF-B, SF-C}
2 Classifier selects SFF-1 as hosting at least one instance of SF-A
3 Classifier encapsulates packet indicating chain ID = 1, service index = 1
4 Classifier progresses packet to SFF-1
5 SFF-1, seeing chain ID=1, service index=1, chooses SFF-A-2 amongst its available instances of SF-A
6 SFF-1 sends packet to SFF-A-1
7 SFF-A-1 sends packet back to SFF-1
8 SFF-1 increments service index to 2
8 SFF-1 selects SFF-2 as hosting at least one instance of SF-B
9 SFF-1 progresses packet to SFF-2
10 process repeats per above until SFF-3, as the egress border, progresses the packet per routing table

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, July 13, 2014 11:30 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ron Parker; [email-masked]
Subject: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Best regards,

Xiaohu

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Saturday, July 12, 2014 2:46 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Maria,

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Jul 2014 13:12:35 +0000

Hi Ron,

Agree, when there are multiple founded next hops (after lookup), use of a LB to select one of the next hops may occur in the two cases mentioned below. 

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Saturday, July 12, 2014 9:28 AM
To: Lucy yong; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Hi, Lucy.

   Ron

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, July 11, 2014 11:44 AM
To: NAPIERALA, MARIA H; [email-masked]; Joel M. Halpern; Ron Parker; [email-masked]
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

I am not proposing a solution (that's the WG's job) but simply using my interpretation of the architecture to move the discussion forward.

On 7/11/14, 12:37 PM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

>> Jim> that's why I said *might* - IOW you do not have to, its a
>>deployment
>> >> >> I'm sorry but I really don't understand why a service path
>>identifier
>> >>SFF's

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 13:20:44 +0000

<Maria> I agree. It should not be mandated by the SFC architecture that something called “service function path ID” is carried in the packet, because it is not necessary or the only way to implement service chaining. There might solutions that would do that but it cannot and doesn’t need to be mandated.

Maria

Given a topology like:

Thanks.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, July 13, 2014 11:30 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ron Parker; [email-masked]<mailto:[email-masked]>
Subject: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Best regards,

Xiaohu

Maria,

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Jul 2014 13:30:48 +0000

Conquer what Maria says.

Lucy

From: sfc [mailto:[email-masked]] On Behalf Of NAPIERALA, MARIA H
Sent: Monday, July 14, 2014 8:21 AM
To: Ron Parker; Xuxiaohu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Maria

Given a topology like:

Thanks.

   Ron

Best regards,

Xiaohu

Maria,

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 14 Jul 2014 10:39:01 -0400

Can we first figure out what we mean by a service path?
Once we have that, I believe we can work out what we want the 
architecture to require of solutions in terms of carrying information in 
the packet.  But since folks have been reading the existing definitions 
and coming to different meanings, and have been noting correctly 
contradictions in the words we chose for the existing definition, I 
would really appreciated it if folks would comment on the definition of 
service function path that I sent to the list.

Yours,
Joel

On 7/14/14, 9:30 AM, Lucy yong wrote:
> Conquer what Maria says.
>
> Lucy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *NAPIERALA, MARIA H
> *Sent:* Monday, July 14, 2014 8:21 AM
> *To:* Ron Parker; Xuxiaohu; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and
> Load Balancers
>
> The meaning of the SFP ID is pretty clear, at least to me – an abstract
> identity for the exact set of service function instances (i.e., SFP ID 1
> = {SF-A-1, SF-B-3, SF-C-2}).    In some ways, it is a collapsed “label
> stack” – there is a single tag implying some sequence of network
> locations.   But, this also implies, at least to me, that there is a
> central point of selection for this end to end sequence (barring
> reclassification, of course).   I, for one, am questioning that
> implication.    I have been uncomfortable with that central point
> methodology due to real-world complexities of dynamic scale and
> timeliness of reaction to failures.
>
> <Maria> I agree. It should not be mandated by the SFC architecture that
> something called “service function path ID” is carried in the packet,
> because it is not necessary or the only way to implement service
> chaining. There might solutions that would do that but it cannot and
> doesn’t need to be mandated.
>
> Maria
>
> An alternative approach is to still use central selection to select the
> chain of abstract service functions (i.e., SFC ID 1 = {SF-A, SF-B,
> SF-C}), but allow the actual instance selection to be distributed,
> realized by the classifier and the SFFs.
>
> Given a topology like:
>
> Classifier -------  SFF-1 -------------------- SFF-2
> -------------------- SFF-3-------------------SFF-4
>
>                                   |       |
>              |       |                                   |
> |                               |
>
>                      SFF-A-1       SFF-A-2       SSF-B-1
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Xuxiaohu
> *Sent:* Sunday, July 13, 2014 11:30 PM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>; Ron Parker;
> *Subject:* [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load
> Balancers
>
> In my understanding, the SFP as an instantiation of an SFC in the network should be “an ordered list of service nodes and SF IDs”(see  http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01). Of course, how to represent the SFP in the data packet is another thing (e.g., either through a path id or through an MPLS label stack). Here the service node means the device which contains the SFF and the NF components mandatorily while containing the SF and SF proxy components optionally. The service node could be attached or embedded with multiple SF instances and those SF instances could be of the same SF type or not.  In the case where there are multiple SF instances of the same SF type (e.g., SF X) are attached to a given service node, the service node could distribute the traffic which needs SF X among those SF instances of SF X type locally. Meanwhile, there may be multiple service nodes within a given SFC-enabled domain which are embedded or attached with the SF
  instance
s of the same SF type. In this way, the SF load-balancing would be made very flexible.
> *Sent:* Saturday, July 12, 2014 2:46 AM
> <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>; [email-masked]
> [email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]
> <mailto:[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]%3e,[email-masked][email-masked]>>
> *From: *"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *Date: *Friday, July 11, 2014 at 12:18 PM
> *To: *Jim Guichard <[email-masked] <mailto:[email-masked]>>,
>  >> To: NAPIERALA, MARIA H; [email-masked]
> <mailto:[email-masked]>; Joel M.
>  >> Halpern; Ron Parker; [email-masked] <mailto:[email-masked]>
>  >> >> Parker; [email-masked] <mailto:[email-masked]>
> <[email-masked] <mailto:[email-masked]>>
>  >> >> wrote:
>  >> >> >>> >>
>  >> >> >>> >> >>>> [[email-masked] <mailto:[email-masked]>]
> on behalf of Joel Halpern Direct
> <mailto:[email-masked]>] Sent: Thursday, July 10,
>  >>2014
>  >> >> 6:15
>  >> >> >>> PM
> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>  >> Subject:
>  >> >> Re:
>  >> >> >>> >> >>> *From: [email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>>
>  >> >> >>> >> >>>>> *To: *Joel Halpern
>  >> Direct<[email-masked]
>  >> >> >>> >> >>>>> From: Joel Halpern Direct
>  >> >> >>> >> >>>>> [email-masked]
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> Subject: Re: [sfc]
>  >> >>Service
>  >> >> >>> >> >>>>>> [[email-masked]
> <mailto:[email-masked]>] on behalf of Joel M. Halpern
> *Subject:* Re: [sfc] Service
>  >> Chains,
>  >> >> <mailto:[email-masked]> <mailto:[email-masked]%3e>>
>  >> >> >>> >> >>>>>>>>> wrote:
>  >> >> >>> >> >>>>>>>>>
>  >> >> >>> >> >>>>>>>>>
>  >> >> >>> >> >>>>>>>>>
> <mailto:[email-masked]>
> <mailto:[email-masked]%3e;[email-masked]>
> <mailto:[email-masked]%3e;[email-masked]>
> <mailto:[email-masked]>
> <mailto:[email-masked]%3e;[email-masked]>
> <mailto:[email-masked]><[email-masked]
>  >> >> <mailto:[email-masked][email-masked]>
> <mailto:[email-masked][email-masked]%3e>>
>  >> >> >>> >> >>>>>>>>> *To:[email-masked]
> <mailto:[email-masked]><[email-masked] <mailto:[email-masked]>

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 15:00:01 +0000

Hi, Joel,

I quote from the the merged architecture draft:

<begin quotation>

(Section 4.3 SFF)
SFP forwarding information is associated with a service path identifier
   that is used to uniquely identify an SFP.  
<end quotation>

My reading of the Section 4.3, given the definitions presented before it, is that an end-to-end fully instantiated path is selected and then used to steer traffic to the requisite SFF's and SF's.   While those definitions could still apply, even in a distributed instance assignment approach, the context around those definitions change.   A particular flow would, indeed still follow some particular path, but there would be no need to associate a path ID to it and there would be no need to (later) build a control plane around distribution of this path ID and maintenance of those path IDs in the face of inevitable failures.

I am exploring the alternative where forwarding is performed based on the abstract SFC ID without requiring the concept of a centrally known SFP to exist at all.   In this alternative approach, the instance selection is distributed to the classifier and the SFF's.   Any desired policy used to flavor instance selection is still supported, but such policy would, indeed, need to be available to the involved entities.   This would also be an excellent use of metadata where the initial ingress node could add one or more pieces of metadata that downstream nodes could make use of in their policy decisions.

    Ron

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 10:39 AM
To: Lucy yong; NAPIERALA, MARIA H; Ron Parker; Xuxiaohu; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Yours,
Joel

  instance

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 14 Jul 2014 15:12:15 +0000

Question: where exactly does it specify that the SFP *must* be
pre-instantiated? What exactly is wrong with the wording “When an SFC is
instantiated into the network it is necessary to select the specific
instances of SFs that will be used, and to create the service topology for
that SFC using SF’s network locators”? Let’s try to be specific rather
than dancing around the wording.

On 7/14/14, 11:00 AM, "Ron Parker" <[email-masked]> wrote:

>My reading of the Section 4.3, given the definitions presented before it,
>is that an end-to-end fully instantiated path is selected and then used
>to steer traffic to the requisite SFF's and SF's.   While those
>definitions could still apply, even in a distributed instance assignment
>approach, the context around those definitions change.   A particular
>flow would, indeed still follow some particular path, but there would be
>no need to associate a path ID to it and there would be no need to
>(later) build a control plane around distribution of this path ID and
>maintenance of those path IDs in the face of inevitable failures.
>
>I am exploring the alternative where forwarding is performed based on the
>abstract SFC ID without requiring the concept of a centrally known SFP to
>exist at all.   In this alternative approach, the instance selection is
>distributed to the classifier and the SFF's.   Any desired policy used to
>flavor instance selection is still supported, but such policy would,
>indeed, need to be available to the involved entities.   This would also
>be an excellent use of metadata where the initial ingress node could add
>one or more pieces of metadata that downstream nodes could make use of in
>their policy decisions.
>
>    Ron
>
>
>To: Lucy yong; NAPIERALA, MARIA H; Ron Parker; Xuxiaohu;
>[email-masked]; [email-masked]; [email-masked];
>> Agree that the current definition of the SFP in the arch draft is a bit
>>confusing, just as what you had pointed out.
>>
>>
>>
>> In my understanding, the SFP as an instantiation of an SFC in the
>>network should be “an ordered list of service nodes and SF IDs”(see
>>http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01). Of
>>course, how to represent the SFP in the data packet is another thing
>>(e.g., either through a path id or through an MPLS label stack). Here
>>the service node means the device which contains the SFF and the NF
>>components mandatorily while containing the SF and SF proxy components
>>optionally. The service node could be attached or embedded with multiple
>>SF instances and those SF instances could be of the same SF type or not.
>> In the case where there are multiple SF instances of the same SF type
>>(e.g., SF X) are attached to a given service node, the service node
>>could distribute the traffic which needs SF X among those SF instances
>>of SF X type locally. Meanwhile, there may be multiple service nodes
>>within a given SFC-enabled domain which are embedded or attached with
>>the SF
>  instance
>>[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,moha
>>[email-masked]<[email-masked]>,[email-masked]
>>m<[email-masked]>,[email-masked]<Ron_Parker@affirme
>>dnetworks.com>,[email-masked]<[email-masked]
>> 
>><mailto:[email-masked][email-masked]%3e,[email-masked]%3cmn1921@
>>att.com%3e,[email-masked][email-masked]%3e
>>,[email-masked][email-masked]%3e,Ron_Parker@affirmednetworks
>>[email-masked]%3e,[email-masked][email-masked]>>
>>Halpern; Ron
>>  >> >> >within the SFC domain and then let the path identifier point to
>>a
>>  >> >>lookup
>>  >> >> >>> Then I misunderstand the proposal ;-) .. However, it seems
>>to me
>>  >> >>that if
>>  >> >> >>> >> entire SFC domain at every single SFF as there is no way
>>to
>>  >>know
>>  >> >>a
>>  >> >> >>> >>priori
>>  >> >> >>> >> >I ahve no problem if some SFF are flow sensitive, and /
>>or
>>  >> >>stateful.
>>by the
>>needing to
>>  >> >> >>> >> >>>>> I don't see anything in the arch draft that
>>suggests any
>>  >> >>sort
>>  >> >> >>>of
>>SFP as
>>  >> >> >>> >> >>>>> choosing and then forwarding to the selected
>>instance of
>>  >> >>the
>>  >> >> >>> >> >>>>> 16 million flows is in my world) of service chains 
>>is
>>  >> >> >>>preconceived
>>tens of
>>  >> >> >>> >> >>>>> environments today. You can't seriously believe 
>>that in
>>  >>the
>>  >> >> >>> >> >>>>>>>>> provides nothing more than a lookup, that 
>>lookup can
>>  >> >> result
>>use of
>>  >> >> >>> >> >>>>>>>>> Requiring a SFC system to have the full 
>>knowledge of
>>  >> >> every
>>  >> >> >>> >> >>>>> available SFC
>>is not
>>participated in
>>  >> >> >>> >> >>>>>>>>> The point of the archtiecture is to permit all 
>>of
>>  >> >>these,
>>this is
>>is a
>>  >> >> >>> >> >>>>>>>>> of logical functions to be applied to a subset 
>>of
>>  >> >>packets.
>>singular or
>>  >> >> >>> >> >>>>>>>>> are invisible to the service chaining 
>>mechanisms (in
>>  >> >>much

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 15:19:30 +0000

Jim,

I am not wordsmithing here, but rather questioning some fundamental assumptions.

The very existence of the service function path concept is fundamental to the architecture.    As an analogy, in a traditional L3 routed network (excepting obscure source routing options), one could still observe that a particular flow is following a particular path through the network, but that is incidental to the architecture rather than fundamental to the architecture.

   Ron

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 14 Jul 2014 15:23:20 +0000

My point Ron is that several times it has been asserted that the SFP needs
to be pre-instantiated; again, where does it say that as I can’t see it?

On 7/14/14, 11:19 AM, "Ron Parker" <[email-masked]> wrote:

>The very existence of the service function path concept is fundamental to
>the architecture.    As an analogy, in a traditional L3 routed network
>(excepting obscure source routing options), one could still observe that
>a particular flow is following a particular path through the network, but
>that is incidental to the architecture rather than fundamental to the
>architecture.
>
>   Ron
>
>
>To: Ron Parker; Joel Halpern Direct; Lucy yong; NAPIERALA, MARIA H;
>Xuxiaohu; [email-masked]; [email-masked];
>>> 5 SFF-1, seeing chain ID=1, service index=1, chooses SFF-A-2 amongst
>>>its
>>> available instances of SF-A
>>>
>>> Again, I think this is where the confusion keeps creeping in.  The
>>>terms
>>> "chain" and "path" seem inconsistent.
>>>
>>> 
>>> <mailto:[email-masked]>;
>>>  >>Ian
>>>  >> >> >>>Smith;

---

From: Tom Taylor <[email-masked]>
Date: Mon, 14 Jul 2014 11:29:42 -0400

What is wrong with that wording is that it assumes that at the point of 
instantiation there is perfect knowledge of SF availability and 
reachability. APONF proposes to supply that information, BTW. However, 
the design is less resilient than one in which SF Forwarding can make 
decisions at each service hop.

Tom Taylor

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 15:33:18 +0000

I would reword this sentence as follows:

"When an SFC is instantiated into the network this results in specific instances of SFs being selected to create the service topology for that SFC using SF’s network locators”

Maria

> >> And assuming a newly recognized flow, the sequence could go
> something
> >> like this:
> >>
> [email-masked]
> <mailto:[email-masked]>;
> >> although it is perfectly acceptable (and some would say recommended)
> to
> >>do
> >> so.
> >>
> <[email-masked]
> <mailto:[email-masked]>
> >>  >> >> >>> >> >>>>>>>>> number of comments that have been made
> about the
> >>  >> >> >>> proposed
> >>  >> >> >>> >> >>>>>>>>> addressed by IP address. They may be
> addressed
> >>as
> >>  >> ports
> >>  >> >> on

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 15:35:11 +0000

Jim,

>>        classifier through the requisite service functions

I am questioning whether SFP needs to exist at an architectural level at all.   If it does not, then the issue of pre-instantiation is moot.   A specific rewording of the snippet above, minus the existence of SFP:

Service Function Chain (SFC):  The ordered set of service functions that must be invoked for the classified flow.   The exact path that will be followed through the network for a given flow is determined dynamically on an SFC-hop by SFC-hop basis with the SFC classifier selecting the initial SFF, the initial SFF selecting the next SFF, and so on, with the SFF hosting the final SF in the chain taking on the role of the SFC egress node.   The classifier and SFF's SHOULD make this selection statefully such that subsequent packets of the flow invoke the same SF instances.   If there is a failure, the surviving classifier and SFF's MAY make new stateful selections for existing flows.

   Ron

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Jul 2014 15:36:13 +0000

IMO:  quote "SFP forwarding information is associated with a service path identifier
that is used to uniquely identify an SFP" is not proper assumed in architecture doc.  

As discussed in this thread, an SF in an SFC may have multiple instances that are available or be in standby. Selection of the instance for the SF may be dynamic based on the flow info. on packet. Thus, we can not require a service path ID to identity an SFP.

Lucy

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 10:20 AM
To: Jim Guichard (jguichar); Joel Halpern Direct; Lucy yong; NAPIERALA, MARIA H; Xuxiaohu; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Jim,

   Ron

---

From: Tom Taylor <[email-masked]>
Date: Mon, 14 Jul 2014 12:06:56 -0400

A pre-assigned identifier could be useful if you want to introduce 
statefulness into the service-level routing.

Tom Taylor

...

---

From: Lucy yong <[email-masked]>
Date: Mon, 14 Jul 2014 16:15:32 +0000

Yeah. But the architecture should not mandate it because you may also have stateless used as well (as described in this thread).

Lucy

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Monday, July 14, 2014 11:07 AM
To: [email-masked]
Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

A pre-assigned identifier could be useful if you want to introduce statefulness into the service-level routing.

Tom Taylor

On 14/07/2014 11:36 AM, Lucy yong wrote:
> IMO:  quote "SFP forwarding information is associated with a service 
> path identifier that is used to uniquely identify an SFP" is not proper assumed in architecture doc.
>
...

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 14 Jul 2014 16:42:28 +0000

> As discussed in this thread, an SF in an SFC may have multiple instances that are available or be in standby. Selection of the instance for the SF may be dynamic based on the flow info. on packet.…

That statement has no impact on the use of a path _identifier_.  An identifier can map to available, redundant or successor instances.    

Selection based on flow/packet info is orthogonal as well, and referenced in the architecture as classification.

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 14 Jul 2014 18:24:05 +0000

Maria,

Inline.

From: <NAPIERALA>, MARIA H <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 14, 2014 6:20 AM
To: Ron Parker <[email-masked]<mailto:[email-masked]>>, Xuxiaohu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jim Guichard (jguichar)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

SK> I disagree on the "not necessary" part as it leads to a very inefficient method.
Let's park aside the SFC vs SFP debate and say SFC==SFP for this explanation. A classifier may determine SFP ID based on a non-trivial function, may be a DPI, as part of its classification. Not carrying the ID requires reclassification after every SF in order to keep the packets on the right SFP, in this case a DPI. Even that reclassification may be to late if one of the SFs transformed the packet. So, you do need a SFP ID for chaining to be useful.

SK> And for the argument about not needing SFP ID but only SFC ID, architecture does not prevent 1:1 mapping between them.

Surendra.

Maria

Given a topology like:

Thanks.

   Ron

Best regards,

Xiaohu

Maria,

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 19:05:37 +0000

<Maria> This discussion is about SFP (and SFP ID) as a specific, pre-defined sequence of service instances.
I believe that SFP (and its representation in the packet) is needed only when the SFCs are subject to traffic engineering. Trying to fit the SFP in the general SFC architecture, without stating what it is for, makes it an impossible task.

Surendra.

Maria

Given a topology like:

Thanks.

   Ron

Best regards,

Xiaohu

Maria,

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 06:33:48 +0000

Hi Jim,

Because you cannot assign an identifier to path unless it is known in advance. 

Anyway, this thread has shown the terminology (read SFP) is not appropriate + the current merged draft seems to adopt (prefer ?) a centralized model. 

Cheers,
Med

>De : Jim Guichard (jguichar) [mailto:[email-masked]]
>Envoyé : vendredi 11 juillet 2014 17:15
>À : NAPIERALA, MARIA H; BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Ron
>Parker; [email-masked]

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 15 Jul 2014 13:03:19 +0000

Hi Med,

>Because you cannot assign an identifier to path unless it is known in

Jim> why not? The identifier simply points to an instantiation of a given
chain in the network. That instantiation may be pre-established or loose
e.g. The actual SF instances to be used may or may not be determined a
priori. The identifier provides enough information to the network to be
able to resolve a given instantiation of a chain as traffic is forwarded
through it. 

> 
>
>Anyway, this thread has shown the terminology (read SFP) is not
>appropriate + the current merged draft seems to adopt (prefer ?) a
>centralized model.

Jim> I am unclear as to why the notion of centralized is assumed? The
architecture should not mandate centralized or distributed. Is the wording
in the draft or discussion on the list causing this misconception? The
architecture as I read it simply says that an SFC is defined as an ordered
list of SF’s and then one or more instantiations of this SFC may be active
within the network and identification of which particular instantiation
traffic is forwarded through is provided by a service path identifier.

>>>> >>> >> >>>>>>>>> It is of course the case that these may be combined.
>>>>I
>>>> tend
>>>> >>> >> >>>>>>>>> to
>>>> >>> >> >>>>> refer to
>>>>packets. A

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 03:44:18 +0000

If you are talking about the definition of SFP, I absolutely agree with you
Since as I said earlier, SFC can be represented by a set of identifier corresponding to SF in the chain while SFP can be represented by 
A set of locator corresponding to SFI invoked for a given chain.

-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 NAPIERALA, MARIA H
发送时间: 2014年7月14日 23:33
收件人: Jim Guichard (jguichar); Ron Parker; Joel Halpern Direct; Lucy yong; Xuxiaohu; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [sfc] Redefine the SFP//RE: Service Chains, Paths, and Load Balancers

Maria

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 15 Jul 2014 18:10:19 +0000

Ian,

Try to clarify the terminology you used:

Does "Selecting a decider" mean "selecting with SFFs"?
Does "Selecting an actor" mean "the SFF that determine which local instances to use"?

To me, there are two levels of decision:

-          Network level decision (which is pretty much same as today's router hops)

-          Node level decision (which local instance to use).

Linda

But the actual point I was trying to make is that there is a consistent semantic difference between 'selecting a decider' which is what you do if you make a next- hop selection amongst SNFs and/or SFFs, and 'selecting an actor' which is what you do when you make a next hop selection amongst SFIs, and you should differentiate between them.
On Jul 12, 2014 1:43 PM, Ron Parker <[email-masked]<mailto:[email-masked]>> wrote:
Ian,

    Ron

Cc: Jim Guichard (jguichar); Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; NAPIERALA, MARIA H

Cc: Jim Guichard (jguichar); Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; NAPIERALA, MARIA H

Sharon,

   Ron

Cc: NAPIERALA, MARIA H; Jim Guichard (jguichar); Ron Parker; Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

--szb

> On Jul 11, 2014, at 12:27 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
>
> Maria,
>
> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; NAPIERALA,
>> MARIA H;
>>>>> On Jul 9, 2014, at 6:01 PM, "Ron Parker"
>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> Jim,
>>>>
>>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
>>> NAPIERALA, MARIA H
>>>>> On Jul 9, 2014, at 5:31 PM, "Ron Parker"
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>> [email-masked]<mailto:[email-masked]>;
>>>>>> On Jul 9, 2014, at 5:17 PM, "Ron Parker"
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Jim,
>>>>>>
>>>>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>>>>>>> On Jul 9, 2014, at 5:07 PM, "NAPIERALA, MARIA H"
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>;
>>> <[email-masked]<mailto:[email-masked]>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>>>> To: NAPIERALA, MARIA H; [email-masked]<mailto:[email-masked]>;

---

From: Ian Smith <[email-masked]>
Date: Tue, 15 Jul 2014 18:31:57 +0000

Linda -

"actor" is a generic way of talking about the part of a system that actually _does_ the thing.  In this context that means _a particular instance of a service function_
"decider" is a generic way of talking about parts of the system that will make decisions about which actor will be used.  In this context it means a SNF, SFF, or a control/policy plane decision engine _when they are selecting SFIs_.

I think of it as being three decisions:

  1.  the network - function selection (bridging and routing, anycast/multicast, tenant domain, etc.);
  2.  the service - function selection + service selection (policy route, label switching, GSLB, virtual server destination (ip:port), traffic classification, etc.);
  3.  the instance - function selection + service selection + instance selection (LB pool member selection, DNS SRV & ENUM);

________________________________
From: Linda Dunbar [[email-masked]]
Sent: Tuesday, July 15, 2014 2:10 PM
To: Ian Smith; Ron Parker
Cc: Sharon; [email-masked]; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; [email-masked]; Eric Gray
Subject: RE: [sfc] Service Chains, Paths, and Load Balancers

Ian,

Does “Selecting a decider” mean “selecting with SFFs”?
Does “Selecting an actor” mean “the SFF that determine which local instances to use”?

-          Network level decision (which is pretty much same as today’s router hops)

Linda

    Ron

Sharon,

   Ron

--szb

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 15 Jul 2014 22:24:17 +0000

Ian,

Thank you very much for the clarification.
So the "Actor" is the Service function internal processing, correct?

Then the "Service Chains, Paths, and Load Balancers" in SFC context should be all about the  "Decider", correct?

Since some  service function instances are visible to Chain Classification nodes and Service Chain orchestration system, some other times, it is a collection of Instances as one entity that is visible to the "Classification Node" or "Orchestration system".

Therefore, some Chains have explicit information on which Service Function instances to use; some Chains only have the information on which cluster of instances to use; some chains have explicit information on which SFFs/SN nodes to use; etc.

http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00 is the attempt to describe decisions by SFFs and SN. Any comments and suggestions?

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Ian Smith
Sent: Tuesday, July 15, 2014 1:32 PM
To: Linda Dunbar; Ron Parker
Cc: Sharon; [email-masked]; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; [email-masked]; Eric Gray
Subject: Re: [sfc] Service Chains, Paths, and Load Balancers

Linda -

Cc: Sharon; [email-masked]<mailto:[email-masked]>; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; [email-masked]<mailto:[email-masked]>; Eric Gray

Linda

    Ron

Sharon,

   Ron

--szb

---

From: Ian Smith <[email-masked]>
Date: Tue, 15 Jul 2014 22:48:16 +0000

>"Then the “Service Chains, Paths, and Load Balancers” in SFC context should be all about >the  “Decider”, correct?"

No, Service Chains, Paths, (and  perhaps Load Balancers) are higher level abstractions -- I think it would be more appropriate to leave the analogy at the actual SNF or SFF nodes and not try and extend it into the abstract concepts of "what is a service chain?" or "what is a path?".  How you understand "Load Balancer" would impact whether you think it is or is not a subset of SFF capabilities.  If you do think of load balancing as reasonably being part of a SFF, then it would be a decider.  If you think of "a load balancer" as a service function that gets included in a chain, then it would be an actor.

I'll send comments on the draft separately.

________________________________
From: Linda Dunbar [[email-masked]]
Sent: Tuesday, July 15, 2014 6:24 PM
To: Ian Smith; Ron Parker
Cc: Sharon; [email-masked]; Jim Guichard (jguichar); NAPIERALA, MARIA H; Joel M. Halpern; [email-masked]; Eric Gray
Subject: [sfc] Service Chains, Paths, and Load Balancers & draft-dunbar-sfc-fun-instances-restoration-00

Ian,

Thank you very much for the clarification.
So the “Actor” is the Service function internal processing, correct?

Then the “Service Chains, Paths, and Load Balancers” in SFC context should be all about the  “Decider”, correct?

Since some  service function instances are visible to Chain Classification nodes and Service Chain orchestration system, some other times, it is a collection of Instances as one entity that is visible to the “Classification Node” or “Orchestration system”.

Linda

Linda -

Linda

    Ron

Sharon,

   Ron

--szb

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 16 Jul 2014 14:05:05 -0400

I think the definition in the merged draft in section 1.3 works and fits with *most* of the document.  It does not dictate as required, but does allow for the specific SFIs to be predetermined on classification.  It also allows for the SFIs to be determined in a more dynamic fashion, "via information contained in the SFC encapsulation". 

The problem I see is that in section 2.3, the text seems to restrict this to the former option.  If that text were reworded to be more like section 4.8, then (at least to me) it would be more clear and less restrictive.

From: [email-masked]<[email-masked]>
To: Lucy yong<[email-masked]>,NAPIERALA, MARIA H<[email-masked]>,Ron Parker<[email-masked]>,Xuxiaohu<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Monday, July 14, 2014
Subject: Re: [sfc] Redefine the SFP//RE:  Service Chains, Paths, and Load Balancers

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Jul 2014 23:52:39 +0000

Ian,

You said:

-- I think it would be more appropriate to leave the analogy at the actual SNF or SFF nodes and not try and extend it into the abstract concepts of "what is a service chain?" or "what is a path?".
Are you saying that SFF or SNF can make local decision on what Service functions or instances to apply to a flow? i.e. the packets are identified (or marked) by the Classifier node, and some SFF/SNF can be given a set of policies on which Service Functions/instances are used to apply treatment for the identified flows?

How you understand "Load Balancer" would impact whether you think it is or is not a subset of SFF capabilities.  If you do think of load balancing as reasonably being part of a SFF, then it would be a decider.  If you think of "a load balancer" as a service function that gets included in a chain, then it would be an actor.

[Linda] Load Balancer is a loaded term. There are load balancer among cluster of servers, or load balancer among set of links  (e.g. ECMP). If SFC only focuses on the "Decider" aspect, and leaves the "Actor" part out of the scope, everything will be easier.
Linda

Linda

Linda -

Linda

    Ron

Sharon,

   Ron

--szb