Subject: Re: [Supa] Network Topology Data Model and Network Configration Data Model

From: "Wunan (Eric)" <[email-masked]>
Date: Tue, 11 Nov 2014 20:04:33 +0000

Hi Juergen,

Please check my reply in line.

In the IP world, we usually talk about nodes, links, and interfaces.
And interfaces have been generalized to cover multiple layers. Is
there a specific reason why you prefer the term 'TerminationPoint'?
How is a 'TerminationPoint' different from an interface (and what
is the relationship between them)?

[Eric]: As the draft said, network topology DM is supposed to be defined in a hierachy manner.

When "IP world" is the concern, we are acutally talking about the topology DM for IP.

You are right that people are more familar with "interface", I am.

Actually in the IP Topology DM, "TerminationPoint" is interface.

Per my understanding, this word may be prefered because network topology is not only focusing on IP.

As you know some protocols don't have to depend on "interface", they got their own vacabulary.

For example, IS-IS was using "circuit" and VLAN got "port".

When speaking "interface", i feel it will be more proper when CLI is used.

What is the difference of this topology data model from other
proposals on the table, such as draft-clemm-i2rs-yang-network-topo-01
and draft-hares-i2rs-info-model-service-topo-01 (there there might
be more)?

[Eric]: I would say both of them are talking about topology data model.

One difference may be the position they are used in the architecture.

For draft-hares-i2rs-info-model-service-topo-01,

I think it is the topology for service, another layer in the hierarchy.

If topology data models are crucial for 'northbound' applications, why
is lets say draft-zaalouk-supa-configuration-model-01 not using a
topology data model but instead coming up with its own notion of
interfaces and node identifiers?

[Eric]: I agree with you. Authors may need to coordinate on that.

Regards

Eric

  *   From: Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de<mailto:[email-masked]>>
  *   To: Tina TSOU <Tina.Tsou.Zouting at huawei.com<mailto:[email-masked]>>
  *   Cc: "supa at ietf.org<mailto:[email-masked]>" <supa at ietf.org<mailto:[email-masked]>>
  *   Date: Tue, 11 Nov 2014 10:17:05 +0100
  *   In-reply-to: <[email-masked]<http://www.ietf.org/mail-archive/web/supa/current/msg00181.html>>
  *   References: <[email-masked]<http://www.ietf.org/mail-archive/web/supa/current/msg00181.html>>
  *   List-id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." <supa.ietf.org>

________________________________

On Tue, Nov 11, 2014 at 08:43:57AM +0000, Tina TSOU wrote:
> Dear all,
>
> As time not allowed, these are the slides for agenda item: Network Topology Data Model and Network Configration Data Model, which I received.
>

In the IP world, we usually talk about nodes, links, and interfaces.
And interfaces have been generalized to cover multiple layers. Is
there a specific reason why you prefer the term 'TerminationPoint'?
How is a 'TerminationPoint' different from an interface (and what
is the relationship between them)?

What is the difference of this topology data model from other
proposals on the table, such as draft-clemm-i2rs-yang-network-topo-01
and draft-hares-i2rs-info-model-service-topo-01 (there there might
be more)?

If topology data models are crucial for 'northbound' applications, why
is lets say draft-zaalouk-supa-configuration-model-01 not using a
topology data model but instead coming up with its own notion of
interfaces and node identifiers?

/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/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Nov 2014 21:15:13 +0100

> When speaking "interface", i feel it will be more proper when CLI is used.

A VLAN port is just another interface. See the IF-MIB or the
ietf-interfaces YANG model or the IANA interface registry. If a
TerminationPoint is just a different name for 'interface', then I
clearly prefer to stick to terms we are all familiar with.
 
> I think it is the topology for service, another layer in the hierarchy.

I was hoping for a more technical answer. Why do we need N topology
data models? If I look at the YANG snippets, I do not see what makes
them specific to a 'position in the architecture'.

/js

---

From: "Wunan (Eric)" <[email-masked]>
Date: Tue, 11 Nov 2014 21:21:01 +0000

Hi Juergen,

Reply in line.

Regards
Eric

________________________________________
发件人: Juergen Schoenwaelder [[email-masked]]
发送时间: 2014年11月12日 4:15
收件人: Wunan (Eric)
抄送: [email-masked]; Tina TSOU
主题: Re: [Supa] Network Topology Data Model and Network Configration Data Model

[Eric]: I think VLAN port's definition use IF-MIB's defined type, but port is not the interface directly in VLAN MIB.

I think this is what you are talking about:

   Dot1dBasePortEntry ::=
       SEQUENCE {
           dot1dBasePort
               Integer32,
           dot1dBasePortIfIndex
               InterfaceIndex,                               -----------------interface
           dot1dBasePortCircuit
               OBJECT IDENTIFIER,
           dot1dBasePortDelayExceededDiscards
               Counter32,
           dot1dBasePortMtuExceededDiscards
               Counter32
       }

[Eric]: Of course it is not because the "position" only. Actually not at all.

For the I2RS model you mentioned, i think it mainly focus on the IP/IGP topology.

While the conception i got from the draft-contreras-supa-yang-network-topo-01,

it tried to define one hierarchy for topology.

Plus it contains some extXXX definition in the model, which don't catched in I2RS topo.

I think it may have some consideration behind this. Maybe the authors can talk more about this.

Based on that currently I won't suggest to reuse I2RS YANG model directly in the SUPA scenario.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 11 Nov 2014 22:37:53 +0100

> Eric

This proves my point. A bridge port maps to an interface since an
interface is the generic way to refer to an an 'endpoint' of a 'link'.

So again, what is the difference between a TerminationPoint and an
interface?

> Based on that currently I won't suggest to reuse I2RS YANG model directly in the SUPA scenario.

Hm. I am still puzzled. I do not know what extlinks are since there
are only empty description clauses. It is not clear why this is not
just a property of a link or why it is a good idea to replicate lots
leafs. While there are differences (no wonder) in the YANG fragments,
I like to know more precisely why topology model A is limited to layer
B and why model C is limited to layer D and why model E is 'more'
generic than model A or B.

/js

---

From: "Wunan (Eric)" <[email-masked]>
Date: Thu, 13 Nov 2014 11:25:32 +0000

Jurgen,

Please see my words in line.

Regards

Eric

________________________________________
发件人: Juergen Schoenwaelder [[email-masked]]
发送时间: 2014年11月12日 5:37
收件人: Wunan (Eric)
抄送: [email-masked]; [email-masked]; Tina TSOU
主题: Re: [Supa] Network Topology Data Model and Network Configration Data Model

[Eric] Per my understanding, the meaning "TerminationPoint" wants to convey is the endpoint of a link.

When generic way speaking, I don't think there is much essential difference between generic TerminationPoint and generic interface.

But I doubt all the people are used to accept "interface" as a generic concept in topology model.

For example, when transmission network(say optical) is concerned, people are used to use the word "port" other than interface.

I think the terminology "TerminationPoint" is kind of abstraction and used to avoid confusion among people from different areas.

Plus, the I2RS draft(draft-clemm-i2rs-yang-network-topo-01) also use the same terminology.

[Eric] The definition from the draft:

"External objects such as extNode, extLink and extTerminationPoint of
   a topology are objects not controlled by the controller which manage
   the topology. For example, a link is an internal link between nodes
   in the network managed by a SDN controller. An external link connects
   a node in the network managed by a SDN controller to a node in the
   network managed by the other SDN controller. A link is a connection
   line in a topology. An external link is a connection line between two
   different topologies."

i.e. topology A's extNodes are nodes outside topo A and directly connected to topo A, and extNodes are not duplicate with internal nodes.

There might be different properties/operation for external nodes and internal nodes, so it is better to have independent object.

And in my opinion, draft-contreras-supa has better abstration for topology. Besides node/link, the key for topology is that it has boundaries, with must be clearly stated in the topologies. And draft-contreras-supa has explicit layer definition, since topology is usually layered.

Good abstraction is to have the key characteristics of an object, and should have just necessary information for your purpose, which does not mean missing key definition characteristics like boundary and layer.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 12:52:14 +0100

> Plus, the I2RS draft(draft-clemm-i2rs-yang-network-topo-01) also use the same terminology.

Yes, different people use different terms. That said, in the IETF we
do have a clear understanding what interfaces are. If TerminationPoints
really are interfaces, I prefer to be consistent with this terminology.
If they are something different, this needs to be clearly defined and
the relationship to interfaces must be clear.

> Good abstraction is to have the key characteristics of an object, and should have just necessary information for your purpose, which does not mean missing key definition characteristics like bounda…

I remain unconvinced that me need N different topology models.

/js

---

From: Andrew Qu <[email-masked]>
Date: Thu, 13 Nov 2014 21:01:33 +0000

Hi Juergen,

Trying understand,  when you said "N different model",  did you mean
I2RS, SUPA, etc ?

Thanks,

Andrew

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, November 13, 2014 3:52 AM
To: Wunan (Eric)
Cc: Andrew Qu; [email-masked]; Tina TSOU
Subject: Re: [Supa] Network Topology Data Model and Network Configration Data Model

> Plus, the I2RS draft(draft-clemm-i2rs-yang-network-topo-01) also use the same terminology.

Yes, different people use different terms. That said, in the IETF we do have a clear understanding what interfaces are. If TerminationPoints really are interfaces, I prefer to be consistent with this terminology.
If they are something different, this needs to be clearly defined and the relationship to interfaces must be clear.

/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/>
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any 
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be 
conveyed only to the designated recipient(s). Any use, dissemination, 
distribution, printing, retaining or copying of this e-mail (including its 
attachments) by unintended recipient(s) is strictly prohibited and may 
be unlawful. If you are not an intended recipient of this e-mail, or believe 
that you have received this e-mail in error, please notify the sender 
immediately (by replying to this e-mail), delete any and all copies of 
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 22:14:16 +0100

Yes,

I believe that the IETF should define _1_ core topology data model and
the IESG members of the areas where this is relevant should find out
where to do this work.

/js

On Thu, Nov 13, 2014 at 09:01:33PM +0000, Andrew Qu wrote:
> _______________________________________________
> Supa mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/supa

---

From: JF Tremblay <[email-masked]>
Date: Thu, 13 Nov 2014 11:32:27 -1000

> On Nov 13, 2014, at 1:52 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

After reading draft-contreras-supa-yang-network-topo-01 once again, a few points bother me, two of them mentioned by Juergen already: 
- The use of "termination point” objects in the model
- The “ext” objects in the model

I tried to backtrack the source of these concepts and the oldest reference I found is this one: 
https://tools.ietf.org/html/draft-medved-i2rs-topology-im-01 <https://tools.ietf.org/html/draft-medved-i2rs-topology-im-01>
The first version of this document is from July 2013, which predates most of the other documents discussed here so far. 

On “termination points”: 
In the medved document above, termination points are describe in 4.1 as follow: 
   A topology contains nodes and links.  Each node in turn contains
   termination points.  A link connects two nodes (a source and a
   destination), terminating on each at a termination point.

It’s still not clear to me what Termination Points refer to in the information model and how they are useful. This terminology seems to come from a circuit-oriented world and I don’t understand how it applies here. 

Is this useful in the context of a tunnel or a MPLS VPN for example? How? The examples I’ve found by googling seem to describe the termination points as the ends of a circuit, as virtual endpoints on a node. They would fit with the definition of a virtual tunnel interface, for example.  

Bottom line: I’m not convinced termination points are useful for describing topology, but I’m just asking to be convinced. 

On “ext” objects: 
Draft medved-i2rs-toplogy describes the “ext” objects as containing protocol-specific extension relating to links, nodes and termination points in section 4.1: 
      The topology, node, link and termination-point elements can be
      extended with topology-specific components (topology-extensions,
      node-extension, link-extension and termination-point-extension
      respectively).  This document defines extensions for the L3
      unicast topology.

Draft-contreras-supa-yang-network-topo seems to define the ext objects as being the same objects, but outside of the control domain (section 4.4): 
   External objects such as extNode, extLink and extTerminationPoint of
   a topology are objects not controlled by the controller which manage
   the topology. 

This definition does not make any sense to me. There’s no need to redefine the same object a second time because it’s outside of the control domain. In the worst case, if this is needed, a single data point inside the object could be used to flag this. But a different object isn’t needed IMHO. 

My thoughts here: forking the definition of the ext objects to mean something entirely different was a bad idea. Let’s get back to the original idea of ext == extension, not ext == external. 

> I remain unconvinced that me need N different topology models.

+1
I’m sure we can get to a single topology model that would be generic enough to cover all needs.

Note that draft-medved also has the concept of nesting topologies through underlay-topologies and supporting-node. 

So far, I like the cleanliness and simplicity of draft-mdeved. Not sure why it’s expired and hasn’t been worked on, as it seems to be the base for several i2rs documents. 

JF

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 13 Nov 2014 21:34:34 +0000

Hi Jürgen

I have introduced some comments in-line.

Best regards

Luis

-----Mensaje original-----
De: Supa [mailto:[email-masked]] En nombre de Juergen Schoenwaelder
Enviado el: jueves, 13 de noviembre de 2014 12:52
Para: Wunan (Eric)
CC: [email-masked]; [email-masked]; Tina TSOU
Asunto: Re: [Supa] Network Topology Data Model and Network Configration Data Model

[Luis>>] There are cases where the termination point of a connection exceeds the notion of interface. I'm thinking in cases such as LAG configurations, IMA groups, or 1+1 radio configurations in microwave. Termination point can result in a proper terminology for abstraction of these situations.

[Luis>>] Since there can be different levels of abstraction, each of those levels could rely in an specific topology model according to the level being abstracted. For sure the whole picture should be consistent.

/js

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, 13 Nov 2014 11:35:24 -1000

> On Nov 13, 2014, at 11:14 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Yes,
> 

Agreed. And we’ve been told i2rs would take care of it. However I’m not seeing much action from that group, any reason why? 

Again, https://tools.ietf.org/html/draft-medved-i2rs-topology-im-01 <https://tools.ietf.org/html/draft-medved-i2rs-topology-im-01> seems to be a good starting point, but I don’t understand why it has been left to expire. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Thu, 13 Nov 2014 11:44:14 -1000

> On Nov 13, 2014, at 11:34 AM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:
> 

Good point, but one could argue that such a case is only two different topologies at different levels of abstraction. The same could be said for a VLAN interface on a node, for example. 

The LAG at one abstraction level is a single link between two nodes. At the abstraction level just below, it’s a number of links between the same two nodes. This way, it leaves the definition of the topology model very clean. 

JF (still not convinced we need termination points)

Btw, as a general public announcement, it would really help if every body on this list: 
a) trimmed their messages (removing unneeded text) 
and 
b) used proper quoting (add appropriate “ >” before quoted text)

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 13 Nov 2014 21:59:43 +0000

Hi JF

I have inserted some comments on your mail

Best regards

Luis

De: Supa [mailto:[email-masked]] En nombre de JF Tremblay
Enviado el: jueves, 13 de noviembre de 2014 22:32
Para: [email-masked]
CC: Alex Clemm; Juergen Schoenwaelder
Asunto: Re: [Supa] Network Topology Data Model and Network Configration Data Model

[Luis>>] In my opinion termination point is a generic and valid term to define the boundaries of a connection. Sometimes (maybe most of them) can be mapped to single interface. But not always. For instance LAG groups.

On “ext” objects:

   the topology.

[Luis>>] In my opinion it is needed to have differentiation. Maybe the differentiation can come with the usage of a flag, certainly. The rationale behind such differentiation basically is to have the notion that those elements are not (or cannot be) controlled and managed by the control and management entities in the domain. This is an essential differentiation from the service provision point of view. Whatever mean is used (flag, characterization as external, etc) to note them as external is needed.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 13 Nov 2014 22:03:20 +0000

Hi JF

Please, find also comments in-line

De: Supa [mailto:[email-masked]] En nombre de JF Tremblay
Enviado el: jueves, 13 de noviembre de 2014 22:44
Para: [email-masked]
Asunto: Re: [Supa] Network Topology Data Model and Network Configration Data Model

[Luis>>] I agree. Two topologies with two levels of abstraction. Termination point is valid for they two.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Nov 2014 23:11:09 +0100

> [Luis>>] In my opinion termination point is a generic and valid term to define the boundaries of a connection. Sometimes (maybe most of them) can be mapped to single interface. But not always. For…

Can you please further explain why LAG groups have termination points
that are not interfaces? In Linux, interface bonding yields another
interface. Interfaces are not flat, they can be stacked and they can
represent aggregations and deaggregations.

/js

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 13 Nov 2014 22:29:19 +0000

Hi Jürgen

I see your point. However it is not always possible to represent these cases as single interfaces. For instance multi-chassis LAG.

My personal opinion is that the term "termination point" is much more generic, covering all situations, and avoid confusions or misunderstanding.

Best regards

Luis

-----Mensaje original-----
De: Juergen Schoenwaelder [mailto:[email-masked]]
Enviado el: jueves, 13 de noviembre de 2014 23:11
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: JF Tremblay; [email-masked]; Alex Clemm
Asunto: Re: [Supa] Network Topology Data Model and Network Configration Data Model

> [Luis>>] In my opinion termination point is a generic and valid term to define the boundaries of a connection. Sometimes (maybe most of them) can be mapped to single interface. But not always. For…

Can you please further explain why LAG groups have termination points that are not interfaces? In Linux, interface bonding yields another interface. Interfaces are not flat, they can be stacked and they can represent aggregations and deaggregations.

/js

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 13 Nov 2014 12:35:10 -1000

> Le 2014-11-13 à 12:11, Juergen Schoenwaelder <[email-masked]> a écrit :
> 
> interface.

and many other OS, I would even say in most OS, including networking OS.

Marc.

> Interfaces are not flat, they can be stacked and they can

---

From: JF Tremblay <[email-masked]>
Date: Thu, 13 Nov 2014 13:46:11 -1000

> On Nov 13, 2014, at 12:29 PM, LUIS MIGUEL CONTRERAS MURILLO <[email-masked]> wrote:
> 
> Hi Jürgen
> 

Hum.. how would you represent this? Each chassis is a node and the LAG looks like a single link to a single TP? But then on which nodes does the TP resides?

> My personal opinion is that the term "termination point" is much more generic, covering all situations,

That remains to be proved. So far, I still have to see a case where it’s really required. 

> and avoid confusions or misunderstanding.

So far it only *creates* confusion, apparently. Could you point us to a complete and useful definition of “termination endpoint”? I don’t remember seeing any in the drafts. 

I would love to have the authors of draft-medved-i2rs-topology-im chime in and tell us where they got the idea or give us the rationale behind termination points. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Thu, 13 Nov 2014 17:23:33 -1000

> My personal opinion is that the term "termination point" is much more generic, covering all situations, and avoid confusions or misunderstanding.

A data point provided by Alex Clemm (thanks): Termination Points are defined in ITU M.3100 from 2005. It seems to be used as a synonym for interface in that document, but imo it’s not very clear (hey, it’s an ITU doc..). 
(see http://www.itu.int/rec/T-REC-M.3100-200504-I/en <http://www.itu.int/rec/T-REC-M.3100-200504-I/en>)

JF

---

From: Andrew Qu <[email-masked]>
Date: Fri, 14 Nov 2014 03:43:29 +0000

Hi Jurgen,

Because what SUPA describes may be high level service relationship,   that may
Be new in the first place and more generic term may be warranted because otherwise, 
I would argue in that case if interface is used that interface has been used for long time
In ip world and it has fixed meaning and not suitable for high level service connection
Which really NOT directly map to physical "interface" or "port"

For example:

If SUPA descript a data center interconnect service topology,
Between data_center_site_A and B has termination points attached,  but using
Interface here may not be proper, because SUPA level dose not explicitly
to specify physical port, it only describe "request" and "relationship" and
does not need to specify "an interface" between DC site A and B.  And they
are logically connected by a "cloud" anyway.

Thanks,

Andrew

-----Original Message-----
From: Supa [mailto:[email-masked]] On Behalf Of LUIS MIGUEL CONTRERAS MURILLO
Sent: Thursday, November 13, 2014 2:29 PM
To: Juergen Schoenwaelder
Cc: JF Tremblay; Alex Clemm; [email-masked]
Subject: Re: [Supa] Network Topology Data Model and Network Configration Data Model

Hi Jürgen

Best regards

Luis

-----Mensaje original-----
De: Juergen Schoenwaelder [mailto:[email-masked]]
Enviado el: jueves, 13 de noviembre de 2014 23:11
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: JF Tremblay; [email-masked]; Alex Clemm
Asunto: Re: [Supa] Network Topology Data Model and Network Configration Data Model

/js

---

From: Andrew Qu <[email-masked]>
Date: Fri, 14 Nov 2014 03:58:26 +0000

Hi Juergen,

There are two aspects here.
1) where the work should be done
2) necessity of SUPA 

Here I want to address 2).

SUPA is not designed to replace I2RS or does similar thing to I2RS,   hence
It should not be merged into "_1_" topology data model.

SUPA is designed to sit on top of I2RS that these two may work together
To accomplish the same network programmability task.

For example:

A cloud network provider receive a working order to create a particular network
For a IT application that run across multiple data centers.  This is trial
Network for that Application.

The working order may be executed via a OSS tool and that tool will generate
a logical map (topology) at high level at the central site,  then the topology
will be further interpreted into SUPA defined language and will be
send to multiple controller that manage each component such as 
1) PCE optical network
2) PEs (WAN controller)
3) POD (CLOS network controller)
4) Vcenter (OpenStack for VM/storage)

Once each controller being informed such request,  I2RS that sits in
OpenStack or CLOS network controller may be called to program
Physical ROUTER/Switch here when "interface" is become more
Proper.

In this way, I don't see SUPA conflict with I2RS and on the opposite,
They are both needed to work together.

Thanks,

Andrew

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, November 13, 2014 1:14 PM
To: Andrew Qu
Cc: Wunan (Eric); [email-masked]; Tina TSOU
Subject: Re: [Supa] Network Topology Data Model and Network Configration Data Model

Yes,

I believe that the IETF should define _1_ core topology data model and the IESG members of the areas where this is relevant should find out where to do this work.

/js

On Thu, Nov 13, 2014 at 09:01:33PM +0000, Andrew Qu wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> ************* Email Confidentiality Notice ******************** The 
> information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or 
> otherwise exempt from disclosure under applicable laws. It is intended 
> to be conveyed only to the designated recipient(s). Any use, 
> dissemination, distribution, printing, retaining or copying of this 
> e-mail (including its
> be unlawful. If you are not an intended recipient of this e-mail, or 
> believe that you have received this e-mail in error, please notify the 
> sender immediately (by replying to this e-mail), delete any and all 
> copies of this e-mail (including any attachments) from your system, 
> and do not disclose the content of this e-mail to any other person. Thank you!
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Nov 2014 05:11:00 +0100

Hi,

I do understand the difference of goals of SUPA and I2RS.

I asked a different question: Should we not have a common core
topology data model? And I talked about the work to define such a
common core toplogy data model.

/js

---

From: Andrew Qu <[email-masked]>
Date: Fri, 14 Nov 2014 04:16:35 +0000

Hi Juergen,

In principle,  I agree with you. 

I think we need to find out if there are overlapping hence the common core
Topology data model can be worked on collaboratively.

Andrew

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, November 13, 2014 8:11 PM
To: Andrew Qu
Cc: Wunan (Eric); [email-masked]; Tina TSOU
Subject: Re: [Supa] Network Topology Data Model and Network Configration Data Model

Hi,

I asked a different question: Should we not have a common core topology data model? And I talked about the work to define such a common core toplogy data model.

/js

On Fri, Nov 14, 2014 at 03:58:26AM +0000, Andrew Qu wrote:
> SUPA is designed to sit on top of I2RS that these two may work 
> together To accomplish the same network programmability task.
> 
> For example:
> 
> A cloud network provider receive a working order to create a 
> particular network For a IT application that run across multiple data 
> centers.  This is trial Network for that Application.
> 
> The working order may be executed via a OSS tool and that tool will 
> generate a logical map (topology) at high level at the central site,  
> then the topology will be further interpreted into SUPA defined 
> language and will be send to multiple controller that manage each 
> component such as
> 1) PCE optical network
> 2) PEs (WAN controller)
> OpenStack or CLOS network controller may be called to program Physical 
> ROUTER/Switch here when "interface" is become more Proper.
> 
> > otherwise exempt from disclosure under applicable laws. It is 
> > intended to be conveyed only to the designated recipient(s). Any 
> > use, dissemination, distribution, printing, retaining or copying of 
> > this e-mail (including its
> > attachments) by unintended recipient(s) is strictly prohibited and 
> > may be unlawful. If you are not an intended recipient of this 
> > e-mail, or believe that you have received this e-mail in error, 
> > please notify the sender immediately (by replying to this e-mail), 
> > delete any and all copies of this e-mail (including any attachments) 
> > from your system, and do not disclose the content of this e-mail to any other person. Thank you!
> >

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 14 Nov 2014 12:28:53 +0000

Hi JF,

Please, see in-line

Hum.. how would you represent this? Each chassis is a node and the LAG looks like a single link to a single TP? But then on which nodes does the TP resides?
[Luis>>] The concept of container plus the idea of termination point can cover this.