Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

Alan Davey <> Fri, 13 May 2016 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C32112B01A; Fri, 13 May 2016 07:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id plizPe6fslW9; Fri, 13 May 2016 07:37:48 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D728012B013; Fri, 13 May 2016 07:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6p+700LHm+ljDr4NEGU9TDgivf89HYfvLLTpj62WRTc=; b=faXWe2wFqBlE/M9Db1Cg3aGSjg30wZSaZjd8xdJpiw/EamB5eWwTC7hc60XcRAbU7mgZ9KlHe4e/BgqS3AWVxpdOJPH8TlSfEJsRJOVjq8LEK8qgoyZcgvy1RH0rEF9pRW8wLNJ4WQiKTLeX1CQzmscN+i8T79R/BPG98kdgBfo=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.492.11; Fri, 13 May 2016 14:37:26 +0000
Received: from ([]) by ([]) with mapi id 15.01.0492.019; Fri, 13 May 2016 14:37:26 +0000
From: Alan Davey <>
To: "Acee Lindem (acee)" <>, "t.petch" <>, "Derek Man-Kit Yeung (myeung)" <>, "" <>
Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts
Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NAANR+BoQAqfv2AAACIaOA=
Date: Fri, 13 May 2016 14:37:26 +0000
Message-ID: <>
References: <> <> <> <> <> <> <01f101d1ac75$8fd66a80$> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-ms-office365-filtering-correlation-id: efa2dee7-8f48-4612-4fc0-08d37b3c1acf
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1058; 5:x3r2A0KA2tOOsxdspZtNyl48SJdkQrW8WjuD6WRD+A1zoKRFMV0H2upuHNvmDEShhSTXVDvVdPF3HWBmIvaU0EORCWYM1yD5IZ6vUamwj2Ik72hqFSuQwzxnwlwFe6d8CBHPLULNLaUruZYdzU8i6A==; 24:v1TIhBZtZNm6C3hWofuXuu1lBi4qYESnCLxoqjIZCXrSr9FZZqJFAnX5TcE+cb9yJj8cvLmRZzdE+X6TJaSJDcZZo8uG9jpDf5kRaQNvJNw=; 7:LfFEC2qvQ6wRk7XwkOiA/7359V7EHWCK0dnHceTO9bc60ESXe+1uGFXIk42uRhrnV7wT1kxR3IafDsabePvAV6yP5JxP53Q2RMWhH2ZVFnLzv4VBKwYAg8TzxtCadKqawIzWtEhBpPSVSuHz1pvVY8gFG7guwGKgtsN8K+5WEvwgmwG67a40iMBiF6rq37t5
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1058;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0201MB1058; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1058;
x-forefront-prvs: 0941B96580
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(76104003)(92566002)(5008740100001)(99286002)(76576001)(93886004)(5003600100002)(5002640100001)(33656002)(19580405001)(8676002)(345774005)(9686002)(4326007)(19580395003)(87936001)(76176999)(77096005)(50986999)(2900100001)(2950100001)(10400500002)(81166006)(2906002)(86362001)(54356999)(15975445007)(74316001)(3280700002)(8936002)(1220700001)(5004730100002)(586003)(6116002)(11100500001)(102836003)(3846002)(66066001)(189998001)(5001770100001)(230783001)(122556002)(3660700001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1058;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 14:37:26.5545 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1058
Archived-At: <>
Cc: OSPF WG List <>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 May 2016 14:37:50 -0000

Hi Tom and Acee

Thank you for getting back to me.  I understand that an "interface" is identified by its name.  My doubt is about how OSPFv2 configuration defined for an "interface" is mapped to an internal OSPFv2 interface object that is indexed on IP address (as per RFC 4750).  Perhaps you could let me know what you think.

In more detail, consider the case where one interface is assigned multiple IP addresses.  The OSPFv2 protocol considers these to be separate networks (as per RFC 2328, section 1.2, for example).  If the OSPFv2 configuration is defined per interface, is that configuration applied to all of the separate OSPFv2 interfaces or to one of them?  If to one of them then how is that one selected?


-----Original Message-----
From: Acee Lindem (acee) [] 
Sent: 13 May 2016 15:02
To: t.petch <>; Alan Davey <>; Derek Man-Kit Yeung (myeung) <>;
Cc: OSPF WG List <>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts

Hi Tom, 

On 5/12/16, 1:41 PM, "OSPF on behalf of t.petch" < on behalf of> wrote:

>----- Original Message -----
>From: "Alan Davey" <>
>To: "Derek Man-Kit Yeung (myeung)" <>; 
>Cc: "OSPF WG List" <>
>Sent: Wednesday, May 11, 2016 5:40 PM
>Hi Derek
>A question about the key for OSPF interfaces in the Yang draft.  Please 
>let me know what you think.
>The background is that the Management Information Base definitions 
>define indices for OSPF interfaces as follows.
>-          For OSPFv2, RFC 4750 defines the index as ospfIfIpAddress,
>-          For OSPFv3, RFC 5643 defines the index as ospfv3IfIndex,
>However, in the OSPF Yang draft, the key is defined as "interface", 
>which I believe is a name of the interface.
>How does "interface" map to the indices defined in RFCs 4750 and 5643?
>It doesn't (IMHO).  You have two lists of interfaces in this I-D
>container interfaces { description "All interfaces."; list interface { 
>key "interface"; description "List of OSPF interfaces.";
>container interfaces { description "All interfaces in the area.";  list 
>interface { key "interface"; description "List of OSPF interfaces.";
>both keyed on 'interface' (which is two separate lists so two separate 
>'interface' leaf, different sets of key objects.).

These are basically the same lists - one is for operational state and the other is for configuration.

>Both are defined as
>     type if:interface-ref;
>and the if: harks back to
>     import ietf-interfaces {prefix "if"; and ietf-interfaces is in 
>RFC7223 where interface-ref is defined as
>"   An interface is identified by its name, which is unique within the
>   server.  This property is captured in the "interface-ref" and
>   "interface-state-ref" typedefs, which other YANG modules SHOULD use
>   when they need to reference a configured interface or operationally
>   used interface, respectively."
>So both lists are keyed on a name which is unique within the server and 
>can be anything, such as 'lan0' or 'fast-ethernet-23/7' or 
>'hotplug23/6/15' or... It all depends; names may be dictated by the 
>hardware with no choice, or they may be dictated by the software to 
>compliant hardware or ...
>Underlying this is the thought that we have no good definition of an 
>interface, one that works across all protocols and other aspects of a 
>configuration; an interface is like a blob of jelly and pinning it down 
>to be a name is about as good a grasp of it as we will get (IMO).



>Tom Petch
>OSPF mailing list