On Thu, 3 Sep 2015, Chris Hall wrote:
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.
I'm not sure on a general rule, but in this case I'd err toward the fine
Manual, given that:
- It seems to be quite specific that deny should be ignored
- The Actual Behaviour doesn't seem to be what people would expect from
other systems anyway (and a patch has been proposed to fix that)
?
...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.
It'd be nice to find a general and specific rule for this, but I think
we're probably stuck with a vague, wiggly "Do what is most reasonable and
in the best interests of users, present and future"!
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.
Agreed.
However, we'll need to get the divining stick out to work out whether
more users rely on the current Actual Behaviour, or whether there's a
greater set of users who havn't /yet/ had to discover this but will be
confused by the current Actual Behaviour when they do.
There's also the possibility that sometimes it may be better to
deliberately follow another path, if that is simpler and less confusing
for users. Of course, then the Documentation should match.
... 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.
That would be good.
The handling of 'internet' remains obscure.
Yeah, a bit. A logic table / table of outcomes, as the "Route Map" section
has, might be useful (http://www.nongnu.org/quagga/docs/docs-info.html#Route-Map).
Clearly, for not-regex 'internet' on its own means "any" -- which in the
context of delete, means "all".
So for delete:
- if the comlist has "internet" value it will match anything && permit ->
delete.
- if a regex, then the regex will be matched against each community in the
attr, and 0 community will be turned into "internet" for that
for match:
- if a regex, the community attr is turned into a string (0 will go to
"internet") and the regex is checked agaisnt the whole string.
- if the comlist has an "internet" value it will match anything && the
sense will be according to the permit/deny of the community list entry.
Is that about right?
We can turn that into a table for the docs probably.
For regex, 'internet' on its own means your actual 0:0
community in all cases !
Yes.
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) ?
So, if my reading of the code is right (could be wrong?):
"internet 100:1 200:1"
- if that is in a community list entry, the "internet" will make it match
anything, regardless of any other specific communities, least that's
what community_list_match suggests to me.
- if that is in a community attribute, then it can be matched with a
regex. The 0 will be turned into "internet" by com2str, which will be a
substring of the full community-string that the regex is applied
against.
So it's the 100:1 and 200:1 that would be redundant? The "internet" bit
already means it will match anything (in an entry)? Or are we looking at
it from different angles?
Note that ecommunity_list_match and ecommunities don't seem to have this
kind of behaviour.
"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.
We probably shouldn't accept and send that.
Perhaps the real mistake is treating 'internet' as a name for 0:0 at all
at all ?
;)
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.
Sounds like it could be useful.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
"Pascal is Pascal is Pascal is dog meat."
-- M. Devine and P. Larson, Computer Science 340
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
