Implementation of RIPE-181++

  > Tony Bates <Tony.Bates at ripe.net> writes:

The text looks very good.

  > I would rather we just
  > made it - ALL polices should be explicitly mention and the sum of
  > interas policiy must equal global as policy.

The reason I don't like this is that I expect many of the 
interas policies to be a limited set of exceptions to the global
policy.

To repeat: If the interas policies differ in complex ways,
it is really worth considering to split the AS in question.
For reasons refer to many a discussion on bgpd.
Should we mention this?

Here are my suggested changes, feel free:


  > The interaction of interas-in/interas-out with as-in/as-out
  > 
  > Although stated above, the rules associated with policy described in

s/stated/formally defined/

  > 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 an error for the interas policies to describe a superset of the
global policies, i.e. to announce or accept more routes than the global
policies.


  > When defining interas based policy one should always ensure that any

When defining complex interas based policies it is advisable to ensure ...
  > possible ambiguites are not present by explicitly defining your pol-
  > icy 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 connections (here connections can mean  peer
  > sessions  or physical connections) between them, known as L1-R1, L2-
Suppose there are three peerings between AS1 and AS2, known ....

  > R2 and L3-R3 respectively. The actual policy of these connections 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}

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

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}
  > 
  > 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 conections L1-R1 and L2-R2 which is incorrect.

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 connectiosn. This again is clearly incorrect.

s/incorrect/not what was intended./

  > We strongly recommend that except in simple cases 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.
  > 
  > It should also be noted there is no direct realtionship between  the
  > cost used in as-in and the preference used in interas-in.



-------- Logged at  Tue Oct 4 11:03:59 MET 1994  ---------