> On Jan 11, 2016, at 7:30 PM, Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> wrote: > > On Mon, Jan 11, 2016 at 05:58:52PM +0100, Dean Bogdanovic wrote: >> >>> >>> 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. >> >> Authors are Cisco/Juniper people, so were using that terminology and I >> believe that CSCO and JNPR are more used in networking then Linux :) >> > > If I were to have the time, I would even challenge you on > that. Clearly, when you consider # of devices connected to the > Internet, I am sure CISCO and JNPR will loose. But even in enterprise > networks, there are tons of Linux and BSD firewalls. Consider all the > home routers running openWRT and packet filters. So yes, if I would > have time, I would challenge you on that argument.
I would definitely take you on this one. As OpenWRT is domain of hobbyist. If I may ask you, what device your ISP is sending you as access point? :) > > In some Junos documentation (Junos 14.2), I have seen the terms > 'filter' and 'term'. But I might be proven wrong… Juniper is using filter and term, that is correct, from day one. OTH, Cisco is using Access Control List (ACL) and ACL Entries (ACE) and several other vendors (Brocade, Huawei, ALu, Ericsson Redback) are using those terms too. ACL is well established in the industry. > >>>>> - 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. >> >> I haven’t seen a network device with filters without supporting L2 and L3 >> types. This is how we started originally, but then comments came in on the >> mailing list and wanted exact typing. Please see the thread >> >> http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html >> >> Model was changed for IETF 94 and at the WG meeting nobody raised the issue. > > I am talking about the modularity of the base model, I do not see how > the cited thread relates to this. Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I appreciate your input, but we did this design choice as design team and went forward with it. Also, the YANG models are not set in stone. I definitely see models evolving. > >>>>> - 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? >> No, it can be timestamp, RIB, VRF, etc. >> >>> - If so, why not make it part of the base model? >> >> We are early in the modeling and people were asking to remove time range >> from the base model and create separate draft, as many other features are >> using time-range. > > I agree that the decision is kind of tough to make. One option is to > make the base model pretty much content free and to add pretty much > everything in a modular way via extensions of the base model. > >>> - If not, what is the extensibility model here? > > Question remains open. > >>>>> 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? >> >> There is discussion in separate thread on this. And it seems we are in >> agreement to move this model to YANG 1.1 and use Martin B proposed solution. > > OK > >>>>> - 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. > > This is why getting the modularity right is very important here. > >>> What speaks against making jump and/or call actions a feature? >> >> jump is not supported on all platforms and all types of filters. > > A feature does not have to be supported by everyone. > >>>>> - 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)? >> >> We can improve the text description. Why not show system specific CLI? It is >> something widely understood and it is an example. >> >> This is what is being translated into XML >> access-list ip sample-ip-acl >> deny tcp host 10.10.10.1 host 10.10.10.255 >> >> And usually people understand real example better, then just text >> description. > > May please CISCO people, others likely less. But so be it. > >>>>> 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. >> >> We could edit the empty fields out, but from personal experience working >> with customers, I was getting questions that the compiler output and the >> examples are not matching (it was vendor data modeling language). > > Which compiler's output? I find it very distracting to list unused > leafs. I assume most NETCONF implementations suppress unused leafs as > well. (I might be proven wrong but I would have a preference to not > use one that sends me tons of useless empty leafs.) There is a vendor that had data modeling language and compiler shipping in their SDK. It is private DM language and it is not used outside of that vendor and customers. > >>>> 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. >> >> No, the mapping between nftables and ACL YANG model has not been finished. > > OK > >>>>> - 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. >> >> Logging/counting and another action (permit/deny) is possible with most >> vendors, but other multiple actions are not by most vendors, example to jump >> to another ACE or ACL. You have to replicate the ACE to do that. So to make >> it simple, this was the choice we made. > > So what about counting logging? Can we make the base simple yet > powerful enough via features to match what common open source software > implementations can do? We made a different design choice. > >>> 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. >> >> In this case, I can’t help at the moment, as have left the previous company >> where I was working on an implementation. > > Perhaps there are others here with sufficient interested to work out > (at least) how the model maps back and forth to the implementation(s) > they are familiar with? I did it for Juniper and it is working well for Junos, but didn’t finish it. I can’t speak for Cisco people, but they are co-authors on the draft and were fine with the model. > > /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
