Re: BGP-4 changes

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

At 2:01 PM -0400 8/30/96, Curtis Villamizar wrote:
>In message <[e-mail]>om>, Yakov Rekhter writes:
>>   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.
>
>This is fine.  It actually makes sense to be able to add an offset if
>MED is being used to load balance the other AS but some control over
>load in the local AS is also desirable.  I would put that in the spec
>as a protocol requirement though.

I don't follow the last sentence (about "protocol requirement") but I'm not
too worked up about it.

I still prefer the wording "must be possible (based on local configuration)
to remove the attribute or override its value".  The way Yakov has it can
be parsed at least two ways, one of which makes no sense.  (It depends on
if you associate "remove" with "value" or "attribute".)

>In private mail John mentioned he wanted to be able to disable MED to
>accomodate existing implementations that do the selection differently.
>It might actually be worth mentioning this.

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.

Discussion of interoperation with existing (wrong) implementations would be
good for an appendix (perhaps Appendix 6.9 which I mention below but don't
volunteer to write :-).

...
>You forgot the statement that any algorithm that produces an
>equivalent result is acceptable.  You might mention that this
>particular algorithm is inefficient.

I agree.  Here is some proposed text [which presumes that Curtis or someone
is going to write Appendix 6, section 6.9 -- if no one does, then remove
the parenthetical sentence].

Insert between prefatory text and item (a):

    Several of the criteria are described using pseudo-code.  Note that
    the pseudo-code shown was chosen for clarity, not efficiency.  It
    is not intended to specify any particular implementation.  BGP
    implementations may use any algorithm which produces the same
    results as those described here.  (See Appendix 6, section 6.9 for
    a description of a more efficient algorithm for MULTI_EXIT_DISC
    treatment.)

>Regardless of what description is used, I'd like to see a description
>of the loop problems and the reasons for some of these rules in the
>selection process, to prevent someone from mistakenly thinks that
>comparing the current best route to the new route is an equivalent
>algorithm.  Would you prefer this in the route selection section, in
>an appendix, or a separate informational RFC.

IMO this would be good to add to the now-famous Appendix 6.9, possibly with
a forward reference from 9.1.2.1.  A discussion of a more efficient MED
implementation would fit in too.

BTW while I'm talking about Appendix 6, 6.2 has a "shall" in it.  This is
inappropriate for something called "Implementation *Recommendations*."  If
anyone thinks this is really a "shall" it should be moved out of the
appendix and into the spec proper.  Or, change the "shall" to "should."

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