[Ibnemo] 答复: 答复: How to group/reuse definitions

["zhangyali (D)" <[e-mail]>]

Hi Pedro,



Thanks for your examples to explain the construction rule of recursion function/template. Answers in line.



Best Regards,

Yali



-----邮件原件-----

发件人: PEDRO ANDRES ARANDA GUTIERREZ [mailto:[e-mail]]

发送时间: 2015年11月13日 16:12

收件人: zhangyali (D); Zhoutianran; Bert Wijnen (IETF); [e-mail]

主题: Re: 答复: [Ibnemo] How to group/reuse definitions



Hi Yali,



Recursion is indeed critical for the vDC use case I’m pursuing from the very beginning.



Answers inline,

BR,/PA

---

Dr. Pedro A. Aranda Gutiérrez



Technology Exploration -

Network Innovation & Virtualisation

email: pedroa d0t aranda At telefonica d0t com Telefónica, Investigación y Desarrollo C/ Zurbarán,12

28010 Madrid, Spain



Fragen sind nicht da, um beantwortet zu werden.

Fragen sind da, um gestellt zu werden.

Georg Kreisler











-----Mensaje original-----

De: "zhangyali (D)" <[e-mail]>

Fecha: viernes, 13 de noviembre de 2015, 8:48

Para: paag <[e-mail]>, Zhoutianran <[e-mail]>, "Bert Wijnen (IETF)" <[e-mail]>, "[e-mail]" <[e-mail]>

Asunto: 答复: [Ibnemo] How to group/reuse definitions



>Hi Pedro,

>

>Thanks for your reflections about recursion in NEMO, and I think it's an important feature will be implemented in the next stage.

>

>As you have said, operators may reuse the services zone many times, we need a simple solution to satisfy this requirement. Learning from the traditional programming language, just as, C, C++, function seems a perfect solution to solve recursion problem.

>

>Take DMZ as an example:

>

>NodeModel DMZ(x,y,z,I,j):

>       Node n1 Type fw Property x;

>       Node n2 Type nat Property y;

>       Node n3 Type host Property z;

>       Connection c1 Type p2p Endnodes n1,n2 Property I;

>       Connection c2 Type p2p Endnodes n2,n3 Property j;



This may be an overkill. Especially in the case of the connections. Remember that these have a logical meaning rather than a physical implementation. So, in most cases, they will have no properties and will not be connections as such.



So I think that



NodeModel FW

        Property IPPrefix: exterior, IPPrefix: interior;



NodeModel L2Switch

        Property integer: ports;



NodeModel DMZ

        Node fw1 Type FW

        Node l2sw1 Type L2Switch

        Connect fw1.interior, l2sw1.ports.0;



Create Node dmz1 Type DMZ

        Property fw1.exterior: 10.0.0.1/32, fw1.interior: 10.0.1.0/28, l2sw1.ports:4;



[Yali] Our expressions of new DMZ are similar, except you omit parameter lists. And firewall and l2-group(L2Switch in your expression, I think) are predefined node types, so I omit them.

    A key point/difference is how to express the connection/connectivity between the two nodes. I think resource is a essential element to allow the communication between nodes no matter where it is, that is, if there is not "real" connection between nodes, they will not be connected.

    And what if user wants to assign a bandwidth in this connection? So I am not sure if the "Connect" includes enough information.



should suffice. I would rather explicitly leave the ConnectionModel and ‘Create Connection’ for connections between sites. With my proposal, we hide the logical relationship between the components of a building block from the end user _and_ we allow to include ‘real’ connections in higher levels of recursion. An example:



Imagine I define a NodeModel for an ExteriorZone and I create a link model for a WAN connection between 2 Exterior Zones



I could create a node model for an Enterprise with two sites like



ModeModel Enterprise

        Node office1 Type ExteriorZone

        Node office2 Type ExteriorZone

        Connection wan Type WAN EndNodes office1, office2;



[Yali] Another perfect example to use Template/function.

         So I think the key point is that the meaning of connection and how to use it. Look forwarding to your opinion.

>

>With this expression, we create a new node type named DMZ, and its properties can be adjusted according to users' requirement. It can be called whenever you want to create a DMZ node, just like a function in C. For example:

>

>CREATE Node dmz1 Type DMZ(property(dmz1-n1), property(dmz1-n2),

>property(dmz1-n3), property(dmz1-c1), property(dmz1-c2)); CREATE Node

>dmz2 Type DMZ(property(dmz2-n1), property(dmz2-n2), property(dmz2-n3), property(dmz2-c1), property(dmz2-c2)); ...

>

>In this way, users could create many DMZ zones with very refined scripts, and we don't need to express internal details again and again.

>

>Do you think this way is a good solution to the recursion problem, and could work in many use cases? Looking forward to your suggestions.

>

>Best Regards,

>Yali

>-----邮件原件-----

>发件人: Ibnemo [mailto:[e-mail]] 代表 PEDRO ANDRES ARANDA

>GUTIERREZ

>发送时间: 2015年11月10日 14:49

>收件人: Zhoutianran; Bert Wijnen (IETF); [e-mail]

>主题: Re: [Ibnemo] How to group/reuse definitions

>

>Hi,

>

>Answers inline… line of thought:

>1. Recursion needs to be supported in a generalised way 2. there are

>use cases where connectivity matters

>

>

>BR,/PA

>---

>Dr. Pedro A. Aranda Gutiérrez

>

>Technology Exploration -

>Network Innovation & Virtualisation

>email: pedroa d0t aranda At telefonica d0t com Telefónica,

>Investigación y Desarrollo C/ Zurbarán,12

>28010 Madrid, Spain

>

>Fragen sind nicht da, um beantwortet zu werden.

>Fragen sind da, um gestellt zu werden.

>Georg Kreisler

>

>

>

>

>

>

>

>

>

>-----Mensaje original-----

>De: Ibnemo <[e-mail]> en nombre de Zhoutianran

><[e-mail]>

>Fecha: lunes, 9 de noviembre de 2015, 8:46

>Para: "Bert Wijnen (IETF)" <[e-mail]>, "[e-mail]"

><[e-mail]>

>Asunto: Re: [Ibnemo] How to group/reuse definitions

>

>>It's really useful to group a set of atomic components and provide the whole as a micro/template, just like the DMZ example. The hierarchy enables the reusability.

>

>OK with that from the very beginning of all this discussion

>

>>To describe a DMZ, I can see two ways.

>>1. One is to describe the exact connectivity among those atomic components.

>

>>

>We need that as we climb in the hierarchy.

>

>>I think the switch and router are what we want to eliminate. It seems too detail with the intent concept. I hope they can be auto generated by the intent engine.

>

>It may seem too detailed if you are looking at routers, switches, etc. But once you have building blocks like DMZ, interior, exterior, etc. then suddenly you start needing expressing the connectivity. In our use case, how else would you be expressing that you have an exterior zone connected to the Internet and two DMZs, one of which serves 3 interior zones while the other serves just one interior zone. I know, I have been using _simple_ examples up until now, but believe me, things can get pretty complex out there.

>

>>2. The other way I would prefer is to define DMZ as a layer 2 group, in which by default all the components are connected by a logic switch(which do not need to explicitly describe again). Or we can define DMZ as a layer 3 group with a  router. In this way, we can put any number of components in easily with fully flexibility.

>

>Again, that depends a lot on the use case. I think the ‘connectivity paradigm’ may be helpful for people doing networking. Saying that I have a connection between two elements may have a different implementation depending on the elements and their location. However, the logical interpretation of the connection (i.e. its intent) is always going to be that packets treated by one block should be sent to another.

>

>>That's my 2 cents.

>>

>>Best,

>>Tianran

>>

>>> -----Original Message-----

>>> From: Ibnemo [mailto:[e-mail]] On Behalf Of Bert

>>> Wijnen

>>> (IETF)

>>> Sent: Thursday, November 05, 2015 5:41 PM

>>> To: [e-mail]

>>> Subject: [Ibnemo] How to group/reuse definitions

>>>

>>> During the IETF94 Hackaton, we got some discussion on how much

>>> detail we want to allow or need in the Intent Language when reusing

>>> definitions. For example, let us assume that you

>>>

>>> - define a router

>>> - define a firewall

>>> - define a loadbalancer

>>> - define a l2 switch

>>> - etc

>>>

>>> And that later on you want to define something like a DMZ and inside

>>> that DMZ you want to use the defined router, firewall, l2 switch, etc.

>>>

>>> The end-user/customer would want to just express his/her intent to

>>> have an internet connection with a DMZ I guess.

>>>

>>> The network administrator of the ISP (operator) needs to then

>>> express that the DMZ consists of let us say a router, a firewall, a l2switch etc.

>>> Do we want/need the network administrator to have to (or to be able

>>> to) specify the details on how these nodes get connected? Or would

>>> we rather see that the Intent Engine generates the proper connections?

>>>

>>> I suggest that those who have proto-type implementations express

>>> their approach and that network operators express their wants/needs

>>> for such a scenario.

>>>

>>> Bert

>>>

>>> _______________________________________________

>>> Ibnemo mailing list

>>> [e-mail]

>>> https://www.ietf.org/mailman/listinfo/ibnemo

>>

>>_______________________________________________

>>Ibnemo mailing list

>>[e-mail]

>>https://www.ietf.org/mailman/listinfo/ibnemo

>

>________________________________

>

>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

>_______________________________________________

>Ibnemo mailing list

>[e-mail]

>https://www.ietf.org/mailman/listinfo/ibnemo



________________________________



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