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

From: "sfc issue tracker" <[email-masked]>
Date: Wed, 16 Sep 2015 13:46:46 -0000

#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.

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Sep 2015 13:15:13 -0400

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

---

From: <[email-masked]>
Date: Thu, 17 Sep 2015 11:53:26 +0000

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.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Sep 2015 11:36:57 -0400

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

---

From: Ron Parker <[email-masked]>
Date: Thu, 17 Sep 2015 20:33:19 +0000

Joel,

I agree with your position.   Elements of the SFC architecture (e.g., SFF) need to know about multiple aspects of any particular SFP including which of its SF's shall be invoked and in which order, which is the next SFF, if any, etc.   It is not unreasonable for it to also know to which chain it belongs, if such knowledge is necessary or beneficial.   And if it is beneficial, this binding can come in the control plane along with the other attributes describing the SFP.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, September 17, 2015 11:37 AM
To: [email-masked]; sfc issue tracker <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc.

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:
>> De : Joel M. Halpern [mailto:[email-masked]] Envoyé : mercredi 
>> 16 septembre 2015 19:15 À : sfc issue tracker; 
>> [email-masked];
>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane 
>> operates on SFC IDs, SFP IDs, etc.
>>
>> 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
>>
>>>             [[Note: The question of whether the data plane operates 
>>> just
>> in
>>>    manipulating service chains based on an identifier of the chain. 
>>> Also,
>> it
>>>    An identifier of the chain is the minimum information that is 
>>> needed,
>> but

---

From: <[email-masked]>
Date: Fri, 18 Sep 2015 06:06:25 +0000

Hi Joel,

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]
> > 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.
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 20 Sep 2015 03:02:23 +0000

Med,

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]" <[email-masked]> wrote:
> 
> Hi Joel,
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Mon, 21 Sep 2015 05:30:27 +0000

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

> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
> Envoyé : dimanche 20 septembre 2015 05:02
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joel M. Halpern; sfc issue tracker; draft-ietf-sfc-control-
> [email-masked]; [email-masked]
> 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.
> 
> > 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.
> >
> architecture