pref syntax for RIPE-81++ (fwd)
Tony Bates
Wed Jul 13 23:25:55 CEST 1994
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. * > -------- Logged at Wed Jul 13 23:40:15 MET DST 1994 ---------
[ rr-impl Archive ]