Re: [i2rs] 'network type' placement and RFC8345

Qin Wu <> Thu, 24 September 2020 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4348B3A1714 for <>; Wed, 23 Sep 2020 19:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 1v8gCka8FvEx for <>; Wed, 23 Sep 2020 19:22:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DED03A0A99 for <>; Wed, 23 Sep 2020 19:22:50 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 012568CCB18DF594D270 for <>; Thu, 24 Sep 2020 03:22:48 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 24 Sep 2020 03:22:47 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 24 Sep 2020 03:22:47 +0100
Received: from ([]) by ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Thu, 24 Sep 2020 10:22:44 +0800
From: Qin Wu <>
To: tom petch <>, Sue Hares <>
CC: "''" <>
Thread-Topic: [i2rs] 'network type' placement and RFC8345
Thread-Index: AdaSFusD+5t7dKo7Qi2RG4sVyqs3yA==
Date: Thu, 24 Sep 2020 02:22:43 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [i2rs] 'network type' placement and RFC8345
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2020 02:22:52 -0000

Hi, Tom:
Layer2, Layer 3, TE are all base modules which other modules can extend from.
I am not sure we have Layer 1 base module,
WSON and flexi-grid, if my understanding is correct, are TE technology specific and WSON and flexi-grid module can be seem as extension to TE module or a module derived from TE module
Therefore we could follow OSPF example defined in the L3 topology module or L3 TE module defined in draft-ietf-teas-yang-l3-te-topo-08.
   module: ietf-l3-te-topology
     augment /nw:networks/nw:network/nw:network-types
       +--rw l3-te!
   module example-ospf-topology
   augment "/nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology" 
       +--rw ospf!
I might be wrong if a generic layer 1 can be defined without adding dependency to TE technology. But at least layer 1 type or layer 0 type are common building block that can be reused.

In addition, base model, in my opinion doesn't need to limit to layer 1, layer 2, layer 3, service layer, TE layer this angle, we may classify network topology from other angle, e.g., classify network topology into UNI topology and NNI topology,
One relevant model is UNI topology model that is proposed in the opsawg
such models are also base model which other modules can derive from.

For network type, if we can define it as identity, it may be another design option.
But comparing with presence container design, I think the only difference is one is explicit way, the other is implicit way.

发件人: i2rs [] 代表 tom petch
发送时间: 2020年9月23日 17:16
收件人: Sue Hares <>
抄送: '' <>
主题: [i2rs] 'network type' placement and RFC8345

RFC8345 requires that a new network type be given a presence container and suggests a tree structure with layer 1, layer 2, layer 3 and service as top level nodes with OSPF as an example of a node subordinate to layer 3.  te-topology , RFC8795, places its presence container at the top level alongside these four.
Question; where should a network type such as WSON or flexi-grid be placed?  wson-yang, in IETF Last Call, places it under te-topology which is possible but it seems to me more like a layer 1 or layer 0. But then network types do not seem to form a tree, rather a mesh so a tree structure seems wrong.  And wherever layer 1 is defined it is not in a module imported by wson-yang although it might be added to layer0-types (!) which wson-yang does import. I would see it as wrong to define layer 1 in wson forcing others to import wson.


I have posted this to Lou and TEAS but as it is a question that cuts across multiple WG I suspect that I will get multiple contradictory answers or none:-)

Tom Petch
i2rs mailing list