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

Kristian Larsson <kristian@spritelink.net> Mon, 01 April 2019 21:29 UTC

Return-Path: <kristian@spritelink.net>
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 B0E0C12000E for <netmod@ietfa.amsl.com>; Mon, 1 Apr 2019 14:29:30 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 CcdvHiL2iFMR for <netmod@ietfa.amsl.com>; Mon, 1 Apr 2019 14:29:27 -0700 (PDT)
Received: from Mail1.SpriteLink.NET (Mail1.spritelink.net [195.182.5.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2CC120033 for <netmod@ietf.org>; Mon, 1 Apr 2019 14:29:27 -0700 (PDT)
Received: from mbp.local (c-bb9de253.014-82-73746f13.bbcust.telenor.se [83.226.157.187]) by Mail1.SpriteLink.NET (Postfix) with ESMTPSA id 315283F439; Mon, 1 Apr 2019 23:29:24 +0200 (CEST)
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, acee@cisco.com, netmod@ietf.org
References: <20190401161321.seiodlfsmjjvjcp5@anna.jacobs.jacobs-university.de> <F1537180-6BF3-40C7-BCFA-3AAE0290AE9D@cisco.com> <A0F7987F-AA67-4A63-8FEE-3B74B5B47CF1@cisco.com> <20190401.192951.1060904547331848297.mbj@tail-f.com> <af1cadb6-a4da-1504-698a-fa8aec463eb8@spritelink.net> <9BD4DA95-38DF-4394-B6EF-D3FAED736DBF@gmail.com>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <7cd09938-332d-f63b-efba-7c628cb3e860@spritelink.net>
Date: Mon, 1 Apr 2019 23:29:23 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <9BD4DA95-38DF-4394-B6EF-D3FAED736DBF@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hojwx5kyIpkOacczE9y7OD0ypFg>
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: Mon, 01 Apr 2019 21:29:31 -0000


On 2019-04-01 22:51, Mahesh Jethanandani wrote:
> 
> 
>> On Apr 1, 2019, at 12:37 PM, Kristian Larsson <kristian@spritelink.net>; wrote:
>>
>>
>>
>>> On 2019-04-01 19:29, Martin Bjorklund wrote:
>>> Hi,
>>> The request was for a combined type that contains both an ip address
>>> *and* a prefix length in one value.  Hence the name
>>> "ip-address-and-prefix-length" :)
>>
>> Right you are, though I'm open to other names but let's first agree on use case / need :)
>>
>>
>>> I know that this type is convenient, esp. if you use it for manual
>>> input, but I wonder if it really is good practice to squeeze two
>>> values into one.
>>
>> Dunno how "manual" has any bearing. This is IMHO just about natural data modeling.
>>
>> You say it's two values but when one can't be used without the other, are they so separated? You can't configure an interface with just an address or just a subnet mask. You need both - they belong together.
> 
> That can be modeled into the data module, I.e. that you have to specify both the address and the prefix length.

I am aware. It wasn't for ip-prefix though, presumably because ip-prefix 
is more natural and so is ip-address-and-prefix-length.


> The reason Martin mentioned two values is because even if they are modeled with a ‘/‘ character, the end system will consume them as two separate values
Not sure if you are arguing against me or just trying to explain :) I 
understand full well how it can be done and I'm saying I've written 
models like that. They are not elegant. Now I want the prettier way to 
do it and preferably with an IETF standardised data type, which is why 
I'm suggesting we add one in 6991bis. Two values or not, they belong 
together and should not exist without the other. The cost of using 
multiple leaves in YANG is quite high so for things that naturally 
belong together I think it's perfectly fine to make a datatype that 
includes the component values. We do it for ip-prefix already. In fact 
you could argue that the normal ipv6-prefix is a compound type since the 
zone is really a separate value from the address. Anyway, similar to how 
ip-prefix makes it easier to work with things likes routes in a routing 
table or how it simplifies the source and destination address matches in 
the ACL RFC we worked on together, an ip-address-and-prefix-length 
datatype will make other things easier which is why I'm suggesting it be 
added.

    kll