Re: [Lsr] Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17

"Acee Lindem (acee)" <acee@cisco.com> Tue, 27 November 2018 22:53 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC93130DC5; Tue, 27 Nov 2018 14:53:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level:
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 R9FXeV2uQJ9f; Tue, 27 Nov 2018 14:53:04 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9563D128CFD; Tue, 27 Nov 2018 14:53:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49900; q=dns/txt; s=iport; t=1543359183; x=1544568783; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mk8FS8B8rphYTndQz75DhK99zgE8Gql4xzSS3uqj3ow=; b=gB4B0JxV8aJRtwAOSOLGpn6wyhJokBaD1xzojFo8FUDnuNpIBMR9IHbJ lUXfq7HbvEatkxTNHJ6llQpn4NACdqLTvDzpolcUGpDAsApP3X8v+z4wh tYcY7j7fSvb3rWR0wULJeVCW4cC1NU8RI56u9whhMe0et45i0DcBleA1M A=;
X-Files: image001.jpg : 1094
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAADGyf1b/5ldJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWBDnZmgQInCoNvlCCCDXyVX3mBZggBAgEBIIRMAhe?= =?us-ascii?q?DASI4EgEDAQECAQECbRwMhTwBAQEBAwUeAggBPRwCAgEGAgcKAwECBgEBAQo?= =?us-ascii?q?OAQYDAgICBRABAwkCDBQJCAEBBAERAQYIgxMBggEPinObUIEviikPBYwIF4F?= =?us-ascii?q?/gRAoH4FOSTWDHgQYgQMRAQgDBwElBgsJBgYKgk4xgiYCiQuFfheGH4UvAzc?= =?us-ascii?q?DhGEJAoYTAWYiihIYgVlNhD4SihWHfYVJh0GDCQIRFIEnNiEnGiNxcBU7KgG?= =?us-ascii?q?CQQmCHheDSoE+iRVBMQEBAQGLPA8XgQiBHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,288,1539648000"; d="jpg'145?scan'145,208,217,145";a="485534798"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2018 22:53:01 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id wARMr13D005068 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Nov 2018 22:53:01 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 27 Nov 2018 17:53:00 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Tue, 27 Nov 2018 17:53:00 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "lsr@ietf.org" <lsr@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Thread-Topic: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Thread-Index: AdSBhYgiLVXk+bRuTn68pWj1+aWyiQFHmleA
Date: Tue, 27 Nov 2018 22:53:00 +0000
Message-ID: <58C71B78-1C6A-4FB5-B64A-7A38628028C1@cisco.com>
References: <576_1542796445_5BF5349D_576_261_1_9E32478DFA9976438E7A22F69B08FF924B7731BE@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <576_1542796445_5BF5349D_576_261_1_9E32478DFA9976438E7A22F69B08FF924B7731BE@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/related; boundary="_004_58C71B781C6A4FB5B64A7A38628028C1ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/aa00YdaqT8UCC50RUogEVHvrNw4>
Subject: Re: [Lsr] Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 22:53:19 -0000

Hey Stephane,
Thanks for the great review – I’ve incorporated most of your comments in the -18 version (just posted). See some inlines.

From: Stephane Litkowski <stephane.litkowski@orange.com>
Date: Wednesday, November 21, 2018 at 5:34 AM
To: "lsr@ietf.org" <lsr@ietf.org>rg>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Subject: Shepherd's review of ietf-ospf.yang and draft-ietf-ospf-yang-17
Resent-From: <alias-bounces@ietf.org>
Resent-To: Derek Yeung <derek@arrcus.com>om>, Yingzhen Qu <yingzhen.qu@huawei.com>om>, Jeffrey Zhang <zzhang@juniper.net>et>, <ingwherchen@mitre.org>rg>, Acee Lindem <acee@cisco.com>
Resent-Date: Wednesday, November 21, 2018 at 5:34 AM

Hi,

Here are some comments I have on the model:

·         The model should use the LSR WG as point of contact and no more the OSPF WG

·         In the feature multi-topology: s/-Topolgy/-Topology

·         In the packet-type typedef: s/database-descripton/database-description.

·         In the container lsa-log description: s/conatiner/container

·         OSPF model has no keychain feature, while ISIS has one. We need to agree on a common way to go.

I went ahead and added a feature to OSPF. It seems we have done this for other options outside the base RFCs.


·         In the container link-tlvs, the link-type is an uint8 , wouldn’t it be better to use an enum to get a description of what is the link type ?

·         Need to expand “af” to ”address-family” everywhere in the model (comments received from Yang doctor in the ISIS model review => ISIS has done this expansion).
I did this but am not so sure this is an improvement 😉


·         Ietf-spf-delay timers use uint16 while ISIS uses timer-value-milliseconds

·         The grouping instance-config has a “uses instance-fast-reroute-state”. It would be better to put it in the instance-state container.

·         The model uses the “ospf-protocol” identity while IS-IS uses just “isis”. We need to find a common way to define the protocol identity name. RIP yang model uses just “rip”, so I suppose OSPF has to align.

·         In the feature “fast-reroute” reference: s/Rereoute/Reroute/

·         The description of the identity “ospf-lsa-type” is strange: “Base identity for OSPFv3 and OSPFv3 Link State Advertisements”. Do you mean just : “Base identity for OSPFv3 Link State Advertisements”
This should be “OSPFv2 and OSPFv3 …” I have updated in -18.


·         It seems that you are using a typedef uint24 for the metric. In IS-IS there is  a metric typedef for this purpose.

·          In the if-state-type, the value 6 is referred as “bdr” while the RFC talks about “backup”. “bdr” works for sure, we just need to agree if we align on RFC naming or common usage naming.

·         In the nbr-state-type, why using “ex-start” instead of “exstart”, again the RFC does not use the “-“.

·         In the packet-type: s/Acknowlegement/Acknowledgement/

·         In the ospfv2-router-link, the type is uint8, would be better to have an enum. Note that this appears multiple times in the model.

·         In the leaf-list attached-router “line 1376”, why using dotted-quad instead of ip-address type ?
These are router-ids which are not necessarily IP addresses.


·         In the grouping area-stat, there are checksum sums that are using int32 type while checksums are using uint32 or some other checksum sums (like in interface-stat) also use uint32. Need to be consistent here.

·         In the grouping interface-physical-link-config, why do you say that it applies to physical interfaces ? Can’t you run OSPF on VLANs ?
By physical, I mean non-virtual. RFC 2328 uses this terminology. I did not change.


·         Please set default values as much as you can (for instance in interface-common-config or interface-physical-link-config or interface-config…)
I’m hesitant to do this since these defaults are non-normative in the RFCs. Can you give an example? I think it is obvious that the absence of a feature means it is not configured.


·         Why do you have interface-physical-link-config and interface-config, what difference do you make between the two ? My point is why there is still so much containers/leaves in the interface-config and why couldn’t we put them in the other groupings or even create additional ones if required.
I’m not sure I disagree with the groupings. There are other possible hierarchies but this seems to work.


·         What is the purpose of some empty groupings that you have created ? like “ospf-config” or “ospf-state”
These are meant to be augmented for top-level config and stats.

Thanks,
Acee



·         In the multi-topology-area-common-config, you are using a limited uint32 type for the default cost while you have defined a uint24 type that you can use. It appears also in area-common-config.

On the draft:

·         In the overview (§1), reference to 7950 does not appear as a link, maybe an XML issue.

·         §2.2: s/The topology container/The “topologies” container

Brgds,


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>  NEW !
mobile: +33 6 71 63 27 50 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>  NEW !
stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>


_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.