Implementation of RIPE-181++
Elise Gerich
Mon Sep 26 03:28:19 CET 1994
Hmmmmmmmmmm...seems like the text is a bit fuzzy, or at least open to interpretation. AS-in is the sum of the policies between any two ASes. Yes? Therefore, if any session (we are not really talking links) between two ASs does not equal the sum (as-in), all of the sessions (interas-in statements) should be explicitly defined to identify unabiguously the addends. So in Laurent's scenario, there are three sessions. The total policy for as1 is to accept from as2 the set of nets belonging to as100 and also to accept net {10/8}. The sessions between as1 and as2 at naps 1 and 2 are unequal to the sum (looking at each session independently). Therefore, It is necessary to explicitly describe all sessions between as1 and as2 for clarity. aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L1 R1 accept as100 interas-in: from as2 L2 R2 accept as100 interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} If someone registers this as: aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L3 R3 accept as100 or {10.0.0.0/8} The policy would be assumed to be equal for all sessions - even though that is not explicitely stated. There is no way to determine the exception to the global (sum ofthe policies)policy. If someone registers this as: aut-num: as1 as-in: from as2 accept as100 OR {10.0.0.0/8} interas-in: from as2 L1 R1 accept as100 The policy for the other two sessions would be assumed to be equal to the policy stated in the as-in statement. The interas-in line that is explicitely stated is assumed to be the exception from the total sum of the policies. It should be unambiguous if the maintainers explicitly define all sessions. If the maintainers do not, I propose that we determine the undefined sessions in the way previously described. --Elise -------- Logged at Mon Sep 26 21:59:07 MET 1994 ---------
[ rr-impl Archive ]