Re: bgp4-17 5.1.3 NEXT_HOP attribute determination

[Yakov Rekhter <[e-mail]>]

Alex,

> Tom,
> 
> > I think that there is a problem with logic and terminology
> > in the determination of NEXT_HOP.  There are four cases
> > listed,
> > - a form of "third party" NEXT_HOP attribute
> > - a second form of "third party" NEXT_HOP attribute
> > - "first party" NEXT_HOP attribute
> > - by default
> > and respectively the BGP speaker
> > - can use
> > - can use
> > - may use
> > - should use
> > which seems inconsistent; I would prefer SHOULD.
> 
> Since use of third party next hops is an optimization
> by nature and does not *have* to be implemented,
> and given that "should" is used for the default,
> I think "may/can" is ok. If we change the optional
> cases to "should" to increase the level on insistence,
> we should do the same to the default case and make
> it a must.
> If you ask me, I think we're all right now.
> 
> 
> > But logically, the first party (common subnet) overlaps the
> > two third parties (common subnet with IBGP or locally
> > originated and common subnet with EBGP) which obviates
> > SHOULD.
> 
> We know how to deal with overlapping cases already---
> the more specific one wins. Same here---third party
> cases are more specific in their description.
> I guess it might be clearer if we changed "-if -if"
> to "-if -otherwise if".

done.

Yakov.