Hi Dirk: Thanks a bunch for your comments.
For the (PIM-like) upward bi-casting operation we do untangle the paths, and that is probably worth the pain since we are paving the way for high volumes back. For downwards traffic, we use the natural redundancy from the ARCs to solve the Single Point(s) of Failure. I'm interested in improving the Right / left selection on each ARC to reduce the chances of collisions, but not to add too much complexity in the process. The proposed algorithm is a simple inheritance, and does not require any global knowledge, so it can work in a DV type operation. I'm unclear whether such simple computation can really untangle links easily. With a full db, maybe, but is it worth the effort. Now, I would challenge the need to perfectly untangle end to end. We have inherited the idea that we need completely non-congruent paths to get redundancy. This is probably doubly a mistake: IOH, one gets more than he bargained for, since the non-congruent path allow redundancy even if all the nodes on a same path break, though the first breakage on that path already condemns that path. What's the point? OTOH, the real life cases of multiple breakages like Shared Risk Link Groups are not nicely aligned along a single path so the full separation of the 2 path does not provide additional guarantees. ARCs do not pay the price of determining non-congruent paths to the destination. ARCs only find non-congruent paths to 2 close Safe Nodes which are, in many occasions, neighbors. From this results an economy of computation and the capability to resist multiple apparently unrelated breakages on the way. So there are not just 2 paths but a combinatory explosion of possible paths. Bi-casting provides an additional chance, on a different plane, and may improves the control of latency and jitter. Cheers, Pascal -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dirk Sent: vendredi 19 octobre 2012 10:27 To: [email protected] Subject: Re: draft-thubert-rtgwg-arc-bicast-00.txt Pascal, isn't it possible to untangle the paths? I remember from my early days of CAD that there are numerous techniques to avoid copper clads being crossed on PCBs. I think we should incorporate some of that algorithmics in here. The price to pay is that you move away from the shortest path, but not very far. It looks like the closer we are to Omega the higher the probability of crossing paths, but also the shorter the paths are (except for pathological link costs, which is a meaningless hypothesis in modern optical networks) There is a second aspect I would like to explore. How can we use this signalling to calculate load balancing for normal ARCnets? 2 more RFPs to finish TGIF Dirk On 11/10/2012 16:46 , Pascal Thubert (pthubert) wrote: > Hi: > > This is an example application of ARCs (draft-thubert-rtgwg-arc), in this > particular case to bicasting. > Hopefully a 01 will soon details the applicability in multicast environments. > > Cheers, > > Pascal > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: jeudi 11 octobre 2012 16:43 > To: Pascal Thubert (pthubert) > Cc: [email protected] > Subject: New Version Notification for > draft-thubert-rtgwg-arc-bicast-00.txt > > > A new version of I-D, draft-thubert-rtgwg-arc-bicast-00.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. > > Filename: draft-thubert-rtgwg-arc-bicast > Revision: 00 > Title: Applying Available Routing Constructs to bicasting > Creation date: 2012-10-11 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-thubert-rtgwg-arc-bicast-00.txt > Status: > http://datatracker.ietf.org/doc/draft-thubert-rtgwg-arc-bicast > Htmlized: http://tools.ietf.org/html/draft-thubert-rtgwg-arc-bicast-00 > > > Abstract: > This draft introduces methods that leverage the concept of ARC to > enable bicasting operations. > > > > > > > The IETF Secretariat > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
