Subject: [sfc] SFC Terminology / Concepts

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 14 Jul 2014 17:47:38 +0000

Dear WG:

There has been much debate over the last few days with regards to SFC concepts. To try and form some consensus around terminology and concepts used to describe the architecture in the merged architecture draft, Joel has kindly suggested the following:

"The SFP provides a level of indirection between the fully abstract notion of service path as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF instance selection authority that is delegated to the network.”

I’d like to ask the WG as a whole, if this clarification is something that we can get consensus on. If so, I’ll ask Joel to provide specific text, that reflects the above, for inclusion in the merged architecture draft.

Thank You,

Jim

---

From: David Allan I <[email-masked]>
Date: Mon, 14 Jul 2014 18:02:52 +0000

I like that text, it strikes a good balance where an implementation has the option of making scale and resiliency a local matter....

D

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, July 14, 2014 10:48 AM
To: [email-masked]
Subject: [sfc] SFC Terminology / Concepts

Dear WG:

"The SFP provides a level of indirection between the fully abstract notion of service path as a sequence of functions to be delivered, and the fully specified notion of exactly what instances of SFFs the packet will visit when it actually traverses the network. By allowing the control components to specify the use of this level of indirection, the deployment may choose the degree of SFF instance selection authority that is delegated to the network."

I'd like to ask the WG as a whole, if this clarification is something that we can get consensus on. If so, I'll ask Joel to provide specific text, that reflects the above, for inclusion in the merged architecture draft.

Thank You,

Jim

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 14 Jul 2014 18:13:09 +0000

Sounds good to me

Regards,
Jeff

On Jul 14, 2014, at 11:03 AM, "David Allan I" <[email-masked]<mailto:[email-masked]>> wrote:

I like that text, it strikes a good balance where an implementation has the option of making scale and resiliency a local matter….

D

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, July 14, 2014 10:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] SFC Terminology / Concepts

Dear WG:

Thank You,

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

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 18:15:46 +0000

I have a counter-proposal that eliminates the term "SFP" entirely:

"The Service Function Chain (SFC) provides a fully abstract view of the service functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service function instance selection.   The Constrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affecting the selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC's associated with it."

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Monday, July 14, 2014 2:03 PM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

D

Dear WG:

Thank You,

Jim

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 18:22:27 +0000

There is one missing word in my text.   Please replace my proposed text with:

"The Service Function Chain (SFC) provides a fully abstract view of the service functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service function instance selection.   The Constrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affecting the instance selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC's associated with it."

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, July 14, 2014 2:16 PM
To: David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Monday, July 14, 2014 2:03 PM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC Terminology / Concepts

D

Dear WG:

Thank You,

Jim

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 18:23:18 +0000

Ron,

this is pretty good.

I would propose to re-phrase the second sentence to: "The Constrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affecting the selection of one or more *specific* service function *instances* in the SFC".

Maria

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 18:25:30 +0000

Sounds very good.

Maria

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, July 14, 2014 2:22 PM
To: Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Thanks.

    Ron

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, July 14, 2014 2:16 PM
To: David Allan I; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] SFC Terminology / Concepts

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Jul 2014 14:29:23 -0400

Maria, while the constraint (either C-SFC or SFP, whichever term the SG 
likes) may be selecting specific instances, it may be more general.

The simplest example is that for a given service chain, one might have 
one SFP (or C-SFC) that causes the entire chain to be delivered at 
data-center-1 and a second SFP (or C-SFC) that causes the entire service 
chain to be delivered at data-center-2.  Each data center has many 
instances running.  And may even have multiple clusters in different 
PODs within the DC.
Yes, the constraint may say use exactly this specific isntances, but it 
does not have to.

Yours,
Joel

On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote:
> Ron,
>
> this is pretty good.
>
> I would propose to re-phrase the second sentence to: “The
> Constrained-SFC (C-SFC) further allows for policy constraints to be
> added to the SFC affecting the selection of one or more **specific**
> service function **instances** in the SFC”.
>
> Maria
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ron Parker
> *Sent:* Monday, July 14, 2014 2:16 PM
> *To:* David Allan I; Jim Guichard (jguichar); [email-masked]
> *Subject:* Re: [sfc] SFC Terminology / Concepts
>
> I have a counter-proposal that eliminates the term “SFP” entirely:
>
> “The Service Function Chain (SFC) provides a fully abstract view of the
> service functions to be invoked and the order in which they are to be
> invoked for some particular flow or set of flows, without concern of
> actual service function instance selection.   The Constrained-SFC
> (C-SFC) further allows for policy constraints to be added to the SFC
> affecting the selection of one or more of the service functions in the
> SFC.   Any SFC may have any number of C-SFC’s associated with it.”
>
> Thanks.
>
>      Ron
>
> "The SFP provides a level of indirection between the fully abstract
> notion of service path as a sequence of functions to be delivered, and
> the fully specified notion of exactly what instances of SFFs the packet
> will visit when it actually traverses the network. By allowing the
> control components to specify the use of this level of indirection, the
> deployment may choose the degree of SFF instance selection authority
> that is delegated to the network.”
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *David Allan I
> *Sent:* Monday, July 14, 2014 2:03 PM
> *To:* Jim Guichard (jguichar); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] SFC Terminology / Concepts
>
> I like that text, it strikes a good balance where an implementation has
> the option of making scale and resiliency a local matter….
>
> D
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* Monday, July 14, 2014 10:48 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] SFC Terminology / Concepts
>
> Dear WG:
>
> There has been much debate over the last few days with regards to SFC
> concepts. To try and form some consensus around terminology and concepts
> used to describe the architecture in the merged architecture draft, Joel
> has kindly suggested the following:
>
> "The SFP provides a level of indirection between the fully abstract
> notion of service path as a sequence of functions to be delivered, and
> the fully specified notion of exactly what instances of SFFs the packet
> will visit when it actually traverses the network. By allowing the
> control components to specify the use of this level of indirection, the
> deployment may choose the degree of SFF instance selection authority
> that is delegated to the network.”
>
> I’d like to ask the WG as a whole, if this clarification is something
> that we can get consensus on. If so, I’ll ask Joel to provide specific
> text, that reflects the above, for inclusion in the merged architecture
> draft.
>
> Thank You,
>
> Jim
>
>
>
> [email-masked]

---

From: David Allan I <[email-masked]>
Date: Mon, 14 Jul 2014 18:36:21 +0000

I'm not that comfortable with this definition....

I like the flexibility that an SF can participate in more than one SC. Hence it makes sense to separate the concept of path and chain.

And a C-SFC is simply an SFP IMO. I cannot envision how it would be expressed differently. A scaled out SF simply being the analogy of a "loose hop" in the path, but with the "loose hop" having an identity.

Make sense?
Dave

From: Ron Parker [mailto:[email-masked]]
Sent: Monday, July 14, 2014 11:22 AM
To: Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: RE: SFC Terminology / Concepts

Thanks.

    Ron

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: Tom Taylor <[email-masked]>
Date: Mon, 14 Jul 2014 14:37:17 -0400

Your text scares me because it introduces some new concepts and 
assumptions.

I'd rather go with Joel's formulation. Clarifying question on that: am I 
right in seeing the implication that when control assigns an SFP, the 
assignment is recorded by an identifier wwhich travels with the packet?

Tom Taylor

On 14/07/2014 2:22 PM, Ron Parker wrote:
> affecting the instance selection of one or more of the service functions
> in the SFC.   Any SFC may have any number of C-SFC’s associated with it.”
>
> Thanks.
>
>      Ron
...

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 18:42:56 +0000

Joel,

for me, this is still about specific service instances to be chosen.

Maria
> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, July 14, 2014 2:29 PM
> To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar);
> [email-masked]
> > I would propose to re-phrase the second sentence to: "The
> > service function **instances** in the SFC".
> >
> > Maria
> >
> > "The Service Function Chain (SFC) provides a fully abstract view of the
> > SFC.   Any SFC may have any number of C-SFC's associated with it."
> >
> > Thanks.
> >
> >      Ron
> >
> > that is delegated to the network."
> >
> > the option of making scale and resiliency a local matter....
> >
> > D
> >
> > that is delegated to the network."
> >
> > I'd like to ask the WG as a whole, if this clarification is something
> > that we can get consensus on. If so, I'll ask Joel to provide specific

---

From: Dave Dolson <[email-masked]>
Date: Mon, 14 Jul 2014 18:43:52 +0000

I feel that the standardization effort needs to be primarily about the concrete *path*, in particular the packet formats and the rules for how SFFs select the next hop(s).

Because of that, I think the paths should have simple names (choosing SFP vs. C-SFC).

It may be just me, but I think we need to work bottom-up.
I think we can have a standard without the abstract paths. The abstraction almost feels like it could be vendor-specific in the Classifier.

(I think the abstraction is very useful at the configuration layer, but not essential to having packets moving.)

I somewhat abashedly admit that I don't understand what Joel has written, especially, "the deployment may choose the degree of SFF instance selection authority that is delegated to the network."
What is "the deployment"? Vendor? Operator? Are the machines configuring themselves?
What is "instance selection authority" ?

Does this really mean, "the mapping from abstract SFC to SFP is left to implementation." ?  And therefore SFC-Classifier vendors can define variations of abstraction?

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, July 14, 2014 2:29 PM
To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Jul 2014 15:52:20 -0400

The most likely realization of the architecture would be that the SFP 
assignment is recorded in an identifier which travels with the packet.

Some folks seem to not want the architecture to mandate that.

Yours,
Joel

---

From: Ron Parker <[email-masked]>
Date: Mon, 14 Jul 2014 20:15:30 +0000

I am not one of them.   I see the chain ID or equivalent being required in the packet.    At a minimum, the SFF receiving the packet needs to know which is the currently required local SF, what is the next required SF (if any) and what is the SFF that reaches the next SF.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Monday, July 14, 2014 3:52 PM
To: Tom Taylor; [email-masked]; Ron Parker
Subject: Re: [sfc] SFC Terminology / Concepts

The most likely realization of the architecture would be that the SFP assignment is recorded in an identifier which travels with the packet.

Yours,
Joel

On 7/14/14, 2:37 PM, Tom Taylor wrote:
> I'd rather go with Joel's formulation. Clarifying question on that: am 
> I right in seeing the implication that when control assigns an SFP, 
> the assignment is recorded by an identifier wwhich travels with the packet?
>
> Tom Taylor
>
>> "The Service Function Chain (SFC) provides a fully abstract view of 
>> the service functions to be invoked and the order in which they are 
>> to be invoked for some particular flow or set of flows, without concern of
>> in the SFC.   Any SFC may have any number of C-SFC's associated with it."
>>
>> Thanks.
>>
>>      Ron
> ...
>
>
>> I like that text, it strikes a good balance where an implementation 
>> has the option of making scale and resiliency a local matter....
>>
>> D
>>
>> concepts. To try and form some consensus around terminology and 
>> concepts used to describe the architecture in the merged architecture 
>> draft, Joel has kindly suggested the following:
>>
>> notion of service path as a sequence of functions to be delivered, 
>> and the fully specified notion of exactly what instances of SFFs the 
>> packet will visit when it actually traverses the network. By allowing 
>> the control components to specify the use of this level of 
>> indirection, the deployment may choose the degree of SFF instance 
>> selection authority that is delegated to the network."
>>
>> that we can get consensus on. If so, I'll ask Joel to provide 
>> specific text, that reflects the above, for inclusion in the merged 
>> architecture draft.
>>
>> Thank You,
>>
>> Jim
>>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Jul 2014 16:22:28 -0400

Maria, the text allows, but does not mandate, the selecting of specific 
service instances.  I can not tell whether you agree or disagree with 
either allowing or not mandating the behavior.

Yours,
Joel

On 7/14/14, 2:42 PM, NAPIERALA, MARIA H wrote:
>> concepts

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Mon, 14 Jul 2014 20:29:22 +0000

Joel,

Which text are you referring to? Sorry but I got lost.

Maria

> Sent: Monday, July 14, 2014 4:22 PM

---

From: "Huangyong (Oliver)" <[email-masked]>
Date: Tue, 15 Jul 2014 00:51:49 +0000

Agree Ron's proposal.

---------------------------
Huangyong (Oliver)
Network research, Huawei

From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Tuesday, July 15, 2014 2:22 AM
To: Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Thanks.

    Ron

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Jul 2014 02:31:06 +0000

Hi Joel,

I believe we should make a clear definition of the SFP. As for how to carry the SFP information in the data packets, there are many ways and therefore it should not be specified in the arch draft.

Best regards,
Xiaohu

> Sent: Tuesday, July 15, 2014 3:52 AM
> The most likely realization of the architecture would be that the SFP assignment
> is recorded in an identifier which travels with the packet.
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 04:33:40 +0000

Chain and Path are still two different things. Change the name of path doesn’t help.
If I have a constraint based path, should I interpret it as constraint based constraint-SFC? No

Regards!
-Qin
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月15日 2:22
收件人: Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
主题: Re: [sfc] SFC Terminology / Concepts

“The Service Function Chain (SFC) provides a fully abstract view of the service functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service function instance selection.   The Constrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affecting the instance selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated with it.”

Thanks.

    Ron

“The Service Function Chain (SFC) provides a fully abstract view of the service functions to be invoked and the order in which they are to be invoked for some particular flow or set of flows, without concern of actual service function instance selection.   The Constrained-SFC (C-SFC) further allows for policy constraints to be added to the SFC affecting the selection of one or more of the service functions in the SFC.   Any SFC may have any number of C-SFC’s associated with it.”

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 06:46:36 +0000

Hi Jim,

The use of SFP is inappropriate. A path is a result of forwarding policies that may not be known in advance.

I'm for using the chain itself as the main abstract level and optionally allow for customized forwarding polices to be provisioned to a subset of involved SFFs if needed. These policies are meant to guide the instance selection process for deployments requiring such complexity.

So, I disagree with this proposal.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : lundi 14 juillet 2014 19:48
À : [email-masked]
Objet : [sfc] SFC Terminology / Concepts

Dear WG:

Thank You,

Jim

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 07:13:38 +0000

Hi Ron, all,

This is much better.

I'm for using the chain as the abstract level that will infer the forwarding actions by default + allow policies to constraint forwarding actions in some nodes (if/when needed). A "path" will be the consequence of these forwarding actions.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Ron Parker
Envoyé : lundi 14 juillet 2014 20:22
À : Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Objet : Re: [sfc] SFC Terminology / Concepts

Thanks.

    Ron

Thanks.

    Ron

D

Dear WG:

Thank You,

Jim

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 07:21:34 +0000

Hi Joel,

As mentioned in several messages, I'm personally for the use of the chain itself is the main information to be conveyed in packets to drive forwarding actions. 

I can understand that an identifier can be assigned to a path that is known in advance, but if that path is not known I'm not sure how an identifier can be assigned to it!

Joel, the use of "path" is really inappropriate to refer to distributed instance selection process for packets bound to a given SFC. 

Cheers,
Med

>-----Message d'origine-----
>De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : lundi 14 juillet 2014 21:52
>À : Tom Taylor; [email-masked]; Ron Parker
>>> the option of making scale and resiliency a local matter..
>>>
>>> D
>>>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Jul 2014 08:49:06 +0000

Hi Med,

IMHO, the architecture should allow the classifier to specify

1) a partial SFP (i.e., some SFFs along that partial SFP need to locally determine the appropriate SFF for the next SF);
2) a complete SFP (i.e., the SFF for each SF in the SFC has been determined by the centralized node);
3) an SFC (i.e., each SFF along the final SFP needs to locally determine the appropriate SFF for the next SF). 

In fact, case 3) could be looked as an extreme of case 1).

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, July 15, 2014 3:22 PM
> To: Joel M. Halpern; Tom Taylor; [email-masked]; Ron Parker
> As mentioned in several messages, I'm personally for the use of the chain itself is
> the main information to be conveyed in packets to drive forwarding actions.
> 
> I can understand that an identifier can be assigned to a path that is known in
> advance, but if that path is not known I'm not sure how an identifier can be
> assigned to it!
> 
> Joel, the use of "path" is really inappropriate to refer to distributed instance
> selection process for packets bound to a given SFC.
> 
> Cheers,
> Med
> 
> >Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; [email-masked]; Ron
> >Parker Objet : Re: [sfc] SFC Terminology / Concepts
> >
> >> I'd rather go with Joel's formulation. Clarifying question on that:
> >> am I right in seeing the implication that when control assigns an
> >> SFP, the assignment is recorded by an identifier wwhich travels with the
> packet?
> >>
> >> Tom Taylor
> >>
> >>> has the option of making scale and resiliency a local matter..
> >>>
> >>> D
> >>>
> >>> There has been much debate over the last few days with regards to
> >>> SFC concepts. To try and form some consensus around terminology and
> >>> concepts used to describe the architecture in the merged
> >>> architecture draft, Joel has kindly suggested the following:
> >>>
> >>> packet will visit when it actually traverses the network. By
> >>> allowing the control components to specify the use of this level of
> >>> I'd like to ask the WG as a whole, if this clarification is
> >>> something that we can get consensus on. If so, I'll ask Joel to
> >>> provide specific text, that reflects the above, for inclusion in the
> >>> merged architecture draft.
> >>>
> >>> Thank You,
> >>>
> >>> Jim
> >>>
> >>>
> >>>

---

From: <[email-masked]>
Date: Tue, 15 Jul 2014 09:34:42 +0000

Hi Xiaohu,

Why a classifier will need specify a path a la ERO? Why it needs to have the full knowledge  of the involved SF instances? Wouldn't this require the classifier to be fed with additional information to drive its selection process? Is this complexity justified for all deployments?

Cheers,
Med

>De : Xuxiaohu [mailto:[email-masked]]
>Envoyé : mardi 15 juillet 2014 10:49
>À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor; [email-masked];
>Ron Parker
>Objet : RE: [sfc] SFC Terminology / Concepts
>
>Hi Med,
>
>1) a partial SFP (i.e., some SFFs along that partial SFP need to locally
>determine the appropriate SFF for the next SF);
>> >>> There is one missing word in my text.   Please replace my proposed
>text
>> >>> with:
>> >>>

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 15 Jul 2014 09:50:11 +0000

Hi Med,

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2014 5:35 PM
> To: Xuxiaohu; Joel M. Halpern; Tom Taylor; [email-masked]; Ron Parker
> Subject: RE: [sfc] SFC Terminology / Concepts
> 
> Hi Xiaohu,
> 
> Why a classifier will need specify a path a la ERO? Why it needs to have the full

In this way, the path selection process (i.e., selecting the appropriate SFF for the next SF based on certain constraints) on the SFF is greatly simplified.

> knowledge  of the involved SF instances? Wouldn't this require the classifier to
> be fed with additional information to drive its selection process? Is this

The classifier could request the PCE to do the SFP computation (see http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is no need for the classifier to be fed with additional information. 

> complexity justified for all deployments?

As I have said, the architecture should allow the classifier to just impose the SFC information on the selected packet as well. In this way, each SFF needs to resolve the appropriate next SFF for the next SF to be executed.

Best regards,
Xiaohu

> >De : Xuxiaohu [mailto:[email-masked]] Envoyé : mardi 15 juillet
> >2014 10:49 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor;
> >[email-masked]; Ron Parker Objet : RE: [sfc] SFC Terminology / Concepts
> >
> >Hi Med,
> >
> >1) a partial SFP (i.e., some SFFs along that partial SFP need to
> >locally determine the appropriate SFF for the next SF);
> >3) an SFC (i.e., each SFF along the final SFP needs to locally
> >determine the appropriate SFF for the next SF).
> >
> >> As mentioned in several messages, I'm personally for the use of the
> >> chain
> >itself is
> >> advance, but if that path is not known I'm not sure how an identifier
> >> can
> >be
> >> assigned to it!
> >>
> >> Joel, the use of "path" is really inappropriate to refer to
> >> distributed
> >instance
> >> >Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; [email-masked];
> >> >Ron Parker Objet : Re: [sfc] SFC Terminology / Concepts
> >> >
> >> >The most likely realization of the architecture would be that the
> >> >SFP assignment is recorded in an identifier which travels with the packet.
> >> >
> >> >> SFP, the assignment is recorded by an identifier wwhich travels
> >> >> with
> >the
> >> packet?
> >> >>
> >> >> Tom Taylor
> >> >>
> >> >>> "The Service Function Chain (SFC) provides a fully abstract view
> >> >>> of the service functions to be invoked and the order in which
> >> >>> they are to be invoked for some particular flow or set of flows,
> >> >>> without
> >concern of
> >> >>> (C-SFC) further allows for policy constraints to be added to the
> >> >>> SFC affecting the instance selection of one or more of the
> >> >>> service
> >functions
> >> >>> I like that text, it strikes a good balance where an
> >> >>> implementation has the option of making scale and resiliency a local
> matter..
> >> >>>
> >> >>> D
> >> >>>
> >> >>> SFC concepts. To try and form some consensus around terminology
> >> >>> and concepts used to describe the architecture in the merged
> >> >>> "The SFP provides a level of indirection between the fully
> >> >>> abstract notion of service path as a sequence of functions to be
> >> >>> delivered, and the fully specified notion of exactly what
> >> >>> instances of SFFs the packet will visit when it actually
> >> >>> traverses the network. By allowing the control components to
> >> >>> specify the use of this level of indirection, the deployment may
> >> >>> choose the degree of SFF instance selection authority that is delegated to
> the network."
> >> >>>
> >> >>> provide specific text, that reflects the above, for inclusion in
> >> >>> the merged architecture draft.
> >> >>>
> >> >>> Thank You,
> >> >>>
> >> >>> Jim
> >> >>>
> >> >>>
> >> >>>

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Tue, 15 Jul 2014 10:08:34 +0000

I'd vote for SFP. Decoupling SFP and SFC is meaningful for they are descriptions of different levels. Whatever how fancy the definitions are, SFC should be an abstraction of a sequence of SFs without any cue of how it is implemented, while SFP is the datapath instantiation and it is design/implementation related. 

So, in general I agree with Joel's proposal, but I also support Dave's comment to clarify it somehow.

Hongyu

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Tuesday, July 15, 2014 2:44 AM
To: Joel M. Halpern; NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Monday, July 14, 2014 2:29 PM
To: NAPIERALA, MARIA H; Ron Parker; David Allan I; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

The simplest example is that for a given service chain, one might have one SFP (or C-SFC) that causes the entire chain to be delivered at
data-center-1 and a second SFP (or C-SFC) that causes the entire service chain to be delivered at data-center-2.  Each data center has many instances running.  And may even have multiple clusters in different PODs within the DC.
Yes, the constraint may say use exactly this specific isntances, but it does not have to.

Yours,
Joel

On 7/14/14, 2:23 PM, NAPIERALA, MARIA H wrote:
> the service functions to be invoked and the order in which they are to 
> be invoked for some particular flow or set of flows, without concern of
> the fully specified notion of exactly what instances of SFFs the 
> the fully specified notion of exactly what instances of SFFs the 
> text, that reflects the above, for inclusion in the merged 
> architecture draft.
>
> Thank You,
>
> Jim
>
>
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 15 Jul 2014 10:51:36 +0000

I agree with Med that requiring classifier make the second selection add complexity and is not desirable. What classifier only needs to do is just mapping a given SFC to a specific SFP.

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年7月15日 17:35
收件人: Xuxiaohu; Joel M. Halpern; Tom Taylor; [email-masked]; Ron Parker
主题: Re: [sfc] SFC Terminology / Concepts

Hi Xiaohu,

Cheers,
Med

>> >>> implementation has the option of making scale and resiliency a local matter..
>> >>>
>> >>> D
>> >>>
>> >>> choose the degree of SFF instance selection authority that is delegated to the network."
>> >>>

---

From: "He, Peng" <[email-masked]>
Date: Tue, 15 Jul 2014 09:08:41 -0400

Try to understand the three scenarios you listed: you mean the classifier can specify a (partial or complete) SFP which is a list of SFFs, then each SFF will (locally) select one of the SF instances under itself for this SF. For partial SFP case, each SFF will identify the SFI under itself and specify (like a classifier) next SFF(s).  The classifier (and SFF?) could obtain this  (SFF) 'path' information from either centralized point (e.g., PCE, controller), or, via a distributed control plane? For partial SFP, will there be a re-classification to decide next SFF(s) or not? 

Regards,
Peng

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Tuesday, July 15, 2014 4:49 AM
To: [email-masked]; Joel M. Halpern; Tom Taylor; [email-masked]; Ron Parker
Subject: Re: [sfc] SFC Terminology / Concepts

Hi Med,

Best regards,
Xiaohu

> chain itself is the main information to be conveyed in packets to drive forwarding actions.
> 
> I can understand that an identifier can be assigned to a path that is 
> known in advance, but if that path is not known I'm not sure how an 
> identifier can be assigned to it!
> 
> distributed instance selection process for packets bound to a given SFC.
> 
> Cheers,
> Med
> 
> >> with the
> >>> of the service functions to be invoked and the order in which they 
> >>> are to be invoked for some particular flow or set of flows, without concern of
> >>> SFC affecting the instance selection of one or more of the service functions
> >>> instances of SFFs the packet will visit when it actually traverses 
> >>> the network. By allowing the control components to specify the use 
> >>> of this level of indirection, the deployment may choose the degree 
> >>> of SFF instance selection authority that is delegated to the network."
> >>>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 15 Jul 2014 13:23:12 +0000

I agree, there is no implication in the suggested text that mandates a static, a priori path, rather is provides the distinction between the fully abstract and the need to actually instantiate that abstraction in the network.

For some reason, 3 or 4 people seem to be fixated on the term “path” but Joel has made it clear that this need not be, architecturally, a known fixed path, but rather, the selection may occur based on needed indirection at the nodes.

Paul

On Jul 14, 2014, at 2:02 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:

D

Dear WG:

Thank You,

Jim

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Jul 2014 11:06:49 -0400

My concern is that there are requests (which I happen to support) for 
allowing a degree of policy expression or scope restriction in what the 
classification communicates to the infrastructure about the service 
delivery.  This needs to include restrictions on SFF selection and 
probably at least allow for restrictions on ctual instance selection.

Given that the restriction includes the case "allow all", expressing the 
information in terms of this intermediate allows for the requirement, 
allows for the communication of the equivalent of the unlimited chain, 
and allows for expression of the exact choice when operations has 
selected that behavior.

Communicating the chain does not add anything to this, and if it were 
used instead of the itnermediate it would remove the ability to meet the 
requirements.

Yours,
Joel

---

From: Tom Taylor <[email-masked]>
Date: Tue, 15 Jul 2014 11:27:48 -0400

In that case I would go with Ron's text. There is an operational issue: 
where to insert constraints. Are they inserted at the ingress classifier 
only (and there can be multiple instances of those) or can they be added 
at intermediate points? A possible advantage of allowing constraints to 
be added further along the path is that it looks ahead to inter-domain 
operation. However, if done within a single domain it increases the 
administrative load because more entities have to be configured with 
policy information.

My view of a path identifier is that it can optimize service-level 
forwarding by providing a function similar to that of the IPv6 Flow 
Label. At branch points (e.g., load balancers) the forwarding decision 
uses the path identifier rather than re-hashing some of the contents of 
the packet. I suppose instead of "path identifier" it would more 
properly be called "service flow identifier".

Tom

...

---

From: Lucy yong <[email-masked]>
Date: Tue, 15 Jul 2014 16:06:22 +0000

Is following text clear assuming SFC and SFP term definition in the merged arch are used?

A SFC may have multiple instantiations in a SFC service network, i.e. multiple SFPs. A SFP selection may further constraint by the policies at the classifier. A SFP identifier in SFC header is inserted by the classifier to differentiate from other SFPs. However, a set of SF instances in the SFP of a SFC may be dynamically or statically selected when the traffic traverse the network. The network implementation must avoid the flow packets re-order when the flow packets pass through the network.

Lucy    

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, July 15, 2014 10:07 AM
To: [email-masked]; Tom Taylor; [email-masked]; Ron Parker
Subject: Re: [sfc] SFC Terminology / Concepts

My concern is that there are requests (which I happen to support) for allowing a degree of policy expression or scope restriction in what the classification communicates to the infrastructure about the service delivery.  This needs to include restrictions on SFF selection and probably at least allow for restrictions on ctual instance selection.

Given that the restriction includes the case "allow all", expressing the information in terms of this intermediate allows for the requirement, allows for the communication of the equivalent of the unlimited chain, and allows for expression of the exact choice when operations has selected that behavior.

Communicating the chain does not add anything to this, and if it were used instead of the itnermediate it would remove the ability to meet the requirements.

Yours,
Joel

On 7/15/14, 3:21 AM, [email-masked] wrote:
>>> SFP, the assignment is recorded by an identifier wwhich travels with the packet?
>>>
>>> Tom Taylor
>>>
>>>> and the fully specified notion of exactly what instances of SFFs 
>>>> the packet will visit when it actually traverses the network. By

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Tue, 15 Jul 2014 16:13:25 +0000

An SFC is traffic engineered or it is not traffic engineered. There is nothing in-between.

Maria

> known in
> and

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 15 Jul 2014 12:26:31 -0400

There are several possible interpretations of this comment.

Given that it is clear that traffic engineering may specify its results 
with different resolutions, the interpretation I end up with is that 
anything which specifies any constraints is "traffic engineered".

If that is the intended meaning, then since the empty set is a valid set 
of constraints, then my approach is to always work in traffic-engineered 
spaces, where that traffic engineering may be trivial, complete, or 
in-between.

Is that what you mean?

Yours,
Joel

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Tue, 15 Jul 2014 16:35:58 +0000

What I meant was that Xiaohu's case (3) is clearly different from (1) and (2). BTW, he did not (because he could not) use an SFP to describe it, because it does not apply.

I am still voting for text as proposed by Ron.  

Maria

> Sent: Tuesday, July 15, 2014 12:27 PM
> To: NAPIERALA, MARIA H; Xuxiaohu; [email-masked];
> Tom Taylor; [email-masked]; Ron Parker
> >> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been
> determined
> >> by the centralized node);
> >> 3) an SFC (i.e., each SFF along the final SFP needs to locally determine
> the
> >> appropriate SFF for the next SF).
> >>
> >>>>>> in the SFC.   Any SFC may have any number of C-SFC's associated
> with
> >>>> it."
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>>       Ron
> >>>>> ...
> >>>>>
> >>>>>
> >>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *David
> Allan
> >>>>>> I

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Jul 2014 01:19:13 +0000

To some extent, the shortest path forwarding can be looked as an extreme of the explicit path forwarding since the former has only specify a single explicit hop (that's the destination). Similarly, case 3 and 1 could be looked as two extremes of case 1.

Best regards,
Xiaohu

> From: NAPIERALA, MARIA H [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2014 12:13 AM
> To: Xuxiaohu; [email-masked]; Joel M. Halpern; Tom Taylor;
> [email-masked]; Ron Parker
> > determined by the centralized node);
> > > advance, but if that path is not known I'm not sure how an
> > > identifier can
> > be
> > > assigned to it!
> > >
> > > >De : sfc [mailto:[email-masked]] De la part de Joel M.
> > > >Halpern Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor;
> > > >[email-masked]; Ron Parker Objet : Re: [sfc] SFC Terminology /
> > > >Concepts
> > > >
> > > >>> Allan I
> > > >>> There has been much debate over the last few days with regards
> > > >>> to SFC concepts. To try and form some consensus around
> > > >>> terminology
> > and

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Jul 2014 02:57:53 +0000

Hi Peng,

> From: He, Peng [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2014 9:09 PM
> Try to understand the three scenarios you listed: you mean the classifier can
> specify a (partial or complete) SFP which is a list of SFFs, then each SFF will
> (locally) select one of the SF instances under itself for this SF. For partial SFP case,

In either case, the SFF should be capable of selecting the appropriate instance of a given SF attached to itself. it's an internal load-balancing issue.

> each SFF will identify the SFI under itself and specify (like a classifier) next SFF(s).
> The classifier (and SFF?) could obtain this  (SFF) 'path' information from either
> centralized point (e.g., PCE, controller), or, via a distributed control plane? For
> partial SFP, will there be a re-classification to decide next SFF(s) or not?

If you want the SFF to locally determine the appropriate SFF for the next SF, the SFF should have the capability of resolving the SFF for the next SF based on certain constraints. Of course, it needs to know some information about the SFs in advance, e.g., the information about which SFFs a given SF is attached.

Best regards,
Xiaohu

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 08:40:33 +0000

Hi Joel,

Please see inline.

Cheers,
Med

>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mardi 15 juillet 2014 17:07
>À : BOUCADAIR Mohamed IMT/OLN; Tom Taylor; [email-masked]; Ron Parker

[Med] Several comments here:
* These are constraints as expressed in Ron's counter-proposal, that I still support. 
* I understand that if it is presented as an ** optional ** feature, but not as the base model. 
* At least many operator representatives who expressed their opinions in this thread are for a simple model that assumes a complete distributed forwarding model. You should also acknowledge that! 
* The architecture should not be drawn only from the perspective of the favorite option you support. 
* I'm for a requirement-driven approach + avoid over-specification + simplicity. The simplicity argument suggests to go for a distributed model as the base model. 
* There are also implications on device procurement that we should not ignore. The distributed model minimizes the need for another set of devices to be deployed because advanced features must be centralized. The model should not mandate a centralized approach; it can allow for it for those requiring it. This is again deployment-specific.

>and allows for expression of the exact choice when operations has

[Med] Some comments here:  
* a path has a connotation that we cannot ignore just because a term has been chosen in a given solution document (read nsh). 
* we need to make progress and ACK there are issues with the proposed approach in the merged draft and also the inaccurate terminology (read change SFP).
* there are various ways to communicate forwarding constraints to a node:
(1) this can be conveyed in the packet itself (by including some kind of Explicit Route Object as in RSVP-TE or a pointer to that object), 
(2) by relying on the chain itself + provisioning constraints directly to a subset of SFFs,
(3) Etc.
* A C-SFC can be expressed as an order list of elements: {element 1, element 2, element 3, .., element n} while an "element" can be structured as a Service Function Identifier or a Service Function Locator.

>used instead of the itnermediate it would remove the ability to meet the

[Med] Disagree. I do still think your analysis is biased with a solution in mind. The chain information is sufficient for a full distributed model. You can consider the parallel with a native IP networks where forwarding actions are undertaken based on the destination IP address. In a SFC domain, instead of using dest-IP, local forwarding actions can be rely solely on the chain identifier. It is not because there are MPLS/MPLS-TE/IP TE solution that every  operational network must support those!

>> As mentioned in several messages, I'm personally for the use of the chain
>itself is the main information to be conveyed in packets to drive
>forwarding actions.
>>
>> Joel, the use of "path" is really inappropriate to refer to distributed
>instance selection process for packets bound to a given SFC.
>>
>> Cheers,
>> Med
>>
>has
>packet
>architecture

---

From: <[email-masked]>
Date: Wed, 16 Jul 2014 08:53:36 +0000

Hi Xiaohu,

Please see inline.

Cheers,
Med

>Envoyé : mardi 15 juillet 2014 11:50
>In this way, the path selection process (i.e., selecting the appropriate
>SFF for the next SF based on certain constraints) on the SFF is greatly
>simplified.

[Med] This does not answer to my question why the "classifier" has specifically to take care of this? How multiple classifiers present in a given SFC-enabled domain behave in order to distribute traffic among available Service Function Nodes? How a classifier can distribute traffic without any conflict with other LBs that may be present in the forwarding path?

>The classifier could request the PCE to do the SFP computation (see
>http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is no
>need for the classifier to be fed with additional information.

[Med] Functionally, the classifier will need a path computation component. Whether these two are co-located or separated is implementation-specific. My concern is to require that path computation component as a mandatory component for the architecture. I think this is not justified.

>As I have said, the architecture should allow the classifier to just impose
>the SFC information on the selected packet as well. In this way, each SFF
>needs to resolve the appropriate next SFF for the next SF to be executed.

[Med] Yes, I understood that from you initial list. My question is how to package all this together without imposing complexity to deployments that do not require it.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 16 Jul 2014 10:14:53 +0000

Hi Med,

> Sent: Wednesday, July 16, 2014 4:54 PM
> >2014 11:50 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor;
> >> Why a classifier will need specify a path a la ERO? Why it needs to
> >> have
> >the full
> >
> >In this way, the path selection process (i.e., selecting the
> >appropriate SFF for the next SF based on certain constraints) on the
> >SFF is greatly simplified.
> 
> [Med] This does not answer to my question why the "classifier" has specifically
> to take care of this? How multiple classifiers present in a given SFC-enabled
> domain behave in order to distribute traffic among available Service Function
> Nodes? How a classifier can distribute traffic without any conflict with other LBs
> that may be present in the forwarding path?
> 
> >
> >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there is
> >no need for the classifier to be fed with additional information.
> 
> [Med] Functionally, the classifier will need a path computation component.
> Whether these two are co-located or separated is implementation-specific. My
> concern is to require that path computation component as a mandatory
> component for the architecture. I think this is not justified.

If the SFP computation is performed by the PCE, the classifier just needs to accept the computation result returned by the PCE and then impose the SFP info on the selected packets. In other words, the classifier doesn't need that SFP computation component anymore. Furthermore, if the classifier is just allowed to impose the SFC info on the selected packet, it doesn't need the SFP computation component as well.

> >As I have said, the architecture should allow the classifier to just
> >impose the SFC information on the selected packet as well. In this way,
> >each SFF needs to resolve the appropriate next SFF for the next SF to be
> executed.
> 
> [Med] Yes, I understood that from you initial list. My question is how to package
> all this together without imposing complexity to deployments that do not
> require it.

Since architecture allows three options, operators could make their own choices accordingly.

Best regards,.
Xiaohu

> >> >2014 10:49 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom
> >> >Taylor; [email-masked]; Ron Parker Objet : RE: [sfc] SFC Terminology /
> >> >Concepts
> >> >
> >> >Hi Med,
> >> >
> >> >> >SFP assignment is recorded in an identifier which travels with
> >> >> >the
> >packet.
> >> >> >
> >> >> >> am I right in seeing the implication that when control assigns
> >> >> >> an SFP, the assignment is recorded by an identifier wwhich
> >> >> >> travels with
> >> >the
> >> >> packet?
> >> >> >>
> >> >> >> Tom Taylor
> >> >> >>
> >> >> >>> "The Service Function Chain (SFC) provides a fully abstract
> >> >> >>> view of the service functions to be invoked and the order in
> >> >> >>> which they are to be invoked for some particular flow or set
> >> >> >>> of flows, without
> >> >concern of
> >> >> >>> (C-SFC) further allows for policy constraints to be added to
> >> >> >>> the SFC affecting the instance selection of one or more of the
> >> >> >>> service
> >> >functions
> >> >> >>> terminology and concepts used to describe the architecture in
> >> >> >>> the merged architecture draft, Joel has kindly suggested the
> following:
> >> >> >>>
> >> >> >>> abstract notion of service path as a sequence of functions to
> >> >> >>> be delivered, and the fully specified notion of exactly what
> >> >> >>> specify the use of this level of indirection, the deployment
> >> >> >>> may choose the degree of SFF instance selection authority that
> >> >> >>> is
> >delegated to
> >> the network."
> >> >> >>>
> >> >> >>> something that we can get consensus on. If so, I'll ask Joel
> >> >> >>> to provide specific text, that reflects the above, for
> >> >> >>> inclusion in the merged architecture draft.
> >> >> >>>
> >> >> >>> Thank You,
> >> >> >>>
> >> >> >>> Jim
> >> >> >>>
> >> >> >>>
> >> >> >>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 16 Jul 2014 13:23:12 -0400

I have gotten a bit lost in the SFF/SFC discussion, which seems to have gotten needlessly complicated and convoluted IMHO. 

	Is it possible for the chairs to add this to the list of things to discuss at the WG meeting or do we want to resolve this on the list ahead of the meeting?

	--Tom

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Wed, 16 Jul 2014 18:59:04 +0000

Joel, et. all,

I think that some of the questions in architecture (SFP/SFC chasing it's
tail) come as people look forward to the encapsulation/header document.
That's probably unavoidable.

When you read the NSH document, the SFP verbiage says that all
participants MUST forward on the SP/SPI, but the document doesn't say how
the SPI is derived/calculated (the vision here could be made clearer) or
what it's relationship is to the transport path (I think you can't mix and
match but can accommodate both within the header), should you opt for the
transport header forwarding.

It's obvious that some deployments prefer to use the transport header for
forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup (which
does play into the SPI or "other mechanisms" that populate a service table
in the SFF).

Perhaps the authors of NSH can suggest verbiage that makes the
relationship between transport-based forwarding and service-based
forwarding (SPI) clearer?

This should eliminate/minimize the calls for redefinition/recasting our
terminology and allow us to move on.

On 7/16/14 1:23 PM, "Thomas D. Nadeau" <[email-masked]> wrote:

>
>	I have gotten a bit lost in the SFF/SFC discussion, which seems to have
>gotten needlessly complicated and convoluted IMHO.
>
>	Is it possible for the chairs to add this to the list of things to
>discuss at the WG meeting or do we want to resolve this on the list ahead
>of the meeting?
>
>	--Tom
>
>
>> In either case, the SFF should be capable of selecting the appropriate
>>instance of a given SF attached to itself. it's an internal
>>load-balancing issue.
>> 
>> If you want the SFF to locally determine the appropriate SFF for the
>>next SF, the SFF should have the capability of resolving the SFF for the
>>next SF based on certain constraints. Of course, it needs to know some
>>information about the SFs in advance, e.g., the information about which
>>SFFs a given SF is attached.
>> 
>> Best regards,
>> Xiaohu
>> 
>>> Regards,
>>> Peng
>>> 
>>> 
>>> 
>>>> chain itself is the main information to be conveyed in packets to
>>>>drive
>>> forwarding actions.
>>>>

---

From: Henry Fourie <[email-masked]>
Date: Wed, 16 Jul 2014 21:36:55 +0000

Ken,
   The Service Chain Header draft https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/
conveys the following intent:

 From section 4.2 Mandatory Fields:

   Path Identifier: Identifies a fully instantiated service function
      path. It represents a sequence of network locators, one for each
      service function that is to be invoked. Participating SFC entities
      MUST use this identifier when selecting the next hop for the
      packet or frame.

>From section 4.4 Header Associated Operations:

   3. Service Path Selection. The Service Network Forwarder (SNF) uses
      the Service Chain Identification information in the SCH to steer
      the traffic flow along the SFC path.

   4. Service Function Instance Selection. The Service Function
      Forwarder (SFF) uses the Service Chain Identification information
      in the SCH to locate the service instance and forward the traffic
      flow to the service instance. The mapping of the Service Chain
      Identification to a service instance can be established through
      the management/control plane, which is out of scope of this
      document.

>From section 4.2 Mandatory Fields:

   Path Identifier: Identifies a fully instantiated service function
      path. It represents a sequence of network locators, one for each
      service function that is to be invoked. Participating SFC entities
      MUST use this identifier when selecting the next hop for the
      packet or frame.

>From section 4.4 Header Associated Operations:

   3. Service Path Selection. The Service Network Forwarder (SNF) uses
      the Service Chain Identification information in the SCH to steer
      the traffic flow along the SFC path.

   4. Service Function Instance Selection. The Service Function
      Forwarder (SFF) uses the Service Chain Identification information
      in the SCH to locate the service instance and forward the traffic
      flow to the service instance. The mapping of the Service Chain
      Identification to a service instance can be established through
      the management/control plane, which is out of scope of this
      document.

- Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Wednesday, July 16, 2014 11:59 AM
To: Thomas D. Nadeau; [email-masked]
Cc: [email-masked]; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Joel, et. all,

---

From: Henry Fourie <[email-masked]>
Date: Wed, 16 Jul 2014 21:39:45 +0000

Ken,
  The Service chain Header draft https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/
should answer some of your questions. In particular:

In section 4.2 Mandatory Fields:

In section 4.4 Header Associated Operations:

 - Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Wednesday, July 16, 2014 11:59 AM
To: Thomas D. Nadeau; [email-masked]
Cc: [email-masked]; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Joel, et. all,

---

From: Henry Fourie <[email-masked]>
Date: Wed, 16 Jul 2014 21:42:51 +0000

Ken,
    The Service Chain Header draft https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/
should answer some of your questions:

- Louis

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Wednesday, July 16, 2014 11:59 AM
To: Thomas D. Nadeau; [email-masked]
Cc: [email-masked]; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern; [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Joel, et. all,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Jul 2014 17:46:59 -0400

I would hope that we can end up with an archtiecture document that is 
understandable and useful without resorting to a specific solution 
document.  That is our goal.  There probably are refinements needed to 
achieve that goal.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 17 Jul 2014 05:53:04 +0000

Hi Xiaohu,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 16 juillet 2014 12:15

[Med] It seems you missed this one.

>If the SFP computation is performed by the PCE, the classifier just needs
>to accept the computation result returned by the PCE and then impose the
>SFP info on the selected packets. In other words, the classifier doesn't
>need that SFP computation component anymore. Furthermore, if the classifier
>is just allowed to impose the SFC info on the selected packet, it doesn't
>need the SFP computation component as well.

[Med] But still, for the sake of interoperability, the classifier need to be prepared for such interface with an external PCE module, no?

>Since architecture allows three options, operators could make their own

[Med] The problem is that packaging a lot of optional features will have an impact on the overall complexity of the solution. This is why I'm questioning having any possible feature as an optional part of the solution.

---

From: <[email-masked]>
Date: Thu, 17 Jul 2014 05:57:00 +0000

Hi Joel,

I fully agree with you about the goal. 

Nevertheless, the merged document, as it currently stands, includes some solution hints that come mainly from nsh. I would really hope the document be updated to be neutral. 

Cheers,
Med

>Envoyé : mercredi 16 juillet 2014 23:47
>À : Henry Fourie; [email-masked]
>SFP
>>>>>>>>> are to be invoked for some particular flow or set of flows,
>without
>>>>> concern of

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Jul 2014 21:33:47 +0000

Agree with what Med said. 

Cheers,
Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 17, 2014 12:57 AM
To: Joel M. Halpern; Henry Fourie; [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Hi Joel,

Cheers,
Med

>Envoyé : mercredi 16 juillet 2014 23:47 À : Henry Fourie; [email-masked] 
>>    The Service chain Header draft 
>> https://datatracker.ietf.org/doc/draft-
>zhang-sfc-sch/
>> participants MUST forward on the SP/SPI, but the document doesn't say 
>> how the SPI is derived/calculated (the vision here could be made 
>> clearer) or what it's relationship is to the transport path (I think 
>> you can't mix
>and
>> match but can accommodate both within the header), should you opt for 
>> the transport header forwarding.
>>
>> It's obvious that some deployments prefer to use the transport header 
>> for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup 
>> (which does play into the SPI or "other mechanisms" that populate a 
>> service
>table
>> in the SFF).
>>
>> This should eliminate/minimize the calls for redefinition/recasting 
>> our terminology and allow us to move on.
>>
>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu 
>>> <[email-masked]>
>>> wrote:
>>>
>>>> Hi Peng,
>>>>
>>>>> To: Xuxiaohu; [email-masked]; Joel M. Halpern; Tom 
>>>>> Taylor; [email-masked]; Ron Parker
>>>>> Try to understand the three scenarios you listed: you mean the 
>>>>> classifier can specify a (partial or complete) SFP which is a list 
>>>>> of SFFs, then each SFF will
>>>> In either case, the SFF should be capable of selecting the 
>>>> appropriate instance of a given SF attached to itself. it's an 
>>>> internal load-balancing issue.
>>>>
>>>>> The classifier (and SFF?) could obtain this  (SFF) 'path' 
>>>>> information
>>>> >from either
>>>>> centralized point (e.g., PCE, controller), or, via a distributed 
>>>>> control plane? For partial SFP, will there be a re-classification 
>>>>> to decide next SFF(s) or not?
>>>>
>>>> If you want the SFF to locally determine the appropriate SFF for 
>>>> the next SF, the SFF should have the capability of resolving the 
>>>> SFF for
>the
>>>> next SF based on certain constraints. Of course, it needs to know 
>>>> some information about the SFs in advance, e.g., the information 
>>>> about which SFFs a given SF is attached.
>>>>
>>>> Best regards,
>>>> Xiaohu
>>>>
>>>>> Regards,
>>>>> Peng
>>>>>
>>>>>
>>>>>
>>>>>> As mentioned in several messages, I'm personally for the use of 
>>>>>> the chain itself is the main information to be conveyed in 
>>>>>> packets to drive
>>>>> forwarding actions.
>>>>>>
>>>>>> I can understand that an identifier can be assigned to a path 
>>>>>> that is known in advance, but if that path is not known I'm not 
>>>>>> sure how an identifier can be assigned to it!
>>>>>>
>>>>>>>> travels with the
>>>>>>>>> of flows,
>>>>>>>>> the merged architecture draft, Joel has kindly suggested the following:
>>>>>>>>>
>>>>>>>>> is delegated to the network."
>>>>>>>>>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Thu, 17 Jul 2014 22:02:21 +0000

I don't think you should write the document in ignorance of the proposed header either.  There's gonna be a header.  Both proposals have a service path element (devil's advocate - you have a draft unwritten for a header without a Service Path abstraction - normalize documents, you're still a minority) and the question from both the editor and the chair were whether we could come to consensus on the meaning of Service Path (which then began the oddessy of trying to diferentiate it from Service Chain).  I don't see hints at a solution around the use of Service Path that are wildly different enough to say one is favored over the other.

I interpreted some of the comments about the Service Chain to be rooted in the fear that one must forward on the Service Path (not appealing to transport-header-centrists), which may/may_not have been clear.

To return to the original question - I haven't really seen a compelling argument why Joel's original proposition will not suffice.

Sent from my iPhone

> On Jul 17, 2014, at 5:34 PM, "Linda Dunbar" <[email-masked]> wrote:
>

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 17 Jul 2014 23:17:16 +0000

Hi Thomas,

I am not sure we will have time to fully discuss this during the
face-to-face meeting as the agenda is already jam packed. Let¹s continue
the discussion on the list and see what Joel & Carlos are able to produce
in terms of text and go from there. I would ask however that members of
this WG that have not already commented on my email entitled ³SFC
Terminology / Concepts² please do so so that we can better gauge consensus
of the WG on this issue.

On 7/16/14, 1:23 PM, "Thomas D. Nadeau" <[email-masked]> wrote:

>>>classifier can
>>>control plane? For

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 18 Jul 2014 02:24:10 +0000

Hi Med,

> Sent: Thursday, July 17, 2014 1:53 PM
> >De : Xuxiaohu [mailto:[email-masked]] Envoyé : mercredi 16 juillet
> >2014 12:15 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom Taylor;
> >> >2014 11:50 À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; Tom
> >> >> Why a classifier will need specify a path a la ERO? Why it needs
> >> >> to have
> >> >the full
> >> >
> >> to take care of this? How multiple classifiers present in a given
> >> SFC-
> >enabled
> >> Nodes? How a classifier can distribute traffic without any conflict
> >> with
> >other LBs

As I has mentioned before, once the SFP is determined by the classifier in advance, there is no need for subsequent SFFs to do complex path selection work anymore (e.g., no need to maintain the SF->SFF mapping table and no need to resolve the appropriate SFF for the next SF on basis on certain constraints). Of course, in order to optimize the traffic forwarding path (i.e., the SFP), a stateful PCE could be used to do the path computation work. By the way, in the distributed and dynamic SFP selection process (i.e., each SFF independently determine the appropriate SFF for the next SF), how to ensure that optimization of the traffic forwarding path?

> >> >> be fed with additional information to drive its selection process?
> >> >> Is
> >> >this
> >> >
> >> >http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01). As such, there
> >> >is no need for the classifier to be fed with additional information.
> >>
> >If the SFP computation is performed by the PCE, the classifier just
> >needs to accept the computation result returned by the PCE and then
> >impose the SFP info on the selected packets. In other words, the
> >classifier doesn't need that SFP computation component anymore.
> >Furthermore, if the classifier is just allowed to impose the SFC info
> >on the selected packet, it doesn't need the SFP computation component as
> well.
> 
> [Med] But still, for the sake of interoperability, the classifier need to be prepared
> for such interface with an external PCE module, no?

Yes, the classifier should act as a PCC.

> >> >impose the SFC information on the selected packet as well. In this
> >> >way, each SFF needs to resolve the appropriate next SFF for the next
> >> >SF to be
> >> executed.
> >>
> >> [Med] Yes, I understood that from you initial list. My question is
> >> how to
> >package
> >> all this together without imposing complexity to deployments that do
> >> not require it.
> >
> [Med] The problem is that packaging a lot of optional features will have an
> impact on the overall complexity of the solution. This is why I'm questioning
> having any possible feature as an optional part of the solution.

How about listing those three options in the architecture draft and saying that either is applicable in some cases.

Best regards,
Xiaohu

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Jul 2014 08:53:18 -0400

Correct.  The definition (sect 1.3) itself is very open and allows for a number of header options:

> delivering traffic . . . via information carried in the SFC encapsulation.

From: [email-masked]<[email-masked]>
To: Linda Dunbar<[email-masked]>
cc: Henry Fourie<[email-masked]>,Joel M.
 Halpern<[email-masked]>,[email-masked]<[email-masked]>,[email-masked]<[email-masked]>
Sent: Thursday, July 17, 2014
Subject: Re: [sfc] SFC Terminology / Concepts

Sent from my iPhone

On Jul 17, 2014, at 5:34 PM, "Linda Dunbar" <[email-masked]> wrote:> > Agree with what Med said. > > Cheers,> Linda> > -----Original Message-----> From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]> Sent: Thursday, July 17, 2014 12:57 AM> To: Joel M. Halpern; Henry Fourie; [email-masked]> Subject: Re: [sfc] SFC Terminology / Concepts> > Hi Joel,> > I fully agree with you about the goal. > > Nevertheless, the merged document, as it currently stands, includes some solution hints that come mainly from nsh. I would really hope the document be updated to be neutral. > > Cheers,> Med> >> -----Message d'origine----->> De : sfc [mailto:[email-masked]] De la part de Joel M. Halpern >> Envoyé : mercredi 16 juillet 2014 23:47 À : Henry Fourie; [email-masked] >> Objet : Re: [sfc] SFC Terminology / Concepts>> >> I would hope that we can end up with an archtiecture document that is >> understandable and useful without resorting to a specific solution >> document.  That is our goal.  There probably are refinements needed to >> achieve that goal.>> >> Yours,>> Joel>> >>> On 7/16/14, 5:39 PM, Henry Fourie wrote:>>> Ken,>>>   The Service chain Header draft >>> https://datatracker.ietf.org/doc/draft->> zhang-sfc-sch/>>> should answer some of your questions. In particular:>>> >>> In section 4.2 Mandatory Fields:>>> >>>    Path Identifier: Identifies a fully instantiated service function>>>       path. It represents a sequence of network locators, one for each>>>       service function that is to be invoked. Participating SFC entities>>>       MUST use this identifier when selecting the next hop for the>>>       packet or frame.>>> >>> In section 4.4 Header Associated Operations:>>> >>>    3. Service Path Selection. The Service Network Forwarder (SNF) uses>>>       the Service Chain Identification information in the SCH to steer>>>       the traffic flow along the SFC path.>>> >>>    4. Service Function Instance Selection. The Service Function>>>       Forwarder (SFF) uses the Service Chain Identification information>>>       in the SCH to locate the service instance and forward the traffic>>>       flow to the service instance. The mapping of the Service Chain>>>       Identification to a service instance can be established through>>>       the management/control plane, which is out of scope of this>>>       document.>>> >>>  - Louis>>> >>> -----Original Message----->>> From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray >>> (kegray)>>> Sent: Wednesday, July 16, 2014 11:59 AM>>> To: Thomas D. Nadeau; [email-masked]>>> Cc: [email-masked]; He, Peng; Ron Parker; Tom Taylor; Joel M. Halpern;>> [email-masked]>>> Subject: Re: [sfc] SFC Terminology / Concepts>>> >>> Joel, et. all,>>> >>> I think that some of the questions in architecture (SFP/SFC chasing >>> it's>>> tail) come as people look forward to the encapsulation/header document.>>> That's probably unavoidable.>>> >>> When you read the NSH document, the SFP verbiage says that all >>> participants MUST forward on the SP/SPI, but the document doesn't say >>> how the SPI is derived/calculated (the vision here could be made >>> clearer) or what it's relationship is to the transport path (I think >>> you can't mix>> and>>> match but can accommodate both within the header), should you opt for >>> the transport header forwarding.>>> >>> It's obvious that some deployments prefer to use the transport header >>> for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop lookup >>> (which does play into the SPI or "other mechanisms" that populate a >>> service>> table>>> in the SFF).>>> >>> Perhaps the authors of NSH can suggest verbiage that makes the >>> relationship between transport-based forwarding and service-based >>> forwarding (SPI) clearer?>>> >>> This should eliminate/minimize the calls for redefinition/recasting >>> our terminology and allow us to move on.>>> >>>> On 7/16/14 1:23 PM, "Thomas D. Nadeau" <[email-masked]> wrote:>>>> >>>> >>>>    I have gotten a bit lost in the SFF/SFC discussion, which seems to>> have>>>> gotten needlessly complicated and convoluted IMHO.>>>> >>>>    Is it possible for the chairs to add this to the list of things to >>>> discuss at the WG meeting or do we want to resolve this on the list>> ahead>>>> of the meeting?>>>> >>>>    --Tom>>>> >>>> >>>> On Jul 15, 2014:10:57 PM, at 10:57 PM, Xuxiaohu >>>> <[email-masked]>>>>> wrote:>>>> >>>>> Hi Peng,>>>>> >>>>>> -----Original Message----->>>>>> From: He, Peng [mailto:[email-masked]]>>>>>> Sent: Tuesday, July 15, 2014 9:09 PM>>>>>> To: Xuxiaohu; [email-masked]; Joel M. Halpern; Tom >>>>>> Taylor; [email-masked]; Ron Parker>>>>>> Subject: RE: [sfc] SFC Terminology / Concepts>>>>>> >>>>>> Try to understand the three scenarios you listed: you mean the >>>>>> classifier can specify a (partial or complete) SFP which is a list >>>>>> of SFFs, then each SFF will>>>>>> (locally) select one of the SF instances under itself for this SF. >>>>>> For partial SFP case,>>>>> >>>>> In either case, the SFF should be capable of selecting the >>>>> appropriate instance of a given SF attached to itself. it's an >>>>> internal load-balancing issue.>>>>> >>>>>> each SFF will identify the SFI under itself and specify (like a>>>>>> classifier) next SFF(s).>>>>>> The classifier (and SFF?) could obtain this  (SFF) 'path' >>>>>> information>>>>>> from either>>>>>> centralized point (e.g., PCE, controller), or, via a distributed >>>>>> control plane? For partial SFP, will there be a re-classification >>>>>> to decide next SFF(s) or not?>>>>> >>>>> If you want the SFF to locally determine the appropriate SFF for >>>>> the next SF, the SFF should have the capability of resolving the >>>>> SFF for>> the>>>>> next SF based on certain constraints. Of course, it needs to know >>>>> some information about the SFs in advance, e.g., the information >>>>> about which SFFs a given SF is attached.>>>>> >>>>> Best regards,>>>>> Xiaohu>>>>> >>>>>> Regards,>>>>>> Peng>>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----->>>>>> From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu>>>>>> Sent: Tuesday, July 15, 2014 4:49 AM>>>>>> To: [email-masked]; Joel M. Halpern; Tom Taylor; >>>>>> [email-masked]; Ron Parker>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts>>>>>> >>>>>> Hi Med,>>>>>> >>>>>> IMHO, the architecture should allow the classifier to specify>>>>>> >>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP need to >>>>>> locally determine the appropriate SFF for the next SF);>>>>>> 2) a complete SFP (i.e., the SFF for each SF in the SFC has been >>>>>> determined by the centralized node);>>>>>> 3) an SFC (i.e., each SFF along the final SFP needs to locally >>>>>> determine the appropriate SFF for the next SF).>>>>>> >>>>>> In fact, case 3) could be looked as an extreme of case 1).>>>>>> >>>>>> Best regards,>>>>>> Xiaohu>>>>>> >>>>>>> -----Original Message----->>>>>>> From: sfc [mailto:[email-masked]] On Behalf Of >>>>>>> [email-masked]>>>>>>> Sent: Tuesday, July 15, 2014 3:22 PM>>>>>>> To: Joel M. Halpern; Tom Taylor; [email-masked]; Ron Parker>>>>>>> Subject: Re: [sfc] SFC Terminology / Concepts>>>>>>> >>>>>>> Hi Joel,>>>>>>> >>>>>>> As mentioned in several messages, I'm personally for the use of >>>>>>> the chain itself is the main information to be conveyed in >>>>>>> packets to drive>>>>>> forwarding actions.>>>>>>> >>>>>>> I can understand that an identifier can be assigned to a path >>>>>>> that is known in advance, but if that path is not known I'm not >>>>>>> sure how an identifier can be assigned to it!>>>>>>> >>>>>>> Joel, the use of "path" is really inappropriate to refer to >>>>>>> distributed instance selection process for packets bound to a >>>>>>> given SFC.>>>>>>> >>>>>>> Cheers,>>>>>>> Med>>>>>>> >>>>>>>> -----Message d'origine----->>>>>>>> De : sfc [mailto:[email-masked]] De la part de Joel M. >>>>>>>> Halpern Envoyé : lundi 14 juillet 2014 21:52 À : Tom Taylor; >>>>>>>> [email-masked]; Ron Parker Objet : Re: [sfc] SFC Terminology / >>>>>>>> Concepts>>>>>>>> >>>>>>>> The most likely realization of the architecture would be that >>>>>>>> the>> SFP>>>>>>>> assignment is recorded in an identifier which travels with the >>>>>>>> packet.>>>>>>>> >>>>>>>> Some folks seem to not want the architecture to mandate that.>>>>>>>> >>>>>>>> Yours,>>>>>>>> Joel>>>>>>>> >>>>>>>> >>>>>>>>> On 7/14/14, 2:37 PM, Tom Taylor wrote:>>>>>>>>> Your text scares me because it introduces some new concepts and >>>>>>>>> assumptions.>>>>>>>>> >>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on that:>>>>>>>>> am I right in seeing the implication that when control assigns >>>>>>>>> an SFP, the assignment is recorded by an identifier wwhich >>>>>>>>> travels with the>>>>>>> packet?>>>>>>>>> >>>>>>>>> Tom Taylor>>>>>>>>> >>>>>>>>>> On 14/07/2014 2:22 PM, Ron Parker wrote:>>>>>>>>>> There is one missing word in my text.   Please replace my proposed>>>>>>>>>> text>>>>>>>>>> with:>>>>>>>>>> >>>>>>>>>> "The Service Function Chain (SFC) provides a fully abstract >>>>>>>>>> view of the service functions to be invoked and the order in >>>>>>>>>> which they are to be invoked for some particular flow or set >>>>>>>>>> of flows,>> without>>>>>> concern of>>>>>>>>>> actual service function instance selection.   The Constrained-SFC>>>>>>>>>> (C-SFC) further allows for policy constraints to be added to >>>>>>>>>> the SFC affecting the instance selection of one or more of the >>>>>>>>>> service>>>>>> functions>>>>>>>>>> in the SFC.   Any SFC may have any number of C-SFC's associated>>>>>>>>>> with>>>>>>>> it.">>>>>>>>>> >>>>>>>>>> Thanks.>>>>>>>>>> >>>>>>>>>>     Ron>>>>>>>>> ...>>>>>>>>> >>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *David >>>>>>>>>> Allan I>>>>>>>>>> *Sent:* Monday, July 14, 2014 2:03 PM>>>>>>>>>> *To:* Jim Guichard (jguichar); [email-masked] >>>>>>>>>> <mailto:[email-masked]>>>>>>>>>>> *Subject:* Re: [sfc] SFC Terminology / Concepts>>>>>>>>>> >>>>>>>>>> I like that text, it strikes a good balance where an >>>>>>>>>> implementation has the option of making scale and resiliency a >>>>>>>>>> local>>>>>> matter..>>>>>>>>>> >>>>>>>>>> D>>>>>>>>>> >>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim >>>>>>>>>> Guichard>>>>>>>>>> (jguichar)>>>>>>>>>> *Sent:* Monday, July 14, 2014 10:48 AM>>>>>>>>>> *To:* [email-masked] <mailto:[email-masked]>>>>>>>>>>> *Subject:* [sfc] SFC Terminology / Concepts>>>>>>>>>> >>>>>>>>>> Dear WG:>>>>>>>>>> >>>>>>>>>> There has been much debate over the last few days with regards >>>>>>>>>> to SFC concepts. To try and form some consensus around >>>>>>>>>> terminology and concepts used to describe the architecture in >>>>>>>>>> the merged architecture draft, Joel has kindly suggested the following:>>>>>>>>>> >>>>>>>>>> "The SFP provides a level of indirection between the fully >>>>>>>>>> abstract notion of service path as a sequence of functions to >>>>>>>>>> be delivered, and the fully specified notion of exactly what >>>>>>>>>> instances of SFFs the packet will visit when it actually >>>>>>>>>> traverses the network. By allowing the control components to >>>>>>>>>> specify the use of this level of indirection, the deployment >>>>>>>>>> may choose the degree of SFF instance selection authority that >>>>>>>>>> is delegated to the network.">>>>>>>>>> >>>>>>>>>> I'd like to ask the WG as a whole, if this clarification is >>>>>>>>>> something that we can get consensus on. If so, I'll ask Joel >>>>>>>>>> to provide specific text, that reflects the above, for >>>>>>>>>> inclusion in the merged architecture draft.>>>>>>>>>> >>>>>>>>>> Thank You,>>>>>>>>>> >>>>>>>>>> Jim>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________>>>>>>>>>> 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, 18 Jul 2014 14:16:20 +0000

> As I has mentioned before, once the SFP is determined by the classifier in
> advance, there is no need for subsequent SFFs to do complex path selection
> work anymore (e.g., no need to maintain the SF->SFF mapping table and no
> need to resolve the appropriate SFF for the next SF on basis on certain
> constraints). 

Why is this complex? It works today pretty well. 
And managing, e.g., 160K SFPs per chain is not complex? (4 hop chain with 20 instances/SFFs at each hop)

>Of course, in order to optimize the traffic forwarding path (i.e.,
> the SFP), a stateful PCE could be used to do the path computation work. By
> the way, in the distributed and dynamic SFP selection process (i.e., each SFF
> independently determine the appropriate SFF for the next SF), how to
> ensure that optimization of the traffic forwarding path?

Carrying the path information in the packet is not the only way to implement traffic engineering.
An SFC system can be instructed to choose a specific SF instance. This is still a service chain, which just happens to use a specific SF instance (among many) as opposed to a service chain where that choice is arbitrary.

> > >> Whether these two are co-located or separated is implementation-
> specific.
> > >My

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Jul 2014 11:00:32 -0400

I suspect that there are two separate but related issues.

The architecture we proposed, and probably any useful archtiecture, does 
constrain solutions.  In adopting an archtiecture, the working group 
makes some choices.

At the same time, those constraints should general, not specific, and 
certainly not aimed at the NSH solution in particular.

Yours,
Joel

---

From: Lucy yong <[email-masked]>
Date: Fri, 18 Jul 2014 20:38:12 +0000

The architecture we proposed, and probably any useful archtiecture, does constrain solutions.  In adopting an archtiecture, the working group makes some choices.
[Lucy] not so sure. We should adopt an architecture without making solution choices ahead. The architecture leads solution development, not the other way.

At the same time, those constraints should general, not specific, and certainly not aimed at the NSH solution in particular.
[Lucy] Yes and Agree.

Lucy

On 7/17/14, 1:57 AM, [email-masked] wrote:
>> Envoyé : mercredi 16 juillet 2014 23:47 À : Henry Fourie; 
>> [email-masked] Objet : Re: [sfc] SFC Terminology / Concepts
>>
>> document.  That is our goal.  There probably are refinements needed 
>> to achieve that goal.
>>
>> Yours,
>> Joel
>>
>>> participants MUST forward on the SP/SPI, but the document doesn't 
>>> say how the SPI is derived/calculated (the vision here could be made 
>>> match but can accommodate both within the header), should you opt 
>>> for the transport header forwarding.
>>>
>>> It's obvious that some deployments prefer to use the transport 
>>> header for forwarding (SR, IGP/anycast) and some prefer a hop-by-hop 
>>> lookup (which does play into the SPI or "other mechanisms" that 
>>> populate a service
>> table
>>> in the SFF).
>>>
>>>>>> classifier can specify a (partial or complete) SFP which is a 
>>>>>> list of SFFs, then each SFF will
>>>>>>>>> Your text scares me because it introduces some new concepts 
>>>>>>>>> and assumptions.
>>>>>>>>>
>>>>>>>>>> the SFC affecting the instance selection of one or more of 
>>>>>>>>>> the service
>>>>>> functions
>>>>>>>>>> There has been much debate over the last few days with 
>>>>>>>>>> regards to SFC concepts. To try and form some consensus 
>>>>>>>>>> around terminology and concepts used to describe the 
>>>>>>>>>> architecture in the merged architecture draft, Joel has kindly suggested the following:
>>>>>>>>>>
>>>>>>>>>> may choose the degree of SFF instance selection authority

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 20 Jul 2014 00:44:46 +0000

The MTU section of the merged-sfc-arch is one example showing what Med said about the current architecture "including some solution hints that come mainly from nsh".

An important part of SFC is the SFC header encapsulation. 
Therefore, the MTU section should emphasize the importance of avoiding packets fragmentation and reassembly because most service functions, especially legacy L4-L7 service functions, don't expect fragmented packets. It is very expensive for intermediate SFF/SN nodes to reassemble packets before passing packets to Service Functions. E.g. The SFC header should avoid literally listing the addresses (especially IPv6 addresses) of the service functions in a service function chain.

But final MTU Section emphasizes that the modern systems can handle packets fragmentation and reassembly, meaning NSH header (no matter how long) is no problem.

I had a two separate conference calls  with the authors of the SFC-architecture draft addressing suggested merging of some content from "legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than 1 hour). 

One of the issues being discussed is the MTU section. Here is text that I suggested to merge with the general "sfc-arch":

"Encapsulating SFC header to data packets has to take MTU size into consideration because most service functions, especially legacy L4-L7 service functions, don't expect fragmented packets. 
It is very expensive for intermediate SFF/SN nodes to reassemble packets before passing packets to Service Functions. 
Therefore, the information carried by the SFC header has to be compact. The SFC header should avoid literally listing the addresses (especially IPv6 addresses) of the service functions in a service function chain."

I sincerely hope that the authors can take this text (or variation of this text) for the MTU section of sfc-arch. 

Linda

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 17, 2014 12:57 AM
To: Joel M. Halpern; Henry Fourie; [email-masked]
Subject: Re: [sfc] SFC Terminology / Concepts

Hi Joel,

Cheers,
Med

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 19 Jul 2014 21:05:59 -0400

I am sorry that we forgot to make the improvements we had discussed with
you to the MTU section.  We should have improved it as part of producing 
this draft.

We will improve the text, making use of your text as much as we can.  I 
expect that we will emphasis the fact that SF can not be expected to 
perform reassembly, and that having SFF or proxy functions do it for 
them is also very expensive.

My inclination is to focus on your points about the importance of 
compactness, rather than particularly on L4-L7 or particularly on 
listing addresses.   I think trying to get to specific about things to 
avoid will weaken the text, and cause contention.

Yours,
Joel

On 7/19/14, 8:44 PM, Linda Dunbar wrote:
> The MTU section of the merged-sfc-arch is one example showing what
> Med said about the current architecture "including some solution
> hints that come mainly from nsh".
>
>
> An important part of SFC is the SFC header encapsulation. Therefore,
> the MTU section should emphasize the importance of avoiding packets
> fragmentation and reassembly because most service functions,
> especially legacy L4-L7 service functions, don't expect fragmented
> packets. It is very expensive for intermediate SFF/SN nodes to
> reassemble packets before passing packets to Service Functions. E.g.
> The SFC header should avoid literally listing the addresses
> (especially IPv6 addresses) of the service functions in a service
> function chain.
>
> But final MTU Section emphasizes that the modern systems can handle
> packets fragmentation and reassembly, meaning NSH header (no matter
> how long) is no problem.
>
>
> I had a two separate conference calls  with the authors of the
> SFC-architecture draft addressing suggested merging of some content
> from "legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than
> 1 hour).
>
> One of the issues being discussed is the MTU section. Here is text
> that I suggested to merge with the general "sfc-arch":
>
> "Encapsulating SFC header to data packets has to take MTU size into
> consideration because most service functions, especially legacy L4-L7
> service functions, don't expect fragmented packets. It is very
> expensive for intermediate SFF/SN nodes to reassemble packets before
> passing packets to Service Functions. Therefore, the information
> carried by the SFC header has to be compact. The SFC header should
> avoid literally listing the addresses (especially IPv6 addresses) of
> the service functions in a service function chain."
>
> I sincerely hope that the authors can take this text (or variation of
> this text) for the MTU section of sfc-arch.
>
> Linda
>
> -----Original Message----- From: sfc [mailto:[email-masked]] On
> Behalf Of [email-masked] Sent: Thursday, July 17, 2014
> 12:57 AM To: Joel M. Halpern; Henry Fourie; [email-masked] Subject: Re:
> [sfc] SFC Terminology / Concepts
>
> Hi Joel,
>
> Nevertheless, the merged document, as it currently stands, includes
> some solution hints that come mainly from nsh. I would really hope
> the document be updated to be neutral.
>
> Cheers, Med
>
>> -----Message d'origine----- De : sfc [mailto:[email-masked]]
>> De la part de Joel M. Halpern Envoyé : mercredi 16 juillet 2014
>> 23:47 À : Henry Fourie; [email-masked] Objet : Re: [sfc] SFC
>> Terminology / Concepts
>>
>> I would hope that we can end up with an archtiecture document that
>> is understandable and useful without resorting to a specific
>> solution document.  That is our goal.  There probably are
>> refinements needed to achieve that goal.
>>
>> Yours, Joel
>>
>>> Ken, The Service chain Header draft
>>> Path Identifier: Identifies a fully instantiated service
>>> function path. It represents a sequence of network locators, one
>>> for each service function that is to be invoked. Participating
>>> SFC entities MUST use this identifier when selecting the next hop
>>> for the packet or frame.
>>>
>>> 3. Service Path Selection. The Service Network Forwarder (SNF)
>>> uses the Service Chain Identification information in the SCH to
>>> steer the traffic flow along the SFC path.
>>>
>>> Forwarder (SFF) uses the Service Chain Identification
>>> information in the SCH to locate the service instance and forward
>>> the traffic flow to the service instance. The mapping of the
>>> Service Chain Identification to a service instance can be
>>> established through the management/control plane, which is out of
>>> scope of this document.
>>>
>>> - Louis
>>>
>>> -----Original Message----- From: sfc
>>> [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
>>> Sent: Wednesday, July 16, 2014 11:59 AM To: Thomas D. Nadeau;
>>> [email-masked] Cc: [email-masked]; He, Peng; Ron Parker; Tom
>>> Taylor; Joel M. Halpern;
>>> I think that some of the questions in architecture (SFP/SFC
>>> chasing it's tail) come as people look forward to the
>>> encapsulation/header document. That's probably unavoidable.
>>>
>>> say how the SPI is derived/calculated (the vision here could be
>>> made clearer) or what it's relationship is to the transport path
>>> (I think you can't mix
>> and
>>> header for forwarding (SR, IGP/anycast) and some prefer a
>>> hop-by-hop lookup (which does play into the SPI or "other
>>> mechanisms" that populate a service
>> table
>>> in the SFF).
>>>
>>> relationship between transport-based forwarding and
>>> service-based forwarding (SPI) clearer?
>>>
>>> This should eliminate/minimize the calls for
>>> redefinition/recasting our terminology and allow us to move on.
>>>
>>>> I have gotten a bit lost in the SFF/SFC discussion, which seems
>>>> to
>> have
>>>> Is it possible for the chairs to add this to the list of things
>>>> to discuss at the WG meeting or do we want to resolve this on
>>>> the list
>> ahead
>>>> of the meeting?
>>>>
>>>> --Tom
>>>>
>>>>
>>>> <[email-masked]> wrote:
>>>>
>>>>> Hi Peng,
>>>>>
>>>>>> -----Original Message----- From: He, Peng
>>>>>> [mailto:[email-masked]] Sent: Tuesday, July 15, 2014 9:09
>>>>>> PM To: Xuxiaohu; [email-masked]; Joel M.
>>>>>> Halpern; Tom Taylor; [email-masked]; Ron Parker Subject: RE:
>>>>>> [sfc] SFC Terminology / Concepts
>>>>>>
>>>>>> Try to understand the three scenarios you listed: you mean
>>>>>> the classifier can specify a (partial or complete) SFP
>>>>>> which is a list of SFFs, then each SFF will (locally)
>>>>>> select one of the SF instances under itself for this SF.
>>>>>> For partial SFP case,
>>>>>
>>>>> appropriate instance of a given SF attached to itself. it's
>>>>> an internal load-balancing issue.
>>>>>
>>>>>> each SFF will identify the SFI under itself and specify
>>>>>> (like a classifier) next SFF(s). The classifier (and SFF?)
>>>>>> could obtain this  (SFF) 'path' information from either
>>>>>> centralized point (e.g., PCE, controller), or, via a
>>>>>> distributed control plane? For partial SFP, will there be a
>>>>>> re-classification to decide next SFF(s) or not?
>>>>>
>>>>> If you want the SFF to locally determine the appropriate SFF
>>>>> for the next SF, the SFF should have the capability of
>>>>> resolving the SFF for
>> the
>>>>> next SF based on certain constraints. Of course, it needs to
>>>>> know some information about the SFs in advance, e.g., the
>>>>> information about which SFFs a given SF is attached.
>>>>>
>>>>> Best regards, Xiaohu
>>>>>
>>>>>> Regards, Peng
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: sfc
>>>>>> [mailto:[email-masked]] On Behalf Of Xuxiaohu Sent:
>>>>>> Tuesday, July 15, 2014 4:49 AM To:
>>>>>> [email-masked]; Joel M. Halpern; Tom Taylor;
>>>>>> [email-masked]; Ron Parker Subject: Re: [sfc] SFC Terminology
>>>>>> / Concepts
>>>>>>
>>>>>> Hi Med,
>>>>>>
>>>>>> 1) a partial SFP (i.e., some SFFs along that partial SFP
>>>>>> need to locally determine the appropriate SFF for the next
>>>>>> SF); 2) a complete SFP (i.e., the SFF for each SF in the
>>>>>> SFC has been determined by the centralized node); 3) an SFC
>>>>>> (i.e., each SFF along the final SFP needs to locally
>>>>>> Best regards, Xiaohu
>>>>>>> -----Original Message----- From: sfc
>>>>>>> [mailto:[email-masked]] On Behalf Of
>>>>>>> [email-masked] Sent: Tuesday, July 15, 2014
>>>>>>> 3:22 PM To: Joel M. Halpern; Tom Taylor; [email-masked];
>>>>>>> Ron Parker Subject: Re: [sfc] SFC Terminology / Concepts
>>>>>>>
>>>>>>> Hi Joel,
>>>>>>>
>>>>>>> As mentioned in several messages, I'm personally for the
>>>>>>> use of the chain itself is the main information to be
>>>>>>> conveyed in packets to drive
>>>>>> forwarding actions.
>>>>>>>
>>>>>>> I can understand that an identifier can be assigned to a
>>>>>>> path that is known in advance, but if that path is not
>>>>>>> known I'm not sure how an identifier can be assigned to
>>>>>>> it!
>>>>>>>
>>>>>>> Joel, the use of "path" is really inappropriate to refer
>>>>>>> to distributed instance selection process for packets
>>>>>>> bound to a given SFC.
>>>>>>>
>>>>>>> Cheers, Med
>>>>>>>
>>>>>>>> -----Message d'origine----- De : sfc
>>>>>>>> [mailto:[email-masked]] De la part de Joel M.
>>>>>>>> Halpern Envoyé : lundi 14 juillet 2014 21:52 À : Tom
>>>>>>>> Taylor; [email-masked]; Ron Parker Objet : Re: [sfc] SFC
>>>>>>>> Terminology / Concepts
>>>>>>>>
>>>>>>>> Yours, Joel
>>>>>>>>> Your text scares me because it introduces some new
>>>>>>>>> concepts and assumptions.
>>>>>>>>>
>>>>>>>>> I'd rather go with Joel's formulation. Clarifying
>>>>>>>>> question on that: am I right in seeing the
>>>>>>>>> implication that when control assigns an SFP, the
>>>>>>>>> assignment is recorded by an identifier wwhich
>>>>>>>>> travels with the
>>>>>>> packet?
>>>>>>>>>
>>>>>>>>> Tom Taylor
>>>>>>>>>
>>>>>>>>>> "The Service Function Chain (SFC) provides a fully
>>>>>>>>>> abstract view of the service functions to be
>>>>>>>>>> invoked and the order in which they are to be
>>>>>>>>>> invoked for some particular flow or set of flows,
>> without
>>>>>> concern of
>>>>>>>>>> actual service function instance selection.   The
>>>>>>>>>> Constrained-SFC (C-SFC) further allows for policy
>>>>>>>>>> constraints to be added to the SFC affecting the
>>>>>>>>>> instance selection of one or more of the service
>>>>>> functions
>>>>>>>>>> in the SFC.   Any SFC may have any number of
>>>>>>>>>> C-SFC's associated with
>>>>>>>> it."
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> Ron
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf
>>>>>>>>>> Of *David Allan I *Sent:* Monday, July 14, 2014
>>>>>>>>>> 2:03 PM *To:* Jim Guichard (jguichar);
>>>>>>>>>> [email-masked] <mailto:[email-masked]> *Subject:* Re:
>>>>>>>>>> [sfc] SFC Terminology / Concepts
>>>>>>>>>>
>>>>>>>>>> I like that text, it strikes a good balance where
>>>>>>>>>> an implementation has the option of making scale
>>>>>>>>>> and resiliency a local
>>>>>> matter..
>>>>>>>>>>
>>>>>>>>>> D
>>>>>>>>>>
>>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf
>>>>>>>>>> Of *Jim Guichard (jguichar) *Sent:* Monday, July
>>>>>>>>>> 14, 2014 10:48 AM *To:* [email-masked]
>>>>>>>>>> <mailto:[email-masked]> *Subject:* [sfc] SFC
>>>>>>>>>> Terminology / Concepts
>>>>>>>>>>
>>>>>>>>>> Dear WG:
>>>>>>>>>>
>>>>>>>>>> There has been much debate over the last few days
>>>>>>>>>> with regards to SFC concepts. To try and form some
>>>>>>>>>> consensus around terminology and concepts used to
>>>>>>>>>> describe the architecture in the merged
>>>>>>>>>> "The SFP provides a level of indirection between
>>>>>>>>>> the fully abstract notion of service path as a
>>>>>>>>>> sequence of functions to be delivered, and the
>>>>>>>>>> fully specified notion of exactly what instances of
>>>>>>>>>> SFFs the packet will visit when it actually
>>>>>>>>>> traverses the network. By allowing the control
>>>>>>>>>> components to specify the use of this level of
>>>>>>>>>> indirection, the deployment may choose the degree
>>>>>>>>>> I'd like to ask the WG as a whole, if this
>>>>>>>>>> clarification is something that we can get
>>>>>>>>>> consensus on. If so, I'll ask Joel to provide
>>>>>>>>>> specific text, that reflects the above, for
>>>>>>>>>> _______________________________________________ sfc
>>>>>>>>>> mailing list [email-masked]
>>>>>>>>> _______________________________________________ sfc
>>>>>>>>> mailing list [email-masked]
>>>>>>>> _______________________________________________ sfc
>>>>>>>> mailing list [email-masked]
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [email-masked]
>>>>>> _______________________________________________ sfc mailing
>>>>>> list [email-masked]
>>>>> _______________________________________________ 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: Linda Dunbar <[email-masked]>
Date: Sun, 20 Jul 2014 01:18:07 +0000

Joel, 

Thanks for the acknowledgement. 

Linda

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Saturday, July 19, 2014 8:06 PM
To: Linda Dunbar; [email-masked]; Henry Fourie; [email-masked]
Subject: Re: MTU section of merged-sfc-arch should emphasize the importance of avoiding packets fragmentation/reassembly, not how modern systems can handle packets fragmentation/reassembly

I am sorry that we forgot to make the improvements we had discussed with you to the MTU section.  We should have improved it as part of producing this draft.

We will improve the text, making use of your text as much as we can.  I expect that we will emphasis the fact that SF can not be expected to perform reassembly, and that having SFF or proxy functions do it for them is also very expensive.

My inclination is to focus on your points about the importance of compactness, rather than particularly on L4-L7 or particularly on 
listing addresses.   I think trying to get to specific about things to 
avoid will weaken the text, and cause contention.

Yours,
Joel

On 7/19/14, 8:44 PM, Linda Dunbar wrote:
> The MTU section of the merged-sfc-arch is one example showing what Med 
> said about the current architecture "including some solution hints 
> that come mainly from nsh".
>
>
> some solution hints that come mainly from nsh. I would really hope the 
> document be updated to be neutral.
>
> Cheers, Med
>
>> -----Message d'origine----- De : sfc [mailto:[email-masked]] De 
>> la part de Joel M. Halpern Envoyé : mercredi 16 juillet 2014
>>> MUST use this identifier when selecting the next hop for the packet 
>>> or frame.
>>>
>>> the Service Chain Identification information in the SCH to steer the 
>>> traffic flow along the SFC path.
>>>
>>> Forwarder (SFF) uses the Service Chain Identification information in 
>>> the SCH to locate the service instance and forward the traffic flow 
>>> to the service instance. The mapping of the Service Chain 
>>> Identification to a service instance can be established through the 
>>> management/control plane, which is out of scope of this document.
>>>
>>> - Louis
>>>
>>> -----Original Message----- From: sfc [mailto:[email-masked]] 
>>> On Behalf Of Ken Gray (kegray)
>>> I think that some of the questions in architecture (SFP/SFC chasing 
>>> it's tail) come as people look forward to the encapsulation/header 
>>> document. That's probably unavoidable.
>>>
>>>>>> -----Original Message----- From: He, Peng [mailto:[email-masked]] 
>>>>>> Sent: Tuesday, July 15, 2014 9:09 PM To: Xuxiaohu; 
>>>>>> [email-masked]; Joel M.
>>>>>> list of SFFs, then each SFF will (locally) select one of the SF 
>>>>>> instances under itself for this SF.
>>>>>> For partial SFP case,
>>>>>
>>>>>> each SFF will identify the SFI under itself and specify (like a 
>>>>>> classifier) next SFF(s). The classifier (and SFF?) could obtain 
>>>>>> this  (SFF) 'path' information from either centralized point 
>>>>>> (e.g., PCE, controller), or, via a distributed control plane? For 
>>>>>> [email-masked]; Ron Parker Subject: Re: [sfc] SFC Terminology / 
>>>>>> Concepts
>>>>>>
>>>>>> Hi Med,
>>>>>>
>>>>>> locally determine the appropriate SFF for the next SF); 2) a 
>>>>>> complete SFP (i.e., the SFF for each SF in the SFC has been 
>>>>>> determined by the centralized node); 3) an SFC (i.e., each SFF 
>>>>>> along the final SFP needs to locally determine the appropriate 
>>>>>> SFF for the next SF).
>>>>>>
>>>>>>> 3:22 PM To: Joel M. Halpern; Tom Taylor; [email-masked]; Ron 
>>>>>>> Parker Subject: Re: [sfc] SFC Terminology / Concepts
>>>>>>>
>>>>>>> Hi Joel,
>>>>>>>
>>>>>>>>> I'd rather go with Joel's formulation. Clarifying question on 
>>>>>>>>> that: am I right in seeing the implication that when control 
>>>>>>>>> assigns an SFP, the assignment is recorded by an identifier 
>>>>>>>>> wwhich travels with the
>>>>>>> packet?
>>>>>>>>>
>>>>>>>>> Tom Taylor
>>>>>>>>>
>>>>>>>>>> Constrained-SFC (C-SFC) further allows for policy constraints 
>>>>>>>>>> to be added to the SFC affecting the instance selection of 
>>>>>>>>>> one or more of the service
>>>>>> functions
>>>>>>>>>> Allan I *Sent:* Monday, July 14, 2014
>>>>>>>>>> 2:03 PM *To:* Jim Guichard (jguichar); [email-masked] 
>>>>>>>>>> <mailto:[email-masked]> *Subject:* Re:
>>>>>>>>>> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim 
>>>>>>>>>> Guichard (jguichar) *Sent:* Monday, July 14, 2014 10:48 AM 
>>>>>>>>>> *To:* [email-masked] <mailto:[email-masked]> *Subject:* [sfc] SFC 
>>>>>>>>>> Terminology / Concepts
>>>>>>>>>>
>>>>>>>>>> Dear WG:
>>>>>>>>>>
>>>>>>>>>> architecture in the merged architecture draft, Joel has 
>>>>>>>>>> kindly suggested the
>>>>>>>>>> following:
>>>>>>>>>>

---

From: Ron Parker <[email-masked]>
Date: Sun, 20 Jul 2014 01:41:25 +0000

Linda,

I'm not debating that fragmentation should be minimized.   But, wrt legacy SF's -- if the transport + service encaps increases the packet enough to cause fragmentation, wouldn't it be at the transport level and not at the level of the original packet?   [Given that it can only be so for fragmentable transports (ie ipv4, ipv6)]. 

   Ron

> On Jul 19, 2014, at 8:45 PM, "Linda Dunbar" <[email-masked]> wrote:
> 
>>> it's
>>>>>> classifier) next SFF(s).
>>>>>>>>>> Guichard

---

From: Linda Dunbar <[email-masked]>
Date: Sun, 20 Jul 2014 23:46:08 +0000

Ron, 

Answer inserted below:

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

Linda,

I'm not debating that fragmentation should be minimized.   But, wrt legacy SF's -- if the transport + service encaps increases the packet enough to cause fragmentation, wouldn't it be at the transport level and not at the level of the original packet?  

[Linda] We are in agreement that the fragmentation at transport level requires the SFF nodes to reassemble fragmented packets before passing to SF nodes. 

 [Given that it can only be so for fragmentable transports (ie ipv4, ipv6)]. 

[Linda] Routers do not fragment IPv6 packets, as they do for IPv4. So SFC header for IPv6 has to be more compact. 

   Ron

>>>> to discuss at the WG meeting or do we want to resolve this on the 
>>>> list
>> ahead
>>>> of the meeting?
>>>> 
>>>>    --Tom
>>>> 
>>>>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sun, 20 Jul 2014 23:54:47 +0000

So, we'd agree it's no special concern because it's SFC - only because of
the generic, often-visited, often-cited concern when "the header is
extend" (presumably - though, I wouldn't want to presume a solution)"?

Out of curiosity, what non-fragmentable transport should we be concerned
about?

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

>I'm not debating that fragmentation should be minimized.   But, wrt
>legacy SF's -- if the transport + service encaps increases the packet
>enough to cause fragmentation, wouldn't it be at the transport level and
>not at the level of the original packet?
>
>[Linda] We are in agreement that the fragmentation at transport level
>requires the SFF nodes to reassemble fragmented packets before passing to
>SF nodes. 
>
>
>>said about the current architecture "including some solution hints that
>>come mainly from nsh".
>> 
>> 
>> Therefore, the MTU section should emphasize the importance of avoiding
>>packets fragmentation and reassembly because most service functions,
>>reassemble packets before passing packets to Service Functions. E.g. The
>>SFC header should avoid literally listing the addresses (especially IPv6
>>addresses) of the service functions in a service function chain.
>> 
>>packets fragmentation and reassembly, meaning NSH header (no matter how
>>long) is no problem.
>> 
>> 
>>SFC-architecture draft addressing suggested merging of some content from
>>"legacy-l4-l7-arch" to general "sfc-arch" (each lasted more than 1
>>hour). 
>> 
>> One of the issues being discussed is the MTU section. Here is text that
>>I suggested to merge with the general "sfc-arch":
>> 
>>service functions, don't expect fragmented packets.
>> It is very expensive for intermediate SFF/SN nodes to reassemble
>>packets before passing packets to Service Functions.
>> Therefore, the information carried by the SFC header has to be compact.
>>The SFC header should avoid literally listing the addresses (especially
>>IPv6 addresses) of the service functions in a service function chain."
>> 
>>>>>>>>>>that:
>>>>>>>>>>>Constrained-SFC