Re: BGP-4 changes

[Rich Woundy <[e-mail]>]

 (Hi folks, I'm finally back)

 Yakov,
 I have some comments about your proposed text.

 >To: [e-mail]
 >Subject: BGP-4 changes
 >Date: Thu, 29 Aug 96 08:03:22 PDT
 >From: Yakov Rekhter <[e-mail]>

 >Folks,

 >Let me propose that we'll make the following changes to the
 >spec:

 >1. Add to 5.1.4 the following:

 >  MULTI_EXIT_DISC shall not be considered when comparing routes received from
 >  different neighboring ASs.

 I agree with your intent, but this is too easy to misinterpret.  For
 example, suppose a router has three routes for a prefix, with the same
 local preference: one from AS X w/MED 5, one from AS X w/MED 10, and one
 from AS Y w/MED 15.  I think the consensus is that the router should not
 compare the MED values 5 and 10 from AS X with the MED value 15 from
 AS Y.  On the other hand, we should also make it clear that as part of
 MED comparison, the route from AS Y w/MED 15 should be preferred over
 the route from AS X w/MED 10 -- otherwise, you can get routing loops.

 How about the following text?

  MULTI_EXIT_DISC values of routes received from different neighboring
  ASs shall not be directly compared.  However, to ensure consistent
  route selection, the ranking of MULTI_EXIT_DISC values of routes
  must be compared, where the MULTI_EXIT_DISC ranking is computed over
  all routes for the same IP prefix from the same neighbor AS.

  In particular, a route with the best MULTI_EXIT_DISC value from its
  neighbor AS must be preferred over a route with an inferior
  MULTI_EXIT_DISC value from its (possibly different) neighbor AS.
  If two routes have the best MULTI_EXIT_DISC values from their
  respective neighboring ASs, they must be considered equivalent with
  respect to MULTI_EXIT_DISC comparisons.

  In the ranking computation, the lower MULTI_EXIT_DISC values are
  preferred, and a route without the MULTI_EXIT_DISC attribute
  shall be treated as equivalent to a route with the highest
  possible MULTI_EXIT_DISC value.

 >  When a route with the MULTI_EXIT_DISC attribute is received over an
 >  external link it must be possible (based on local configuration) to
 >  remove or override the value of the attribute. This shall be done
 >  prior to determining the degree of preference of the route.

 I agree totally with this text.

 >2. Replace 9.1.2.1 clause (a) with the following:

 >     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.

 Can we assume that the local system must take into account MEDs?
 I think the answer is yes.  The new text you propose back in 5.1.4
 explicitly permits the removal or override of MEDs.  If an
 ISP wants to ignore MEDs in the route selection process, it is
 safer to remove MEDs from all routes at the borders (as is
 commonly done today), than to set a configuration option on all
 routers in the AS to change the route selection algorithm.

 How about the following text (which also refers to ranking)?

  a) If the candidate routes differ in their MULTI_EXIT_DISC
  attribute, select the route(s) that have the best MULTI_EXIT_DISC
  values from their respective neighboring ASs.  The ranking of
  MULTI_EXIT_DISC values per neighboring AS is described in 5.1.4.

 >Comments ?

 Yes, one more comment.  Notice how I put the missing MED case
 in the ranking discussion, not in the tie-breaking discussion.
 To see the subtle point I am making here, consider two routes
 from AS X w/MED 10 and from AS Y w/no MED.  I don't think we
 should penalize the route from AS Y; after all, does any provider have
 a problem with a peer provider that *encourages* shortest exit???
 (There may be other legitimate reasons why MEDs are not sent.)
 If we compare routes from AS X w/MED 10 and from AS X w/no MED,
 *then* we should discourage use of the missing MED route.
 The first comparison is a tie-breaking consideration, and the
 second comparison is a ranking consideration.

 >Yakov.

 -- Richard Woundy, IBM