here's as far we have got.

  > jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) writes:
  > 
  > Jessica, Tony, Daniel, (probably others)
  > 
  > 	Since you are all at the regional-tech, I would propose you try to
  > 	agree on:
  > 
  > 	1- We keep the as-in as-out stuff as it is
  > 	2- the interas-in/out will contain the IP router addresses AND the
  > 	pref metric in interas-out.
  > 	PS: I still do beleive what Gilles suggested (no component) is
  > 	sound.
  > --
  > Jean-Michel.

We sat and discussed. Here is the outcome as I recall it. I was very tired
so it may not be all that accurate in the details.
-----------

About as-transit and the experimental doc:

All objects about which there is no consensus that they should go into
81++ should be published as "experimental" RR stuff in one separate
document called RR extensions or some such.  The extensions document
will be updated whenever there is a new extension.  ripe-81++ shall have
text pointing out that possibility and a way to find the newest version
of the extensions document.  This text is to be proposed by the MERIT
folks a.s.a.p.  The extensions document should always be a collection of
*all* experimental extensions being used. 

as-transit goes in the experimental doc.  Merit writes it up. 

----------

About metrics in interas-out. 

There were two proposals:

1) represent outgoing metric information as a preference similar to the
preference in interas-in:

2) represent outgoing metric information in a separate attribute

After heated discussion we agreed that the outgoing metric (MED) is to
be represented in the interas-out attribute (option 1). 

The syntax has to be such to prevent confusion between the outgoing
preference representing a metric to be generated and the incoming
preference representing a static preference in accepting mroutes.  The
latter is a fundamental concept of the RR which should not be made
obscure or confused in any way.  

They syntax needs to accomodate metric values for different EGPs.  As a
minimum it must be specified which EGP is used and which of the EGP's
metrics will be set. 

Merit is to propose a syntax a.s.a.p. 

This is only concerned with generating metrics and not with registering
whether and how to use received metrics.  While this is sufficient to
generate *local* configurations it is not enough for a routing registry.
In a routing registry the recipient of such metrics must be able to
register whether and how he will use received metrics.  Just generating
a metric is not enough.  

Merit is to make a proposal for this at the same time. 


-------------


The component attribute seems to be too confusing to be useful after
all.  It has two uses: registering holes and registering information
about heterogeneous aggregates. 

We all agree that registering holes, i.e.  parts of a route to which the
originator has no connectivity is a good thing.  Gilles has proposed a
special attribute "hole:" for this to make it clearer.  We agreed to use
the hole attribute. 

The other use of component is to register heterogeneuity of routes. 
Some have argued that membership information (AS, community) is either
used in routing or it is not.  If it is, one should not aggregate routes
with difeerent membership information and create heterogeneous
aggregates.  If one does not do this, each route will be homogeneous and
the hints provided via the component attribute are not needed.  Gilles
has put this argument very well.  If this strategy is used routing and
its description in the registry will be very clear. 

However, we believe that this strategy will not be used exclusively.  It
hurts aggregation efficiency badly.  We strongly believe that some ASes
will want to agggregate more agressively, accepting the loss in routing
granularity that they and others will suffer as a consequence.  In fact
We belive that we should encourage such behavior for the sake of routing
efficiency and scaling. 

Once such inhomogeneous aggregates are created and the more speicifc
homogeneous routes withdrawn there is no information left about the
routing granularity that existed before.  The component attribute was
designed to provide the originator of heterogeneous aggregates with a
way of documenting the heterogenuity.  Our expectation is that
this would encourage routing efficiency because people would be more
confident to aggregate if they had a way to document potential problems.

Unfortunately the component attribute is less than clear and
authorisation is a problem too.  So let us look at another way of doing
this: Introduce an attribute "withdrawn:" or "not routed" to the route
object in order to specify that the route specified is not really
originated.  This solves the authorisation problem and is
also easier to understand in the first place.  The only problem with it
is that it may be confusing in the second instance because seeing a
route object does not automatically mean that the route described is
originated somewhere.  This could be solved by using a new object
altogether for not originated routes. 

RIPE folks to make the proposals a.s.a.p.  
This will be early next week.

If we do this the new "hole:" attribute and the "withdrawn:" attribute
replace component.  The only problem is that we loos the DMZ interface
information that used to be in ias-int:.  Laurent suggested to use
a new "border-router" object for this. The advantage of this obviously
is clarity. Everyone understands what a border router and its interfaces
are. Merit is to write this up.

We agreed to

	- throw away component (it was overloaded and unclear)
	- introduce "hole:" 
	- introduce a way to have unannounced routes
		- either with a new attribute to the route object
		- or with a new object name altogether 
	- document DMZ interfaces with a "border-router" object	


Comments ?

Daniel





-------- Logged at  Mon Jun 6 13:46:54 MET DST 1994  ---------