[Xorp-users] [Xorp-hackers] Policy network4 operator

Pavlin Radoslavov pavlin at icir.org
Thu Nov 16 17:32:26 PST 2006 

> 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_command_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

More information about the Xorp-users mailing list