Ripe 181

  > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes:

Cengiz,

Sorry for the late reply. I was too busy to take the time to re-think this
properly and write down an answer. But now here goes:

The as-in attributes define an ordered list of peerings:

	- per route accepted
	- per peer AS

The interas-in attributes *refine* this list

	- per route accepted
	- per peer AS
	- per external peering 

Thus (as you rightly note) it does not make sense to compare preferences
between different routes (ASes) accepted.

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.

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.

  > 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

  > On the other hand, we need to compare the preference of AS200 routes
  > received from AS1 and received from AS2. According to the as-in, we
  > prefer it from AS1. Hence:
  > 	XXX < 11, XXX = 10 (as-in value).

Indeed, see above.

  > 3.
  > Example topology:
  > AS1 is connected to AS2 through L1 R1.
  > AS1 is connected to AS3 through L1 R3.
  > 
  > aut-num: AS1
  > as-in: from AS2 10 accept AS100 OR AS200

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=101) AS100

AS100: AS2/L1R1 AS3
AS200: AS2 AS3

  > interas-in: from AS3 L1 R3 (pref=100) AS100

AS100: AS2/L1R1 AS3/L1R3
AS200: AS2 AS3

  > consider L1's configuration file (gated's import proto bgp ...)
  >    preference for routes of AS100 learned from R1 is 101.
  >    preference for routes of AS100 learned from R3 is 100.
  >    preference for routes of AS200 learned from R1 is XXX.
  >    preference for routes of AS200 learned from R3 is YYY.

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 R3 2

  > Again document does not tell us about XXX and YYY for excess routes
  > (AS200). I think XXX= 10 and YYY= 11.

Which is not necessary.

  > Also note that in this example local preferences contradict the global
  > preferences. 

The way this is defined they cannot.


Daniel



-------- Logged at  Thu Oct 13 18:00:59 MET 1994  ---------