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

Martin Bjorklund <> Tue, 23 April 2019 10:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E938212041A for <>; Tue, 23 Apr 2019 03:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MR3ep4Cv1lXo for <>; Tue, 23 Apr 2019 03:55:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38A74120045 for <>; Tue, 23 Apr 2019 03:55:04 -0700 (PDT)
Received: from localhost (unknown []) by (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: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <> <>
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: <>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Apr 2019 10:55:07 -0000

Kristian Larsson <> wrote:
> On 2019-04-18 14:18, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <> 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

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

> 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:
> split:
> address:
> prefix-length: 24
> Say we have another interface with address '' (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:", 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
> Python ipaddress.IPv4, from example:
>   interface = IPv4Interface('')
> 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 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.