Subject: [Roll] ROLL WG Agenda IETF85

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sat, 6 Oct 2012 09:37:02 +0000

Dear all,

The ROLL WG will meet in Atlanta. Please let us not later than Oct 17 if you would like to request a "presentation" slot ?

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Oct 2012 09:43:30 +0000

Dear chairs,

I introduced the concept of ARCs to the routing area WG (see  attached).
I think it would be a good idea to present to the group how ARCs can be used to implement a generalized sibling in RPL. 
I'd probably need 15 minutes at least since the concept will be new to many...

What do you think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: samedi 6 octobre 2012 11:37
To: roll WG
Subject: [Roll] ROLL WG Agenda IETF85

Dear all,

Thanks.

JP.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

Subject: resending: draft-thubert-rtgwg-arc
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 2 Oct 2012 16:38:45 +0000

Dear Routing area;

I tried to post this but apparently the message was too big due to included pictures. Retrying

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.

ROOTABWe 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

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: mardi 2 octobre 2012 09:59
To: Pascal Thubert (pthubert)
Subject: Confirmation for Auto-Post of I-D draft-thubert-rtgwg-arc

Hi,

The IETF datatracker draft submission service has received your draft draft-thubert-rtgwg-arc-00, and requires a confirmation step in order to be able to complete the posting of the draft.

Please follow this link to the page where you can confirm the posting:

Confirmation URL: http://datatracker.ietf.org/submit/status/44821/confirm/2f2a6b0c984150e6a53a0c734f5ab0411c68c288/

Best regards,

                The IETF Secretariat

                through the draft submission service