[Xorp-users] [Xorp-hackers] Policy network4 operator
Mike Horn
mhorn at vyatta.com
Thu Nov 16 17:53:18 PST 2006
Hi Pavlin,
Sorry I missed it originally, see my last email ;-) Obviously we both have
strong opinions about which sign direction is "right". If people continue
to vote in favor of flipping the sign behavior, would you be willing to
consider changing the behavior?
Btw, I think the right long term answer is to use something similar to the
Juniper syntax, which removes any potential for ambiguity.
-mike
-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On
Behalf Of Pavlin Radoslavov
Sent: Thursday, November 16, 2006 6:32 PM
To: mhorn at vyatta.com
Cc: xorp-users at xorp.org; xorp-hackers at xorp.org; 'Pavlin Radoslavov'
Subject: Re: [Xorp-users] [Xorp-hackers] Policy network4 operator
> I agree, Cisco and Juniper syntax are very different, and there really
> isn't an "industry standard". You only listed the following options:
>
> (1) Do nothing and use the current "<=" and friends syntax.
> (2) Add the hack for the "exact/longer/orlonger..." support as in
> the examples given above.
>
> Isn't another option to flip the meaning of the sign? In which case >
> would mean longer prefixes, so network4 > 10.0.0.0/8 would be any 10.X
> prefixes with a prefix length longer than 8. This would be aligned
> with Cisco's use of "ge" and "le" and seems like from the limited
> responses to be everyone's preference.
>
> What do you think about using this as an interim approach?
I think I already wrote a paragraph about this in my previous email.
And, no, it won't be aligned with Cisco's use of "ge" and "le", because they
are using "ge" and "le" to compare network mask length (the argument is an
integer) while we are using ">=" and "<=" to compare network addresses.
Pavlin
> -mike
>
> -----Original Message-----
> From: xorp-hackers-bounces at icir.org
> [mailto:xorp-hackers-bounces at icir.org]
> On Behalf Of Pavlin Radoslavov
> Sent: Thursday, November 16, 2006 5:59 PM
> To: Dave Roberts
> Cc: xorp-users at xorp.org; Robert Bays; Kristian Larsson;
> mhorn at vyatta.com; xorp-hackers at xorp.org
> Subject: Re: [Xorp-hackers] [Xorp-users] Policy network4 operator
>
> Dave Roberts <dave at vyatta.com> wrote:
>
> > Being a product manager at heart, my advice would be to follow
> > industry conventions here. The fact is, the industry has already
> > solved this problem and there are certain expectations of operating
> > behavior and terminology that router users already have. So why
> > reinvent
> the wheel?
> > Violating the norms of the vast majority of users just seems senseless.
> >
> > My conclusion is that Robert's suggestion of adopting Juniper
> > terminology and behavior seems like a no-brainer. Failing that, look
> > at what Cisco does and base something off that. But whatever you do,
> > don't go inventing new terminology and behavior without a *STRONG*
> > reason for doing so; all you will do is end up confusing the vast
> > majority of users that are schooled on existing products. Complex
> > router configurations are difficult enough to get debugged and
> > working without users having to remember that XORP is the one router
> > on the planet that does something needlessly different.
>
> In an ideal world we can change any of the configuration semantics in
> any way we like so we won't be having this discussion.
>
>
> About the suggestion to follow what other have done.
> Syntax-wise, even Cisco and Juniper are doing things very differently,
> so there is no universal solution that we can just reuse.
>
> I checked the Cisco documentation online about the relevant policy
> semantics, and the closest I found is along the lines:
>
> =============================================================
> Cisco IOS IP Command Reference,
> Volume 2 of 4: Routing Protocols
> Release 12.3 T
>
> http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_comman
> d_refe
> rence_chapter09186a008017d02f.html
>
> and
>
> Routing Policy Language Commands on Cisco IOS XR Software
> http://www.cisco.com/en/US/products/ps5763/products_command_reference_
> chapte
> r09186a00803b0e1b.html
>
> Some examples from the first document are:
>
> To accept a mask length of up to 24 bits in routes with the prefix
> 192/8:
> ip prefix-list abc permit 192.168.0.0/8 le 24 To deny mask lengths
> greater than 25 bits in routes with a prefix of
> 192/8:
> ip prefix-list abc deny 192.168.0.0/8 ge 25 To permit mask lengths
> from 8 to
> 24 bits in all address space:
> ip prefix-list abc permit 0.0.0.0/0 ge 8 le 24 To deny mask lengths
> greater than 25 bits in all address space:
> ip prefix-list abc deny 0.0.0.0/0 ge 25 To deny all routes with a
> prefix of 10/8:
> ip prefix-list abc deny 10.0.0.0/8 le 32
>
> =============================================================
>
> As you can see, the syntax is very different from XORP, the "ge | le"
> arguments are of different type (network mask length), etc, so we
> cannot reuse or adapt this.
>
>
> The Juniper syntax for network address matching is like:
>
> route-filter 192.168.0.0/16 exact;
> route-filter 192.168.0.0/16 longer;
> route-filter 192.168.0.0/16 orlonger;
> route-filter 192.168.0.0/16 upto /24 reject; route-filter
> 192.168.0.0/16 through 192.168.16.0/20; route-filter 192.168.0.0/16
> prefix-length-range /26-/30 reject;
>
> Futhermore, Juniper allows you to have more than one route-filter
> statement per block.
>
> Our rtrmgr simply cannot be modified to support syntax like this.
> If we ever rewrite the rtrmgr (see Bugzilla entry #677), then there is
> some chance it might be easier to extend it with some of this syntax,
> but for now this is just not an option.
>
> The best we could do is to take the exact/longer/orlonger keywords
> from the first three examples, and support them similar to the
> existing comparison operators:
>
> "network4 exact 10.0.0.0/8" SAME AS "network4 == 10.0.0.0/8"
> "network4 longer 10.0.0.0/8" SAME AS "network4 < 10.0.0.0/8"
> "network4 orlonger 10.0.0.0/8" SAME AS "network4 <= 10.0.0.0/8"
> "network4 shorter 10.0.0.0/8" SAME AS "network4 > 10.0.0.0/8"
> "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8"
> "network4 not 10.0.0.0/8" SAME AS "network4 != 10.0.0.0/8"
>
> Note that the last three keywords (shorter/orshorter/not) don't exist
> in Juniper, so feel free to suggest better names.
> And, no, the rtrmgr template syntax doesn't allow us to have the
> tokens ordered same like in Juniper: "network4 10.0.0.0/8 exact".
>
> Have in mind that even such change is going to be very ugly (we need
> to add hacks to the rtrmgr AND the policy manager), and there is no
> guarantee it will actually work properly before we actually try it.
> Any other syntax changes are just no-starters with what we have now.
>
> About the suggestion of changing the direction of the "<=" operator:
> if you think that the current direction is wrong (which I strongly
> disagree with) or confusing, then just changing the direction is going
> to be ever more confusing, so this shouldn't be an option.
>
> To summarize, here are the choices I see:
>
> (1) Do nothing and use the current "<=" and friends syntax.
> (2) Add the hack for the "exact/longer/orlonger..." support as in
> the examples given above.
>
> If anyone has any other suggestions, please be very specific (and
> realistic) with examples what the syntax should look like, rather than
> being vague with "follow vendor FOO".
>
> Pavlin
>
>
> > -- Dave
> >
> > Kristian Larsson wrote:
> > > I think Roberts idea is just great, why not copy Juniper
> > > terminology. We already got a Juniper lookalike shell.
> > >
> > > And just as robert.. I'd go with option B if I had to choose
> > > between the two.
> > >
> > > -K
> > >
> > > On Tue, Nov 14, 2006 at 05:13:04PM -0800, Robert Bays wrote:
> > >> Maybe it makes more sense to use Juniper terminology; exact,
> > >> longer, orlonger, through, upto...
> > >>
> > >> Short of that, I prefer option B.
> > >>
> > >> Cheers,
> > >> Robert.
> > >>
> > >> Mike Horn wrote:
> > >>> Hi all,
> > >>>
> > >>> Pavlin and I have been discussing what the "right" direction
> > >>> should be for the network4 operator in policy statements. Right
> > >>> now if you specify "network4 <= 10.0.0.0/8" this would match all
> > >>> the 10.0.0.0/8
> and
> > >>> longer prefixes (i.e. 10.0.0.0/9, 10.1.0.0/16, etc.).
> > >>>
> > >>> My recommendation is to change the operator from "<=" matches
> > >>> longer prefixes to ">=" matches longer prefixes, since this
> > >>> seems more intuitive to me (/9 is > /8) and this would make it
> > >>> match the "prefix-length4" operator where "prefix-length4 > 24"
> > >>> matches all prefixes longer than /24.
> > >>>
> > >>> Which do you prefer:
> > >>>
> > >>> A) keep it the way it is now, < matches longer prefixes
> > >>> B) changing it to use > for longer prefix matches
> > >>>
> > >>> Btw, the bug on this is 358
> > >>>
> > >>> _http://www.xorp.org/bugzilla/show_bug.cgi?id=358_
> > >>>
> > >>> -mike
> > >>>
> > >>>
> > >>>
> ----------------------------------------------------------------------
> --
> > >>>
> > >>> _______________________________________________
> > >>> Xorp-hackers mailing list
> > >>> Xorp-hackers at icir.org
> > >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > >> _______________________________________________
> > >> Xorp-users mailing list
> > >> Xorp-users at xorp.org
> > >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> > >
> >
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
More information about the Xorp-users
mailing list