Implementation of RIPE-181++

>It should also be noted there is no direct relationship between  the
>cost used in as-in and the preference used in interas-in.

Actually, the cost in as-in and the preference in interas-in need to be
comparable.  See the example below:

AS1 peers with AS100 at two interconnections.  AS100 include nets 
{a,b,c,x,y,z}.  AS1 likes to do load banlancing by accepting nets a,b,c
at interconnection1 (L1 R1) with preference 1 and x,y,z with preference 2.
At interconnection2 (L2 R2), AS1 accepts x,y,z with preference 1 and a,b,c
with preference 2.  The policy expression would be as follow:

aut-num: AS1
as-in: from AS100 1 accept AS100        
interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c}
interas-in: from AS100 L1 R1 (pref=2) accept {x,y,z}
interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} 
interas-in: from AS100 L2 R2 (pref=2) accept {a,b,c}

If people do explicitly list their interas-in policy, then there is no
problem.  However, if people do not explicitly list them as the current
version allows, then we will have a problem if the cost and pref is not
comparable. 
 
aut-num: AS1
as-in: from AS100 1 accept AS100
interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c}
interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z}

This implies that

interas-in: from AS100 L1 R1 (pref=1) accept {x,y,z}
interas-in: from AS100 L2 R2 (pref=1) accept {a,b,c}

This is incorrect policy.

So for this example, either we advice people the be carefully put their
cost and pref that means they are not uncomparable, or have to have them
explicitly list the interas policy which needs a change to the current
text.

						--Jessica  



-------- Logged at  Tue Oct 4 21:12:16 MET 1994  ---------