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

["Manav Bhatia" <[e-mail]>]

> 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 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. The use of arbitrary path IDs can
influence the amount of memory required to hold the routes on both the
routers. 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.

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]

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

>In general I think your draft may work well for IPv4/v6 unicast address
>family. I don't think that it works well for any other address families
>already proposed in this WG.

I have already replied as to how this proposal would work for VPNv4 routes,
and other AFI, SAFI routes. Let me know if there is any ambiguity there.

Cheers,
Manav

[1] The last paragraph in section 3 from
draft-walton-bgp-route-oscillation-stop-01.txt




_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr