Subject: [Supa] RV: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 18 Sep 2014 07:54:06 +0000

Dear colleagues,

Please note a new draft document addressing YANG modelling of network topology has been just uploaded. Any comment is more than welcome.

Thanks

Best regards

Luis

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

A new version of I-D, draft-contreras-supa-yang-network-topo-00.txt
has been successfully submitted by Luis M. Contreras and posted to the IETF repository.

Name:           draft-contreras-supa-yang-network-topo
Revision:       00
Title:          A YANG Data Model for Network Topologies
Document date:  2014-09-18
Group:          Individual Submission
Pages:          23
URL:            http://www.ietf.org/internet-drafts/draft-contreras-supa-yang-network-topo-00.txt
Status:         https://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/
Htmlized:       http://tools.ietf.org/html/draft-contreras-supa-yang-network-topo-00

Abstract:
   This document defines a YANG data model for network topologies.

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

________________________________

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: JF Tremblay <[email-masked]>
Date: Thu, 18 Sep 2014 16:23:35 -0400

Luis, 
Thanks to you and Andrew for writing this. Very interesting and quite in line with the conception of a multi-layer topology model I was myself trying to express.

A few questions: 
You limited the scope of the topology information to layer-3 and beneath. Was it because you don’t believe such a topology could be applicable at higher levels? 
In my mind, such a generic topology model could apply to higher layers. For example, a host-server relationship could be a very basic topology with a link between two nodes. It would allow later on to define policies or parameters on such a session/link.  
  
Another point: I do like the idea of hierarchizing the topologies, but I’m not sure I understand it the way you described it. Reading the document, it seemed at first that a parent topology would be a lower-abstraction (lower-level) topology object. Topologies of different levels would be linked through a parent-children relationship. But then the text mentions “The parent topology has a container node that maps a sub topology.”, it sounds like you’re defining a topology embedded in a topology of the same layer. Do I get this right? Both concepts are interesting, maybe a way could be found to differentiate them in the text. The second one sounds more like a container-contained relationship rather than parent-children. 

Also, could a topology be a parent to more than one higher-level topology? I guess it does, but I haven’t seen it clearly mentioned in the text. An example would be a single physical topology with several different logical topologies on top of it. 

Btw, you might want to take a look at http://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not exactly the same concepts, but it describes interesting ideas too. 

JF Tremblay 
Viagenie

On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:

> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Sat, 20 Sep 2014 11:08:17 +0000

Hi JF,

I read this draft and have some comments to yours. Please see below in-line.

Regards,
Will

From: Supa [mailto:[email-masked]] On Behalf Of JF Tremblay
Sent: Friday, September 19, 2014 4:24 AM
To: LUIS MIGUEL CONTRERAS MURILLO
Cc: [email-masked]; [email-masked]
Subject: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Luis,

A few questions:
You limited the scope of the topology information to layer-3 and beneath. Was it because you don't believe such a topology could be applicable at higher levels?
In my mind, such a generic topology model could apply to higher layers. For example, a host-server relationship could be a very basic topology with a link between two nodes. It would allow later on to define policies or parameters on such a session/link.

[Will] I agree with JF that we should not limit the scope of topology. Actually, I think in the draft they did not limit the scope as I see words like, "physical, data link and IP and can be extended to   layer 4,5 and 7", "The model is also capable of depicting the  topology at different layers", "A network at any layer can contain multiple topologies. Each  topology is captured in its own list elements, distinguished via a  topology ID." However, I guess you have such an impression because in section 4, when they give the detailed examples, they only write about l0-l3.

IMHO, the advanced network functions (besides the basic routing and forwarding functions) for added value services are mostly Layer4 to Layer7 based. The Layer 4-7 network service function may include (not limited) firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, NAT,TCP optimizer, etc. Some of them are designed and deployed to enhance user experience, such as TCP or video optimization, content catching and compression, while others apply actions to data packets, such as Firewall, Policing (e.g. PCEF/PCRF), Mirroring, statistics collection based on Layer 4-7 headers, etc. If an application need to control multiple service functions in network, it may need a topology for Layer 4-7 service function nodes and connections (For example, a traffic steering application may need to know the L4-L7 topology first. So it can tell network (including network service function nodes) how to steer a traffic).

So, I propose to add following words in the end of page 4, below the sentence "ip means layer 3 topology ...":
"TCP/UDP or other Layer 4-7 information" means layer 4-7 topology that switch packets by Layer 4-7 information in packet or packet header."

I also  propose to add description like below(please note that they are just examples and may need to be modified) into "module SUPA-topology":
enum ip {
               value 4;
               description "L4";
             }
             enum ip {
               value 5;
               description "L5";
             }
             enum ip {
               value 6;
               description "L6";
             }
             enum ip {
               value 7;
               description "L7";
             }

Another point: I do like the idea of hierarchizing the topologies, but I'm not sure I understand it the way you described it. Reading the document, it seemed at first that a parent topology would be a lower-abstraction (lower-level) topology object. Topologies of different levels would be linked through a parent-children relationship. But then the text mentions "The parent topology has a container node that maps a sub topology.", it sounds like you're defining a topology embedded in a topology of the same layer. Do I get this right? Both concepts are interesting, maybe a way could be found to differentiate them in the text. The second one sounds more like a container-contained relationship rather than parent-children.

Also, could a topology be a parent to more than one higher-level topology? I guess it does, but I haven't seen it clearly mentioned in the text. An example would be a single physical topology with several different logical topologies on top of it.

JF Tremblay
Viagenie

On Sep 18, 2014, at 3:54 AM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:

Dear colleagues,

Thanks

Best regards

Luis

-----Mensaje original-----
De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Abstract:

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

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
_______________________________________________
Supa mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/supa

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 30 Sep 2014 22:16:41 +0000

Hi JF

Sorry for jumping so late on this. These are very busy weeks for me. Please, see my comments in line.

De: JF Tremblay [mailto:[email-masked]]
Enviado el: jueves, 18 de septiembre de 2014 22:24
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]
Asunto: Re: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Luis,

A few questions:
You limited the scope of the topology information to layer-3 and beneath. Was it because you don't believe such a topology could be applicable at higher levels?
In my mind, such a generic topology model could apply to higher layers. For example, a host-server relationship could be a very basic topology with a link between two nodes. It would allow later on to define policies or parameters on such a session/link.
[Luis>>] Agree, This hierarchy can be extended to higher layers than L3, with the appropriate dependencies with respect to the underlying topologies describing lower layers.

Another point: I do like the idea of hierarchizing the topologies, but I'm not sure I understand it the way you described it. Reading the document, it seemed at first that a parent topology would be a lower-abstraction (lower-level) topology object. Topologies of different levels would be linked through a parent-children relationship. But then the text mentions "The parent topology has a container node that maps a sub topology.", it sounds like you're defining a topology embedded in a topology of the same layer. Do I get this right? Both concepts are interesting, maybe a way could be found to differentiate them in the text. The second one sounds more like a container-contained relationship rather than parent-children.
[Luis>>] In my opinion it can be used for both approaches. From my point of view a clear parent-child relationship could be the one e.g. observed between an IP topology and a transmission (let say a photonic mesh) topology. On the other hand, it can be used as well for a "Russian doll" approach. An example of that could be for instance the case in which an operator offers transport capabilities to other service provider in one are, like in some mobile backhaul scenarios. The infrastructure operator will clearly observed the physical topology while offering a condensed (or contained) topology to the service provider which is renting that capacity. Let me know if it makes sense to you.

Also, could a topology be a parent to more than one higher-level topology? I guess it does, but I haven't seen it clearly mentioned in the text. An example would be a single physical topology with several different logical topologies on top of it.
[Luis>>] I think so. The example mentioned above for the rented capacity in the mobile backhaul could be a case, assuming more than one operator rents capacity to the same infrastructure provider. Other cases could be for instance the deployment of different VPNs on the same transport infrastructure..

Btw, you might want to take a look at http://tools.ietf.org/html/draft-edprop-opsawg-multi-layer-oam-ps-00. It describes a multi-layer OAM model. Not exactly the same concepts, but it describes interesting ideas too.
[Luis>>] Thanks for the pointer. I didn't have an opportunity yetto read this work, but I commit to do and come back to this thread if any comment raise to me.

JF Tremblay
Viagenie

[Luis>>] Thank you, and sorry for the delay in answering. Best regards. Luis.

Dear colleagues,

Thanks

Best regards

Luis

-----Mensaje original-----
De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Abstract:

The IETF Secretariat

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 30 Sep 2014 22:17:38 +0000

Hi Will,

Thanks for your comment. I basically agree. Noted for the next version of the draft.

Regards,

Luis

De: Liushucheng (Will) [mailto:[email-masked]]
Enviado el: sábado, 20 de septiembre de 2014 13:08
Para: JF Tremblay; LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]; [email-masked]
Asunto: RE: [Supa] New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Hi JF,

Regards,
Will

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Luis,

A few questions:

JF Tremblay
Viagenie

Dear colleagues,

Thanks

Best regards

Luis

-----Mensaje original-----
De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Enviado el: jueves, 18 de septiembre de 2014 9:48
Para: LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu; LUIS MIGUEL CONTRERAS MURILLO; Andrew Qu
Asunto: New Version Notification for draft-contreras-supa-yang-network-topo-00.txt

Abstract:

The IETF Secretariat