Implementation of RIPE-181++

 cengiz at ISI.EDU (Cengiz Alaettinoglu) writes:
  * 
  * Tony Bates (Tony.Bates at ripe.net) on October  5:
  * > No - the text is clear - the pref is mapped to a relative value
  * > in...see the appendix for more details. I think this is enough. No
  * > hanging I hope ;-).
  * 
  * Please yank some text from the appendix. I still can not find this. 
  *
Well - I guess this is the bit you need...
....

          <preference> is defined as follows:

          (<pref-type>=<value>)

          It should be noted the parenthesis ``('' and ``)'' and the
          ``<pref-type>''  keyword  must be present for this prefer-
          ence to be valid.

          <pref-type> currently only supports "pref".  It  could  be
          expanded  to  other  type of preference such as TOS/QOS as
          routing technology matures.

          <value> can take one of the following values:

          <cost>
               <cost> is a positive integer used to express a  rela-
               tive  cost  of routes learned. The lower the cost the
               more preferred the route. This <cost> value  is  only
               comparable  to  other  interas-in  attributes, not to
               as-in attributes.

          MED
               This    indicates    the    AS    will    use     the
               MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented
               in BGP4 and IDRP, sent from its neighbor AS.

               NOTE:  Combinations  of  MED  and  <cost>  should  be
               avoided for the same destinations.

               CAVEAT: The pref-type values may well be enhanced  in
               the future as more inter-ASs routing protocols intro-
               duce other metrics.

               Any route specified in interas-in and  not  specified
               in  as-in  is  assumed  not accepted between the ASes
               concerned. Diagnostic tools should flag  this  incon-
               sistency  as an error.  It should be noted that if an
               interas-in policy is specified then it  is  mandatory
               to  specify  the  corresponding  global policy in the
               as-in line. Please note there is no relevance in  the
               cost  associated  with as-in and the preferences used
               in interas-in.
          <routing policy expression> is an expression as defined in
          as-in above.

...

While I see there are potentially some small outstanding
implementation issues here, I don't think this constitutes enough of a
problem to stop this being released a RIPE document today. We can
always pick this up in the extensions document which is currently just
a place-holder in many ways.

		--Tony.




-------- Logged at  Thu Oct 6 17:56:29 MET 1994  ---------