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

["Wunan (Eric)" <[e-mail]>]

Jurgen,



Please see my words in line.



Regards

Eric

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

On Tue, Nov 11, 2014 at 09:21:01PM +0000, Wunan (Eric) wrote:
> Hi Juergen,
>
> Reply in line.
>
> Regards
> Eric
>
> ________________________________________
> 发件人: Juergen Schoenwaelder [[e-mail]]
> 发送时间: 2014年11月12日 4:15
> 收件人: Wunan (Eric)
> 抄送: [e-mail]; Tina TSOU
> 主题: Re: [Supa] Network Topology Data Model and Network Configration Data Model
>
> On Tue, Nov 11, 2014 at 08:04:33PM +0000, Wunan (Eric) wrote:
> >
> >
> > 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.
>
> 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.
>
> [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
>        }

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?

[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.

> > 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.
>
> 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'.
>
> [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.

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.



[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

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>