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]> 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]] De la part de Daniel Migault > > Envoyé : mardi 28 juin 2016 17:43 > > À : [email protected]; [email protected] > > Cc : Alireza Ranjbar; [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]] > > 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. > > > > The IETF Secretariat > > > > _______________________________________________ > > Dots mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dots >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
