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

From: Cengiz Alaettinoglu <[email-masked]>
Date: Tue, 19 Jan 1999 09:59:12 -0800 (PST)

As we agreed in Orlando, we are going to ask IESG to advance the
following i-d to proposed standard. Please give your last minute
comments/feeback by January 29th.

   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

The changes between 00 and 01 of this document are addition of two
appendixes, one providing formal grammar rules, and one that lists the
changes since RFC 2280, deletion of withdrawn attribute and some
editorial changes (all of which we agreed in Orlando). I am attaching
the changes appendix below.

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

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California
============================================================================
C Changes from RFC 2280

RFC 2280 [3] contains  an earlier version of  RPSL. This section  summarizes
the changes since then.  They are as follows:

 o  It is  now  possible to  write  integers  as sequence  of  four  1-octet
    integers (e.g. 1.1.1.1)  or as  sequence of two  2-octet integers  (e.g.
    3561:70).  Please see Section 2.

 o  The definition of address  prefix range is extended  so that an  address
    prefix is also an address prefix range.  Please see Section 2.

 o  The semantics for a range operator  applied to a set containing  address
    prefix ranges is  defined (e.g. {30.0.0.0/8^24-28}^27-30).    Please see
    Section 2.

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

 o  Plus ('+') character is  added to space and  tab characters to split  an
    attribute's value  to multiple  lines (i.e.  by starting  the  following
    lines with  a space,  a tab  or a  plus ('+')  character).   Please  see
    Section 2.

 o  The withdrawn attribute of route class is removed from the language.

Alaettinoglu et.  al.            Expires  July 15, 1999            [Page 62]
Internet Draft                     RPSL                     January 15, 1999

 o  The syntax and semantics of union, and list types and typedef  attribute
    have changed.  Please see Section 7.

 o  In  the  initial   dictionary,  the   typedef  attribute  defining   the
    community_elm,   rp-attribute  defining  the   community  attribute   has
    changed.  Please see Section 7.

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

 o  Guideliness for extending RPSL is added.  Please see Section 10.

 o  Formal grammar rules are added.  Please see Appendix B.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Wed, 20 Jan 1999 09:06:10 -0800 (PST)

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.

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

Cengiz

---

From: Mark Prior <[email-masked]>
Date: Fri, 22 Jan 1999 22:14:29 +1030

Being a user of the withdrawn attribute I guess I should speak up in
its defense :-) While I have previously said that I only use withdrawn
because I consider the implementation of delete to be broken it has
proved to be useful at times to have the withdrawn record "lying
around" when mistakes are made so perhaps it should survive. I would
like an automatic mechanism in the server to clean them up though as
while the record exists some other maintainer can't come along and
recreate the original record.

Mark.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Fri, 22 Jan 1999 12:42:10 -0800 (PST)

> recreate the original record.

Mark,

withdrawn is implementors headache. You yourself have run into
problems in some alpha software in the past.

rps-auth solves "some other maintainer can't come along and recreate
the original record" problem.

Cengiz

---

From: Mark Prior <[email-masked]>
Date: Mon, 25 Jan 1999 10:14:11 +1030

I am not convinced that it will. It is fine in theory but practice
will be an entirely different matter.

In Australia there are 4 main IAPs (Connect, Optus, OzEmail and
Telstra). We each register our customers routes in the IRR (Telstra
uses CW and registers all customers under their AS while the rest of
us register in RADB). Just about none of the smaller ISPs appear to
know/care about the IRR and leave it up to the big 4 to register their
routes (it's pretty rare that an Australian ISP doesn't have a link to
at least one of the big 4). Internet charging being what it is the
smaller ISPs move around, don't send all their routes to all their
upstreams etc. If a customer connects to Connect (say) we will
register their route in RADB (under their AS). If they then get
another link to Optus then they will try to register their route but
will fail since we have already hijacked it (we get a nice message
from RADB telling us that the customer now has a link to Optus :-) Now
should the customer sometime later cancel their link to Connect we
will (currently) withdraw the route. There is no mechansim to warn
Optus that we have done this so the first they know about it is when
the customer complains.

We won't suffer from this problem since we have our own DB and only
use the RADB for info but this problem sort of forces you down that
path.

Mark.

---

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

> Optus that we have done this so the first they know about it is when

I dont see why withdrawing in this case helps over deleting. In either
case people who configure from IRR will not use these routes,
withdrawn or deleted. You also make it harder for your competition to
un-withdraw these routes since you are the maintainer of them.

What I would have done (with no business objectives): Register the
routes using a different maintainer than my own, but include access to
myself in that maintainer. When the customer leaves, delete access to
myself, but leave the objects in tact for the next ISP or customer to
take over. I think this is the best for the customer.

I really would like opinion from others on this.

Cengiz

---

From: Mark Prior <[email-masked]>
Date: Thu, 28 Jan 1999 09:35:58 +1030

It was more of a case of "rps-auth doesn't fix everything" than
withdrawn is needed in this context.

Oh yeah? You are expecting ISPs to cooperate, and we know that aight
gunna happen.

Mark.

---

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

Please let me know of a case (good one) for withdrawn, otherwise it is 
going away for forever:-)

Cengiz