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

"Acee Lindem (acee)" <acee@cisco.com> Tue, 17 May 2016 12:04 UTC

Return-Path: <acee@cisco.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 D736E12D881; Tue, 17 May 2016 05:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 rDN2fRMVq8FL; Tue, 17 May 2016 05:04:06 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEB512D150; Tue, 17 May 2016 05:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5296; q=dns/txt; s=iport; t=1463486645; x=1464696245; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kXjuKVGMpF4/UzhHxStXKkDY4FqVQojm9OL+PLFMuMY=; b=D7E3r1PNp8vkS29aBAQfwpTE6BgHgyBqA514KtDonRKopP26d7E3JKh+ TMd+YHZ4qgrS11QF9XfADRQgroe1GbJUIvSLLtneN14Ey8+p3VS2+0Vbo n2PDx09My07P06iJ6GBaaxnD6qyp0DXvfnyjX7+tGwBh6F13prrZwb78+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BBBAAtCDtX/4kNJK1SCoM3gQNQBrdegg8BDYF2hhECHIEZOBQBAQEBAQEBZSeEQgEBAQQjEUUMBAIBCBUBBAIjAwICAjAUARACBAENBRuIFLF4kXEBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGJcYQRBgsBHAczgkaCWQEEiAOFXIpKAY4egWmET4hhj0EBHgEBQoIGG4FLboZRNn8BAQE
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="274582722"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 May 2016 12:04:04 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4HC44u7026887 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 12:04:04 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 08:04:03 -0400
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.1104.009; Tue, 17 May 2016 08:04:03 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "t.petch" <ietfc@btconnect.com>, Alan Davey <Alan.Davey@metaswitch.com>, "Derek Man-Kit Yeung (myeung)" <myeung@cisco.com>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>
Thread-Topic: [OSPF] draft-ietf-ospf-yang-03 questions and doubts
Thread-Index: AQHRrHYn2XZTM8Zh7Ea9M+xWxcvHEgoPjYmAAiVQNuADX5obgAcESYLgBoJ48NAANR+BoQAqfv2AAACIaOAABMymEQBcakowns4FoA+AACMagA==
Date: Tue, 17 May 2016 12:04:03 +0000
Message-ID: <D3607E64.61138%acee@cisco.com>
References: <C2EE31C852049D499842B19FC01C0804012A72782A@ENFICSMBX1.datcon.co.uk> <D2D8C451.73937%myeung@cisco.com> <CY1PR0201MB1066110895F4C141E7779015F9AF0@CY1PR0201MB1066.namprd02.prod.outlook.com> <D2FDEE96.7531D%myeung@cisco.com> <BN3PR0201MB10597DBA718D60998EA82E0FF9950@BN3PR0201MB1059.namprd02.prod.outlook.com> <BN3PR0201MB10593ECF530B4B73B7EDEA38F9720@BN3PR0201MB1059.namprd02.prod.outlook.com> <01f101d1ac75$8fd66a80$4001a8c0@gateway.2wire.net> <D35B5666.60D24%acee@cisco.com> <BN3PR0201MB1059516477FD53CC451B4CADF9740@BN3PR0201MB1059.namprd02.prod.outlook.com> <00ef01d1ad34$e0e406c0$4001a8c0@gateway.2wire.net> <BN3PR0201MB105993070C1185BA1B2C78D8F9770@BN3PR0201MB1059.namprd02.prod.outlook.com> <01c201d1b021$1b09ee20$4001a8c0@gateway.2wire.net>
In-Reply-To: <01c201d1b021$1b09ee20$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D7D4D9C02C11804490E980F62EC1E93D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/D7qM1ajvDPbnIySNDlaiccbfUyo>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts
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: Tue, 17 May 2016 12:04:08 -0000

<Speaking as a member of the OSPF YANG Design Team>
What we did with the OSPF YANG model was use interface as the key to list
even though OSPFv2 allows configuration by IP subnet. This is consistent
with both OSPFv3 and the interface YANG models in RFC 7223 and RFC 7277.

Thanks,
Acee

On 5/17/16, 5:42 AM, "t.petch" <ietfc@btconnect.com> wrote:

>----- Original Message -----
>From: "Alan Davey" <Alan.Davey@metaswitch.com>
>To: "t.petch" <ietfc@btconnect.com>; "Acee Lindem (acee)"
><acee@cisco.com>; "Derek Man-Kit Yeung (myeung)" <myeung@cisco.com>;
><draft-ietf-ospf-yang@ietf.org>
>Cc: "OSPF WG List" <ospf@ietf.org>
>Sent: Monday, May 16, 2016 9:44 AM
>
>> Hi Tom
>>
>> Thanks for your quick response.  I just want to check that I
>understand your email.  Please let me know if the following is correct
>or not.
>>
>> -  You expect that the NMS would identify an interface by name in all
>cases of protocol configuration, where there is flexibility on what the
>"interface" represents.
>>
>> -  There will only ever be one primary IP address assigned to an
>interface (or zero in the case of unnumbered point to point interfaces).
>>
>> -  There is a set of zero or more secondary IP addresses that may be
>assigned to the interface.
>>
>> -  Only the primary address (or unnumbered interface) would ever have
>OSPF configuration associated with it.  Secondary addresses never have
>OSPF configuration associated.  (As an aside, multicast considerations
>do not preclude running OSPF using a secondary address.)
>>
>> -  I assume that in the case of a non-empty set of secondary
>addresses, the secondary addresses should be advertised by the OSPF
>protocol.  Is this true?
>
>My context is IPv4 (despite my erroneous reference to multicast:-); with
>IPv6, interfaces are expected to have multiple IP addresses and so
>applications must be prepared for that.  With IPv4, the concept came
>late in the day which is why I am uncertain about how much support there
>is thereof.
>
>Using a NMS with NETCONF and the IETF YANG models, then the protocol/DDL
>identifies the interface, whatever that may be, physical, logical (FR
>VC, MPLS LSP, ...) by name; the YANG list is keyed by 'name' which is a
>change in approach from that of the MIB module.  How the NMS presents
>that to the user is up to the NMS (it could be - I don't know - that an
>NMS chooses to use IPv4 addresses because that is what users are
>familiar with).
>
>Secondary addresses I saw first with one router manufacturer and then
>later with others; I would expect most to support them.  The
>implementations I have seen have only one primary.  I have always seen
>secondary addresses as an unsatisfactory solution to addressing issues
>and while they were needed at the time, I would like to think that their
>use has diminished since.  I would look askance at a design that uses
>them in this day and age.  Doubtless they are still around but how
>widespread they are, I don't know.  (I was active in getting them
>included in the YANG model which I do not think that all those involved
>were).
>
>The configuration of OSPF may have an option to advertise or to suppress
>the advertisement of secondary addresses in the LSA.
>
>Whether or not a secondary address can be used for other purposes in
>OSPF, such as DR or BDR, I am unsure; something at the back of my mind
>says there is an issue with the use of broadcast by a DR but I cannot
>track down a reference to that.  With the proposed YANG models - if-cfg,
>ip-cfg, ospf - it is feasible to configure a secondary interface in the
>same way as a primary one, should the device support that.
>
>Tom Petch
>
>> Regards
>> Alan
>>
>>
>> -----Original Message-----
>> From: t.petch [mailto:ietfc@btconnect.com]
>> Sent: 13 May 2016 17:31
>
><snip>
>