On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
> Juergen,
>
> Please see answers inline
>
> Dean
>
> > On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder
> > <[email protected]> wrote:
> >
> > On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
> >>
> >> This email initiates a NETMOD WG Last call for
> >> draft-ietf-netmod-acl-model-06.
> >> Please review the draft and make any comments to the list by Wednesday, 16
> >> December, 2015
> >> by 8AM EST.
> >>
> >
> > Technical
> >
> > - I am not sure I personally like the acl-oper-data and ace-oper-data
> > containers in the middle of the config true tree. I understand that
> > operational state in this case is likely tightly bound to the
> > lifetime of the config state but I also generally prefer to have a
> > clean separation of config from state. But since I am not
> > implementing this, I am happy to leave the decision to those who
> > write the code.
> >
> > - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
> > instead of source-ipv4-network and destination-ipv4-network and
> > I would probably have used src-mac-address and src-mac-address-mask
> > and dst-mac-address and dst-mac-address-mask. Generally simple
> > src instead source and dst instead destination - lines up all
> > much more nicely.
>
> I know that src and dst are pretty standard abbreviations, but have
> preference to use full words.
>
My eyes prefer the shorter versions but it might be subjective where
the line between arconyms and words is drawn. For me, things are not
done consistently according to my personal preferences. ;-)
> > - I would have put the acl-name and acl-type first followed by the
> > entries list.
>
> Can you please expand on this? Is there any major difference? OR just design
> choice?
Technically you can define key leafs anywhere but I think there are some
benefits of defining them at the beginning of a list:
a) I find it nice if the leafs listed in the key statement follow the
key statement and not N pages down the document.
b) If you put them at the end and you have to add additional definitions,
you will end up with leafs somewhere in the middle.
c) The XML encoding requires to ship key leafs first and it might be
simpler if the key leafs are also defined first in the data model
(so if you use the same order, you actually get things correct).
Now you tell me what the advantages are to put them at the end...
> > - I also wonder why we use both the term 'entry' and 'rule', why not
> > pick one of them? You have for example rule-name (which is the key
> > of the list but again comes last).
> This is a bit of compromise between Cisco and Juniper terminology. In Cisco
> it is ACE and in Juniper term. But in the yang model and in the text we are
> using consistently one or the other word.
For the sake of clarity, I personally would prefer to have a single
term. I think Linux packet filters call things rules. I think BSD
packet filtering calls things rules. Wikipedia seem say that packet
filters consist of filtering rules... So I guess I have a preference
but I will not get a sleepless night over this.
> > - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
> > we expect that all implementations will always support all three?
> > Another option would be to have the generic model completely without
> > any protocol specific elements and to have separate models to
> > augment in ipv4, ipv6, and ethernet specific ace types. I actually
> > think this would make much more sense since you would not have a
> > module 'packet fields' but instead a clear extension of the
> > ietf-access-control-list module. You could also drop the examples
> > how to extend the core model since the ip and ethernet extensions
> > would already serve the purpose. You also would not need features
> > since an implementation advertises the extension modules.
>
> We started early with such design, but then the WG feedback moved us to the
> current design.
Can you provide pointers to minutes etc? I think the routing model
also has a core model where even unicast routing is augmented in. This
seems to make the boundary between the generic infrastructure and the
addins very clear.
> > - The 'uses packet-fields:metadata' resolves to a leaf
> > 'input-interface' which is of type string. Is this the only metadata
> > field we ever envision to be there? If so, why not make it part of
> > the base model? If not, what is the extensibility model here?
>
> It can be used for route filtering
Yeah, but the questions were:
- Is this the only metadata field we ever envision to be there?
- If so, why not make it part of the base model?
- If not, what is the extensibility model here?
> > And
> > should the interface reference not use a more specific type than
> > 'string’?
>
> Interface references can be many things, from standard naming we are
> familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as
> string gives us most flexibility in that regards.
I disagree that the goal here is most flexibility. We do have an
interfaces data model in the IETF. Why are we avoiding to refer to it
here?
> > - Some implementations support the action to jump or goto other
> > acls. Is this not common enough to include it as a base action,
> > perhaps protected by a feature?
>
> Yes among vendors, but it can be very specific. Example, in Juniper
> implementation there are two types of filters, classical and Fast Update
> Filters (FUF). Classic filters support (on specific HW platforms) filter as
> action, but FUF does not. Not all terms and not all actions are supported on
> FUFs. So you have to see what filter type and what platform it is, in order
> to such a specific action.
What speaks against making jump and/or call actions a feature?
> > - In the example in section 4.3, does the CLI shown really help much?
> > The syntax is pretty system specific.
>
> OTH, it is widely understood and self explanatory.
The question was whether it is needed to show system specific CLI.
BTW, I note that the textual description says "deny ... from
_leaving_". How is the 'from leaving' translated into the XML? Is
there any distinction between input and output filters (or forwarding
filters or whatever your engine supports)?
> > In the XML shown, can you not
> > leave out all the fields that are not set? This would remove a lot
> > of noise. I do not understand what having both actions deny and
> > permit at the same time means. Did you validate the example against
> > the data model? (I also find the keys at the end somewhat strange
> > and not that NETCONF XML serialization actually requires the keys to
> > be sent first.)
> We used pyang sample xml skeleton to create the xml example.
Whatever, the noise does not really help and the example might even
mislead people to believe they have to write down all unused leafs.
> Leaving both actions in the document is my fault. In the model, action is a
> choice, and it was a bad copy paste job. Didn’t choose :)
> >
> > - The clarification whether the boundary port numbers are included in
> > a port range should be in the YANG model. The YANG model should also
> > say what it means if one of the ranges is not present. We should not
> > define the semantics by examples.
> I’m loosing you here. We are stating in the model if the boundary port
> numbers are included in a port rang.
Ack, I found it in the description of container source-port-range (and
previously I looked at lower-port and upper-port).
> >
> > - I do not understand section 5. It shows some nftables syntax but
> > does not really shed a light on what the example shown does or how
> > that maps to the YANG data model. So I am left somewhat clueless.
>
> Just wanted to point out that the basic structure of iptables is similar to
> ACL yang model, so a translation from one to the other should be a simple
> process. If someone wants to make it compliant.
It escapes me how the iptables fragment shown in page 18 maps to the
YANG model. What is the substance behind the statement "It should be
fairly easy to do translation between ACL YANG model described in this
draft and Linux nftables."? Has someone done a mapping? It is not
obvious to me how this works.
> > - Can I trigger multiple actions from an ace? Or do I have to
> > replicate the ace to do that? In general, there is extension of
> > a choice (means one of several) and there are extension of a
> > choice already present.
> Again, this is very platform dependent, so didn’t want to include it in the
> base model.
>
So what would I do if I want to 'log' and 'deny'? Even if the base
model does not do that, how can I augment this in? The base model must
provide the necessary extensibility hooks.
> > - Empty description statements or descriptions statements "(null)"
> > need to be fixed.
>
> There are no empty descriptions. You are probably referring to
> ietf-packet-fields.yang model. There is a bug in pyang which was reported to
> Martin and fixed since.
I am talking about this (page 25):
description "(null)";
> > - I am a bit surprised that we do not define how to attach an ACL to
> > an interfaces or a set of interfaces given that we do have an
> > interfaces YANG data model. The example given in A.3 makes me wonder
> > why there should be a counter in the interfaces config tree. The
> > targets/interface-name back-reference seems to indicate that I can
> > attach an ACL only to a single interface.
>
> I wasn’t the author of that section
This is a WG document so this needs to be resolved.
> > - I do not understand A.4 at all. Defining an identity does not make
> > the choice work differently.
> >
> > - Has someone tried to implement this?
>
> Was working on implementation while at my previous employer, but am not aware
> of any other implementation.
I believe it will help a lot to have prototype implementations of this
data model in order to make sure the model does actually work and
provides the extensibility hooks that are necessary. In particular, I
would feel much more convinced if it would be clear (as a proof of
concept) how the model maps to say Linux packet filters. I would
actually not mind if mapping examples from the data model to various
filtering engines would be in the appendix. This would give evidence
that people have actually worked through a couple of concrete
examples.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
