[OSPF] draft-ietf-ospf-yang-02 questions and doubts

Alan Davey <Alan.Davey@metaswitch.com> Thu, 08 October 2015 12:50 UTC

Return-Path: <Alan.Davey@metaswitch.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BDC1B335D for <ospf@ietfa.amsl.com>; Thu, 8 Oct 2015 05:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 dSJqReDKWfeQ for <ospf@ietfa.amsl.com>; Thu, 8 Oct 2015 05:50:27 -0700 (PDT)
Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5D61B3363 for <ospf@ietf.org>; Thu, 8 Oct 2015 05:50:26 -0700 (PDT)
Received: from ENFIRHCAS1.datcon.co.uk (172.18.74.33) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 8 Oct 2015 13:50:12 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0248.002; Thu, 8 Oct 2015 13:50:24 +0100
From: Alan Davey <Alan.Davey@metaswitch.com>
To: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: draft-ietf-ospf-yang-02 questions and doubts
Thread-Index: AdEBx7vD5s3ZOYb6QcWXFHL0G85eEw==
Date: Thu, 8 Oct 2015 12:50:23 +0000
Message-ID: <C2EE31C852049D499842B19FC01C0804011A65C395@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.209.34]
Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804011A65C395ENFICSMBX1dat_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Qy9f-3Nb3W78cl2tKveVKAbcXqU>
Subject: [OSPF] draft-ietf-ospf-yang-02 questions and doubts
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 08 Oct 2015 12:50:32 -0000

Folks

I have read draft-ietf-ospf-yang-02 and have some questions and doubts.  Please let me know your thoughts on the following.


-          There are some concepts that appear to be implementation specific. For example, should the following be part of the OSPF Yang definition?


o   admin-distance: this is not an OSPF concept that I am familiar with.  Administrative distance is commonly used for comparing the usability of routes originating from different protocols and not associated specifically with an OSPF instance.


o   nsr: there is no IETF standard for NSR.



o   local-rib: OSPF may be one of a number of routing protocols running on a router and therefore the local RIB is not OSPF-specific.



o   container ldp: should this be part of the OSPF Yang?


-          Conversely, should configuration of IGP shortcut support be added to the Yang definition?


-          There are some options that I would expect to see for the instance-config that are not present.  Are there any plans to add other options?  For example, the following.


o   Configuring the instance as an ASBR.

o   Support for traffic engineering.

o   The ospfRFC1583Compatibility field defined in RFC 4750.


-          The text is OSPFv2-centric in places.  For example:


o   leaf router-id and grouping interface-operation : the description fields references RFC 2328.  Should this also refer to RFC 5340 for the OSPFv3 case?

o   The grouping interface-operation

*  does not include the instance ID

*  dr and bdr leaves have type:ipv4-address.

o   container graceful-restart : description "Enable/Disable graceful restart as defined in RFC 3623."  (Note that the feature graceful-restart does reference RFC 5187, OSPFv3 Graceful Restart.)

o   container te-rid: refers to IPv4 addresses in several places.


-          The TE (Traffic Engineering) configuration is specified within "container mpls".  Is it safe to assume that TE configuration is always mpls-related?  It may be better to make it non-specific about the usage of the TE information.


-          I found the "container stub-router" confusing.  In particular, the different description fields.  For example, I failed to understand the following.

o   "Specific different triggers to enable stub router." for the choice trigger description

o   "Enables maximum metric for non-stub router link" for the presence.

Regards
Alan Davey