IETF Logo Mail Archive

[OSPF] Some doubts about OSPF YANG model.

Yangang <yangang@huawei.com> Sat, 20 August 2016 14:24 UTC

Return-Path: <yangang@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E172512D531 for <ospf@ietfa.amsl.com>; Sat, 20 Aug 2016 07:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.467
X-Spam-Level:
X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 1OIFliMdRAQg for <ospf@ietfa.amsl.com>; Sat, 20 Aug 2016 07:24:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F337112D124 for <ospf@ietf.org>; Sat, 20 Aug 2016 07:24:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPU15374; Sat, 20 Aug 2016 14:24:08 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 20 Aug 2016 15:24:08 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Sat, 20 Aug 2016 22:23:55 +0800
From: Yangang <yangang@huawei.com>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: Some doubts about OSPF YANG model.
Thread-Index: AdH67np442TlrEKJStyWksOPOvPQ9w==
Date: Sat, 20 Aug 2016 14:23:55 +0000
Message-ID: <D496C972D1A13540A730720631EC73418606CB0C@nkgeml514-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.111.246]
Content-Type: multipart/alternative; boundary="_000_D496C972D1A13540A730720631EC73418606CB0Cnkgeml514mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57B86809.0039, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f372eb19966ba9498097f7c603adbef5
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/HK1fcX3DOd_TUfs9w8AIqzHaQh4>
Subject: [OSPF] Some doubts about OSPF YANG model.
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Aug 2016 14:24:14 -0000

Hi,

I am reading the YANG model of OSPF, and I have some doubts. I hope it can provide some help for model standard process.

1. Page 8: There are two leaf: mtu-ignore and prefix-suppression. I think maybe no need define these two leaf in virtual link.

2. Page 9: Similar with the first doubt, do we need "mtu-ignore" in sham-link?

3. Page 9: Maybe there is a mistake in writing. "bfd" leaf should be moved to OSPF BFD model.

4. Page 13: In the notification definition: About the "rx-bad-packet", it is not same as the model, "if-rx-bad-packet". The other, there is similar trap in OSPF MIB. But some EMS/NMS don't handle it because robustness of OSPF can handle it. Sometime, only when some adjacencies are broken, or routes have some problem, the administrator will debug it and find the number of some bad packet counter will be very big, Base on it, the problem can be solved and the service will be restored. I suggest maybe we can provide some counter in OSPF.

5. Page 39: In the container opaque, there are some define about "router-address-TLV", "link-TLV" and some other named TLV, do we need "when" statement?

6. Page 58: About the leaf of "Hello-Interval" and "Dead-Interval". Do we need define the default value? Because this kind of parameter can affect the adjacency establish. Sometime the adjacency maybe cannot be established because the default value is different. Maybe a explicit define is good choice.

7. Page 75: About te-id of MPLS, it should be defined in OSPF model? Or OSPF quote it from MPLS model?

It is all I got.

Yangang.

v2.23.0 | Report a Bug | By Email