Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]

Ladislav Lhotka <lhotka@nic.cz> Thu, 25 February 2016 13:08 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F21A930A; Thu, 25 Feb 2016 05:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.657
X-Spam-Level:
X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] 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 k70TvWC6vhUX; Thu, 25 Feb 2016 05:08:09 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8731A9301; Thu, 25 Feb 2016 05:08:08 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02] (unknown [IPv6:2001:718:1a02:1:e195:2630:b6d8:3b02]) by mail.nic.cz (Postfix) with ESMTPSA id 8CFA3181672; Thu, 25 Feb 2016 14:08:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1456405686; bh=5CcU6eRMfHWLpAavjvhxjT3zrEjwD8j6BRrIpgwmnyI=; h=From:Date:To; b=WjXKCalAho3WMT5MpvhretNuAu3ZGINfZG5DeHqslFo517NiJwQ94ZBCVA9rHeE/3 8V5+PgOTVcBv/SWYmtoexCgkxQ073nxYZGWVvkTOwT9NysBqHz5iRUxLzoP84UkbDo ThIakN5+Exocfniwqk2ugQ6uv/0fFZ8Wo2VaImjQ=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <56CEF681.5040306@cisco.com>
Date: Thu, 25 Feb 2016 14:08:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C8F95D6-6F20-4E69-B7B3-2176C8F528D9@nic.cz>
References: <03b801d16382$b01e9e70$105bdb50$@olddog.co.uk> <56BA76C1.2040009@bogus.com> <56C01065.1000804@pi.nu> <56C1F076.5070708@innovationslab.net> <56C29512.3030401@pi.nu> <56C314FA.40209@innovationslab.net> <059901d168b9$15c92fc0$415b8f40$@olddog.co.uk> <56C32361.8050901@innovationslab.net> <56CEF681.5040306@cisco.com>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/yoAFDRtsH27H1KgDuKr8amIC8fw>
X-Mailman-Approved-At: Thu, 25 Feb 2016 05:31:28 -0800
Cc: Santosh Esale <sesale@juniper.net>, joel jaeggli <joelja@bogus.com>, rtg-ads@ietf.org, Ross Callon <rcallon@juniper.net>, Adrian Farrel <adrian@olddog.co.uk>, "Sowmya Krishnaswamy (sowkrish)" <sowkrish@cisco.com>, Xufeng Liu <xufeng.liu@ericsson.com>, Brian Haberman <brian@innovationslab.net>, NETMOD WG <netmod@ietf.org>, George Swallow <swallow.ietf@gmail.com>, jescia.chenxia@huawei.com, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, int-ads@ietf.org, "Kamran Raza (skraza)" <skraza@cisco.com>, Jeff Tantsura <jeff.tantsura@ericsson.com>, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, Adrian Farrel <afarrel@juniper.net>, Loa Andersson <loa@pi.nu>, ops-ads@ietf.org
Subject: Re: [netmod] Consistency in YANG for Router IDs [Was: WG Chair comments on draft-raza-mpls-ldp-mldp-yang-02]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2016 13:08:13 -0000

Hi Benoit,

this was discussed a while ago in this thread:

https://mailarchive.ietf.org/arch/msg/netmod/TehrMAboX-cMmmX537rs81DNl3I

tl;dr: The WG decision then was to introduce a new type in ietf-inet-types, namely "dotted-quad", that explicitly does NOT have the semantics of an IPv4 address - it is an uint32 number that's expressed in the dotted quad format, which is what most router platforms accept as routerID via CLI.

Lada

> On 25 Feb 2016, at 13:41, Benoit Claise <bclaise@cisco.com> wrote:
> 
> Dear all,
> 
> Sorry for the delay (mix of vacation and business travel). 
> 
> Let me try to summarize the situation as I see it:
> - From the routing RFCs, BGP Identifier, OSPF router ID, TE identifier, and LSR identifiers are all an unsigned integers.
> - We need consistency for the router ID and identifier in YANG leaf/typedef
> - The OSPF MIB module has defined
> RouterID ::= TEXTUAL-CONVENTION
>        STATUS       current
>        DESCRIPTION
>           "A OSPF Router Identifier.
>            Note that the Router ID, in OSPF, has the same format
>            as an IP address, but identifies the router independent
>            of its IP address."
>        SYNTAX       IpAddress
> 
> 
>   ospfRouterId OBJECT-TYPE
>        SYNTAX       RouterID
>        MAX-ACCESS   read-write
>        STATUS       current
>        DESCRIPTION
>           "A 32-bit integer uniquely identifying the
>           router in the Autonomous System.
>           By convention, to ensure uniqueness, this
>           should default to the value of one of the
>           router's IP interface addresses.
> 
> As Adrian mentioned: it is NOT an IP address but the MIB module uses the notational formatting of n IP address for display purposes.
> - An IPv4 address as OSPF router ID doesn't make sense in an IPv6 environment
> 
> Based on this, I believe that:
> - We must not associate an IP address semantic with the router ID
> - Based on Brian's feedback (which I agree with) "As long as the YANG module does not specify a format that makes the routerID display like an IPv4 address", it was probably a mistake to have defined RouterID as IpAdress in OSPF MIB module.
> - Interestingly, https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20 contains:
> 
>      grouping router-id {
>        description
>          "This grouping provides router ID.";
>        leaf router-id {
>          type yang:dotted-quad;
>          description
>            "A 32-bit number in the form of a dotted quad that is used by
>             some routing protocols identifying a router.";
>          reference
>            "
> RFC 2328
> : OSPF Version 2.";
>        }
>      }
> 
> This should be an uint32 number.
> - An union-based solution is a bad compromise
> From draft-raza-mpls-ldp-mldp-yang-02
>              leaf lsr-id {
>                type union {
>                  type yang:dotted-quad;
>                  type uint32;
>                }
>                description "LSR ID.";
> 
> 
> 
> Since the question was asked: as AD, I would support uint32 everywhere.
> 
> Now, practically, how to move forward? 
> - Either all drafts reference draft-ietf-netmod-routing-cfg-20 (with the uint32 modification),
> - Or you create a "Common Routing YANG Data Types", similarly to RFC 6991 including the router IDs. I see already many typedef in draft-raza-mpls-ldp-mldp-yang-02
> - Or you define you own types in your own draft
> 
> But, if we have agreement on the uint32, let's document this now somewhere/somehow, and let's not revisit this on regular basis (yes, I see it coming...)
> A few lines of explanation in the draft would already help for example, in an operational section, explaining to people the mapping of the MIB OSPF RouterID to the YANG object
> 
> Regards, Benoit
>> Hi Adrian,
>> 
>> On 2/16/16 7:53 AM, Adrian Farrel wrote:
>> 
>>> Hi Brian,
>>> 
>>> I said I wasn't going to participate in this discussion :-)
>>> 
>> Nice try. ;)
>> 
>> 
>>>>> I should not respond to questions that I don't fully understand, but:
>>>>> 
>>>>> the BGP Identifier is an unsigned integer
>>>>> the OSPF router ID is an unsigned integer
>>>>> 
>>>> I assume the above is based on the YANG definition of OSPF routerID. RFC
>>>> 4750 says the routerID is an IPv4 address. Is that an issue?
>>>> 
>>> To quote from 4750...
>>> 
>>> RouterID ::= TEXTUAL-CONVENTION
>>>        STATUS       current
>>>        DESCRIPTION
>>>           "A OSPF Router Identifier.
>>>            Note that the Router ID, in OSPF, has the same format
>>>            as an IP address, but identifies the router independent
>>>            of its IP address."
>>>        SYNTAX       IpAddress
>>> 
>>> So it explicitly says it is NOT an IP address but the MIB module uses the notational formatting of n IP address for display purposes.
>>> 
>>> I think this is done because the router ID is often chosen to be an IP address of the router, and because it is easier for humans to deal with a.b.c.d where each element is a 3-digit number less than 256, than it is to manage a single number in the range 0 to 2^32 -1.
>>> 
>>> 
>> The above is the textual convention, whereas the following is the actual
>> OSPF routerID...
>> 
>>   ospfRouterId OBJECT-TYPE
>>        SYNTAX       RouterID
>>        MAX-ACCESS   read-write
>>        STATUS       current
>>        DESCRIPTION
>>           "A 32-bit integer uniquely identifying the
>>           router in the Autonomous System.
>>           By convention, to ensure uniqueness, this
>>           should default to the value of one of the
>>           router's IP interface addresses.
>> 
>> So the MIB actually says the default is to use an IPv4 address...
>> 
>> All that being said, my point was further along where I said:
>> 
>> 
>>>> I am not concerned with what the operator will choose as his/her
>>>> routerID value. I am concerned with what format options will be
>>>> associated with the routerID in the yang module. As long as the format
>>>> options does not allow display in dotted decimal notation, I am fine.
>>>> 
>> As long as the YANG module does not specify a format that makes the
>> routerID display like an IPv4 address, I am fine.
>> 
>> Brian
>> 
>> 
>> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C