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

[Ladislav Lhotka <[e-mail]>]

Per Hedeland <[e-mail]> writes:

> On 2019-04-18 10:41, Ladislav Lhotka wrote:
>> On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
>>>
>>> On 2019-04-18 09:40, Ladislav Lhotka wrote:
>>>> Juergen Schoenwaelder <[e-mail]> writes:
>>>>
>>>>> On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote:
>>>>>> I wonder though, isn't ipX-address-and-prefix-length the clearer name,
>>>>>> or if
>>>>>> we do want to shorten then ipX-address-and-plen. I think Martin stated
>>>>>> the
>>>>>> case for ipX-address-and-prefix but that is IMHO not the way this is
>>>>>> typically perceived by people.
>>>>>>
>>>>>> 1.2.3.4/24
>>>>>> ^^^^^^^----- ipv4 address
>>>>>>          ^^^-- ipv4 prefix length
>>>>>>
>>>>>> now, taking the prefix-length you know that 1.2.3 is the prefix but does
>>>>>> that mean the above is an IPv4 address and a prefix? Or is it just that
>>>>>> you
>>>>>> can infer the prefix from the above? It's just different ways of looking
>>>>>> at
>>>>>> it. My experience tells me ipX-address-and-prefix-length is the clearer
>>>>>> way
>>>>>> of conveying what this is.
>>>>>>
>>>>>
>>>>> I guess this is somewhat subjective. The prefix length is the number
>>>>> used to convey what the prefix is. So you are effectively defining an
>>>>> address and the prefix that this address belongs to. ;-)
>>>>
>>>> Strictly speaking, what is being defined by the number is a subnet mask.
>>>
>>> Heh, amazing how something so binary can turn out to be so subjective ;)
>>> This sort of turns into philosophical questions and I'm not sure we need
>>> to straighten it all out. I'd still call the prefix-length the
>>> prefix-length. It directly maps to the typical subnet mask
>>> representation and as you say, they can be thought of as the same thing.
>>>
>>> Does this mean you prefer ipX-address-and-subnet-mask? Because I think
>> 
>> No.
>> 
>>> that when someone reads that they are going to expect a value that looks
>>> like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still
>>> think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is
>>> the better name :)
>>>
>>>
>>>>> Given that we already have ip-prefix (which does as well use a prefix
>>>>> length to convey what the prefix is), it seems ip-address-and-prefix
>>>>> is more consistent with the existing RFC 6991 definitions. Being
>>>>> consistent with what we have was the main reason for me to prefer
>>>>> ip-address-and-prefix.
>>>>
>>>> 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.
>
> Agreed - except the not entirely minor nit that the thing after the
> "/" is not a prefix but a *prefix-length*. Another way of putting it

Yes, you are right, mea culpa.

> is that the IP address is a property of an interface, while the
> prefix-length or subnet mask is a property of the network that an
> interface is connected to.
>
> So this would clearly be two separate values "bundled" into one, and
> despite the similar syntax, it is radically different from the
> existing ip*-prefix types, which really do represent a single value -
> as Kristian pointed out earlier in the thread, the value is the
> initial N bits of a set of IP addresses - i.e. a prefix, as the name
> says.
>
> Thus if these types should be added, I don't think there is any reason
> to have a naming that is "consistent" with the existing ip*-prefix
> types - rather the naming should highlight the difference. And since
> the two values given are an IP address and a prefix-length, the
> natural choice would be ip*-address-and-prefix-length.
>
> Using ip*-address-and-prefix would be both inaccurate (neither of the
> two values is a prefix, although they can of course be combined to
> compute a one) and IMHO confusing due to the similarity in naming of
> the existing ip*-prefix types.
>
> If ip*-address-and-prefix-length is considered too verbose/clunky
> (although I don't know why this matters for a type name), a reasonable
> shorter form could IMHO be ip*-address-and-length - the prefix-length
> is of course a length, but it is not a prefix. Kristian's
> ip*-address-and-plen is of course even shorter, and could be
> considered to have more information, but I believe we generally try to
> avoid at least non-obvious abbreviations in the YANG modules.
>
>>> this, like postgresql has data types (cidr and inet) that map exactly to
>>> this behaviour, i.e. both store something that looks like an IP address
>>> and a prefix-length but one (cidr for pg) forces bits in host portion to
>>> be set to all 0. Python ipaddress has the same with IPv4Address and
>>> IPv4Interface.
>>>
>>>
>>>> Moreover, the most natural use for
>>>> this type would be the address specification in the "ietf-ip" module,
>>>> but we already have two leaves there: ip and prefix-length.
>>>
>>> Like I said in another mail, I think it is nice if these common
>>> datatypes become used by vendors and implementors. Many use proprietary
>> 
>> That's fine, but we can also define a *grouping* of IP address and subnet prefix
>> length. And if we stick to the leaves "ip" and "prefix-length", this grouping
>> can be used in the next revision of RFC 7277. This would be my preferred
>> solution.
>
>  From a data modelling perspective, having separate leafs for separate
> values should be the natural choice, and I don't think anyone is
> suggesting that the "bundled" type, if added, should be used in e.g.
> RFC 7277. A grouping could be nice, but it is still two separate
> leafs.

Yes, and it is IMO how it should be. As Martin pointed out, complicated
lexical representations are difficult to deal with, e.g. in XPath
expressions.

>
> This is no solution to Kristian's problem, which as far as I
> understand is about having a YANG model for existing devices that
> already *use* the "bundled" type, i.e. it "needs" to be a single leaf
> in the YANG module.

I doubt this is a real problem - a netconf/restconf server backend can
easily translate the two separate leaves into a single string if
necessary. Backends on other devices may well need to use the IP
address and mask separately.

Lada

>
> Whether this need is enough motivation to actually add these types to
> ietf-inet-types I don't really know. There is no real cost in doing it
> per se, but it could have the negative consequence that it is taken as
> an encouragement/"blessing" to use these types when writing new
> modules that *don't* "need" to use them. Bad from a data modelling
> perspectve, and bad for the operational reasons that Martin gave an
> example of while I was writing this. But maybe the 'description'
> statement could warn against this.
>
> --Per

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67