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

[Christian Hopps]

> On Apr 2, 2019, at 22:16, Alex Campbell  wrote:
> 
> I don't think this is joining an address with a prefix - this is joining an 
> address with a prefix *length*.
> If it was two separate values, it would still be constraining the address to 
> be covered by the prefix, since there would be no way to define a prefix that 
> the address didn't cover.

It is joining the two things as far as what data it *represents* (i.e., how it 
can be used). You are correct if we are just talking about the physical bits 
being stored, but semantics count. Otherwise I think you are agreeing with me 
that by representing the 2 values this way it necessarily constrains their 
values the way we want it to.

Thanks,
Chris.

> 
> Also a distinction from ipv4-prefix is that an ipv4-prefix is completely 
> meaningless if either part is removed, whereas an 
> ip-address-and-prefix-length still specifies an IP address if you remove the 
> prefix length.
> 
> Alex
> 
> 
> From: netmod  on behalf of Christian Hopps 
> 
> Sent: Wednesday, 3 April 2019 7:52 a.m.
> To: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
>> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund  wrote:
>> 
>> "Rob Wilton (rwilton)"  wrote:
>>> Hi Acee,
>>> 
>>> Having re-read the thread, I think that "ip-address-prefix" is going
>>> to be confusing, since I had incorrectly assumed that the type being
>>> defined was an IP prefix, but as you have pointed out there is already
>>> a type for that.
>>> 
>>> I think that we need to choose this name very carefully or otherwise I
>>> suspect that folks will accidentally use the wrong type.
>>> 
>>> So having the type as "ip-address-and-prefix-length" or
>>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
>> 
>> The combined type really specifies (i) an ip address and (ii) an ip
>> prefix.  The prefix happens to be specified with a length indicator.
>> So I think the name "ip-address-and-prefix" is the correct one.
>> 
>>> I
>>> think that I also now agree with Martin that this is really merging
>>> two values into one leaf.
>> 
>> And for the record (again, perhaps), I think this is a bad idea in
>> general, and I am not sure an exception is needed in this case.
> 
> (Again :) this is not just joining two values, it is also constraining the 
> address value to be a value covered by the prefix. The common use case is for 
> interface state where the interface has an address which should be within the 
> prefix assigned to the network the interface attaches to.
> 
> This isn't just about saving space.
> 
> I also agree that "-and-" is a really good idea, saving a few characters in 
> an identifier when doing so has shown to cause the identifier to be 
> misunderstood is not an optimization IMO.
> 
> Thanks,
> Chris.
> 
>> 
>> 
>> /martin
>> 
>> 
>>> Where is this type going to be used?  Is it only used for configuring
>>> host address/prefix?  Or are there other uses cases as well?
>>> 
>>> Thanks,
>>> Rob
>>> 
>>> 
 -Original Message-
 From: Acee Lindem (acee) 
 Sent: 02 April 2019 16:52
 To: Rob Wilton (rwilton) ; Martin Bjorklund
 >>> f.com>; j.schoenwael...@jacobs-university.de
 Cc: netmod@ietf.org
 Subject: Re: [netmod] 6991bis: address-with-prefix-length
 
 Hi Rob,
 
 On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
 >>> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
 
 
 
> -Original Message-
> From: netmod  On Behalf Of Martin
 Bjorklund
> Sent: 02 April 2019 13:47
> To: j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Juergen Schoenwaelder  wrote:
>> If you go back ~20 messages, my proposal was ip-address-prefix,
>> ipv4-address-prefix, and ipv6-address-prefix.
> 
> Do we agree that this type really specifies two values in one?  If so
> I think
 the
> "and" is useful.
 
   Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
 
 This was my confusion as well since the ipv4-prefix and ipv6-prefix
 types
 (ietf-inet-types) have been used when they probably shouldn't have
 been.
 Note that they both have the constraint of not allowing the host bits
 to be set
 should they should be used in situations like interface address
 assignment.
 
 Excerpted from RFC6991 ipv4-type definition (note the last sentence):
description
   "The ipv4-prefix type represents an IPv4 address prefix.
The prefix length is given by the number following the
slash character and must be less than or equal to 32.
 
A prefix length value of n corresponds to an IP address
mask that has n contiguous 1-bits from the most
significant bit (MSB) and all other 

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

[Alex Campbell]

I don't think this is joining an address with a prefix - this is joining an 
address with a prefix *length*.
If it was two separate values, it would still be constraining the address to be 
covered by the prefix, since there would be no way to define a prefix that the 
address didn't cover.

Also a distinction from ipv4-prefix is that an ipv4-prefix is completely 
meaningless if either part is removed, whereas an ip-address-and-prefix-length 
still specifies an IP address if you remove the prefix length.

Alex


From: netmod  on behalf of Christian Hopps 

Sent: Wednesday, 3 April 2019 7:52 a.m.
To: Martin Bjorklund
Cc: netmod@ietf.org
Subject: Re: [netmod] 6991bis: address-with-prefix-length

> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund  wrote:
>
> "Rob Wilton (rwilton)"  wrote:
>> Hi Acee,
>>
>> Having re-read the thread, I think that "ip-address-prefix" is going
>> to be confusing, since I had incorrectly assumed that the type being
>> defined was an IP prefix, but as you have pointed out there is already
>> a type for that.
>>
>> I think that we need to choose this name very carefully or otherwise I
>> suspect that folks will accidentally use the wrong type.
>>
>> So having the type as "ip-address-and-prefix-length" or
>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
>
> The combined type really specifies (i) an ip address and (ii) an ip
> prefix.  The prefix happens to be specified with a length indicator.
> So I think the name "ip-address-and-prefix" is the correct one.
>
>> I
>> think that I also now agree with Martin that this is really merging
>> two values into one leaf.
>
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

(Again :) this is not just joining two values, it is also constraining the 
address value to be a value covered by the prefix. The common use case is for 
interface state where the interface has an address which should be within the 
prefix assigned to the network the interface attaches to.

This isn't just about saving space.

I also agree that "-and-" is a really good idea, saving a few characters in an 
identifier when doing so has shown to cause the identifier to be misunderstood 
is not an optimization IMO.

Thanks,
Chris.

>
>
> /martin
>
>
>> Where is this type going to be used?  Is it only used for configuring
>> host address/prefix?  Or are there other uses cases as well?
>>
>> Thanks,
>> Rob
>>
>>
>>> -Original Message-
>>> From: Acee Lindem (acee) 
>>> Sent: 02 April 2019 16:52
>>> To: Rob Wilton (rwilton) ; Martin Bjorklund
>>> >> f.com>; j.schoenwael...@jacobs-university.de
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>>
>>> Hi Rob,
>>>
>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>> >> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>>>
>>>
>>>
 -Original Message-
 From: netmod  On Behalf Of Martin
>>> Bjorklund
 Sent: 02 April 2019 13:47
 To: j.schoenwael...@jacobs-university.de
 Cc: netmod@ietf.org
 Subject: Re: [netmod] 6991bis: address-with-prefix-length

 Juergen Schoenwaelder  wrote:
> If you go back ~20 messages, my proposal was ip-address-prefix,
> ipv4-address-prefix, and ipv6-address-prefix.

 Do we agree that this type really specifies two values in one?  If so
 I think
>>> the
 "and" is useful.
>>>
>>>Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
>>>
>>> This was my confusion as well since the ipv4-prefix and ipv6-prefix
>>> types
>>> (ietf-inet-types) have been used when they probably shouldn't have
>>> been.
>>> Note that they both have the constraint of not allowing the host bits
>>> to be set
>>> should they should be used in situations like interface address
>>> assignment.
>>>
>>> Excerpted from RFC6991 ipv4-type definition (note the last sentence):
>>> description
>>>"The ipv4-prefix type represents an IPv4 address prefix.
>>> The prefix length is given by the number following the
>>> slash character and must be less than or equal to 32.
>>>
>>> A prefix length value of n corresponds to an IP address
>>> mask that has n contiguous 1-bits from the most
>>> significant bit (MSB) and all other bits set to 0.
>>>
>>> The canonical format of an IPv4 prefix has all bits of
>>> the IPv4 address set to zero that are not part of the
>>> IPv4 prefix.";
>>>
>>>So, I think that the names above are probably right, or otherwise if
>>>you
>>> want the "and" then perhaps it should be
>>> "ip-address-and-prefix-length" -
>>> which seems clunky?
>>>
>>> I think the original suggestion of ipxx-address-prefix would be ok.
>>>
>>> Thanks,
>>> Acee
>>>
>>>Thanks,
>>>Rob
>>>
>>>

 Also note that the current text in RFC 6991 says:

 The 

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

[Christian Hopps]

> On Apr 2, 2019, at 2:27 PM, Martin Bjorklund  wrote:
> 
> "Rob Wilton (rwilton)"  wrote:
>> Hi Acee,
>> 
>> Having re-read the thread, I think that "ip-address-prefix" is going
>> to be confusing, since I had incorrectly assumed that the type being
>> defined was an IP prefix, but as you have pointed out there is already
>> a type for that.
>> 
>> I think that we need to choose this name very carefully or otherwise I
>> suspect that folks will accidentally use the wrong type.
>> 
>> So having the type as "ip-address-and-prefix-length" or
>> "ip-addr-and-prefix-len" now seems like a clearer choice to me.
> 
> The combined type really specifies (i) an ip address and (ii) an ip
> prefix.  The prefix happens to be specified with a length indicator.
> So I think the name "ip-address-and-prefix" is the correct one.
> 
>> I
>> think that I also now agree with Martin that this is really merging
>> two values into one leaf.
> 
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

(Again :) this is not just joining two values, it is also constraining the 
address value to be a value covered by the prefix. The common use case is for 
interface state where the interface has an address which should be within the 
prefix assigned to the network the interface attaches to.

This isn't just about saving space.

I also agree that "-and-" is a really good idea, saving a few characters in an 
identifier when doing so has shown to cause the identifier to be misunderstood 
is not an optimization IMO.

Thanks,
Chris.

> 
> 
> /martin
> 
> 
>> Where is this type going to be used?  Is it only used for configuring
>> host address/prefix?  Or are there other uses cases as well?
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> -Original Message-
>>> From: Acee Lindem (acee) 
>>> Sent: 02 April 2019 16:52
>>> To: Rob Wilton (rwilton) ; Martin Bjorklund
>>> >> f.com>; j.schoenwael...@jacobs-university.de
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] 6991bis: address-with-prefix-length
>>> 
>>> Hi Rob,
>>> 
>>> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
>>> >> boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
>>> 
>>> 
>>> 
 -Original Message-
 From: netmod  On Behalf Of Martin
>>> Bjorklund
 Sent: 02 April 2019 13:47
 To: j.schoenwael...@jacobs-university.de
 Cc: netmod@ietf.org
 Subject: Re: [netmod] 6991bis: address-with-prefix-length
 
 Juergen Schoenwaelder  wrote:
> If you go back ~20 messages, my proposal was ip-address-prefix,
> ipv4-address-prefix, and ipv6-address-prefix.
 
 Do we agree that this type really specifies two values in one?  If so
 I think
>>> the
 "and" is useful.
>>> 
>>>Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
>>> 
>>> This was my confusion as well since the ipv4-prefix and ipv6-prefix
>>> types
>>> (ietf-inet-types) have been used when they probably shouldn't have
>>> been.
>>> Note that they both have the constraint of not allowing the host bits
>>> to be set
>>> should they should be used in situations like interface address
>>> assignment.
>>> 
>>> Excerpted from RFC6991 ipv4-type definition (note the last sentence):
>>> description
>>>"The ipv4-prefix type represents an IPv4 address prefix.
>>> The prefix length is given by the number following the
>>> slash character and must be less than or equal to 32.
>>> 
>>> A prefix length value of n corresponds to an IP address
>>> mask that has n contiguous 1-bits from the most
>>> significant bit (MSB) and all other bits set to 0.
>>> 
>>> The canonical format of an IPv4 prefix has all bits of
>>> the IPv4 address set to zero that are not part of the
>>> IPv4 prefix.";
>>> 
>>>So, I think that the names above are probably right, or otherwise if
>>>you
>>> want the "and" then perhaps it should be
>>> "ip-address-and-prefix-length" -
>>> which seems clunky?
>>> 
>>> I think the original suggestion of ipxx-address-prefix would be ok.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>>Thanks,
>>>Rob
>>> 
>>> 
 
 Also note that the current text in RFC 6991 says:
 
 The ipv4-prefix type represents an IPv4 address prefix.
 
 so having a type ipv4-address-prefix for something that is not (only)
 an
 "ipv4 address prefix" is imo confusing.
 
 
 /martin
 
 
 
 
> 
> /js
> 
> On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
>> - Original Message -
>> From: "Jeff Tantsura" 
>> To: ; "Kristian Larsson" 
>> Sent: Monday, April 01, 2019 11:09 PM
>> 
>> What Kristian has proposed makes sense, in favor.
>> 
>> 
>> 
>> Yes, I support this idea and we should be able to come up with a
>> more user-friendly name;  address-prefix or address-length ?
>> 
>> 

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

[Juergen Schoenwaelder]

On Tue, Apr 02, 2019 at 08:27:32PM +0200, Martin Bjorklund wrote:
> 
> > I
> > think that I also now agree with Martin that this is really merging
> > two values into one leaf.
> 
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.
>

This format is used and convenient where it is used (and I do
sometimes miss it at other places where it is not used). I would not
be religious about this combination of values. Note that even
ip-prefix is a combination of a prefix length and an address
'pattern'. So ip-address-and-prefix is actually three values in
one. ;-)

We have yang:date-and-time, a combination of date and time (we are
adding these right now). yang:date-and-time actually clumps together
year, month, day, hours, minutes, seconds, optional subseconds,
timezone. For me, it seems useful to adopt commonly used formats.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Mahesh Jethanandani]

> On Apr 2, 2019, at 11:27 AM, Martin Bjorklund  wrote:
> 
> And for the record (again, perhaps), I think this is a bad idea in
> general, and I am not sure an exception is needed in this case.

+1

Mahesh Jethanandani
mjethanand...@gmail.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Acee,
> 
> Having re-read the thread, I think that "ip-address-prefix" is going
> to be confusing, since I had incorrectly assumed that the type being
> defined was an IP prefix, but as you have pointed out there is already
> a type for that.
> 
> I think that we need to choose this name very carefully or otherwise I
> suspect that folks will accidentally use the wrong type.
> 
> So having the type as "ip-address-and-prefix-length" or
> "ip-addr-and-prefix-len" now seems like a clearer choice to me.

The combined type really specifies (i) an ip address and (ii) an ip
prefix.  The prefix happens to be specified with a length indicator.
So I think the name "ip-address-and-prefix" is the correct one.

> I
> think that I also now agree with Martin that this is really merging
> two values into one leaf.

And for the record (again, perhaps), I think this is a bad idea in
general, and I am not sure an exception is needed in this case.


/martin


> Where is this type going to be used?  Is it only used for configuring
> host address/prefix?  Or are there other uses cases as well?
> 
> Thanks,
> Rob
> 
> 
> > -Original Message-
> > From: Acee Lindem (acee) 
> > Sent: 02 April 2019 16:52
> > To: Rob Wilton (rwilton) ; Martin Bjorklund
> >  > f.com>; j.schoenwael...@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > 
> > Hi Rob,
> > 
> > On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"
> >  > boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
> > 
> > 
> > 
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin
> > Bjorklund
> > > Sent: 02 April 2019 13:47
> > > To: j.schoenwael...@jacobs-university.de
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> > >
> > > Juergen Schoenwaelder  wrote:
> > > > If you go back ~20 messages, my proposal was ip-address-prefix,
> > > > ipv4-address-prefix, and ipv6-address-prefix.
> > >
> > > Do we agree that this type really specifies two values in one?  If so
> > > I think
> > the
> > > "and" is useful.
> > 
> > Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
> > 
> > This was my confusion as well since the ipv4-prefix and ipv6-prefix
> > types
> > (ietf-inet-types) have been used when they probably shouldn't have
> > been.
> > Note that they both have the constraint of not allowing the host bits
> > to be set
> > should they should be used in situations like interface address
> > assignment.
> > 
> > Excerpted from RFC6991 ipv4-type definition (note the last sentence):
> >  description
> > "The ipv4-prefix type represents an IPv4 address prefix.
> >  The prefix length is given by the number following the
> >  slash character and must be less than or equal to 32.
> > 
> >  A prefix length value of n corresponds to an IP address
> >  mask that has n contiguous 1-bits from the most
> >  significant bit (MSB) and all other bits set to 0.
> > 
> >  The canonical format of an IPv4 prefix has all bits of
> >  the IPv4 address set to zero that are not part of the
> >  IPv4 prefix.";
> > 
> > So, I think that the names above are probably right, or otherwise if
> > you
> > want the "and" then perhaps it should be
> > "ip-address-and-prefix-length" -
> > which seems clunky?
> > 
> > I think the original suggestion of ipxx-address-prefix would be ok.
> > 
> > Thanks,
> > Acee
> > 
> > Thanks,
> > Rob
> > 
> > 
> > >
> > > Also note that the current text in RFC 6991 says:
> > >
> > >  The ipv4-prefix type represents an IPv4 address prefix.
> > >
> > > so having a type ipv4-address-prefix for something that is not (only)
> > > an
> > > "ipv4 address prefix" is imo confusing.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > > > - Original Message -
> > > > > From: "Jeff Tantsura" 
> > > > > To: ; "Kristian Larsson" 
> > 
> > > > > Sent: Monday, April 01, 2019 11:09 PM
> > > > >
> > > > > What Kristian has proposed makes sense, in favor.
> > > > >
> > > > > 
> > > > >
> > > > > Yes, I support this idea and we should be able to come up with a
> > > > > more user-friendly name;  address-prefix or address-length ?
> > > > >
> > > > > Tom Petch
> > > > >
> > > > > p.s.
> > > > >
> > > > >identifier  = (ALPHA / "_")
> > > > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > > > >
> > > > > Cheers,
> > > > > Jeff
> > > > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > > > , wrote:
> > > > > > Hello Mahesh,
> > > > > >
> > > > 

Re: [netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

[Acee Lindem (acee)]

Hi Sasha,
You are correct that there is no per-next-hop preference in the current model. 
However, this is included in the augmentation in 
draft-ietf-rtgwg-yang-rib-extend.
Thanks,
Acee

From: Alexander Vainshtein 
Date: Tuesday, April 2, 2019 at 9:53 AM
To: Acee Lindem , Ladislav Lhotka 
Cc: Routing WG , "netmod@ietf.org" 
Subject: Doubts about static routes in RFC 8349 (was: Doubts about static 
routes in RFC 8022)

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the 
same problem.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: 'a...@cisco.com' ; 'lho...@nic.cz' 
Cc: 'rt...@ietf.org' ; 'netmod@ietf.org' 
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple 
routes with common destination, different next hops and different route 
preferences.

This is because only route destination is considered as the key in the RIB in 
Appendix A of RFC 8022., while route preference is a per-route read-only leaf 
in the data model.

In particular (and this was my original problem) , it is possible to configure 
a static route with multiple next hops (using the next-hop-list construct) 
using the data model defined in RFC 8022, but all the next hops in this 
construct would have the same preference. AFAIK, many (if not all) deployed 
implementations support ability to configure static routes with the same 
destination, different next hops and different preferences, so that one of 
these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB 
(RFC 4292), because it includes both the route destination and its next hop in 
the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

Hi Tom,

But having joined this thread midway through, I thought that what was being 
described was an ip-prefix.

I wonder how many folks will mistakenly think that "ip-address-prefix" means 
"ip-prefix"?

Thanks,
Rob


> -Original Message-
> From: tom petch 
> Sent: 02 April 2019 17:34
> To: Rob Wilton (rwilton) ; Martin Bjorklund  f.com>; j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> - Original Message -
> From: "Rob Wilton (rwilton)" 
> Sent: Tuesday, April 02, 2019 4:37 PM
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin
> Bjorklund
> > > Sent: 02 April 2019 13:47
> > >
> > > Juergen Schoenwaelder  wrote:
> > > > If you go back ~20 messages, my proposal was ip-address-prefix,
> > > > ipv4-address-prefix, and ipv6-address-prefix.
> > >
> > > Do we agree that this type really specifies two values in one?  If
> so I think the
> > > "and" is useful.
> >
> > Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
> 
> No; that is the point.  A prefix is not an address.  What we specifying here 
> is
> an address and an address mask, except that now we can use a shorthand
> for the mask since the one bits of the mask are contiguous and left justified
> (which they used not to be:-).
> 
> Including 'and' in the identifier of this type may be semantically more
> accurate but IMHO just clutters up the identifier, makes it longer, harder to
> type, read and do anything else with.
> 
> 'ipv6-address-prefix'
> 
> is quite long enough (if not too long).
> 
> Tom Petch
> 
> >
> > So, I think that the names above are probably right, or otherwise if
> you want the "and" then perhaps it should be "ip-address-and-prefix-length"
> - which seems clunky?
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > > Also note that the current text in RFC 6991 says:
> > >
> > >  The ipv4-prefix type represents an IPv4 address prefix.
> > >
> > > so having a type ipv4-address-prefix for something that is not
> (only) an
> > > "ipv4 address prefix" is imo confusing.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > > >
> > > > /js
> > > >
> > > > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > > > - Original Message -
> > > > > From: "Jeff Tantsura" 
> > > > > To: ; "Kristian Larsson"
> 
> > > > > Sent: Monday, April 01, 2019 11:09 PM
> > > > >
> > > > > What Kristian has proposed makes sense, in favor.
> > > > >
> > > > > 
> > > > >
> > > > > Yes, I support this idea and we should be able to come up with a
> > > > > more user-friendly name;  address-prefix or address-length ?
> > > > >
> > > > > Tom Petch
> > > > >
> > > > > p.s.
> > > > >
> > > > >identifier  = (ALPHA / "_")
> > > > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > > > >
> > > > > Cheers,
> > > > > Jeff
> > > > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > > > , wrote:
> > > > > > Hello Mahesh,
> > > > > >
> > > > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > > > >
> > > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund
> 
> > > > > wrote:
> > > > > > > >
> > > > > > > > I know that this type is convenient, esp. if you use it
> for
> > > > > > > > manual input, but I wonder if it really is good practice
> to
> > > > > > > > squeeze two values into one.
> > > > > > >
> > > > > > > Agree. The combination makes sense for CLI, but for modeling
> the
> > > > > address and prefix should be separate.
> > > > > >
> > > > > > Okay, then why do we have an ip-prefix data type at all? With
> the
> > > > > > same line of argument you apply, it should be split up.
> > > > > >
> > > > > > So you're the third person bringing up CLI. I don't get this
> at
> > > > > > all. I don't see how CLI are different from everything else.
> This
> > > > > > is about
> > > > > data
> > > > > > modeling and data modeling is about expressing the world in a
> data
> > > > > > modeling language. It's like painting a picture but instead of
> a
> > > > > > brush you have a schema language like YANG. What do you see?
> > > > > > Express it. It doesn't matter if the purpose is a CLI, a web
> page
> > > > > > or just exposing it via NETCONF for another system to consume.
> > > > > >
> > > > > > I think address-and-prefix-length is natural. JUNOS uses this
> format.
> > > > > XR
> > > > > > uses this format (for IPv6 at least). Nokia SROS uses this
> format.
> > > > > >
> > > > > > We have written a bunch of models where the lack of this IMHO
> > > > > > makes
> > > > > them
> > > > > > less elegant. I'd like for there to be an IETF standard data
> type
> > > > > > to make those models more elegant.
> > > > > >
> > > > > > Kind regards,
> > > > > > Kristian.
> > > > > >
> > > > > > ___
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > > >
> > > > >
> > > >
> > 

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

[tom petch]

- Original Message -
From: "Rob Wilton (rwilton)" 
Sent: Tuesday, April 02, 2019 4:37 PM
> > -Original Message-
> > From: netmod  On Behalf Of Martin Bjorklund
> > Sent: 02 April 2019 13:47
> >
> > Juergen Schoenwaelder  wrote:
> > > If you go back ~20 messages, my proposal was ip-address-prefix,
> > > ipv4-address-prefix, and ipv6-address-prefix.
> >
> > Do we agree that this type really specifies two values in one?  If
so I think the
> > "and" is useful.
>
> Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

No; that is the point.  A prefix is not an address.  What we specifying
here is an address and an address mask, except that now we can use a
shorthand for the mask since the one bits of the mask are contiguous and
left justified (which they used not to be:-).

Including 'and' in the identifier of this type may be semantically more
accurate but IMHO just clutters up the identifier, makes it longer,
harder to type, read and do anything else with.

'ipv6-address-prefix'

is quite long enough (if not too long).

Tom Petch

>
> So, I think that the names above are probably right, or otherwise if
you want the "and" then perhaps it should be
"ip-address-and-prefix-length" - which seems clunky?
>
> Thanks,
> Rob
>
>
> >
> > Also note that the current text in RFC 6991 says:
> >
> >  The ipv4-prefix type represents an IPv4 address prefix.
> >
> > so having a type ipv4-address-prefix for something that is not
(only) an
> > "ipv4 address prefix" is imo confusing.
> >
> >
> > /martin
> >
> >
> >
> >
> > >
> > > /js
> > >
> > > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > > - Original Message -
> > > > From: "Jeff Tantsura" 
> > > > To: ; "Kristian Larsson"

> > > > Sent: Monday, April 01, 2019 11:09 PM
> > > >
> > > > What Kristian has proposed makes sense, in favor.
> > > >
> > > > 
> > > >
> > > > Yes, I support this idea and we should be able to come up with a
> > > > more user-friendly name;  address-prefix or address-length ?
> > > >
> > > > Tom Petch
> > > >
> > > > p.s.
> > > >
> > > >identifier  = (ALPHA / "_")
> > > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > > >
> > > > Cheers,
> > > > Jeff
> > > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > > , wrote:
> > > > > Hello Mahesh,
> > > > >
> > > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > > >
> > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund

> > > > wrote:
> > > > > > >
> > > > > > > I know that this type is convenient, esp. if you use it
for
> > > > > > > manual input, but I wonder if it really is good practice
to
> > > > > > > squeeze two values into one.
> > > > > >
> > > > > > Agree. The combination makes sense for CLI, but for modeling
the
> > > > address and prefix should be separate.
> > > > >
> > > > > Okay, then why do we have an ip-prefix data type at all? With
the
> > > > > same line of argument you apply, it should be split up.
> > > > >
> > > > > So you're the third person bringing up CLI. I don't get this
at
> > > > > all. I don't see how CLI are different from everything else.
This
> > > > > is about
> > > > data
> > > > > modeling and data modeling is about expressing the world in a
data
> > > > > modeling language. It's like painting a picture but instead of
a
> > > > > brush you have a schema language like YANG. What do you see?
> > > > > Express it. It doesn't matter if the purpose is a CLI, a web
page
> > > > > or just exposing it via NETCONF for another system to consume.
> > > > >
> > > > > I think address-and-prefix-length is natural. JUNOS uses this
format.
> > > > XR
> > > > > uses this format (for IPv6 at least). Nokia SROS uses this
format.
> > > > >
> > > > > We have written a bunch of models where the lack of this IMHO
> > > > > makes
> > > > them
> > > > > less elegant. I'd like for there to be an IETF standard data
type
> > > > > to make those models more elegant.
> > > > >
> > > > > Kind regards,
> > > > > Kristian.
> > > > >
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >
> > > >
> > >
> 
> > > > 
> > > > 
> > > >
> > > >
> > > > > ___
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen |
Germany
> > > Fax:   +49 421 200 3103

> > >
> > > ___
> > > netmod mailing list
> > 

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

[Rob Wilton (rwilton)]

Hi Acee,

Having re-read the thread, I think that "ip-address-prefix" is going to be 
confusing, since I had incorrectly assumed that the type being defined was an 
IP prefix, but as you have pointed out there is already a type for that.

I think that we need to choose this name very carefully or otherwise I suspect 
that folks will accidentally use the wrong type.

So having the type as "ip-address-and-prefix-length" or 
"ip-addr-and-prefix-len" now seems like a clearer choice to me.  I think that I 
also now agree with Martin that this is really merging two values into one leaf.

Where is this type going to be used?  Is it only used for configuring host 
address/prefix?  Or are there other uses cases as well?

Thanks,
Rob


> -Original Message-
> From: Acee Lindem (acee) 
> Sent: 02 April 2019 16:52
> To: Rob Wilton (rwilton) ; Martin Bjorklund  f.com>; j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Hi Rob,
> 
> On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)"  boun...@ietf.org on behalf of rwil...@cisco.com> wrote:
> 
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin
> Bjorklund
> > Sent: 02 April 2019 13:47
> > To: j.schoenwael...@jacobs-university.de
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] 6991bis: address-with-prefix-length
> >
> > Juergen Schoenwaelder  wrote:
> > > If you go back ~20 messages, my proposal was ip-address-prefix,
> > > ipv4-address-prefix, and ipv6-address-prefix.
> >
> > Do we agree that this type really specifies two values in one?  If so I 
> think
> the
> > "and" is useful.
> 
> Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?
> 
> This was my confusion as well since the ipv4-prefix and ipv6-prefix types
> (ietf-inet-types) have been used when they probably shouldn't have been.
> Note that they both have the constraint of not allowing the host bits to be 
> set
> should they should be used in situations like interface address assignment.
> 
> Excerpted from RFC6991 ipv4-type definition (note the last sentence):
>  description
> "The ipv4-prefix type represents an IPv4 address prefix.
>  The prefix length is given by the number following the
>  slash character and must be less than or equal to 32.
> 
>  A prefix length value of n corresponds to an IP address
>  mask that has n contiguous 1-bits from the most
>  significant bit (MSB) and all other bits set to 0.
> 
>  The canonical format of an IPv4 prefix has all bits of
>  the IPv4 address set to zero that are not part of the
>  IPv4 prefix.";
> 
> So, I think that the names above are probably right, or otherwise if you
> want the "and" then perhaps it should be "ip-address-and-prefix-length" -
> which seems clunky?
> 
> I think the original suggestion of ipxx-address-prefix would be ok.
> 
> Thanks,
> Acee
> 
> Thanks,
> Rob
> 
> 
> >
> > Also note that the current text in RFC 6991 says:
> >
> >  The ipv4-prefix type represents an IPv4 address prefix.
> >
> > so having a type ipv4-address-prefix for something that is not (only) an
> > "ipv4 address prefix" is imo confusing.
> >
> >
> > /martin
> >
> >
> >
> >
> > >
> > > /js
> > >
> > > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > > - Original Message -
> > > > From: "Jeff Tantsura" 
> > > > To: ; "Kristian Larsson" 
> > > > Sent: Monday, April 01, 2019 11:09 PM
> > > >
> > > > What Kristian has proposed makes sense, in favor.
> > > >
> > > > 
> > > >
> > > > Yes, I support this idea and we should be able to come up with a
> > > > more user-friendly name;  address-prefix or address-length ?
> > > >
> > > > Tom Petch
> > > >
> > > > p.s.
> > > >
> > > >identifier  = (ALPHA / "_")
> > > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > > >
> > > > Cheers,
> > > > Jeff
> > > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > > , wrote:
> > > > > Hello Mahesh,
> > > > >
> > > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > > >
> > > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund  f.com>
> > > > wrote:
> > > > > > >
> > > > > > > I know that this type is convenient, esp. if you use it for
> > > > > > > manual input, but I wonder if it really is good practice to
> > > > > > > squeeze two values into one.
> > > > > >
> > > > > > Agree. The combination makes sense for CLI, but for modeling the
> > > > address and prefix should be separate.
> > > > >
> > > > > Okay, then why do we have an ip-prefix data type at all? With the
> > > > > same line of argument you apply, it should be 

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

[Acee Lindem (acee)]

Hi Rob, 

On 4/2/19, 11:37 AM, "netmod on behalf of Rob Wilton (rwilton)" 
 wrote:



> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 02 April 2019 13:47
> To: j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Juergen Schoenwaelder  wrote:
> > If you go back ~20 messages, my proposal was ip-address-prefix,
> > ipv4-address-prefix, and ipv6-address-prefix.
> 
> Do we agree that this type really specifies two values in one?  If so I 
think the
> "and" is useful.

Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

This was my confusion as well since the ipv4-prefix and ipv6-prefix types 
(ietf-inet-types) have been used when they probably shouldn't have been.  Note 
that they both have the constraint of not allowing the host bits to be set 
should they should be used in situations like interface address assignment. 

Excerpted from RFC6991 ipv4-type definition (note the last sentence): 
 description
"The ipv4-prefix type represents an IPv4 address prefix.
 The prefix length is given by the number following the
 slash character and must be less than or equal to 32.

 A prefix length value of n corresponds to an IP address
 mask that has n contiguous 1-bits from the most
 significant bit (MSB) and all other bits set to 0.

 The canonical format of an IPv4 prefix has all bits of
 the IPv4 address set to zero that are not part of the
 IPv4 prefix.";

So, I think that the names above are probably right, or otherwise if you 
want the "and" then perhaps it should be "ip-address-and-prefix-length" - which 
seems clunky?

I think the original suggestion of ipxx-address-prefix would be ok. 

Thanks,
Acee

Thanks,
Rob


> 
> Also note that the current text in RFC 6991 says:
> 
>  The ipv4-prefix type represents an IPv4 address prefix.
> 
> so having a type ipv4-address-prefix for something that is not (only) an
> "ipv4 address prefix" is imo confusing.
> 
> 
> /martin
> 
> 
> 
> 
> >
> > /js
> >
> > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > - Original Message -
> > > From: "Jeff Tantsura" 
> > > To: ; "Kristian Larsson" 
> > > Sent: Monday, April 01, 2019 11:09 PM
> > >
> > > What Kristian has proposed makes sense, in favor.
> > >
> > > 
> > >
> > > Yes, I support this idea and we should be able to come up with a
> > > more user-friendly name;  address-prefix or address-length ?
> > >
> > > Tom Petch
> > >
> > > p.s.
> > >
> > >identifier  = (ALPHA / "_")
> > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > >
> > > Cheers,
> > > Jeff
> > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > , wrote:
> > > > Hello Mahesh,
> > > >
> > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > >
> > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund 
> > > wrote:
> > > > > >
> > > > > > I know that this type is convenient, esp. if you use it for
> > > > > > manual input, but I wonder if it really is good practice to
> > > > > > squeeze two values into one.
> > > > >
> > > > > Agree. The combination makes sense for CLI, but for modeling the
> > > address and prefix should be separate.
> > > >
> > > > Okay, then why do we have an ip-prefix data type at all? With the
> > > > same line of argument you apply, it should be split up.
> > > >
> > > > So you're the third person bringing up CLI. I don't get this at
> > > > all. I don't see how CLI are different from everything else. This
> > > > is about
> > > data
> > > > modeling and data modeling is about expressing the world in a data
> > > > modeling language. It's like painting a picture but instead of a
> > > > brush you have a schema language like YANG. What do you see?
> > > > Express it. It doesn't matter if the purpose is a CLI, a web page
> > > > or just exposing it via NETCONF for another system to consume.
> > > >
> > > > I think address-and-prefix-length is natural. JUNOS uses this 
format.
> > > XR
> > > > uses this format (for IPv6 at least). Nokia SROS uses this format.
> > > >
> > > > We have written a bunch of models where the lack of this IMHO
> > > > makes
> > > them
> > > > less elegant. I'd like for there to be an IETF standard data type
> > > > to make those models more elegant.
> > > >
> > > > Kind regards,
> > > > Kristian.
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > 

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

[Rob Wilton (rwilton)]

> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 02 April 2019 13:47
> To: j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Juergen Schoenwaelder  wrote:
> > If you go back ~20 messages, my proposal was ip-address-prefix,
> > ipv4-address-prefix, and ipv6-address-prefix.
> 
> Do we agree that this type really specifies two values in one?  If so I think 
> the
> "and" is useful.

Isn't an "IP prefix" made up of an "IP address" and a "prefix length"?

So, I think that the names above are probably right, or otherwise if you want 
the "and" then perhaps it should be "ip-address-and-prefix-length" - which 
seems clunky?

Thanks,
Rob


> 
> Also note that the current text in RFC 6991 says:
> 
>  The ipv4-prefix type represents an IPv4 address prefix.
> 
> so having a type ipv4-address-prefix for something that is not (only) an
> "ipv4 address prefix" is imo confusing.
> 
> 
> /martin
> 
> 
> 
> 
> >
> > /js
> >
> > On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> > > - Original Message -
> > > From: "Jeff Tantsura" 
> > > To: ; "Kristian Larsson" 
> > > Sent: Monday, April 01, 2019 11:09 PM
> > >
> > > What Kristian has proposed makes sense, in favor.
> > >
> > > 
> > >
> > > Yes, I support this idea and we should be able to come up with a
> > > more user-friendly name;  address-prefix or address-length ?
> > >
> > > Tom Petch
> > >
> > > p.s.
> > >
> > >identifier  = (ALPHA / "_")
> > >  *(ALPHA / DIGIT / "_" / "-" / ".")
> > >
> > > Cheers,
> > > Jeff
> > > On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> > > , wrote:
> > > > Hello Mahesh,
> > > >
> > > > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > > > >
> > > > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund 
> > > wrote:
> > > > > >
> > > > > > I know that this type is convenient, esp. if you use it for
> > > > > > manual input, but I wonder if it really is good practice to
> > > > > > squeeze two values into one.
> > > > >
> > > > > Agree. The combination makes sense for CLI, but for modeling the
> > > address and prefix should be separate.
> > > >
> > > > Okay, then why do we have an ip-prefix data type at all? With the
> > > > same line of argument you apply, it should be split up.
> > > >
> > > > So you're the third person bringing up CLI. I don't get this at
> > > > all. I don't see how CLI are different from everything else. This
> > > > is about
> > > data
> > > > modeling and data modeling is about expressing the world in a data
> > > > modeling language. It's like painting a picture but instead of a
> > > > brush you have a schema language like YANG. What do you see?
> > > > Express it. It doesn't matter if the purpose is a CLI, a web page
> > > > or just exposing it via NETCONF for another system to consume.
> > > >
> > > > I think address-and-prefix-length is natural. JUNOS uses this format.
> > > XR
> > > > uses this format (for IPv6 at least). Nokia SROS uses this format.
> > > >
> > > > We have written a bunch of models where the lack of this IMHO
> > > > makes
> > > them
> > > > less elegant. I'd like for there to be an IETF standard data type
> > > > to make those models more elegant.
> > > >
> > > > Kind regards,
> > > > Kristian.
> > > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > >
> > >
> > > 
> > > 
> > > 
> > >
> > >
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Tue, Apr 02, 2019 at 02:46:40PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > If you go back ~20 messages, my proposal was ip-address-prefix,
> > ipv4-address-prefix, and ipv6-address-prefix.
> 
> Do we agree that this type really specifies two values in one?  If so
> I think the "and" is useful.
> 
> Also note that the current text in RFC 6991 says:
> 
>  The ipv4-prefix type represents an IPv4 address prefix.
> 
> so having a type ipv4-address-prefix for something that is not (only) an
> "ipv4 address prefix" is imo confusing.

I can fix the wording. But I can also use ip*-address-and-prefix if
people think this a better name. Perhaps I should do both, fix the
wording (at other places the text just says "ip prefix") and use
ip*-address-and-prefix for the new types.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Doubts about static routes in RFC 8349 (was: Doubts about static routes in RFC 8022)

[Alexander Vainshtein]

Hi all,
I have noticed that 8022 has been obsoleted by RFC 8349. But it has exactly the 
same problem.

Regards,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com

From: Alexander Vainshtein
Sent: Tuesday, April 2, 2019 3:57 PM
To: 'a...@cisco.com' ; 'lho...@nic.cz' 
Cc: 'rt...@ietf.org' ; 'netmod@ietf.org' 
Subject: Doubts about static routes in RFC 8022
Importance: High

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple 
routes with common destination, different next hops and different route 
preferences.

This is because only route destination is considered as the key in the RIB in 
Appendix A of RFC 8022., while route preference is a per-route read-only leaf 
in the data model.

In particular (and this was my original problem) , it is possible to configure 
a static route with multiple next hops (using the next-hop-list construct) 
using the data model defined in RFC 8022, but all the next hops in this 
construct would have the same preference. AFAIK, many (if not all) deployed 
implementations support ability to configure static routes with the same 
destination, different next hops and different preferences, so that one of 
these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB 
(RFC 4292), because it includes both the route destination and its next hop in 
the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   
alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Doubts about static routes in RFC 8022

[Alexander Vainshtein]

Acee, Ladislav and all,
I have serious doubts regarding the data model for static routes in RFC 8022.

As I see it, the data model defined in this document does not support multiple 
routes with common destination, different next hops and different route 
preferences.

This is because only route destination is considered as the key in the RIB in 
Appendix A of RFC 8022., while route preference is a per-route read-only leaf 
in the data model.

In particular (and this was my original problem) , it is possible to configure 
a static route with multiple next hops (using the next-hop-list construct) 
using the data model defined in RFC 8022, but all the next hops in this 
construct would have the same preference. AFAIK, many (if not all) deployed 
implementations support ability to configure static routes with the same 
destination, different next hops and different preferences, so that one of 
these next hops would act as a protection of the other.

For the reference, this problem does not exist in the standard MIB for the RIB 
(RFC 4292), because it includes both the route destination and its next hop in 
the list  of indices in the corresponding MIB.

What, if anything, did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:  +972-549266302
Email:   alexander.vainsht...@ecitele.com


___

This e-mail message is intended for the recipient only and contains information 
which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
__
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

Hi Kristian,

Completely agree.  My suggestion for a tuples type is really for YANG Next.  
I'll add it to the tracker so that it can be discussed.

For the immediate problem, I agree with defining a combined type.  Juergen's 
proposal looks good to me.

Thanks,
Rob


> -Original Message-
> From: netmod  On Behalf Of Kristian Larsson
> Sent: 02 April 2019 13:28
> To: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Hi Rob,
> 
> On 2019-04-02 14:17, Rob Wilton (rwilton) wrote:
> >> -Original Message-
> >> From: netmod  On Behalf Of Martin
> Bjorklund
> >> Sent: 01 April 2019 18:30
> >> To: Acee Lindem (acee) 
> >> Cc: netmod@ietf.org
> >> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> >>
> >> Hi,
> >>
> >> The request was for a combined type that contains both an ip address
> >> *and* a prefix length in one value.  Hence the name
> >> "ip-address-and-prefix- length" :)
> >>
> >> I know that this type is convenient, esp. if you use it for manual
> >> input, but I wonder if it really is good practice to squeeze two values 
> >> into
> one.
> >
> > Perhaps allowing YANG to support a tuple type would be an elegant
> solution.  I.e. the value exists on a single path, and has to be atomically
> updated, but the value can still be composed from different types.
> 
> I think that would be a great addition to YANG. I've had numerous
> discussions over the awkardness of using a grouping to group multiple leaves
> together when you really want to define some form of compound / tuple
> type.
> 
> However, that is a longer term project and IMHO not something that should
> stop adding a ip-address-and-prefix-length type to 6991bis today :)
> 
> Kind regards,
> Kristian.
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kristian Larsson]

Hi Rob,

On 2019-04-02 14:17, Rob Wilton (rwilton) wrote:

-Original Message-
From: netmod  On Behalf Of Martin Bjorklund
Sent: 01 April 2019 18:30
To: Acee Lindem (acee) 
Cc: netmod@ietf.org
Subject: Re: [netmod] 6991bis: address-with-prefix-length

Hi,

The request was for a combined type that contains both an ip address
*and* a prefix length in one value.  Hence the name "ip-address-and-prefix-
length" :)

I know that this type is convenient, esp. if you use it for manual input, but I
wonder if it really is good practice to squeeze two values into one.


Perhaps allowing YANG to support a tuple type would be an elegant solution.  
I.e. the value exists on a single path, and has to be atomically updated, but 
the value can still be composed from different types.


I think that would be a great addition to YANG. I've had numerous 
discussions over the awkardness of using a grouping to group multiple 
leaves together when you really want to define some form of compound / 
tuple type.


However, that is a longer term project and IMHO not something that 
should stop adding a ip-address-and-prefix-length type to 6991bis today :)


Kind regards,
   Kristian.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 01 April 2019 18:30
> To: Acee Lindem (acee) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] 6991bis: address-with-prefix-length
> 
> Hi,
> 
> The request was for a combined type that contains both an ip address
> *and* a prefix length in one value.  Hence the name "ip-address-and-prefix-
> length" :)
> 
> I know that this type is convenient, esp. if you use it for manual input, but 
> I
> wonder if it really is good practice to squeeze two values into one.

Perhaps allowing YANG to support a tuple type would be an elegant solution.  
I.e. the value exists on a single path, and has to be atomically updated, but 
the value can still be composed from different types.

Thanks,
Rob


> 
> 
> /martin
> 
> 
> "Acee Lindem (acee)"  wrote:
> > Ok, now I'm confused. I see that the ietf-inet-type model already has the
> types ipv4-prefix and ipv6-prefix. How are these any different???
> > Thanks,
> > Acee
> >
> > On 4/1/19, 12:31 PM, "Acee Lindem (acee)"  wrote:
> >
> > I believe the "address-" could be omitted from the type identifiers. At
> least within the routing area, "ipv4-prefix" is unambiguous.
> > Thanks,
> > Acee
> >
> > On 4/1/19, 12:14 PM, "netmod on behalf of Juergen Schoenwaelder"
>  university.de> wrote:
> >
> > This is the right time for this and I would call these
> > ip-address-prefix, ipv4-address-prefix and ipv6-address
> > prefix.
> >
> > /js
> >
> > On Mon, Apr 01, 2019 at 04:38:34PM +0200, Kristian Larsson wrote:
> > > Hello,
> > >
> > > seeing that 6991 is up for a refresh I wonder if this would be 
> > the time
> to
> > > suggest the addition of a type for address-and-prefix-length, for
> example
> > > like 192.0.2.1/24?
> > >
> > > I find that it's the most natural way express the address and 
> > prefix-
> length
> > > to configure on an interface or for some other use. We currently
> have an
> > > ip-prefix type which allows CIDR style prefixes but since all 
> > bits to the
> > > right of the mask is to be 0 it is only possible to use for 
> > describing the
> > > IP prefix / network address itself - not the address of a host in 
> > that
> > > network.
> > >
> > > I actually wish the interface-ip modules would have used a 
> > combined
> leaf for
> > > these settings rather than the dual-leaf approach it currently 
> > has, but
> I
> > > suppose that ship has sailed :/
> > >
> > > Regardless, can we add such a type? Is this the document and time 
> > to
> do it?
> > > :)
> > >
> > > Kind regard,
> > >Kristian.
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen |
> Germany
> > Fax:   +49 421 200 3103 
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

If you go back ~20 messages, my proposal was ip-address-prefix,
ipv4-address-prefix, and ipv6-address-prefix.

/js

On Tue, Apr 02, 2019 at 11:13:09AM +, tom petch wrote:
> - Original Message -
> From: "Jeff Tantsura" 
> To: ; "Kristian Larsson" 
> Sent: Monday, April 01, 2019 11:09 PM
> 
> What Kristian has proposed makes sense, in favor.
> 
> 
> 
> Yes, I support this idea and we should be able to come up with a more
> user-friendly name;  address-prefix or address-length ?
> 
> Tom Petch
> 
> p.s.
> 
>identifier  = (ALPHA / "_")
>  *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> Cheers,
> Jeff
> On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
> , wrote:
> > Hello Mahesh,
> >
> > On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> > >
> > > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund 
> wrote:
> > > >
> > > > I know that this type is convenient, esp. if you use it for manual
> > > > input, but I wonder if it really is good practice to squeeze two
> > > > values into one.
> > >
> > > Agree. The combination makes sense for CLI, but for modeling the
> address and prefix should be separate.
> >
> > Okay, then why do we have an ip-prefix data type at all? With the same
> > line of argument you apply, it should be split up.
> >
> > So you're the third person bringing up CLI. I don't get this at all. I
> > don't see how CLI are different from everything else. This is about
> data
> > modeling and data modeling is about expressing the world in a data
> > modeling language. It's like painting a picture but instead of a brush
> > you have a schema language like YANG. What do you see? Express it. It
> > doesn't matter if the purpose is a CLI, a web page or just exposing it
> > via NETCONF for another system to consume.
> >
> > I think address-and-prefix-length is natural. JUNOS uses this format.
> XR
> > uses this format (for IPv6 at least). Nokia SROS uses this format.
> >
> > We have written a bunch of models where the lack of this IMHO makes
> them
> > less elegant. I'd like for there to be an IETF standard data type to
> > make those models more elegant.
> >
> > Kind regards,
> > Kristian.
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> 
> 
> 
> 
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[tom petch]

- Original Message -
From: "Jeff Tantsura" 
To: ; "Kristian Larsson" 
Sent: Monday, April 01, 2019 11:09 PM

What Kristian has proposed makes sense, in favor.



Yes, I support this idea and we should be able to come up with a more
user-friendly name;  address-prefix or address-length ?

Tom Petch

p.s.

   identifier  = (ALPHA / "_")
 *(ALPHA / DIGIT / "_" / "-" / ".")

Cheers,
Jeff
On Apr 1, 2019, 1:09 PM -0700, Kristian Larsson
, wrote:
> Hello Mahesh,
>
> On 2019-04-01 21:40, Mahesh Jethanandani wrote:
> >
> > > On Apr 1, 2019, at 10:29 AM, Martin Bjorklund 
wrote:
> > >
> > > I know that this type is convenient, esp. if you use it for manual
> > > input, but I wonder if it really is good practice to squeeze two
> > > values into one.
> >
> > Agree. The combination makes sense for CLI, but for modeling the
address and prefix should be separate.
>
> Okay, then why do we have an ip-prefix data type at all? With the same
> line of argument you apply, it should be split up.
>
> So you're the third person bringing up CLI. I don't get this at all. I
> don't see how CLI are different from everything else. This is about
data
> modeling and data modeling is about expressing the world in a data
> modeling language. It's like painting a picture but instead of a brush
> you have a schema language like YANG. What do you see? Express it. It
> doesn't matter if the purpose is a CLI, a web page or just exposing it
> via NETCONF for another system to consume.
>
> I think address-and-prefix-length is natural. JUNOS uses this format.
XR
> uses this format (for IPv6 at least). Nokia SROS uses this format.
>
> We have written a bunch of models where the lack of this IMHO makes
them
> less elegant. I'd like for there to be an IETF standard data type to
> make those models more elegant.
>
> Kind regards,
> Kristian.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod







> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Choice Case vs Container+When in RFC7950

[Juergen Schoenwaelder]

I prefer choice since a choice says clearly upfront that what follows
are N alternatives. With when statements, I have to keep all the when
statements in my mind to derive the conclusion that the model defines
alternatives. And the transport leaf in your when construction is
redundant.

/js

On Tue, Apr 02, 2019 at 01:13:52AM +, Qin Wu wrote:
> Hi, Folks:
> Choice case seems interchangeable with Container+when, here is the example of 
> Choice case
>  container system {
>description
>  "Contains various system parameters.";
>choice services {
>  description
>"Configure externally available services.";
>  case ssh {
>description
>  "SSH service-specific configuration.";
>// more leafs, containers, and stuff here...
>  }
>  case tls {
>description
>  "TLS service-specific configuration.";
>// more leafs, containers, and stuff here...
>  }
>}
>  }
> I think it can be replaced with container+when representation as follows:
> container system {
>description
>  "Contains various system parameters.";
>container services {
>  description
>"Configure externally available services.";
>  leaf transport {
>enum ssh {
> description
>  "ssh";
>   }
>enum tls {
>description
> "tls";
>   }
>  }
>  container "ssh" {
>when "../transport=ssh" {
> description
> "active only when the transport is ssh";
>}
>description
>  "SSH service-specific configuration.";
>// more leafs, containers, and stuff here...
>  }
>  container "tls" {
>when "../transport=tls" {
> description
> "active only when the transport is tls";
>}
>description
>  "TLS service-specific configuration.";
>// more leafs, containers, and stuff here...
>  }
>}
>  }
> However I didn't see any guidance on when to use Choice case or when to use 
> Container+when?
> Any thought about this?
> 
> -Qin

> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod