Paul Jakma wrote (on Wed 02-Sep-2015 at 14:59 +0100): > On Fri, 21 Aug 2015, Chris Hall wrote: > > > On the subject of "set comm-list xxx delete", The Fine Manual > > (page 61) says: > > > > "For communities value deletion, only permit community-list > > is used. deny community-list is ignored." ... > I guess in terms of what we have supported, we have never defiend > behaviour when a deny is included, so we ahve some latitude to do > whatever is sensible here, including honouring the documentation.
I'm feeling particularly dim this morning... ...are the Documentation (the Fine Manual) and the Defined Behaviour not one and the same ? In which case, the Actual Behaviour is broken. ...or do we deem Defined Behaviour and Actual Behaviour to be one and the same ? In which case, the Documentation is broken. ...or is there a third specification for Defined Behaviour ? If the Meta-Specification is "follow Cisco semantics", then the Documentation and the Actual Behaviour are both broken. ... > I think we're in undefined land on the deny really. Perhaps it > should be ignored, as the docs say. But, whatever works for > people ... I agree... as a practical matter any change here needs to avoid/minimise disruption to users. > ... I see Daniel has a patch to make this work in accordance > with other implementations? Pretty much; though IMHO entries which are "invalid" according to Cisco should be defined to be ignored (do nothing) in all cases, rather than do variety of things, depending on context. The handling of 'internet' remains obscure. Clearly, for not-regex 'internet' on its own means "any" -- which in the context of delete, means "all". For regex, 'internet' on its own means your actual 0:0 community in all cases ! Since the form "100:1 200:1" is an AND, then surely "internet 100:1 200:1" means "any" AND "100:1" AND "200:1" (so the 'internet' is redundant) ? "set community internet..." will set your actual 0:0 community, and that will be sent in an UPDATE. All the 0:* communities are "Reserved" (by RFC1997) -- so I suppose you could argue that 0:0 is no less invalid than 0:1. Perhaps the real mistake is treating 'internet' as a name for 0:0 at all at all ? > > BTW, running "100:.*" through the regular expression engine > > has the happy, or possibly unhappy, effect of matching (inter > > alia) 100:10 and 32100:10. I guess that's what everybody > > expects/wants ? > Expected given how regexes work, though perhaps will be > unexpected in this context. I think that should be documented, > for sure. An option to automatically anchor it might be useful > for some? I toyed with the idea of such an option. It gets tricky (not really feasible) to do in the general case -- but for trivial regexes I think it removes a "gotcha". FWIW I have implemented a "short-cut" which checks for trivial regexes and implements those without running an actual regex -- which makes something of a difference in the Route Server case. ... > Another possible gotcha is that in the context of a delete, the > regexp is applied community by community; while for a general > match the regexp is applied to the string form of the entire list > of communities. (Possible to think it does community by community > in both cases). Well... for a general match, it seems reasonable that a regex of the form "_100:.*_200:.*" is an AND in the same way that a not-regex "100:1 200:1" is. The Cisco semantics say that the delete case is different, and that neither of these are valid -- which means that the expanded and standard entries are consistent (to the extent that both are defined to be undefined). I will confess to being tempted by the idea of treating an expanded entry which has no wild cards in it as a standard entry (along with automatically anchoring trivial regexes). IMHO, the thing should be cleaned up and users warned to check their existing configurations before deploying a new version. In the limit, one could implement a "do it the old way" configuration flag, and even a "tell me if I need to worry" check. Chris _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
