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

[Enke Chen <[e-mail]>]

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

Depends on the application, a speaker may or may not be able to use the 
same path identifier it has received. What exactly is the problem of 
constructing an identifier?

>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? 
>  
>

Router-ids are unique only with an AS. Since you did not specify the 
application, the fact that Router A uses the router-id as the identifier 
seems to suggest that this is a route reflection case (full-mesh), and 
it is ibgp between A and B.

How does B announce these routes to D?   It depends on the application 
again. If D is an ibgp peer, B can use the same router-id.   If D is an 
ebgp peer and ebgp multipath is involved, B needs to assign an unique id.

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

It is all relative, and I am afraid that your description of "mucky, 
fragile, redundant, complex, prone to error" might be relevant in the 
current discussion.

-- Enke

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

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