Subject: Re: RPCL comments

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 08 Sep 1998 23:30:32 +0200

At 12:33 08.09.98 -0400, Curtis Villamizar wrote:
>
>The question remains as to what you want to do with this draft.  If
>you just want it publiched as informational then you don't need our
>help (but I can see where comments would be helpful).  I don't think
>we'd want to take this on as a work group item, but the correct thing
>to do would be to ask the WG if you want to pursue this.
>

If there is IETF community interest in pursuing this idea along a
standards track, we might think of forming a new WG as a home for it.

RPS needs a charter revision anyway (the earliest non-ticked-off
milestone is in July 95, the latest in Jan 96, and there are no
milestones for any of the work the WG is currently doing); we might
think of refocusing the current RPS as "make it work" only, and leave
possible other interesting applications of RPSL extensions to another
working group.

                    Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 08 Sep 1998 17:46:15 -0400

Curtis Villamizar wrote:

> Ardas, Tony, Rob,
>
> Sorry for the long delay in commenting.

hey, glad someone does ;-)

> RPCL is interesting.  It is somewhat hard to comment on until it is in
>
> at least limited use, since this is where weaknesses or inconveniences
>
> due to the policy language structure are often discovered.  RPCL does
> seem complete and the expressions seem more powerful than the policy
> configuration statements in current routers.

I agree with you completely. There is this one implementaion and
probably more forthcoming & we still discuss on major issues (EXCEPTs,
no BLOCKs). I think that to help the situation couple of vendors will
have to take the hit & offer it as experimental feature in their
routers. If you're interested in the private e-mail exchanges that we
(authors) are having, let us know.

And yes, publishing the RPSL yacc-grammar as we agreed on could help
forthcoming implementations a big deal.

> One thing that interests me is the possibility of leaving the AS based
>
> expressions in place and using the light weight mirror capability
> described in the rps-dist draft.  This would reduce or eliminate the
> need to update router configurations on a regular basis to accommodate
>
> change in the registry.

Well, the BGP stuff still has the AS based expressions (I think we're
talking about the <peering> clause here)
in it I thought & even more than RPSL (you can mix IP addresses & AS
numbers), whereas for IGP I'm arguing that a restricted form of peering
should be in the language. It's in flux ...

> to do would be to ask the WG if you want to pursue this.

Hmm, I think we tried to gather some consensus for a BOF since we kind
of thought that RPCL does not fit well into rps charter. So far, I guess
we are sliding into the informational track although if enough interest
is sparked, I wouldn't mind to be a workgroup item for the rps group or
its own group or just have a BOF to shake things out ... Maybe Rob has
some idea.

> Specific commetns below.  I still only went through this sort of
> quickly.  For example, I didn't read through all of the examples.
>
> Curtis
>
>    Unlike RPSL, which specifies the policies and other internal
> objects of  an
>    AS,  RPCL  is  used  to configure the policies of an individual
> router. Its
>    syntax and semantics for the policy language is, however, derived
> from  the
>    RPSL. This consistency in policy specification language at the AS
> level and
>    the router level facilitates the conversion from one to the other.
>
> Extending RPCL to take AS expressions and act as a light weight mirror
>
> could be a topic for later extension.  You may want to consider where
> you'd need to leave hooks in the code and the language (maybe just not
>
> remove some of the RPSL syntax).

well, I think on the BGP side we have the stuff & as I said we're still
arguing about the IGP, whereas having ASes in IGP peering spec doesn't
make sense ...

>
>
>                            DST PROTOCOL
>
>                        | RIP  | OSPF | BGP  |
>                --------+------+------+------+
>                Static  |Export|Export|Export|
>                --------+------+------+------+
>                Direct  |Export|Export|Export|
>          SRC   --------+------+------+------+
>          PROT  RIP     |Export|Export|Export|
>                --------+------+------+------+
>                OSPF    |Export| ---- |Export|
>                --------+------+------+------+
>                BGP     |Export|Export|Export|
>                --------+------+------+------+
>
> Although it can get quite ugly, some routers have limited support for
> multiple instances of the same protocol on one box.  This allows the
> router to appear to be in more than one AS rather than having two
> boxes and an EBGP peering between the two.  I don't know of anyone
> that actually uses this feature, but years back it was thought to be
> potentially useful so at least one vendor coded it.

yes, and that's why the editor has the ip-instance clause. I'm not sure
it makes sense to extend RPCL to specify between which instance you
apply what. Actually the implementation just has a matrix per virtual
router from-to protocol.

>       <as-set> is a set of AS numbers in braces separated by commas,
> such  as
>            {AS12, AS47, AS111}.
>
> I'd have to look but I thought as-set came in square braackets.
>
> One thing to watch out for is as-sequences in the as-paths.  Some code
>
> can be confused by arbitrary placement of as-sequence groupings in the
>
> as-path.  For example, an as-path with 3 as in it could be one
> as-sequence with three as or an as-sequence with threee as-sequence in
>
> it with one as in each as-sequence.  IMHO the whole as-set as-sequence
>
> has turned out to be unneccesary baggage.

yes, any suggestions how to handle it better ?

>   2.3 Peering Types
>    The basic peering expressions are as follows:
>
> Gated has implied peer groups demarcated by brackets.  Cisco has named
>
> peer groups.  It looks like you are covered in terms of functionality.
>
> Some people like the named peer groups, but I think it is more a
> personal preference than any technical reason (having to do with some
> functionality you don't otherwise get).
>
>       | prefix      <prefix>    <prefix-range-list>          ---
>       | preference  <integer>        ---
> pref=<integer>
> OSPF  | metric      [1-65535]        ---
> metric=<integer>
>       | tag         <integer>   tag==<integer>
> tag=<integer>
>       | type        <ospf-type> type==<ospf-type>
> type=<ospf-type>
>
> OSPF actually has a pair of metrics, type1 and type2.  This only
> impacts the use of ASE routes in OSPF.  This is something ISPs don't
> do but enterprise customers will probably want.

I argued taht one as well as having the differentiation on route type
between E1 and E2 types.

>       | prefix      <prefix>    <prefix-range-list>          ---
>       | origin      <as>        <as>                         ---
>       | source-peer <peer>      src-peer==<peering-spec>     ---
> BGP   | preference  <integer>        ---
> pref=<integer>
>       | med         <integer>        ---
> med=<integer>
>       | dpa         <integer>        ---
> dpa=<integer>
>       | as-path     <as-path>   <aspath-regex>
> aspath.prepend<as-path>
>       | community   <comm-list> comm==<comm-list>
> comm=<comm-list>
>       |                         comm.contains<comm-list>
> comm.=<comm>
>       |
> comm.append<comm-list>
>       |
> comm.delete<comm-list>
>
> You need the actions med=IGP or med=IGP+<const>.  That is where you
> add the IGP cost to a constant to get the adverticed MED.  The
> constant defaults to zero.

ok, but that leads into the ugly street where people start to ask for
fully blown arithmetic expression support to compute MED from any
arbitrary garbage. I tried to punt on that one intentionally originally
...

>    A compound rule is of the form:
>
>       <PR-Import-Compound-Rule>: {<PR-Import-Rule>; <PR-Import-Rule>;
> ...}
>
>    It is an ordered list of import rules with the following semantics:
>
>       - A route matches a compound rule if it matches  at  least  one
> of  the
>       rules in its list, and
>       - if there are matching rules, then the first such rule  is
> applied  to
>       the route.
>
> This is OK as long as you don't implement the ordering as a linear
> walk.

well, there is a lot of optimization you can do to find out whether
anything would match at all upfront in a block but once you're in it,
you're pretty much damned to walk the list (although you can
intelligently skip things without evaluating them).

>    The other type of structured rule is a refine rule with the
> following  syn-
>    tax:
>
>         <PR-Import-Refine-Rule>: <PR-Import-Rule> refine
> <PR-Import-Rule>
>
> Cool.
>
>    Finally, the full syntax of an import rule for protocol PR is:
>
>     <PR-Import-Rule>:
>        [from <peering>] [action <PR-import-action>] accept <PR-filter>
> |
>        [from <peering>] block <PR-filter>
> |
>        {<PR-Import-Rule>; <PR-Import-Rule>; ...}
> |
>        <PR-Import-Rule> refine <PR-Import-Rule>
>
> What happenned to "except"?  We use this extensively.

yes, that what I argue for & originally included. As well, I want to get
rid of blocks since they make the language ugly (although Rob argued a
couple of RIP cases which are not as obvious when written as except). I
think one problem is that except is not really an "EXCEPT" but pretty
strange construct which accepts first the block & then runs a join that
is more like what you'd expect from an "EXCEPT". Scares a lot of people
on a first read ...

>                     SRC PROTOCOL                         SRC PROTOCOL
>
>                 | RIP |OSPF | BGP |               |  RIP | OSPF |  BGP
> |
>       ----------+-----+-----+-----+
> --------+------+------+------+
>       Static    | YES | YES | YES |       Static  | BLK  | BLK  | BLK
> |
>       ----------+-----+-----+-----+
> --------+------+------+------+
>       Direct    | YES | YES | YES |       Direct  | BLK  | BLK  | BLK
> |
>  DST  ----------+-----+-----+-----+  DST
> --------+------+------+------+
>  PROT RIP       | YES | YES | YES |  PROT RIP     |ACCEPT| BLK  | BLK
> |
>       ----------+-----+-----+-----+
> --------+------+------+------+
>       OSPF      | YES | --- | YES |       OSPF    | BLK  |ACCEPT| BLK
> |
>       ----------+-----+-----+-----+
> --------+------+------+------+
>       BGP       | YES | YES | YES |       I-BGP   | BLK  | BLK
> |ACCEPT|
>       ----------+-----+-----+-----+
> --------+------+------+------+
>       Block Rule| YES | --- | --- |       E-BGP   | BLK  | BLK  | BLK
> |
>       ----------+-----+-----+-----+
> --------+------+------+------+
>     (a) Configuration and Block Rule             (b) Default-Action
>
> How cah Static and Direct be the DST protocol?  Are src and dst
> reversed?
>
>    Some protocols, such as BGP, perform aggregation via a  configured
> policy.
>    Based on  the current state of the RIB, the configured aggregation
> rules of
>    a protocol PR determine:
>
> OSPF also has area summary routes which is a form of aggregation.
>
>       <PR-aggregation-rule>:
>          aggregate into     <prefix>
>          triggered by       AND/OR of HC{<prefix-range-list>} and
>                                       EX{<prefix-range-list>}
>          components         ATOMIC | [protocol <PR_1>] <PR_1-filter>
>                                     [[protocol <PR_2>] <PR_2-filter>]
> ...
>          action             <PR-action>
>          export components  from <PR_1> <PR_1-to-PR-export-rule>
>                            [from <PR_2> <PR_2-to-PR-export-rule>] ...
>          holes              <prefix-range-list>
>
> I don't think this aligns well with RPSL.  It seems to be taken from
> an earlier iteration.

I let Ardas comment on that one. I just did the underlying rework of
aggregates in RPSL with Cengiz but he implemented the details so he'll
be more in-tune ...

>   APPENDIX A. A Policy Editor for RPCL
>
> I didn't look over the appendix.

That doesn't hurt, as other people say it is "non-normative". One could
implement the editor in a completely different way of course ...

            --- -tony