Re: Addr: Re: BGP-4 - revised I-D

["John G. Scudder" <[e-mail]>]

Allow me to suggest that we have consensus regarding MED, and that said
consensus is (a) that it's useful and (b) should only be comparable between
like ASes.

Let me further suggest that this is already what RFC 1771 specifies, as
does draft-ietf-idr-bgp4-03.txt, but that the text in question is so vague
as to allow, nay, encourage differing interpretations.  Here it is:

5.1.4   MULTI_EXIT_DISC


   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric.  All other factors
   being equal, the exit or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute may be propagated over internal links to other BGP speakers
   within the same AS.  The MULTI_EXIT_DISC attribute is never
   propagated to other BGP speakers in neighboring AS's.


This could be fixed by adding something like the following:

"MULTI_EXIT_DISC must not be considered when comparing routes received from
different neighboring ASes."

and I further think that at least one of the following is needed too:

a. "It must be possible to disable the consideration of MULTI_EXIT_DISC
when evaluating routes."

b. "It must be possible to remove the MULTI_EXIT_DISC attribute when it is
received from a neighboring AS.  This removal should be done prior to
propagating the route or determining its preference."

c. "It must be possible to enable the consideration of MULTI_EXIT_DISC when
evaluating routes."

Either (a) or (b) would allow interoperability between differing
implementations.  I like (b) better, because removing the attribute
entirely seems safer than having to twist a knob that says "ignore this
attribute" (and make sure you've twisted it into the same position on all
your routers).

(c) doesn't help with the transition case, but if (a) or (b) isn't chosen,
(c) had better be, otherwise the 5.1.4 text leaves it up to the discretion
of the implementor whether or not to implement MED at all ("...*may* be
used...").  (I hope everyone understands by now that IBGP interoperability
demands that it be possible to coerce all IBGP speakers to use the same
process for route selection.)

9.1.2.1.a should also be changed from:

      a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
      MULTI_EXIT_DIST.

to something like:

      a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute but were received from the same
      neighboring AS, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
      MULTI_EXIT_DISC.


I don't know if folks think it is also necessary to specify an algorithm to
do this, e.g. the election Rich has written about.  I tend to think of this
as an implementation detail, but if people are complaining that MED is too
hard to implement, I guess an existence proof to the contrary might be
useful.  Perhaps as an appendix?

Maybe we can hum or rub our navels or something, adopt this text or
similar, and then anyone who wants to discuss GAMs or the like can do so
secure in the knowledge that MEDs work the way they ought.

--John

--
John Scudder                        email:  [e-mail]
Internet Engineering Group, LLC     phone:  [phone]
122 S. Main, Suite 280              fax:    [phone]
Ann Arbor, MI  41804                www:    http://www.ieng.com