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

From: <[email-masked]>
Date: Mon, 23 Nov 2015 06:35:48 +0000

Re-,

A trivial case is when there are no constraints on the chain itself (no predetermined loose/strict path). Packets bound to a chain will fly over a (hop-by-hop computed) path that will result from the decision-making process of crossed sfc-aware elements, distributed load-balancing policies, local SF failure detect/repair, etc.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : jeudi 19 novembre 2015 15:22
> À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson
> Cc : [email-masked]
> Objet : Re: [sfc] #15 (control-plane): Whether the control plane operates
> on SFC IDs, SFP IDs, etc.
> 
> 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
> 
> On 11/19/15 2:41 AM, [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.).
> >
> > 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
> >
> >> -----Message d'origine-----
> >> De : Dave Dolson [mailto:[email-masked]]
> >> Envoyé : jeudi 19 novembre 2015 08:32
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : [email-masked]
> >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane
> operates
> >> on SFC IDs, SFP IDs, etc.
> >>
> >> 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:
> >>
> >> ==
> >> SFC <--> destination host name
> >> SFP <--> destination IP address
> >> RSP <--> sequence of routers and links to deliver the IP packet
> >> ==
> >>
> >> 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
> >>
> >>> -----Message d'origine-----
> >>> De : sfc [mailto:[email-masked]] De la part de Dave Dolson
> >>> Envoyé : mercredi 18 novembre 2015 20:34
> >>> À : Jim Guichard (jguichar)
> >>> Cc : [email-masked]
> >>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane
> >> operates
> >>> on SFC IDs, SFP IDs, etc.
> >>>
> >>> [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); draft-ietf-
> sfc-
> >>> [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:
> >>>
> >>>> 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.
> >>>>
> >>>>> 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
> >>>>>
> >>>>>> -----Message d'origine-----
> >>>>>> De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
> >>>>>> Envoyé : mercredi 18 novembre 2015 15:35
> >>>>>> À : BOUCADAIR Mohamed IMT/OLN
> >>>>>> Cc : Paul Quinn (paulq); draft-ietf-sfc-control-
> >> [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,
> >>>>>>
> >>>>>>> On Nov 18, 2015, at 8:08 AM, [email-masked] wrote:
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>
> >>>>>> 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.
> >>>>>>
> >>>>>>> Cheers,
> >>>>>>> Med
> >>>>>>>
> >>>>>>>> -----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-
> >>>>>>>> [email-masked]; Joel M. Halpern; sfc issue tracker;
> >>>>>>>> [email-masked]
> >>>>>>>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane
> >>>>>> operates
> >>>>>>>> on SFC IDs, SFP IDs, etc.
> >>>>>>>>
> >>>>>>>> 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:
> >>>>>>>>>
> >>>>>>>>> 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; draft-ietf-sfc-control-
> >>> [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
> >>>>>>>>>
> >>>>>>>>>> -----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
> >>>>>>>>>> tracker; [email-masked];
> >>>>>>>>>> [email-masked]; Joel M. Halpern
> >>>>>>>>>> Objet : RE: [sfc] #15 (control-plane): Whether the control
> >> plane
> >>>>>>>>>> operates on SFC IDs, SFP IDs, etc.
> >>>>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>>
> >>>>>>>>>> I stand by my earlier comments that almost all uses of SFC in
> >> the
> >>>>>>>>>> control requirements draft should be SFP.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [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
> >>>>>>>>>>
> >>>>>>>>>> -----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,
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> sfc mailing list
> >>>>>>>>> [email-masked]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/sfc
> >>>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> sfc mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/sfc
> >>>
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sfc
> >>> _______________________________________________
> >>> sfc mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sfc
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
> >

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 23 Nov 2015 10:27:35 -0500

And that case can be easily handled by carrying and SFP ID.  There is no 
need for an SFC ID in the communication between the control plane and 
the data plane.

Yours,
Joel