Subject: Re: [sfc] How to progress our control plane requirements document

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Feb 2017 10:44:49 -0600

Hi Med,

I am curious, we are putting so much effort, so many cycles on CP
requirements, while I think the real interest on this should be what
is this CP protocol itself? People are asking where is the beef?

Currently this is somewhat mysteriously hidden.

I suggest putting our efforts, the real minds on that?

Regards,

Behcet

On Mon, Feb 20, 2017 at 1:26 AM,  <[email-masked]> wrote:
> Hi Adrian,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Adrian Farrel [mailto:[email-masked]]
>> Envoyé : vendredi 17 février 2017 17:30
>> À : BOUCADAIR Mohamed IMT/OLN; 'Eric C Rosen'; 'Joel M. Halpern';
>> [email-masked]
>> Objet : RE: [sfc] How to progress our control plane requirements document
>>
>> Hi Med,
>>
>> I'm not convinced that this draft should address the CP requirements in
>> your
>> draft.
>
> [Med] That's fine by me. It is perfectly fine to address a subset of requirements, but what I'm less comfortable with is to call a proposal (The) "Control plane for SFC".
>
> It seems more important to build a functional system(i.e., one that
>> works
>> and delivers the operational function that makes an SFC network work).
>>
>> Therefore, in reviewing the draft it may be more helpful to say:
>> - this doesn't work
>> - I need to achieve this function
>> - this could be done better.
>>
> [Med] I confess this wasn't my perspective when reading the mackie draft.
>
>> But for completeness, here are some answers to your points:
>>
>> > For example, I checked your BGP CP draft to check if it addresses the CP
>> > requirement in the SFC CP draft. Many of these CP requirements are
>> included in
>> > your proposal but many others are missing, e.g.,
>> >
>> > * I don't see how classification rules are installed/removed/updated.
>>
>> Section 7.5
> [Med] Sorry. Thank you for the pointer.
>
>>
>> > * I don't see any features to associate classification and forwarding
>> entries
>> with
>> > validity lifetime.
>>
>> I don't believe this to be a useful feature.
>
> [Med] Programming a state that is not limited in time may be a source of troubles from a manageability standpoint. Means to help the classifier to automatically clean its table without an explicit action from a third party (controllers) are useful, IMO.
>
>> But it could be added at some point.
>>
> [Med] Sure. BGP is powerful enough :)
>
>> > * I don't see how the CP sets the SI at classifiers
>>
>> Section 7.5
>>
>> > * I don't see how the CP set the semantic of a metadata per each chain,
>> scope,
>> > etc.
>>
>> It would be premature to define a control plane for something that hasn't
>> been
>> properly specified in the forwarding plane.
>
> [Med] I understand your argument about the weakness of the DP plane spec in this regards, but I do think that is (hopefully) fixed with the new text (https://trac.ietf.org/trac/sfc/ticket/21)
>
>> But it seems to me that most SFs will not be so programmable: they will
>> look for
>> specific TLVs in metadata and ignore (forward) the rest, and they will add
>> specific TLVs to the metadata.
>
> [Med] I don't know what is/will be a default behavior of an SFC-ware SF. For example, I don't see based on which criteria a CGN or firewall SF will decide that it must look for particular TLVs. Also, I don't see based on which criteria a classifier implementation will decide to inject a given set of TLVs, etc. There is a void that needs to be fulfilled by the CP.
>
>> Sending CP messages will not change the behavior of SFs in this regard.
> [Med] There is a need to communicate SFC instructions to underlying SFC-aware nodes.
>
>> Attempting to do so would be adding unnecessary complexity to the system.
>>
>> > * I don't see how the CP indicates the behavior to follow when a
>> metadata is
>> > consumed
>>
>> Ditto the above only more so!
>> An SF is an SF and is not CP-programmable.
>
> [Med] We are not talking about SFs in general, but about SFC-aware SFs. Of course, SF-specific control is not of interest here.
>
>>
>> > * I don't see how an SFC proxy in instructed to insert/supply metadata
>> on
>> behalf
>> > of SFC-unaware SFs
>>
>> An SFC proxy is, in that respect, no different from the metadata component
>> of an
>> SF that can handle metadata.
>
> [Med] ... except that the proxy does not know what TLVs are to be inserted/stripped/modified per attached SF (and per chain).
>
>>
>> But you *have* pointed to an interesting "hole" in the architecture if it
>> is
>> assumed that the SFC proxy can somehow know about the state in the SFC-
>> unaware
>> SF and shape metadata accordingly.
>>
>> > * I don't see the CP behavior when an SF is to be withdrawn
>>
>> I don't even know what it means to "withdraw an SF".
>
> [Med]  What I meant is, for example, when an SF is decommissioned or when now instance is available to deliver the service. Does the solution allows to maintain the installed SFPs but with a bypass of that SF or it imposes to reinstall new paths.
>
>> Do you mean "to take an SFI gracefully out of service"? If so, you would
>> simply
>> withdraw the SFIR and the route would go (as is normal in BGP).
>> Or do you mean "to remove an SF from an SFP"? If so, 4.5.1.
>>
>> > * I don't see how an SFC proxy is instructed about the SFs to service.
>>
>> Are you asking how a proxy that severs more than one SF knows to which SF
>> to
>> route packets?
>
> [Med] This is more about checking that only entitled SFs are authorized to be serviced by a proxy.
>
>> If you are, then my answer is "don't do that!" Proxies are cheap. You can
>> virtualise a proxy at any location.
>>
>> > * Etc.
>>
>> See section, oh... :-)
>
> [Med] Will read that section SOON ;-)
>
>>
>> Thanks,
>> Adrian
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Feb 2017 17:40:38 -0000

Hi Behcet,

datatracker.ietf.org/doc/draft-mackie-bess-nsh-bgp-control-plane/

:-)

Adrian

> -----Original Message-----
> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: 20 February 2017 16:45
> To: Mohamed Boucadair
> Cc: [email-masked]; Eric C Rosen; Joel M. Halpern; [email-masked]
> Subject: Re: [sfc] How to progress our control plane requirements document
> 
> Hi Med,
> 
> > [Med] That's fine by me. It is perfectly fine to address a subset of
> requirements, but what I'm less comfortable with is to call a proposal (The)
> "Control plane for SFC".
> >
> > [Med] Programming a state that is not limited in time may be a source of
> troubles from a manageability standpoint. Means to help the classifier to
> automatically clean its table without an explicit action from a third party
> (controllers) are useful, IMO.
> >
> > [Med] I understand your argument about the weakness of the DP plane spec in
> this regards, but I do think that is (hopefully) fixed with the new text
> (https://trac.ietf.org/trac/sfc/ticket/21)
> >
> > [Med] I don't know what is/will be a default behavior of an SFC-ware SF. For
> example, I don't see based on which criteria a CGN or firewall SF will decide that it
> must look for particular TLVs. Also, I don't see based on which criteria a classifier
> implementation will decide to inject a given set of TLVs, etc. There is a void that
> needs to be fulfilled by the CP.
> >
> > [Med] We are not talking about SFs in general, but about SFC-aware SFs. Of
> course, SF-specific control is not of interest here.
> >
> >>
> > [Med] ... except that the proxy does not know what TLVs are to be
> inserted/stripped/modified per attached SF (and per chain).
> >
> >>
> > [Med]  What I meant is, for example, when an SF is decommissioned or when
> now instance is available to deliver the service. Does the solution allows to
> maintain the installed SFPs but with a bypass of that SF or it imposes to reinstall
> new paths.
> >

---

From: <[email-masked]>
Date: Tue, 21 Feb 2017 06:55:21 +0000

Hi Behcet, 

Please see inline. 

Cheers,
Med

> De : Behcet Sarikaya [mailto:[email-masked]]
> Envoyé : lundi 20 février 2017 17:45
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; Eric C Rosen; Joel M. Halpern; [email-masked]
> Objet : Re: [sfc] How to progress our control plane requirements document
> 
> Hi Med,
> 
> is this CP protocol itself?

[Med] I'm not sure there will "one" CP protocol. It is likely there will be many protocols and protocols extensions to fill the void. For example, 
* some deployments may reuse their existing PCC architecture but augmented with new tools,
* while others may want to reuse their RADIUS platforms to interact with the classifier while other SFC nodes are controlled via one or more control elements,
* some other deployments may have a preference for an extension to BGP
* others may prefer to use PCE
* other may combine BGP and PCE, and so on.

The whole point of this requirement effort was to make sure that a minimum set of CP requirements, drawn from the perspective of the SFC WG but defined in other WG eventually, are fulfilled within an SFC domain. 

I don't see how the IETF can mandate a given deployment to use BGP (for example) while an update of existing control tools may do the job. For example, mandating that every SF instance to be a BGP speaker is too high. 

 People are asking where is the beef?

[Med] You have to wait for the starter first. I fully agree it is frustrating to wait for too long. I hear you, Behcet.

> requirements, but what I'm less comfortable with is to call a proposal
> (The) "Control plane for SFC".
> >
> automatically clean its table without an explicit action from a third
> party (controllers) are useful, IMO.
> >
> > [Med] I understand your argument about the weakness of the DP plane spec
> in this regards, but I do think that is (hopefully) fixed with the new
> text (https://trac.ietf.org/trac/sfc/ticket/21)
> >
> > [Med] I don't know what is/will be a default behavior of an SFC-ware SF.
> For example, I don't see based on which criteria a CGN or firewall SF will
> decide that it must look for particular TLVs. Also, I don't see based on
> which criteria a classifier implementation will decide to inject a given
> set of TLVs, etc. There is a void that needs to be fulfilled by the CP.
> >
> > [Med] We are not talking about SFs in general, but about SFC-aware SFs.
> Of course, SF-specific control is not of interest here.
> >
> >>
> > [Med]  What I meant is, for example, when an SF is decommissioned or
> when now instance is available to deliver the service. Does the solution
> allows to maintain the installed SFPs but with a bypass of that SF or it
> imposes to reinstall new paths.
> >

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 21 Feb 2017 15:59:59 -0600

> I don't see how the IETF can mandate a given deployment to use BGP (for example) while an update of existing control tools may do the job. For example, mandating that every SF instance to be a BGP…

I agree that BGP speaker requirement is too high.
Also I don't think SDN approaches like path computation element would
suit us here.

Why not an in house CP protocol for SFC?

Regards,

Behcet

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Feb 2017 20:01:21 -0000

>> I don't see how the IETF can mandate a given deployment to use BGP (for
>> example) while an update of existing control tools may do the job. For example,
>> mandating that every SF instance to be a BGP speaker is too high.
>>
> 

Just in case there should be any doubt, draft-mackie-bess-nsh-bgp-control-plane does NOT require or even suggest that SFs be BGP speakers.

OTOH, it recognises that the SFC network is an overlay of tunnels between SFFs, and that a routing protocol is appropriate for that type of network.

Of course, if folk want to operate SFC networks using a north-south management plane model, that is their business, and it shouldn't be too hard to achieve except in complex and large networks.

Adrian