Implementation of RIPE-181++

Tony and Daniel,

I liked Tony's original comment about keeping it simple, and 
somehow the text seems more complicated than necessary - though
please don't think I am complaining - you all have done a masterful
job.

Comments scattered after appropriate text.
>Tony Bates writes:
> 
> 
>  Daniel Karrenberg <Daniel.Karrenberg at ripe.net> writes:
>   * 
> Okay, thanks for your changes. I have incorperated them and added a
> small note on the slitting ASes. Find below he revised text. 
> 
> 	
> 		--Tony.
> 
> P.S. Today is really the last day to comment before we send this
> document out as ripe-181.
> 
> The interaction of interas-in/interas-out with as-in/as-out
> 
> Although formally defined above, the rules  associated  with  policy
> described  in  terms  of  interas-in and interas-out with respect to
> as-in and as-out are worthy of clarification for implementation.
> 
> When using interas-in or interas-out policy descriptions,  one  must
> always  make  sure the set of policies described between two ASes is
> always equal to or a sub-set of the policy described in  the  global
> as-in  or  as-out  policy.  When a sub-set is described remember the
> remaining routes are implicitly shared across all connections. It is

The sentence, "When a sub-set is described remember the remaining routes
are implicitly shared across all connections." has always been confusing
for me.  I am sure that I don't interpret this as it is meant, and
can't figure out why it seems to mean something that we don't want to
mean.  What it says to me is, if my global policy is accept a+b+c
and my subset policy is accept a+b, then the remaining route is c
and it is accepted by all connections.  Now, that is different than
what I thought we agreed (in fact it is incorrect).  Please try to 
clarify what it is I am missing in my intrepretion of this sentence.  
I really think I understand what we mean, but this sentence just doesn't jive.

> an error for the interas policies to describe a superset of the glo-
> bal policies, i.e. to announce or accept more routes than the global
> policies.
> 
> When defining complex interas based  policies  it  is  advisable  to
> ensure  that  any possible ambiguities are not present by explicitly
> defining your policy with respect to the  global  as-in  and  as-out
> policy.
> 
> If we look at a simple example, taking just  in-bound  announcements
> to simplify things. If we have the following global policy:
> 
> 
> aut-num: AS1
> as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
> 
> Suppose there are three peerings between AS1 and AS2, known  as  L1-
> R1, L2-R2 and L3-R3 respectively. The actual policy of these connec-
> tions is to accept AS100 equally on these three links and just route
> 10.0.0.0/8  on L3-R3. The simple way to mention this exception is to
> just specify an interas policy for L3-R3:
> 
> interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}

My simple policy description of L3R3 would be:
interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}
interas-in: from AS2 L3 R3 (pref=10) accept AS100
because the statement about the difference between as-in and interas-in
is equal across all the links is easy to misinterpret.

I think that we should strive to encourage folks who are explicitly
stating an exception to state it explicitly.

> 
> 
> The implicit rule that all routes not mentioned in interas  policies
> are  accepted on all links with equal preference ensures the desired
> result.
>

This still seems confusing to me, because if you have two different
interas-in statements, the total subtraction from the as-in statement
could result in a difference of zero, which is not what you were
trying to express.

Basically, I have the same problem with this statement as I did with the
previously noted sentence. 

> The same policy can be written explicitly as:
> 
> interas-in: from AS2 L1 R1 (pref=100) accept AS100
> interas-in: from AS2 L2 R2 (pref=100) accept AS100
> interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}
> 
> 

Small error (it may be a typo, but it is why my previous example
looks like it does).  In the as-in statement we use "10" not "100."
But maybe you meant to do that to stress that the preferences in
as-in and interas-in are unequivilant.  But if that is the case,
how can you decide that the preference to accept AS100 is
comparable to the preference to accept {10.0.0.0/8}.  Or doesn't
it matter? I would have thought that if something is unstated,
it would be interpreted exactly as stated in the as-in statement.

> 
> 
> ripe-181.txt                                           October, 1994
> ^L                               - 29 -
> 
> 
> Whilst this may at first sight seem obvious, the problem arises when
> not all connections are mentioned. For example, if we specified only
> an interas-in line for L3-R3 as below:
> 
> aut-num: AS1
> as-in: from AS2 10 accept AS100 OR {10.0.0.0/8}
> interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}
> 
> 
> then the policy for the other links according  to  the  rules  above
> would mean they were equal to the global policy minus the sum of the
> local  policies  (i.e.  ((AS100  OR  {10.0.0.0/0})   /   (AS100   OR
> {10.0.0.0/0}))  =  empty)  which  in this case would mean nothing is
> accepted on connections L1-R1 and L2-R2 which is incorrect.
> 

What I think is incorrect is the statement, "remaining routes are 
implicitly shared across all connections."  If we delete this statement
we avoid all the ambiguity.

The problem is in what we have stated and then how we want it to
be interpreted.  They are inconsistent.

> Another example: If we only registered  the  policy  for  link   L2-
> R2:
> 
> interas-in: from AS2 L2 R2 (pref=100) accept AS100
> 
> The implicit policy for both L1-R1 and L3-R3 would be as follows:
> 
> interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8}
> interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8}
> 
> 
> This is derived as the set of  global  policies  minus  the  set  of
> interas-in  policies  (in  this case just accept AS100 as it was the
> L2-R2 interas-in policy we  registered)  with  equal  cost  for  the
> remaining connection. This again is clearly not what was intended.
> 
> We strongly recommend that you always mention all policies  for  all
> interas  connections explicitly, to avoid these possible errors. One
> should always ensure the set of the interas policies is equal to the
> global policy. Clearly if interas policies differ in complex ways it
> is worth considering splitting the  AS  in  question  into  separate
> ASes.  However, this is beyond the direct scope of this document.
> 
> It should also be noted there is no direct relationship between  the
> cost used in as-in and the preference used in interas-in.
> 
> 

        --Elise



-------- Logged at  Tue Oct 4 20:47:38 MET 1994  ---------