[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Joel,

Elegance is very much in the eye of the beholder, which is why I'd rather not appeal to it in discussing these things, but rather stick to facts. What I like about the add-path approach is exactly that it doesn't impute any particular semantics to the path identifier. I think it's instructive that OSPF used to use the prefix as its database key and has finally moved away from that in OSPFv3.

I don't understand your apparent concern about how to choose the path identifier. Surely this is a problem that can be solved by any moderately skilled undergraduate.

--John

At 7:58 AM -0400 8/23/06, Joel M. Halpern wrote:
Enke, I have real trouble with your characterization of your draft.
You claim it is simple and elegant.
From where I sit, it introduces a new identifier that must be shared between the routers. That identifier has to be assigned and managed by the advertising router in such a way that it is unique for each path that needs advertised (under all possible circumstances). But it has to be used by the receiver no matter how the sender has chosen to allocate / create it. As such, if the two happen to have the same implementation view they may find it simple. But it is quite dependent upon that implementation.
While our draft makes use of information that was already being exchanged to provide the necessary disambiguation. I would argue that such is in fact both simpler and more elegant.

At the same time, your claim of greater flexibility is in fact not backed up by need. We previously had support for advertising paths with different attributes but the same NLRI and the same next-hop. In discussion with folks we realized that there was no actual use case where you need the differentiation. Either the advertiser is in the path (next-hop self) in which case preserving the paths does not add information, even for the route oscillation case, or the advertiser is preserving the next-hop information in which case the next hops provide the needed differentiation. Thus, using the next-hop as an added differentiator provides exactly the flexibility needed by the problem, and is much simpler, more amenable to variations in implementations strategies, and more robust.

Yours,
Joel M. Halpern

...

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