Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson]

On 2019-04-26 13:28, Ladislav Lhotka wrote:

On Fri, 2019-04-26 at 12:56 +0200, Kristian Larsson wrote:


On 2019-04-26 09:39, Ladislav Lhotka wrote:

On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:

On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:

Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Agreed. The description only says (and only for ipv6-prefix


I think it says it for ipv4-prefix too:

...
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.";


This defines the canonical format, and Juergen explained its role earlier in
this thread.


Ah yes, I see now, you're right.




error? Ambiguity of what you are referencing makes it impossible for me
to parse your sentence. Please elaborate.

I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid
input that can safely be interpreted to mean 2001:db8::/64
- NSO instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?


I am not familiar with NSO. If it uses the the types from ietf-inet-types and
refuses to accept such input values from a NETCONF/RESTCONF client, then it
looks like a bug to me.


It does use these types so filing bug report I guess.

  
it does accept it, it must then store or at least always return it in

the canonical format?


RFC 7950 says in sec. 9.1 that the server MUST return values in the canonical
form and that the values are conceptually stored in the canonical form (in a
datastore).


Thanks for the reference, it helps! :)

Kind regards,
   Kristian.

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

Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson]

On 2019-04-26 13:18, Juergen Schoenwaelder wrote:

On Fri, Apr 26, 2019 at 12:56:57PM +0200, Kristian Larsson wrote:


I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid input
that can safely be interpreted to mean 2001:db8::/64
- NSO instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if it
does accept it, it must then store or at least always return it in the
canonical format?


I do not find anything in 6021+6991 that says 2001:db8::1/64 is
illegal input. If it were illegal, we would not need the definition of
the canonical format that is in 6021+6991. Apparently text could have
been more explicit but if you connect the bits and pieces, I think the
conclusion must be that 2001:db8::1/64 is allowed input, i.e., you do
not have to clear the bits that are irrelevant but the server will do
this since it has to return the value in canonical format.


Thanks for your time in answering this Juergen, much appreciated.

I think the canonical representation is quite clear as is the part that 
the server must return data (and conceptually store) in canonical 
format. What is much less clear is the allowed input formats which then 
includes 2001:db8::1/64. I think it could be worthwhile to explicitly 
state this as it is a bit surprising. Unlike say the uintX types, there 
is no "lexical representation" section for ip-prefix (I presume because 
they are not basetypes and so the lexical presentation follows the base, 
string in this case + the pattern) that explains things in any detail. 
Do you think we could add some clarifications, perhaps to the 
description of the type about this? Or could we even add a lexical 
representation section with examples? Or just an examples section?


Kind regards,
   Kristian.

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

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

[Kristian Larsson]

On 2019-04-23 12:55, Martin Bjorklund wrote:

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
easy.


By relying on the lexical order? Time zone is at the end so it will 
probably mess things up. Maybe that's why you said only *quite* ok.


Speaking of time-zone, shouldn't that be modeled as a separate leaf?

I think you could probably have a conversation around the combination or 
split of time / time-zone rather similar to the conversation we are 
having here about the combination or split of address / prefix-length.




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.


In some cases it might be better to have a ip*-address-and-prefix-length 
type than two separate leaves ;)




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


I can see how it is challenging with XPath but it seems equally as 
challenging with a combined leaf as with split leaves.


I think you were trying to argue for how it is beneficial to have split 
leaves, one for address and another for mask/prefix-length, as it makes 
filtering easier. I don't think you've shown that.




  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.


There are multiple opinions on what "it is" in this thread. 
authoritatively restating your opinion does not help. Juergen called 
this "what goes in" vs "the meaning".


Perhaps easier to agree on, is the information that is contained, which 
is a superset of "what goes in" and "the meaning"


1.2.3.4/24
^^^ - address
^^ -- prefix-length
^ + ^^ -- prefix

24 is a prefix-length and it is in there. I'm fine with anyone claiming 
that there is "prefix information" contained within 1.2.3.4/24,

Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson]

On 2019-04-26 09:39, Ladislav Lhotka wrote:

On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:

On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:


On 2019-04-18 13:12, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:

On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a
valid
integer value but the + will be dropped in the canonical
representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Agreed. The description only says (and only for ipv6-prefix


I think it says it for ipv4-prefix too:

  ...
  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.";



) that the host bits
should be zero, i.e. no strict requirement.
There is no strict requirement of what? Accepting the data? Throwing an 
error? Ambiguity of what you are referencing makes it impossible for me 
to parse your sentence. Please elaborate.


I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid 
input that can safely be interpreted to mean 2001:db8::/64

- NSO instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if 
it does accept it, it must then store or at least always return it in 
the canonical format?


   kll

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

Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson]

On 2019-04-25 23:51, Juergen Schoenwaelder wrote:

On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:



On 2019-04-18 13:12, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:

On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a valid
integer value but the + will be dropped in the canonical representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?



I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.


Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type 
ip-prefix (or ip6-prefix).


It would be interesting to hear Martins opinion on this.

Kind regards,
   Kristian.

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

Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson]

On 2019-04-18 13:12, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:

On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a valid
integer value but the + will be dropped in the canonical representation.


Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be rounded
if an integer input is expected?


The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.


Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax 
error, is that implementation incorrect?


   kll

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

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

[Kristian Larsson]

On 2019-04-18 18:02, Juergen Schoenwaelder wrote:

On Thu, Apr 18, 2019 at 03:14:20PM +0200, Per Hedeland wrote:


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


The property relevant for the network is the _prefix_, not the
prefix-length. 


Agreed.



The prefix-length 12 does not tell the system the
network prefix that is valid on the link, the prefix tells it. In
other words, you have a single value that gives you an address and a
prefix, hence ip-address-and-prefix. The question is whether we name
it according to the pieces that go into the combined value or whether
we name it according to the meaning of the combined value. What goes
in is "address + prefix length" and the meaning is "address + prefix".


Very good analysis on why we have different opinions for the name :)

I can tell someone "enter the address and prefix-length" and they will 
understand what I mean. I don't think it is clear what to enter if 
someone says "enter the address and prefix".. this is why I think 
ip*-address-and-prefix-length is the more natural name :)


Kind regards,
   Kristian.

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

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

[Kristian Larsson]

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




It
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?


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? 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.


  kll

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

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

[Kristian Larsson]

On 2019-04-18 09:40, Ladislav Lhotka wrote:

Juergen Schoenwaelder  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 
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 
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 
models but at least using standard datatypes allows us to easily parse 
the data into sensible datatypes on our end, like Python's 
ipaddress.IPv4Interface.


  kll

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

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

[Kristian Larsson]

On 2019-04-17 21:20, Juergen Schoenwaelder wrote:

Kristian,

I was instructed to upload draft-ietf-netmod-6991bis-00 without any
changes relative to draft-schoenw-netmod-6991bis-01 and this explains
why there is no address-with-prefix-length. The next version will have
definitions for ip-address-and-prefix, ipv4-address-and-prefix, and
ipv6-address-and-prefix - so not action needed from your side at this
point in time.


Ah, okay, I see! :)

Very well, then I'll leave Emacs alone ;)

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.


   kll






/js

On Wed, Apr 17, 2019 at 09:07:48PM +0200, Kristian Larsson wrote:

Juergen,

not sure where we really landed with this. I see 6991bis-00 is available but
without any of these types. I still think these data types makes sense and
would like to see them included. There are some people against and there are
some people for. Would it help if I wrote a few lines of YANG for this and
sent to you?

Kind regards,
Kristian.



On 2019-04-01 18:13, Juergen Schoenwaelder 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




___
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]

On 2019-04-02 20:48, Juergen Schoenwaelder wrote:

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. ;-)


I agree that it's useful and please avoid religious. Though I think 
ip-address-and-prefix-length is still two values at max. ip-prefix is 
two values in the common storage form since we typically use a fixed 
length 32 bit integer for storing an IP address and then need a second 
field to tell us how many bits are significant for the prefix. A more 
natural way of storing it could have used a variable length field in 
which case a /8 network really would only be 8 bit long (but then again, 
variable length field typically are stored as TLV or LV, so two values 
again... but way below our abstraction level now).




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.


This rings very true to me. Even if the IETF interfaces-ip model doesn't 
use these types, they are being used by Cisco, Juniper etc in their 
proprietary models, it's just that the type is currently string or 
something like that - if they could use a common IETF data type then it 
would be easier to cast this to a proper data type in a programming 
language, so like when you parse the config you'd get a Python 
ipaddress.IPv4Network object out of this or similar.


   kll

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

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

[Kristian Larsson]

Juergen,

not sure where we really landed with this. I see 6991bis-00 is available 
but without any of these types. I still think these data types makes 
sense and would like to see them included. There are some people against 
and there are some people for. Would it help if I wrote a few lines of 
YANG for this and sent to you?


Kind regards,
   Kristian.



On 2019-04-01 18:13, Juergen Schoenwaelder 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




___
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

[Kristian Larsson]

On 2019-04-01 22:51, Mahesh Jethanandani wrote:




On Apr 1, 2019, at 12:37 PM, Kristian Larsson  wrote:




On 2019-04-01 19:29, Martin Bjorklund wrote:
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" :)


Right you are, though I'm open to other names but let's first agree on use case 
/ need :)



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.


Dunno how "manual" has any bearing. This is IMHO just about natural data 
modeling.

You say it's two values but when one can't be used without the other, are they 
so separated? You can't configure an interface with just an address or just a 
subnet mask. You need both - they belong together.


That can be modeled into the data module, I.e. that you have to specify both 
the address and the prefix length.


I am aware. It wasn't for ip-prefix though, presumably because ip-prefix 
is more natural and so is ip-address-and-prefix-length.




The reason Martin mentioned two values is because even if they are modeled with 
a ‘/‘ character, the end system will consume them as two separate values
Not sure if you are arguing against me or just trying to explain :) I 
understand full well how it can be done and I'm saying I've written 
models like that. They are not elegant. Now I want the prettier way to 
do it and preferably with an IETF standardised data type, which is why 
I'm suggesting we add one in 6991bis. Two values or not, they belong 
together and should not exist without the other. The cost of using 
multiple leaves in YANG is quite high so for things that naturally 
belong together I think it's perfectly fine to make a datatype that 
includes the component values. We do it for ip-prefix already. In fact 
you could argue that the normal ipv6-prefix is a compound type since the 
zone is really a separate value from the address. Anyway, similar to how 
ip-prefix makes it easier to work with things likes routes in a routing 
table or how it simplifies the source and destination address matches in 
the ACL RFC we worked on together, an ip-address-and-prefix-length 
datatype will make other things easier which is why I'm suggesting it be 
added.


   kll

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

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

[Kristian Larsson]

On 2019-04-01 19:38, Acee Lindem (acee) wrote:


On 4/1/19, 1:30 PM, "Martin Bjorklund"  wrote:

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

Ok - I understand now.
 
 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.

Agreed. It seems a prefix with a prefix length of 32 for IPv4 or 128 for IPv6 
would allow specification.


No, it does not. You must be referring to some other use case. I want to 
configure the IP address and prefix-length on an interface. The 
prefix-length naturally needs to align with the prefix-length / subnet 
mask used on the network to which the interface is connected. If it is a 
/24 network then the prefix-length needs to be 24. I can't just say it's 
a /32 so I can enter this information - the router wouldn't understand 
what is then connected to that network / interface and wouldn't be able 
to route packets correctly.


At the same time, I need to specify the exact IP address to be used by 
this device on the interface, so I need to have bits set to the right of 
the mask, thus I can't use current ip-prefix type.




The convenience is primarily for mapping to CLI.


Heh, I don't understand what it has to do with CLI but since you're the 
second person mentioning there must be some connection I don't see.


Kind regards,
   Kristian.





 "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" 
 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 
<https://www.jacobs-university.de/>
 >
 > ___
 > 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

[Kristian Larsson]

On 2019-04-01 19:29, Martin Bjorklund wrote:

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


Right you are, though I'm open to other names but let's first agree on 
use case / need :)




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.


Dunno how "manual" has any bearing. This is IMHO just about natural data 
modeling.


You say it's two values but when one can't be used without the other, 
are they so separated? You can't configure an interface with just an 
address or just a subnet mask. You need both - they belong together.


Similarly, in a routing table you have prefixes, which consist of an 
address and a length - it got its own data type yet you could apply your 
argument to it and say they should be separated. It's just that *that* 
data type forbids bits to be set in the mask portion of the address, 
which is correct for the routing table use case, but means it can't be 
used to describe an interface address and mask.


   kll







/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"  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 <https://www.jacobs-university.de/>
 
 ___

 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] 6991bis: address-with-prefix-length

[Kristian Larsson]

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

[Kristian Larsson]

Gentlemen,

... snip snip...
On 2018-03-09 01:40, Mahesh Jethanandani wrote:
Choice of source port definition using range/operator or referring to a 
group of source ports, to be added as a future 'case' statement.



 - ditto for "or referring to a group of destination ports."
 - ditto on both of the above for the "udp" container
 - is it possible for both "egress-interface" and "ingress-interface" 
leafs to
   be specified at the same time?  - if not, should there a 'must' 
statement to
   prevent that possibility? - or an explanation for what happens if 
it occurs?


Let me discuss this with my co-authors.


It is possible to match both egress-interface and ingress-interface in 
the same ACL. Different devices support different type of attachment 
points for ACLs. Most routers, like an ASR9k or Juniper MX, supports 
attaching ACLs on interfaces in either ingress or egress direction. If 
we apply ACL FOO ingress on interface BAR then it would perhaps be weird 
to use the ingress-interface match in the FOO ACL since 
ingress-interface will always be BAR for every packet evaluated. Using 
egress-interface would make a lot more sense (and we will know the 
egress-interface if the platform performs the route lookup before 
evluating the ACL which is an implementation issue). We could introduce 
a must constraint to avoid a silly situation but I don't think that's a 
real improvement on the model.


Above all, considering the other type of attachment, which we find among 
others on Linux with iptables or nftables, which is a sort of "global" 
attachment point, it makes sense to be able to specify both. nftables 
rules are not written and attached to a particular interface but rather 
end up in a central list of rules and so it makes sense being able to 
write individual rules that match on ingress-interface, egress-interface 
or both (or none). A must constraint would make that impossible, so 
please don't add a must.


Kind regards,
   Kristian.

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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt

[Kristian Larsson]

On 2018-02-06 19:36, Mahesh Jethanandani wrote:

Kristian,

As I commented on the PR, putting the ‘container’ inside of the ‘choice’ 
statement allows me to collapse the ‘container’ and the ‘case’ statement into a 
single ‘container’ statement. With your changes, I see an additional ‘case’ 
statement, bloating the model in four places.


You are right and I see how you have moved the container from the types 
module. I think I was thrown off by making assumption on how things 
looked in my branch of the model rather than inspecting your history.


The original issue that I disliked here is that you have a container 
named source-port-range-or-operator which I think is a good name for a 
choice statement in the schema tree but is a horrible name for a node in 
the data tree. It should simply be "source-port". Can we please fix that?


I did place my containers and choice statements the other way around for 
even when we use a object reference I imagined that it would be under 
the source-port container, thus having that at the top makes sense. This 
is less important though, if we want to repeat that through the object 
reference augmentations that's fine.


   Kristian.




Cheers.


On Feb 6, 2018, at 1:42 AM, Kristian Larsson <krist...@spritelink.net> wrote:

Mahesh,

I suppose, since you posted the update Friday night, that I missed my chance of 
prettifying the source/destination port choice/container structure that was 
just added. If not, it's in a PR towards your repo - 
https://github.com/mjethanandani/acl-model/pull/4

Kind regards,
   Kristian.



On 2018-02-03 02:41, Mahesh Jethanandani wrote:

This update addresses the comments that were received as part of LC. For those 
of you who commented on the draft during the LC, please verify that your 
comments have been addressed.
Thanks.

On Feb 2, 2018, at 5:26 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Mahesh Jethanandani
  Lisa Huang
  Sonal Agarwal
  Dana Blair
Filename: draft-ietf-netmod-acl-model-16.txt
Pages   : 54
Date: 2018-02-02

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "" --> the assigned RFC value for this draft both in this
  draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
  draft gets approved.  The date also needs to get reflected on the
  line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Mahesh Jethanandani
mjethanand...@gmail.com
___
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


Mahesh Jethanandani
mjethanand...@gmail.com



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

Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt

[Kristian Larsson]

Mahesh,

I suppose, since you posted the update Friday night, that I missed my 
chance of prettifying the source/destination port choice/container 
structure that was just added. If not, it's in a PR towards your repo - 
https://github.com/mjethanandani/acl-model/pull/4


Kind regards,
   Kristian.



On 2018-02-03 02:41, Mahesh Jethanandani wrote:

This update addresses the comments that were received as part of LC. For those 
of you who commented on the draft during the LC, please verify that your 
comments have been addressed.

Thanks.


On Feb 2, 2018, at 5:26 PM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Network Access Control List (ACL) YANG Data Model
Authors : Mahesh Jethanandani
  Lisa Huang
  Sonal Agarwal
  Dana Blair
Filename: draft-ietf-netmod-acl-model-16.txt
Pages   : 54
Date: 2018-02-02

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "" --> the assigned RFC value for this draft both in this
  draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
  draft gets approved.  The date also needs to get reflected on the
  line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


Mahesh Jethanandani
mjethanand...@gmail.com

___
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] WG Last Call: draft-ietf-netmod-acl-model-15

[Kristian Larsson]

Mahesh,

I've reviewed this model, I think I largely caused the last couple of 
updates to it late last year. Overall I think it is a good model. 
Placement of feature-statements could be debated - no clear answers.
object groupings is something I would like to see in the model but it 
was always deferred.



On 2018-01-22 16:50, Kent Watsen wrote:

Hi Mahesh,

Thanks, it doesn't get much more concrete then a pull request  ;)

Okay, so from a chair/shepherd perspective, can folks please consider 
this update to -15 as the LC solution to removing the open issue Juergen 
found in the draft?


As a contributor, I don't think the name of the groupings or their 
description statements should allude to something that doesn't exist 
yet.  Rather than e.g. "source-or-group", could it be instead something 
like "source-type"?


+1

Also, the update seems to be for both when 
specifying networks as well as when specifying port-ranges, but the 
original issue (see below) only mentioned addresses - is the 
pull-request actually what's needed and the description of the issue in 
Section 8 is incomplete?


     8.  Open Issues

    o  The current model does not support the concept of "containers"

     used to contain multiple addresses per rule entry.


Object groupings are useful whenever there are many of something. There 
are usually more address entries than ports, so perhaps more useful for 
addresses, but it can still be useful to say "NFS-PORTS" and mean all 
the ports that NFS use (god knows what they are).


Other have mentioned scale ACL and that it can be solved in other ways. 
To me, this sort of object-groupings is not about optimising things for 
the hardware but rather making it easy for me to write rules. I think it 
is paramount for security that ACLs can be easily read and understood. 
If we do not understand them, then we cannot say they are effective and 
secure. Object groupings greatly improves the readability of ACLs and 
thus makes it easier to write secure ACLs.


I understand the authors wishes to get the first version out the door 
but I can't help but wonder if it isn't just easier to add in object 
groupings now. It's not that damn complicated (they are just lists).
If not, I'm happy to work with them on the next version which could 
include object groupings.


As for the PR to add choices, there seems to be an extra container 
inserted. I also made a comment on GitHub.
At the very least, I think it would be best if this PR is fixed and 
merged before we proceed.


   kll

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

Re: [netmod] IETF ACL model

[Kristian Larsson]

Robert Wilton <rwil...@cisco.com> writes:

> On 27/11/2017 13:17, Kristian Larsson wrote:
>> Robert Wilton <rwil...@cisco.com> writes:
>>
>>> Thinking about this some more. I'm not sure what it means for the "ACL
>>> Type" to be "any-acl". It seems that the "match any packet" should be a
>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a
>>> type of ACL.
>> Yes, I agree as so far that any-acl makes no sense as an acl-type. The
>> way I understood acl-type, and the way that vendors have told me it will
>> be used, is to say "this is an IPv4 ACL" and then on an attachment point
>> you can specify that only ACLs of acl-type ipv4-acl can be attached to
>> the interface. That makes perfect sense. I do not see how any-acl can
>> map into this.
>>
>> I agree that any-acl is logically a type of ACE but we don't have an
>> ace-type and the exact same information can IMHO already be conveyed
>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
>> need a feature for it.
>>
>> >From what I can tell the any-acl container in the ACE should be used to
>> explicitly signify a match on "any". Think of IOS style ipv4 acl:
>>permit ip any any
>>
>> We have to provide a source and destination so this would be a rather
>> explicit mapping of that. However, our structure in this YANG model is
>> just completely different than an IOS command so I don't see why we
>> should try and mimic IOS in the YANg model.
>>
>> Not specifying a destination IP address means we match on any
>> destination IP address. The same is true for any other field we can
>> match on. Not setting a match implies we don't try to match on that
>> field, thus we allow "any" value. I think the logical continuation of
>> this is that for an ACE with no matches defined at all, we match any
>> packet. I think we can update the text to better explain this.
>
>>
>>
>>
>>> Otherwise if the ACL type is "any-acl" then this only allows two types
>>> of ACLs to be defined, neither of which seem to be particularly useful:
>>> (1) An ACL that matches all traffic and permits it, i.e. the same as
>>> having no ACL at all.
>>> (2) An ACL that matches all traffic and drops.
>>>
>>> So I think perhaps the answer here is to define neither ACL type
>>> "any-acl" nor leaf "any". The presumption could be that any ACE that is
>>> configured to match no fields implicitly matches all packets (because
>>> all non specified fields are treated as wildcards), and then applies the
>>> permit/deny rule associated with the ACE. This logic can apply to all
>>> ACL types.
>> Yes yes yes :)
> Another area of the current model that I'm not quite convinced about is 
> about the L4 matches (UDP, TCP, ICMP).
>
> Currently the model assumes that if a device can support matching on say 
> UDP fields that they can apply to any type of ACL. However, I think 
> that it is plausible that the UCP, TCP and ICMP fields might only apply 
> to IP ACLs and not Ethernet ACLs.

Indeed, I agree with you. It's IMHO not just plausible but probable.
I think the model is a compromise between reality and perfectly
expressed constraints.

As I've alluded to I think the matches you can use are really not a
condition of the device but of the attachment point. Depending on where
you attach the ACL you will have different capabilities. Accurately
modeling this however, is very difficult and so the use of YANG features
limiting the ACLs themselves (and not what ACL can be attached
somewhere) to convey roughly what things are supported by the device is
a reasonable approximation.

For example, if we have two types of attachment points and one supports
matching on everything whereas the other does not, naturally our YANG
feature set must be the superset of the features supported by the two
attachment points or we could not even define those matches in the ACLs.
Trying to attach an ACL that matches on things that this attachment
point doesn't support will result in a run-time error. Similarly, the
match conditions supported is likely different based on what type of
linecard we have installed, which is AFAIK impossible to express in a
YANG model. We cannot condition this on the type of line card, since
that is state data and we can't do constraints from config to state.

I bet a bunch of the potential match conditions on IP header fields are
not supported by most devices today (think cheap commodity chips). Or
being able to match on TCP and a given port but not on TCP-flags...
there are lots of cases. The questio

Re: [netmod] IETF ACL model

[Kristian Larsson]

Robert Wilton  writes:

> Thinking about this some more. I'm not sure what it means for the "ACL 
> Type" to be "any-acl". It seems that the "match any packet" should be a 
> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a 
> type of ACL.

Yes, I agree as so far that any-acl makes no sense as an acl-type. The
way I understood acl-type, and the way that vendors have told me it will
be used, is to say "this is an IPv4 ACL" and then on an attachment point
you can specify that only ACLs of acl-type ipv4-acl can be attached to
the interface. That makes perfect sense. I do not see how any-acl can
map into this.

I agree that any-acl is logically a type of ACE but we don't have an
ace-type and the exact same information can IMHO already be conveyed
WITHOUT the any-acl type and thus it has no reason to exist. Nor do we
need a feature for it.

>From what I can tell the any-acl container in the ACE should be used to
explicitly signify a match on "any". Think of IOS style ipv4 acl:
  permit ip any any

We have to provide a source and destination so this would be a rather
explicit mapping of that. However, our structure in this YANG model is
just completely different than an IOS command so I don't see why we
should try and mimic IOS in the YANg model.

Not specifying a destination IP address means we match on any
destination IP address. The same is true for any other field we can
match on. Not setting a match implies we don't try to match on that
field, thus we allow "any" value. I think the logical continuation of
this is that for an ACE with no matches defined at all, we match any
packet. I think we can update the text to better explain this.



> Otherwise if the ACL type is "any-acl" then this only allows two types 
> of ACLs to be defined, neither of which seem to be particularly useful:
> (1) An ACL that matches all traffic and permits it, i.e. the same as 
> having no ACL at all.
> (2) An ACL that matches all traffic and drops.
>
> So I think perhaps the answer here is to define neither ACL type 
> "any-acl" nor leaf "any". The presumption could be that any ACE that is 
> configured to match no fields implicitly matches all packets (because 
> all non specified fields are treated as wildcards), and then applies the 
> permit/deny rule associated with the ACE. This logic can apply to all 
> ACL types.

Yes yes yes :)

   Kristian.

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Mon, Nov 06, 2017 at 07:16:11PM +, Kent Watsen wrote:
> 
> This closes the Last Call on this document.  There is
> clearly a lot of interest in the publication of an ACL
> model, but there also seems to be significant concern
> for how this model is structured.  It seems that we need
> to spend some more time to ensure the current structure
> is okay.  Based on the result of this discussion, we
> will then judge if this Last Call was successful of not.

I've probably ignited the most recent debate on this model. I'm
sorry for prolonging the process and preventing moving into RFC
but I really am not comfortable with the current structure.

Besides the structure, which is perhaps more subjective, I think
the model contains actual errors. For example, it appears that
there should be stats entries at the interface attachment points
but that data is config true and not config false and the leafref
doesn't match on the acl-type so it could point to any
acl-rule!? It's possible to match on conflicting data, like IPv4
and IPv6 or TCP and UDP in the same ACE, which just doesn't make
any sense at all. There is a match on interface but it is not
clear if this is ingress or egress interface. any-acl is empty!?

I am working on a couple of concrete suggestions for making a
more elegant model.

   kll

-- 
Kristian LarssonKLL-RIPE
+46 72 5479985k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Sat, Nov 04, 2017 at 10:38:45AM -0700, Sonal Agarwal wrote:
> Kristian,
> 
> In response to one of your previous comments:
> 
> "I'm really bothered by the compound key consisting of acl-type
> and the acl-name since attachment points then need to reference
> both.  It's also weird because I don't think choosing the
> acl-type is really a choice of the user but more of a limitation
> of the platform.
> 
> One approach would be to change the key to only be the acl-name
> but let the acl-type leaf remain, perhaps make it mandatory or
> default to some unified acl-type. I think it's still possible to
> implement a constraint on this, right? Like if a platform only
> supports a specific type at some attachment point it can add a
> constraint on the acl-type by doing deref() on the leafref."
> 
> The key for an ACL needs to remain as the name and type. They
> both uniquely define the presence of the ACL in config. 

You can't argue for a design choice by saying "this is how it
is". If we change the key to be acl-name only then it is the name
that "uniquely define the presence of the ACL in config".

What do you perceive as the benefit of having acl-type in the
key? Why can't it be an attribute? We can still check, from the
attachment point, what the acl-type is.

   kll

-- 
Kristian LarssonKLL-RIPE
+46 72 5479985k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14 - acl-type in list key?

[Kristian Larsson]

Another question somewhat related to attachment point. Why is
acl-type part of the list key?

I think compound keys are really quite clunky and should be
avoided if possible. In this case I really don't see why acl-type
needs to be part of the list key.

For the list of ACLs it means that the acl-name needs to be
unique instead of the combination of the type and name. This
seems rather uncontroversial to me.

Is it because we want to have constraints on the acl-type? ISTM
that we can apply such constraints anyway.

I just don't understand why it's part of the list key. Can it
please be removed?

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Thu, Nov 02, 2017 at 07:10:30PM +0630, Mahesh Jethanandani wrote:
> Ok. Will update the model to reflect the discussion on this thread.

Mahesh, would it be helpful if I prepared changes in the form of
pull requests on the github repo?

I can write code, we can discuss it here and merge once agreed?

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Thu, Nov 02, 2017 at 03:20:34PM +0630, Mahesh Jethanandani wrote:
> Kristian,
> 
> I hear you. What I am providing is the rational for the current design. 

Ok, thank you! That is valuable to me so please don't stop :)


> I would like to hear from others in the WG. We have been
> reviewing this draft for the last couple of years, and we are
> now at the tail end of the LC.

Believe me, I have no intention of stopping this draft. I just
want to improve it.

I actually wanted to start using it earlier this year but found
the structure so unwieldy to work with that I eventually gave up
and instead decided to try and improve the model. It took a wee
bit longer than I intended but here I am.

For the interested, I wanted to build a YANG translation service
in NCS (now Cisco NSO) that could translate ACLs from one format
into the native format of four different vendors. I currently
keep feature parity across four different platforms and doing
that for something like ACLs is highly error prone.


> I would really like to see this draft move forward,
> particularly since it is not broken.

I want to have a standard ACL model too.

I am not complaining just for the sake of complaining, it is
because I found the structure unnatural or otherwise difficult to
use. I will try my best to not just criticise but instead provide
actual suggestions on how to improve things.

Kind regards,
   Kristian.

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Thu, Nov 02, 2017 at 05:38:02PM +, Robert Wilton wrote:
> 
> 
> On 02/11/2017 16:41, Kristian Larsson wrote:
> >On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote:
> >>   feature mixed-ipv4-acl {
> >> if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
> >> description "Layer 2 and Layer 3 IPv4 ACL supported";
> >>   }
> >>   ...
> >Features dependent on features... inception. I didn't even know
> >this was possible with YANG. Learned something today \o/
> This just means that a device cannot say that it supports a "mixed-ipv4-acl"
> ACL unless it supports classifying traffic on Ethernet and classifying
> traffic on IPv4.
> 
> So the 'match type' feature specify what header fields the hardware is
> capable of match on.  E.g. a basic L2 device might say that is only matches
> on the Ethernet header.
> 
> The "ACL types" features specify what combination of header fields can be
> combined into a single ACL.

Ah, right. Sorry, I was thinking that match-on-l2-eth-hdr and
match-on-ipv4-hdr would imply mixed-ipv4-acl. My bad.


> The real benefit for defining "match type" is that the unsupported fields in
> the ACL can then be cleanly left out of the device schema.  E.g. a
> hypothetical new breed of IPv6 only routers that only support matching on
> match-on-ipv6-hdr, and don't want to carry v4 baggage.

Since I work for a network that aspires of being v6 only I quite
like this ;)


> >Are we seeking to have a single style of attachment points? I
> >think that's difficult in reality. Linux has one style, where a
> >single global "ACL" is defined. Most routers use per interface
> >ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> >v6). I doubt one can be said to be better than the other so
> >trying to argue that everyone should converge on one way is
> >pointless. Similarly supporting every different style is also
> >futile as it's completely against the point of standardisation.
> >
> >The pragmatic compromies is likely to support a few ways and any
> >vendor that needs something radically different need to build
> >their own model, do augment, deviate, refine or whatever. Other
> >thoughts?
> For interface attachments I think that the approach in the draft looks OK,
> and reasonably generic, but will need vendor deviations. This is probably
> OK.

I don't agree. Given the length we've gone in trying to convey the
match capabilities of the platform I think we can afford to give
implementors some options when it comes to attachment too! :)

Arguing that one way of doing ACL attachment is better than
another is futile and my personal opinion is that there simply is
no one way that's better than all else. A single global
attachment point like what Linux does is not better or worse from
the per interface ACL style that most router vendors employ. It's
just different. I believe the model should allow vendors and
users to express the most common forms we currently have. Not all
ways, but the two or three most common ways, which probably
covers the vast majority of all platforms.

The current model is an ill fit for platforms that attach filters
globally, like most host firewalls (Linux *tables, OpenBSD pf,
FreeBSD ipfw etc) or the vast majority of firewalls (Juniper SRX,
Cisco ASA, Checkpoint etc). There must be different attachment
options for "per interface" vs "global". 

As for the per-interface style options
 * current draft; a list of ACLs of varying "type", evaluated in
   specified order, per-interface and per direction
 * three separate ACLs for ethernet, ipv4 and ipv6 and
   per-interface and per direction

The only vendor I know of that have a single attachment point on
an interface is Huawei. However, it's not just an attachment
point for ACLs but for what Huawei calls a "traffic-policy" which
mixes in ACLs and QoS in the same place. It is so different from
everything else that deviations or augmentations will no doubt be
required to express what they have. The other large router
vendors; Cisco, Juniper and Nokia, all use separate attachment
points for ipv4, ipv6 and ethernet.

Shouldn't we have a model that supports;
 * virtually all host network stacks
 * virtually all firewalls
 * the vast majority of high end routers

Rather than:
 * no currently existing platform (or is there one I don't know of?)


> Personally, I would put the ACL interface attachment points as an
> augmentation of if:interfaces/interface rather than having a separate top
> level list, but perhaps that is just want I am used to ...

+1 on augmentation of interfaces.

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Thu, Nov 02, 2017 at 12:53:29PM +, Robert Wilton wrote:
> One further refinement might also be to make the ACL type features a bit more
> hierarchical as well, but I don't know if that makes it too complex?

I was pondering this for a bit but I'm not sure it actually
helps.

> For example, the model could define separate features for what type of ACE
> matching is supported by the device, separately from what types of ACE
> combinations are allowed.
> 
> E.g.
> 
> // New 'match type' features.
> 
> feature match-on-l2-eth-hdr {
>// Device can match on L2 Ethernet header fields.
> }
> feature match-on-ipv4-hdr {
>// Device can match on IPv4 header fields.
> }
> feature match-on-ipv6-hdr {
>// Device can match on IPv6 header fields.
> }
> 
> 
> The existing ACL type features could then depend on these:
> 
> 
>   feature l2-acl {
> if-feature "match-on-l2-eth-hdr";
> description "Layer 2 ACL supported";
>   }
> 
>   feature ipv4-acl {
> if-feature "match-on-ipv4-hdr";
> description "Layer 3 IPv4 ACL supported";
>   }
> 
>   feature ipv6-acl {
>if-feature "match-on-ipv6-hdr";
>    description "Layer 3 IPv6 ACL supported";
>   }
> 
>   feature mixed-ipv4-acl {
> if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
> description "Layer 2 and Layer 3 IPv4 ACL supported";
>   }
>   ...

Features dependent on features... inception. I didn't even know
this was possible with YANG. Learned something today \o/

Anyway, I don't think you can actually deduce that a device
supports an ACL that maches on ethernet and IPv4 based on that it
supports matching on Ethernet headers and IPv4 headers.

For example, on IOS XR there are "ethernet-service access-list"
which can match on Ethernet headers but they are distinct from
ipv4 access-list and they use different attachment points under
an interface. IPv6 is yet another ACL with its own attachment
point... you cannot mix them in the same ACL. I guess they are
logically evaluated in order, so ethernet first, and if it passes
that then the ipvX ACL is evaluated. I believe the situation is
similar on JUNOS.

Which brings us to how to define attachment points. By using YANG
features a device can declare what ACL types it supports but if
the device has different attachment points then there should
probably be some constraint on what ACL type is attached where.

Are we seeking to have a single style of attachment points? I
think that's difficult in reality. Linux has one style, where a
single global "ACL" is defined. Most routers use per interface
ACL and as seen, they split it up on ethernet vs IP (and v4 vs
v6). I doubt one can be said to be better than the other so
trying to argue that everyone should converge on one way is
pointless. Similarly supporting every different style is also
futile as it's completely against the point of standardisation.

The pragmatic compromies is likely to support a few ways and any
vendor that needs something radically different need to build
their own model, do augment, deviate, refine or whatever. Other
thoughts?

An example (from the top of my head so excuse syntax errors):


grouping interface-attach {
  choice attach-style {
case mixed {
  if-feature mixed-acl;
  leaf-list mixed {
description "Any type of ACL that can match on ethernet, ipv4, ipv6 or 
anything else";
ordered-by user;
type leafref {
  path "/access-list/acl/acl-name"; // we can apply any acl-type
}
  }
}

case specific-acl {
  if-feature specific-acl;

  leaf-list ethernet {
description "ACL for Ethernet";
ordered-by user;
type leafref {
  path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, eth-acl)';
  }

  leaf-list ipv4 {
description "ACL for IPv4";
ordered-by user;
type leafref {
  path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, ipv4-acl)';
  }

  leaf-list ipv6 {
description "ACL for IPv6";
ordered-by user;
type leafref {
  path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, ipv6-acl)';
  }
}
  }
}

// ACLs attached under interface, like most big routers do it
augment "/if:interfaces/if:interface" {
  if-feature interface-acl;
  container acl {
description
  "ACL attachment point";

container ingress {
  uses interface-attach;
}
container egress {
  uses interface-attach;
}
  }
}


// ACL globally att

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote:
> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> Mahesh,
> 
> I think the question is why we need to have different match containers
> for each possible feature set combination instead of having a single
> match container with groups of leafs in it marked as features. This
> would seem to cut down the size of the module and the tree diagram
> significantly. I think this will also make clients simpler sicne they
> do not have to select a certain container based on the feature set
> announced. 
> 
> 
> The current design of match containers was chosen to allow platforms to select
> one container that matched what the hardware supported from a l2, l3 and ipv
> {4,6} perspective.

Sure, but you are conflating the structure of the model with the
feature-wraps. Without changing the features of the model, we can
structure it in a different way where there is not a 1:1 mapping
between features and containers under the matches container.


> I would argue that even though the overall diagram is bigger
> with this design, once the platform selects the container of choice, the tree
> and the configuration itself would be a little simpler/smaller. 

I am arguing the opposite. It's really awkward to place the same
type of data, like IPv4 match conditions, under different paths
based on a feature.

If the system model had done the same we would have:
/system
/system-with-ntp
/system-with-ntp-and-radius

How do you augment in new leaves? While you are using groupings
which allows for a reuse of data across all these containers,
someone who is augmenting can't, since you can't augment a
container, only where it is used. Someone wishing to add a leaf
to the model needs to augment in three different locations to
support a new match condition for IPv4 (let's say some meta-data
attribute).


> Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The 
> current
> tree looks like this:
> 
> 
> ||  +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}?
> ||  |  +--rw destination-mac-address?yang:mac-address
> ||  |  +--rw destination-mac-address-mask?   yang:mac-address
> ||  |  +--rw source-mac-address? yang:mac-address
> ||  |  +--rw source-mac-address-mask?yang:mac-address
> ||  |  +--rw ethertype?  eth:ethertype
> ||  |  +--rw dscp?   inet:dscp
> ||  |  +--rw ecn?uint8
> ||  |  +--rw length? uint16
> ||  |  +--rw ttl?uint8
> ||  |  +--rw protocol?   uint8
> ||  |  +--rw source-port-range!
> ||  |  |  +--rw lower-portinet:port-number
> ||  |  |  +--rw upper-port?   inet:port-number
> ||  |  |  +--rw operation?operator
> ||  |  +--rw destination-port-range!
> ||  |  |  +--rw lower-portinet:port-number
> ||  |  |  +--rw upper-port?   inet:port-number
> ||  |  |  +--rw operations?   operator
> ||  |  +--rw ihl?uint8
> ||  |  +--rw flags?  bits
> ||  |  +--rw offset? uint16
> ||  |  +--rw identification? uint16
> ||  |  +--rw destination-ipv4-network?   inet:ipv4-prefix
> ||  |  +--rw source-ipv4-network?inet:ipv4-prefix
> ||  |  +--rw next-header?uint8
> ||  |  +--rw destination-ipv6-network?   inet:ipv6-prefix
> ||  |  +--rw source-ipv6-network?inet:ipv6-prefix
> 
> ||  |  +--rw flow-label?
> ||  |  inet:ipv6-flow-label
> 
> 
> 
> whereas, if the design went with one match container with each group of leafs
> in their own container (to support the if-feature statement for that
> container), the tree would look like this:
> 
> 
> ||  +--rw l2-acl {l2-acl}?
> ||  |  +--rw destination-mac-address?yang:mac-address
> ||  |  +--rw destination-mac-address-mask?   yang:mac-address
> ||  |  +--rw source-mac-address? yang:mac-address
> ||  |  +--rw source-mac-address-mask?yang:mac-address
> ||  |  +--rw ethertype?  eth:ethertype
> 
> ||  +--rw ipv4-acl {ipv4-acl}?
> ||  |  +--rw dscp?   inet:dscp
> ||  |  +--rw ecn?uint8
> |  

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

I think there's a problem with the current approach for features
where it conflates the limitations of the device with the
limitations of an attachment point.  Ultimately it is the
limitations of the attachment point that matter. Creating an ACL
in config on a device doesn't actually mean anything until you
attach it somewhere.

It's not hard to imagine a device where different limitations
apply, let's say a fairly simple Ethernet switch built on some
commodity chip. It consists of, say:
 * 24 * 10GE on a commodity chip
 * some control plane (a x86 PC) connected to that commodity chip

The commodity chip supports matching ethernet headers, so ACLs
attached to those ports are "eth-acl". The control plane on the
other hand supports complex matching on anything you can imagine.
What YANG features should such a device advertise?

   kll




On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote:
> Mahesh,
> 
> On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> > I think there is confusion in how the ACL model is going to be
> > implemented by vendors and used by customers.
> >
> > As Eliot alluded to, the model is trying to address the issue
> > of the capabilities of each platform as they exist across the
> > industry but also within each vendor. So the first thing an
> > implementation would do is to pick which feature they do
> > support. A low end platform that supports only layer 2 ACL will
> > pick l2-acl as their feature, while a high end router capable
> > of support l2 and l3, ipv4 and ipv6 ACL will declare
> > l2-l3-ipv4-ipv6 as the feature they support. That pretty much
> > takes out all the other containers in the matches container.
> > The additional features they might want to choose include
> > support for TCP, UDP and ICMP. For a high end router this boils
> > down to having definitions for
> > 
> > - ethernet
> > - ipv4
> > - ipv6
> > - tcp
> > - udp
> > - icmp
> > 
> > which is the list you have in mind, but this time making sure
> > that the platform is capable of supporting each one of the
> > definitions. Imagine if the low end platform advertised a model
> > for all the above capabilities only to reject them when you
> > tried to configure a ipv6 address that it already knows it
> > cannot support.
> 
> You imply that the low end platform would advertise features that
> it doesn't support. Why would it do that?
> 
> I don't suggest removing features - only restructure where the
> data is held.  In my example, under the ethernet container I can
> do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
> device supports a given feature so why are you saying that we
> need different containers for the ethernet matching part of an
> ACL of type eth-acl vs say eth-ipv4-acl?
> 
> Right now the features themselves affect the structure of the
> model and thus the data, which I rather dislike. The config to
> match e.g. ethernet headers should always go in the same place.
> 
> The model gives the illusion of supporting "unified" ACLs but
> actually doesn't at all.
> 
> 
> > Similarly the condition on tcp/udp/icmp container is to make
> > sure the platform is capable of supporting them. Only if the
> > platform declares tcp-acl, udp-acl, and icmp-acl feature, will
> > those containers be visible from a configuration perspective.
> 
> And if the device supports all of those features I can write an
> ACE that matches on TCP flags at and ICMP types.. and it would
> validate according to the model but cleary makes no sense.
> 
> > The acl-type is used as a check to make sure the user is aware
> > what kind of ACL the platform supports and the ACL they are
> > trying to configure matches the acl-type. If the platform
> > declared the feature l2-acl and if the user tries to set the
> > ACL type to l2-l3-ipv4-ipv6 then the configuration would be
> > rejected.
> 
> Another way of structuring this is to have completely different
> lists of ACLs where each type of ACL is its own list, e.g.
>  * eth-acl
>  * ipv4-acl
>  * ipv6-acl
>  * eth-ipv4-ipv6-acl
> 
> What advantage do you think your currently proposed model holds
> over such an approach?
> 
> What are your thoughts on the attachment point using two leaves?
> Are you satisfied with this?
> 
> 
> > In the Linux/nftables case, the platform should
> > declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and
> > icmp-acl if that is what it wants to support. The interface
> > attachment point has been defined but it is not mandatory that
> > a configuration has to define it. So if in Linux, the ACL list

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

Mahesh,

On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> I think there is confusion in how the ACL model is going to be
> implemented by vendors and used by customers.
>
> As Eliot alluded to, the model is trying to address the issue
> of the capabilities of each platform as they exist across the
> industry but also within each vendor. So the first thing an
> implementation would do is to pick which feature they do
> support. A low end platform that supports only layer 2 ACL will
> pick l2-acl as their feature, while a high end router capable
> of support l2 and l3, ipv4 and ipv6 ACL will declare
> l2-l3-ipv4-ipv6 as the feature they support. That pretty much
> takes out all the other containers in the matches container.
> The additional features they might want to choose include
> support for TCP, UDP and ICMP. For a high end router this boils
> down to having definitions for
> 
> - ethernet
> - ipv4
> - ipv6
> - tcp
> - udp
> - icmp
> 
> which is the list you have in mind, but this time making sure
> that the platform is capable of supporting each one of the
> definitions. Imagine if the low end platform advertised a model
> for all the above capabilities only to reject them when you
> tried to configure a ipv6 address that it already knows it
> cannot support.

You imply that the low end platform would advertise features that
it doesn't support. Why would it do that?

I don't suggest removing features - only restructure where the
data is held.  In my example, under the ethernet container I can
do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
device supports a given feature so why are you saying that we
need different containers for the ethernet matching part of an
ACL of type eth-acl vs say eth-ipv4-acl?

Right now the features themselves affect the structure of the
model and thus the data, which I rather dislike. The config to
match e.g. ethernet headers should always go in the same place.

The model gives the illusion of supporting "unified" ACLs but
actually doesn't at all.


> Similarly the condition on tcp/udp/icmp container is to make
> sure the platform is capable of supporting them. Only if the
> platform declares tcp-acl, udp-acl, and icmp-acl feature, will
> those containers be visible from a configuration perspective.

And if the device supports all of those features I can write an
ACE that matches on TCP flags at and ICMP types.. and it would
validate according to the model but cleary makes no sense.

> The acl-type is used as a check to make sure the user is aware
> what kind of ACL the platform supports and the ACL they are
> trying to configure matches the acl-type. If the platform
> declared the feature l2-acl and if the user tries to set the
> ACL type to l2-l3-ipv4-ipv6 then the configuration would be
> rejected.

Another way of structuring this is to have completely different
lists of ACLs where each type of ACL is its own list, e.g.
 * eth-acl
 * ipv4-acl
 * ipv6-acl
 * eth-ipv4-ipv6-acl

What advantage do you think your currently proposed model holds
over such an approach?

What are your thoughts on the attachment point using two leaves?
Are you satisfied with this?


> In the Linux/nftables case, the platform should
> declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and
> icmp-acl if that is what it wants to support. The interface
> attachment point has been defined but it is not mandatory that
> a configuration has to define it. So if in Linux, the ACL list
> is global, one would not define a attachment point, which
> implies it is a global list.

Naturally one has to define an attachment point or the system
wouldn't know which one of potentially multiple ACLs to apply to
nftables. It might however be up to another YANG model to define
that attachment point.

The list of features seem to align poorly with reality. How can
we have a list of attachment points in the model but without
if-feature wrapping it? Surely a Linux machine must be able to
announce that it doesn't support per-interface ACLs? A side
question is why that attachment list exists in the first place -
why isn't it an augmentation of the interfaces module?

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> Hi Kristian,
> 
> Just my view below:
> 
> 
> On 10/31/17 11:25 AM, Kristian Larsson wrote:
> 
> > This brings us to the acl-type. It seems to me that this is
> > primarily for being able to do YANG validation when a device does
> > NOT support a unified model. I.e. if Linux nftables was all we
> > wanted to model, then we wouldn't need this and the only
> > (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> > need acl-type because most current network devices out there have
> > per-AFI types and we want to be able to say:
> >  * this interface attachment point can only do ipv4-acl
> > And still be able to validate the data based on the YANG model.
> > Is this correct? It seems like one hell of a design trade-off to
> > be able to achieve that. Wouldn't we be better off with actually
> > having different list of ACLs, again vastly simplifying the
> > attachment points and making data validation much easier?
> 
> This reflects, IMHO, the complexity of the situation.  You want
> consistent policy implemented to the full extent of device
> capabilities.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.


>  That means that if someone wants to generate a mixed mode
> ACL, they can.  But if we attempt to separate those mixed modes on the
> device, can we guarantee that we have gotten the intent correct and
> consistent with, say, what would have been the mixed mode?  I think
> that's how we got here but others can speak more authoritatively.  And
> keep in mind, all of this ties to efficient use of device resources, and
> so there's a lot of h/w optimization seemingly going on here.

So how is the current situation better than doing:

module: ietf-access-control-list
+--rw access-lists
   +--rw acl [acl-name] <<< this is the unified one
   |  +--rw acl-namestring
   |  +--rw aces
   | +--rw ace* [rule-name]
   |+--rw rule-name  string
   |+--rw matches
   ||  +--rw ethernet
   ||  +--rw ipv4
   ||  +--rw ipv6
   |...

   +--rw ipv4-acl* [acl-name]
   |  +--rw acl-namestring
   |  +--rw aces
   | +--rw ace* [rule-name]
   |+--rw rule-name  string
   |+--rw matches
   ||  +--rw ipv4
   |...

   +--rw ipv6-acl* [acl-name]
   |  +--rw acl-namestring
   |  +--rw aces
   | +--rw ace* [rule-name]
   |+--rw rule-name  string
   |+--rw matches
   ||  +--rw ipv4
   |...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
leaf ingress-acl {
  type leafref {
  path "/acl:access-lists/acl/acl-name";
}
must 'yangexp:deref(.)/../acl-type="ipv4-acl"';
}
  }
}

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,
   Kristian.

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

s "In ordet to apply an ACL to any attachment
   point, vendors would have to augment the ACL YANG model", is
   this really true? Surely we have standard attachment points.
 * in 1. the examples of use start with policy based
   routing and then firewalls. ISTM that ACLs are primarily used for
   "packet filters" so it's weird it's not even included.
   Firewall often implies statefulness, which is not really what
   we are dealing with here and PBR is not nearly as use as
   packet filters. Maybe everyone knows this already, but then
   why write anything at all?
 * in 1. "in case vendors supports it, metadata matches apply.." why
   include a condition on if the vendors supports it? this is
   true for anything, "in case the vendor supports it, the BGP
   routing protocol works this way...". I think we can require
   certain metadata matches in the model, or just do if-feature,
   but constantly prefixing everything with a "in case vendor.."
   is unnecessary IMHO
 * in 1. ISTM: s/networked devices/networking device/
 * in 3. "each ACE has a group of match criteria and a group of action
   criteria" - no, it does not, actions are not a criteria!?
 * indent is mix of tabs and spaces
 * the icmp-off action leaf is IMHO weirdly modeled and it's a
   weird option in itself - can you point to vendors implementing
   similar options? this seems doable by just having an ACE match
   on ICMP and action=drop
 * why eth-acl vs l2-acl. this is mixing apples and pears. L2 is
   a layer in the TCP/IP model whereas ethernet is one
   implementation of an L2 protocol. Why name the identify
   eth-acl and the match container l2-acl?
 * why have the "acl-sets" container? why not just have the list
   directly?
 * the leafrefs in the interface-acl grouping are relative making
   it impossible to re-use the grouping at a different "depth"
 * letting the matched-packets be EITHER per-interface per-ACE OR
   per-ACE across all interfaces seems insane. We have to know
   what we are getting back. Better to have separate counters
   then and let vendor fill in one or the other? Or declare
   deviations? Curreny mode is not useful at all.

Again, apologies for my ignorance.

Kind regards,
   Kristian.


-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] why is the alarm YANG work being done in CCAMP?

[Kristian Larsson]

I agree, I think this belongs in NETMOD.

I'd also like to say that we, the TeraStream team of Deutsche
Telekom, are currently implementing support for the alarm module.
This work is happening in both our NMS (consisting partly of
Tail-F NCS as well as other components producing / consuming the
alarm module) and in devices, where our home grown lwAFTR will
probably be the first implementation. It's using open source
software in the form of Snabb (https://github.com/snabbco/snabb)
for dataplane and the NETCONF / YANG stack consists of netopeer2
and sysrepo (another open source project we're involved with).

Kind regards,
   Kristian.



On Mon, Jul 17, 2017 at 04:16:16PM +0200, Dan Romascanu wrote:
> Hi,
> 
> I am sorry if I am late to observing this. Please feel free to bash me and
> point to where this discussion already took place. I just heard in the NETMOD
> WG meeting that draft-vallin-netmod-alarm-module is going to be undertaken by
> the CCAMP WG. What is the reason? The problem space of Alarm management data
> model seems IMO pretty generic, and on the other side I cannot see what is
> CCAMP-ish or even RTG Area specific in this work.
> 
> Thanks and Regards,
> 
> Dan
> (one of the authors of RFC 3877)

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


-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] modelling of packet-action WG Last Call for draft-ietf-netmod-acl-model-11

[Kristian Larsson]

Pardon my ignorance as this might have been asked before but why
is the actions/packet-handling modelled as a choice? It would
seem an identity would be better or perhaps even an enum?

   kll

On Fri, Jul 07, 2017 at 06:34:28PM +, Kent Watsen wrote:
> 
> 
> This is a notice to start a three week NETMOD WG last call for the
> document:
> 
> Network Access Control List (ACL) YANG Data Model
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11
> 
> Note: Three weeks is more than needed, especially given this 
>   draft has been through Last Call before, but we understand
>   folks are busy these days.
> 
> Please indicate your support or concerns by Friday, July 28, 2017.
> 
> We are particularly interested in statements of the form:
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issues: ...
> 
> As well as:
>   * I have implemented the data model in this draft.
>   * I am implementing the data model in this draft.
>   * I am considering to implement the data model in this draft.
>   * I am not considering to implement the data model in this draft.
> 
> Thank you,
> NETMOD WG Chairs
> 
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-11

[Kristian Larsson]

On Mon, Jul 17, 2017 at 05:11:48PM +0200, Juergen Schoenwaelder wrote:
> On Mon, Jul 17, 2017 at 04:18:47PM +0200, Lou Berger wrote:
> > All,
> > 
> > Per our discussion in today's session, another version of this draft
> > is needed to address open issues.  As this revision will include
> > technical changes, another LC will be needed after that version is
> > published.
> > 
> > Please do comment on this version, but be aware this version will *not*
> > be submitted for publication.
> >
> 
> I planned to review this I-D but I will now wait for the next
> version. ;-) However, a few things I already noted:
> 
> - The identifiers are long, I think this was discussed before. I
>   suggest to replace 'source' with 'src' and 'destination' with
>   'dst'; this will likely also make the tree diagram fit the
>   traditional RFC format again.
> 
> I am not sure about the idea to spell out all the mixed-x-y-z
> combinations. This may turn out costly to maintain long term.
> 
> The naming is also inconsistent I think. My understanding is that
> mixed-l2-l3-ipv4-acl really means mixed-eth-ipv4-acl. In fact,
> ipv4-acl is actually l3 and possibly l4 since the grouping
> acl-ip-header-fields uses acl-transport-header-fields. You can skip
> the l4 portions since they are in a presence container. Note that this
> is different from how you deal with l2 and l3 combinations.

+1, this bothered me too when reading the model. IPv4 and IPv6 is
explicitly named while L2 just implies Ethernet. Should have
eth-ipv4-acl in the name, or eth-ipv6-acl.. or if we support
matches for other L2 technology then include that in the name.
While Ethernet is popular we do still have other L2 technologies.

> I guess I
> would generally prefer a solution that is more orthogonal
> wrt. layering and likely not causing maintenance headaches in 5-10
> years from now.

I don't immediately see a better way of doing it. It is rather
tricky.


> That said, I am not planning to implement this YANG module myself so
> as long as multiple implementors think this is all good, it might be
> sufficient to simply fix terminology and naming to be clear, concise
> and consistent.

I'm trying to implement it, as a user :)

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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