as-in/as-out

  > epg at merit.edu writes:
  > > Tony and I have provided an extensive motivated critique of your 
  > > last proposal and have never heared back. Maybe we can start off there?
  > > 
  > Let me search my mail - I remember a note from Tony (while you were
  > ill) but don't recollect anything else.

-------
Date:        Tue, 22 Mar 1994 13:53:02 +0100
From:        Daniel Karrenberg <Daniel.Karrenberg at ripe.net>
Sender:      dfk at reif.ripe.net

To:          Elise Gerich <epg at merit.edu>
Cc:          rr-impl at ripe.net

Subject:     Re: extensions for routing registry 
In-Reply-To: Your message of Thu, 10 Mar 1994 16:37:07 EST.
	     <199403102137.QAA16455 at merit.edu> 
-------


To add to Tony's comments with which I agree.

- I personally do not like the [to] [from] etc. syntactic sugar.
  Users who want a more comfortable input language, should use a local 
  post/preprocessor which we should provide.
  If the routing registry itself (view it as a database) provides different
  representations we will get lots of confusion as to the semantics.
  Also all tools using the RR will have to accept multiple representations
  which is only adding possibilities for bugs and general entropy

- The RIPE-81 as-out does *not* have a preference for a reason.
  I (think I) know what you want to do, BUT ...
  Try to define the semantics in a clear, concise and understandable way! 
  I cannot.
  This will also obscure the principle of what as-in and as-out really means.
  This will lead to confusion even if its optionality and advisory nature 
  is clearly marked.
  The only gain obtainable from it is some conistency checking implementable
  only if the full topology is known.
  Rather use as-exclude and as-transit for this as these are clearly non-local
  attributes.

- Usage of communities must be clearly flagged with the potential problems
  w.r.t. implementability. The only way I see it implementable is network
  based lists, now that the BGP4 folks have withdrawn the path attribute from
  the spec. It also needs to be mentioned that using them can potentially
  hurt CIDR aggregation efficiency badly.

- I like the as-exclude attribute (without syntactic sugar)
  It needs more language about that this can be implemented in two ways:

	- using path info by the AS registering the as-exclude

	- filtering implemented by the AS mentioned.

  The second is advisory in nature but should be encouraged. It needs
  language that filtering by the AS mentioned is quite OK based on the
  as-exclude etc. pp.

  This also means we need a way to provide server functionality of the type
  "tell me all ASes mentioning ASx (me) in as-exclude!" At them moment we
  can get this from the full database file but this does not scale.

- as-transit can be quite usefule but needs a better definition of semantics 
  It has similar problems as as-out preferences: You need the whole graph.
  But these are more acceptable here as as-transit is clearly not local.
  It also needs a section on how this can be implemented. 
  And its advisory nature.

- border router level
  this should not go in the as-out attributes but rather be a separate
  set of attributes line "link-out" "link-in" with a requirement
  to have the as-in and as-out as well. this way you get an optional level 
  of complexity.
  Otherwise it looks fine.

- database selector
  same problems as community

In conclusion I personally would be very unhappy if you folks announced a 
registry using this stuff tomorrow. This needs some solid design sessions
where semantics are clearly defined and we can discuss what is needed and
what is fluff. Finally this needs some test as to wether people actually
understand it (the same way).

I strongly fear that adding too many features at this point in time can 
provide enough problems to make this whole RR idea fail. 
I do not want that to happen.

Another *very worthwhile* idea is to make much more clear what is basic
functionality and what is enhanced functionality.

Please do not understand these remarks as antagonistic or de-valuing your
work. Due to resource-sacrceness over here you are very much leading
the way for extensions. I apreceiate that very much. My overwhelming
concern is to not de-value the RR concept by making it overly 
complex.

Daniel

PS: I am missing the aggregate stuff.

  > > We will also have to add classless/aggregation support in this go.

  > We had been using the inetnum object to represent classless/aggregates;
  > but that may be a problem for you all since you also need it for
  > network assignment/allocation.  Have you thought about using inetnum
  > for the classless/aggregate object or were you leaning toward creating
  > a new object?

We have come to a basic design which we will put up for scrutiny by y'all
in a while. Need to write it up.

Daniel



-------- Logged at  Wed Apr 27 18:03:37 MET DST 1994  ---------