Hi, unsurprisingly I agree with Gábor (since we discussed this today), but I'd like to add that I do find the proposal interesting and timely.
If ARC, as we interpreted it, really is a specific combination of an MRT algorithm and a detour endpoint selection method, both of which are work in progress, then maybe ARC should be merged into the MRT algorithm draft on the long run. Then the WG should perform a careful analysis to decide which alg to mandate. András Sent from my mobile Gábor Sándor Enyedi <[email protected]> ezt írta: Hi Pascal, I think Alia was wrong, and ARC is extremely close to MRT. Unfortunately, I can't be completely sure, since I only read about ARC today, but I think that the phrase "ARC" is what MRT calls "ear". To be more precise, ARCs seems to be special ears, which must meet with some extra requirement, namely that you can get a shortest path along a well defined order of the ears. Could you please read through the MRT draft and help me to find the fundamental difference between the concept of ear and ARC? Gabor PS: No doubt, there is some difference between the two techniques, since packets leave the detour when it leaves an ARC/ear (if I understood that correctly). However, this behavior can easily be reproduced with MRT, if we pop the packets from the detour not at the destination/egress router, but at the endpoint of the ear. Actually this is a special case of what we call "endpoint selection" (and currently working on); MRT detours do not need to end at the destination, but packets can be put back to the shortest path at several other nodes (e.g. at a node closer to the destination), so that is worth to compute a good endpoint... one such endpoint can be the end of the ear, if the ears are selected as you do. Currently with MRT we are working on 1. what should be the specific algorithm to calculate MRTs 2. what should be the endpoint of the detours ARC seems to me as a specific combination of 1+2. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: [email protected] Subject: FW: draft-thubert-rtgwg-arc [resending due to excess size ] Dear Routing area; About http://www.ietf.org/id/draft-thubert-rtgwg-arc-00.txt The ARC technology derives from some internal research at cisco, and following that line of thought, we found a number of interesting properties that we want to share with you. Some of you already know about ARCs. This is not yet another FRR solution, but rather another way of looking at a routing topology and forwarding. Instead of following the arrows along a path, a packet will cascade from arc to arc, each arc providing at least 2 edges that the packet can use to progress. Certainly, ARCs can be used for fast reroute, but there are tons of other applications. This particular draft mainly presents the concepts, and will defrer to more drafts to specify actual solutions for the specific problems that we want to address with ARCs. We have begun recently to open the technology for particular applications, in particular at ISA100 and IEC SC65C in the context of industrial wireless networking. Those networks require multiple forwarding solutions for each node and a packet may hit multiple transient failures along its way over a multihop wireless mesh. Industrial WSN is thus a practical use case for which simple DAGS cannot apply and where even the MRT approach is not sufficient. As you go through the draft, you'll find that an ARC topology is made of multiple ARCs and that each ARC allows at least one breakage with the FRR low packet loss. You'll find that an ARC topology can be made to follow the SPF path in normal operation and yet provide an alternate for all nodes in a biconnected graph. You'll find that monoconnected zones are easily isolated and that the proposed computation can recurse there to obtain a maximal redundancy. An ARC topology can be exploited in classical routing or in MPLS. The recovery can be data plane or control plane which provides additional capabilities. Because ARCs are (at least) dual ended, an ARC topology also enables load balancing and a recursive overflow management to take the traffic away from the pain points. There's probably a lot more, but we'll have to discover that together. About IPR: Stewart recommended that I talk to Alia (and effectively Joel) in Taipei to make sure that the IPR cisco has on ARC is not on the way of MRT, and we concluded that these were effectively 2 different technologies. So cisco did not claim IPR regarding MRT but we certainly have IPR on ARCs. We'll post ASAP on that. Please let us know if this approach triggers interest. We wish to discuss ARCs during the RTGWG meeting in Atlanta and will be asking for a slot from the chairs. Cheers, Pascal _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
