as-in/as-out

OK, back to as-in/as-out or another attribute.  I did dig up all the
messages (2).  Here are the comments that referred specifically
to as-in/as-out:

tony.bates at ripe.net writes:
1) "When do you stop this list (explicit net #s) and turn it into
a community list anyway just for clarity, 10, 1000, ?" as-in comment
2) "I would like to see tis metric part noted as advisory information
as well and clearly that as this is all it is and not enforceable at
all." as-out comment
3) "Some general things. I'm not sure the verbosity of optional 'to,
announce, accept' really adds much.  As an operator I want the tools to
do things for me and if I need verbosity get them to pput in there.
These are all directly implicted so if needed get the server to do it."
as-in and as-out comments
4) "I see why you might like this but hasn't it just gone into an area
of complexity you don't want in the registry. I do see it but I do not
think it will be used except by a few very large transit sites and then
could easily map this information in another way.  The only tool where
this might help is in prtraceroute I guess." gateway info for as-in and
as-out comment
5) "Again this is fine except for the level of complexity it adds to the
representation." db selector comment

daniel.karrenberg at ripe.net writes:
1 "- 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" 
2 "- 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."
3 "- 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."

I will focus on two of the issues mentioned: as-out metrics and
the gateway semantics.

One of the "services" that this registry can offer is configuration
generation.  With the NSFNET experience and what we anticipate
will be expected from the RA, this information is needed to
generate the correct configuration files. So whereas this information
is not binding, and it is not used by tools such as prtraceroute,
it would be needed in the generation of router configurations.

The border router extension solves the problem of an autonomous
system that has two border routers that have different routing
policies - Barrnet does this all the time. So it seemed logical
to associate 'border route', 'neighbor', and 'cost' in the same
attribute.  In the RIPE-81 as-in attribute this added one optional
value; in the RIPE-81 as-out attribute it would require making
as-out syntactically consistent with as-in. The value of adding
this (even if rarely used) is the ability to generate router
configurations and for prtraceroute (as Tony says).

         --Elise 




-------- Logged at  Thu Apr 28 21:37:13 MET DST 1994  ---------