Draft of RIPE81++

Hi all,

I am quite new on this list. Here are my opinions on this
issue. Perhaps most of my concerns have been addressed.

First of all, I do not agree that a new attribute is necessary to
support multi-exit discriminators. Why not just extend the as-in/out
statements? If backward compatibility is the reason, the previous
syntax can be made a special case. If ambiguity is the reason, there
are simple solutions as proposed.  I support that the specification of
0,1 or 2 border-routers are allowed. [see below]

epg at merit.edu (epg at merit.edu) on September  2:
> We are concerned that requiring the identification of the local
> gateway and the remote gateway in the interas attribute has two
> problems.  The first problem is that of maintenance of the attribute.
> If an AS is required to list both the local gateway and the remote
> gateway, then the AS must update its registry information whenever
> the remote AS makes any configuration changes. This could lead
> to many inconsistencies within the database. 

I will use "br-edge" to mean border-router-to-border-router edge in
the following.

A br-edge can be identified with 
	1) two AS numbers 
	   if there is only one br-edge between two ASs
	2) two AS numbers and one border-router address 
	   if there are
	   multiple br-edges between the ASs, but each border-router
	   is only connected to one border-router in the other AS
	3) two AS numbers and two border-router addresses 
	   if there are multiple
	   br-edges and a border-router is connected to two
	   border-routers in the other AS.

With what Tony proposes, ripe81++ allows specification of either 0
(with as-in) or 2 border-router addresses (interas-in). Elise proposes
to allow also specification of 1 border-router address to cover case 2
above since it is helping in maintaining the databases. I have not
seen the reason why it is necessary/useful to force specifying two
addresses in this case.  I have more important reasons to support
specifying one addresses. [See below]
	
>   * 2) the mandatory nature of asin/out attributes if interas attributes are
>   *    present

Even if they are optionally present the semantics of such expressions
are not clear in the document (at least July 94 version) and can be
ambiguous. What is the semantics of the following policy:

as-in: AS690 100 NOT ANY
interas-in: L:foo AS690 R:bar 100 ANY

(please forgive the syntax errors :-)

Jean-Michel Jouanigot (jimi at dxcoms.cern.ch) on September  6:
> Elise, I agree with you, there's no need to register  information
> you don't need, it's more difficult to manage, but as Tony points
> out, why would anybody need this detailed information unless  you
> really  want to configure a box with it, in which case you *need*
> the local and remote addresses. 

You have a point. But the boxes are now getting more complicated:-)
One such box is the Routing Arbiter Route Server. RS peers with many
border routers. Hence, someone who peers with an RS may not (and does
not need to) know addresses of other border routers. Multi-exit
discrimination may be achieved if specification of one border-router
address is allowed.

Regards.

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
cengiz at isi.edu            University of Southern California




-------- Logged at  Wed Sep 7 10:37:46 MET DST 1994  ---------