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

Kristian Larsson <kristian@spritelink.net> Fri, 26 April 2019 12:20 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 57046120091 for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 05:20:01 -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 aor6MAO6deY9 for <netmod@ietfa.amsl.com>; Fri, 26 Apr 2019 05:19:57 -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 51FCB120045 for <netmod@ietf.org>; Fri, 26 Apr 2019 05:19:56 -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 1819D3F5C3; Fri, 26 Apr 2019 14:19:52 +0200 (CEST)
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
References: <20190418120353.gslhfbdic3tuyqu6@anna.jacobs.jacobs-university.de> <20190418.141843.1973570958718557899.mbj@tail-f.com> <ee598735-7853-fa64-1c26-80200e07d871@spritelink.net> <20190423.125503.1821955933546060158.mbj@tail-f.com>
From: Kristian Larsson <kristian@spritelink.net>
Message-ID: <9178ea41-fa46-f474-5bd0-eae9bcc02fa4@spritelink.net>
Date: Fri, 26 Apr 2019 14:19:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190423.125503.1821955933546060158.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mFVI6ZJ7V8APeGltlk1hCTzF1Zk>
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: Fri, 26 Apr 2019 12:20:01 -0000


On 2019-04-23 12:55, Martin Bjorklund wrote:
> Kristian Larsson <kristian@spritelink.net> wrote:
>>
>>
>> On 2019-04-18 14:18, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>> On Thu, Apr 18, 2019 at 10:41:11AM +0200, Ladislav Lhotka wrote:
>>>>>>>
>>>>>>> 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.
>>>>
>>>> I think we should be pragmatic. There are other common types that are
>>>> in fact constructed out of simpler types, date-and-time is a prime
>>>> example of a type constructed out of a date value and a time value.
>>> I think that date-and-time represents one thing - a single point in
>>> time.
>>
>> Convenient for users to enter a single point in time in terms of year,
>> month, day, hours, minutes and seconds, perhaps. But not as convenient
>> for a program that needs to compare two date-and-times.
> 
> Actually, *comparing* works quite ok, but calculating diff is not as
> easy.

By relying on the lexical order? Time zone is at the end so it will 
probably mess things up. Maybe that's why you said only *quite* ok.

Speaking of time-zone, shouldn't that be modeled as a separate leaf?

I think you could probably have a conversation around the combination or 
split of time / time-zone rather similar to the conversation we are 
having here about the combination or split of address / prefix-length.


>> Clearly for a
>> program comparing times against each other we must represent a point
>> in time as the number of vibrations of cesium since an arbitrarily
>> chosen epoch.
> 
> We do have yang:timeticks as well.  In some cases that's a better type
> than yang:date-and-time.

In some cases it might be better to have a ip*-address-and-prefix-length 
type than two separate leaves ;)


>>>> is sometimes convenient to treat something that is in fact constructed
>>>> as an atomic value.
>>> Convenient for users that enter these values, perhaps.  But not as
>>> convenient for a program (or a filter) that needs one of the combined
>>> values.
>>
>> Really? Are you using a text representation of IP addresses when you
>> handle them in your program?
>>
>> If you are to deal with IP addresses, prefixes etc in a robust way in
>> your program, you need an internal datatype that understands what an
>> address is - it needs to handle it as bits and massage it to any other
>> presentation you want. It needs to understand relevant comparisons and
>> operations, like is prefix A contained in prefix B?
> 
> I agree.  Note that I wrote *filter* above.  It also extends to
> must/when expressions.  The problem is that these mechanisms use
> XPath, and XPath is quite limited when it comes to "understanding"
> types.  I even wrote a (now expired) draft with a proposed solution:
> https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00

I can see how it is challenging with XPath but it seems equally as 
challenging with a combined leaf as with split leaves.

I think you were trying to argue for how it is beneficial to have split 
leaves, one for address and another for mask/prefix-length, as it makes 
filtering easier. I don't think you've shown that.


>>>   For example, suppose I want to find all entries with a given
>>> prefix; that is non-trivial with a combined ip-address-and-prefix
>>> type.
>>
>> This seems like a very weird example since it doesn't support your
>> case; it is not easier with two separate leaves!?
>>
>> The alternative to using ip-address-and-prefix-length would be to use
>> two leaves; one for the address and the other for the subnet mask /
>> prefix-length.
>>
>> combined:
>> ip-address-and-prefix-length: 1.2.3.4/24
>>
>> split:
>> address: 1.2.3.4
>> prefix-length: 24
>>
>> Say we have another interface with address '1.2.3.5' (prefix-length 24
>> still). In what way is it easier to determine these are part of the
>> same IP prefix / subnetwork by having the values split in two leaves?
> 
> As have been said before in this thread, it is not an address and a
> prefix length, it is an address and a prefix.

There are multiple opinions on what "it is" in this thread. 
authoritatively restating your opinion does not help. Juergen called 
this "what goes in" vs "the meaning".

Perhaps easier to agree on, is the information that is contained, which 
is a superset of "what goes in" and "the meaning"

1.2.3.4/24
^^^^^^^ ----- address
         ^^ -- prefix-length
^^^^^ + ^^ -- prefix

24 is a prefix-length and it is in there. I'm fine with anyone claiming 
that there is "prefix information" contained within 1.2.3.4/24, just as 
there is an address and a prefix-length in there but I think claiming, 
as you did, that there is no prefix-length in there is patently false.

The representation of a prefix includes a prefix-length so I think your 
statement is incorrect as it contradicts itself.

Since you are adamant about the definition I suppose you had no part in 
the creation of tailf:ipv4-address-and-prefix-length or it would have 
been called ipv4-address-and-prefix!? Or maybe it wouldn't have existed 
at all.


> So the split model
> would have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.

No, it would not. The split model is what is in RFC7277/8344, which you 
wrote, and there is no ip-prefix in that model so I don't know why you 
would say that the split model would have it.

>> There is no text operation that can easily do this for us - we need to
>> parse the values with some class / type in our programming language
>> that helps us make this comparison so in what way is
>> ip-address-and-prefix-length worse?
>>
>> Let us look at some examples how this is typically done. Again,
>> postgresql has the 'inet' type. From the docs:
>>
>> "The input format for this type is address/y where address is an IPv4
>> or IPv6 address and y is the number of bits in the netmask. If the /y
>> portion is missing, the netmask is 32 for IPv4 and 128 for IPv6, so
>> the value represents just a single host. On display, the /y portion is
>> suppressed if the netmask specifies a single host."
>>
>> It wants it combined, which means the two leaves need to be formatted
>> into something that looks like 1.2.3.4/24.
>>
>> Python ipaddress.IPv4, from example:
>>
>>    interface = IPv4Interface('192.0.2.5/24')
>>
>> Same thing. Rust ipaddress? Same thing. Go net? Same. Our internal
>> classes that compute IP addressing? Same thing. It seems most of the
>> datatypes that natively handle this kind of information takes a text
>> format like 1.2.3.4/24 as input (and not as separate fields), which is
>> what is being suggested we have a datatype for.
> 
> Is your point that there exist libraries that _can_ handle
> "<addr>/<plen>", or are you suggesting that it is problematic to have
> separate objects b/c libraries _only_ handle "<addr>/<plen>"?

Neither, really.

You suggested that a combined type is worse from a program perspective 
and use a filter example to prove it.

I show how:
- filtering is equally non-trivial with two separate leaves (the leaf 
you want to filter on doesn't exist)
- you need to use some ip address library to parse and filter with
- that probably rules out any XPath filter
- most such ip addressing libraries actually use the combined form and 
not separate leaves, so if anything a slight convenience factor to the 
combined form

    kll