pref syntax for RIPE-81++ (fwd)
Tony Bates
Thu Jul 14 00:27:31 CEST 1994
Jessica Yu <jyy at merit.edu> writes: * Tony, * * I will address a. now and leave b for tomorrow. * Okay ;-) * 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 recal * l * 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> Okay, I definately favour this one (above) as it is consistent with the more general as-in/out lines * Same applies to interas-out. * Sure. * 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 par * t * of the text. * That's right - it is down to Jimi if we are deadlocked. Are we ? * --Jessica * --Tony. * * ------- 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 discusse * d * 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, althou * gh * 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 numb * er. * * > 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 sam * e 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 adve * rtis * * e * * > routes to neighborAS. If IGP metric is used to convert * to * * > MED, the value is 'IGP'. Otherwise, the value is a num * eric * * > 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 f * utur * * e * * > when other metrics be used for policy decisions without changes to th * e al * * ready * * > defined ones. For example, when tos/qos is widely used, one could ju * st a * * dd * * > another field in the pref-type: tos=value. * * > * * ------- End of Forwarded Message * -------- Logged at Thu Jul 14 23:33:25 MET DST 1994 ---------
[ rr-impl Archive ]