Re: [netmod] 6991bis: address-with-prefix-length

Ladislav Lhotka <lhotka@nic.cz> Thu, 25 April 2019 08:31 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350E61200E5 for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 01:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oRMgVmgCWTQF for <netmod@ietfa.amsl.com>; Thu, 25 Apr 2019 01:31:33 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 364BC120075 for <netmod@ietf.org>; Thu, 25 Apr 2019 01:31:33 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 81ADA1820414; Thu, 25 Apr 2019 10:31:54 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 4400E1820408; Thu, 25 Apr 2019 10:31:36 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Per Hedeland <per@hedeland.org>
Cc: netmod@ietf.org
In-Reply-To: <ff7ac95a-3544-5485-c9d6-ff2b57ecf5cd@hedeland.org>
References: <10d3413c-df96-6e7d-df82-5542bb02348d@spritelink.net> <20190401161321.seiodlfsmjjvjcp5@anna.jacobs.jacobs-university.de> <699d2c10-9b08-97f1-69d9-f66e3a83c643@spritelink.net> <20190417192013.zdhz4e5fwakm3x4a@anna.jacobs.jacobs-university.de> <048ecdb8-759e-2905-11a8-4c1caedc9371@spritelink.net> <20190417195437.gpnvh6woidqkkqtt@anna.jacobs.jacobs-university.de> <874l6vsqvi.fsf@nic.cz> <4ef7deb6-9904-6ce1-5b84-4cd18a48256d@spritelink.net> <9ffbaa76105f00cc57bf071d432299e55f024544.camel@nic.cz> <ff7ac95a-3544-5485-c9d6-ff2b57ecf5cd@hedeland.org>
Mail-Followup-To: Per Hedeland <per@hedeland.org>, netmod@ietf.org
Date: Thu, 25 Apr 2019 10:31:13 +0200
Message-ID: <87a7gewkoe.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hnxIm3zF1gABuKqWWOirOS5ySp4>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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 Apr 2019 08:31:36 -0000

Per Hedeland <per@hedeland.org>; writes:

> On 2019-04-18 10:41, Ladislav Lhotka wrote:
>> On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
>>>
>>> On 2019-04-18 09:40, Ladislav Lhotka wrote:
>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; writes:
>>>>
>>>>> On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote:
>>>>>> I wonder though, isn't ipX-address-and-prefix-length the clearer name,
>>>>>> or if
>>>>>> we do want to shorten then ipX-address-and-plen. I think Martin stated
>>>>>> the
>>>>>> case for ipX-address-and-prefix but that is IMHO not the way this is
>>>>>> typically perceived by people.
>>>>>>
>>>>>> 1.2.3.4/24
>>>>>> ^^^^^^^----- ipv4 address
>>>>>>          ^^^-- ipv4 prefix length
>>>>>>
>>>>>> now, taking the prefix-length you know that 1.2.3 is the prefix but does
>>>>>> that mean the above is an IPv4 address and a prefix? Or is it just that
>>>>>> you
>>>>>> can infer the prefix from the above? It's just different ways of looking
>>>>>> at
>>>>>> it. My experience tells me ipX-address-and-prefix-length is the clearer
>>>>>> way
>>>>>> of conveying what this is.
>>>>>>
>>>>>
>>>>> I guess this is somewhat subjective. The prefix length is the number
>>>>> used to convey what the prefix is. So you are effectively defining an
>>>>> address and the prefix that this address belongs to. ;-)
>>>>
>>>> Strictly speaking, what is being defined by the number is a subnet mask.
>>>
>>> Heh, amazing how something so binary can turn out to be so subjective ;)
>>> This sort of turns into philosophical questions and I'm not sure we need
>>> to straighten it all out. I'd still call the prefix-length the
>>> prefix-length. It directly maps to the typical subnet mask
>>> representation and as you say, they can be thought of as the same thing.
>>>
>>> Does this mean you prefer ipX-address-and-subnet-mask? Because I think
>> 
>> No.
>> 
>>> that when someone reads that they are going to expect a value that looks
>>> like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still
>>> think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is
>>> the better name :)
>>>
>>>
>>>>> Given that we already have ip-prefix (which does as well use a prefix
>>>>> length to convey what the prefix is), it seems ip-address-and-prefix
>>>>> is more consistent with the existing RFC 6991 definitions. Being
>>>>> consistent with what we have was the main reason for me to prefer
>>>>> ip-address-and-prefix.
>>>>
>>>> I am not in favour of adding this type. Having ip-prefix next to
>>>> ip-address-and-prefix is confusing.
>>>
>>> Confusing or not, they are NOT interchangeable and actually do different
>>> things, which is why both are needed. There's plenty of precedence to
>> 
>> I actually agree with you. It is a historical accident that these two different
>> things got mixed up (and some vendors contributed to this). I would argue that
>> 
>> - IP prefix is a set of IP addresses, and as such can be thought of as a single
>> entity.
>> 
>> - IP address and subnet mask/prefix are two separate things, the latter being an
>> instruction for routing to *other* destination addresses.
>
> Agreed - except the not entirely minor nit that the thing after the
> "/" is not a prefix but a *prefix-length*. Another way of putting it

Yes, you are right, mea culpa.

> is that the IP address is a property of an interface, while the
> prefix-length or subnet mask is a property of the network that an
> interface is connected to.
>
> So this would clearly be two separate values "bundled" into one, and
> despite the similar syntax, it is radically different from the
> existing ip*-prefix types, which really do represent a single value -
> as Kristian pointed out earlier in the thread, the value is the
> initial N bits of a set of IP addresses - i.e. a prefix, as the name
> says.
>
> Thus if these types should be added, I don't think there is any reason
> to have a naming that is "consistent" with the existing ip*-prefix
> types - rather the naming should highlight the difference. And since
> the two values given are an IP address and a prefix-length, the
> natural choice would be ip*-address-and-prefix-length.
>
> Using ip*-address-and-prefix would be both inaccurate (neither of the
> two values is a prefix, although they can of course be combined to
> compute a one) and IMHO confusing due to the similarity in naming of
> the existing ip*-prefix types.
>
> If ip*-address-and-prefix-length is considered too verbose/clunky
> (although I don't know why this matters for a type name), a reasonable
> shorter form could IMHO be ip*-address-and-length - the prefix-length
> is of course a length, but it is not a prefix. Kristian's
> ip*-address-and-plen is of course even shorter, and could be
> considered to have more information, but I believe we generally try to
> avoid at least non-obvious abbreviations in the YANG modules.
>
>>> this, like postgresql has data types (cidr and inet) that map exactly to
>>> this behaviour, i.e. both store something that looks like an IP address
>>> and a prefix-length but one (cidr for pg) forces bits in host portion to
>>> be set to all 0. Python ipaddress has the same with IPv4Address and
>>> IPv4Interface.
>>>
>>>
>>>> Moreover, the most natural use for
>>>> this type would be the address specification in the "ietf-ip" module,
>>>> but we already have two leaves there: ip and prefix-length.
>>>
>>> Like I said in another mail, I think it is nice if these common
>>> datatypes become used by vendors and implementors. Many use proprietary
>> 
>> That's fine, but we can also define a *grouping* of IP address and subnet prefix
>> length. And if we stick to the leaves "ip" and "prefix-length", this grouping
>> can be used in the next revision of RFC 7277. This would be my preferred
>> solution.
>
>  From a data modelling perspective, having separate leafs for separate
> values should be the natural choice, and I don't think anyone is
> suggesting that the "bundled" type, if added, should be used in e.g.
> RFC 7277. A grouping could be nice, but it is still two separate
> leafs.

Yes, and it is IMO how it should be. As Martin pointed out, complicated
lexical representations are difficult to deal with, e.g. in XPath
expressions.

>
> This is no solution to Kristian's problem, which as far as I
> understand is about having a YANG model for existing devices that
> already *use* the "bundled" type, i.e. it "needs" to be a single leaf
> in the YANG module.

I doubt this is a real problem - a netconf/restconf server backend can
easily translate the two separate leaves into a single string if
necessary. Backends on other devices may well need to use the IP
address and mask separately.

Lada

>
> Whether this need is enough motivation to actually add these types to
> ietf-inet-types I don't really know. There is no real cost in doing it
> per se, but it could have the negative consequence that it is taken as
> an encouragement/"blessing" to use these types when writing new
> modules that *don't* "need" to use them. Bad from a data modelling
> perspectve, and bad for the operational reasons that Martin gave an
> example of while I was writing this. But maybe the 'description'
> statement could warn against this.
>
> --Per

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67