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

[Martin Bjorklund <[e-mail]>]

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