Ripe 181

Let me make sure I understand this right. 

There are cascade of two orderings. 
A router L1 prefers a route from its peer R1
over its other peer R2 if
 1) R1's AS != R2's AS 
    and the as-in preference of this route via R1's AS
    is less than or equal to 
    the as-in preference of this route via R2's AS 
 2) R1's AS == R2's AS
    and the interas-in preference of this route via R1
    is less than or equal to 
    the interas-in preference of this route via R2.

This is almost but not equivalent to the following:
	Assume all preference values are in the range 0...Range
	a route is accepted from a peer with gated preference of
		as-in preference * Range + interas-in preference

	(in addition you map smallest of these numbers to 1, next
	smallest to 2 and so on).

Is this right? The cascade of two orderings is news to me.
Having a cascade has pros and cons. 

Some minor comments below:

Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on October 13:
> ...
> It also does not make sense to compare local (interas-in) preferences
> between different peer ASes! The preferences between the peers are defined
> in as-in.  The local preferences only differentiate between different
> peerings to the same AS.

I wish these were the words in Ripe-181. There would not be any
confusion. 

> 
> A suitable algorithm to derive gated preferences would be
> 
> 
> 	for all ASes referenced in as-in attributes
> 
> 		build an ordered list of peers by preference
> 
> 	for all ASes referenced in interas-in attributes
> 
> 		ERROR if ordered list for route cannot be found 
> 
> 		replace the peer entry in the ordered list above
> 		by an ordered list of peering sessions to this peer
> 
> 	for all ordered lists thus generated
> 
> 		output preference statements with increasing integers
> 		per list element 
> 			- for any specific peering mentioned
> 			- for all peerings to the neighbor if no specific 
> 			  peering is mentioned
> 
> 		
> 
>   > 2)
>   > Example topology:
>   > AS1 is connected to AS2 through L1 R1, L1 R2.
>   > AS1 is connected to AS3 through L1 R3.
>   > 
>   > aut-num: AS1
>   > as-in: from AS2 10 accept AS100 OR AS200
> 
> Makes lists:
> 
> AS100: AS2
> AS200: AS2
> 
>   > as-in: from AS3 11 accept AS100 OR AS200
> 
> AS100: AS2 AS3
> AS200: AS2 AS3
> 
>   > interas-in: from AS2 L1 R1 (pref=100) AS100
> 
> AS100: AS2/L1R1 AS3
> AS200: AS2 AS3
> 
>   >    preference for routes of AS100 learned from R1 is 100.
>   >    preference for routes of AS100 learned from R2: not valid.
>   >    preference for routes of AS100 learned from R3 is 11.
>   >    preference for routes of AS200 learned from R1 is XXX.
>   >    preference for routes of AS200 learned from R2 is XXX.
>   >    preference for routes of AS200 learned from R3 is 11.
> 
> preference for routes of AS100 learned from R1 1
> preference for routes of AS100 learned from R3 2
> preference for routes of AS200 learned from R1 1
> preference for routes of AS200 learned from R2 1
> preference for routes of AS200 learned from R3 2
> 
>   > The value of XXX is not specified in Ripe181. Literally speaking this
>   > means a random value. 
> 
> ripe-181 says that the preferences are equal across all peerings
> to the sam neighbor and consistent with as-in (global) policy. In this case 
> the preference value in interas-in is not relevant and can be undefined.
> This does not mean that a configuration tool cannot derive an appropriate
> value depending on the output language.

Ripe-181 does not say they are consistent. It says there is no
relevance.

> 
>   > In one of your examples [Ref 1. below], you have used
>   > the value used in the other interas-in statement. Which makes:
>   > 	XXX = 100.
>   > Daniel [Ref 2.] suggests it should be greater than any value mentioned
>   > in an interas-in statement. Which makes:
>   > 	XXX >= 101.
> 
> My brain was disengaged when I wrote this and it fell into the same
> trap as Cengiz. The value is immaterial

Exactly. This is because our brains read and interpret the ripe-181
document where the cascade of two orderings is neither explicit nor
implicit.

There is one problem that I foresee with your algorithm. You are
trying to come-up with one total ordering (per route) whereas your
input has cascade of two partial orderings.

What do you do below:

aut-num: AS1
as-in: from AS2 10 accept AS100
as-in: from AS3 10 accept AS100
interas-in: from AS2 L1R1 10 accept AS100
interas-in: from AS2 L1R2 11 accept AS100
interas-in: from AS3 L1R3 12 accept AS100
interas-in: from AS3 L1R4 13 accept AS100

Obviously there is no total ordering with these values.
A partial ordering is fine as long as gated is concerned.
However, I am not 100% sure that 
one can come up with "one" partial ordering
unless you compare interas-in preferences for different ASs
(i.e.  10 with 12).
Gated does not support two partial orderings.

Cengiz

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




-------- Logged at  Fri Oct 14 12:31:04 MET 1994  ---------