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

[Italo Busi <[e-mail]>]

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.

My 2 cents

Italo

-----Original Message-----
From: tom petch [mailto:[e-mail]]
Sent: mercoledì 25 novembre 2020 13:23
To: Xufeng Liu <[e-mail]>
Cc: TEAS WG <[e-mail]>
Subject: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo

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

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.

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