One document matched: draft-ietf-rps-extending-00.txt

Internet Draft                                           Cengiz Alaettinoglu
Expires  May 20, 1998                                                USC/ISI
draft-ietf-rps-extending-00.txt                                  David Meyer
                                                        University of Oregon
                                                               David Kessens
                                                                     USC/ISI
                                                           November 20, 1997


                       Guidelines for Extending RPSL





Status of this Memo


This document is  an Internet  Draft, and  can be  found as  draft-ietf-rps-
extending-00.txt in  any  standard internet  drafts  repository.    Internet
Drafts are working documents of the Internet Engineering Task Force  (IETF),
its Areas,  and  its Working  Groups.    Note  that  other groups  may  also
distribute working documents as Internet Drafts.

Internet Drafts  are draft  documents valid  for a  maximum of  six  months.
Internet Drafts may be  updated, replaced, or  obsoleted by other  documents
at any time.   It  is not appropriate  to use Internet  Drafts as  reference
material, or to cite  them other than  as a ``working  draft'' or ``work  in
progress.''

Please check  the I-D  abstract  listing contained  in each  Internet  Draft
directory to learn the current status of this or any other Internet Draft.


1 Introduction


This Internet Draft  describes guidelines for  extending the Routing  Policy
Specification Language  (RPSL) [3,  4].    Our  experiences with  PRDB  [2],
RIPE-81 [6], and  RIPE-181 [5]  taught us  that RPSL had  to be  extensible.
These languages were not  extensible and each transition  to a new  language
turned out to be quite  painful.  As a  result, extensibility was a  primary
design goal for  RPSL. New  routing protocols  or new  features to  existing
routing protocols can be easily handled using RPSL's dictionary class.   New
classes or new attributes to the existing classes can also be added.

Objects specified in the policy language are stored in the Internet  Routing
Registry (IRR)  [1, 7,  4].    Replacing  the specification  language  often
involves re-registering the existing objects in  the new syntax.   Software,
Internet Draft                Extending RPSL               November 20, 1997

either public domain or in-house, needs to be updated to understand the  new
syntax.   And the user  community needs to  be informed and  trained of  the
changes.

The initial RPSL dictionary object can be used to express most or all of the
policies being used in the Internet today.  However, extensions to RPSL will
be necessary as new  routing protocols or new  features to existing  routing
protocols are introduced.   This document provides guidelines for  extending
RPSL. These guidelines are designed with an eye toward maintaining  backward
compatibility with existing tools and databases.


2 Guidelines


In this section, we list the  available options for extending RPSL. We  list
them from the most preferred to the least preferred order.


2.1 Extensions by changing the dictionary class


Before proceeding  with  any  extensions,  the dictionary  class  should  be
studied in depth.   The dictionary class  is the primary mechanism  provided
to extend RPSL. Dictionary objects define routing policy attributes,  types,
and routing protocols.  Routing  policy attributes may correspond to  actual
protocol attributes, such as the  BGP path attributes (e.g. community,  dpa,
and AS-path), or they may correspond to router features (e.g. BGP route flap
damping).

We recommend  updating the  RPSL dictionary  object to  include  appropriate
rp-attribute and protocol  definitions when  new path  attributes or  router
features are introduced.   For example,  in an earlier  version of the  RPSL
document, it  was only  possible to  specify that  a router  performs  route
flap damping on a peer,  but it was not  possible to specify the  parameters
of route flap  damping.   Later the  parameters were added  by changing  the
dictionary.

When changing the dictionary, full compatibility should be maintained.   For
example, in  our flap  damping  case, we  made the  parameter  specification
optional in case this level  of detail was not desired  by some ISPs.   This
also achieved compatibility.   Any object registered without the  parameters
will continue  to be  valid.   Any  tool based  on RPSL  is expected  to  do
a default action on  routing policy attributes that  they do not  understand
(e.g. issue  a  warning and  otherwise  ignore).    Hence,  old  tools  upon
encountering a flap  damping specification with  parameters will ignore  the
parameters.






Alaettinoglu et.  al.             Expires  May 20, 1998             [Page 2]
Internet Draft                Extending RPSL               November 20, 1997

2.2 Extensions by adding new attributes to existing classes


New attributes  can  easily  be  added  to  any  class.     To  ensure  full
compatibility, new attributes should be  optional and should not  contradict
the semantics of  the objects  they are  attached to.   Any  tool that  uses
the IRR should  be designed so  that it ignores  attributes that it  doesn't
understand.  Most existing tools adhere to this design principle.

We recommend adding new attributes to existing classes when a new aspect  of
a class is discovered.  For  example, RPSL route class extends its  RIPE-181
predecessor by including  several new attributes  that enable aggregate  and
static route specification.


2.3 Extensions by adding new classes


New classes  can  be added  to  RPSL to  store  new types  of  policy  data.
Providing full compatibility is straight forward as long as existing classes
are still  understood.   Since  a tool  should only  query the  IRR for  the
classes that it  understand, full compatibility  should not be  an issue  in
this case.

New classes should  be added  with care.   Before  adding a  new class,  one
should question  if the  information contained  in the  objects of  the  new
class could have  better belonged  to some  other class.    For example,  if
the geographic location of  a router needs  to be stored in  IRR, it may  be
tempting to add a new class called, say router-location class.  However, the
information better belongs to the inet-rtr class, perhaps in a new attribute
called geographic-loc.

RPSL added several  new classes  to RIPE-181.    For example,  we added  the
route-set class which assigns a name to a set of address prefixes.   None of
the classes in RIPE-181 were appropriate for storing this binding.


2.4 Extensions by changing the syntax of existing RPSL attributes


If all of the methods described above fail to provide the desired  extension
or extensions,  it  may be  necessary  to change  the  syntax of  RPSL.  Any
change in  RPSL syntax  must  provide backwards  compatibility,  and  should
be considered only  as a  last resort since  full compatibility  may not  be
achievable.   That  is, old  tools may  break when  they  encounter the  new
syntax.  However, we require that the old syntax to be still valid.

One of the innocent  changes we made  to RIPE-181 was  to add comments  that
started on a hash  character (i.e. '#')  and ended at the  end of the  line.
These comments can be inserted anywhere.  However, this innocent new feature
is expected to break some of the  existing tools since they are not  written


Alaettinoglu et.  al.             Expires  May 20, 1998             [Page 3]
Internet Draft                Extending RPSL               November 20, 1997

to skip over comments.


3 Conclusions


In this document, we have  provided guidelines for extending RPSL.  However,
for extensions to be  adapted, IRRs may  need to deploy new  software.   The
ISPs need  to learn  of  the extensions.    Hence,  the extensions  must  be
documented, most preferable as  an IETF standards  RFC. Registries may  also
require some proof of user interest in the extensions before proceeding.



References


[1] Internet            Routing            Registry.             Procedures.
    http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.

[2] NSFNET   Policy   Routing   Database   (PRDB).   Maintained   by   MERIT
    Network   Inc.,   Ann   Arbor,   Michigan.   Contents   available   from
    nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now   by    anonymous
    ftp.

[3] C.  Alaettinouglu,  T.  Bates,  E.  Gerich,   D. Karrenberg,   D.  Meyer,
    M. Terpstra,  and C. Villamizer.  Routing Policy Specification  Language
    (RPSL).  Internet  Draft  draft-ietf-rps-rpsl-04,   Network  Information
    Center, November 1997.

[4] C.  Alaettinouglu,  D. Meyer,  and  J. Schmitz.  Application  of  Routing
    Policy  Specification Language (RPSL)  on the  Internet. Internet  Draft
    draft-ietf-rps-appl-rpsl-01, July 1997. Work in progress.

[5] T.  Bates,  E. Gerich,  L.  Joncheray, J-M.  Jouanigot,  D.  Karrenberg,
    M.  Terpstra,  and J.  Yu.  Representation  of IP  Routing  Policies  in
    a  Routing  Registry.  Technical Report  RFC-1786,  Network  Information
    Center, March 1995.

[6] T. Bates, J-M.  Jouanigot, D. Karrenberg, P. Lothberg, and M.  Terpstra.
    Representation of  IP Routing Policies in  the RIPE Database.  Technical
    Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.

[7] A.  M. R.  Magee.  RIPE  NCC Database  Documentation.  Technical  Report
    RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.








Alaettinoglu et.  al.             Expires  May 20, 1998             [Page 4]