Re: BGP-4 changes

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

Rich,

Now that you bring it up, I am having a somewhat hard time thinking of
*any* good reason to alter an existing MED.

However, supposing one were to do so, would this text for 5.1.4 fix the
problem?

  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 the attribute.  This may be done either prior to or after
  determining the degree of preference of the route and performing
  route selection (decision process phases 1 and 2).

  An implementation may also (based on local configuration) alter the
  value of the MULTI_EXIT_DISC attribute received over an external link.
  If it does so, it MUST do so prior to determining the degree of
  preference of the route and performing route selection (decision
  process phases 1 and 2).

Note that I also added "and performing route selection."  This used to just
say "determining the degree of preference" which strictly speaking is in
phase 1 and therefore left the actual MED comparison part unspecified,
since it's in phase 2.

--John

---
At 6:34 PM -0400 9/3/96, [e-mail] wrote:
>*** Resending note of 08/31/96 15:15
>Subject: Re: BGP-4 changes
>John,
>
>I now have second thoughts about changing the MED value; stripping the
>attribute is of course still OK.  The problem is not route loops,
>but non-deterministic routing (i.e. not predictable).
>
>>As far as I'm concerned, being able to strip the attribute at the border
>>achieves this goal fine.  Either or both is OK with me.
>
>>In private email Curtis mentioned a case (which in retrospect I should have
>>seen) where we should be able to strip MED after route selection but before
>>export into IBGP.  The case applies when I have a router facing two
>>neighbors across a DMZ.  I want to consider the MED to get the next hop
>>"right" across the DMZ, but I want to use shortest-path inside my AS.  I
>>believe that this stays loop-free since we only consider MED once we
>>have already decided to choose an external route.
>
>Let's assume that a router considers the original EBGP MED in the
>route selection process, but sends the modified MED in the
>IBGP export.  Further assume a provider modifies the MED to value
>0 at two border gateways (A & B), in order to try to draw traffic to
>the nearest of these two exits.
>
>Suppose border A gets an external BGP route with MED X first.  With no
>competition from B, border A installs the route and exports into IBGP
>with MED 0.  Border B will see this same route only with MED 0.
>
>Later, border B receives its route with MED Y (same prefix, same
>neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
>is), then border B will reject the external in favor of the internal
>route from A.
>
>Note that acceptance of the internal route from A over the external
>route of B is based totally on timing issues -- first come, first
>served.  It only occurs when the MED value is decreased -- that's why
>stripping the MED is OK, since missing MEDs have value -1.
>
>To fix this, one might use the modified MED value for both route
>selection and IBGP export, but one throws away useful information
>as Curtis and John mention above (for optimizing local external
>route selection).
>
>Do we need the ability to change the MED attribute value, or is
>it sufficient to be able to remove the MED attribute?  Can we get
>away with modifying local preference instead of changing the MED
>value?
>
>-- Richard Woundy, IBM


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