Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

From: Tina TSOU <[email-masked]>
Date: Sun, 28 Sep 2014 04:30:03 +0000

Dear Luis, Andrew et al,

Thank you for writing such a concrete model.

I read draft-contreras-supa-yang-network-topo-00<http://datatracker.ietf.org/doc/draft-contreras-supa-yang-network-topo/>. It is well written. Below are some comments.

The basic idea of this draft is very good, and I can understand what the author tries to say. However still, more clarification is needed especially for some definitions.

1.         In section 4.2, there are "virtual node" and "container node", what is difference between these two kinds of nodes? For the virtual node, it is more understandable that it is the virtualization of the physical node or nodes. But for the container node, it can be a group of nodes or only one node. What is the necessity to define such a container node, is it domain specific or a general idea for all the use cases?

2.         Would you elaborate one use case for the container node? In order to demonstrate the insufficiency of virtual node to cover the application or use cases, show one use case that the container node idea is necessary.

3.      In section 4.2, there is also some external links or nodes definition, what is the purpose for that? Are they external for the user or the up level controller?

4.       In first figure of section 4
                  +-------------------------+
                  |                         |
                  |       topology          |
                  |                         |
                  +-+-+----+---------+--+-+-+
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
                    | |    |         |  | |
      +------------+ |    |         |  | |
       |              |    |         |  | +------------------+
       |        +-----+    |         |  +--------+           |
       |        |          |         +-+         |           |
       |        |          |           |         |           |
    +--+---+ +--+---+ +----+------++---+---+ +---+---+ +-----+-----+
    |link  | |node  | |termination||extLink| |extNode| |extTerminat|
    +------+ +------+ |Point      |+-------+ +-------+ |ionPoint   |
                      +-----------+                    +-----------+

How can the unified topology be mapped into different applications or users? I guess you need to map this topology, if this is the only one topology, to different applications in order to make it work.

Thank you,
Tina

---

From: Tina TSOU <[email-masked]>
Date: Mon, 29 Sep 2014 03:38:53 +0000

Dear Martin,

We discussed off-line how the supa topology draft is related to the i2rs topology draft, I feel it is worthy to bring it to the list for broader audience.

This draft http://datatracker.ietf.org/doc/draft-hares-i2rs-info-model-service-topo/ also focused on network topology information model which is also within the scope of SUPA topology model. However, besides the common interests at topology model, there are still significant differences between the two.

1.       The I2RS topology model is based on a service topology which is closely related to certain service. And the service topology can be dedicated to one tenant or multiple tenants. For SUPA, different layers have different views or representations of the same network topology. Multiple users may not "share" the same topology but use their own topology at their own layer.

2.       The I2RS topology model use service topologies which should be independent from network topology and therefore should not map onto other underlay topologies. The SUPA topology model is a unified topology model to support service at all levels. Each level can have its own representation of the topology.

3.     There is no YANG based topology model in this I2RS draft yet. SUPA has a well defined YANG data model to describe the topology.

All in all, the two drafts have something in common and the basic principals are very close. IMO, service topology can be one use case for SUPA topology model to be used in BGP, OSPF and so on.

Thank you,
Tina

From: Supa [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Sunday, September 28, 2014 12:30 PM
To: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]
Cc: [email-masked]
Subject: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

Dear Luis, Andrew et al,

Thank you,
Tina

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 30 Sep 2014 23:01:29 +0000

Hi Tina,

Thanks for your comments. Please, see my answers in-line.

De: Supa [mailto:[email-masked]] En nombre de Tina TSOU
Enviado el: domingo, 28 de septiembre de 2014 6:30
Para: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]
CC: [email-masked]
Asunto: [Supa] Comments on draft-contreras-supa-yang-network-topo-00

Dear Luis, Andrew et al,

1.         In section 4.2, there are “virtual node” and “container node”, what is difference between these two kinds of nodes? For the virtual node, it is more understandable that it is the virtualization of the physical node or nodes. But for the container node, it can be a group of nodes or only one node. What is the necessity to define such a container node, is it domain specific or a general idea for all the use cases?
[Luis>>] As you point out a virtual node can represent an slice of a physical node. On the other hand, the container node represents a grouping of several other nodes that can be observed as a one consolidated node from a topology perspective. I would say that it is a general idea that can be applicable to some use case.

2.         Would you elaborate one use case for the container node? In order to demonstrate the insufficiency of virtual node to cover the application or use cases, show one use case that the container node idea is necessary.
[Luis>>] From my understanding the idea of a container node can be useful for representing some scenarios. I have mentioned in some previous mail an example of a rented infrastructure let’s say for mobile backhaul. The service provider which rents the infrastructure will handle a detailed topology of the physical infrastructure but it could expose a simplified topology to the service provider which is renting such capacity. Other example could be for instance the internals of a data center. You could consider for example all the DC environment as a container node connecting a virtual machine to a border router, hiding the complexity of the internal topology of the DC, that could not be required to be known from the service perspective for that VM. Let me know if these examples make sense to you.

[Luis>>] The external links or nodes represent objects connected to the topology but not controlled by the controller. They are required to provide consistent definition to some topologies (I’m thinking for instance in VPNs). Probably the text has to be refined for a better explanation of that.

[Luis>>] Not sure if I understand correctly the question. The topology will have different views according to the users or applications. Each view should provide the elements needed for comprehensively representing the service for each user or application. Nor sure if this answers the question. Please, let me know if not.
Thank you,
Tina

________________________________

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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Oct 2014 08:05:11 +0200

> [Luis>>] The external links or nodes represent objects connected to the topology but not controlled by the controller. They are required to provide consistent definition to some topologies (I’m thi…

This approach may not be very suitable if there are multiple
controller since then you have to maintain N different topology
models. It may be more scalable to have one topology and instead tag
nodes and links as needed (if exposure of controller domains is needed
at all).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>