Daniel,
Based on your description, your proposed collaboration information exchange is
between two domain’s orchestration systems, i.e. the “A” interface in the
I2NSF framework, Correct?
+-----------------------------------------------------+
| I2NSF Client |
| E.g. Overlay Network Mgnt, Enterprise network Mgnt |
| another network domain’s mgnt, etc. |
+----------+------------------------------------------+
|
| Client Facing Interface (A)
|
+-----+---------------+
|Network Operator mgmt| +-------------+
| Security Controller | < --------- > | Developer’s |
+---------------+-----+ Registration | Mgnt System |
| Interface +-------------+
|
| NSF Facing Interface (B)
|
+---------------------------+-----------------------+
| |
| |
+---+--+ +------+ +------+ +--+---+
+ NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . .
+------+ +------+ +------+ +------+
Developer A Developer B
Figure 1: I2NSF Reference Model
Is it necessary for the "Down" network to provide the list of SFs to "Upper"
network? or it is up to the “down” network to use its own SFs based on the
policies from “Upper” network?
Thanks, Linda
From: I2nsf [mailto:[email protected]] On Behalf Of Daniel Migault
Sent: Thursday, July 07, 2016 9:23 AM
To: [email protected]
Cc: [email protected]; [email protected]; Alireza Ranjbar
Subject: Re: [I2nsf] New Version Notification for
draft-mglt-i2nsf-ssf-collaboration-00.txt
Hi Med,
Thank you for the feed backs. Please see inline my responses. I would be happy
discuss more in depth these questions in Berlin!
BR,
Daniel
On Wed, Jun 29, 2016 at 8:19 AM,
<[email protected]<mailto:[email protected]>> wrote:
Hi Daniel, all,
Thank you for sharing this draft.
I have some high-level questions about this proposal:
* In which deployment case you think that a service function will take the
responsibility to contact another service function located in another domain to
ask for collaboration? Wouldn't that be the responsibility of the respective
administrative entities managing those domains?
MGLT: In our case, the collaboration is established between between the
administrative entity of each domain. Once the provider and the initiator have
agreed on setting a collaboration defined by the resources to be engaged, as
well as the service, I would say the collaboration is set. in some cases, the
security service instantiated may require additional configurations. For
example, when a firewall is being instantiated by the provider, the initiator
may then need to configure the firewall. Such configuration in our view is not
pat of the collaboration. Instead what would be part of the collaboration is
the ability for the firewall to be configured by X using protocol Y. X could be
a SF or the orchestrator of the domain.
* Based on which criteria an SSF may decide that it needs collaboration with
another SSF? Wouldn't that be driven by service requirements and objectives
(that are not visible to a monolithic SSF)?
MGLT: In our case, the criteria is when a DDoS attack is being detected, and
the attack can be better mitigated in another domain. This means that the
orchestrator takes the decision given the various inputs it receives from the
SSFs. But the collaboration could also be requested by a single SSF.
* Given that service functions deployed in a given domain are unlikely to be
disclosed outside that domain, how SSF discovery is achieved?
MGLT: That is a good question. Currently we assume that the you know the next
upper/ lower provider you woudl like to set the collaboration with. We have not
yet designed an appropriated SSF discovery protocol. One reason also for it is
that we need to think of a common language for service designation.
* Would collaboration be tied to the 'initiator' and 'provider' instances which
are involved in a CA? Is that optimal given that multiple instances of the same
SSF may be deployed in a given domain for various reasons (load-balancing,
resiliency, etc.)?
MGLT: In our case, collaboration is mostly set between the orchestrators of the
different domain. We also had scenario with a single domain where one SSF
dynamically ask duplication of its SSF instances, and when multiple SSF are
duplicated, we had one collaboration per duplicated instance.
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : Dots [mailto:[email protected]<mailto:[email protected]>] De la
> part de Daniel Migault
> Envoyé : mardi 28 juin 2016 17:43
> À : [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
> Cc : Alireza Ranjbar; [email protected]<mailto:[email protected]>
> Objet : Re: [Dots] New Version Notification for draft-mglt-i2nsf-ssf-
> collaboration-00.txt
>
> Hi,
>
> Please find our draft for elaborating a collaboration between security
> services locate in different administrative domains.
>
> Feed backs /Comments are welcome!
> BR,
> Daniel
>
> -----Original Message-----
> From: [email protected]<mailto:[email protected]>
> [mailto:[email protected]<mailto:[email protected]>]
> Sent: Tuesday, June 28, 2016 6:40 PM
> To: Daniel Migault; Alireza Ranjbar
> Subject: New Version Notification for draft-mglt-i2nsf-ssf-collaboration-
> 00.txt
>
>
> A new version of I-D, draft-mglt-i2nsf-ssf-collaboration-00.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> repository.
>
> Name: draft-mglt-i2nsf-ssf-collaboration
> Revision: 00
> Title: Collaboration Agreement for Security Service Function
> Document date: 2016-06-28
> Group: Individual Submission
> Pages: 13
> URL: https://www.ietf.org/internet-drafts/draft-mglt-i2nsf-ssf-
> collaboration-00.txt
> Status: https://datatracker.ietf.org/doc/draft-mglt-i2nsf-ssf-
> collaboration/
> Htmlized: https://tools.ietf.org/html/draft-mglt-i2nsf-ssf-
> collaboration-00
>
>
> Abstract:
> This document specifies a collaboration agreement protocol. The
> collaboration agreement makes possible individual security services
> functions (SSF) to collaborate with each other. The collaboration is
> mostly intended for SSF located in different administrative domains,
> in which case the collaboration cannot be performed by a shared
> orchestrator.
>
> The collaboration between SSF in different domains assumes the
> traffic is steered through the two domains.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
> _______________________________________________
> Dots mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/dots
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
