About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: new proposal for rpslng

  • To: Joao Luis Silva Damas < >
  • From: Florent Parent < >
  • Date: Tue, 15 Jan 2002 10:32:15 -0500


--On 2002-01-15 14:03:47 +0100 joao@localhost wrote:

First of all, sorry for not having commented earlier.

Let me start by showing my astonishment about the fact that of the 4
suggested methods for expanding RPSL described in 2622, you seem to have
jumped directly to the last one, the least desirable one.

Apart from the obvious software problems the current proposal may (will)
generate,
? Clearly, this implementation requires an update to the current tools to understand the new syntax.

I think there is an additional one, which for me is quite
important: user confusion.

I would rather have a route6 class and import6/export6 attributes (in the
autnum object). It is cleaner and it ehklps to avoid user mistakes, both
when generating the data and when reading it.
At the cost of introducing new attributes and class for IPv6 only. I had initially considered that "route", but you end up adding many new attributes and classes to add IPv6. The route taken here is more like making RPSL "IP independent", ie. not adding any new classes or attributes that are specifically tied to an address family.

One other thing I found surprising while reading the current proposal was
the fact that, while there seems to be discussion about even mpls-vpn in
RPSL (which I myself believe to be outside the scope of RPSL),
I don't see any such reference in the document.

there is
mention of ipv6 and multicat tunnel description. While one should be able
to describe routing policies for native IPv6 networks, I believe if we
leave out a way to describe tunnels, 6to4 gateways, etc the use for the
IPv6 RPSL will be very limited. As a matter of fact, this was the part
where we asked for more input from people running networks, so that we
could get a set of clear requirements that the language extensions should
address, before jumping into an i-d.
Tunnel description was removed from the current document as I needed more thoughts/discussion on the subject. I fully agree that we have to work on this.

Thanks Joao. I hope more discussions will occur during the conference.

Florent.







  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community