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

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

At 11:20 AM +0530 8/24/06, Manav Bhatia wrote:
>  > PS. The stated issue with add-path's drawback to require uniqe
> >  identifier to be generated by BGP speaker is not IMHO at all a problem.
>
> It is really.
>
> The suggested scheme becomes mucky

I won't take that personally, but I do suggest that you may want to 
consider your choice of adjectives in the future.  Glass houses, 
stones, etc.

> and fragile when one has to readvertise
> the multiple paths that it has received, because it can then no longer use
> the Router ID to disambiguate the paths. The speaker is then left to
> construct some unique arbitrary identifier specific to the peer the speaker
> is sending the path to, for those paths.
>
> A
> |
> B   C
>  \  /
>   D
>
>
> Assume A sends two routes x1:10/8, x2:10/8, where x1 and x2 are the router
> IDs of the peers A received these routes from, to B.
>
> How does B announce these routes forward to D?
>
> It has to generate and manage unique path IDs which now, are neither based
> on router IDs nor derived from AS numbers, etc. Something that the draft
> conveniently prefers to skim over.

Actually, something that the draft deliberately chooses to remain 
silent on because we didn't care to over-specify.

I'm dumbfounded that so many people seem to believe that associating 
a unique identifier with a datum is a hard problem.  I guess if we 
resurrect add-path, we could add an appendix with a sample algorithm, 
or we can just provide a reference to a standard algorithms textbook.

> The use of arbitrary path IDs can
> influence the amount of memory required to hold the routes on both the
> routers.

Omelette, eggs, etc.  The additional overhead isn't very much 
(neighborhood of 8 bytes/route -- 4 for rx'd identifier, 4 for tx'd), 
but yes it does exist.

> If different path IDs are used, the amount of memory needed to
> store all the routes increases. You cannot simply ignore the path IDs that
> you send/receive as you need to store them for performing implicit/complete
> withdrawals.

Well, sure.  I'm not sure this is an interesting point of comparison 
though -- see follow up to Enke's message.

> The claim therefore that add-paths "requires only minor software changes for
> the vast majority of the BGP speakers in a network" is misleading and
> incorrect. [1]

Only speakers which wish to advertise multiple paths have to know how 
to generate unique path identifiers.  The rest just need to know how 
to consume them.  I guess it's in the eye of the beholder what 
constitutes "minor".  Or maybe it's "vast".  In any case, I'd rather 
debate specific merits rather than argue about whether it's 
misleading if vast is more elegant than minor.

> We believe that introducing a new arbitrary identifier is redundant, complex
> and prone to implementation quirks and can fail in interesting ways. We
> instead use the next_hop (which is already exchanged) as the "unique
> identifier".

Regarding redundancy (which is the only claim above which is 
substantive enough to debate at this point) see my previous message 
to Paul.

--John

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