Subject: [i2rs] network-type: container vs. identity?

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 8 Jul 2016 03:47:11 +0000

Hi, Authors,

   while using this model as a base to augment for technology-specific topologies, I wonder why the leaf network-types is a container, instead of being as a identity?

I remember I asked Alex offline before, but the response I got was that the identity was also under consideration at that time. Given the latest version (June 2016 version) still use container, I wonder if the authors can explain why the alternative is discarded? Thank you.

Regards,
Xian

---

From: Robert Varga <[email-masked]>
Date: Mon, 11 Jul 2016 12:53:50 +0200

On 07/08/2016 05:47 AM, Zhangxian (Xian) wrote:
> Hi, Authors,
> 
>  
> 
>    while using this model as a base to augment for technology-specific
> topologies, I wonder why the leaf network-types is a container, instead
> of being as a identity?
> 
>  
> 
> I remember I asked Alex offline before, but the response I got was that
> the identity was also under consideration at that time. Given the latest
> version (June 2016 version) still use container, I wonder if the authors
> can explain why the alternative is discarded? Thank you.

The idea is to be able to have multiple traits, for example for composition.

Bye,
Robert

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Tue, 12 Jul 2016 14:49:23 +0000

Hi, Robert, 

   Thank you for your clarification. Just make sure I get your point, let me try with a (real) example. 

   At the moment, we have the following relationship among different topology types ( using the diagram from https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-02 as base):

            +-----------------------------+
           |  +-----------------------+  |
           |  |    ietf-network |  |
           |  +----------^------------+  |
           |         |            |
           |  +-----------------------+  |
           |  | ietf-network-topology |  |-------< [ietf-te-topology]------<[ otn-topology] ( as an example)
           |  +----------+------------+  |
           +-------------^---------------+
                         |
                         |
             +-----------^-------------+
             | l3-unicast-igp-topology |
             +----+---------------+----+
                  ^               ^
                  |               |
                  |               |
         +--------^-----+      +-----^---------+
         | ospf-topology|    | isis-topology |
         +--------------+       +---------------+

So, this shows support of more than two levels of relationships and many branches. Is that what you mean by multiple traits and composition? Although I do not see an example using this identity for this, but I wonder if the following way of using identity is supported and can be used to cater your need? 

Identity network-types {
  Description "base type for network types";
}

Identity type-topology {
 Base "network-types";
}

Identity type-l3-unicast-igp {
 Base " type-topology ";
}

Identity type-ospf {
 Base "type-l3-unicast-igp";
}

I am cooking the codes up with my limited understanding of YANG, so I might be wrong. If so, please do let me know. 

Cheers,
Xian

-----Original Message-----
From: Robert Varga [mailto:[email-masked]] 
Sent: 2016年7月11日 18:54
To: Zhangxian (Xian); [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] network-type: container vs. identity?

On 07/08/2016 05:47 AM, Zhangxian (Xian) wrote:
> topologies, I wonder why the leaf network-types is a container, 
> instead of being as a identity?
> 
>  
> 
> I remember I asked Alex offline before, but the response I got was 
> that the identity was also under consideration at that time. Given the 
> latest version (June 2016 version) still use container, I wonder if 
> the authors can explain why the alternative is discarded? Thank you.

Bye,
Robert

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 12 Jul 2016 16:29:48 +0000

Hi Xian,

the way it is structured with containers and all will allow you to indicate the various network types that apply to a network.  If there is a hierarchy of network types, you would have a hierarchy of containers.  In your case  network-types --> ietf-te-topology--> otn-topology.  Network will indicate each of the network types that it instantiates.  

You could model a hierarchy of network types also through a hierarchy of identities, as you indicate in your example.  Sure, in your example this is a viable alternative, but it is not clear what you would gain through that.  For one, in the case of "otn-topology", the fact that the same topology is also an ietf-te-topology is rather implicit, not explicit.  Per Robert's point, if for some reason you have multiple traits and want to "compose" a network to encompass multiple types, this is straightforward to do with the current pattern, not so straightforward with identities.   

--- Alex

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, July 12, 2016 7:49 AM
To: Robert Varga <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] network-type: container vs. identity?

Hi, Robert, 

Identity network-types {
  Description "base type for network types"; }

Identity type-topology {
 Base "network-types";
}

Identity type-ospf {

Cheers,
Xian

-----Original Message-----
From: Robert Varga [mailto:[email-masked]]
Sent: 2016年7月11日 18:54
To: Zhangxian (Xian); [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] network-type: container vs. identity?

Bye,
Robert

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jul 2016 18:44:45 +0200

> You could model a hierarchy of network types also through a hierarchy of identities, as you indicate in your example.  Sure, in your example this is a viable alternative, but it is not clear what y…

Alex,

can you further detail why a hierarchy of containers is more
straightforward in some cases than a hierarchy of identities?

/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: Robert Varga <[email-masked]>
Date: Tue, 12 Jul 2016 18:53:32 +0200

On 07/12/2016 06:29 PM, Alexander Clemm (alex) wrote:
> Per Robert's point, if for some reason you have multiple traits and want to "compose" a network to encompass multiple types, this is straightforward to do with the current pattern, not so straightforward with identities.   

There is also an issue of consistency within the models. While it may
not be obvious to have more 'topology types', it certainly makes sense
for nodes within a topology -- for example in ODL we tag topology nodes
with capabilities based on the southbound protocol (like PCEP, OpenFlow,
NETCONF).

Bye,
Robert

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 12 Jul 2016 17:09:18 +0000

We do have a case for a topology that has multiple "topology types": we are defining a topology-type "sr-topoloyg" which is derived from "l3-unicast-igp-topology". We are also defining a topology of type "SR TE topology", which type is both "sr-topology" and "te-topology", hence multiple-inheritance is needed. 

Thanks,

- Xufeng

> Sent: Tuesday, July 12, 2016 12:54 PM
> To: Alexander Clemm (alex) <[email-masked]>; Zhangxian (Xian)
> <[email-masked]>; [email-masked]
> Cc: [email-masked]
> > Per Robert's point, if for some reason you have multiple traits and want to
> "compose" a network to encompass multiple types, this is straightforward to do
> with the current pattern, not so straightforward with identities.
> 
> There is also an issue of consistency within the models. While it may not be
> obvious to have more 'topology types', it certainly makes sense for nodes within
> a topology -- for example in ODL we tag topology nodes with capabilities based
> on the southbound protocol (like PCEP, OpenFlow, NETCONF).
> 
> Bye,
> Robert