Subject: [I2nsf] I2NSF Terminology draft : Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

From: Linda Dunbar <[email-masked]>
Date: Sat, 18 Jun 2016 21:08:46 +0000

Dear authors of the I2NSF terminology draft:

I2NSF framework has two different types of clients:

1.      One type of client sending inquiry/request for Flow Security Policy to a controller (who controls a network). For example: an overlay network controller sending inquiry/request for Flow Security Policy to an underlay network controller.

2.      Another type of client is the controller sending Flow Security Policy to individual NSFs.

Simply put, the client described in 1) is making request to the (I2NSF) Controller (i.e. the controller’s North Bound Interface); and the “client” described in 2) is making request to the NSFs ( i.e. the controller’s South Bound Interface).

It seems to me that the “I2NSF Client” described in the current I2NSF Terminology draft is performing the “controller” function, and the “I2NSF Agent” is residing in the NSF for receiving the flow security policies from the “Controller”.

Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

Any suggestions?

Linda

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 20 Jun 2016 09:46:18 +0000

Hi Linda,

The obvious suggestion that comes to my mind is to use the SDN analogy, and call the clients of type 1 “I2NSF applications” and those of type 2 “I2NSF controllers”

Be goode,

On 18 Jun 2016, at 23:08 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Any suggestions?

Linda

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 Jun 2016 12:02:12 +0000

Diego,

Do you mean that we should abandon the general “I2NSF Client” term, instead having the following two separate definitions?

Controller Client: I2NSF applications that send inquiry/request for Flow Security Policy to a controller (who controls a network). For example: an overlay network controller sending inquiry/request for Flow Security Policy to an underlay network controller

NSF Client: I2NSF controllers that send Flow Security Policy to individual NSFs

Linda

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Monday, June 20, 2016 4:46 AM
To: Linda Dunbar
Cc: John Strassner; Xialiang (Frank); Susan Hares; [email-masked]
Subject: Re: [I2nsf] I2NSF Terminology draft : Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

Hi Linda,

Be goode,

Any suggestions?

Linda

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 21 Jun 2016 12:28:09 +0000

Hi,

Not exactly. We could say that we have two type of I2NSF clients:

* I2NSF applications, sending inquiry/request for Flow Security Policy to a controller (which controls a security domain)

* I2NSF controllers, that collect and expose NSF capabilities, and send Flow Security Policy to individual NSFs within a security domain

(Note the use of the term “security domain” rather than “network”)

Be goode,

On 21 Jun 2016, at 14:02 , Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:

Diego,

Linda

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Monday, June 20, 2016 4:46 AM
To: Linda Dunbar
Cc: John Strassner; Xialiang (Frank); Susan Hares; [email-masked]<mailto:[email-masked]>
Subject: Re: [I2nsf] I2NSF Terminology draft : Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

Hi Linda,

Be goode,

Any suggestions?

Linda

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 Jun 2016 12:34:43 +0000

Diego,

That is great suggestion. Can the authors of the I2NSF terminology draft add those wording to the draft?

Thanks, Linda

From: DIEGO LOPEZ GARCIA [mailto:[email-masked]]
Sent: Tuesday, June 21, 2016 7:28 AM
To: Linda Dunbar
Cc: John Strassner; Xialiang (Frank); Susan Hares; [email-masked]
Subject: Re: [I2nsf] I2NSF Terminology draft : Is it better to have two distinct terminologies to differentiate the “Client to controller” from the “Client to NSFs”?

Hi,

Be goode,

Diego,

Linda

Hi Linda,

Be goode,

Any suggestions?

Linda

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: John Strassner <[email-masked]>
Date: Tue, 21 Jun 2016 09:52:11 -0700

+1

This is a great suggestion Diego.

I think having "client" in the northbound and southbound, while correct, is
ambiguous. This focuses on the primary actors (applications for northbound
and controllers for southbound).

In addition, I strongly support incorporating the notion of a security
domain.

best regards,
John

On Tue, Jun 21, 2016 at 5:28 AM, DIEGO LOPEZ GARCIA <
[email-masked]> wrote:

> * I2NSF applications, sending inquiry/request for Flow Security Policy to
> a controller (which controls a security domain)
>
> * I2NSF controllers, that collect and expose NSF capabilities, and send
> Flow Security Policy to individual NSFs within a security domain
>
> On 21 Jun 2016, at 14:02 , Linda Dunbar <[email-masked]> wrote:
>
> Diego,
>
> Do you mean that we should abandon the general “I2NSF Client” term,
> instead having the following two separate definitions?
>
> *Controller Client*: I2NSF applications that send inquiry/request for
> Flow Security Policy to a controller (who controls a network). For example:
> an overlay network controller sending inquiry/request for Flow Security
> Policy to an underlay network controller
>
> *NSF Client*: I2NSF controllers that send Flow Security Policy to
> individual NSFs
>
> Linda
>
> *From:* DIEGO LOPEZ GARCIA [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Monday, June 20, 2016 4:46 AM
> *To:* Linda Dunbar
> *Cc:* John Strassner; Xialiang (Frank); Susan Hares; [email-masked]
> *Subject:* Re: [I2nsf] I2NSF Terminology draft : Is it better to have two
> distinct terminologies to differentiate the “Client to controller” from the
> “Client to NSFs”?
>
> Hi Linda,
>
> The obvious suggestion that comes to my mind is to use the SDN analogy,
> and call the clients of type 1 “I2NSF applications” and those of type 2
> “I2NSF controllers”
>
> Be goode,
>
>
> On 18 Jun 2016, at 23:08 , Linda Dunbar <[email-masked]> wrote:
>
> 1.      One type of client sending inquiry/request for Flow Security
> Policy to a controller (who controls a network). For example: an overlay
> network controller sending inquiry/request for Flow Security Policy to an
> underlay network controller.
> Simply put, the client described in 1) is making request to the (I2NSF)
> Controller (i.e. the controller’s North Bound Interface); and the “client”
> described in 2) is making request to the NSFs ( i.e. the controller’s South
> Bound Interface).
>
> It seems to me that the “I2NSF Client” described in the current I2NSF
> Terminology draft is performing the “controller” function, and the “I2NSF
> Agent” is residing in the NSF for receiving the flow security policies from
> the “Controller”.
>
>
> Is it better to have two distinct terminologies to differentiate the
> “Client to controller” from the “Client to NSFs”?
>
> Any suggestions?
>
> Linda
>
> [email-masked]
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
>
> --
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 21 Jun 2016 09:54:02 -0700

I'll take a first stab and send to the other terminology authors. I have a
number of other refinements that I've been gathering. Then, when the
authors agree, we'll post an update to the list for IETF96.

best regards,
John

On Tue, Jun 21, 2016 at 5:34 AM, Linda Dunbar <[email-masked]>
wrote:

> *From:* DIEGO LOPEZ GARCIA [mailto:[email-masked]]
> *Sent:* Tuesday, June 21, 2016 7:28 AM
> *To:* Linda Dunbar

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 29 Jun 2016 20:27:34 -0700

I personally think that it is better to not use the term "client", since it
is describing two different interactions. I find that confusing, and I am
still bothered by the implication that this is a client-server (or even an
n-tier) architecture. I would like the freedom to build a distributed
implementation without those constraints.

best regards,
John

-- 
regards,
John