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

["Manav Bhatia" <manav at riverstonenet.com>]

I didn't see a reply on how add-path proposal aims to address an issue
raised by Paul below? This illustrates the general concern that we have with
arbitrarily picking up a path ID. I think it has been disambiguated that the
Router ID will not work as a Path Id and an implementation needs to pick up
its own unique numbers ..
 
>The problem, and Joel's point (I think), is that in not giving any 
>guidance on how this identifier is to be picked, implementations will 
>settle on picking this identifier in a deficient way. E.g. 
>particularly as the draft suggests that router-ID is one possible 
>choice of such identifier (and indeed you suggest same the below).
>
>Such a choice would not work for re-advertising multiple paths, e.g. 
>a cluster of route-reflectors:
>
> 	RR1-RR2
>        / |   |
>       A  B   C
>
>Say A, B and C all advertise a certain NLRI, P.
>
>RR1 and RR2 use add-path with their clients and between themselves so 
>as to allow all paths to be distributed to all RR-clients. Both the 
>RR implementations go for the simple approach (as suggested in the 
>draft and your email) of using the router-ID of the speaker a path 
>was received from as the Add-Path-ID. So RR1 sends to RR2:
>
> 	UPDATE: feasible P:A, <attributes>
> 	UPDATE: feasible P:B, <attributes>
>
>Where X:Y is: add-path NLRI for Prefix X and add-path-id of Y.
>
>Now, how should RR2 advertise these to its clients?
>
>It clearly can not blindly just use the Router-ID of the speaker it 
>received the paths from (RR1 in both cases).
>
>It could however just reuse the path-ids. So the RR's add-path 
>implementation now becomes (wrt choosing Add-Path-ID):
>
> 	"If the received path already has a path-ID, and no other
>          received paths have the same, just re-use that path-id.
>
>          Otherwise, use the Router-ID of speaker the path was
>          received from"
>
>So now RR2 /can/ easily advertise the two paths received from RR1 to 
>C and D.
>
>However, our friendly BGP network administrator now figures out he 
>really ought to have clients peer with both RRs, he does so for B 
>(e.g. A and C's sessions to other RR may be broken for some reason):
>
> 	RR1-RR2
>        /  |/ |
>       A   B  C
>
>
>RR2 now has recieved:
>
>>From RR1:
>
> 	P:A
> 	P:B
>
>>From B:
>
> 	P
>
>What should it advertise to C?
>
>The choices seem to be:
>
>- Figure out that P and P:B are the exact same path (e.g. they'll
>   have the exact same next-hop..), and advertise just P:B to C.
>
>   - remember, that RR1 used 'B' as the path-ID is wholly at the
>     discretion of RR1
>
>   - the nexthop however...
>
>or
>
>- Advertise both P:B and P:B' to C
>
>   - where B' is some constructed identifier for the path
>     for P received from B
>
>It seems to us that behaviour of the add-path draft with RR clusters 
>may be quite indeterminable, given that the issue of the additional 
>path-identifier is left completely at the discretion of speakers.
>
>One could say "Ah, but ORIGINATOR_ID can be used!", but that's a 
>route-reflection specific attribute. It won't work for other cases 
>that could make use of add-path, e.g. ECMP..
>
>Also, for ECMP, a lot of the details of whether not multiple-paths 
>should be advertised or else whether or not the AS_PATH must be 'ECMP 
>aggregated' revolve around next-hop.
>
>> the routes (simulating full-mesh).  It is actually the (prefix, 
>> router-id) that would identify a path instead of the prefix itself.
>
>And see above :)
>
>> As the issue of how to identify a path is so fundamental to 
>a solution,  I 
>> hope that it can be clarified before we dive into other details.
>
>Yep, fully agreed.
>
>And for any two paths to the same destination a speaker may have, the 
>next-hop(s) serve(s) as an identity, regardless of other attributes 
>of the paths.
>
>- if they are not to the same remote speaker, the paths obviously are
>   different (at least in that "plane" of routing)
>
>- if they are the same, the two paths are effectively the same,
>   regardless of the other attributes.
>
>We maintain so anyway and think it to be fundamental to routing.
>
>In which case, we might as well make use of this property, rather 
>than having speakers left to reinvent identifiers, which we think is 
>not quite as easy and problem-free in the general case as it is for 
>simple RR cases.
>


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