Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

tom petch <> Wed, 03 July 2019 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 254F0120733 for <>; Wed, 3 Jul 2019 03:12:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iEjqVea_xXxC for <>; Wed, 3 Jul 2019 03:12:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3220E12029A for <>; Wed, 3 Jul 2019 03:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=461aA74002o5G09bHnid+i64UFUzWd8qCy++VJxA72Y=; b=JTkYibJESfrdM8YEdszeWM8siBRGuvIz87R5GWDXlRyAMIJtGrnbK+sEimsrdvNoCkVdGE5GMcpmapHA4RnbaVQ+ozVBdnombWhc7yKX/BRX6hunOPgURx8KpwhoEIIUXszYaNK+5mGvtudCoAgb+x3J3vDRd6FBuCQfcfPOvQc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.15; Wed, 3 Jul 2019 10:12:17 +0000
Received: from ([fe80::ad68:9faf:d031:adf6]) by ([fe80::ad68:9faf:d031:adf6%5]) with mapi id 15.20.2052.010; Wed, 3 Jul 2019 10:12:17 +0000
From: tom petch <>
To: Young Lee <>, "" <>
Thread-Topic: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt
Thread-Index: AQHVJ4SsXRtvkfDwGUSTOsTxhShohQ==
Date: Wed, 3 Jul 2019 10:12:16 +0000
Message-ID: <073d01d53187$c742fde0$>
References: <> <> <013901d52784$b2e64760$> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LO2P265CA0059.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::23) To (2603:10a6:7:8e::28)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6852f349-4027-4398-fc59-08d6ff9eecb7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR0702MB3833;
x-ms-traffictypediagnostic: HE1PR0702MB3833:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(346002)(396003)(39860400002)(13464003)(189003)(199004)(81156014)(110136005)(86362001)(8676002)(66574012)(6506007)(386003)(486006)(81166006)(316002)(2501003)(99286004)(53546011)(44716002)(62236002)(6436002)(6486002)(5660300002)(6246003)(53936002)(14496001)(1556002)(186003)(71190400001)(66066001)(44736005)(71200400001)(14454004)(8936002)(66446008)(66476007)(66556008)(64756008)(73956011)(66946007)(6512007)(9686003)(25786009)(50226002)(3846002)(7736002)(2906002)(6116002)(446003)(26005)(229853002)(305945005)(256004)(52116002)(476003)(478600001)(4720700003)(76176011)(81816011)(81686011)(61296003)(68736007)(102836004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0702MB3833;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yzM+XuxlpuBtL/IltuB38+O6aj2b9M6sIBJbKHZ+jPciiAHT8aCPATkmLYfEb+J6YkmwylhALXrblpTTrVqusc28GLMN++/ObAUu3PcqWZzepi21bafzI6A4yk6W5koAaWKwsIGIBQ/Kmg0JlqJUFBXNn2AcatUV1n2PhjD9y6EZrHtdcQi6hVK/zitUoBs1qw9wQavVnQ8GuW7Wk9dnFE//VQEvj+0KxQlA1posFMG70f1vLP66t50vADX9uMwjeTzflhpUiVWxUzHQzsX1b2QL/wm+sAwTJvNztM/cCgly+6gbxaizsLuVdzHRQaCXtl7fG2eMnz7EnBCjtsyTPmKiVDsfF5SV8zG6alDPCdugmhiJntGdst0nmElMy7WP7Lv9+yO83zsjoSwYFduXF0bNFrdy5Y0l3KVzouzuTi0=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6852f349-4027-4398-fc59-08d6ff9eecb7
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 10:12:16.8925 (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-Transport-CrossTenantHeadersStamped: HE1PR0702MB3833
Archived-At: <>
Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt
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: Wed, 03 Jul 2019 10:12:23 -0000

Top posting about references, lack of.  You could do worse than use
teas-yang-te-topo as an exemplar for when to include references..

YANG should have a reference in Introduction, probably RFC7950,

In the YANG module, which will get extracted and so has to make sense on
its own, without the rest of the RFC-to-be

       feature multi-src-dest {
A good general principle is that any optional feature should have a
reference where I can see what it adds that is not in the base model.

the identity derived from
        identity vn-compute-state-type {
I would like to learn more about - what happens when a compute fails,
what happens while it is in progress?

      typedef vn-disjointness {
what is it? (I see no mention of disjoint in RFC8453)

      "VNAP related information";
perhaps a reference to RFC8453 s.6

      "Reference LTP in the TE-topology";
where can I find more about LTP - I see no ltp in RFC8453

       leaf connectivity-matrix-id
could reference te-topo for more information on connectivty-matrices

      "The list of metrics for VN";
te-topo has references for metrics; you could either reference them or
reference te-topo

       "a virtual network is identified by a vn-id";
well yes but I want to know more about id and name, their usage,
constraints thereon and so on; RFC8453 seeme silent on this

Tom Petch

----- Original Message -----
From: "Young Lee" <>
To: "tom petch" <>om>; <>
Sent: Tuesday, July 02, 2019 3:49 PM

Hi Tom,

Thanks for your comments. My apology for a delayed response. Please see
inline for my comment.



-----Original Message-----

From: tom petch []

Sent: Thursday, June 20, 2019 11:25 AM

To: Young Lee <>om>;

Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

----- Original Message -----

From: "Young Lee" <>

To: <>

Sent: Friday, June 14, 2019 7:44 PM

> Hi WG,


> The changes for this revision are as follows:


> - Added in Introduction Section on how the VN model can support 5G

transport context.

> - in Section 3.2: case 2 --- clarified how VN model is used along with

TE-topo Connectivity matrices construct and added a paragraph to
introduce the JSON example of the models (in Section 7)

> - For YANG model: converted "ltp" from configurable parameter to

leafref type; added references for imported modules.

> - Editorial: affiliation changes for a co-author; Compliant with five

front page authors' list.

As I said of -03, rather short on references and some that are seem

Look, for example, at


to see the sort of level of reference that a YANG module benefits from.

YL>> It will be good to be specific on which references are wrong and
what needs to be added.

Several of the existing references should be Normative, according to
YANG Guidelines.

YL>> Again, can you point which ones you think Normative?

You have

       import ietf-te-types { prefix "te-types";

           reference"I-D.ietf-teas-yang-te-types: Traffic Engineering

but in the list of prefixes, always a good thing to have, is

      | te-types| ietf-te-types  | [TE-Tunnel]     |

while the I-D References has

   [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic

             Engineering Tunnels and Interfaces", work in progress:


which looks like a mismatch.

YL>> Yes, you're right. The reference should be TE-type as TE-type was
separated out from TE-tunnel model. Will correct this in the revision.

VN is expanded in the text but I think needs expanding in the Title of
the I-D and in the YANG module; others need expanding on first use;
L3SM,  L2SM  and L1CSM

YL>> OK. Agreed.

And I think you should provide a reference for VN up front, something
along the lines of "For more information on Virtual Networks, see

in the Introduction, first paragraph. (I don't think that RFC8453 is a
brilliant reference for VN but I cannot find a better one).

YL>> Agree. Will add the VN reference up front.

Tom Petch

> Thanks.

> Young & Dhruv


> -----Original Message-----

> From: Teas [] On Behalf Of

> Sent: Friday, June 14, 2019 1:28 PM

> To:

> Cc:

> Subject: [Teas] I-D Action: draft-ietf-teas-actn-vn-yang-05.txt



> A New Internet-Draft is available from the on-line Internet-Drafts


> This draft is a work item of the Traffic Engineering Architecture and

Signaling WG of the IETF.


>         Title           : A Yang Data Model for VN Operation

>         Authors         : Young Lee

>                           Dhruv Dhody

>                           Daniele Ceccarelli

>                           Igor Bryskin

>                           Bin Yeong Yoon

> Filename        : draft-ietf-teas-actn-vn-yang-05.txt

> Pages           : 56

> Date            : 2019-06-14


> Abstract:

>    This document provides a YANG data model generally applicable to


>    mode of Virtual Network (VN) operation.