Re: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo

[tom petch <[e-mail]>]

From: Italo Busi <[e-mail]>
Sent: 26 November 2020 10:50

Hi Tom,

I think there is valid logic in the way network-types have been defined up to now. See some comments in line below.
<tp
>
Italo

I thought that you would:-)  Yes, 8345 does allow it and is more explicit about a tree sturcture than I had remembered.  I think that my view of network subtypes is more limited than yours:-(  You are saying that the tree structure of the network-types should be the same as the tree structure of the augments for the data nodes.  Well, yes, logical but not a logic I am keen on.   As with the data, I see us ending up with a te-topology monolith plus a few outliers. Anyhow, having raised it I will shut up about it.

In passing, I checked my references, where you say you guess I mean, and I really do mean what I first wrote and not your emendations. I have repeated that inline below.   Curious that you did not think that I meant them.

Tom Petch


My 2 cents

Italo

-----Original Message-----
From: tom petch [mailto:[e-mail]]
Sent: mercoledì 25 novembre 2020 13:23

Top posting a more general TEAS issue I see when looking at teas-yang-l3-te-topo

A model that introduces a new network type must define a new network type, as a presence container, as defined in RFC8345.

I assumed that this would be a flat namespace but no, it is a tree structure which means that to reference it, as happens many times with YANG when statements, you must know where in the tree it is defined.

[[Italo Busi] ] I think that the text in section 4.1 of RFC8345 clearly explains that the network-types are intended to be used in a hierarchical fashion:

   When a network is of a certain type, it will contain a corresponding
   data node.  Network types SHOULD always be represented using presence
   containers, not leafs of type "empty".  This allows the
   representation of hierarchies of network subtypes within the instance
   information.  For example, an instance of an OSPF network (which, at
   the same time, is a Layer 3 unicast IGP network) would contain
   underneath "network-types" another presence container
   "l3-unicast-igp-network", which in turn would contain a presence
   container "ospf-network".  Actual examples of this pattern can be
   found in [RFC8346<https://tools.ietf.org/html/rfc8346>].

Thus
teas-sf-aware- topo-model places it under /network-types/te-topology

[[Italo Busi] ] I think it makes sense since the teas-sf-aware- topo-model requires to be implemented together with the te-topology

while teas-yang-sr-te-topo places it under /network-types/l3-unicast-topology

[[Italo Busi] ] I guess you mean teas-l3-te-topology. I think that for L3-TE the approach makes sense since the l3-te-topo-model requires to be implemented together with the l3-unicast-topology-topology
<tp>

No I really do mean teas-sr-te-topo and l3-unicast-topology which is what it augments
</tp>

while
teas-l3-te-topology does both!

[[Italo Busi] ] I guess you mean the teas-yang-sr-te-topo. I think that for SR-TE the approach makes sense sine the L3-TE and SR-MPLS topologies can be used either independently or, in case of SR-TE, together.

<tp>
No I really do mean teas-l3-te-topology
</tp>


This seems unfortunate and likely to cause confusion, errors, over time.  Doubtless there is a logic behind the different placements but I see consistency as better.

Tom Petch
________________________________________
From: Xufeng Liu <[e-mail]<mailto:[e-mail]>>
Sent: 20 November 2020 23:02

Hi Tom,
Thank you much for your further comments. We have posted https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-l3-te-topo-09, hoping to address some of your comments below.

Thanks,
- Xufeng

On Tue, Jul 14, 2020 at 7:34 AM tom petch <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>> wrote:
From: Xufeng Liu <[e-mail]<mailto:[e-mail]<mailto:[e-mail]<mailto:[e-mail]>>>
Sent: 13 July 2020 15:29