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

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

Paul,

At 10:12 PM +0100 8/23/06, Paul Jakma 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.
>
> The draft should perhaps say how.
>
> We are reasonably certain there are issues with all but simple 
> reflector cases - any case where one wishes multiple paths to be 
> /readvertised/ can not use identifiers derived from the identity of 
> from whom the route was learnt (e.g. router-ID). So the speaker is 
> left to construct some identifier specific to the peer the speaker 
> is sending the path to, for that path.
>
> Which seems redundant to us as such an identifier already exists in 
> all the BGP AFI/SAFIs we have considered -> the nexthop.

It's been quite a while since we wrote that draft so I'm having to 
refresh my memory, but we did consider the concerns you describe 
while writing it.  Some responses:

As to "say how" -- we specifically wanted to avoid prescribing how to 
derive the path identifier, since what's the point of a 
semantics-free identifier if the specification goes and forces a 
particular algorithm on you?  As I said in my note to Joel, I just 
don't see this as a very difficult problem.  Do you?

As to the re-advertisement case -- yes, the path identifier has to be 
reconstructed.  Again, this seems to me a simple problem.

As to redundancy -- if you can make the case convincingly that there 
is never, under any circumstance, a case where one might want to 
advertise more than a single route with a given next hop, then I 
think you have a strong argument.  I'm not convinced of this premise 
yet, however.  (See previous message with example involving 
confederations, for one.)

If indeed there is ever a case where you want to advertise two routes 
with the same next hop, then the path identifier is not redundant.

Regards,

--John

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