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

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 16 Oct 2015 12:04:28 +0000

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