Kristian Larsson <[email protected]> wrote: > > > On 2019-04-18 14:18, Martin Bjorklund wrote: > > Juergen Schoenwaelder <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
