Re: bgp4-17 5.1.3 NEXT_HOP attribute determination

[Alex Zinin <[e-mail]>]

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

> And what does locally originated actually mean?

It means that the route was not received from another
BGP peer and was created by the guy we're talking about.

> Presumably IGP and static except that the subsequent use of
> internal router does not quite match that.

> I wonder if it would be clearer if the focus was on the
> common subnet rather than where the route came from.  Can eg
> the third party cases be combined as

> 'if the external peer X shares a common subnet with the
> immediate next hop that the BGP speaker itself has installed
> in its routing table for this route, then the speaker SHOULD
> use this immediate next hop in the NEXT_HOP attribute'

When I changed this text to what it is now, I tried to preserve
the spirit of the old one, and keep some "educational" info.
I think both ways are fine and functionally equivalent, it is
more a question of preference.
So, I guess my vote is to stet it :)

Alex.