Subject: Re: Removing MED (New Issue 1.0)

From: Enke Chen <[email-masked]>
Date: Tue, 01 Oct 2002 11:05:10 -0700

Steve,

> From: "Stephen Gill" <[email-masked]>
> To: "'Enke Chen'" <[email-masked]>,
> 	"'Natale, Jonathan'" <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: Removing MED (New Issue 1.0) 
> Date: Tue, 1 Oct 2002 13:01:04 -0500
> 
> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

-- Enke

>  Cisco treats a missing med as 0, and I think Juniper
> treats it as worst.  Cisco has a knob to change this: bgp bestpath
> missing-as-worst.  
> 
> -- steve
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Enke
> Chen
> Sent: Tuesday, October 01, 2002 12:58 PM
> To: Natale, Jonathan
> Cc: [email-masked]; [email-masked]
> Subject: Re: Removing MED (New Issue 1.0) 
> 
> Jonathan:
> As the MED value is treated as zero when the MED attribute is missing,
> removing the MED attribute is really equivalent to setting the value to
> zero. Based on this logic, one can argue that "MED removal" is supported
> by multiple vendors.
> 
> However, I do see that the current text can be consolidated and cleaned
> up:
> 
> ------------------------
> 5.1.4 MULTI_EXIT_DISC
> 
>    ...
> 
>    A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
>    which allows the MULTI_EXIT_DISC attribute to be removed from a
>    route. This MAY be done prior to 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 shall do so prior to determining the degree
>    of preference of the route and performing route selection (decision
>    process phases 1 and 2).
> 
> -------------------------
> 
> How about this:
> 
>    A BGP speaker MUST implement a mechanism based on local configuration
>    which allows the value of MULTI_EXIT_DISC attribute of a received
> route
>    to be altered. This shall be done prior to determining the degree of
>    preference of the route and performing route selection (decision
> process
>    phases 1 and 2).
> 
> --------------------------
> 
> -- Enke
> 
> > Message-ID:
> <[email-masked]
> om>
> > From: "Natale, Jonathan" <[email-masked]>
> > To: [email-masked]
> > Subject: Removing MED (New Issue 1.0)
> > Date: Tue, 1 Oct 2002 13:23:16 -0400 
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Content-Type: text/plain
> > Sender: [email-masked]
> > Precedence: bulk
> > 
> > In reference to:
> > 
> > "A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
> >  which allows the MULTI_EXIT_DISC attribute to be removed from a
> >  route"
> > 
> >  Does anybody know how this can be done in IOS???  Looks like it
> cannot.
> > 
> >  Juniper???
> > 
> >  Other code???
> > 
> >  Change to "SHOULD"???
>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 01 Oct 2002 22:12:02 -0400

> > treats it as worst.  Cisco has a knob to change this: bgp bestpath

If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
bahaviour if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out.  In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal.  The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).

Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again.  Unfortunately these implementation hints are necessary to
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).

Curtis