Subject: Re: WG Last Call on draft-ietf-rps-rpsl-v2-01

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Jan 1999 20:46:28 -0500

Title	: Routing Policy Specification Language (RPSL)
   Author(s)	: C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens,   
	          D. Meyer, T. Bates, D. Karrenberg, M. Terpstra 
   Filename	: draft-ietf-rps-rpsl-v2-01.txt,.ps
   Pages	: 64
   Date		: 18-Jan-99

> I have implemented RPSL 100% in RAToolSet/BIRD. The bison grammar
> rules are straight from there.

This is really useful.  Unfortunately the names in the bison don't
match the names in the draft.  At the very minimum you need to have
comments which map each expression in the document to the bison.  For
example: 

  //// router-expression == rtr_expr ////

rahter than just:

  //// rtr_expr ////...

This way we could easily get a precise clarification from the grammar
when reading the text.

We also need definitions of the tokens.  See bleow.

>  o  All dates are now in UTC. Please see Section 2.

Grumble.  OK.

>  o  The syntax and semantics of  export-comps attribute of route class  have
>     changed.  Please see Section 8.

I don't remember any discussion of this change.  It is all wrong.  If
the scope of an aggregate is multiple providers it makes absolutely no
sense to specify the export policy of the components in the aggregate.

The export-comps is supposed to be just a list, nothing more.  If a
prefix falls under an aggregate it is omitted from any export
statements in which it would otherwise appear unless it falls within
the export-comps list for the aggregate in which case it is not
omitted.  This was the functionality agreed to.

Could you please forward any email discussing this change or restore
it to what we had agreed to before.

> I realize I forgot to add one other change to the changes appendix:
> For peering specification, we had two rules:
>     <peer-as> [<peer-router>] [at <local-router>]
>     <as-expression> [at <router-expression>]
> Having these two rules leads to several reduce/reduce conflicts in
> bison, with no obvious way around it. The fix is to have one rule
> which supercedes the two rules:
>     <as-expression> [<router-expression>] [at <router-expression>]
> This is also totally backward compatible.

This is a much needed change.  Looks a lot better.  However see below.

> I am going to modify the changes appendix to include one other item
> before sending it to IESG:
> 	o A <router-expression> is now allowed as the peer router in a
> 	  peering. Please see Section x.
> (Along with other comments from you folks).
>  
> Cengiz

Here are some comments that I've made in private exchanges.  I don't
know whether these sort of changes should go into this cut of RPSL or
go into a later version to be recycled yet again as PS.  This may
largely depend on the OPs ADs preferences.

We've been experimenting with RPSL to configure policy on
route-reflector clients to give some full routing, some partial (our
customers only or some other subset), and some just default and a few
others.  In addition there is import policy on each.  What this is
doing is moving policy for customers (mostly single homed) to the
access router rather than CPE router.  If the CPE becomes customer
managed this becomes EBGP rather than IBGP route-reflector.

One thing that would be very useful is a "filter" object that could be
referenced anywhere that <filter> appears.  This would be useful for
someone with multiple AS that all have similar import or export
policies.  We might even want to consider a "hints" attribute where we
could put such things as "route-map-name" or "prefix-list-name" for
routers that support named policy stanzas.  The hint could be used in
the simple case where an import or export just references a single
filter object otherwise ignored and ignored if the router being
configured did not support named policy stanzas.

In addition it would be useful to have a "peer-group" object that
could be used in the router-expression in <as-expression>
[<router-expression>] [at <router-expression>].  The name of the
peer-group might be used in generating router configurations that
support named peer-groups.  The alternate that we were counting on was
to use a route-set with /32s in it.  It doesn't look like this is
supported:

rtr_expr_operand: TKN_IPV4 | TKN_DNS

Since the tokens are not defined it is not entirely clear what
TKN_IPV4 and TKN_DNS are.  The text just says:

  and <router-expression-1> and <router-expression-2> are expressions
  over router IP addresses and DNS names using operators AND, OR, and
  NOT. The DNS name can only be used if there is an inet-rtr object
  for that name that binds the name to IP addresses.

It would appear that router IP addresses means fully dotted IPv4 quad.

Allowing an object named "peer-group" might be preferable to allowing
a route-set and accepting all routers falling within the route-set.
The route set would be OK too.  Adding one or the other to
rtr_expr_operand would be a good thing.  Having no ability to name
these sets will bloat our aut-nums a bit and give us cause to
preprocess aut-nums and use the source prior to preprocessing for the
actual configuration.

Neither of these changes are essential.  We can use aut-num source
prior to preprocessing in our configuration generation (as we already
do) and submit the aut-num after preprocessing if there are any
significant changes.  These aut-nums may never be submited to a
publicly readable database anyway (at least not before stripping the
route-reflector policy).  We might want to consider these two changes
for the next round of RPSL.

I'd also like to point out that as much as some people would like to
see no changes at all it is likely that we will need to have a next
round of RPSL because people are using RPSL and through using it will
come up with more efficient ways to express routing policy.

Curtis

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Wed, 27 Jan 1999 09:48:11 -0800 (PST)

> This way we could easily get a precise clarification from the grammar

grumble.
will do where possible.

> We also need definitions of the tokens.  See bleow.

Tokens match the definitions in Section 2 of rpsl. Names may not match
exactly. I will also add comments on this.

> it to what we had agreed to before.

This was suggested by the Fore folks and was discussed in the LA IETF
WG meeting.

Please see ftp://ftp.isi.edu/rps/la-ietf-98/implementation-experience.ps

You could get the older behavior by:

	export-comps: to as-any announce <whatever>

Hence, it can not be "all wrong".  May be someone from Fore may
comment, or I can dig the mail archives if you insist.

> This is a much needed change.  Looks a lot better.  However see below.

When I did this, it was a grammar fix. I did not know there was a need 
for it. I am glad.

> configured did not support named policy stanzas.

I favor this one. Mark also wanted a way to name a set of communities
for private use. He could use the filter object as well. Something
like:

route-filter: rf-foo
filter: <filter>

Wearing an RPS hat, I dont like the hint attribute. I think it is
configuration information that should not be included.  Wearing an
RAToolSet hat, I dont mind implementing such a feature even if it is
left outside of RPSL.

> It would appear that router IP addresses means fully dotted IPv4 quad.

yes

> preprocess aut-nums and use the source prior to preprocessing for the

You are suggesting:

rtr-set: <an hierarchical name, e.g. as1:rtr-core>
members: list of IPv4 or dns names 
member-by-ref: list of maintainers

(I called it rtr-set to be consistent and more general). DNS names can 
only be used if there is an inet-rtr for that name.

> for the next round of RPSL.

I can incorporate these changes next week, give another week or two to
the WG for review and submit the draft to IESG for movement. This
would be the least delay path.

The changes are small (rtr-set is very much like rs-set and
route-filter is more like a preprocessor macro).

The question to the the WG and ADs is: do you support these changes,
if so, is it OK to incorporate them next week before submitting them
to IESG.

> come up with more efficient ways to express routing policy.

I think it is important that we finish up with the document and
implementation and refocus on deployment. We had over a year in phase
II of the transition for people to play with the language and tell us
all these nice extensions during this phase. However, with the
exception of few (thanks Mark:-), most people only recently started to
play with it. The encouraging news is that there are quiet a few
people now who are non implementors and play with the language.

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Jan 1999 19:33:43 -0500

> Please see ftp://ftp.isi.edu/rps/la-ietf-98/implementation-experience.ps

If I remember correctly the reason was along the lines of "easier to
code in RPSL this way" and this was objected to at the meeting.

> comment, or I can dig the mail archives if you insist.

The document doesn't agree with what you've said above.

   When a  set of  routes are  aggregated, the  intent is  to  export only  the
   aggregate route and  suppress exporting  of the more  specifics outside  the
   aggregation boundary.    However,  to satisfy  certain policy  and  topology
   constraints (e.g. a multi-homed component),  it is often required to  export
   some of the components.  The export-comps attribute serves this purpose.  It
   equals an RPSL export policy expression as follows (see Section6.2):

    export-comps: to <peering-1> [action <action-1>]
                  . . .
                  to <peering-N> [action <action-N>]
                  announce <filter>

   where <filter> matches the  more specifics that need  to be exported to  the
   peerings specified.    While exporting  to  <peering-i>, the  <action-i>  is
   executed to set the  path attributes.   If this  attribute is missing,  more
   specifics are not exported outside the aggregation boundary.  Note that, the
   <filter> contains an  implicit "AND"  term with  the more  specifics of  the
   aggregate.

What you've said above in email is 'export-comps: to as-any announce
ANY' would be equivalent to the old behavior in which export statement
in the aut-num for the announcing AS applied if there was an
export-comp attribute in the aggregate.  What the document says is
that the "to" and "action" and "filter" in the route object is in
effect the export policy.  You need to change the document.

I object to any policy being placed in the route object itself since
multiple providers will be announcing the route and many are likely to
have different export policies.

The export-comp should be a filter only and specify those prefixes
which slip through the implicit export blocking of the aggregate.  Any
"to" and "action" should be specified in the export policy for the AS
making the announcement.

> RAToolSet hat, I dont mind implementing such a feature even if it is

In RaToolSet it would have to be:

  remarks:  cisco-hint: <cisco-hint>
  <cisco-hint>: |
     <cisco-hint> route-map-name <name> |
     <cisco-hint> prefix-list-name <name> ;

(please excuse the mixed bison syntax).  This would need to be in
remarks if it is not an attribute supported by other tools.  If so, it
is sort of ugly but there is no need to change the RPSL doc to support
this.

> only be used if there is an inet-rtr for that name.

You can call it peer-group or rtr-set.  If building Cisco configs it
maps directly to a peer-group and gives the OPs folks here the
peer-group names they already know and love.

This look like you are saying "yes" in support of the idea but calling
it rtr-set?  If so, fine with me.

> if so, is it OK to incorporate them next week before submitting them

Cool.  Thanks.

> people now who are non implementors and play with the language.

My preference would also be to get these changes in now rather than
later.

Curtis

btw- Please define "play".  ;-)

Actually it is only recently we've tried to figure out how to do
route-reflectors and support Cisco configs rather than Bay and gated,
generate the whole Cisco config and preserve what our operational
people like about their hand edited Cisco configs.  Before that we've
made sure that there was support in RPSL so we could remove all of the
kludges we had to work around limitations in RIPE-181 but we haven't
removed those kludges in our config software.