Re: BGP-4 changes

[Yakov Rekhter <[e-mail]>]

John,

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

Ok. I'll put "remove the attribute or override its value".
  
> 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.)

Ok. I'll include the above paragraph.

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

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

Ok.

Yakov.