Subject: Re: [sfc] About minimal controller requirement

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Tue, 4 Apr 2017 01:45:28 +0000

Thanks for you reply, please see comments inline.
Thanks
Roberta

-----Original Message-----
From: Sumandra Majee [mailto:[email-masked]] 
Sent: Friday, March 31, 2017 4:37 AM
To: Roberta Maglione (robmgl) <[email-masked]>
Cc: [email-masked]
Subject: Re: About minimal controller requirement

Hello,

Thanks for your input. I noticed the SF type in the bgp nsh draft and keeping up with minimal controller/config requirement, why would controller need to know the type of service.

Having said that, I agree it is useful and a full-fledged orchestrator can use this to create dynamic service chains on demand based functionality. So if a chain requires FW <-> TCP-OPT<->NAT then one can connect those types appropriately. 

[RM] My understanding of your answer is that the "SF type" is an useful concept in order to be able to build a fully orchestrated solution, but it introduces some challenges and I agree on that.

But then,
a) How does the controller know it if it is properly configured, is the type available once the brick boots up into a “proper” mode?
[RM] in my opinion this question is not related to the Sf type, it's orthogonal to this discussion, it stays even if you don't define/use the SF type.

b) What would be the type of a multi function device. Advanced L7 devices are tcp-opt+adc+many other functions… so is it a multi function type. If the answer is yes then it is a set of type. 
[RM] I agree this requires more thoughts, but I think it's similar to what you are trying to do with capabilities exchange

c) Having a type means yet another semantics to deal with, again from the bare minimal requirement it might be non-essential but useful information.

[RM] well, I see the SF type as an indirection level to the concrete SF: you can have a SC that requires for example a FW (this the SF type), than the orchestrator system checks and decides if there is already an available (capable to be used for another service chain) FW SF or if it needs to spin up a new VM with a FW SF and then provide the details of this new Sf to the controller. 

On 3/29/17, 7:11 AM, "Roberta Maglione (robmgl)" <[email-masked]> wrote:

    Hello Sumandra,
    I listened to your presentation in sfc yesterday and I have a comment:
    in slide 3, as part of the minimal configuration requirements you listed the SF Name. I agree with you that SF name is needed for the configuration, but when we first looked at this problem what we thought  it would be useful for the controller to have is an additional level of abstraction  for Service Function type. The reason for this is because there could be multiple  instances of the same SF type and the controller may be able to choose which instance to use to build a specific chain. The concept of  "service function type" is also part of the bgp/bess nsh draft.
    Please let me know what you think.
    Thanks
    Roberta