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

tom petch <ietfa@btconnect.com> Thu, 26 November 2020 12:29 UTC

Return-Path: <ietfa@btconnect.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A413A12C6 for <teas@ietfa.amsl.com>; Thu, 26 Nov 2020 04:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg9ezMlA7BE3 for <teas@ietfa.amsl.com>; Thu, 26 Nov 2020 04:29:17 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130117.outbound.protection.outlook.com [40.107.13.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C870E3A12C5 for <teas@ietf.org>; Thu, 26 Nov 2020 04:29:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZFVjH+YYtTLlWmcYRSOznCIR/+Qf3Q2zzMxrocjk1L1ckwucd1ONohMYAwdjDnzJr6aEUaVUk/LUXJAmQ9w4nAziKRCSApnzuUHeAfgv0jRVoLM84mw2Zbae15QU7pqI6NB4HiqYoVhJPHwLcbvmW3WWAwf0y29VtyTy04e2zB6AhM1VDDaOrP/2SCP86d3cJieDQ9eV5I7pCn4mImWTaQXlfx2MSqgd5Perh5mMSc94X4xIXZ3nrd+K0ELRvf9EmO/NPqNY9/au8U4cNo9IANPdc0IfPJTR4Kao4QcVVcaitmZ+/Yi1yB3Fq7+3evuCQkpxcyU3Wzc10dFnFmCL0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EWQA3oQSt0TOEMtQ90fTQs0ysCXLvOlxd4F4j8UYpDw=; b=Gqk7Sldib3623ogxUsA2BqUeNaThPUY5YnRPDeKvm0tbhI8HtAYcBxhPkrDIWepm0QqZjIslB8jnUw3iQ1Lfr+uynwrFv4XkpRBenivzAZtLTnnPXItY4/xavy2dJ2gkpJt9z1eycoD/kk5j6kYOUWKrgY+O362JBHXyQ5rix1vdZkkDKcBXvauUkGhCKlZHNXvxdiloIzz2ohffz4XTS+sO8Ev/vvetJkua8TiX9+G3u0SnKoBDDX+N2tmy+vmxnaDPyCWIEhg9KkCht+4N/p/J+aGdRlsrJIbWcKTUsXkLqEjTJ34CNof71yxMkHkhkdBZTsWcGTpPlOQy6ANmyg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EWQA3oQSt0TOEMtQ90fTQs0ysCXLvOlxd4F4j8UYpDw=; b=N9OEdidMKXHZTe22lQJsYibuPo8Pegjcx75paA2SM2kZpaP5hpm9FyGByDN2RfVx9xGYhksDK4cbw3KQ4ejnavE7633hzVJ3s+ww1gkyAFUdL7r9r5u1Fj2ulGiyZweFZZxaq7RRdw1E7IJP/G0iepykDC9s6OJY2y04f85oBWQ=
Received: from AM6PR07MB5784.eurprd07.prod.outlook.com (2603:10a6:20b:95::29) by AM7PR07MB6980.eurprd07.prod.outlook.com (2603:10a6:20b:1c3::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Thu, 26 Nov 2020 12:29:13 +0000
Received: from AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b]) by AM6PR07MB5784.eurprd07.prod.outlook.com ([fe80::15d0:d260:35ea:7c9b%6]) with mapi id 15.20.3611.022; Thu, 26 Nov 2020 12:29:13 +0000
From: tom petch <ietfa@btconnect.com>
To: Italo Busi <Italo.Busi@huawei.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>
CC: TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo
Thread-Index: AQHWwyXBeXEXx4E87kyj/eyiIovA1KnaPcGAgAAUx+k=
Date: Thu, 26 Nov 2020 12:29:13 +0000
Message-ID: <AM6PR07MB57849AA20A22B0F1187C13E1A2F90@AM6PR07MB5784.eurprd07.prod.outlook.com>
References: <CAEz6PPQC8NUnTimMVXBXzbd9+FxdeTDV8NXPuLDASBF=1YUR_A@mail.gmail.com> <DB7PR07MB53406ABD74B3CEE15B5952BDA2AB0@DB7PR07MB5340.eurprd07.prod.outlook.com> <CAEz6PPS-ZWSb7cubv2jB05ZCb9kyyGXDPd5KpAQ05iHmtpMpCw@mail.gmail.com> <DB7PR07MB5340DFF664791762E1F082F6A2A20@DB7PR07MB5340.eurprd07.prod.outlook.com> <CAEz6PPT6N0a3FNtseRFzuXEAJoBvnBRBtwzg4vi+ZDLHxUZCrQ@mail.gmail.com> <DB7PR07MB534098BD42E7C079288A20B5A2610@DB7PR07MB5340.eurprd07.prod.outlook.com>, <CAEz6PPRByqJ46E4aCv-v=mtX9BoLZPCgo4tx-2zaHjOxELMgqQ@mail.gmail.com> <AM6PR07MB5784DF50C33FB512C07FA87CA2FA0@AM6PR07MB5784.eurprd07.prod.outlook.com>, <eedf0b071ab64b5abce2a1a9bf0def0a@huawei.com>
In-Reply-To: <eedf0b071ab64b5abce2a1a9bf0def0a@huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.146.121.140]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 03b3b0d0-6a65-4879-3b77-08d89206e25f
x-ms-traffictypediagnostic: AM7PR07MB6980:
x-microsoft-antispam-prvs: <AM7PR07MB698099292C07E7B4334CEFBFA2F90@AM7PR07MB6980.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y8iiZZ2pOUYLpt7SOSLZdHchdBBcddFQBp2y3qFMHT6fJp0IgyTt9AT91/MdMi6FYV8Ahp81VGyeUlImhrN+AnEUDfvMDjGc6uSqifJ2NYxVErzmae76Dh+dDjGz0E4YqszbP/M21a32bJD+xsFOXQHSVnuet0Da/EpDpeTjzckjzZ6jpBw0YWOo2oj2qNXvi8iTd8vPSd6w5KpXIwNvUdqpFEVjvhuNm2xSLTY1x0VA0Ip3va1iiXvIDtL0tUQKpwR0PANw6udCxP6FhUWH+pKITG5t8S8ft2aUxnbxUssVOyLE1vh13LgxugjsNEUiZCXEnXehfurmJSO5gtbyFHpP9IkQxvTiWAo75NNUteAooOfclgHVZ5CsPEirF3jZMAcJsfzILvqp+YrtCzRMZekyhjBdovSL+E7LuwyPO3tjOD4+eZzOgC+8HVDvrNU86rdKopZW4mepvYdtZRo6Cw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5784.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(346002)(39860400002)(396003)(64756008)(6506007)(15650500001)(33656002)(53546011)(66556008)(26005)(8676002)(66446008)(76116006)(71200400001)(316002)(4326008)(7696005)(2906002)(66946007)(8936002)(91956017)(66476007)(55016002)(9686003)(478600001)(86362001)(83380400001)(966005)(110136005)(5660300002)(186003)(52536014)(49343001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?ynaTBBhoToEWY+qWOLaThr+5xG50w/mDeONIZjGpBhj1SrEtJnPpFt9+zw?= =?iso-8859-1?Q?JM8y/yP99alGNIx+i28NcU9pYf/T3aeHpIaK/qVYWUdl6p0BJdqEel+g8+?= =?iso-8859-1?Q?ef5bvECnCEm1FQhuP6ORvONEP5PO8s8tpI1TV+C8xsRj1sJtSbnOf0wa9G?= =?iso-8859-1?Q?wVIFWcpt3pCkDzH8EeNTLor+L6DS5JN+1a5wrLUFWoywCTGVkEaR1dmAYn?= =?iso-8859-1?Q?GLJfts0S0/KpoYE26/VDRy2Jk+aOq3uH9ioCqPaij9Br5r8IUxOFa8Vwdr?= =?iso-8859-1?Q?GykQP8WK86tlNSo4drsaIyA2EiMxWeyW/naEekEyqBXCam8myuYUAgJV6d?= =?iso-8859-1?Q?Cg2o8V8o78Iqkw6/iIwVt2Nc8v/+sdCfwv6uqmsE9jLF00ZNjadN2DpywP?= =?iso-8859-1?Q?/BSda6Nl9mAGykEJnGqDuYy79TxW89ZVb1NUzRTH3A77rS5GbQf52rIHfJ?= =?iso-8859-1?Q?H4M/dfa0c5d8JcS4c0C1cZqjUyLhu2FK8P4V96jRQXiVviDw8yW8IwLvt7?= =?iso-8859-1?Q?I0G64LcTGPRQ9u0WAmwTmSvMJxXS95pnkPJG0TKmfgZMmzG3jexqQvz335?= =?iso-8859-1?Q?nVN/CFxc1/yWd0x9MZcflr0qdL+90qW+m2MyKBdvwJQx2Mn5hImrcBK2uc?= =?iso-8859-1?Q?J6gFzP0GqW6ShoTXXNL8Xhaw97plSc0BuYr89mWFkA+kuZpxDN4AKhIRPX?= =?iso-8859-1?Q?e+7ZzJCcqm7K5mnPK6AVdZ/pEZUZzRWAWtuh57at6iGz/qpCpKvgpVWUtU?= =?iso-8859-1?Q?Wf9xO5tXZYLnIkv3MCEND/NXhcjazdPOrKOjP9mL9u1Puh+WFZRxT0TmGw?= =?iso-8859-1?Q?arYNnhOHEF6AZK7lAbfL5KA/JYfAKGQpwQruvT593PqLd/0dQyi33aIyKw?= =?iso-8859-1?Q?6losUj8IJNxZMiqo+nMMc0gFzBa8KusIaFvdsttFcDr0R4Poq8vQqTGPFM?= =?iso-8859-1?Q?2eLtMq9p6ete6a0pxUHdUSDgAgTwFAmAejX1F91pTafdyBMwzqCnRsTw3s?= =?iso-8859-1?Q?zJzbzDVHecrjxijGM=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM6PR07MB5784.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03b3b0d0-6a65-4879-3b77-08d89206e25f
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 12:29:13.7376 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: u8Vw9HRalgfl6CZrVzHvwPOtOLDjVQlq9zAS9/Wtr749dJjCOT5MPt+k/zEY2zCGAuVltGuKNiZL/Lvt5tGUFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6980
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-IIcSKvokiuFnBxfbxMJ8hki04U>
Subject: Re: [Teas] network-types was stttus update on draft-ietf-teas-yang-l3-te-topo
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2020 12:29:20 -0000

From: Italo Busi <Italo.Busi@huawei.com>
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:ietfa@btconnect.com]
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>]6>].

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 <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>
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 <ietfa@btconnect.com<mailto:ietfa@btconnect.com<mailto:ietfa@btconnect.com<mailto:ietfa@btconnect.com>>> wrote:
From: Xufeng Liu <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>>>
Sent: 13 July 2020 15:29