pref syntax for RIPE-81++ (fwd)

Tony,

You raised two issues with the proposal:

a. where is the linkid (as you called, I more think of it a neighbor border 
router id) in interas-in/out  &
b. If multiple preferences type are listed, how to interpret them.

I will address a. now and leave b for tomorrow.

The linkid, it is still there.  We did not put in the definition (it is
in the example as you can see), because the syntax is not settled.  I recall
that there are at least two options on the table:

interas-in: <my brouterid> [from] ASxxx <neighbor's brouterid> .... or
interas-in: [from] ASxxx <my brouterid> <neighbor's brouterid>

Same applies to interas-out.

If my memory serves me, someone (jimi?) needs to pick one and get done with
it.  And as soon as it gets picked, we will just put it in the relevant part
of the text.

						--Jessica  
  

------- Forwarded Message

Return-Path: tony at ripe.net
Received: from ncc.ripe.net (ncc.ripe.net [192.87.45.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA08004; Wed, 13 Jul 1994 17:26:05 -0400
Received: from mature.ripe.net by ncc.ripe.net with SMTP
	id AA01660 (5.65a/NCC-2.3); Wed, 13 Jul 1994 23:25:57 +0200
Received: from localhost.ripe.net by mature.ripe.net with SMTP
	id AA06744 (5.65a/NCC-2.1); Wed, 13 Jul 1994 23:25:56 +0200
Message-Id: <9407132125.AA06744 at mature.ripe.net>
To: epg at merit.edu
Cc: rr-impl at ripe.net, jimi at dxcoms.cern.ch, farrache at ccpnxt5.in2p3.fr
Subject: Re: pref syntax for RIPE-81++ (fwd) 
In-Reply-To: Your message of Wed, 13 Jul 1994 16:56:00 EDT.
             <9407132056.AA01233 at pepper.merit.edu> 
From: Tony Bates <Tony.Bates at ripe.net>
X-Phone: +31 20 592 5064
Date: Wed, 13 Jul 1994 23:25:55 +0200
Sender: Tony.Bates at ripe.net


 epg at merit.edu writes:
  * 
Okay, initial thoughts is this looks good and in line with what we discussed
at Merit. However, somewhere we have lost the local linkid part which is
what the interas attributes are for. I think just an oversight ?. 
But if I assume this is added in like I think (?)
we agreed as just the two ends of the link (perhaps ? host addresses) then
I have just a couple of questions. If you could clarify this for me I think 
for me at least we could wrap this into ripe-81++.

			--Tony.


  * > -------------------
  * >  
  * > interas-in and interas-out preference definition
  * > 
  * > 1. interas-in
  * > 
  * > interas-in: [from] neighborAS preference [accept] route
  * > 
  * > where 'preference' here is defined as:
  * > 
  * > <pref-type>=<value> [,<pref-type>=<value>]
  * > 
Just so I usderstand this means we could have something like this. I use
addr<n> just as a psuedo representation for the linkid bit.

interas-in: from AS333 addr1 addr2 med-in=yes,pref=2 accept AS1104
interas-in: from AS333 addr1 addr3 med-in=yes,pref=1 accept AS1104

Presumably this is okay. No idea if the inbound AS can implement this 
but you could use this to show what you do in case of equal med metrics
from both links. Or is the intention only to allow one or the other, although
the definition doesn't seem to show this.

  * > <pref-type> has the following:
  * > 
  * > 	pref: 	the pre-configured preference for incoming routes same as 
  * > 		defined in as-in attribute.  It's value is numeric number.
  * > 		The lower the value, the higher preference.
  * > 
  * > 	med-in:	the usage of Multi_Exit_Discriminator metric from its 
  * > 		neighbor's routing advertisement.  The value is yes or no.
  * > 		Omission of the entry implies no usage of  MED from its
  * > 		neighbor AS.
  * > 
  * > 2. interas-out
  * > 
  * > 	interas-out: [TO] neighborAS preference [ANNOUNCE] route  
Slight correction     ^^                         ^^^^^^^^
                      to                         announce
  * > 
  * > where 'preference' is defined as:
  * > 
  * > <pref-type>=<value> [,<pref-type>=<value>] 
  * > 
  * > <pref-type> has the following: 
  * > 
  * >         pref:   the pre-configured preference for outgoing routes same as
  *  
  * > 		defined in interas-in attribute.  It's value is numeric 
  * >                 number.  The lower the value, the higher preference. 
  * > 
  * >         med-out: the value of Multi_Exit_Discriminator metric to advertis
  * e 
  * > 		routes to neighborAS.  If IGP metric is used to convert to 
  * > 		MED, the value is 'IGP'.  Otherwise, the value is a numeric
  * > 		number.  Omission of the entry implies no usage of MED when
  * >                 advertising routes to its neighbor AS.
  * > 
  * > 3. Examples:
  * > 
  * > aut-num: AS237
  * > interas-out: to AS690 <enss128> med-out=IGP announce AS237
  * > interas-out: to AS690 <enss145> med-out=IGP announce AS237
  * > 
I sort of assume the enss bit is the link stuff ?

  * > aut-num: AS266 
  * > interas-out: to AS690 <enss131> pref=1 announce {35/8, 128.14/16}
  * > interas-out: to AS690 <enss129> pref=2 announce {35/8, 128.14/16}  
  * > 
Only question here is - is this not just as MED - can it be anything else ?

  * > aut-num: AS701
  * > 
  * > interas-out: to AS690 <enss134> med-out=2 announce {15/8,192.35.1/24}
  * > interas-out: to AS690 <enss145> med-out=4 announce {15/8,192.35.1/24, 193
  * .1.1/24}
  * > 
  * > aut-num: AS690
  * > interas-in: from AS237 med-in=yes accept AS237
  * > 
  * > interas-in: <enss131> from AS266 pref=1 accept {35/8, 128.146/16}
  * > interas-in: <enss129> from AS266 pref=2 accept {35/8, 128.146/16}
  * > 
  * > interas-in: from AS701 med-in=yes accept ANY 
  * > 
  * > 4. Expansion
  * > 
  * > The preference field by this design could be easily expanded in the futur
  * e
  * > when other metrics be used for policy decisions without changes to the al
  * ready
  * > defined ones.  For example, when tos/qos is widely used, one could just a
  * dd
  * > another field in the pref-type: tos=value.
  * > 

------- End of Forwarded Message




-------- Logged at  Thu Jul 14 00:27:40 MET DST 1994  ---------