AS path extensions
Cengiz Alaettinoglu
Tue Mar 14 20:00:49 CET 1995
Dennis, Thanks for the clarification. Dennis Ferguson (dennis at mci.net) on March 13: > Cengiz, > > > Cisco is using a different syntax which is closer to grep. However, > > gated's as path syntax misses a feature that I think is important. > > Perhaps I should use the posix syntax as Daniel suggested. > [...] > > It is not possible to specify ranges, and negation of ranges > > (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as > > path expression for "as paths not containing AS100" without listing > > all 65K AS numbers in that expression. This would be > > "^[^AS100]*$". There are other advantages of ranges, they reduce the > > number of states in the compiled pattern. > > I'm currently independently reworking some of this stuff for a gated v4.0 > someday. I've included negation, so the above pattern becomes (I think) > "(!100)*". Ranges are not supported, not necessarily because they couldn't > be supported within the syntax but rather because I'm having difficulty > figuring out why one would want them other than to hack around the lack > of negation. Neat. I need a clarification. Do you allow negation of any regular expression or just negation of as numbers? If you allow just the negation of as numbers, how do you represent [^100 200]*, i.e. as paths containing neither 100 nor 200? I was referring to anything that goes into "[" "]" in grep as ranges. You are probably right that expressions like [100-200] is not too useful. > > Note that your last sentence isn't true for my reimplementation (I'm not even > sure it was before), ranges don't reduce the number of states in the compiled > pattern compared to or'd lists. Since long lists of |'d AS numbers occur > frequently, patterns of the form ( 86 | 200 | 201 | ... ) also compile to > a single state in the DFA in a data structure which makes the actual match > pretty fast. Nice. > > > AS65535)*". This is a short term fix. I think more grep like syntax is > > desired. > > I can't figure out the grep-like part. I'm pretty sure there is nothing > which can be written in grep-like syntax which can't be represented in > the syntax gated uses, and I suspect the reverse probably true as well > (with some proviso's, for example it isn't clear to me how one would do > > .* (1239 | 1240 | (86 179)) > > in grep without blowing it out to multiple lines, and multiple line regexp's > will very likely be either harder to compile efficiently or slower to execute). > I think you're complaining about features rather than syntax, features can > be added to either syntax. Oh no, I am not complaining. I think the context of my message was missing. I am extending ripe-181 to allow specification of as path expression. Curtis suggested to use the gated syntax for regular expressions in my extensions. I have not picked gated's syntax because it lacked negation and ranges. > > The other thing the reimplementation does is attempt to do something with > AS sets. In particular, > > 86 .* [200 201 .*] > > matches a path beginning with 86 (or a set which includes 86) and ending with > a set which includes at least 200 and 201. > > [86] .* [200 201] > > matches a path with an initial sequence starting with AS 86 and ending with > a set of exactly 200 and 201. This is also neat. May I suggest not to use "[" and "]", because people will confuse them with grep's "[" and "]", especially if we pick "[" and "]" to mean ranges in the registry. > I do this as > > import as-path-exp-1 preference 1 { > net ... > net ... > all continue ; > } ; > import as-paths-exp-2 preference 2 { > net ... > net ... > all restrict ; > } ; This would be perfect. Is this implemented? Cengiz P.S. In Danvers IETF, there is a Routing Policy System BOF to define a language for specifying routing policies (mailing list rps at isi.edu). It is on thursday morning. -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Wed Mar 15 11:09:30 MET 1995 ---------
[ rr-impl Archive ]