AS path regular expressions extension to ripe 181

Curtis Villamizar (curtis at ans.net) on June 19:
> 
> In message <199506161659.AA28641 at cat.isi.edu>, Cengiz Alaettinoglu writes:
> > 
> > That is why we want the extensibility to be part of the language.
> 
> Bzzt.  Bogus advertising claim here.
> 
> Unless I'm mistaken, the extensibility you have built into RPSL is in
> the area of actions.  If new pattern matching semantics were needed,
> you'd have to change the language too.

Nope, that is not true.

> 
> For example, how would you add evaluation of lisp sexps passed by some
> fancy new protocol?  This is equivalent to not having REs and someone
> coming along and wanting to pass something that has to be matched
> against an RE (though lisp sexp are a lot less likely).
> 
> Things which don't understand the new semantics are always not going
> to give you a result.  The best you can do is arrange the syntax so
> they come back with an "I don't know what to do with this" response,
> which just tells you more politely that you need to upgrade than
> a "syntax error in as-in network list at '<^690>'" message would.
> 
> Curtis

In the IETF presentation, each rpsl-attribute had a default value. A
tool would use this default value in the filters if it did not know
about the rpsl-attribute. E.g. color == 6, if a tool does not know
about color it would replace it with the default color value, say 0,
and evaluate 0==6 and produce an approximate result.

This solves the need for new attributes like extended-as-in,
super-extended-as-in, etc.

I now have a different idea where tools can reconfigure themselves
from the dictionary. Coming soon to this theater very soon.

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz.home



-------- Logged at  Tue Jun 20 00:09:14 MET DST 1995  ---------