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

Martin Bjorklund <mbj@tail-f.com> Tue, 23 April 2019 10:55 UTC

Return-Path: <mbj@tail-f.com>
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 E938212041A for <netmod@ietfa.amsl.com>; Tue, 23 Apr 2019 03:55:06 -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 MR3ep4Cv1lXo for <netmod@ietfa.amsl.com>; Tue, 23 Apr 2019 03:55:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38A74120045 for <netmod@ietf.org>; Tue, 23 Apr 2019 03:55:04 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id DBD051AE02C9; Tue, 23 Apr 2019 12:55:00 +0200 (CEST)
Date: Tue, 23 Apr 2019 12:55:03 +0200 (CEST)
Message-Id: <20190423.125503.1821955933546060158.mbj@tail-f.com>
To: kristian@spritelink.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <ee598735-7853-fa64-1c26-80200e07d871@spritelink.net>
References: <20190418120353.gslhfbdic3tuyqu6@anna.jacobs.jacobs-university.de> <20190418.141843.1973570958718557899.mbj@tail-f.com> <ee598735-7853-fa64-1c26-80200e07d871@spritelink.net>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/4L4ODTobguJKtzUuM0VHgw0qr_g>
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: Tue, 23 Apr 2019 10:55:07 -0000

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.

> 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.

> >> 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


> Or if we are dealing with time, then a class that understands leap
> years, leap seconds, time zones etc can be fairly useful so you don't
> have to fall in any of those pitfalls.
> 
> I don't think we choose a format or representation in our YANG models
> primarily to suit the algorithmic needs of a computer program, in that
> case an IPv4 address would just be a uint32 and not the dotted quad
> format we have today.
> 
> 
> >  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.  So the split model
would have a leaf "ip-prefix: 1.2.3.0/24", which can be compared.

> 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>"?

If it is the former, I agree.  There exist functions that can handle
this format.



/martin