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

Italo Busi <> Thu, 26 November 2020 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7EA733A112D for <>; Thu, 26 Nov 2020 02:51:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RYh6dRC1LgZC for <>; Thu, 26 Nov 2020 02:51:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A9333A0C40 for <>; Thu, 26 Nov 2020 02:51:06 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4ChZJ90BVDz67JFq; Thu, 26 Nov 2020 18:49:13 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 26 Nov 2020 11:50:59 +0100
Received: from ([]) by ([]) with mapi id 15.01.2106.002; Thu, 26 Nov 2020 11:50:59 +0100
From: Italo Busi <>
To: 'tom petch' <>, Xufeng Liu <>
Thread-Topic: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo
Thread-Index: AQHWw9S6rZt3P8P5M0aAk42RBFv3jKnaOeSg
Date: Thu, 26 Nov 2020 10:50:59 +0000
Message-ID: <>
References: <> <> <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_eedf0b071ab64b5abce2a1a9bf0def0ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Nov 2020 10:51:09 -0000

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


-----Original Message-----
From: tom petch []
Sent: mercoledì 25 novembre 2020 13:23
To: Xufeng Liu <>
Cc: TEAS WG <>
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<>].

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

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 <<>>
Sent: 20 November 2020 23:02

Hi Tom,
Thank you much for your further comments. We have posted, hoping to address some of your comments below.

- Xufeng

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