Re: [Idr] Progressing draft-bhatia-bgp-multiple-next-hops-01.txt

["John G. Scudder" <jgs at cisco.com>]

At 10:22 AM +0100 8/31/06, Paul Jakma wrote:
> Hi Curtis,
>
> On Wed, 30 Aug 2006, Curtis Villamizar wrote:
>
> > You can't propose a protocol extension where routes cannot be 
> > distinguished when a legitimate example is given just because the 
> > example is in your opinion "something no one would want to do".
>
> It's not a consideration because the exit-peer can easily peer with 
> the RS in Enke's example.

That is incorrect.  As Enke pointed out (twice now) the AS path will 
be different depending on which peer advertises the route.  As Enke 
also pointed out, the two different AS paths may result in different 
filtering, localpref, etc, by the recipient.

If you want to deprecate third-party next hop, please raise it as a 
separate topic, but I don't think you can just pretend it's 
semantically identical to direct advertisement.

(By the way, if we're going to start deprecating our least favorite 
features of BGP, there are a few I'd like to add to the list. :-)

> 3-p-n generally is discouraged, it has reliability problems - it's 
> the poor man's substitute for direct peering (usually administrative 
> overhead of setting it up). Certainly at IXes we know of it is 
> generally discouraged.

N.b. neither Enke, Curtis nor I are entirely lacking in experience 
with IXes, network operations, etc.

> Its use tends to be primarily because of the /lack/ of eBGP RS solutions.
>
> We'd be interested in any plausible cases where a peer would /not/ 
> want to advertise the path to the RS, but would be happy for other 
> peers to advertise the path to the RS (and hence all RS-client 
> peers). We can't quite think of them.

Again, it's not an either-or.  As detailed above (and in several 
previous messages) since the semantics of the advertisements from the 
direct and third-party advertisers differ (in particular, different 
AS paths may reflect different business relationships) it's quite 
reasonable for both versions of the route to be of genuine use to 
various consumers of the routes.

If there were no way to support third-party next hop and still get 
multiple path support, then I'd be more sympathetic to the argument 
that it's a corner feature which regrettably has to be abandoned to 
enable progress.  But the fact is, it's entirely possible to continue 
to support it.

Also, the fact that one non-obvious casualty of using next hop as 
identifier has been identified leads me to be concerned that others, 
as yet unidentified, may also exist.  BGP is a surprisingly subtle 
protocol, and just because I can't quite think of another bad 
interaction doesn't mean there isn't one.  On the other hand, if one 
picks (or at least, retains the option to pick) an identifier which 
has no other semantics then the risk of such interactions is 
eliminated.

--John

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr