Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

From: <[email-masked]>
Date: Tue, 17 Nov 2015 13:34:19 +0000

Hi Paul,

Thank you for sharing your feedback.

RFC7665 says the following:

"
This architecture does not mandate the degree of
   specificity of the SFP.  Architecturally, within the same SFC-enabled
   domain, some SFPs may be fully specified, selecting exactly which SFF
   and which SF are to be visited by packets using that SFP, while other
   SFPs may be quite vague, deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC.  The
   specificity may be anywhere in between these extremes.
"

The control draft is completely aligned with that approach. 

The control-plane document allows in particular to provision required information when "deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC". It happens that information is no more than the service chain itself (without any constraints).

Also, the current control-plane document allows to instruct a loose path (SFP) or a strict path (RSP), etc. 

I fully agree that whether a full path is specified within a domain or if it is deferred to SFFs is really deployment-specific. Nevertheless, the control plan should accommodate all these flavors. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Quinn (paulq) [mailto:[email-masked]]
> Envoyé : vendredi 16 octobre 2015 14:04
> À : Joel M. Halpern
> Cc : BOUCADAIR Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc-control-
> [email-masked]; [email-masked]
> Objet : Re: [sfc] #15 (control-plane): Whether the control plane operates
> on SFC IDs, SFP IDs, etc.
> 
> Joel,
> 
> I concur.
> 
> The data plane deal with paths, not chains.  The relationship of paths to
> chains falls squarely in the control plane (or even more likely "policy"
> plane) realm.  The specificity of the path is left to implementation, in
> the architecture draft, but that's consistent with your position and
> provides the requisite functionality.
> 
> Paul
> 
> > On Sep 17, 2015, at 11:36 AM, Joel M. Halpern <[email-masked]>
> wrote:
> >
> > As far as I can tell, there is nothing in the Service Chaining work that
> requires correlating service path IDs with service chain IDs within the
> data plane.  Any such relationship exists entirely within the control
> plane or above, and would be driven by requirements other than the data
> plane.  When I look at this document, all of the requirements that talk
> about service function chain IDs can be accurately captured, in terms of
> data plane requirements, by service function path IDs.  Thus, the
> requirement that the data plane has is to see such path IDs.  Yes, in some
> deployments those will be 1-1 with chain IDs.  They are still path IDs.
> >
> > Introducing a requirement for the data plane to see and work with chain
> IDs is not grounded in the work of the group.
> >
> > Yours,
> > Joel M. Halpern
> >
> > On 9/17/15 7:53 AM, [email-masked] wrote:
> >> Re-,
> >>
> >> The control draft as it stands is compliant with the data plane
> architecture document.
> >>
> >> Indeed, the arch draft acknowledges the following:
> >> (1) SFPs are "associated with a given SFC".
> >> (2) SFPs are presented as a form of constrained SFCs.
> >> (3) Some deployments may not impose any constraint on the abstract SFC.
> >> (4) Some others may impose either loose or strict routes.
> >>
> >> Requiring SFP IDs for deployments that do not impose any constraint on
> the SFC is an oxymoron because according to the data plane architecture,
> an SFP is a "constrained version of the original SFC".
> >>
> >> For deployments that do not impose any constraint on the abstract SFC,
> but adopt a fully distributed SFC forwarding strategy, a chain identifier
> is sufficient.
> >>
> >> Because an SFP may be associated with several SFCs, the identifier of
> the SFC may be required to associate an SFP with its SFC.
> >>
> >> Below an excerpt from the arch draft, fwiw:
> >> ==========
> >>    A service function path (SFP) is a mechanism used by service
> chaining
> >>    to express the result of applying more granular policy and
> >>    operational constraints to the abstract requirements of a service
> >>    chain (SFC).  This architecture does not mandate the degree of
> >>    specificity of the SFP.  Architecturally, within the same SFC-
> enabled
> >>    domain, some SFPs may be fully specified, selecting exactly which
> SFF
> >>    and which SF are to be visited by packets using that SFP, while
> other
> >>    SFPs may be quite vague, deferring to the SFF the decisions about
> the
> >>    exact sequence of steps to be used to realize the SFC.  The
> >>    specificity may be anywhere in between these extremes.
> >>
> >>    As an example of such an intermediate specificity, there may be two
> >>    SFPs associated with a given SFC, where one SFP specifies that any
> >>    order of SFF and SF may be used as long as it is within data center
> >>    1, and where the second SFP allows the same latitude, but only
> within
> >>    data center 2.
> >>
> >>    Thus, the policies and logic of SFP selection or creation (depending
> >>    upon the solution) produce what may be thought of as a constrained
> >>    version of the original SFC.  Since multiple policies may apply to
> >>    different traffic that uses the same SFC, it also follows that there
> >>    may be multiple SFPs may be associated with a single SFC.
> >> =======
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Joel M. Halpern [mailto:[email-masked]]
> >>> Envoyé : mercredi 16 septembre 2015 19:15
> >>> À : sfc issue tracker; [email-masked];
> >>> BOUCADAIR Mohamed IMT/OLN
> >>> Cc : [email-masked]
> >>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane
> operates
> >>> on SFC IDs, SFP IDs, etc.
> >>>
> >>> Given that we have an adopted architecture that specifies that the
> >>> system should function in terms of service function paths, I would
> >>> prefer that the control requirements draft align with the architecture
> >>> in that regard.  We are, as far as I know, specifying the requirements
> >>> for control mechanisms in support of the architecture and data plane
> we
> >>> standardize.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 9/16/15 9:46 AM, sfc issue tracker wrote:
> >>>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc.
> >>>>
> >>>>   The draft includes this note:
> >>>>
> >>>>            [[Note: The question of whether the data plane operates
> just
> >>> in
> >>>>            terms of SFP IDs or needs SFC IDs, as described in this
> >>> version
> >>>>            of the draft, is still under discussion among the
> authors.]]
> >>>>
> >>>>   The current version of the draft is more generic as it does not
> >>> preclude
> >>>>   manipulating service chains based on an identifier of the chain.
> Also,
> >>> it
> >>>>   does not assume that the SFP indirection level is mandatory (SFP
> IDs).
> >>>>
> >>>>   Note the current version accommodates various deployment contexts:
> >>> e.g.,
> >>>>   rely solely on a chain ID, rely on a chain ID and a SFP, supply a
> >>> strict
> >>>>   path, supply a loose path, etc. The purpose is to not dictate
> >>> deployment
> >>>>   choices on how forwarding is actually achieved within an SFC-
> enabled
> >>>>   domain.
> >>>>
> >>>>   An identifier of the chain is the minimum information that is
> needed,
> >>> but
> >>>>   other information may be supplied as well.
> >>>>
> >>>>   Feedback from the WG about which information to supply is needed.
> >>>>
> >>>>   FWIW, there is a ticket issue for this issue for the nsh spec.
> >>>>
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc

---

From: Joel Halpern <[email-masked]>
Date: Tue, 17 Nov 2015 13:48:49 +0000

Your statement that " It happens that information is no more than the service chain itself (without any constraints)." (Where "it" refers to " the exact sequence of steps to be used to realize the SFC".) Does not make sense to me.  The SFC is the general description of the objective.  That is not the same as the exact sequence of places that must be visited.

I stand by my earlier comments that almost all uses of SFC in the control requirements draft should be SFP.

Yours,
Joel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 8:34 AM
To: Paul Quinn (paulq)
Cc: sfc issue tracker; [email-masked]; [email-masked]; Joel M. Halpern
Subject: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Paul,

"

Cheers,
Med

> De : Paul Quinn (paulq) [mailto:[email-masked]] Envoyé : vendredi 16 
> octobre 2015 14:04 À : Joel M. Halpern Cc : BOUCADAIR Mohamed IMT/OLN; 
> sfc issue tracker; draft-ietf-sfc-control- [email-masked]; 
> [email-masked] Objet : Re: [sfc] #15 (control-plane): Whether the 
> control plane operates on SFC IDs, SFP IDs, etc.
> 
> Joel,
> 
> I concur.
> 
> The data plane deal with paths, not chains.  The relationship of paths 
> to chains falls squarely in the control plane (or even more likely "policy"
> plane) realm.  The specificity of the path is left to implementation, 
> in the architecture draft, but that's consistent with your position 
> and provides the requisite functionality.
> 
> Paul
> 
> requires correlating service path IDs with service chain IDs within 
> the data plane.  Any such relationship exists entirely within the 
> control plane or above, and would be driven by requirements other than 
> the data plane.  When I look at this document, all of the requirements 
> that talk about service function chain IDs can be accurately captured, 
> in terms of data plane requirements, by service function path IDs.  
> Thus, the requirement that the data plane has is to see such path IDs.  
> Yes, in some deployments those will be 1-1 with chain IDs.  They are still path IDs.
> >
> >> (3) Some deployments may not impose any constraint on the abstract SFC

---

From: <[email-masked]>
Date: Tue, 17 Nov 2015 14:02:42 +0000

Hi Joel, 

Please see inline. 

Cheers,
Med

> De : Joel Halpern [mailto:[email-masked]]
> Envoyé : mardi 17 novembre 2015 14:49
> À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq)
> Cc : sfc issue tracker; [email-masked];
> [email-masked]; Joel M. Halpern
> Objet : RE: [sfc] #15 (control-plane): Whether the control plane operates
> Your statement that " It happens that information is no more than the
> service chain itself (without any constraints)." (Where "it" refers to "
> the exact sequence of steps to be used to realize the SFC".) Does not make
> sense to me. 

[Med] RFC 7665 says:

"   Thus, the policies and logic of SFP selection or creation (depending
   upon the solution) produce what may be thought of as a constrained
   version of the original SFC. " 

in short: SFP is defined as a constrained version of the original SFC.

What is the name to use to refer to a "non-constrained" SFC or to the information that you will provision to an SFF when the path computation and selection decision is "deferred to the SFF"?

It does not make sense to call a non-constrained version of the SFC as SFP given that RFC7665 explicitly defines SFP as "constrained version of the original SFC"!

 The SFC is the general description of the objective.  That
> is not the same as the exact sequence of places that must be visited.
> 

[Med] I noted that Joel.. that's fair but this position is IMHO not aligned with RFC7665 that allows to control any variation from a non-constrained SFC to a fully constrained SFC. 

> The control-plane document allows in particular to provision required
> information when "deferring to the SFF the decisions about the
>    exact sequence of steps to be used to realize the SFC". It happens that
> information is no more than the service chain itself (without any
> constraints).
> 
> I fully agree that whether a full path is specified within a domain or if
> it is deferred to SFFs is really deployment-specific. Nevertheless, the
> control plan should accommodate all these flavors.
> 
> Cheers,
> Med
>

---

From: Joel Halpern <[email-masked]>
Date: Tue, 17 Nov 2015 14:06:10 +0000

What is provisioned into the SFF reflects the SFP.  The control system decides whether that SFP indicates the same set of all possible choices that the SFC does, or is a proper subset.  

In order to allow for an SFP that reflects meaningful constraints, what is provisioned has to be the SFP.
No special provision is needed for the case where the SFP is isomorphic to the SFC. In such a case, you still provision the SFP.  And the result is an SFP with as much flexibility as the SFC.

If, in contrast, you declare that the provisioning includes the SFC then you are introducing extra complexity without adding any new cases that can be handled.

Yours,
Joel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2015 9:03 AM
To: Joel Halpern; Paul Quinn (paulq)
Cc: sfc issue tracker; [email-masked]; [email-masked]; Joel M. Halpern
Subject: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Joel, 

Please see inline. 

Cheers,
Med

> À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq) Cc : sfc issue 
> tracker; [email-masked];
> Objet : RE: [sfc] #15 (control-plane): Whether the control plane 
> operates on SFC IDs, SFP IDs, etc.
> 
> the exact sequence of steps to be used to realize the SFC".) Does not 
> make sense to me.

[Med] RFC 7665 says:

> I stand by my earlier comments that almost all uses of SFC in the 
> control requirements draft should be SFP.
> 

>    exact sequence of steps to be used to realize the SFC". It happens 
> that information is no more than the service chain itself (without any 
> constraints).
> 
> Also, the current control-plane document allows to instruct a loose 
> path
> (SFP) or a strict path (RSP), etc.
> 
> I fully agree that whether a full path is specified within a domain or 
> if it is deferred to SFFs is really deployment-specific. Nevertheless, 
> the control plan should accommodate all these flavors.
> 
> Cheers,
> Med
> 
> > De : Paul Quinn (paulq) [mailto:[email-masked]] Envoyé : vendredi 
> > 16 octobre 2015 14:04 À : Joel M. Halpern Cc : BOUCADAIR Mohamed 
> > IMT/OLN; sfc issue tracker; draft-ietf-sfc-control- 
> > [email-masked]; [email-masked] Objet : Re: [sfc] #15 
> > (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.
> >
> > Joel,
> >
> > I concur.
> >
> > The data plane deal with paths, not chains.  The relationship of 
> > paths to chains falls squarely in the control plane (or even more 
> > likely
> "policy"
> > plane) realm.  The specificity of the path is left to 
> > implementation, in the architecture draft, but that's consistent 
> > with your position and provides the requisite functionality.
> >
> > Paul
> >
> > control plane or above, and would be driven by requirements other 
> > than the data plane.  When I look at this document, all of the 
> > requirements that talk about service function chain IDs can be 
> > accurately captured, in terms of data plane requirements, by service function path IDs.
> > >> (3) Some deployments may not impose any constraint on the 
> > >> abstract
> SFC

---

From: <[email-masked]>
Date: Tue, 17 Nov 2015 14:27:58 +0000

Re-,

Thank you for engaging. 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 17 novembre 2015 15:06
> What is provisioned into the SFF reflects the SFP.

[Med] Which one? Given than multiple SFPs may be bound to the same SFC 

Excerpt from RFC7665:

" Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs associated with a single SFC."

The text talks about policies that are applied to the traffic whiteout any precision where these policies are applied. 

  The control system
> decides whether that SFP indicates the same set of all possible choices
> that the SFC does, or is a proper subset.

[Med] That's indeed a valid case. The control plane accommodates that case. 

> provisioned has to be the SFP.

[Med] I would call that RSP. That's more clear.

> No special provision is needed for the case where the SFP is isomorphic to
> the SFC. In such a case, you still provision the SFP.  And the result is
> an SFP with as much flexibility as the SFC.

[Med] This is confusing, Joel. SFP cannot be isomorphic to the SFC as the definition of an SFP is a "constrained version of SFC" (that is clearly mentioned in RFC7665). I'm for more consistency in the use of the notions we are manipulating. 

> 
> If, in contrast, you declare that the provisioning includes the SFC then
> you are introducing extra complexity without adding any new cases that can
> be handled.

[Med] I'm not sure to see this extra complexity. I do even see benefits in having access to the SFC information allows, e.g., correlate between a service path and a chain in deployments where a path may be shared among multiple chains.

> What is the name to use to refer to a "non-constrained" SFC or to the
> information that you will provision to an SFF when the path computation
> and selection decision is "deferred to the SFF"?
> 
> It does not make sense to call a non-constrained version of the SFC as SFP
> given that RFC7665 explicitly defines SFP as "constrained version of the
> original SFC"!
> 
> [Med] I noted that Joel.. that's fair but this position is IMHO not
> aligned with RFC7665 that allows to control any variation from a non-
> constrained SFC to a fully constrained SFC.
> 
> > Yours,
> > Joel
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Nov 2015 22:56:34 -0500

Let me trying phrasing this differently.
A Service Function Chain (SFC) effectively designates a (potentially 
large) collection of sequences of SFF and SF visitations, any one of 
which would satisfy the the SFC.

An Service Function Path (SFP) designates a subset of the collection 
designated by the SFC. For some SFPs, in some deployments, that will be 
a set of 1.  For other SFPs (in the same or other deployments) it may be 
a larger set.  For some SFPs in some deployments the SFP may designate 
the same set of choices as the SFC.

Formally, the SFP is a subset of the SFC, but not necessarily a proper 
subset.

By always having control provision in terms of SFPs, the data plane 
always sees the effects of the constraints that control has placed in 
selecting the SFP.  And because of the definition of SFP, this allows 
the range of deplooyments the working group has requested.

Add SFC information into the provisioning does not increase the 
capability.  It does not, in fact, add any information tha thte 
forwarding can use.

Yours,
Joel

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 07:45:57 +0000

Hi Joel, all,

(The discussion is going in the right direction as it helps to see where is the disconnect)

Please see inline. 

Cheers,
Med 

> Envoyé : mercredi 18 novembre 2015 04:57
> À : BOUCADAIR Mohamed IMT/OLN; Joel Halpern; Paul Quinn (paulq)

[Med] This is a new definition, Joel. 

An SFC is no more than "an
        ordered set of abstract service functions and ordering
        constraints that must be applied to packets and/or frames and/or
        flows selected as a result of classification." 

Instantiating an SFC may lead to a collection of sequences of SFFs/SF, but still those collections are INSTANTIATIONS of a SINGLE SFC. An instantiation of an SFC may or may not be known in advance. This is deployment-specific: some may go for a fully distributed scheme, others for centralized, others for an hierarchical approach, etc.  

> designated by the SFC. 

[Med] I acknowledge this is subtle, but still you are proposing a new definition. I prefer the one in the data arch RFC:

" The SFP provides a level of indirection between the
        fully abstract notion of service chain as a sequence of abstract
        service functions to be delivered, and the fully specified
        notion of exactly which SFF/SFs the packet will visit when it
        actually traverses the network." 

BTW, this definition from RFC7665 is odd since it defines SFP by itself:

"The service function path is a
        constrained specification of where packets assigned to a certain
        service function path must go."

For some SFPs, in some deployments, that will be
> Formally, the SFP is a subset of the SFC, but not necessarily a proper

[Med] Again, this is subtle but I still disagree. I would agree if you said "the SFP is an SFC instantiation" to be aligned with this text from the data arch RFC: 

"Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs associated with a single SFC."

> selecting the SFP.

[Med] still works with s/SFPs/"SFCs and/or SFPs".

  And because of the definition of SFP, this allows
> the range of deplooyments the working group has requested.

[Med] No problem with that part since SFP is vague enough.

> capability.  It does not, in fact, add any information tha thte

[Med] I does, as it allows to drive the forwarding decision-making process when the service path computation and selection is fully distributed, when policies are not enforced at a centralized point but in various points of the network (e.g., hierarchical), etc.  

> > The text talks about policies that are applied to the traffic whiteout
> any precision where these policies are applied.
> >
> >    The control system
> >> In order to allow for an SFP that reflects meaningful constraints, what
> is
> >> provisioned has to be the SFP.
> >
> > [Med] This is confusing, Joel. SFP cannot be isomorphic to the SFC as
> the definition of an SFP is a "constrained version of SFC" (that is
> clearly mentioned in RFC7665). I'm for more consistency in the use of the
> notions we are manipulating.
> >
> >>
> > [Med] I'm not sure to see this extra complexity. I do even see benefits
> in having access to the SFC information allows, e.g., correlate between a
> service path and a chain in deployments where a path may be shared among
> multiple chains.
> >
> >>
> >> Yours,
> >> Joel
> >>
> >> Subject: RE: [sfc] #15 (control-plane): Whether the control plane
> operates

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 Nov 2015 10:51:43 +0000

I am a bit baffled to see this thread again — it appears the discussion restarted to continue in circles.

Med,

I too agree with Joel and strongly believe there is no need for SFC identification passed down — there is no provisioning of SFCs southbound.

(Almost) every instance of “SFC” in the control-plane requirements draft should really say “SFP”. There is no use of talking about SFCs towards the data plane. The relationship between chains and paths is a policy matter which belongs in the policy/control itself, but not out of there.

This is no different than what I said a few months ago on the same topic.

Thanks,

— Carlos.

> On Nov 17, 2015, at 9:06 AM, Joel Halpern <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 13:08:31 +0000

Carlos, 

This is an open issue for this draft, so it is normal to continue discussing it. I don't know how you can conclude in advance that we are circling.

"strongly believe" is not a technical argument, btw.

Cheers,
Med

> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Envoyé : mercredi 18 novembre 2015 11:52
> À : Joel Halpern
> Cc : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq); draft-ietf-sfc-
> [email-masked]; Joel M. Halpern; sfc issue tracker;
> [email-masked]
> I too agree with Joel and strongly believe there is no need for SFC
> identification passed down — there is no provisioning of SFCs southbound.
> 
> (Almost) every instance of “SFC” in the control-plane requirements draft
> should really say “SFP”. There is no use of talking about SFCs towards the
> data plane. The relationship between chains and paths is a policy matter
> which belongs in the policy/control itself, but not out of there.
> 
> > What is provisioned into the SFF reflects the SFP.  The control system
> is provisioned has to be the SFP.
> > No special provision is needed for the case where the SFP is isomorphic
> to the SFC. In such a case, you still provision the SFP.  And the result
> is an SFP with as much flexibility as the SFC.
> >
> > It does not make sense to call a non-constrained version of the SFC as
> SFP given that RFC7665 explicitly defines SFP as "constrained version of
> the original SFC"!
> >

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 14:03:45 +0000

HI Carlos, dear all,

Maybe it is the naming and the extreme generalization in some IDs which reopened the discussion.

My current (obvious) picture is:

1.) A service described by what we call policies may result in a graph (SFG) and branching conditions.

2.) Allowed service chains are walks through that graph fulfilling the policy rules. SFG -> SFC = 1:n.

3.) A topological (in the sense of abstract) SFC may be mapped onto a set of SFPs. SFC -> SFP = 1:m.

4.) The SFPs may  still include some degrees of freedom (routing to different instances of SFs etc).

5.) Therefore the notion of a rendered path (R-SFP or RSP) which is the final unique path for a certain flow. SFP -> RSP = 1:r

In this picture the SFP definition is something in between a SFC and the eventual rendered path. 

If above (trivial)  interpretation is correct I could argue that from the logical point of view I could use the mappings

1.) SFC -> SFP -> RSP or 
2.) SFC -> RSP directly.

To me the real value of the intermediate SFP is not obvious from the logical point of view. For sure it may help in the implementation of an abstraction breakdown.
Do I miss something? The question SFP-ID or  RSP-ID seems to be also addressed to the WG at the end of the NSH draft.

If I would use SFP instead of RSP  in the NSH and SFF FW tables there may be remaining ambiguities in selecting the RSP.
In this case I even could  use a SFC-ID  in NSH and assume the SFF has all the intelligence to resolve the path ambiguities.

For sure you could construct anything in between. But this is probably the origin of the renewed discussion. In that light and accepting we are orbiting  I support Med's attempt to clarify these topics.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Carlos Pignataro (cpignata)
Gesendet: Mittwoch, 18. November 2015 11:52
An: Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Med,

Thanks,

— Carlos.

>> Envoyé : mardi 17 novembre 2015 14:49 À : BOUCADAIR Mohamed IMT/OLN; 
>> Paul Quinn (paulq) Cc : sfc issue tracker; 
>> [email-masked];
>> that information is no more than the service chain itself (without 
>> any constraints).
>> 
>> I fully agree that whether a full path is specified within a domain 
>> or if it is deferred to SFFs is really deployment-specific. 
>> Nevertheless, the control plan should accommodate all these flavors.
>> 
>> Cheers,
>> Med
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 Nov 2015 14:35:07 +0000

Med,

> On Nov 18, 2015, at 8:08 AM, [email-masked] wrote:
> 
> Carlos,
> 

Discussion is great, Med. But my ‘we are circling' comment (not in advanced, but already evident) is because I saw the same questions, same arguments, and same answers as before.

> "strongly believe" is not a technical argument, btw.

Well, I believe so on technical grounds! Most of which have already been said, so I do not want to contribute to the circular discussion.

The control-plane draft talks about “SFC forwarding” and “SFC data plane”, and “SFC IDs”. The architecture says that SFC are made of abstract service functions. There’s no actual forwarding in this abstract conceptual model.

The control-plane draft says “Suppose the SFC ID for this SFP is "yellow”,”, and my point again is that in the data plane an SFP has an identifier (which identifies the SFP (SFP-ID) and is not the identifier of something else, it’s not a Topology-ID, it’s not a SKU, it’s not a URI, it’s not a Family Name, and not an SFC ID), and the control (and policy) plane can of course work with SFCs.

My $0.02.

Thanks,

— Carlos.

---

From: Ron Parker <[email-masked]>
Date: Wed, 18 Nov 2015 14:35:11 +0000

Hi, Walter.

One rationale behind the 1:N SFP-to-RSP relationship was to enable "late binding" by the SFF.    Thus, there could be a delegation of responsibility such that control plane chose SFP (e.g., HTTP-optimizer-silver-instances --> Firewall-silver-instances) and then allow classifier and SFF's to autonomously finalize the unique RSP.   Upon failure of one of the elements in the RSP, the classifier and SFF's could perform local repair by moving to a different RSP that respects the original SFP.

That being said, a 1:N can always degenerate to 1:1 -- that is in some deployment scenarios, SFPs do, indeed, represent unique RSPs.   This, of course, requires all aspects of failure recovery to be handled in the control plane.   

I think both deployment scenarios are entirely valid and we wanted to keep the architecture open enough to support both.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Wednesday, November 18, 2015 9:04 AM
To: Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

HI Carlos, dear all,

1.) SFC -> SFP -> RSP or
2.) SFC -> RSP directly.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Carlos Pignataro (cpignata)
Gesendet: Mittwoch, 18. November 2015 11:52
An: Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Med,

Thanks,

— Carlos.

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 15:03:58 +0000

Carlos, 

There is not SFC ID in the core text of the control plane draft. 

The text you quoted is part of an appendix with a note that clearly states this is not discussed. A corresponding issue record has been recorded to seek for more feedback on that appendix. 

Cheers,
Med

> Envoyé : mercredi 18 novembre 2015 15:35
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Paul Quinn (paulq); [email-masked]; Joel
> M. Halpern; sfc issue tracker; [email-masked]; Joel Halpern
> > This is an open issue for this draft, so it is normal to continue
> discussing it. I don't know how you can conclude in advance that we are
> circling.
> >
> 
> Discussion is great, Med. But my ‘we are circling' comment (not in
> advanced, but already evident) is because I saw the same questions, same
> arguments, and same answers as before.
> 
> Well, I believe so on technical grounds! Most of which have already been
> said, so I do not want to contribute to the circular discussion.
> 
> The control-plane draft talks about “SFC forwarding” and “SFC data plane”,
> and “SFC IDs”. The architecture says that SFC are made of abstract service
> functions. There’s no actual forwarding in this abstract conceptual model.
> 
> The control-plane draft says “Suppose the SFC ID for this SFP is
> "yellow”,”, and my point again is that in the data plane an SFP has an
> identifier (which identifies the SFP (SFP-ID) and is not the identifier of
> something else, it’s not a Topology-ID, it’s not a SKU, it’s not a URI,
> it’s not a Family Name, and not an SFC ID), and the control (and policy)
> plane can of course work with SFCs.
> 
> My $0.02.
> 
> Thanks,
> 
> — Carlos.
> 
> > Cheers,
> > Med
> >
> >>>> service chain itself (without any constraints)." (Where "it" refers
> to
> >> "
> any
> or

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 15:16:05 +0000

Hi Walter, 

Thank you for sharing your views. 

Please see inline. 

Cheers,
Med

> De : Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
> Envoyé : mercredi 18 novembre 2015 15:04
> À : Carlos Pignataro (cpignata); Joel Halpern
> Cc : sfc issue tracker; [email-masked]; Paul Quinn (paulq); draft-ietf-sfc-
> [email-masked]; Joel M. Halpern; BOUCADAIR Mohamed IMT/OLN
> Objet : AW: [sfc] #15 (control-plane): Whether the control plane operates

[Med] Yes, but the above two points are out of scope, IMHO. 

> 5.) Therefore the notion of a rendered path (R-SFP or RSP) which is the
> final unique path for a certain flow. SFP -> RSP = 1:r
> 
> If above (trivial)  interpretation is correct I could argue that from the
> logical point of view I could use the mappings
> 
> 1.) SFC -> SFP -> RSP or
> 2.) SFC -> RSP directly.
> 

[Med] Yes, both models should be supported. 

> To me the real value of the intermediate SFP is not obvious from the
> logical point of view. For sure it may help in the implementation of an
> abstraction breakdown.
> Do I miss something? The question SFP-ID or  RSP-ID seems to be also
> addressed to the WG at the end of the NSH draft.
> 
> If I would use SFP instead of RSP  in the NSH and SFF FW tables there may
> be remaining ambiguities in selecting the RSP.
> In this case I even could  use a SFC-ID  in NSH and assume the SFF has all
> the intelligence to resolve the path ambiguities.

[Med] That's is indeed a valid approach. FWIW, there is an open ticket for the nsh draft on this: http://trac.tools.ietf.org/wg/sfc/trac/ticket/1 

> 
> For sure you could construct anything in between. But this is probably the
> origin of the renewed discussion. In that light and accepting we are
> orbiting  I support Med's attempt to clarify these topics.
> 
> Best regards,
> Walter
> 
> 
> 
> 
> Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); draft-ietf-sfc-
> [email-masked]; Joel M. Halpern; Med Boucadair

---

From: <[email-masked]>
Date: Wed, 18 Nov 2015 15:18:59 +0000

Hi Ron, 

Please see inline. 

Cheers,
Med

> De : Ron Parker [mailto:[email-masked]]
> À : Haeffner, Walter, Vodafone DE; Carlos Pignataro (cpignata); Joel
> Halpern
> One rationale behind the 1:N SFP-to-RSP relationship was to enable "late
> binding" by the SFF.    Thus, there could be a delegation of
> responsibility such that control plane chose SFP (e.g., HTTP-optimizer-
> silver-instances --> Firewall-silver-instances) and then allow classifier
> and SFF's to autonomously finalize the unique RSP.   Upon failure of one
> of the elements in the RSP, the classifier and SFF's could perform local
> repair by moving to a different RSP that respects the original SFP.
> 
> That being said, a 1:N can always degenerate to 1:1 -- that is in some
> deployment scenarios, SFPs do, indeed, represent unique RSPs.   This, of
> course, requires all aspects of failure recovery to be handled in the
> control plane.
> 
> I think both deployment scenarios are entirely valid and we wanted to keep
> the architecture open enough to support both.
> 

[Med] To double check, do you mean these two models:

1.) SFC -> SFP -> RSP or
2.) SFC -> RSP directly. 

Thank you. 

> Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn
> (paulq) <[email-masked]>; [email-masked];
> Joel M. Halpern <[email-masked]>; Med Boucadair
> <[email-masked]>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 18 Nov 2015 15:19:12 +0000

Hi, Med,

I also referred to other parts of the document, when I wrote:

> The control-plane draft talks about ³SFC forwarding² and ³SFC data plane²

For example, I am not sure I understand what this means:

"   o  Populate SFC forwarding policy tables of involved SFC data plane²

Or at:
"   o  SFC Forwarding Policy Table: this table reflects the SFC-specific
     traffic forwarding policy enforced by SFF components for every
     relevant incoming packet that is associated to one of the existing
     SFCs."

My comment is that those should be ³SFP"

Thanks,

‹ Carlos.

-----Original Message-----
From: Med Boucadair <[email-masked]>
Date: Wednesday, November 18, 2015 at 10:03 AM
To: Carlos Pignataro <[email-masked]>
Cc: "Paul Quinn (paulq)" <[email-masked]>,
"[email-masked]"
<[email-masked]>, Joel Halpern
<[email-masked]>, sfc issue tracker <[email-masked]>,
"[email-masked]" <[email-masked]>, Joel Halpern <[email-masked]>
Subject: RE: [sfc] #15 (control-plane): Whether the control plane operates
on SFC IDs, SFP IDs, etc.

>The text you quoted is part of an appendix with a note that clearly
>states this is not discussed. A corresponding issue record has been
>recorded to seek for more feedback on that appendix.
>
>Cheers,
>Med
>
>> Discussion is great, Med. But my Œwe are circling' comment (not in
>> The control-plane draft talks about ³SFC forwarding² and ³SFC data
>>plane²,
>> and ³SFC IDs². The architecture says that SFC are made of abstract
>>service
>> functions. There¹s no actual forwarding in this abstract conceptual
>>model.
>> 
>> The control-plane draft says ³Suppose the SFC ID for this SFP is
>> "yellow²,², and my point again is that in the data plane an SFP has an
>> something else, it¹s not a Topology-ID, it¹s not a SKU, it¹s not a URI,
>> it¹s not a Family Name, and not an SFC ID), and the control (and policy)
>> ‹ Carlos.
>> >> I am a bit baffled to see this thread again ‹ it appears the
>>discussion
>> >> restarted to continue in circles.
>> >>
>> >> Med,
>> >>
>> >> identification passed down ‹ there is no provisioning of SFCs
>> southbound.
>> >>
>> >> (Almost) every instance of ³SFC² in the control-plane requirements
>> draft
>> >> should really say ³SFP². There is no use of talking about SFCs
>>towards
>> the
>> >> ‹ Carlos.
>> >>> On Nov 17, 2015, at 9:06 AM, Joel Halpern
>><[email-masked]>
>> >> wrote:
>> >>>
>> >> you are introducing extra complexity without adding any new cases
>>that
>> can
>> >> be handled.
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>>>> (control-plane): Whether the control plane operates on SFC IDs,
>>SFP
>> >> IDs, etc.
>> >>>>>
>> >>>>> Joel,
>> >>>>>
>> >>>>> I concur.
>> >>>>>
>> >>>>> accurately captured, in terms of data plane requirements, by
>>service
>> >> function path IDs.
>> >>>>> Yes, in some deployments those will be 1-1 with chain IDs.  They
>>are
>> >>>> still path IDs.
>> >>>>>>

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 15:44:43 +0000

Hi Ron,

Thanks for your quick response.

"SFPs do, indeed, represent unique RSPs" ==> guess you mean 1:n not 1:1.

Regards,
Walter

-----Ursprüngliche Nachricht-----
Von: Ron Parker [mailto:[email-masked]]
Gesendet: Mittwoch, 18. November 2015 15:35
An: Haeffner, Walter, Vodafone DE; Carlos Pignataro (cpignata); Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi, Walter.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Wednesday, November 18, 2015 9:04 AM
To: Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

HI Carlos, dear all,

1.) SFC -> SFP -> RSP or
2.) SFC -> RSP directly.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Carlos Pignataro (cpignata)
Gesendet: Mittwoch, 18. November 2015 11:52
An: Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Med,

Thanks,

— Carlos.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 18 Nov 2015 16:17:44 +0000

[Chair hat off …]

I have to say I am struggling to see the “issue” in this thread that needs
to be addressed other than confusion over SFC vs SFP definition; from a
data plane perspective it is *very* clear that SFP/SI identifiers are used
as the lookup key into a forwarding construct that may contain 1:n number
of next-hops (SFFs, SFs). In some cases that lookup will point to a single
next-hop, in others multiple next-hops. In *all* cases this has absolutely
nothing to do with the SFC as each representation of that SFC is uniquely
identified by an SFP-id.

Jim 

On 11/18/15, 10:19 AM, "sfc on behalf of Carlos Pignataro (cpignata)"
<[email-masked] on behalf of [email-masked]> wrote:

>>plane²
>>> >> SFP given that RFC7665 explicitly defines SFP as "constrained
>>>version
>>> of
>>> >> the original SFC"!
>>> >>>
>>> >>>> Cc: sfc issue tracker;
>>> >>>>>> Introducing a requirement for the data plane to see and work
>>>with
>>> >>>>>> chain

---

From: Ron Parker <[email-masked]>
Date: Wed, 18 Nov 2015 17:04:14 +0000

Responding to Med's question here, too.

My view is that the hierarchy is, in general,

SFC-->(N)SFP -->(M)RSP

Clearly, either N, M, or both could be constrained to equal 1.   Let's say M is constrained to value 1:

SFC-->(N)SFP-->RSP

From an intuition perspective, the SFP and RSP could be collapsed, since they are 1:1 in this case:

SFC-->(N)SFP or SFC-->(N)RSP are two equivalent ways to view the same effective relationship in this constrained case.

   Ron

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]] 
Sent: Wednesday, November 18, 2015 10:45 AM
To: Ron Parker <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: AW: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Ron,

Regards,
Walter

-----Ursprüngliche Nachricht-----
Von: Ron Parker [mailto:[email-masked]]
Gesendet: Mittwoch, 18. November 2015 15:35
An: Haeffner, Walter, Vodafone DE; Carlos Pignataro (cpignata); Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi, Walter.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Wednesday, November 18, 2015 9:04 AM
To: Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

HI Carlos, dear all,

1.) SFC -> SFP -> RSP or
2.) SFC -> RSP directly.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Carlos Pignataro (cpignata)
Gesendet: Mittwoch, 18. November 2015 11:52
An: Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Med,

Thanks,

— Carlos.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 17:28:01 +0000

Hi Ron,

I think, we are in line with the hierarchy. SFC -> SFP 1:N;   SFP -> RSP 1:M (okay my M is different to yours because you say a set of N SFPs maps onto a set of M RSPs and I say each SFP maps onto M SRPs. But finally our conclusions are equivalent.)

Well, making the mappings 1:1 is a very special, simplified  case.  For sure, in real implementations SFP = RSP maybe an often seen case. But shouldn't we have a definition which covers the multivalued cases?

So far I see the WGs official position is 

SFC-ID only in c-plane.

SFP_ID in the NSH.

DE-plane must resolve the potential remaining ambiguities in RSPs.

Is this assumption right or wrong?

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: Ron Parker [mailto:[email-masked]] 
Gesendet: Mittwoch, 18. November 2015 18:04
An: Haeffner, Walter, Vodafone DE; Carlos Pignataro (cpignata); Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

SFC-->(N)SFP -->(M)RSP

SFC-->(N)SFP-->RSP

   Ron

-----Original Message-----
From: Haeffner, Walter, Vodafone DE [mailto:[email-masked]]
Sent: Wednesday, November 18, 2015 10:45 AM
To: Ron Parker <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: AW: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Ron,

Regards,
Walter

-----Ursprüngliche Nachricht-----
Von: Ron Parker [mailto:[email-masked]]
Gesendet: Mittwoch, 18. November 2015 15:35
An: Haeffner, Walter, Vodafone DE; Carlos Pignataro (cpignata); Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi, Walter.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Haeffner, Walter, Vodafone DE
Sent: Wednesday, November 18, 2015 9:04 AM
To: Carlos Pignataro (cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
Cc: sfc issue tracker <[email-masked]>; [email-masked]; Paul Quinn (paulq) <[email-masked]>; [email-masked]; Joel M. Halpern <[email-masked]>; Med Boucadair <[email-masked]>
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

HI Carlos, dear all,

1.) SFC -> SFP -> RSP or
2.) SFC -> RSP directly.

Best regards,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Carlos Pignataro (cpignata)
Gesendet: Mittwoch, 18. November 2015 11:52
An: Joel Halpern
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel M. Halpern; Med Boucadair
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Med,

Thanks,

— Carlos.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 18:24:03 +0000

Hi Joel,

You say " A Service Function Chain (SFC) effectively designates a (potentially large) collection of sequences of SFF and SF visitations, any one of which would satisfy the the SFC".

Shouldn't we say <<<< A Service Function Chain (SFC) effectively designates a (potentially large) collection of sequences of SFF and SF visitations, any one of which MUST satisfy the POLICIES DESCRIBING THE SERVICE >>>>. 

At the moment your statement reads to me more like (if you allow a dramatic simplification) a SFC is defined by a SFC. I am sure that's not what you had in mind.

Cheers,
Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Joel M. Halpern
Gesendet: Mittwoch, 18. November 2015 04:57
An: [email-masked]; Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]; Joel M. Halpern; sfc issue tracker; [email-masked]
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Let me trying phrasing this differently.
A Service Function Chain (SFC) effectively designates a (potentially
large) collection of sequences of SFF and SF visitations, any one of which would satisfy the the SFC.

An Service Function Path (SFP) designates a subset of the collection designated by the SFC. For some SFPs, in some deployments, that will be a set of 1.  For other SFPs (in the same or other deployments) it may be a larger set.  For some SFPs in some deployments the SFP may designate the same set of choices as the SFC.

Formally, the SFP is a subset of the SFC, but not necessarily a proper subset.

By always having control provision in terms of SFPs, the data plane always sees the effects of the constraints that control has placed in selecting the SFP.  And because of the definition of SFP, this allows the range of deplooyments the working group has requested.

Add SFC information into the provisioning does not increase the capability.  It does not, in fact, add any information tha thte forwarding can use.

Yours,
Joel

On 11/17/15 9:27 AM, [email-masked] wrote:
>> Envoyé : mardi 17 novembre 2015 15:06 À : BOUCADAIR Mohamed IMT/OLN; 
>> decides whether that SFP indicates the same set of all possible 
>> choices that the SFC does, or is a proper subset.
>
>> No special provision is needed for the case where the SFP is 
>> isomorphic to the SFC. In such a case, you still provision the SFP.  
>> And the result is an SFP with as much flexibility as the SFC.
>
>> If, in contrast, you declare that the provisioning includes the SFC 
>> then you are introducing extra complexity without adding any new 
>> cases that can be handled.
>
>>> Your statement that " It happens that information is no more than 
>>> the service chain itself (without any constraints)." (Where "it" refers to "
>>> the exact sequence of steps to be used to realize the SFC".) Does 
>>> not make sense to me.
>>
>> [Med] RFC 7665 says:
>>
>> information that you will provision to an SFF when the path 
>> computation and selection decision is "deferred to the SFF"?
>>
>> It does not make sense to call a non-constrained version of the SFC 
>> as SFP given that RFC7665 explicitly defines SFP as "constrained 
>> version of the original SFC"!
>>
>>> The control-plane document allows in particular to provision 
>>> required information when "deferring to the SFF the decisions about the
>>>     exact sequence of steps to be used to realize the SFC". It 
>>> happens that information is no more than the service chain itself 
>>> (without any constraints).
>>>

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 18 Nov 2015 18:40:08 +0000

Removed redundant recipients so message is not moderated...

My feedback based on Opensource implementation.

Chains have do not IDs as in data plane Ids. They only have names such as
³ietf-yokohama-chain-1²

Service Path are constructed from chains. Many SFPs can be constructed
from the same SFC with different constraints. SFPs always have friendly
names and IDs BUT the ID is only used for actual forwarding if they are
fully specific (concrete) SFPs, in this case SFP=RSP. If SFP is abstract,
say, it only specifies 1 service-hop out of three, then clearly this ID
can not be used for forwarding since the path is incomplete.

When SFP is partially specified (incomplete or abstract) the ID of the RSP
is the one actually used for forwarding. Many RSPs with different
constraints can be constructed from a single SFP.

I believe this is what a previous message mentioned as :

SFC-->(N)SFP -->(M)RSP

It is implied that these N SFP can be completely different from one
another within the SFC constraints. And it is also implied that RSP can be
completely different from one another within the SFP constraints.

Thanks,

>
>
>On 11/18/15, 9:28 AM, "sfc on behalf of Haeffner, Walter, Vodafone DE"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>Hi Ron,
>>
>>I think, we are in line with the hierarchy. SFC -> SFP 1:N;   SFP -> RSP
>>1:M (okay my M is different to yours because you say a set of N SFPs maps
>>onto a set of M RSPs and I say each SFP maps onto M SRPs. But finally our
>>conclusions are equivalent.)
>>
>>Well, making the mappings 1:1 is a very special, simplified  case.  For
>>sure, in real implementations SFP = RSP maybe an often seen case. But
>>shouldn't we have a definition which covers the multivalued cases?
>>
>>Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq);
>>[email-masked]; Joel M. Halpern; Med
>>Boucadair
>>SFC-->(N)SFP or SFC-->(N)RSP are two equivalent ways to view the same
>>effective relationship in this constrained case.
>>
>>
>>   Ron
>>
>>
>>To: Ron Parker <[email-masked]>; Carlos Pignataro
>>(cpignata) <[email-masked]>; Joel Halpern <[email-masked]>
>>Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq);
>>[email-masked]; Joel M. Halpern; Med
>>Boucadair
>>responsibility such that control plane chose SFP (e.g.,
>>HTTP-optimizer-silver-instances --> Firewall-silver-instances) and then
>>allow classifier and SFF's to autonomously finalize the unique RSP.
>>Upon failure of one of the elements in the RSP, the classifier and SFF's
>>could perform local repair by moving to a different RSP that respects the
>>original SFP.
>>
>>I think both deployment scenarios are entirely valid and we wanted to
>>keep the architecture open enough to support both.
>>
>>   Ron
>>
>>
>>In this case I even could  use a SFC-ID  in NSH and assume the SFF has
>>all the intelligence to resolve the path ambiguities.
>>
>>For sure you could construct anything in between. But this is probably
>>the origin of the renewed discussion. In that light and accepting we are
>>Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq);
>>[email-masked]; Joel M. Halpern; Med
>>Boucadair
>>I am a bit baffled to see this thread again ‹ it appears the discussion
>>identification passed down ‹ there is no provisioning of SFCs southbound.
>>
>>(Almost) every instance of ³SFC² in the control-plane requirements draft
>>should really say ³SFP². There is no use of talking about SFCs towards
>>the data plane. The relationship between chains and paths is a policy
>>matter which belongs in the policy/control itself, but not out of there.
>>
>>>then you are introducing extra complexity without adding any new cases
>>>that can be handled.
>>>
>>> Yours,
>>> Joel
>>>
>>>aligned with RFC7665 that allows to control any variation from a
>>>non-constrained SFC to a fully constrained SFC.
>>>
>>>> Yours,
>>>> Joel
>>>>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 18 Nov 2015 19:34:15 +0000

[reduced distribution to Jim & sfc list]

Jim,
I think your description is helpful. Can we find a place for this in the docs?

I don't think I can understand it without referring to the concrete NSH, however.

If I understand correctly, the following are true:
- if the NSH SPI in two packets are the same, they are on the same SFP.
- if the NSH SPI in two packets are different, they are on different SFPs.
- although two packets have the same SPI, they may traverse different RSPs.

- when thinking of the data-plane and south-bound interfaces C1 thru C4, the SFC concept doesn't exist.
   (SFC is just a north-interface concept like, "chain A provides a firewall and a NAT")

Have I got it right?

I also think the following *analogy* with routing can be drawn:
SFC <--> destination host name
SFP <--> destination IP address
RSP <--> sequence of routers and links to deliver the IP packet

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, November 18, 2015 11:18 AM
To: Carlos Pignataro (cpignata); [email-masked]
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel Halpern; Joel M. Halpern
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

[Chair hat off …]

Jim 

On 11/18/15, 10:19 AM, "sfc on behalf of Carlos Pignataro (cpignata)"
<[email-masked] on behalf of [email-masked]> wrote:

>>>choices
>>> isomorphic
>>> then
>>>not
>>>computation
>>>as
>>>non-
>>>required
>>>happens

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 18 Nov 2015 20:10:42 +0000

"- although two packets have the same SPI, they may traverse different
RSPs.”

hummm…I do not see how this can be achieved today.

I know you can classify on 5-tuple or others, but what is the solution to
achieve what you say above within the confines of NSH? Where is the ID
that will allow you to demux between two packets that have the same SP but
traverse different RSPs.

On 11/18/15, 11:34 AM, "sfc on behalf of Dave Dolson"
<[email-masked] on behalf of [email-masked]> wrote:

>[email-masked]; Joel Halpern; Joel M. Halpern
>>>> identifier (which identifies the SFP (SFP-ID) and is not the
>>>>identifier
>>>>of
>>>> >>>>> Thus, the requirement that the data plane has is to see such
>>>>path
>>>> IDs.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Nov 2015 15:15:42 -0500

What the working group asked was that the archtiecture and protocol 
support this option.

There are multiple ways that an SFF supporting multiple RSP per SFP 
could be implemented.  My current understanding is that we do not plan 
to mandate a technique.  All the approaches I know of require that the 
SFF look at some additional information beyond the SFP-ID and SFP-Index.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 18 Nov 2015 20:21:35 +0000

My question was not on mandating a technique but whether the WG would work
on at least one solution that leveraged NSH as opposed to everything being
implementation specific.

With everything being implementation specific two SFFs of different
vendors on the same path might steer packets to RSPs differently. Since
this is a on-the-wire interop issue my take is that it would fall right
into the WG confines to propose at least one solution.

On 11/18/15, 12:15 PM, "Joel M. Halpern" <[email-masked]> wrote:

>>> I think your description is helpful. Can we find a place for this in
>>>the
>>> docs?
>>>
>>> I don't think I can understand it without referring to the concrete
>>>NSH,
>>> however.
>>>
>>>
>>> - when thinking of the data-plane and south-bound interfaces C1 thru
>>>C4,
>>> the SFC concept doesn't exist.
>>>>>> Cc : Paul Quinn (paulq);
>>>>>>>>> In order to allow for an SFP that reflects meaningful
>>>>>>>>>constraints,
>>>>>> what

---

From: Dave Dolson <[email-masked]>
Date: Wed, 18 Nov 2015 20:26:01 +0000

I'm thinking of a load-balancing or fail-over solution, in which an SFF can choose from one or more SF instances for the same SPI.

It doesn't need to be visible to the SFC controller because the outcome of processing would be identical.

If these aren't different RSPs for the same SFP, then what are?

---

From: Ron Parker <[email-masked]>
Date: Wed, 18 Nov 2015 20:29:50 +0000

Dave,

I see it as you do.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: Wednesday, November 18, 2015 2:34 PM
To: Jim Guichard (jguichar) <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Jim,

Have I got it right?

-Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, November 18, 2015 11:18 AM
To: Carlos Pignataro (cpignata); [email-masked]
Cc: sfc issue tracker; [email-masked]; Paul Quinn (paulq); [email-masked]; Joel Halpern; Joel M. Halpern
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

[Chair hat off …]

I have to say I am struggling to see the “issue” in this thread that needs to be addressed other than confusion over SFC vs SFP definition; from a data plane perspective it is *very* clear that SFP/SI identifiers are used as the lookup key into a forwarding construct that may contain 1:n number of next-hops (SFFs, SFs). In some cases that lookup will point to a single next-hop, in others multiple next-hops. In *all* cases this has absolutely nothing to do with the SFC as each representation of that SFC is uniquely identified by an SFP-id.

Jim 

On 11/18/15, 10:19 AM, "sfc on behalf of Carlos Pignataro (cpignata)"
<[email-masked] on behalf of [email-masked]> wrote:

>>> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]  Envoyé 
>>>: mercredi 18 novembre 2015 15:35  À : BOUCADAIR Mohamed IMT/OLN  Cc 
>>>: Paul Quinn (paulq); [email-masked];
>>>Joel
>>> M. Halpern; sfc issue tracker; [email-masked]; Joel Halpern  Objet : 
>>>Re: [sfc] #15 (control-plane): Whether the control plane operates  on 
>>>SFC IDs, SFP IDs, etc.
>>> 
>>> Med,
>>> 
>>> discussing it. I don't know how you can conclude in advance that we 
>>> are circling.
>>> >
>>> 
>>>advanced, but already evident) is because I saw the same questions, 
>>>same  arguments, and same answers as before.
>>> 
>>> Well, I believe so on technical grounds! Most of which have already 
>>>been  said, so I do not want to contribute to the circular 
>>>discussion.
>>> 
>>>plane²,  and ³SFC IDs². The architecture says that SFC are made of 
>>>abstract service  functions. There¹s no actual forwarding in this 
>>>abstract conceptual model.
>>> 
>>>"yellow²,², and my point again is that in the data plane an SFP has 
>>>an  identifier (which identifies the SFP (SFP-ID) and is not the 
>>>identifier of  something else, it¹s not a Topology-ID, it¹s not a 
>>>SKU, it¹s not a URI,  it¹s not a Family Name, and not an SFC ID), and 
>>>the control (and
>>>policy)
>>> >> Envoyé : mercredi 18 novembre 2015 11:52 À : Joel Halpern Cc : 
>>> >> BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq); draft-ietf-sfc- 
>>> >> control plane
>>> >> I too agree with Joel and strongly believe there is no need for 
>>> >> SFC identification passed down ‹ there is no provisioning of SFCs
>>> southbound.
>>> >>
>>> >> This is no different than what I said a few months ago on the 
>>> >> same
>>> topic.
>>> >>
>>> >> Thanks,
>>> >>
>>> >> ‹ Carlos.
>>> >>
>>> >>>> Envoyé : mardi 17 novembre 2015 14:49 À : BOUCADAIR Mohamed 
>>> >>>> IMT/OLN; Paul Quinn (paulq) Cc : sfc issue tracker; 
>>> >>>> Objet : RE: [sfc] #15 (control-plane): Whether the control 
>>> >>>> plane operates on SFC IDs, SFP IDs, etc.
>>> >>>>
>>> >>>  upon the solution) produce what may be thought of as a 
>>> >>> constrained  version of the original SFC. "
>>> >>>
>>> >>> in short: SFP is defined as a constrained version of the 
>>> >>> original
>>>SFC.
>>> >>>
>>> >>> What is the name to use to refer to a "non-constrained" SFC or 
>>> >>> to
>>>the
>>> >>>> I stand by my earlier comments that almost all uses of SFC in 
>>> >>>> the control requirements draft should be SFP.
>>> >>>>
>>> >>>
>>> >>>> This architecture does not mandate the degree of  specificity 
>>> >>>> of the SFP.  Architecturally, within the same SFC-
>>> enabled
>>> >>>>> 16 octobre 2015 14:04 À : Joel M. Halpern Cc : BOUCADAIR 
>>> >>>>> Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc-control- 
>>> >>>>> The data plane deal with paths, not chains.  The relationship 
>>> >>>>> of paths to chains falls squarely in the control plane (or 
>>> >>>>> even more likely
>>> >>>> "policy"
>>> >>>>> implementation, in the architecture draft, but that's 
>>> >>>>> consistent with your position and provides the requisite functionality.
>>> >>>>>
>>> >>>>> Paul
>>> >>>>>
>>> >>>>> the data plane.  Any such relationship exists entirely within 
>>> >>>>> the control plane or above, and would be driven by 
>>> >>>>> requirements other than the data plane.  When I look at this 
>>> >>>>> document, all of the requirements that talk about service 
>>> >>>>> function chain IDs can be accurately captured, in terms of 
>>> >>>>> data plane requirements, by
>>>service
>>> >> function path IDs.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 20:37:51 +0000

Reinaldo,

This is a very good remark. Therefore it may be worth to discuss and resolve such degrees of freedom. 

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Reinaldo Penno (repenno)
Gesendet: Mittwoch, 18. November 2015 21:22
An: Joel M. Halpern; Dave Dolson; Jim Guichard (jguichar)
Cc: [email-masked]
Betreff: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

My question was not on mandating a technique but whether the WG would work on at least one solution that leveraged NSH as opposed to everything being implementation specific.

With everything being implementation specific two SFFs of different vendors on the same path might steer packets to RSPs differently. Since this is a on-the-wire interop issue my take is that it would fall right into the WG confines to propose at least one solution.

On 11/18/15, 12:15 PM, "Joel M. Halpern" <[email-masked]> wrote:

>> "- although two packets have the same SPI, they may traverse 
>> different RSPs.”
>>
>> I know you can classify on 5-tuple or others, but what is the 
>>solution to  achieve what you say above within the confines of NSH? 
>>Where is the ID  that will allow you to demux between two packets that 
>>have the same SP but  traverse different RSPs.
>>
>>>the  docs?
>>>NSH,  however.
>>>C4,  the SFC concept doesn't exist.
>>> I have to say I am struggling to see the “issue” in this thread that 
>>>needs  to be addressed other than confusion over SFC vs SFP 
>>>definition; from a  data plane perspective it is *very* clear that 
>>>SFP/SI identifiers are used  as the lookup key into a forwarding 
>>>construct that may contain 1:n number  of next-hops (SFFs, SFs). In 
>>>some cases that lookup will point to a single  next-hop, in others 
>>>multiple next-hops. In *all* cases this has absolutely  nothing to do 
>>>with the SFC as each representation of that SFC is uniquely  
>>>identified by an SFP-id.
>>>
>>> Jim
>>>
>>>>> The text you quoted is part of an appendix with a note that 
>>>>> clearly states this is not discussed. A corresponding issue record 
>>>>> has been recorded to seek for more feedback on that appendix.
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>>Envoyé : mercredi 18 novembre 2015 15:35  À : BOUCADAIR Mohamed 
>>>>>>IMT/OLN  Cc : Paul Quinn (paulq); 
>>>>>> M. Halpern; sfc issue tracker; [email-masked]; Joel Halpern  Objet 
>>>>>>: Re: [sfc] #15 (control-plane): Whether the control plane  
>>>>>> discussing it. I don't know how you can conclude in advance that 
>>>>>> we are circling.
>>>>>>>
>>>>>>
>>>>>> Discussion is great, Med. But my Œwe are circling' comment (not 
>>>>>> in advanced, but already evident) is because I saw the same 
>>>>>> questions, same arguments, and same answers as before.
>>>>>>
>>>>>> Well, I believe so on technical grounds! Most of which have 
>>>>>> already been said, so I do not want to contribute to the circular 
>>>>>> discussion.
>>>>>>
>>>>>> The control-plane draft talks about ³SFC forwarding² and ³SFC 
>>>>>> data plane², and ³SFC IDs². The architecture says that SFC are 
>>>>>> made of abstract service functions. There¹s no actual forwarding 
>>>>>> in this abstract conceptual model.
>>>>>>
>>>>>>"yellow²,², and my point again is that in the data plane an SFP 
>>>>>>has an  identifier (which identifies the SFP (SFP-ID) and is not 
>>>>>>the  identifier  of  something else, it¹s not a Topology-ID, it¹s 
>>>>>>not a SKU, it¹s not a  URI,  it¹s not a Family Name, and not an 
>>>>>>SFC ID), and the control (and
>>>>>> policy)
>>>>>>>> [email-masked]; Joel M. Halpern; sfc issue 
>>>>>>>>tracker;  [email-masked]  Objet : Re: [sfc] #15 (control-plane): 
>>>>>>>>Whether the control plane
>>>>>> operates
>>>>>>>> data plane. The relationship between chains and paths is a 
>>>>>>>> policy
>>>>>> matter
>>>>>>>>> What is provisioned into the SFF reflects the SFP.  The 
>>>>>>>>> control
>>>>>> system
>>>>>>>> to the SFC. In such a case, you still provision the SFP.  And 
>>>>>>>> the
>>>>>> result
>>>>>>>>> If, in contrast, you declare that the provisioning includes 
>>>>>>>>> the
>>>>>> SFC
>>>>>> then
>>>>>>>>>> [email-masked]; Joel M. Halpern Objet : RE: [sfc] #15 
>>>>>>>>> It does not make sense to call a non-constrained version of 
>>>>>>>>> the
>>>>>> SFC
>>>>>> as
>>>>>>>>> [Med] I noted that Joel.. that's fair but this position is 
>>>>>>>>> IMHO
>>>>>> not
>>>>>>>>>>> The data plane deal with paths, not chains.  The 
>>>>>>>>>>>relationship of  paths to chains falls squarely in the 
>>>>>>>>>>>control plane (or even
>>>>>> more
>>>>>>>>>>> likely
>>>>>>>>>> "policy"
>>>>>>>>>>> than the data plane.  When I look at this document, all of 
>>>>>>>>>>> the requirements that talk about service function chain IDs 
>>>>>>>>>>> can be accurately captured, in terms of data plane 
>>>>>>>>>>> requirements, by
>>>>>> service
>>>>>>>> function path IDs.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Wed, 18 Nov 2015 20:50:17 +0000

Hi Dave,

Yes, the LB is a good example. But here you may have different possibilities to define a path.

In your model the path terminates at one of the VMs/physMs behind the LB. This may be an example of a SFP with multiple RSP instances. The complete handling could become costly or very even complex.

You also could define such a SF as an object consisting of a LB with multiple SF instances attached. Then you could terminate the path already at ingress LB. Hope this simplifies things.

Do you see any issues I have probably overseen in my example?

Cheers,
Walter

-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:[email-masked]]
Sent: Wednesday, November 18, 2015 3:11 PM
To: Dave Dolson; Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

"- although two packets have the same SPI, they may traverse different RSPs.”

I know you can classify on 5-tuple or others, but what is the solution to achieve what you say above within the confines of NSH? Where is the ID that will allow you to demux between two packets that have the same SP but traverse different RSPs.

On 11/18/15, 11:34 AM, "sfc on behalf of Dave Dolson"
<[email-masked] on behalf of [email-masked]> wrote:

>needs to be addressed other than confusion over SFC vs SFP definition; 
>from a data plane perspective it is *very* clear that SFP/SI 
>identifiers are used as the lookup key into a forwarding construct that 
>may contain 1:n number of next-hops (SFFs, SFs). In some cases that 
>lookup will point to a single next-hop, in others multiple next-hops. 
>In *all* cases this has absolutely nothing to do with the SFC as each 
>representation of that SFC is uniquely identified by an SFP-id.
>
>Jim
>
>>>>Re: [sfc] #15 (control-plane): Whether the control plane operates  
>>>>SKU, it¹s not a URI,  it¹s not a Family Name, and not an SFC ID), 
>>>>and the control (and
>>>>policy)
>>>> >>>>> even

---

From: <[email-masked]>
Date: Thu, 19 Nov 2015 07:21:19 +0000

Hi Reinaldo, 

Fully agree on the last part of your message.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Reinaldo Penno
> (repenno)
> Envoyé : mercredi 18 novembre 2015 21:22
> À : Joel M. Halpern; Dave Dolson; Jim Guichard (jguichar)
> Cc : [email-masked]
> >>>needs
> >>>>>> been
> >>>>>>an
> >>>>>>>>>>>Mohamed
> >>>>>>>>>>>consistent
> >>>>>>>>>>>> As far as I can tell, there is nothing in the Service
> Chaining
> >>>>>>>>>>>> work that

---

From: Dave Dolson <[email-masked]>
Date: Thu, 19 Nov 2015 07:32:12 +0000

Med,
I would say that the SFC has no representation in the data plane (like host name has no representation in IP routing.)
‎Both are abstractions.

-Dave

  Original Message
From: [email-masked]
Sent: Thursday, November 19, 2015 2:12 AM
To: Dave Dolson
Cc: [email-masked]
Subject: RE: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Dave,

I fully agree with this analogy:

==
==

Hence the need for the control plane to instruct the underlying data plane elements with required information at each of these three levels.

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Dave Dolson
> Envoyé : mercredi 18 novembre 2015 20:34
> À : Jim Guichard (jguichar)
> Cc : [email-masked]
> [email-masked]; Joel Halpern; Joel M. Halpern
> >>> >>> Cc: sfc issue tracker; draft-ietf-sfc-control-
> [email-masked];

---

From: <[email-masked]>
Date: Thu, 19 Nov 2015 07:41:18 +0000

Re-,

Yes, but still there is a record somewhere to link the name to one or a list of IP addresses. That record can be maintained in a central entity or be local (an SFF can decide which exact SF instance it can solicited (LB cases, redundancy group, etc.). 

What I'm asking for is more freedom in the cp architecture to make the resolution when it is appropriate: either centralized, distributed, or a mix (hierarchical context).

Cheers,
Med

> De : Dave Dolson [mailto:[email-masked]]
> Envoyé : jeudi 19 novembre 2015 08:32
> I would say that the SFC has no representation in the data plane (like
> host name has no representation in IP routing.)
> ‎Both are abstractions.
> 
> -Dave
> 
>   Original Message
> Hence the need for the control plane to instruct the underlying data plane
> elements with required information at each of these three levels.
> 
> Cheers,
> Med
> 
> > Subject: Re: [sfc] #15 (control-plane): Whether the control plane
> operates
> > >>> Cc : Paul Quinn (paulq); draft-ietf-sfc-control-
> [email-masked];
> > >>>Joel
> > >>> [mailto:[email-masked]]
> > >>> >>>> [mailto:[email-masked]]

---

From: <[email-masked]>
Date: Thu, 19 Nov 2015 07:45:26 +0000

Hi Jim,

Let's me rephrase the issue.

What we are discussing is related to this part of the draft (and some other occurrences): 

======
   o  SFC Forwarding Policy Table: this table reflects the SFC-specific
      traffic forwarding policy enforced by SFF components for every
      relevant incoming packet that is associated to one of the existing
      SFCs.

         [[Note: The question of whether the data plane operates just in
         terms of SFP IDs or needs SFC IDs, as described in this version
         of the draft, is still under discussion among the authors.]]
=======

The current draft is generic as it allows to instruct via the cp interfaces the underlying dp elements with SFC, SFP, RSP, and other policies. When preparing the draft, I had a discussion with Joel about this design. We both agreed that this is worth to be discussed. 	

I explained, and other have done that too, that both models should be addressed. 

The discussion revealed the definition in the dp RFC are too vague. We need to resolve that as WG.

Cheers,
Med

> De : Jim Guichard (jguichar) [mailto:[email-masked]]
> Envoyé : mercredi 18 novembre 2015 17:18
> À : Carlos Pignataro (cpignata); BOUCADAIR Mohamed IMT/OLN

---

From: <[email-masked]>
Date: Thu, 19 Nov 2015 07:12:14 +0000

Hi Dave,

==

Cheers,
Med

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Nov 2015 09:22:04 -0500

Can you please describe some situation where there is increased value in 
having SFC information in the data plane.  Having the coordination 
within the control components is understandable and usually necessary. 
But that is out of scope for this document and this working group.
In what circumstance does the increased flexibility, which introduces 
additional complexity in the data plane, add value?

Yours,
Joel

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 19 Nov 2015 14:30:34 +0000

Hi Med,

On 11/19/15, 2:41 AM, "sfc on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Re-,
>
>Yes, but still there is a record somewhere to link the name to one or a
>list of IP addresses. That record can be maintained in a central entity
>or be local (an SFF can decide which exact SF instance it can solicited
>(LB cases, redundancy group, etc.).

Jim> actually from the SFC perspective there is not. The SFC is just an
ordered list of abstract SF types; from the SFC 1 or more SFP’s can be
generated and in some cases the SFP record will point to specific SFF/SF
locators but in others it might just refine the SFC to specify something
like “the FW from the SFC ordered list must be selected from DC #1”. From
the SFP one or more RSPs may be generated and these are the entities that
specify the exact SFF/SF locators.

Section 2.3.1 of RFC7665 is very clear on this.

Jim 
 
> 
>
>What I'm asking for is more freedom in the cp architecture to make the
>resolution when it is appropriate: either centralized, distributed, or a
>mix (hierarchical context).
>
>Cheers,
>Med
>
>>draft-ietf-sfc-
>>already
>>has
>>tracker;
>>relationship

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Thu, 19 Nov 2015 14:42:35 +0000

Hi Med,

On 11/19/15, 2:45 AM, "[email-masked]"
<[email-masked]> wrote:

>The current draft is generic as it allows to instruct via the cp
>interfaces the underlying dp elements with SFC, SFP, RSP, and other
>policies. When preparing the draft, I had a discussion with Joel about
>this design. We both agreed that this is worth to be discussed. 	
>

Jim> which document and what exactly is too vague? For example if we refer
to section 2.3.1 of RFC7665 it states:

"As an example of this progressive refinement, consider a Service
   Function Chain (SFC) that states that packets using this chain should
   be delivered to a firewall and a caching engine.

   A Service Function Path (SFP) could refine this, considering that
   this architecture does not mandate the degree of specificity an SFP
   has to have.  It might specify that the firewall and caching engine
   are both to be in a specific data center (e.g., in DC1), or it might
   specify exactly which instance of each firewall and caching engine is
   to be used.

The Rendered Service Path (RSP) is the actual sequence of SFFs and
   SFs that the packets will actually visit.  So if the SFP picked the
   DC, the RSP would be more specific.”

What exactly is vague about this? Seems pretty clear, at least to me, how
progressive refinement from SFC to eventual RSP is achieved.

Jim

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 19 Nov 2015 22:21:18 +0000

Joel,

> On Nov 17, 2015, at 10:56 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> A Service Function Chain (SFC) effectively designates a (potentially large) collection of sequences of SFF and SF visitations, any one of which would satisfy the the SFC.
> 

I would even lift that "higher": an SFC connotes policy, not realization.  That puts is squarely in the control/policy space.

> An Service Function Path (SFP) designates a subset of the collection designated by the SFC. For some SFPs, in some deployments, that will be a set of 1.  For other SFPs (in the same or other deploy…

We are on the same page: this where the rubber meets the road, or the packets meet the wire.  The abstract policy from the SFC is mapped to tangible resources for instantiation.

> Add SFC information into the provisioning does not increase the capability.  It does not, in fact, add any information tha thte forwarding can use.

Exactly what I was trying to convey above: policy --> SFC, instantiation --> SFP.  Using that distinction, the architecture has a clear line between the two domains, and a way to cross them.

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Thu, 19 Nov 2015 22:24:43 +0000

> On Nov 18, 2015, at 2:34 PM, Dave Dolson <[email-masked]> wrote:
> 

Yes, that's exactly the intent.  A chain tell you what you want, or as you say: a firewall and a nat.  That means nothing in the service plane.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sat, 21 Nov 2015 22:25:17 +0000

I have to say the argument here is bit confusing, I'm trying to parse it.

The SFP results from parsing the constraints of the SFC.  There was some
architectural relaxation in the SFP definition.  The original idea of the
unconstrained hop was not that it was a blind draw, but rather it had a
local heuristic for selecting which of many functions (probably the SAME
functions) it supported (for HA, load balancing or other practical reasons
where we didn't want to maintain the knowledge in a central repository of
the state of those functions).

An SFP with no constraints DOESN'T exist ...a PATH is a constraint.

To contrive a service chain that doesn't care about order and arbitrarily
selects the path has to assume that every junction in the path could
support all the functions required in the chain - which is a constraint
itself BTW, otherwise you have a blind pinball machine.  In that
contrivance, if you do have all the functions at every hop, you
essentially have a huge load-balancer and not really a service chain.

Perhaps the argument is for the capability of the SFCID has to be passed
in the data plane to enable some sort of finer clue in a derived path at
what otherwise was (by intent, for a number of different use cases) a
loose hop in the resolution.  In order to have selected the loose hop SFF
in the first place, I'd argue you probably needed to know that it had the
capability of fulfilling the request - otherwise, again, we're shooting
blindly in the dark.  In this case the SCID then provides some further
granularity in function selection that couldn't be expressed as an
externally addressable entity in policy by the SFF/policy point (a "low
latency" function or "normal latency" mixed together with a local
heuristic for knowing which is which) - otherwise, we would have resolved
it instead of paying the tax.  Possible, but a HUGE stretch, because it
assumes a highly connected and cognizant SFF (it knows the policy meaning
and provides enough information to the general policy store so that it can
be selected for the loose hop in the first place) that can't create
logically addressable associations for finer discrimination of it's
resources.  It seems that that sort of "broken implementation" isn't worth
a permanent tax on everyone.

If the SFF is THAT hooked into the entire policy schema that it can act
that independently, why not make it re-classify (it should see the same
classifier mappings to SCIDs as other nodes of it's class), associate with
an SCID and get on with whatever local resolution is appropriate (in it's
highly independent mind).

Again, looking for a deployment angle that is non-rhetorical and not
broken that would merit such a tax.

>Hi Carlos,
>
>As I mentioned in my previous message to Joel, the control plane draft
>DOES NOT mandate any IDs. It lists a set of information that is needed to
>be instructed via control plane interfaces. I'm arguing that not only
>SFPs are needed to be communicated to the control points, but also
>service chains. 
>
>Please refer to the excerpt from the data plane arch I included in one of
>my messages. 
>
>FWIW, there is a ticket for the NSH specification draft since almost 5
>months: http://trac.tools.ietf.org/wg/sfc/trac/ticket/1
>
>Cheers,
>Med
>
>> Envoyé : dimanche 20 septembre 2015 05:02
>> Cc : Joel M. Halpern; sfc issue tracker; draft-ietf-sfc-control-
>> It seems to me you are reading what you want to read from the
>>architecture
>> and data plane documents, and not what it's actually there.
>> 
>> Where are service chain IDs within the data plane?
>> 
>> Thanks,
>> 
>> Thumb typed by Carlos Pignataro.
>> Excuze typofraphicak errows
>> 
>> > On Sep 18, 2015, at 02:06, "[email-masked]"
>> > The excerpt I provided from the arch draft clearly shows that extreme
>> cases are allowed: non-constrained SFCs, fully constrained SFCs, and any
>> variation in between. The control plane should be able to accommodate
>>all
>> those cases.
>> >
>> > The data plane draft is also explicit there is a binding between the
>> service chain and its SFPs. The control plane relies on that ground for
>> the requirements it derives for the interfaces that are in scope. It
>>does
>> not mandate that correlation should be transported in packets, but it
>> identifies this is a piece of information that is needed to be
>> communicated via control interfaces.
>> >
>> > The document DOES NOT mandate any IDs.
>> >
>> > Cheers,
>> > Med
>> >
>> >> Envoyé : jeudi 17 septembre 2015 17:37
>> >> À : BOUCADAIR Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc-
>> control-
>> >> [email-masked]
>> >> Cc : [email-masked]
>> >> requirement that the data plane has is to see such path IDs.  Yes, in
>> >> some deployments those will be 1-1 with chain IDs.  They are still
>>path
>> >> IDs.
>> >>
>>constrained

---

From: Shunsuke Homma <[email-masked]>
Date: Sun, 22 Nov 2015 19:04:40 +0900

Hi,

I and authors had analyzed a pattern in which two packets having the 
same SPI traverse different RSPs, and the result is described in section 
"Service Paths Selection Patterns" of 
"draft-homma-sfc-forwarding-analysis-04."
https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/

We assume that dynamic paths selection will be useful for large-scale 
networks because it enables operators to separate control and management 
for each DC or domain. In other words, it enables to avoid using a 
"super controller" in large-scaled networks such as carrier grade networks.

IMHO, there are surely situations in which conveying SPI as abstract 
information in data-plane is beneficial, and some SFFs should be 
available to select the next hops dynamically.

Thanks,
Shunsuke

On 2015/11/19 23:22, Joel M. Halpern wrote:
>> Yes, but still there is a record somewhere to link the name to one or
>> a list of IP addresses. That record can be maintained in a central
>> entity or be local (an SFF can decide which exact SF instance it can
>> solicited (LB cases, redundancy group, etc.).
>>
>> resolution when it is appropriate: either centralized, distributed, or
>> a mix (hierarchical context).
>>
>> Cheers,
>> Med
>>

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service System Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sun, 22 Nov 2015 17:50:19 +0000

See my earlier response.  For the
SFC ID to have any meaning, the interpreting node would be hooked to the same policy system - otherwise it's a random variable.  I just find it a stretch to have the capabilities required for maintaining THAT functionality but being selectively incapable of maintaining the classification table that mapped to the SFC ID (the distribution of which, like the SFC ID, is amenable to distributed control) - which was apparently the capability of a similarly "gifted" policy node somewhere upstream in the chain - is  a dysfunctional arrangement (of capabilities for a node) that shouldn't be encouraged by a general tax.

Sent from my iPhone

> On Nov 22, 2015, at 5:04 AM, Shunsuke Homma <[email-masked]> wrote:
> 
> Hi,
> 
> I and authors had analyzed a pattern in which two packets having the same SPI traverse different RSPs, and the result is described in section "Service Paths Selection Patterns" of "draft-homma-sfc-forwarding-analysis-04."
> We assume that dynamic paths selection will be useful for large-scale networks because it enables operators to separate control and management for each DC or domain. In other words, it enables to avoid using a "super controller" in large-scaled networks such as carrier grade networks.
> 
> IMHO, there are surely situations in which conveying SPI as abstract information in data-plane is beneficial, and some SFFs should be available to select the next hops dynamically.
> 
> Thanks,
> Shunsuke
>

---

From: Shunsuke Homma <[email-masked]>
Date: Mon, 23 Nov 2015 12:42:22 +0900

Hi Ken,

Of course, I don't think every SFF decides the next hop dynamically. It 
will cause significant complexity of the control. I think that use of 
"dynamic SFF" should be restrictive rather than every SFF should be 
dynamic SFF.

What I want to say is that dynamic paths selection should not be 
excluded in standard if there are some situations in which it is 
beneficial. I'm worrying that it will be difficult to manage end-to-end 
paths across multiple domains completely in large-scale network, and I 
think that distribution of control and management will be required for 
more scalable and flexible service chaining mechanism.
(I also assume that NSH may be over-spec in small network from viewpoint 
of just transport.)

Shunsuke

---

From: <[email-masked]>
Date: Mon, 23 Nov 2015 07:00:02 +0000

Hi Jim,

The excerpt you quoted is clear to me too. This is not where the disconnect comes from. 

The case of RSP is also clear.

The one which is less clear is when there are no constraints on the sfc and, using the wording from the dp arch RFC, the decisions are "deferred to the SFF about the exact sequence of steps to be used to realize the SFC" (Section 2.3 of RFC 7665). Calling that case an SFP is odd since SFP is by definition a "thought of as a constrained version of the original SFC" (Section 2.3 of RFC 7665)

RFC7665 also ACKs "the specificity may be anywhere in between these extremes" which I understand as the architecture allows for these configurations: (1) fully distributed, (2) loose path, (3) strict path.

Cheers,
Med

> Envoyé : jeudi 19 novembre 2015 15:43
> Cc : sfc issue tracker; [email-masked]; Joel Halpern; Joel M. Halpern

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Mon, 23 Nov 2015 21:40:03 +0000

Hi Med,

I think the point is that the SFP-id (not SFC-id or any other id) is used
as the lookup key to determine forwarding action regardless of whether the
SFC is fully constrained, partially constrained, or not constrained at
all. Forwarding is simply realized by the result of the lookup on the
SFP-id. 

Jim

On 11/23/15, 2:00 AM, "[email-masked]"
<[email-masked]> wrote:

>The one which is less clear is when there are no constraints on the sfc
>and, using the wording from the dp arch RFC, the decisions are "deferred
>to the SFF about the exact sequence of steps to be used to realize the
>SFC" (Section 2.3 of RFC 7665). Calling that case an SFP is odd since SFP
>is by definition a "thought of as a constrained version of the original
>SFC" (Section 2.3 of RFC 7665)
>
>RFC7665 also ACKs "the specificity may be anywhere in between these
>extremes" which I understand as the architecture allows for these
>configurations: (1) fully distributed, (2) loose path, (3) strict path.
>
>Cheers,
>Med
>
>>data
>> >> >>> something else, it¹s not a Topology-ID, it¹s not a SKU, it¹s not
>>a
>> >> URI,
>> >> >>> >>>> Also, the current control-plane document allows to instruct
>>a
>> >> >>>loose
>> >> >>> >>>> path
>> >> >>> >>>>> paths to chains falls squarely in the control plane (or
>>even
>> >> more
>> >> >>> >>>>> likely
>> >> >>> >>>> "policy"
>> >> >>> >>>>> requires correlating service path IDs with service chain
>>IDs
>> >> >>>within

---

From: Ron Parker <[email-masked]>
Date: Mon, 23 Nov 2015 21:59:23 +0000

Hi, Jim.

In the case of late-binding of load balancing decisions, I would modify the sentence to be:

Forwarding is realized by the result of the lookup on the SFP-id and the flow-id and/or characteristics within the original/carried packet such as its 5-tuple.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 23, 2015 4:40 PM
To: [email-masked]
Cc: sfc issue tracker <[email-masked]>; [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Med,

I think the point is that the SFP-id (not SFC-id or any other id) is used as the lookup key to determine forwarding action regardless of whether the SFC is fully constrained, partially constrained, or not constrained at all. Forwarding is simply realized by the result of the lookup on the SFP-id. 

Jim

On 11/23/15, 2:00 AM, "[email-masked]"
<[email-masked]> wrote:

>and, using the wording from the dp arch RFC, the decisions are 
>"deferred to the SFF about the exact sequence of steps to be used to 
>realize the SFC" (Section 2.3 of RFC 7665). Calling that case an SFP is 
>odd since SFP is by definition a "thought of as a constrained version 
>of the original SFC" (Section 2.3 of RFC 7665)
>
>> De : Jim Guichard (jguichar) [mailto:[email-masked]]  Envoyé : 
>>jeudi 19 novembre 2015 15:43  À : BOUCADAIR Mohamed IMT/OLN  Cc : sfc 
>>issue tracker; [email-masked]; Joel Halpern; Joel M. Halpern  Objet : 
>> >authors.]] =======
>> >policies. When preparing the draft, I had a discussion with Joel 
>> >about this design. We both agreed that this is worth to be discussed.
>> >
>> What exactly is vague about this? Seems pretty clear, at least to me, 
>>how  progressive refinement from SFC to eventual RSP is achieved.
>> 
>> Jim
>> 
>> >
>> >Cheers,
>> >Med
>> >
>> >> De : Jim Guichard (jguichar) [mailto:[email-masked]]  Envoyé : 
>> >>mercredi 18 novembre 2015 17:18  À : Carlos Pignataro (cpignata); 
>> >>BOUCADAIR Mohamed IMT/OLN  Cc : sfc issue tracker; [email-masked]; 
>> >>Paul Quinn (paulq);
>> >>draft-ietf-sfc-
>> >> [email-masked]; Joel Halpern; Joel M. Halpern  Objet 
>> >>: Re: [sfc] #15 (control-plane): Whether the control plane operates  
>> >> I have to say I am struggling to see the “issue” in this thread 
>> >>that needs  to be addressed other than confusion over SFC vs SFP 
>> >>definition;
>>from a
>> >> data plane perspective it is *very* clear that SFP/SI identifiers 
>> >>are used  as the lookup key into a forwarding construct that may 
>> >>contain 1:n number  of next-hops (SFFs, SFs). In some cases that 
>> >>lookup will point to a single  next-hop, in others multiple 
>> >>next-hops. In *all* cases this has absolutely  nothing to do with 
>> >>the SFC as each representation of that SFC is uniquely  identified 
>> >>by an SFP-id.
>> >>
>> >> Jim
>> >>
>> >> >>data plane²
>> >> ><[email-masked]>, sfc issue tracker 
>> >> ><[email-masked]>, "[email-masked]" <[email-masked]>, Joel 
>> >> >Halpern
>> >> >>clearly states this is not discussed. A corresponding issue 
>> >> >>record has been recorded to seek for more feedback on that appendix.
>> >> >>
>> >> >>Cheers,
>> >> >>Med
>> >> >>
>> >> >>>Objet : Re: [sfc] #15 (control-plane): Whether the control 
>> >> >>> The control-plane draft says ³Suppose the SFC ID for this SFP 
>> >> >>> is "yellow²,², and my point again is that in the data plane an 
>> >> >>> SFP
>>has
>> >>an
>> >> >>> it¹s not a Family Name, and not an SFC ID), and the control 
>> >> >>>(and
>> >> >>>policy)
>> >> >>> >> -----Message d'origine----- De : Carlos Pignataro 
>> >> >>> >> (cpignata) [mailto:[email-masked]] Envoyé : mercredi 18 
>> >> >>> >> novembre 2015 11:52 À : Joel Halpern Cc : BOUCADAIR Mohamed 
>> >> >>> >> IMT/OLN; Paul Quinn (paulq);
>> >>draft-ietf-sfc-
>> >> >>> >>> Subject: RE: [sfc] #15 (control-plane): Whether the 
>> >> >>> >>> control
>> >>plane
>> >> >>> >>>> -----Message d'origine----- De : Joel Halpern 
>> >> >>> >>>> [mailto:[email-masked]]
>> >> >>> >>>> Envoyé : mardi 17 novembre 2015 14:49 À : BOUCADAIR 
>> >> >>> >>>> Mohamed IMT/OLN; Paul Quinn (paulq) Cc : sfc
>> >>issue
>> >> >>> >>>> (control-plane): Whether the control
>> >>plane
>> >> >>> >>>> Your statement that " It happens that information is no 
>> >> >>> >>>> more
>> >>than
>> >> >>>the
>> >> >>> >>>> the exact sequence of steps to be used to realize the 
>> >> >>> >>>> SFC".)
>> >>Does
>> >> >>>not
>> >> >>> >>>> make sense to me.
>> >> >>> >>>
>> >> >>> >>> [Med] RFC 7665 says:
>> >> >>> >>>
>> >> >>> >>> What is the name to use to refer to a "non-constrained" 
>> >> >>> >>> SFC
>>or
>> >>to
>> >> >>>the
>> >> >>> >>>> is not the same as the exact sequence of places that must 
>> >> >>> >>>> be
>> >> >>>visited.
>> >> >>> >>>>
>> >> >>> >>>> I stand by my earlier comments that almost all uses of 
>> >> >>> >>>> SFC
>>in
>> >>the
>> >> >>> >>>> Subject: RE: [sfc] #15 (control-plane): Whether the 
>> >> >>> >>>> control
>> >>plane
>> >> >>> >>>>  domain, some SFPs may be fully specified, selecting 
>> >> >>> >>>> exactly
>> >> which
>> >> >>> SFF
>> >> >>> >>>>  and which SF are to be visited by packets using that 
>> >> >>> >>>> SFP,
>> >>while
>> >> >>> other
>> >> >>> >>>>  SFPs may be quite vague, deferring to the SFF the 
>> >> >>> >>>> decisions
>> >> about
>> >> >>> the
>> >> >>> >>>>  exact sequence of steps to be used to realize the SFC.  
>> >> >>> >>>> The  specificity may be anywhere in between these extremes.
>> >> >>> >>>> "
>> >> >>> >>>>
>> >> >>> >>>> information when "deferring to the SFF the decisions 
>> >> >>> >>>> about
>>the
>> >> >>> >>>> I fully agree that whether a full path is specified 
>> >> >>> >>>> within a
>> >> >>>domain
>> >> >>> or
>> >> >>> >>>>> -----Message d'origine----- De : Paul Quinn (paulq) 
>> >> >>> >>>>> [mailto:[email-masked]] Envoyé :
>> >> >>>vendredi
>> >> >>> >>>>> (control-plane): Whether the control plane operates on 
>> >> >>> >>>>> SFC
>> >>IDs,
>> >> >>>SFP
>> >> >>> >> IDs, etc.
>> >> >>> >>>>>
>> >> >>> >>>>> Joel,
>> >> >>> >>>>>
>> >> >>> >>>>> I concur.
>> >> >>> >>>>>
>> >> >>> >>>>> control plane or above, and would be driven by 
>> >> >>> >>>>> requirements
>> >> other
>> >> >>> >>>>> requirements that talk about service function chain IDs 
>> >> >>> >>>>> can
>> be
>> >> >>> >>>>> accurately captured, in terms of data plane 
>> >> >>> >>>>> requirements,
>>by
>> >> >>>service
>> >> >>> >> function path IDs.
>> >> >>> >>>>>>> The control draft as it stands is compliant with the 
>> >> >>> >>>>>>> data
>> >> plane
>> >> >>> >>>>> architecture document.
>> >> >>> >>>>>>>
>> >> >>> >>>>>>> (3) Some deployments may not impose any constraint on 
>> >> >>> >>>>>>> the abstract
>> >> >>> >>>> SFC
>> >> >>> >>>

---

From: "Bottorff, Paul" <[email-masked]>
Date: Mon, 23 Nov 2015 23:34:21 +0000

Hi Ron:

It seems SI may also be needed in a forwarding decision since the SFP-id and flow-id are the same for every SF in the chain. 

It is also possible we are using an MPLS chain, MPLS Segment Route chain, or MAC chain to forward at the SFF. In these cases the SFF does rely on the SFP-id or SI.

Cheers,

Paul

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
Sent: Monday, November 23, 2015 1:59 PM
To: Jim Guichard (jguichar); [email-masked]
Cc: sfc issue tracker; [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi, Jim.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 23, 2015 4:40 PM
To: [email-masked]
Cc: sfc issue tracker <[email-masked]>; [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Med,

Jim

---

From: <[email-masked]>
Date: Tue, 24 Nov 2015 12:57:35 +0000

Hi Jim, all,

In order to make some progress, I suggest to make the following change as a resolution to the issue we are discussing. Other occurrences in the draft will be tweaked too.

===
OLD:

         [[Note: The question of whether the data plane operates just in
         terms of SFP IDs or needs SFC IDs, as described in this version
         of the draft, is still under discussion among the authors.]]
NEW:
   o  SFC Forwarding Policy Table: this table reflects the SFC-specific
      traffic forwarding policy enforced by SFF components for every
      relevant incoming packet that is associated to one of the existing
      SFCs.  The SFP Identifier (SFP-id) is used as a lookup key to
      determine forwarding action regardless of whether the SFC is fully
      constrained, partially constrained, or not constrained at all.
      Additional information such as a flow identifier and/or other
      characteristics (e.g., the 5-tuple transport coordinates of the original
      packet) may be used for lookup purposes.  The set of information
      to use for lookup purposes may be instructed by the control plane.
===

Please review this proposed text.

Cheers,
Med

> Envoyé : lundi 23 novembre 2015 22:40
> Cc : sfc issue tracker; [email-masked]
> >>how
> >> >>used
> clearly
> >> >> >>> >>>> service chain itself (without any constraints)." (Where
> "it"
> >> >> >>>refers
> >> >> >>> to
> >> >> >>> >> "
> >> >> >>> >>> "   Thus, the policies and logic of SFP selection or
> creation
> >> >> >>> (depending
> The
> >> >> >>> >>>> I fully agree that whether a full path is specified within
> a
> >> >> >>>domain
> >> >> >>> or

---

From: <[email-masked]>
Date: Tue, 24 Nov 2015 12:59:38 +0000

Hi,

The new text looks good to me - thanks to Med for this proposal.

Cheers,

Christian.

-----Message d'origine-----
De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 24 novembre 2015 13:58
À : Jim Guichard (jguichar); [email-masked]
Cc : sfc issue tracker
Objet : Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

Hi Jim, all,

===
OLD:

Cheers,
Med

> lundi 23 novembre 2015 22:40 À : BOUCADAIR Mohamed IMT/OLN Cc : sfc 
> issue tracker; [email-masked] Objet : Re: [sfc] #15 (control-plane): 
> Whether the control plane operates on SFC IDs, SFP IDs, etc.
> 
> Hi Med,
> 
> I think the point is that the SFP-id (not SFC-id or any other id) is 
> used as the lookup key to determine forwarding action regardless of 
> whether the SFC is fully constrained, partially constrained, or not 
> constrained at all. Forwarding is simply realized by the result of the 
> lookup on the SFP-id.
> 
> Jim
> 
> >The one which is less clear is when there are no constraints on the 
> >sfc and, using the wording from the dp arch RFC, the decisions are 
> >realize the SFC" (Section 2.3 of RFC 7665). Calling that case an SFP 
> >is odd since SFP is by definition a "thought of as a constrained 
> >version of the original SFC" (Section 2.3 of RFC 7665)
> >
> >>jeudi 19 novembre 2015 15:43  À : BOUCADAIR Mohamed IMT/OLN  Cc : 
> >>sfc issue tracker; [email-masked]; Joel Halpern; Joel M. Halpern  
> >> >interfaces the underlying dp elements with SFC, SFP, RSP, and 
> >> >other policies. When preparing the draft, I had a discussion with 
> >> >Joel about this design. We both agreed that this is worth to be discussed.
> >> >
> >> Jim> which document and what exactly is too vague? For example if 
> >> Jim> we
> >>refer
> >>    specify exactly which instance of each firewall and caching 
> >> engine
> is
> >>    to be used.
> >>
> >>
> >> What exactly is vague about this? Seems pretty clear, at least to 
> >>me, how  progressive refinement from SFC to eventual RSP is 
> >>achieved.
> >>
> >> Jim
> >>
> >> >
> >> >Cheers,
> >> >Med
> >> >
> >> >> De : Jim Guichard (jguichar) [mailto:[email-masked]]  Envoyé 
> >> >>: mercredi 18 novembre 2015 17:18  À : Carlos Pignataro 
> >> >>(cpignata); BOUCADAIR Mohamed IMT/OLN  Cc : sfc issue tracker; 
> >> >>[email-masked]; Paul Quinn (paulq);
> >> >>draft-ietf-sfc-
> >> >> as the lookup key into a forwarding construct that may contain 
> >> >>1:n number  of next-hops (SFFs, SFs). In some cases that lookup 
> >> >>will point to a single  next-hop, in others multiple next-hops. 
> >> >>In *all* cases this has absolutely  nothing to do with the SFC as 
> >> >>each representation of that SFC is uniquely  identified by an 
> >> >>SFP-id.
> >> >>
> >> >> Jim
> >> >>
> >> >> >>> Envoyé : mercredi 18 novembre 2015 15:35 À : BOUCADAIR 
> >> >> >>> Mohamed IMT/OLN Cc : Paul Quinn (paulq);
> >> >> >>> The control-plane draft says ³Suppose the SFC ID for this 
> >> >> >>> SFP is "yellow²,², and my point again is that in the data 
> >> >> >>> plane an SFP
> >>has
> >> >>an
> >> >> >>> >> (cpignata) [mailto:[email-masked]] Envoyé : mercredi 
> >> >> >>> >> 18 novembre 2015 11:52 À : Joel Halpern Cc : BOUCADAIR 
> >> >> >>> >> Mohamed IMT/OLN; Paul Quinn (paulq);
> >> >>draft-ietf-sfc-
> >> >> >>> >> I too agree with Joel and strongly believe there is no 
> >> >> >>> >> need
> >>for
> >> >>SFC
> >> >> >>> >> which belongs in the policy/control itself, but not out 
> >> >> >>> >> of
> >> there.
> >> >> >>> >>
> >> >> >>> >> you are introducing extra complexity without adding any 
> >> >> >>> >> new
> >> cases
> >> >> >>>that
> >> >> >>> can
> >> >> >>> >> be handled.
> >> >> >>> >>>
> >> >> >>> >>> Yours,
> >> >> >>> >>> Joel
> >> >> >>> >>>
> >> >> >>> >>>> specificity of the SFP.  Architecturally, within the 
> >> >> >>> >>>> same
> >> SFC-
> >> >> >>> enabled
> >> >> >>> >>>> that information is no more than the service chain 
> >> >> >>> >>>> itself
> >> >> (without
> >> >> >>> any
> >> >> >>> >>>> constraints).
> >> >> >>> >>>>
> >> >> >>> >>>>> Thus, the requirement that the data plane has is to 
> >> >> >>> >>>>> see
> >>such
> >> >> path
> >> >> >>> IDs.
> >> >> >>> >>>>>> Introducing a requirement for the data plane to see 
> >> >> >>> >>>>>> and
> >>work
> >> >> >>>with
> >> >> >>> >>>>>> chain

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Tue, 24 Nov 2015 15:01:47 +0000

Hi Med,

I would like to see “SFC Forwarding Policy Table” replaced with “SFP
Forwarding Policy Table” and “SFC-specific traffic forwarding” replaced
with “SFP-specific traffic forwarding”; forwarding is determined based
upon the SFP *not* SFC. If you can make those changes the text looks good.

Jim

On 11/24/15, 7:57 AM, "[email-masked]"
<[email-masked]> wrote:

>Hi Jim, all,
>
>In order to make some progress, I suggest to make the following change as
>a resolution to the issue we are discussing. Other occurrences in the
>draft will be tweaked too.
>
>===
>OLD:
>>"deferred
>> >> >What we are discussing is related to this part of the draft (and
>>some
>> >> >other occurrences):
>> >> >
>> >> >======
>> >> >I explained, and other have done that too, that both models should
>>be
>> >> >addressed.
>> >> >
>> >> >The discussion revealed the definition in the dp RFC are too vague.
>>We
>> >> >need to resolve that as WG.
>> >>
>> >> >> of next-hops (SFFs, SFs). In some cases that lookup will point to
>>a
>> >> >>single
>><[email-masked]>,
>> >> >> >>> >>>> À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq) Cc :
>>sfc
>> >> >>issue
>> >> >> >>> >>>>> De : Paul Quinn (paulq) [mailto:[email-masked]] Envoyé
>>:
>> >> >> >>>vendredi
>> >> >> >>> >>>>> Yes, in some deployments those will be 1-1 with chain
>>IDs.
>> >> >>They
>> >> >> >>>are
>> >> >> >>> >>>> still path IDs.
>> >> >> >>> >>>>>>

---

From: <[email-masked]>
Date: Tue, 24 Nov 2015 15:37:56 +0000

Re-,

I can make those changes.

Cheers,
Med

> Envoyé : mardi 24 novembre 2015 16:02
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : sfc issue tracker
> me,
> 1:n
> >> >> >>number
> >> >> >> >"   o  Populate SFC forwarding policy tables of involved SFC
> data
> >> >> >>plane²
> >> >> >> >
> >> >> >> >
> >> >> >> >Or at:

---

From: "sfc issue tracker" <[email-masked]>
Date: Wed, 25 Nov 2015 10:29:03 -0000

Comment (by [email-masked]):

 The following changes are made in -01:

 OLD:

 NEW:
    o  SFP Forwarding Policy Table: this table reflects the SFP-specific
       traffic forwarding policy enforced by SFF components for every
       relevant incoming packet that is associated to one of the existing
       SFCs.  The SFP Identifier (SFP-id) is used as a lookup key to
       determine forwarding action regardless of whether the SFC is fully
       constrained, partially constrained, or not constrained at all.
       Additional information such as a flow identifier and/or other
       characteristics (e.g., the 5-tuple transport coordinates of the
       original packet) may be used for lookup purposes.  The set of
       information to use for lookup purposes may be instructed by the
       control plane.

 * Add this NEW text to Section 1.3:
 NEW:
    As a reminder, a Service Function Path (SFP) designates a subset of
    the collection designated by the SFC.  For some SFPs, in some
    deployments, that will be a set of 1.  For other SFPs (in the same or
    other deployments) it may be a larger set.  For some SFPs in some
    deployments the SFP may designate the same set of choices as the SFC.
    This document accommodates all those deployments.

 * Others minor edits.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-sfc-
  [email-masked]       |  [email-masked]
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  control-plane            |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sfc/trac/ticket/15#comment:1>
sfc <http://tools.ietf.org/sfc/>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 25 Nov 2015 21:00:56 +0000

This reads as a positive change. I agree those relate to SFP and not SFC. 

Thanks,

> On Nov 24, 2015, at 10:38, "[email-masked]" <[email-masked]> wrote:
> 
> Re-,
>