[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 2:22 PM +0530 8/24/06, Manav Bhatia wrote: 
Enke,

multi-paths.  How do (X, N1) and (X, N2) got withdrawn on RR2 as they
are no longer valid (replaced by B1 and B2), in other words
how does RR2
figure out (X, N11) is a replacement of (X, N1), and (X, N22) a
replacement of (X, N2)?


UPDATE: unfeasible nlri X, multiple_hop N1
UPDATE: unfeasible nlri X, multiple_hop N2
UPDATE: feasible nlri X, multiple_hop N11, <other attributes>
UPDATE: feasible nlri X, multiple_hop N12, <other attributes>

I think we can each come up with a scenario where one scheme would be more
optimal and would involve lesser number of UPDATEs than the other.

Sure. In terms of implementation overhead, I don't think you've addressed Enke's original point though, which was that the full sequence on the RR is:

- Receive X, N1 from client
- Advertise X, N1 to peer RR
- Receive X, N11 from client
==> at this point a conventional implementation might simply free the
    memory used to store N1 and somehow queue the replacement,
    X, N11 for advertisement.  However, a multiple-hop implementation
    would have to retain N1 (marked as deleted or the like) until all
    peers had been updated -- since N1 is used as part of the key in
    the withdrawal.
- Followed by updates as you've noted above

The point here isn't that this is necessarily a show-stopper. However, I think it does demonstrate that until one carefully considers the implications in a real implementation, it's dangerous to make sweeping statements about how one proposal is simpler than other.

--John

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