From bashandy@cisco.com Mon Oct 1 07:51:01 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E0D1F0CF9 for ; Mon, 1 Oct 2012 07:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqnDPG1lIAAd for ; Mon, 1 Oct 2012 07:51:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9136F1F0CCD for ; Mon, 1 Oct 2012 07:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7866; q=dns/txt; s=iport; t=1349103060; x=1350312660; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=/ZId6Qp94kqffAqQhZWXMej1x2GwpVChvk1OCIpmRVI=; b=TfpgC1+A/DJFtw9gKl7wLt30l2XJJo4CVB5EGQ7tYp3Y7ga8uSLK/zki BV8Y7yKq7eRV71HXfjBtSXpjBy9WJvZzVw0fjiIVfKcFlqR1mVmuYYwgM vzXFacQMvrcIL9AOpd1XZ3NRZ/1U/JniwiQsL2g9qO2gWfYZrcL0x37lJ Q=; X-Files: signature.asc : 248 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="asc'?scan'208,217";a="127103802" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 01 Oct 2012 14:51:00 +0000 Received: from [10.82.233.208] (rtp-vpn5-463.cisco.com [10.82.233.208]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q91EovDY014314; Mon, 1 Oct 2012 14:50:58 GMT Message-ID: <5069ADD0.50900@cisco.com> Date: Mon, 01 Oct 2012 16:50:56 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: Fwd: I-D Action: draft-rtgwg-bgp-pic-00.txt References: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> In-Reply-To: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD0E71C04E5E9955DD08101BB" Cc: "Pradosh Mohapatra \(pmohapat\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:51:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD0E71C04E5E9955DD08101BB Content-Type: multipart/alternative; boundary="------------090604070602080308030506" This is a multi-part message in MIME format. --------------090604070602080308030506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design All comments and suggestions are most welcomed Thanks Ahmed -------- Original Message -------- Subject: I-D Action: draft-rtgwg-bgp-pic-00.txt Date: Mon, 1 Oct 2012 07:08:38 -0700 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : Abstract Author(s) : Ahmed Bashandy Clarence Filsfils Prodosh Mohapatra Filename : draft-rtgwg-bgp-pic-00.txt Pages : 19 Date : 2012-10-01 Abstract: In the network comprising thousands of iBGP peers exchanging millions of routes, many routes are reachable via more than one path. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed a technique by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding chains in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete transparency and automation, and zero management and provisioning effort The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rtgwg-bgp-pic There's also a htmlized version available at: http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090604070602080308030506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design

All comments and suggestions are most welcomed

Thanks

Ahmed



-------- Original Message --------
Sub= ject: I-D Action: draft-rtgwg-bgp-pic-00.txt
Dat= e: Mon, 1 Oct 2012 07:08:38 -0700
Fro= m: <internet-drafts@ietf.org>
Rep= ly-To: <internet-drafts@ietf.org>
To:= <i-d-announce@ietf.org> 


A New Internet-Draft is available from the on-line Internet-Dr=
afts directories.


	Title           : Abstract
	Author(s)       : Ahmed Bashandy
                          Clarence Filsfils
                          Prodosh Mohapatra
	Filename        : draft-rtgwg-bgp-pic-00.txt
	Pages           : 19
	Date            : 2012-10-01

Abstract:
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one path. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed a technique by which traffic
can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding chains in a
hierarchical manner and sharing forwarding elements among the maximum
possible number of routes. The proposed technique achieves prefix
independent convergence while ensuring incremental deployment,
complete transparency and automation, and zero management and
provisioning effort


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgwg-bgp-=
pic

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce<=
/a>
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--------------090604070602080308030506-- --------------enigD0E71C04E5E9955DD08101BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQaa3R+G19kFA5zIYRAi64AJ9DCUvyAY2gnhVwcdKlS66Fg6RYOACfVaZo WcSHNCfDxvYe5R9RZc4xfKE= =T/Fx -----END PGP SIGNATURE----- --------------enigD0E71C04E5E9955DD08101BB-- From bashandy@cisco.com Mon Oct 1 07:51:25 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7C1F0D02 for ; Mon, 1 Oct 2012 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMR6xYPymkg9 for ; Mon, 1 Oct 2012 07:51:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 728471F0CCD for ; Mon, 1 Oct 2012 07:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7866; q=dns/txt; s=iport; t=1349103082; x=1350312682; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1CI8QFwzlJpCwl5mu8FCEMNzIkWedvu8x0+Uahc9H00=; b=ACBJPMETgeoI+XiCI+gKJu85kGlingw8DAmYqOihEfvreZMwU4yKHEa3 oc638GFHhuYsG8/C6miaNexEHV9V8u72ODYKHir0avODsDnb12RDKcayD 4JSS8+8s2INbHVZs18WgBYF7P3ZNFkipNSUq9UCrUeiuhKoDEGexikaol g=; X-Files: signature.asc : 248 X-IronPort-AV: E=Sophos;i="4.80,517,1344211200"; d="asc'?scan'208,217";a="127084242" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 01 Oct 2012 14:51:11 +0000 Received: from [10.82.233.208] (rtp-vpn5-463.cisco.com [10.82.233.208]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q91Ep88b013866; Mon, 1 Oct 2012 14:51:09 GMT Message-ID: <5069ADDB.1040404@cisco.com> Date: Mon, 01 Oct 2012 16:51:07 +0200 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "rtgwg@ietf.org" Subject: Fwd: I-D Action: draft-rtgwg-bgp-pic-00.txt References: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> In-Reply-To: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A17B76FB11CF608234B1BBF" Cc: "Pradosh Mohapatra \(pmohapat\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:51:25 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A17B76FB11CF608234B1BBF Content-Type: multipart/alternative; boundary="------------040700070901020901060803" This is a multi-part message in MIME format. --------------040700070901020901060803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design All comments and suggestions are most welcomed Thanks Ahmed -------- Original Message -------- Subject: I-D Action: draft-rtgwg-bgp-pic-00.txt Date: Mon, 1 Oct 2012 07:08:38 -0700 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : Abstract Author(s) : Ahmed Bashandy Clarence Filsfils Prodosh Mohapatra Filename : draft-rtgwg-bgp-pic-00.txt Pages : 19 Date : 2012-10-01 Abstract: In the network comprising thousands of iBGP peers exchanging millions of routes, many routes are reachable via more than one path. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed a technique by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding chains in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete transparency and automation, and zero management and provisioning effort The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rtgwg-bgp-pic There's also a htmlized version available at: http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------040700070901020901060803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

This draft provides an overview of BGP prefix independent convergence and how it is possible to achieve sub-second and, for certain local failures, sub-50msec convergence using hierarchical and shared FIB chain design

All comments and suggestions are most welcomed

Thanks

Ahmed



-------- Original Message --------
Sub= ject: I-D Action: draft-rtgwg-bgp-pic-00.txt
Dat= e: Mon, 1 Oct 2012 07:08:38 -0700
Fro= m: <internet-drafts@ietf.org>
Rep= ly-To: <internet-drafts@ietf.org>
To:= <i-d-announce@ietf.org> 


A New Internet-Draft is available from the on-line Internet-Dr=
afts directories.


	Title           : Abstract
	Author(s)       : Ahmed Bashandy
                          Clarence Filsfils
                          Prodosh Mohapatra
	Filename        : draft-rtgwg-bgp-pic-00.txt
	Pages           : 19
	Date            : 2012-10-01

Abstract:
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one path. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed a technique by which traffic
can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding chains in a
hierarchical manner and sharing forwarding elements among the maximum
possible number of routes. The proposed technique achieves prefix
independent convergence while ensuring incremental deployment,
complete transparency and automation, and zero management and
provisioning effort


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgwg-bgp-=
pic

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce<=
/a>
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--------------040700070901020901060803-- --------------enig0A17B76FB11CF608234B1BBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQaa3c+G19kFA5zIYRAremAJ434Cv7d3dKKTLbJ//amwZIuR+6ZQCfaAoA sn81hpP2/GftYnPNC95wcnU= =hl0y -----END PGP SIGNATURE----- --------------enig0A17B76FB11CF608234B1BBF-- From curtis@occnc.com Mon Oct 1 12:58:54 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6621F8919 for ; Mon, 1 Oct 2012 12:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kadMTukMcsiv for ; Mon, 1 Oct 2012 12:58:54 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE4521F8918 for ; Mon, 1 Oct 2012 12:58:54 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q91Jwopm057256; Mon, 1 Oct 2012 15:58:50 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210011958.q91Jwopm057256@gateway1.orleans.occnc.com> To: "Alvaro Retana (aretana)" From: Curtis Villamizar Subject: Re: Agenda Items for Atlanta In-reply-to: Your message of "Mon, 24 Sep 2012 18:37:55 -0000." Date: Mon, 01 Oct 2012 15:58:50 -0400 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 19:58:54 -0000 In message "Alvaro Retana (aretana)" writes: > Hi! > > We're still a few weeks away from the next in-person meeting, but I > would like to start collecting topics for the agenda. > > Please let me know of any time requests. I would like to see > discussions of any proposed presentations on the list. > > Thanks! > > Alvaro. Alvaro, I would like to discuss the CL Framework in detail if time permits. This is now a WG document but we have had no activity on list about the CL Framework since last IETF. I think a discussion at the meeting could get things moving. We can tailor the depth of discussion depending on how much time the WG can spare. Curtis btw - since entropy-label is now in the rfc-editor's queue, the mpls-tp-multipath work will be resubmitted shortly, proposing to use only the entropy label based forwarding. Since CL Framework references this document, CL Framework will also be changed (hopefully before the meeting), putting greater emphasis on entropy label based load balancing. From adrian@olddog.co.uk Mon Oct 1 14:51:18 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF8611E813B for ; Mon, 1 Oct 2012 14:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu6To34064Ba for ; Mon, 1 Oct 2012 14:51:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3BE11E809A for ; Mon, 1 Oct 2012 14:51:16 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q91LpF0X023166; Mon, 1 Oct 2012 22:51:15 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q91LpEcv023158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Oct 2012 22:51:14 +0100 From: "Adrian Farrel" To: Subject: AD review of draft-ietf-rtgwg-ordered-fib Date: Mon, 1 Oct 2012 22:51:13 +0100 Message-ID: <0b7c01cda01e$e07fb020$a17f1060$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2gHt23L7KiHt6bQxOcXBrENofYLg== Content-Language: en-gb Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 21:51:18 -0000 Hi, I've done my usual AD review of your draft prior to issuing IETF last call and passing the I-D for IESG evaluation. The main purpose of the review is to catch issues that might come up in later reviews and to ensure that the document is ready for publication as and RFC. I have a number of concerns that I believe will necessitate a new revision of the document, so I will put it into "Revised I-D Needed" state in the data tracker and wait to hear from you. As always, all my comments are up for discussion and negotiation. Thanks for the work, Adrian ==== Purpose and direction of the document.... It's all very interesting, but why are we publishing it? What is it adding? What is the purpose? If this is intended to be simply a record of discussions: 1. It should say so 2. It should say that more work is needed to examine the mechanism before any attempt is made to convert it to a protocol 3. I don't need to review it for technical accuracy 4. I don't understand why the working group wants to publish it 5. I can't decide on the value of improving the document to make it more easy to read. The document doesn't seem to have any *use*. What does WG consensus mean for this document? That there is consensus to publish it, or that there is consensus behind the content? If the former, why? If the latter, what does this mean? After discussion of this point with a WG chair and with one of the authors, it seems that it would be reasonable to add a significant note to the Abstract and the Introduction about the purpose. This would say something along the lines of... The idea is to capture the current state of discussions in the WG so that they are not lost, can be referenced, and might be picked up again later. The WG currently has no interest in pursuing these ideas further. --- Notwithstanding the discussion of scope in the point above, the Abstract should state the scope and purpose of the document and the mechanism. If this is a framework of a guidance for actual protocol mechanisms, it should say that clearly and should indicate that: - the mechanisms described need to be equally and conformantly implemented by every node in the "network" (is that OSPF area or IS-IS level?) - this document only describes the principles, but does not specify the protocol details for exchange of information and synchronization of actions between routers in the network. --- I am a little bothered by the use of 2119 language in this document. Do you believe you are using it to define a conformant implementation, and how is conformance measured if the mechanism is not for implementation? Or are you trying to use it to set requirements for the protocol specification that might follow? Wouldn't normal English usage be just as good? --- In email on the WG list you said: > The expected use of this technology in the failure case > is in conjunction with IPFRR where following a protected > failure, and in the absence of a convergence control > technology, microloops may form and/or the repair > may be staved. But this *really* is not apparent in this document until at the end of Section 4.2 you have: The sudden failure of a link or a set of links that are not protected using a FRR mechanism must be processed using the conventional mode of operation. Thus, reading the document, very many questions arise and there is a lot of confusion which has to be unpicked in the light of this fact. Indeed, the example in Figure 1 doesn't mention the FRR protection, and the discussion seems to assume no such protection. Furthermore, in the Abstract it says: This mechanism can be used in the case of non-urgent link or node shutdowns and restarts or link metric changes. It can also be used in conjunction with a fast re-route mechanism which converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations. implying that FRR is only one of the options. --- The fact that the oFIB process operates on a timer could possibly be drawn out a little sooner. --- It is pretty well hidden that this mechanism only applies in a network where all routers apply the mechanism. In fact, I suspect that that limitation isn't quite true, and there are fringe conditions where routers would not need to be upgraded. But, anyway, what you clearly need to indicate is that the mechanism depends on a way to detect that all routers operate the mechanism. And you should probably discuss a little what happens if one or more routers in the network do not participate. --- While I would agree that Section 8 describes a state machine that produces the desired black-box behavior of an oFIB capable router, I would suggest that it is not a requirement that oFIB capable routers directly implement this state machine. You might change the section to say that the state machine describes the behavior that an oFIB capable router must demonstrate. --- Section 8.4 suddenly introduces "LSP" and "AAH" AAH finally shows in Appendix A. --- Transitions to Abandoned and the text in Section 8.5 don't seem to describe normal FIB updates (i.e. non-oFIB) but surely they have to be done. Maybe that is what AAH stands for, but Appendix A seems to suggest that AAH is an unknown (needing more research) and it is very unclear what "Trigger AAH" actually means across the whole of Section 8. Yet that line item appears a lot and is clearly an essential part of the mechanism. --- Section 10 should at least point at B.4. From internet-drafts@ietf.org Tue Oct 2 11:27:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98F21F858E; Tue, 2 Oct 2012 11:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0REKnSjwl9Au; Tue, 2 Oct 2012 11:27:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB27F21F854E; Tue, 2 Oct 2012 11:27:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-mofrr-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002182754.4227.30172.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 11:27:54 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:27:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Multicast only Fast Re-Route Author(s) : Apoorva Karan Clarence Filsfils Dino Farinacci IJsbrand Wijnands Bruno Decraene Uwe Joorde Wim Henderickx Filename : draft-ietf-rtgwg-mofrr-00.txt Pages : 15 Date : 2012-10-02 Abstract: As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This draft describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast only Fast Re- Route (MoFRR) works by making simple enhancements to multicast routing protocols such as PIM and mLDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-mofrr There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-mofrr-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pthubert@cisco.com Tue Oct 2 09:48:07 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA05221F8555 for ; Tue, 2 Oct 2012 09:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUhluKms4xuP for ; Tue, 2 Oct 2012 09:48:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 74CB821F8539 for ; Tue, 2 Oct 2012 09:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48694; q=dns/txt; s=iport; t=1349196482; x=1350406082; h=from:to:subject:date:message-id:mime-version; bh=Bufwfr9xg0wLOd5nyguyQcyjq3l2GEOtfRjTfUuFduA=; b=B/mlLGXXRfeWXnF/ta541v0NeMJvR2rMCJsmOMo6rsjCjswfJBwIjYQy OxCEixkSZq8S7FKQOrqLAJsKz3DqW1c1NoefUtnQIWhRMD9INfFmZtzeV B02JO++mHmX51qpcgdlECu0fMrNndH0I2MwMPS39Jr+ZA5g2uKUfjfXub 0=; X-Files: image003.png : 25369 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADQaa1CtJXG9/2dsb2JhbABFgkuDQLdMgQKBCIIgAQEBBAUBDAEQAggBXQEIHQEBAQIgAgQFEAEODBsBBgQBBBIBBgIBBQ0Hh2MLl1aBKI0bgjuQXZBLMmADkA4BlByBaYJnghc X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="png'150?scan'150,208,217,150";a="127535527" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 02 Oct 2012 16:48:02 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q92Gm1gs006470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Oct 2012 16:48:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.4]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 11:48:01 -0500 From: "Pascal Thubert (pthubert)" To: "rtgwg@ietf.org" Subject: FW: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszg Date: Tue, 2 Oct 2012 16:48:01 +0000 Deferred-Delivery: Tue, 2 Oct 2012 16:48:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--29.117800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 03 Oct 2012 03:49:08 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:48:07 -0000 --_004_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_" --_000_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W3Jlc2VuZGluZyBkdWUgdG8gZXhjZXNzIHNpemUgXQ0KDQoNCg0KRGVhciBSb3V0aW5nIGFyZWE7 DQoNCg0KDQpBYm91dCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRodWJlcnQtcnRnd2ct YXJjLTAwLnR4dA0KDQoNCg0KVGhlIEFSQyB0ZWNobm9sb2d5IGRlcml2ZXMgZnJvbSBzb21lIGlu dGVybmFsIHJlc2VhcmNoIGF0IGNpc2NvLCBhbmQgZm9sbG93aW5nIHRoYXQgbGluZSBvZiB0aG91 Z2h0LCB3ZSBmb3VuZCBhIG51bWJlciBvZiBpbnRlcmVzdGluZyBwcm9wZXJ0aWVzIHRoYXQgd2Ug d2FudCB0byBzaGFyZSB3aXRoIHlvdS4NCg0KDQoNClNvbWUgb2YgeW91IGFscmVhZHkga25vdyBh Ym91dCBBUkNzLiBUaGlzIGlzIG5vdCB5ZXQgYW5vdGhlciBGUlIgc29sdXRpb24sIGJ1dCByYXRo ZXIgYW5vdGhlciB3YXkgb2YgbG9va2luZyBhdCBhIHJvdXRpbmcgdG9wb2xvZ3kgYW5kIGZvcndh cmRpbmcuIEluc3RlYWQgb2YgZm9sbG93aW5nIHRoZSBhcnJvd3MgYWxvbmcgYSBwYXRoLCBhIHBh Y2tldCB3aWxsIGNhc2NhZGUgZnJvbSBhcmMgdG8gYXJjLCBlYWNoIGFyYyBwcm92aWRpbmcgYXQg bGVhc3QgMiBlZGdlcyB0aGF0IHRoZSBwYWNrZXQgY2FuIHVzZSB0byBwcm9ncmVzcy4gQ2VydGFp bmx5LCBBUkNzIGNhbiBiZSB1c2VkIGZvciBmYXN0IHJlcm91dGUsIGJ1dCB0aGVyZSBhcmUgdG9u cyBvZiBvdGhlciBhcHBsaWNhdGlvbnMuIFRoaXMgcGFydGljdWxhciBkcmFmdCBtYWlubHkgcHJl c2VudHMgdGhlIGNvbmNlcHRzLCBhbmQgd2lsbCBkZWZyZXIgdG8gbW9yZSBkcmFmdHMgdG8gc3Bl Y2lmeSBhY3R1YWwgc29sdXRpb25zIGZvciB0aGUgc3BlY2lmaWMgcHJvYmxlbXMgdGhhdCB3ZSB3 YW50IHRvIGFkZHJlc3Mgd2l0aCBBUkNzLg0KDQoNCg0KV2UgaGF2ZSBiZWd1biByZWNlbnRseSB0 byBvcGVuIHRoZSB0ZWNobm9sb2d5IGZvciBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9ucywgaW4gcGFy dGljdWxhciBhdCBJU0ExMDAgYW5kIElFQyBTQzY1QyBpbiB0aGUgY29udGV4dCBvZiBpbmR1c3Ry aWFsIHdpcmVsZXNzIG5ldHdvcmtpbmcuIFRob3NlIG5ldHdvcmtzIHJlcXVpcmUgbXVsdGlwbGUg Zm9yd2FyZGluZyBzb2x1dGlvbnMgZm9yIGVhY2ggbm9kZSBhbmQgYSBwYWNrZXQgbWF5IGhpdCBt dWx0aXBsZSB0cmFuc2llbnQgZmFpbHVyZXMgYWxvbmcgaXRzIHdheSBvdmVyIGEgbXVsdGlob3Ag d2lyZWxlc3MgbWVzaC4gIEluZHVzdHJpYWwgV1NOIGlzIHRodXMgYSBwcmFjdGljYWwgdXNlIGNh c2UgZm9yIHdoaWNoIHNpbXBsZSBEQUdTIGNhbm5vdCBhcHBseSBhbmQgd2hlcmUgZXZlbiB0aGUg TVJUIGFwcHJvYWNoIGlzIG5vdCBzdWZmaWNpZW50Lg0KDQoNCg0KQXMgeW91IGdvIHRocm91Z2gg dGhlIGRyYWZ0LCB5b3UnbGwgZmluZCB0aGF0IGFuIEFSQyB0b3BvbG9neSBpcyBtYWRlIG9mIG11 bHRpcGxlIEFSQ3MgYW5kIHRoYXQgZWFjaCBBUkMgYWxsb3dzIGF0IGxlYXN0IG9uZSBicmVha2Fn ZSB3aXRoIHRoZSBGUlIgbG93IHBhY2tldCBsb3NzLiBZb3XigJlsbCBmaW5kIHRoYXQgYW4gQVJD IHRvcG9sb2d5IGNhbiBiZSBtYWRlIHRvIGZvbGxvdyB0aGUgU1BGIHBhdGggaW4gbm9ybWFsIG9w ZXJhdGlvbiBhbmQgeWV0IHByb3ZpZGUgYW4gYWx0ZXJuYXRlIGZvciBhbGwgbm9kZXMgaW4gYSBi aWNvbm5lY3RlZCBncmFwaC4gWW914oCZbGwgZmluZCB0aGF0IG1vbm9jb25uZWN0ZWQgem9uZXMg YXJlIGVhc2lseSBpc29sYXRlZCBhbmQgdGhhdCB0aGUgcHJvcG9zZWQgY29tcHV0YXRpb24gY2Fu IHJlY3Vyc2UgdGhlcmUgdG8gb2J0YWluIGEgbWF4aW1hbCByZWR1bmRhbmN5Lg0KDQoNCg0KW2Np ZDppbWFnZTAwMy5wbmdAMDFDREEwQ0UuMkZCQTA2NDBdDQoNCg0KDQpBbiBBUkMgdG9wb2xvZ3kg Y2FuIGJlIGV4cGxvaXRlZCBpbiBjbGFzc2ljYWwgcm91dGluZyBvciBpbiBNUExTLiBUaGUgcmVj b3ZlcnkgY2FuIGJlIGRhdGEgcGxhbmUgb3IgY29udHJvbCBwbGFuZSB3aGljaCBwcm92aWRlcyBh ZGRpdGlvbmFsIGNhcGFiaWxpdGllcy4gQmVjYXVzZSBBUkNzIGFyZSAoYXQgbGVhc3QpIGR1YWwg ZW5kZWQsIGFuIEFSQyB0b3BvbG9neSBhbHNvIGVuYWJsZXMgbG9hZCBiYWxhbmNpbmcgYW5kIGEg cmVjdXJzaXZlIG92ZXJmbG93IG1hbmFnZW1lbnQgdG8gdGFrZSB0aGUgdHJhZmZpYyBhd2F5IGZy b20gdGhlIHBhaW4gcG9pbnRzLiBUaGVyZSdzIHByb2JhYmx5IGEgbG90IG1vcmUsIGJ1dCB3ZSds bCBoYXZlIHRvIGRpc2NvdmVyIHRoYXQgdG9nZXRoZXIuDQoNCg0KDQpBYm91dCBJUFI6IFN0ZXdh cnQgcmVjb21tZW5kZWQgdGhhdCBJIHRhbGsgdG8gQWxpYSAoYW5kIGVmZmVjdGl2ZWx5IEpvZWwp IGluIFRhaXBlaSB0byBtYWtlIHN1cmUgdGhhdCB0aGUgSVBSIGNpc2NvIGhhcyBvbiBBUkMgaXMg bm90IG9uIHRoZSB3YXkgb2YgTVJULCBhbmQgd2UgY29uY2x1ZGVkIHRoYXQgdGhlc2Ugd2VyZSBl ZmZlY3RpdmVseSAyIGRpZmZlcmVudCB0ZWNobm9sb2dpZXMuIFNvIGNpc2NvIGRpZCBub3QgY2xh aW0gSVBSIHJlZ2FyZGluZyBNUlQgYnV0IHdlIGNlcnRhaW5seSBoYXZlIElQUiBvbiBBUkNzLiBX ZSdsbCBwb3N0IEFTQVAgb24gdGhhdC4NCg0KDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlz IGFwcHJvYWNoIHRyaWdnZXJzIGludGVyZXN0LiBXZSB3aXNoIHRvIGRpc2N1c3MgQVJDcyBkdXJp bmcgdGhlIFJUR1dHIG1lZXRpbmcgaW4gQXRsYW50YSBhbmQgd2lsbCBiZSBhc2tpbmcgZm9yIGEg c2xvdCBmcm9tIHRoZSBjaGFpcnMuDQoNCg0KDQpDaGVlcnMsDQoNCg0KDQpQYXNjYWwNCg0KDQo= --_000_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5U ZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4 dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxiPjxpPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bcmVzZW5kaW5nIGR1ZSB0byBleGNlc3Mgc2l6ZSBd PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5EZWFyIFJvdXRpbmcgYXJlYTs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BYm91dCA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LXRodWJlcnQtcnRnd2ctYXJjLTAwLnR4dCI+DQpodHRwOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LXRodWJlcnQtcnRnd2ctYXJjLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+VGhlIEFSQyB0ZWNobm9sb2d5IGRlcml2ZXMgZnJvbSBzb21lIGlu dGVybmFsIHJlc2VhcmNoIGF0IGNpc2NvLCBhbmQgZm9sbG93aW5nIHRoYXQgbGluZSBvZiB0aG91 Z2h0LCB3ZSBmb3VuZCBhIG51bWJlciBvZiBpbnRlcmVzdGluZyBwcm9wZXJ0aWVzIHRoYXQgd2Ug d2FudCB0byBzaGFyZSB3aXRoIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U29t ZSBvZiB5b3UgYWxyZWFkeSBrbm93IGFib3V0IEFSQ3MuIFRoaXMgaXMgbm90IHlldCBhbm90aGVy IEZSUiBzb2x1dGlvbiwgYnV0IHJhdGhlciBhbm90aGVyIHdheSBvZiBsb29raW5nIGF0IGEgcm91 dGluZyB0b3BvbG9neSBhbmQgZm9yd2FyZGluZy4gSW5zdGVhZCBvZiBmb2xsb3dpbmcgdGhlIGFy cm93cyBhbG9uZyBhIHBhdGgsIGEgcGFja2V0IHdpbGwgY2FzY2FkZSBmcm9tIGFyYyB0byBhcmMs IGVhY2gNCiBhcmMgcHJvdmlkaW5nIGF0IGxlYXN0IDIgZWRnZXMgdGhhdCB0aGUgcGFja2V0IGNh biB1c2UgdG8gcHJvZ3Jlc3MuIENlcnRhaW5seSwgQVJDcyBjYW4gYmUgdXNlZCBmb3IgZmFzdCBy ZXJvdXRlLCBidXQgdGhlcmUgYXJlIHRvbnMgb2Ygb3RoZXIgYXBwbGljYXRpb25zLiBUaGlzIHBh cnRpY3VsYXIgZHJhZnQgbWFpbmx5IHByZXNlbnRzIHRoZSBjb25jZXB0cywgYW5kIHdpbGwgZGVm cmVyIHRvIG1vcmUgZHJhZnRzIHRvIHNwZWNpZnkgYWN0dWFsDQogc29sdXRpb25zIGZvciB0aGUg c3BlY2lmaWMgcHJvYmxlbXMgdGhhdCB3ZSB3YW50IHRvIGFkZHJlc3Mgd2l0aCBBUkNzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZSBoYXZlIGJlZ3VuIHJlY2VudGx5IHRvIG9wZW4g dGhlIHRlY2hub2xvZ3kgZm9yIHBhcnRpY3VsYXIgYXBwbGljYXRpb25zLCBpbiBwYXJ0aWN1bGFy IGF0IElTQTEwMCBhbmQgSUVDIFNDNjVDIGluIHRoZSBjb250ZXh0IG9mIGluZHVzdHJpYWwgd2ly ZWxlc3MgbmV0d29ya2luZy4gVGhvc2UgbmV0d29ya3MgcmVxdWlyZSBtdWx0aXBsZSBmb3J3YXJk aW5nIHNvbHV0aW9ucyBmb3IgZWFjaCBub2RlIGFuZA0KIGEgcGFja2V0IG1heSBoaXQgbXVsdGlw bGUgdHJhbnNpZW50IGZhaWx1cmVzIGFsb25nIGl0cyB3YXkgb3ZlciBhIG11bHRpaG9wIHdpcmVs ZXNzIG1lc2guICZuYnNwO0luZHVzdHJpYWwgV1NOIGlzIHRodXMgYSBwcmFjdGljYWwgdXNlIGNh c2UgZm9yIHdoaWNoIHNpbXBsZSBEQUdTIGNhbm5vdCBhcHBseSBhbmQgd2hlcmUgZXZlbiB0aGUg TVJUIGFwcHJvYWNoIGlzIG5vdCBzdWZmaWNpZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5BcyB5b3UgZ28gdGhyb3VnaCB0aGUgZHJhZnQsIHlvdSdsbCBmaW5kIHRoYXQgYW4gQVJD IHRvcG9sb2d5IGlzIG1hZGUgb2YgbXVsdGlwbGUgQVJDcyBhbmQgdGhhdCBlYWNoIEFSQyBhbGxv d3MgYXQgbGVhc3Qgb25lIGJyZWFrYWdlIHdpdGggdGhlIEZSUiBsb3cgcGFja2V0IGxvc3MuIFlv deKAmWxsIGZpbmQgdGhhdCBhbiBBUkMgdG9wb2xvZ3kgY2FuIGJlIG1hZGUgdG8gZm9sbG93IHRo ZSBTUEYgcGF0aCBpbg0KIG5vcm1hbCBvcGVyYXRpb24gYW5kIHlldCBwcm92aWRlIGFuIGFsdGVy bmF0ZSBmb3IgYWxsIG5vZGVzIGluIGEgYmljb25uZWN0ZWQgZ3JhcGguIFlvdeKAmWxsIGZpbmQg dGhhdCBtb25vY29ubmVjdGVkIHpvbmVzIGFyZSBlYXNpbHkgaXNvbGF0ZWQgYW5kIHRoYXQgdGhl IHByb3Bvc2VkIGNvbXB1dGF0aW9uIGNhbiByZWN1cnNlIHRoZXJlIHRvIG9idGFpbiBhIG1heGlt YWwgcmVkdW5kYW5jeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNDgwIiBoZWlnaHQ9IjM2MCIg aWQ9IlBpY3R1cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDMucG5nQDAxQ0RBMENFLjJGQkEw NjQwIj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFuIEFSQyB0b3BvbG9n eSBjYW4gYmUgZXhwbG9pdGVkIGluIGNsYXNzaWNhbCByb3V0aW5nIG9yIGluIE1QTFMuIFRoZSBy ZWNvdmVyeSBjYW4gYmUgZGF0YSBwbGFuZSBvciBjb250cm9sIHBsYW5lIHdoaWNoIHByb3ZpZGVz IGFkZGl0aW9uYWwgY2FwYWJpbGl0aWVzLiBCZWNhdXNlIEFSQ3MgYXJlIChhdCBsZWFzdCkgZHVh bCBlbmRlZCwgYW4gQVJDIHRvcG9sb2d5IGFsc28gZW5hYmxlcyBsb2FkIGJhbGFuY2luZw0KIGFu ZCBhIHJlY3Vyc2l2ZSBvdmVyZmxvdyBtYW5hZ2VtZW50IHRvIHRha2UgdGhlIHRyYWZmaWMgYXdh eSBmcm9tIHRoZSBwYWluIHBvaW50cy4gVGhlcmUncyBwcm9iYWJseSBhIGxvdCBtb3JlLCBidXQg d2UnbGwgaGF2ZSB0byBkaXNjb3ZlciB0aGF0IHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5BYm91dCBJUFI6IFN0ZXdhcnQgcmVjb21tZW5kZWQgdGhhdCBJIHRhbGsgdG8g QWxpYSAoYW5kIGVmZmVjdGl2ZWx5IEpvZWwpIGluIFRhaXBlaSB0byBtYWtlIHN1cmUgdGhhdCB0 aGUgSVBSIGNpc2NvIGhhcyBvbiBBUkMgaXMgbm90IG9uIHRoZSB3YXkgb2YgTVJULCBhbmQgd2Ug Y29uY2x1ZGVkIHRoYXQgdGhlc2Ugd2VyZSBlZmZlY3RpdmVseSAyIGRpZmZlcmVudCB0ZWNobm9s b2dpZXMuIFNvIGNpc2NvDQogZGlkIG5vdCBjbGFpbSBJUFIgcmVnYXJkaW5nIE1SVCBidXQgd2Ug Y2VydGFpbmx5IGhhdmUgSVBSIG9uIEFSQ3MuIFdlJ2xsIHBvc3QgQVNBUCBvbiB0aGF0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhpcyBhcHBy b2FjaCB0cmlnZ2VycyBpbnRlcmVzdC4gV2Ugd2lzaCB0byBkaXNjdXNzIEFSQ3MgZHVyaW5nIHRo ZSBSVEdXRyBtZWV0aW5nIGluIEF0bGFudGEgYW5kIHdpbGwgYmUgYXNraW5nIGZvciBhIHNsb3Qg ZnJvbSB0aGUgY2hhaXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DaGVlcnMsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_-- --_004_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=25369; creation-date="Tue, 02 Oct 2012 16:48:00 GMT"; modification-date="Tue, 02 Oct 2012 16:48:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAGKuSURBVHhe7Z0JmBTVuf7JTaLe+zfqNRrJYuJN jFEnRmPc4r5EwSWC6LizuuJKICBqlHFDMYIIKoIKogKCC7ig7MwAsgmCiKDIpqggBEcRVED8/uet nmpPVVd3V3dX9amqfs/ztDgz1bX8zql661vOdxoJGwmQAAmQAAmQQNkJNCr7EXlAEiABEiABEiAB oQBzEJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABz DJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAA CZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAA CZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCA AQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIU YAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQ eUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgS IAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAES IAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAES oABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABz DJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAA CZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAA CZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCA AQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIU YAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQ eUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgS IAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAES IAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAES oABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABz DJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAA CZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAA CZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCA AQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIU YAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQ eUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgS IAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAES IAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAES oABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABz DJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAA CZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAA CZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCA AQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIU YAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQ eUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgS IAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAES IAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAESoABzDJAACZAACZCAAQIUYAPQeUgSIAESIAES oABzDJAACZAACZCAAQIUYAPQecjyE1hYUyWNGjVKfapHqBMYIdWNqtV/7ab9vLBGqqprpKZKbVtV IwuxdXXDd619aN/DtvZ+1b/WrtE89lH+q+YRSYAEokyAAhzl3uG5BUPAEkldbLHbPALcqEpqoLzW ptUNou0+HexD287aZ8PP1jH1vwVzKdwLCZBAcghQgJPTl7ySLARg/Val1dTD4k2p7PcWMcSzwfJt UGD1N1i+LkH1EGZYypYVnLEPdg8JkAAJOAlQgDkiEk+gdAG2ES1MuaVta5oCnPixwwskgTAJUIDD pMt9R4OApwsaYvq9RZuKETe4qfNYr2krV3c540r149ACjkbf8yxIIMIEKMAR7hyeWnAEHElUdqYU LNh0YhaSrrwF2JHAlU7iajg3fR+6i5oCHFzncU8kkFACFOCEdiwviwRIgARIINoEKMDR7h+eHQmQ AAmQQEIJUIAT2rG8LBIgARIggWgToABHu394diRAAiRAAgklQAFOaMfysoIjcNsjo2Xzlq3B7ZB7 IgESIAFFgALMYUACOQhAeI9oea+s/GQ9OZEACZBAoAQowIHi5M6SRgDCCwGe8dbypF0ar4cESMAw AQqw4Q7g4aNNYO6iDy0BHjdjUbRPlGdHAiQQOwIU4Nh1GU+43AQgwGwkQAIkEDQBCnDQRLm/xBGg ACeuS3lBJBAJAhTgSHQDT6JUApu3bpMFKz5zfEZMWSFPT1pmffqOnC+3PlYr1/V6WS65+0W5stcE 3x8IsJ/tb3tiuvQYMks6PzjGOs7N/SdZx8Xx5yz5T/rcFq/6vNTL5fdJgAQSQIACnIBOTNolbPx6 a1qsRs9eZQnYoPHvS9dBc9Kfy/tMl9NuHe/7c9xVA+Wodg9Y8dwjWt0nx1zeL7TPka17Wsc5sm1v wXHznedF99Y5ru3BlxenXxxqF6y2WCxbvSFp3czrIYGKJ0ABrvghUF4AtpVqW6cDXnsvLT7V3Sfn Fat8YlYJf7dfRGyhHjn9g/QLCzwBbCRAAvEgQAGORz/F6izhYoXLFZZrr5HvWAIbtrh2HDA7qxWJ 8xj/5scZLmq3y7rUnyGEtsvb/e8dw95ynF/z2yeG+rJxzcMz5Zan3rTOx752inOsbiOebAUQoABX QCeHcYlwidoiC0sMIgtXahAWaNte09JiZQuZLqBJjKHimvQXAPu6dQ9BEKJtu7uxX3ghcMw19V+F MUS4TxIggTwEKMAcInkJ4CGNWKwttKWIrO0+9RLWvCfCDSwCq9ZttIRz+qJP0xY3rN1SX4LwfXgs bJc2cZMACYRLgAIcLt9Y7d1OfoJl1OPZtwVuzGLEFu5g2/0J4YZYfPbl5lixiPvJQqTdYYBiLGiM AYpy3EcDzz+qBCjAUe2ZMpwXhBGWKMQSbt9CxNZ2E+P7tsUUKVfmiGpp1KhKahaWAWSMDoEXIfQ7 +szOLC80dEBRjlGH81QjTYACHOnuCfbkbMGFq7EQscWUH1jEdswQlnLU24jqRlJdrUS4eoTxU11Y U6VeBhqlPtb5jJDqRtXqv3bTfl5YI1XVNVJTpbatqhG8P+Ba0t/Xv4dt7f2qf9OX6rEPPxD0UAO8 GIWMEWwPQYfVzWQvP7S5DQlwNaREj4FiBBcPUsR64x0HtAXNLXQGutsSSV1scQ55BFi33GHJe75E YB+6ha/9bB0zGOsfyWF2/L+QkIQtyBiDbCRAAt4EaAEnaGTgYQmXsF8LF25kxPeQYZyoQg+aaFmW sEEjGNZvVYYfPI8AN1i+qaGJbWEBuwTVQ5jT1woBduwj2EFuu7AxdvyKMsYkxmYSM9iDpcu9VRIB CnCMexuuYFRKwoPQzzxbuJJh3eI75U6KQlIQhN5d1SrXeePhbmdNwwWuz2nNdf4O0c1qQZan40sX YPs8F6bc0rY1bVCA3eTgcobrGVOb/AgyksGQd4CQBsYFGwlUKgEKcER63m+c8FE1Z3P0Mx1l98Ou kN/vrh7Iu7eSY1VJxj/vr8cJj5U/q9/hYTjgkWvl/wKME/rFBSsJD1gUoCg0ycdv7BEWPIQZ7vLv LSvbYswSN/V7AUFt5+mChph+b9Gm+r7BTZ3Hev3+5cLlgtaPE7IFnA+N/WKIlz0/JUOxDV6uEuWF yQeJfycBRYACHIVhkCdOiAfToPF95LeNTrSE9bT2rWTHRr+R37dvqIV8zrHSaP9brIedMxGmPHFC IMScVDur1q+ABr0drOlenZtIoyaPar2ashxNuqEdSVT2iVhZ2nZiFpKuvAXY8WKWTuJquDx9H7qL 2rAAu28peCvg/YCnJl+2Pf4OS5piHIUHE88hbAIU4AbCuOHt4hB2UQO4P2HB2dm/YXWGl5tyzpLH 5cBGTeSYdHWpW+TnjVKWrSXADZYvznHk9Ifl7wbihHiwgk0hFq5dMtJ2KdvM9XrGtvWsl3PEdfpx b8IT8PNzxlsueTzw0a+WiJlU4LAGTkz3C7czErtwb+V6CcO4ghXNRK6YdjRPOy+BihZgxK1wgxcq IBCdIKfi2AKMebSwIlNWgia41qo/qZ8PVfGzHr2ukt/8tpO8kTEdqDxxQrh7IaD5LFg71gchxUM0 qOkp4GRXgYIw5yswgW0Q92aLHgGMCfQNxlOufAD7hQr9zkYCSSFQkQKMmzifKyyfuOCBAGEpVYjx /fHPdZKfNjopZd2mP4+pGG/KzYwXhJsv3Fu5LM9MzR01ECfEecJqyRXTs7OqsV25XYg4HlyXze+Y JKdmWaYQ57d45j0iX69Iyv2buOvAvZnvpRj3A/qaCVyJ6/6Ku6CKEmA8pLNN0bHdXRBVPATswvgQ E7gyswmPLcSFWnewvrFf23pzJFGpeK51Pjc0NR4nxHXBKs9lncBlj+uJQoN13H34Ajnnzsny95oJ GVa61Kohrz71008UWd6VYhyFTstyDvC0QGhzvSwjLIF7tNQX4Qhj4KklmEBFCDBuTrxVu61a3NgQ F7/WmmWtqmQSrwcCYpv6dCAvYXa6mDMXk4cYwxUXFTcbRDWbex6/B7tIlZ/UblTEp/HwPu/uWvXy UJvu+8/G7WoJsP3Z+vpvIi3Ctz0yWjZviX7lsbCfkbB28XKcS4xx70TlRTBsHtx/MggkXoAhEG7r FeKIOG6hVqve5dmE2C3ySDSBNQ0rMZtbG+Idpbd4vGjgZcLrfHGuuPZS2JXz1sG14MF9YY86Oe+e Wnmw//UOAYYQb6nbSWT9a+U8LV/HgvAe0fJeWfnJel/bV8pGbu+Re5zifsf9FJcxWin9xuvMJJBo AYZl635jhiUcZBEK3Oj5koC8hMy2vqNmQUJcvaxeCK9fT0EUbzQ8jPHSdb6yiCeNaJohwpYQL+ki su3ryJw+hBcCPOOt5SWdk9855un8AkO1qAu9SNsjla1uNV604QWJ2j1W6HVy++QSSKwAw+rU45YQ ybDcU/kE+PRuKXcztoNlGcVpFXgp8bLSwRAvGUlpeGj3G/2u1D17qqcIfzXz0Mi4pOcu+tAS4HEz FhWPP+a1qP1eOFzUeLnOdi/anii/++N2JFAOAokUYMRQ9RsRIhJmDdp8GdOnd5tguUGDtLz1wVFq nBBWr1eSFQQ5rHMux+DOdQw8sJ8d1kG2TNou0yVdq1zSnw4zfYrW8SHApbTSS2FGrxZ1Lh54wcKc 8myxYiRhRvEFuJQ+5nfjSyBxAgyh1cUXN2KY0xXg3jpbZdzmEuGbn5wb2ggpNU6Ih5X73OGCrpR5 s2MmPSf1452JWekkrXfbGHdJmxdge+iWZ455kDcKxnC2WQ8U4iBJc1/FEkiUAEMM9fglxDes+A8s Q6/Mai8hDjOruZQ4Iaxy9/nCRV5pUzpWfLxK5ow6xtMlLbP3Fdm0uNj7y/oe+ghu5EdfmCaDX54p cC37/UCA/W6L7Z4Z84Z1nFemvJ1K3qrAWtTuzkLuQraqWxTikoY2v1wigcQIMERDz3aGSzUMyxfJ PBCujFhTQ5zXLWhIAgmz+YkT2g8gzJm0i2V4VbKCK7pSG8bPsOG3erqkZcoOJbmkewwaJy06DrDc yUe37SlXdX8m5+fCm5+U0zs8Jk2ve1ROaP+IHHN5P+vT5NpHrd816zRQsM2Vdw3L2M+Jl/W2jnP6 tf0Ex0Wr9FrU9pjGy3i27H6EW+KcZFip923crzsxAqwnEEEcw4jzwKXllSEMMbOX29OXzwsr6QuD 7osZM2T1oEGyols3uWu/Y2T+8cenP0s7dJCP+/WT+smpBKp8MWo9QW3z6tWytb4+7uO6qPPHy1XP p5+X917e39sa/uDuovbr50v2i10hZVGjNm/cz3VGYRsIcbaELQh0UvMeosCe5+AkkAgBdruCg87a hZh7LQQAsS3HW/O2r7+WdSNHypIrr1Qe0X1ViLKR78+EH20nDx54ilzaro+nEMNToL8oQMinN25s CXglNghhh4fr5KUhZ3uL8IpugWOB9Z0tVpnv5cn+O8ZnmKGOwC86AjvMFkbCiw2KzFRaKCYCXVJx pxB7AYY46g+pIF2+eFP2ih3BjRv0w84dJ5wza6HM6NZdpp3URGq339634OYS5+E/+z/pdOq1cso1 T8gJ1z0pJ3UcLtc9NCU96CHy+vch9utfi16BirDvUjyYr1DFHO7rd7Ns9siSVm6HwE4BY8zr5c6e J45wBzwvSJbD/+db0g/7WjxijIh6kRLlzWDLTwDeK6/7HN6IML1Y+c+MWySdQKwFGNaKPt0AVkQQ za5/7LY+YC3iQRhGhR07TnjuqdfI/b8/VCb+6MeBiK6XIL/83z+RViddIke27S3HXzXQeqgvWrom q3X9bps2FeeWhmfj6odnyL8e6CUbJ+yYaQ0rd3Qx3g97KT57Wpy7iAR+9vPQtxefcE+3GXHU+WqV b3Vbq8+2Jk3UnOboFBYJ4t4Mcx94mfcq6gFxpls6TPKVu+9YCzCsXVsk4TYKIuMZD0ivhRdwrDBd UnD5FuJeHtH4d5Zr+ZYm7eWuTv3k3hv6W59B3QfLS62vk+cPOVFe2qVxThF/dN+jpFpZwWB45k2j pWeL62XyT3by/A7c0pVmDUMIIcLX3PuIpwjf89BNBT85MIayuZUx7rxf7uwpQI3Si3PoyxvbZVH7 q7Fgi6/97+fVFxZ8jvoX6uYskVenvVPSPuL2Za9cj6QVpIlbnyT1fGMrwLAg9AdZEHFflCp0Zzfj 7TeMbGp7QMHtO3OvvfJauy/stqfc/9ez5cGuD1uuSLjA850XEtOuvrC7DNr70Kz7H73jrnJFq/vS LM/qMlIePKZaJm/n7fZGHLqSGsZE615T5Zbe3TPc0ZZ7uoga0l4uZ30swwpz9i0EuEpqFjaQH1Et japqxP7R7o/nJ7wr7+2pEsgaLGD73zVNmhVtCfcdViudeo2qpC63rjVbPXT0Da3hihsOoV1wLAUY VoJupZbqesYN5U6CwRtvmNNykKH85hFH5BReiO7d5/xT+j8+wRLcQl3f+kvKBdc9LT0Pb5H1eLCk dRG4WLmmR/x6f8/tFzRtqkomV45r86qHplts7uhTk+mKnrZLwfOEkeCTK7kqM4/BQ4B1E1h7PNR/ 9KnU7/aLDBH++LBjixJhiO8FNz4R2gMo6jvGPeS1mEvQOSBR58DzC4dALAVYf4CV6nqGu8ldhjHM EoyY5rOwefOcwvtI1QmWpesnFphvWMCC0x/2bS5/RIb+aj/P4z97ZFPLFa1v30PFFL3iyHMOOkhw LUluXvNGe/XrnCnCbx5REAZ34qDOGy+CmS9auV3QGQdfsUK++sWeGSK84s9HFyzC7WqGSLMO/Qu6 vqRtnC0nBLkThb4UJ40Nr6c0ArETYFirupu4WNezl4sJ+4VghdVg9SKWmi1T+aHDz5RBT0wKJJat XwPe4uFKR1YnXjbwkJ9+bRfP83j94EOlW++xDhHGFKZXdv15xvZwnX85b15YuIzv1/Fydss4OU3V 9IZYDnr8kkwRXj3I9/nioe21aAD6x9u96bKABfWZNZe015GVCG/+1a9LFmFU1cKHTax68u6kN1jH xSTjkScJgEDsBFhPvEIsrZiG+Jr7RsqMuxWz5+zfQcGMbMI7WGU9PzHgtVCTvLzODElV03bZxVNY Z79Y6yg6gmQtJH65rwHfx4tFUhvGildm7PTnjnKK8PTGBSFwrzyVu3iMW4BT1a2yeKG/Pw/lodhc 9acMEf7oUP/uaAqws1vx4u6esoS+o0u6oOHPjRsIxEqA3dZvMYMeb7FulzNc2mG5kuCmRXELL/GF oPWrGRi4xVvI6P5aWUpwJ3sJ68cvvuJYohAJWl4JXVN22MGqypXUhrGhv/jBCm7b/enMOcJf+vcG uBfBwM/ZW6YFfHaj/aX9uM+sim/42POEkaCHD84Xno6ah1RJ1l/unSHCS/fbR/o81EN6Dejp+Xlw UG8Z9pwqZ/lAN7nvwRqpnfSE9Zk8/fW8takz6lEncGB4rQMO7mwkUAiBWAlwqdYvXIrlXKYQ7tnX 9/B2OT98csvIuK5QejJbXBrCioe7zq33X87wfKFIsgjjpsIL39l3ThJ7fecMK7gANzTclnbsF6VM 3c0prGOkyZ7fT0E6Yv9GcmrrzoJpUEMGtUx/6oafIAtGHZj+pIuIvKJu871Tc4Mdn8PUz+PUp7a0 z5pXfypvP7+vLHxhX1k8aj+Z+tQB8livk+WJB5vLsGH/Rt3UQp5JsdkWfej2pKEvw3qZjw0Ynqhv ArER4FKtX7fFEeZKSaCPWs1Td850747dYUd57Nb+kbxJUUPay1Jf3rWr9bKgZ4Mia9pr26SLMMbh hSpWi7nBGVWyChQajMHWPafKizM/TFus8M7c0Os+K+Ma4jp6yBmWoK56VSVVlSKUuUS4lP0W+N1t 844T5RISWd5VrIpimMZVIDffT7cybAiXtDtEgdBYmDUDynBZPESZCMRGgEuxft3uw7BvEMRW67bf IUOghqs5mrWT3ipT1xZ3GBQE8RJWVMPaUP+l6KsoXX9ujarYtV3G9oku2LHta9m87K7MVZMQA1Z/ y9bwAgMPDNyUiP9CfDvd10eQVQ2hhch+Ni7LusQFilxWoc4mwheWZgGX9GKgX9ucg0SwBjMWvaif bHwtZr93ECxedz36sJ8xfs+N20WbQCwEuFjrFzeGO2ECD78wXURwO3vVbn70xPONxnoLGYYoDoK4 rluI7fm/OlMU+pj4Y6cI47vwACSurRsp1vrAXoL4sXPxCiRvwesCVrBqL7pzuGXVjhh8viW2gYmW X3HGecPynHq0bP7d/2S6o+//Y+rv+T4QSb/HDGI7TPGCtQz2W+sjPaTcXjaKcKS7KxInFwsB1uey wt3jp0Fk3ZmmmLcXZkNCU+1Pf5YhXAPPuiJ2LikIqFeGNBK2Nq1b72DrJcL47qbFpS1kH2ZfFbRv PPxzCY9ypdo1nuEhsKZ73T7SEtxRT7Uo3X3sFjJbJGEtwo2Lj201wnLEZ1N29pvWrJO1/6ssdi0m /J0Kl5S0eAMS0Oxj4191Pl+8c5NsmHWSrKk9XL6t3T4Y4ca142VnczTnoKN4jz6vmyJc0J1WcRtH XoAhpPoaqX4zn90LbyPTOcyGRKbJqviB22occcHVYR421H1DQL3KZOJ3G5Yuc8S+ujTrnHHtqG0d 67WF8wjvN3W7S7/Hu6bHZ/Oa0VZiFJKhPFdR8msRwuqD0EBYV92fEravVwTa11gxabMKHziSslQO QOhNxXs3fDJeVsy5Q+ZNvFbeefX44l9QFjZXLw2DImcZU4RDH0WJOUDkBRiCa79RQoj9uI/d1Z/K MT1gytEnZgjQmJZXxX6gQECzTVNaO2uOYyk9r6pZcFvHrkHw8rhaxw87xbJyMTYvv2eglSzluWpS LtFF3NgW2k+HiapqUlZU01t3dFrBKnRQkhVcwtm/++EamTptuNSN7iAzR/5N1ozZw7/FPEWd9yK1 ChQYRqS5Rdi7wllETpanYYxA5AVYzzD0U6UKiS66CyhstzN6bnqbKzPEd9KZ5xrr1KAPjLrPEFK3 dY9Y74dPPu2YioEymu7tUIQkFg3CC0HMIZqYeoQMaIwxWLuLX9rPv1AsUC8jduZvBFyo9eu+kOWN nXOE795XWZVWpa1q9V+7aT8vrJGq6hq1OISaFtWwIASKgjRS7uzUR/setk3/Xisc4rEP9/hA3sfc t+dI7bi7Zdrzp/kXZLzULFWWfA4XfLnGoluEy/EsKte18TjBEIi0AOtzJTEPNd8qJCiyoc9XLcdb 54x7+mYIzuRD/hpM70RsL8iE9sqQXtD+Gjn/9lT5StSS9lrEIdLVsmB5+hReJFMha9lXxvLMvUSW qNWj4MrOkSFtspsnXqrWDNZiwd/u84f8AqyXwcTKTJ4ludzlMrWfLWHOU0rTBQUx9gmvT5IJIy/3 77KGKx8uaoPsTXjjTI4nHrswApEWYD2OizT/XA2F8/UKV5izGvZcvBXjazOm4SAOHOu4Z57xgznB XiI8+YCDBSsoQYRRtnLC/+7m2A5u7Mg1WEmII/qweOFmhtt562QVN83nVoYFVmZ3crFsZ3f8g3z9 Xz92xoIX35/bAnYshQhhheXrElQPYU6Xz4QAeyyn6PcacF/PeXOCzB3bStaOVRZvvtg6VqzCi5Ah q9g9RSmIRVb8suJ20SYQWQHGTaZbs7kKnruXJ4QQQ5DDbOvfXSpjdvqpU4zUGrqJyfzNAQ9zhb2m KU1S05FuO+kSywrGGsNuoY6MFYyEJmQQ+xBeFMVYNuYv+R/ysKAjFIP0O/YX1lTJxD3Uy5FeJatb dQECbB/JXrGpwQUdogC7r+2DJa/I4vFn+YvBG7CK3TMysi+64bfXuF1SCERWgPX4Sb6pR/r8O4g2 XNFhNsREX9z7gAyBwfzZSmmYppRtZacJKrv2qb0OzJgfbLxKlg/hxRzdjqpAxsCh/5b6KQfnFl7D llUgY01Zo50aHegQ4C2HHKBivN9btBDpdGw3j/X6/SIRLhe05XZuEOcSLeCs161cze++0VuWjDky /wsTYsWIx5cpFg+DQp/N4VV+NJD+5E5iRSCyAoz4rZ1MlatQvbtIR+6i9sH0zajmrTPEd+kttwaz 8xjtBQtNeCVnZVv16dNhhrJUfQgvSj3e+8gd8uprD8qWmWoFoVxuTRS1wFxUg7HFIIfJM6eqx4Ae B1aeHLXc0veJVVbSlbd4psRZS8LS48H6PnQXdVgCrEFZu04tMjLxn/ld1Mighns64GleXv3jXgca RgZbZROIpABDVPVM5lzJV3ppxGKXJyxkCEx7YmSG+L7192aF7CJx2666/37Poh26EMNahmCXtfkQ Xkx3GfbMrTJn9nPy3VyVtJNLeBEvRu3iBLYNKpzicEOrojJJaUsXPCnLxx2d3ypGWCJkIdbL4sIi DjtPJSl9mNTriKQA65mDsISzNbiadaHGG2aYbeOqj+W1n+zqEOBpe/5GGULZawCHeT5R2jcSzzDd yKt61thf/VblJM0r3+n6EN5PxzSWsaPvkmXLVGW1PIlYVrw4JklVxUL+6IDDnAKs6pknrX2+fom8 M6lN/lhxiELszleBILNVLoFICjAsWVtYc7lp9O1QczfsNvqQYzKSrhJZ87hEkGAyqPtgKxGrzeWP WMl0WQuoLF8usmFDiUds+LoP4V0xem+ZOukB2bRhVd5ELEt4Q7aIgrnw4vaCPrH7ZflZFzsFWHk1 kto2bVwnC+q6yOfj8yx+Add0CDFivbiQn+mVSe0HXpe65aIGAfP9bPHF4MzmonEnXuWbI1zqdc6/ /Z74Fpgo9eKL+L4+hxv9iQXMM9rHKgZ2xx2qitGiIo6gfcWn8NZNekTw8LUKNSD2l83dnHDhtclh pgDcoLiX3vtnjVOAr1Tik/C2efMmeWt6L1k37ufZxwIS7VBnO+B4v248sEBHwgdajsuLnACjZrMt wLmsWn0hbD8VskrpYrhP3Sv+zD762FJ2mdzvvvSSyMyZ1vXpVcwy4vNw2w8YINKiRfECDOsEVkqO uC0sXgjvxk1fprJe8UDNtj0qVSXc1awPPAiwfa/1UrW8HTFgVXTFT6ubs0RenRbuIid+zqPUbZA9 vWbcb7KPDSTeoVJaQE23gtEHYU+bDOi0uZuACUROgPVF31FW0qvpsV/M+fVTH7oUbhN+r9bxVZme 9mfyjjuVP6GolAso53eHDBFp184SYXcpPsdc7gkTRM47T+SiiwoXYCxLl8eKTQuvmv5hZSxj2kk2 4cXfUK2qwpouwP2btC/KAu47rFY69RqVGHLvzntCVo/NIcTwjgS0LKJuBZejXn1iOilBFxIpAdYf CLncz3plmXwVskrtq0Xd763o+b4F8xs7VuS000QuvVS2vD7dUZ0s3VeI+7ZXD/zWrUUuVrHHt9/2 dxi4AeEOzGHFLnvldzJxwsOp0EWu9XshxhBerDYUsHvR38WY30q/34Yc19IhwKOatLNeoPI1iO8F Nz6Rb7PY/X1u3Z1SnyVG/N1U5UVBicsSm163HqEAtsojECkBRpzQdolly36GtauXnAwz8xnTZib8 z0+cJRVbXVJ5o6SQK56jstbhVm6pHuhKhEfdP8IR09+0VmWq9+ghcq5arOLyy1MCjO/ka5j+k8OK xXSiJ4ffZ63La7mRc9V2hoDDHV2hwmujziXAEOSssXutr9rVDJFmHfrn671Y/r3+809l7rjLsntO UFWrhPKW7qVWWaIylsOkpJOOlAAj5msLcLa4rh47QRw4zFbb7DyH+E6i6zk/biRUna+WhoO4KhHe eHEb+cclfdL9OrHmYVl7XBN5+7gzZdrRal5tPgGGSOYoG4lFEfoPVPWpEa7IFxNG4hVc1yFktuYH E70t9FDOiKNUn2nFOJ4/uY34EYRHX5gm+CS5YarayjF/9BZijKnlXYu+fH1eMJOxisYY2y9GRoDx NqjXfrYsGY+mF95AwlZYbU3dtAzX88qevcI6XHL2u3JlKgYMAVYu5m0tzpYh53aWs258xRLh6y57 WO4/85/y7JHnyVvH/l3knHOyW8AQXyRGecRusfZu/0fby5PjF6YSrPK4pq1kLQqvY5zplZlW7ban Q4C/UctM+mmVIMA2h+WzbpJNE3f0FmJ4XIoYX/psgbANCj/9yW3KSyAyAqw/DHINRD8iHQTCsb/d z1lwY/8Dgtht8vexZo3INdfI56c1k0lNWslNLXtIm+ufliuuely6tO5l/YtPh0v6yrjHXxF5/nmR 97O8SC2+R+Q5NUQHq89o9WkQ4hGDz5eawZPlk9XLUglWWPYvV2ZzCW7CJHeYfc+1Uv2hW7/btt9e 5s9aKHMXfZj3c8eAVwUfP9va2zwz5g3Lan5lytuy8pP1sUKM+eMrxmepqoUQyRczCr4ePaTGbOiC 8cX6C5ERYN0Vky2xSo9ZhZm08N49mSv5sOCGz3GOohr33SdbhwyVe258Uu4++2YZcfQFUld1vMza 56/WZ9IBJ8nLhzaT5fc9opKgGuYHb9ki8p6qCoR4MBa1UPv4rt2vVUKXGqLt1Gd4SoDfe3l/Wfu6 sorzrN9riXIFZjb77CVrM1uA+x51gUOAl/x2f7mq+zOhfU68rLcc0fJeOf3aftJj0LhCTjky2y6a 088zSes7uKSR2FdA00NvfhLfCtg1N404gcgIsD79CHFer4aYlB0jvuWpN0NDO27P3zqs3wUXtQrt WInc8Xpl1Sgx/erGW+TNPx5jCe5rB5/u+Iw7qKl8e2YzkeuvF5k6NSXEN94ocvrpllv6i+bnyGfH 7i7STA3Rft9bv77WfmWCla9hBQG+SK3dvHGX3ZyLMahQC/6GPAyEeZAQiY9uqeklYPXCOfa2EBVM rcF+wi6S4+tiQ9jo888+zL5U5SIVU/c5XUkvKhT2rI4QMHCXJRCIhAC7px9lm9erZ0mHNVBXDHvW OedXrQxT9kUESujQsn71889F1q5NfSCgmF707bepeb0QVpXp/FUbNZ3lsDMyBHjKkUp8GxK14LK2 rN8n1HQWJb4rml0o4w8+TeYdqpYD7KWG6CQfAmxnNvt86JWVU0QPtvKt9+WLP6m1jrXkqy1qTWeI spfAlvI7iDdEGfdw0tysi+vUlDqvEAiKd/gIf+jht1y17yM6jHhaJRCIhADrmc25BqBeJSus6lfu 2O/8K64uAW8Cv6rqPFvTiGCt2h/M58Wnd28RxIBrakQuUG5NCKz6fHFxWxl7iFOE5/9NJV81/N2a kqT2uWX6DJn7t2qBdVz7xxPl9vNuk/seqpFvpqoEoWwx3jkHpeLAFF7/g01VIdukwizf/FR5GDTx xf/b049KEVs/34XHC2EnR3EW/1cQuS3XvD/UO0ELL4Z5qqtRgCPXnWU7oUgIsB7/zZXZrMdKsrmp SyG3asRzzmlHP6b1m8ET9Zv79BE588xUFavL1DxJCCnm/iKhCu5ke46vLbDq33XntXKIMKzctACr v289q4X0u+lx6dmsi8xUceKezbtI1wenfO++RIYpSgHqnwQvlFDKOM713RX39M1wOdsivGCvAzMs X9ulDHcyPrjvIBheH3sb/OvHZW0LNcQYsc+wK9qFxdTe75YN78inE5TV63pZtAp35BBhCnDYPRPd /UdCgPWawbmEVS/dFsab80RXyck5LLrhPXLheh4+PFVsA5YvhLZtW5E6Vc0H1i/m9mria///Ry0u Trui11/Q8D213TdtL5U5h5wsD55+vVx6zWBBXeKhL/gozhHd+ypSZwZhe+vWXvKfXdWiAy6L1/55 zt6HSoce4yyrFGIY1P0FdzPuabxY6/evl5UMNzVCS7F2Uaupc8snn5Ehwtum7JwhwshjAQc9to7k Uv1FJ1IDiScTOAHjAuye/5trgWp9AYagb9JNixdnzPst6xq2gXdtyDtE1jKs3auVix5zeeGOhnsa ouwhvvbv3j/jfEuEt12aspw3tmontX89U8Yf2MTKlq6+YZRMmP1ByCdfIbtXruYF198qn6s1rLMJ 71eq0ts77W8om+ghIQsCj/n8uZK68CIQ5+StZTM6Zojw1jqnCOulKL1eSLhWcPLvU+MCrLtf4IrK 1eDWsgcqqvgE2d74h6qmpC24UHuimurClp8AEq5g9Q4eLPKWWpMZCyzkEGD87YOzlOu6ITasJ2iN Pry5LJiyIP8xuUVeAvN7Pp5TeL9VyYWb2qvkt/r6vPsKawO8fEOMdQ+YLkSY8w8RyvVSHta5BbHf T+fd4CHCO6UtYXdZXf3aYWzE3SUfBMOk78O4AOsp+PlKselVsIKOAb/2y/9zCPDHTw9Net8Hd31I vEJs+PXXRZo3zyvAEF93THjiIadJ/dUdUtnUWNABmdVsBRP4fOmHsuRPR2a1eFFkQzoozqrOeZQa Kt/h/veyBOGWzbYyWpSuwetcvnjnJm8Rbshf0BeW0a89zBr3UWdWSednXIALmYSuJ2t5LvBeZM+t nrsgY+rRNqxXy1YYASwx6EOA3eILF/TX56ukrDvuSFnRiCvj/7NVyCrsrCpm6yWj62Tt/6pqTB5x 3qgKr7tzEFrKJsSImcbRLb3l/VsyRPirKSqzX2Xu6/W402szqxcRtsogYFyA8XZrD7x8iR+YemRv G+T6meMu+4dDgN84TdUoZvNPAC8rqAENd3QrVbQkhwu6/qI2jmxoLMiAJCzLdf3ww6rk5OiUiGNB B8wPRpwZ8Wa2nATGdX9cNu6g6hS7xNcS3m7djLqai+k6PAv0l3P7vkfcOI7WsJcIfzbtr9aKXHoR IjwP4+pyL6afK/07RgVYL8CBGytf0xd4z+euzrcv/e8v/3ofhwCvHjSokK9X9rYQx+eeS80NhsXa qVMqI9pDhN1FOSC+Wy9R4oupTEjemjUrZfle2DBFCWKO32P/KHHJlkEAFuGwNrfK5h9tlyG+357S REQlF8a5ofqd/pIexgt4ufhsefe6DEt43czmVsUx+7ri+HJRLn5JPI5RAdYLcPgpLaknbCFxI4j2 xZp1GdnPWw0mpgRxTWXbB6peIV6L+cCY+1tbK9JfrQ2LOcEuAYaVC1ezXZIS/29ZvtgO1u7996eq YWElJUxjgghjn9jXGWpaRz9VbAPTn9jSBHD/DGj2D+94L+K8CWmwCL3c0kG+hJcL1bfz1UuRa57w ypn/tAQYFj9bZREwKsD6m5+flHv3lKUgpiJNUNmievbzzAP+VFkjoJSrRdLVpUpEEbOFaCIbGjFc WMHaXGBYubB2bfFF5jOsYUt827RJWcD4Hj7YR9++qc/AgSmBx/xiTHHatKmUs03Ud5G8g6pVntOL 8LKSwAZrWF8NDaKFF/dYuWxV3HfbrD9kiPCwZ7vHMr6dwGFW1ksyKsB6jMev60X/ThCJWENPvdgh wEsTZDmEOpLefjsVo9WLbsBiRcx25syUsCr3Meb7vnFCi7T4oiQl4sDpOtDtUUdXWc6wptl8EUBR i/EHnpIpvjuolXgSHj5BbNg9fxgFPmKVnKUyoLdN28MhwlsmbSdfrOMUPF83QII2MirAevJBvgQs m7keBy61cDks6mcb7+0Q4HVYCo8tNwEsuqCtXGSJMCxh/O6FF1JiOnGi9fPSI0+2imzY1u+6c5XV Bpc1Eq06d04tP4jYMaYy5WgLa6qUsdco9akeobYcIdWNqtV/7ab9vLBGqqprpKZKbVtVIwuxdXXD d619aN/DtvZ+1b/WrtE89hGFYfH8hHfV0o4neIvva69F4RRDPwd4vvSiPLCE8TOmMsWmqXWDv6tT L0yaO/rTcXvJ5s308sSmDwM4UWMCDPHTlzHzO+kc7ibdDVWK+2n6rCUZ8V+ufORjVA1Vc6SRLIWs ZbiH4TqGKGPurm3Jqnjt1NGz5M7qblaFqxf+eo6sOr06Zfl2757KdoZb+ZlnUnFfuJqzNUskdbHF hnkEuFGV1EB5rU2rG0TbfQDsQ9vO2mfDz9Yx9b/54BLyJhNnLheUjMxwO++iag2DZQU13PfuAh6w jP2+yEcC1epBGa7o9yaqnAe2iiFgTID1+W9wIRXS9IpYpSxgPeSOx5zx3732KuQ0KndbZCTnmSf9 RZ+H5amml8vNF98jHS7pK0OeUkKNIhuwdrFeMOYMd+mSSrLCB6KepcH6rUqrqb1RHgFusHwbFFgJ Kyxfl6B6CDMsZcsKhgA79mG2u+fNUWvrqsUSMsQXYzbmmc7FksVLu3uqEkQ4iNyQYs+p4O+9q8Ix rqSsJW+qREa2iiBgTID1tX0LzWbUv1uoeOu9OuCcaxwCvAjZuGyBEBh91tUy4w9HWZ/XVQLWt3ff k7KS0WarDHZYvfaShXBJY4Wl0ATY3vHClFvatqZjIsDvvLVClqtQSYb4HnRQ5CpaBTJ4CtyJu5oU LGO/HrUCDxX85moesGDdYE2EN07YUVZ/wmIcwcOO3h6NCbBe1QrlKAtpSLjQ3dDFlKXEDfr4fkc5 BHgVpsKwlUwARVIGnagWWVBr+iLpalML5XqG29kuL4m5w3BBY54vhBj/wqWdzar2dEFDTL+3aFMx 4gY3dR7rNW3l6i5nXLV+nIhYwB/MXigrfp5FfDldLj1W3Zawn1kVJQ/0oHawSc3VnuKMBy97tYrx 4KD4Rng/xgRYj98UU/dUF/BiCpfjmC/usodDgOsnT45wV8Xj1BBawMuRLcAfIO575ZWpOLHebBFG oQ0kcSGBC67pLM2RRGVnSsGCTSdmIenKW4AdCVzpJK6GA+n70F3UERDgdW8t9i4tCcuX4usYKYgJ uxOzSglPlf1u84gHz5ug8iXYEk3AmADr1W2KmUKAG07fR6FW9NCX5rEAR8BDG14F+yEIAZ5/hCo6 APfymDHe04wgwogFYxtMacKCDmwpAitWyIadf5rpdm6qVumi+HqOEmRB654x/H+sMqM94sFrV1ZG Znul3vZGBBjiqdd2LRa+vpISxLgQIe/ToadDgOfAqmAriYDulRh+6uWy5RQlFsiUzlVGElnTEGEU 7+DiCyn+SmC/+vmvvMWXi4TkHKP6NEU8YzDVMTbxYFWkQ2aqpDotHvzlRPUStjlaK1eV9JDglx0E jAgwpgrYAlxKEhVuLH0ucSFxn54nt3EI8LsoHMFWNAF3XP6Df9yccitjkYZ8DSKM+cB55gLn200i /q4EdvMhh3nXdab4+upid9nKWJV4rJ+ckRW9fsapvq6bG8WPgBEBRtUrW4Cxxm8pTa8nDZcTYpD5 GoT7KTWlQy9ByQUY8lHL/Xfd+rUeeIMHpxZXYCuMAAqUuFY0+uLYk/JO+yrsIMneGvc3Xuz19XVj FQ9e0S1zDeFVypPEljgCRgRYrwGNsnqlNj2hK5srGnVkcUPixsT2E9TqMboAv6nWUi2lqEep1xDn 77utX6sYQoRWL7rtkdGyecvW6CNGFr5LfD86QFnDtHwL7jvMBdZLVuK5EBtXtJqatPWNw52lKmt3 oiu64FEQ/S8YEWDdRRTEm6k7AzLbPEA7aavN5Y84xHesWkcV4hy7pI2IjC99CkhY7j48UIt5gEJ4 j2h5r6z8JHuGdSQwzpsnglrOmgBj7m/9R59G4vTieBK6pw33dxAv+2XjoKYmfVur1nLW4sGbF6ha 62yJImBEgHWL1Y/L2A9xWF16BiQm57ub7SbtePZNDgGGOxo3KCxztvwEMIXLTnjT4/lgGGQpQAgu Hpq6KxFjp5AxA+GFAM94q6EISP7LK+sWuL4pb6g4+b6qGIMmvp/tuKs8PVStNsVWEgHdFY3nQyGJ miUdOIgvf3B3hita1jMrOgi0UdmHEQEudQpSNnjuDEi3dW2LRc/DWzgEGD/jRi3GwopKR5bzPGxR hLWrv0wFaf16xfF0IfY77Wzuog8tAR43Y1E5Efk+FpbT699ErQjlcj3fV/2veImF7ysu74Z6ydvY rbmrXNEbp/3RIcLfzVIvaqiexZYIAmUX4KCmIGWjrycDeSVlQWjdCVhd1MMuSMstESMjx0Xo0790 UfS7pKQfPm7LVz9OoeECCHBUW7/n5wusXV2AsdQgsvtjNYc1qoDVeekhkthZwWrVJHetaEGSFlsi CJRdgPFQsR+msJ6CbrCc9MUakIihuywhHu4KWE8PzLEST9AnmID9uWNrujhCOIopDerG4l7ztbrj cLmi1X3pz/Xn1sjzF12jnkXdHJ+FKot4/vHHOz4D9/hdxu/c2yxQBS7sfX2sFrRHVTR8wl4da+q/ HnCI72aVHHiRulabKXjy5bC0m8YdJilkumJpRw7m28unqkpx+oINKFvJucHBwDW8l7ILMOKH9sMF 7rcwGuI8upsbb73IgkbD317apbHDBb1h6bIwTiO0fZpeG3ek1oduy7SYxdG/VlWfIHYQPojgrKZn WF4Kt6dCz1ov9/+jUIst0piyFlTZ0rUnqGIlmvsZa/3qTL1yGUIbWAnesdsKjtOMh81fr5f6ccpL ooswreBEjNayC7Aepy10FaRCiOOtV7eiIMJ2THjM7r9wCDAEIDYtAmvjIiPZLbz4GR6NXA82cF6v Fo2HyMJSnfq732eUAy23sJZ6PAjzElXrGqJczDjaeMTRDgG+5cLuabZY1IItGALuWLDfHIJgjl76 XqaPv8kpwNMbMxZcOlbjeyi7AOtzgMN+wEAovAq01+37R8eDf93IkcY7wu8JRGFtXLj53QIMb4Y7 iQ1W4gd33y0zmpwutT/ZKfZi60esp+z+M1nYspX4HVObjz7WIcD3qAx9ZuT7vRsK207PiA4j/FXY 2RS29fJP1gqWKXRYwavuL2wn3DpyBMouwHpyDdb1DbtBhN1VcV4+u61DDGCNxaWVLsD2lZa2Nq7u XbA9GSunzJTpnW6RMYcdG7jYvrDbnmm39KC9D5W7jmvp+GBqWb/bBsrsIS/J3GH5Py8/OFye7TU0 /Xn+9kdk8NlXymPNLpfBp1yYPtaIxr8r+lom/M9P5JVTWsi0vk9kz2hGCVTNBb1MHW/izGhOmYrL PZLtPPV1xPGSg2dDnNr0Vy7MtILjdAE81wwCZRdgvQhHEMk6fvoUblFdhJHM47ZmvkQhhDi0iKyN i+Sgi68aKP1a3yQvHn6SjPvvHYsXqv/dTcYedLhMOKNaZl1/g8zp85gVYx0+4GVPVzfi+4iN6vO+ 9aSlQuYJ5+tyWPXIW0CltNreg+Sl1tdZ1/vyr/cp6HpHq0znAUc2l341AwXuz/Q5Kpe8ewqSqCQy rniUr2cK/zvyP3TPTdzm/dfNnSebJ23nFOF18fHeFd5jyf9G2QVYz1AuZh3gYrsEIgw3qX0Dui2b mXvtJVtjssybibVxD9m3q9S9PEYmXnujjDz6tIxENj/u2cnbbS9TDjtS5l9xtZVw5SeRCWMEYotx gw8emnacGQ9UZLS6hRg/l+PhivGy9LkXZVb7DjL+z0f4FmSIce+/nCGXtutjXdOcPx6TKcK77CKi YuUU4mLveO/v6c+fuLmhYbHXDT/BKcBYwpAttgTKLsD66kXldgHBmrFFGNNY3KKBhJqwp53EZaRA XD5+eqjUNm0u4372S9/iojNFkhUSlCC2YXoYMI70giD2SxYyX8tdXAWxX6ysNXXnXXwxg2v93ye2 lU93/lmmCMM1DSGGm1p5BNhKJ+B2Q8cpGxpX32NAX6cAY/lCttgSKLsA69ODyv1wtHsJyV94SD+o Ch64RRiW8KbFmWUsY9vDBZw4Xj6W93lIJh95gi/xcLOb3rixJT7ICDbxImP3q+5mROjB1EPWFuNp SkTzegjU/N+PXAU5MlzTiq906CASl3BJAWOvXJu6M/jLFQYL6vr6jFJTN/XpSPh/rCPMFksCZRdg ++GIJB6TDa7NVt3He841naKK4lfS8oQfv/iKTG7SLL9IKItMFxJwQgLbKrWKT1ReWhBb1V/yMN6Q CV9ub4s+trep1Yw+HTZMFp1/voBZNjGeoviuVJ8tP/gvb2tYL1epXhQtMa7Ql8VSnh36+Ah7JkYp 5+n1XUylXPbK7xgHDhqsof2VVYD1t088FE03xBBv61+XteADHpgmLLlycFn/7lIZd3VXeW0355zo XJYaqkfBpQzB/WKGKpEX0eaV+W5ahG1UuhhnYz2tQYi//sEP8gsxRBkLOWApwzjNZzc4dvSiHGEV Awrr8uDNGT3kDBblCAtwmfdrTICjlADx7IR3Pd3ReEDCfYi5rElpI2+8R4bvd6gva3fmAX+S5V27 hhq/LZVr3Zwl8uq0dzJ2g/CG/qC114LW3dF4ATO5Og5e7jC2EPbIJsYL1BhcrT7f+hVjVVJTlLXN lp2AXsvctCeumH56augtTgGer7Lm2WJJoKwCrJehRDZilBpcl3decJNgbWCvh+FsZWWgilMc2xdr 1lnW7pidfppXeGcdcpixGG4xbPsOq5VOvUZl/WqPZ9/OWM4QFrKdPV3OTPxc14exBY9LLvf0Iojx D3/kzypGvFh5K+iizqSOsrR6noDJl7BixvxjL45jIlYx4CL4HWMCHOTSdUFxhXXU69HJgkIPWS0S ZWFEJd6Z77pXvrNMnm/WKutLhX2NU3fe2XItx+W69OuG+F5w4xNZUeiZ717lM6MiwPYF+LGK4aJ+ V30+zJe0ZceMMa84pi+P+cZ4MX93J2IFOW+8mPMp9DtW3FpPxJqmMuXZYkmgrAJcrjrQpfYE3pDv uejmrMKFRBq4ZqM6b3j6rCXyWNPWMkFl1uaK6WJxASQHIS4Z19auZog069A/5+ljBS6voh0Q5KgJ sH4hsIrRR7n6cLoS2QU77y5rfrJbfstYTbOTGJVdDXNM6i9j7nXDwzxuEPu2ztedCR3EjrmPshMw JsBxWOXluVGz5aHDz8z6AER8GAsLREWIMaWi1wVdBIUesj20J+yyq4xscXFRCweUfXT6OOCjL0wT fLxatkId+sM3ygJsXxMWecALX77pTHW//K1MV96bjSqMkjGFSc+gRtKWmipWyU2vER+3TGiM2TVj 9nCKcCV3ZoyvvawCrM/TjMugx0O877+fzbk0Hua/otiEqQbh7X5FD0FRh2zCi3NE9vJjwydlFSxT 51/KcXMJMB5U7ilJbjd0HATY5gNPBabHIR8hl1U8fu/95Zljz5U5SoxzCjEs4got8KFXxApzVbZS xna278KFTgEOg2z590kB9sncStK6pndOkcODEUIctkW88pP1Mm7GIuk2YKxcemVvGbync3Un/eFc t9vuMqNrN5k7732Zu+hDuWPAq9andu5y62c/n2fGvGGJ9itT3hYcO+hmXw+OMfjlmb7OyT5v+3qy Xcfr81fINQ9MlJM7j0x/TuwwRE647kk5SS18P+6NFUFfTln2hzKemIOdS4gn/n5/+ffZnWS8KjiT U4ixGEmFzSfWa9LHTYAxwCjAZbnNQj9IWQVYH/Rxi7vYPYFSdneefnVONy9ixKgIhSkmeFAGLcgd e70oJ7XrJf/608kyQWXFej2Ex+/w/6TPCWdL64795MyOj8uJV/WXYy7vl/HB75te96ic2/UJufT2 oXJV92cyPide1luOaHmvnH5tP+kxSGVgBtywzxYdB1jHOLptT89z8DqvQn5XfcMTcuwVqes/snVP 61hHtu0tN/R5OeCrKe/ukDiHsZZLiCcfcLDc2/I2GXV4C9ms8gKyijEKe8SkHnqplOMuwIwBlzoC ovF9CnAR/YBs6aEvzZOeJ7fJm2FsPxgx1xPTTJD0VGwJTiQTwXXWpVnnnC8AU1tdLjf0nui5kpBX JrD+OxQmqF2wuggq4X0FbmKcE8IW9gcPUHuBBv1f/N7eBi9L+K499xdeDPf60HFyQecijDgxhDhn pS21EMY91/e1hDirCGP6UgVkTFOAw7tfuWf/BMoqwKZWQvKPo7AtIaQvvjxH+h3RLG/GsW6hvFR1 qCxausb3wSAgWEcZC0jkWp922rEnSYeuQ4oSXrcwY9EM9/QM/Lxs9Qbf513ohohtQTTt1Y/0NYfz vTj4+TvG373PLXQs3JAUAbZZYxrTUmXJ5hTi05rLXdf3yx0jxgIQCbaGYy3AqP2sZUF/N5XTkAp9 1kRlewpwAD0BIR5ft1juPuefOWPEugg/cNQ5Aos2X4Pld9u5XXMK7+vKahnWtVdW4UXVMQg4pldB cOwPwgCwFiFM2abp4EGF68PyftgGAhlkwzmhKIa+SpYfMQ1im9PVNKRbnpon4GBqwYYgWer7gkWc s7CHCpO8dkkHubvlXbJKJe95WsQJtoZjLcCb1GIx+jSk2SqrnS2WBCjAAXcbHuY33DBYbjvpEqu8 5dBf7ecZn3txlz1yLhLw4Uf/kX4XdBRsl7U6knqIvnV9J/lHz/EZ4ovsX4irX2GxaswqcfUSQt0S hViW2vACgAdgNtF3iyteIFDRynYt42VAf5HQ/x+C7nZT+7WkcYyoud9LZY1lIFHDO2vd6T32kKc6 95RBarxmjQ/DGo7xXHEvhro3Lg5TIh3XsF5V5NMFeIEqP8oWSwIU4JC6DVODsBSeLSZP7XWg4yGI KUNe9Yk31H8pz7e/OWeMFw9TZMC+N3uhuMUFP6PWbbFxZuCwrV0vK7PYCmZwL0MY3TFY9zHwYMR2 EFU/HgK/3Qce2CfY4BpyiT8Y4qEcprvd73kHtR2KemC962xCPOMvh8oj194ni9ULo6c1jClLCVrs Qb834zIl0h4LG1c+6hTgJarkKFssCVCAQ+42xE2HnXdVxoOvx1Hnp8UZogOBWPT86Lz1muFWRGY1 BM09xxWWYhDL7mHus9cC9/YLQyHIIGLuRRF00YXFDasaLyylvDQUck72tugbvGzoD2P3CwGS0pIU J8Y0OcwJzybESOB79m9tvK1hVXgmKZW09BdBvJTFqW1cfDNXQ4pTh+U4VwpwyB2JSlnuhx0qVVWr Oaj6w75/k1Y5K24hsQZxPTQIpNuStGO1pV4OXOi5XLZ+V4/JJbx4cYiahZnPQsdLUtwWb882FlDQ A+MyW6LW63s0lhfadpZljdW6s3oFLfv/1Xfj3uJcivKrBS2dArx6UNy7o2LP35gAx60AejEjxGt+ JuozX9HqvrT4nnnT6KxVtmCpeJW6dK/wU6xb2OuaEEPNZRHiwZVr9Ri4jbNZvPi9V4x1YU2Ves43 Sn2qR8AJLtWNqtV/7ab9vLBGqqprpKZKbVtVIwuxdXXDd619aN/DtvZ+1b/WrtE89qGzwNjUk3T0 hzU8A0kZu8iYzjWHeNqRx8vM/Y/2FmEsexjTuHDcF2PYNEv1iR4Drp9czOOJ34kAgbIKsG61BeEq jQA/z1OAheFVpQjie/WF3S33Liyqf/SdIk/tc1iG5Vu3/Q5WEQ+vRRJghbnn7YbhuoUlnK2MYzYB yhY7hvBmjadaIqmLLZDmEeBGVVID5bU2rW4QbXdXYB/adtY+G362jqn/zXskYYzCUveKF+P3fhPc ojpO7fP6YsaMrOUtp+68i9QdfYa3S/qII2I5Vcl9D8WtHzfUKc+ELsBfr4j6EOP5ZSFAAQ54aMBN 7JXsgkL6+nrCiDsNOOCEDPGd9Yd9BQ9Erwah1UUR7uAw1zLF8ZCg4nZJu61YCLJX9nRO4U0bo1VS lVZT+6rzCHCD5dugwEpYYfm6BNVDmGEpW1YwBNixj9yDINuiDuAS9LSsgIej793hZQ8vfdnc0rOq /iz1/0/FgN0uaSzsELPkLEzJs19icT/FrW2dvL1TgLfFdzWzuLEP+nwpwAESxZQPrwQXVMHC39Ag ahAmTFFyx4axnR3n9TotfTlHPEDKVc7TFiD7oWVnjeJakEDlNW3Ir5sW7ufSBNgmtTDllrat6QAF 2D4CLGIkZXllbof5IhTgEM27K5S2zLYE4syddpI1u/0yQ4S/+81vRBrGd94DRGADPUQSZPimLJf2 pXqOaNbv5un7lOWwPEg4BCjAAXGFdetlPcAaRqwNDa4uuJ+LEV98X89MRpy23M2O7yI+CjFyx4qL sgg9XdAQ0+8t2lSMuMFNncd6TVu5ussZoPTjFGgBuzkjTu5OgoMlhd8npSFb2ms8T1MW8Cd7/CpT hHfeOTYirHuRYA3HqW39eKBDgLe93SxOp89zdRGgAAcwJLKJL6YM2XFcW7CKFV/EUHXLy2TBiFff WJXhloYoF2sFOpKo7EwpWLDpxCwkXXkLsCOBK53E1dCp+j50F3WJAoy9w/rXXZl238TtgZ5r+MMa flPFed2emimK88dqXWm3O3rLr34deXe0+z6K20tT/bx2TvfzB3cH8ATjLkwRoACXSD6b+GIBdbvh pofFVKz4Yj/6wx6WZhiJV35Q6Gs6Q3SQoGTyZcDPOYe5jdeaw/BUxC2xJxcjxIa95g1/sJ2KRbpi wl/9QpW1jHBMWB+/GLum7qNix+Tndfs7BXjdyGJ3xe9FgEBZBVgv/xZklSNTHBHX9XLTYdF0u+EB ff7tY0sSX+xLdz+biFvhQeWOfyLxKgn9WOr4geWvj227YEmSMv2RGOiV3/Dh9pki/NneSiQiupCD 3k8m7qOSxpprEQYrFozfscWWgDEBTkJ1Ia9sZyw3aDdYhufd9KIM2vvQghOu3CNKnwqD6T7lbF7i i4dXkqy8IHi6vQPweiTpBQXrWnslaK354Q8zLOH630dPhDFe9TBO3DLYt34y1JmANfuwIIYt92GQ AAW4SPiwCNxuOd3yhfhecN3Tnqsj5ct2dp+SybgVHlpuyzdJcc4iuz/r19yZ6ggXJKmmNC4c4RX3 2F/rIcL/OfKESBXrwNQ/XYDj5qH4z+wLWIIy6BvW8P4owEV2AMRWfwjBFY1VZ1AycvadPeWms7rI 2B12zHhQwWrONdXI63TgLdAfHOWyPHEcd6Zz3ArXF9m9JX0NiT26xyKJIowsacf4V7Hgz/7rvzIs 4SiJsD6W4YqOVVNzfb+Z/BNWwIpVp+U/WQpwfkaeWyD+m62gfbbfI6MUbrxCm1uAC/1+MdvD7exe kKFc846LOd+ofQdWr17ABP8fN4srH9OMl1Alwp97iPDHZ56bb1eh/x0vRfpLbNzqerunH219/Teh M+MBwidQVgHW6+smIQa85MorfYuwPiWp0G41IcB6sQJYcxTfQntNLNezLsKICRc7Vavwo5fnG24R xjzhjR4i/Mm1XcpzQlmOoo9nzAOOW/bzptf/yOlHRkdQOAenAJfIddX99+dc3g3WMBZUKKW5BTjs h7i7ulXcklVKYR30d1ERTHdHww1arhBC0NeSbX9eIvz1D36Q4Y5eNuylcp2S4zjuHIrYhVGw2pFW /erbWpV5vjlV3Ict3gSMCXDcXECe3fzttyJbtlhv0916j7VWObrruJby+H5HyfS/Hm0tyJCtrnMh wwaZtOVyn7kTVZhwVUhPeW/rjgnHLv7oA4FbhGeqF8/NLhH+/Ce7yudLP/Sxt2A3cXtzwn6BDfTs Vez322l7OAR4y/wzAz0Ed2aOQFkFGCvI2EISe5cmxHf4cJH33stYfi+M6jq6KzOsN3i3pR27eZLm 7qO8R3ZnR4fVh3lPJMQN3CI832Mt4aV/+EtZ3b9u6xfenVi1Vfc7xNdaiIGrH8WqC3OdbFkFWJ8n GVm35qZN/qZOzJ4t0q6d1I2Y7LBOw3qxCLuAAKwCvUYuErDiFieL+l3pniechDwIN3O3CK/0EOG5 F11Ttq7SM5/DXj0s8ItSbma39Vv/dsfAD8MdmiNgTIAjawGMHSvy5JMiEOJsbe1akS5d5KtmLeSa awelBThMd61eihIxxaDdaLrAQ4iD3r+5IR6tI1cCZ7cI13uI8MInRobeMZiLr4duEF6JVVvawWH9 fjlpN1HF5WN1CTzZ3ATKKsC6Gy6yAjxHzQ9s1izlXlZrpGY0uJ7VHOBtZ7WQ2Yc1lSuuety6ycO2 GN1x4CAfJu64bxIts6g8CPBio4cTkhgPBmt9nvB0xINdIlyv4sGfvLMstG5xc45d5rOyfr+bsoND gP+z6J7QeHHHZggYE2BMSYpke/NNkbPPFjnvPJEXXrCSrBwNrucLL5TFTc+VMQefZgkwLNJylBzU K1IF9UBBjEzP0o3si1EkB0txJ4UERN0yCytsUdzZBfctvWKWVzz4vd8fHFqYw12bO4y8jOBIeexp 0fm0fkMFHI2dl1WA9cnwkRXgRYtELlAl31R8V1q1EhkzRgRWL1qD6/mzFufJawefnhbgcsWz3Q/u IFzesa4OFI17qKiz0BMS8TKVtKlJNhTMBLAL03jFg6deU1MUv1xfcnt0wDpWrX6yc86vmoK0bvH9 sboEnqw/AmUVYD3LFtZcJNvy5SJt24pcfnnqX4gx3NJor78u31zbQaYfeJJM3e9YGfvnU6VPj+fL ehnuKRXuN3vMO/Xb9BhZGHFlv+dRidshwU1Peotddq7PTsN62Pqawu548PLGewfqPcIzRvfooPhJ rJIJ1epG383YyyHA6ybt65M2N4sbgbIKsD4lILKxr1WrUtYvxPfii0UefVQFtD4WWb9eZM0a6fvA q3LdZQ/Lv8/qKsNOu1I+X+gxrQEWs9pWYE3nSuYqYrSgnKH+gMH/2yKMBw1+9rNaklsA/HyniNPl V3IQcCcJJW3RBvvSN69eLdN22cWyhOd4JGSN6BSMdYcwkB5fh5u/kBfSSAzWBU0zrN+v1k2LxKnx JIInUFYBhnjYsS+4PiPZ4Ga+Rk2TuO46kdGjRd56y0q6khtvlPprO8mIoy+QAae0t2K/b0xTAgux RbIWhBvbjhgh0r17ah89eqSEOODmnlNqi7Duos4Xy9WzqoOKJwd8mRWxOz1WiUS+pDY9M3qdS4Tn qOU6Sy3Mg6QrWLuxznpe0S1DfD+YdW1ShwSvSxEwJsC4WSLZYLE++2xKTNWKL5YL+pxzLKt4/vHN ZeKfTpap+x8ns49tLjJUrc+5YUNKqOGyPlcVnce2+Bc/Yx8hNS8Rdq9clC3OjoeVbkWX+vAL6RIr Yrew2iqlL1APHVbwAg8r+I4bBhftKvZatSsJcd8Pxh7AaUcJfwqUVYDB0n5DxUMnsu1zFUd98EGR Fi1ELrvMEtMvLm5rJV7Znw3nt0yJ7Uuqvi2EVmVGW6J76aUp17WevBXShbpFWH/7t/8fIuyOgem1 niMbCgiJWRR3q/dHZD1DAYCDK9pOyPrSJcLjDzzFV+gEL4u6dwdeNfeLZ2TzS7IxRF3n6Y0d1m/9 ODVNa3V407QC6E7uIgACZRdgPfHEWOYn3MZwNeOjSklasdpZs0RmzBCB+MLy1cQXwvrGCS3S4jv3 JCW8ENtLLkkJNL5bo7I5IbwQ5aef9ldNK4AO9CPCeCDZIgzmusXFOb8BdEKJu3B7JJIaCwYmOyt6 kUuAN/9oO2nT5dm8BWAgthi/iO2Ck9vtHMvFLlxTjrDwwswZKpTFlngCZRdg/W21HHNnM3oQLubH HrNiuulkK+Uak1NPTcVuIcItlXXbYPlCaNec2zItvmMPOcOyhi0Bxgcu6j59RFBB64wzRNTqSJaw l7EhCevyPtMd8S+3NYz4IsRXn6KRZGurjPgDOZRuBSe5Bve6kSMtK3iKR3GOIWohk1zZ4PrYhfC6 E67sMR5Ih5RrJx5Tjma8dlW5js7jGCZQdgHWi0kYs77gMv7Xv1LWqi2kiNui8AYEFIJs/179O+3o 5mkBXnyqKtCh/c0S8U6dvo8Zv/++kS51u+G83NFXPzRTLuxRlxZqxn6NdJXnQSvFCsa0pCk77GCJ 8FKXFfzZjrvKhbeP9YwFu7P23eO7x7NvFx1DNjkKts0+0OF6/mjsPrG8DpMM43zssgswYpKRWBEJ 832RpQwRRtwWFu+oUSJt2jis33XntXJYv9+0VdvqAoz/hwhDeOG+NtD07HL9wQR3P2K8iJlhysvg Ce+n2eNvbNEioFvBkS1UEwCy+ccfbwkwSlRuc4lwr2adxauwjZ617xbf2M6hXjcyI+t5/ce1ARDm LuJCoOwCrK8IY3zuKeb39u8voqr1yB13pBKn8P+awM7/2znZrV97O8R+7WIdBnoeDyy43/DQBlN4 Frzi6/qUlyBrSRu45EQeUp8njzhnrApIFNAjK7p1SydjrXIJ8LLGv7OSqvTm9g7oAgw3tLFckgKu 2WvTtRNVgQ0V77U/9TNPK3GP/HrcCJRdgCEW9g0UiTdXWK1ImkI28/OqqpXmlt56yaWCmK+d+eyI /epWMKxm1JCuVW+vKNgRwaZbyXi4x/WhFUG0gZ6SHsuH1yKJbf1rr6UFeLbHlKSO7fo4CmjAvewV UtEz/ePGae54VSdAE1/r/7+cF7fL4PmWSKDsAqwXi8CNFYmGQhr49O6dSqpqENcPzrooLb6IA2e4 nm0RvvpqkTrl0sXP//53qihHxBosY/uBFbtpGhFjGebpVEI/ba2vTwswXNHuwhzT9z1K7EQ03SuQ S4TjlM8wadKgTPF9V73Es1UcgbILMKYP2DdS5OagYvqRloA149iz0gK8olnDPF+v+C8yqlV2p5x1 VsqCRoIXpjZFqFWCZRUh3EWfCtytutAkdV3m2fvumxZhd2GOLT/8UXpKkntVI3vpTzu3wQ65xGXq 1sxpA2TzpO2cAow5wKoGNFvlESi7AOuu0MhUw0JC1kwVd5owIR0D3tiqXf7kK4gxBPuZZ1IJXbZ4 w4pGKUq1eEN6JSWDY0tfSzjJsUWDiAM9tD5TIKmxersqll2YY8svf6nq8qnHUcNnxFHny9DJy60E Qsx1R15D3F9GFs9U6/m63c74ef1rgY4f7iw+BMouwECjv+EbR4WY7V13peYFw43cUNHqvdPPzyy8 4bZ+UYijc+fU9yC4+C5EGFOaMCe4fXujyVk2Wz3xLTJuf+MdH90T0IurJHVO8Co13c8WX/y75s9/ dggwpiTd/WRCamNv+1pW1qrngZf4rlbuaLaKJWBEgHV3qJFiHHZ3I+47cGDKbXyemt8LCxhirCzY 2r+emRZgFOLwjP/ie6gb/baKZaMSFmLIffuKvPpqSpQx3xiZ1oab7sZL6uLvhhEHenjdS4Qs3yS0 TYsXy7sqWRGFONDqJ092CPDMPfaQrT/4gUOE771YzUyIe9u0WF3rbzPFd8oOIrER34VSU9VIOSfs T5XULNQ7xv33anHW8cr2d/fvG/ZfVSOO3cd9DOQ4fyMCrLvY3OvZlo01ylFiEYXq6tQ8YFivKMKh RHNr20tk3EFNLQFGFvS2S1P1oB0fWLmogGWvdmRoDrAfXnrFIDzc2aJPQC+xaKxgTcCY7OxnLE3o dkHDCv7YlRFdV3WCZIxXvDRHqeVwH3/7QS/ZOnn7DPH9buouMXM7Qyg10R1RLY3SIpkS0SpNkRfW VCmxtkU4399TnYnv6PuIUheHeS5GBFgvOGAsxjVbubdatUqt+4tpRHb8VsWDVw0eIRMOPFlq/3ii VQXLIbytW6csZogvEq0imPGsDxg9izQyMfcwR3RC9q0XrMm3tGScLtntetbd0O61glEfenLd4u8v b9iw1NKgUWlYRAHr97qb+v22t5p4upy/e+MgNeNiRVSuwOd5uARY2bfVtsA6xNjeXUp0q2EG5/t7 w1cowD67IojN9JquRpYNQ9LV9deLNGsmcuWVqaxluI7hNlYx4VHTlkv7Kx+VJ49vI+8d/jeRv/89 9UHBDRTsgOWsXGjW96L0QPDoHJ11kqsrBTEuo7QPPQ4cudkCJYJaou45XXhRjGOh+uB33+y+u8MN PfZaFRJC69BBRJWwFDWFKTINlazgStYzmFVt523T9vCO92KqkYoHx69lt4Ata9dSWmcbUZ0S4Hx/ T0s2LeDyDQu4nY3OSUV2MtbyxSpGKCHpKp4x9KFXpHPb+y0RnvSEiueiyIYd0125MpX1DKsZKyYh 7hvhphcxYPw3wh3lOjU9cz0pcWD9Ehc0beooxoGSlPVYoOHwwx0CvGSfg2UbXpTx97+r+y1CbePi m1NCa8dyV3TzFN7NtTvFKN7rBdgVq9UEN5/A5vs7BdjAgNYfLlF0iz7S/j6Ztc/h8sohf5ePOikr FysdYRUlxJ8efjg13xdxY7iwsYIS4skRbcZXn4oolziclj5bIGmVy1CMY85BB6VFeKVHRSx9WhL+ f8ANqmxshNq7Y05MCe7842XbvOM8xXd9ncruhqs61k23gDX3Mq4pq4u5IWac7+8NXOiCLvMA0R8u Uah5iwn9iLXh3zsvulOm7n+cjPnzabL5TBUDxhzfDRtShFDz2RZfxIPhkoY4R7TpCVhR4BxRTJE8 LX22gD0XFv/GfT6sDfvrFSvUOvSN08sTbvrRjx3Wry7Aa3bZw5oPHJUGL95n43b1djU3TDdau6Bb VE63xPPIlYSFeHBDvFcT0++TtPL9PfUlCnCJXVTo1yMzFanhxDHf0n4pqLngDkuAxx50qrz6l9Pl iqseF8f82alTUysgISaM+cMRy4C2Xyb0+b8Q4qQ8uAsda3HaHiKDmK97oXl7bGIVqyS9SH2h1t+2 lydceaKyKLNYws+c0Coy1w3+nfuPzyq+9RN/IV+tmxanYZfnXN1JWF5JWdo0pYxpRCkRTk9j8phm RAEu83DRpyLpdVxNudr0uHSPs2+yBBjTIG47/3Y5786JTvGCyxlzhjF1CWsBr11bZnq5D6e/THjV z43EIhiRIhadk8H4h8hmq3uMZfmS1jA3GAlYyJD+5hI13c9DhPsPis7ymUhsvKW3Cj15FdbQf4cS k0tV8ljsXdBJG3HRuR4j05Bw+fpUJMQpsZweHjom5zzaVkfvv3eU2b8/XAad2E7O6/yCeE6VsucR wwKO2FQk/WXC/SBPmgUVnVspuDPBKkjZBDip87g/uPtutRjQPCvLefNPf+YQ4Tl7H2r0uaD3LLxI 8CYNelxVwcslwHPUdCNkSbORQA4CZRVgPDww7cgWW/dDBgPbpHvNXokGAjzhwFOsLGj32qQOllu2 iCgXWtRc0DjHbC7MpC5xl7S7XPcQGZ0xYAIs5vtqVvAjLVWVuYg0PL/QH9OfO8pTgK1kLApvRHor +qdRVgEGjlzuUdN1b+2Fv3s16yx3Vt8qZ9wyVuKyyop7qOnL2kV29ano3x/GzhAzBbBwhv6SGqcl 90oFt/mkky0RRk3oYWOisbKYXtRm1at7OgR4wagD5YZe91kGBhsJ+CVQdgGGhasnYOkPmChkOSLZ qu11T0n1DaMsN3lcm/0yYfPFwzyuLxNx7YNSz1tPoqu40IHKkP52u+1l1OEtxGi9eK0Tbc9dzeDJ afFdU3u4LJw/0nKRm8pfKXWc8fvmCIQuwHZWJzI77c8/BsySM7qNz4hzdXx0Vnobffty/v+1/WbK 6ercmt0+QTo//obx8ynl2i/Uknla95wa62sphUNcv9tl4BxlBU+y7pPWvSqv/8acc43c0vHxyI3b AcP6yzuvHi8PDBkauXOL61gP67yjYNTlkvfQBVh/i8+WWMLfZ76MkAmZWGPgFnLgvcAxUOwYiHod dQowHnIJ/5x667jEX2PS+5DXl/z7lH0cfB9XvAAj8xnxEa/P3KXr5cq+0y1xGDXjg6zbZfs+f+/N VedCrvkZcRyREcdAMsdA1KfthW4B5wtvAxCmzJicfpTvHPl3EiABEiABEgiagHEBxgVF/S0laOjc HwmQAAmQAAlEQoDZDSRAAiRAAiRQaQQowJXW47xeEiABEiCBSBCgAEeiG3gSJEACJEAClUaAAlxp Pc7rJQESIAESiAQBCnAkuoEnQQIkQAIkUGkEKMCV1uO8XhIgARIggUgQoABHoht4EiRAAiRAApVG gAJcaT3O6yUBEiABEogEAQpwJLqBJ0ECJEACJFBpBCjAldbjvF4SIAESIIFIEKAAR6IbeBIkQAIk QAKVRoACXGk9zuslARIgARKIBAEKcCS6gSdBAiRAAiRQaQQowJXW47xeEiABEiCBSBCgAEeiG3gS JEACJEAClUaAAlxpPc7rJQESIAESiAQBCnAkuoEnQQIkQAIkUGkE/j93WZf5aHs0PAAAAABJRU5E rkJggg== --_004_E045AECD98228444A58C61C200AE1BD81F881691xmbrcdx01ciscoc_-- From gabor.sandor.enyedi@ericsson.com Wed Oct 3 08:26:52 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6CB21F841B for ; Wed, 3 Oct 2012 08:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uZKAxDodC4J for ; Wed, 3 Oct 2012 08:26:51 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3100F21F86BD for ; Wed, 3 Oct 2012 08:26:51 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-82-506c5939d968 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 61.8D.25676.9395C605; Wed, 3 Oct 2012 17:26:49 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.2.76]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 3 Oct 2012 17:26:49 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "Pascal Thubert (pthubert)" , "rtgwg@ietf.org" Date: Wed, 3 Oct 2012 17:26:48 +0200 Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeA= Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra5lZE6Awe+zWhYzprxjtLjw5jez A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxcMk69oKFKhXT5x1mbmB8JNPFyMkhIWAi sbJjFSOELSZx4d56ti5GLg4hgVOMErvfdjBBOPMZJb6s3csKUsUmECyx/cEGNhBbRCBS4t7D nWA2i4CKxNnnt5lAbGEge9bhO6wQNaoSK+9vZIKwrSQ2ne8Gqufg4BUIl9j3ywkkLCTgIzHj 90xWkDCngK/EySXmICajgKzEw7UWIBXMAuISt57MZ4I4U0BiyZ7zzBC2qMTLx//AFjEKyEh8 WHqIDaJeT+LG1ClQtrbEsoWvwep5BQQlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzCuYmZ OenlRnqpRZnJxcX5eXrFqZsYgfFxcMtv1R2Md86JHGKU5mBREue13rrHX0ggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVAOjLR/PPGPGCyGyz0wF8y9N79VRqbsj5N3upv+wM/LppxcLmtZaHJZ1 uupevV1kt8KRkpztt+rYV9azs+5/r9v1wOT3vbLq7DdKTt2XbirMZt14uPfUsj/rA2uarj7q uNQ75xUr+61/HxPkjEK/x1wse+NyepbKpfyeL+WZ2s/Ziu/189yXOHpXiaU4I9FQi7moOBEA hWFIt10CAAA= X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:26:52 -0000 Hi Pascal, =20 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 t= hat the phrase "ARC" is what MRT calls "ear". To be more precise, ARCs seem= s to be special ears, which must meet with some extra requirement, namely t= hat you can get a shortest path along a well defined order of the ears. Cou= ld you please read through the MRT draft and help me to find the fundamenta= l difference between the concept of ear and ARC? =20 Gabor =20 PS: No doubt, there is some difference between the two techniques, since pa= ckets leave the detour when it leaves an ARC/ear (if I understood that corr= ectly). 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 t= he endpoint of the ear. Actually this is a special case of what we call "en= dpoint selection" (and currently working on); MRT detours do not need to en= d at the destination, but packets can be put back to the shortest path at s= everal other nodes (e.g. at a node closer to the destination), so that is w= orth to compute a good endpoint... one such endpoint can be the end of the = ear, if the ears are selected as you do. =20 Currently with MRT we are working on=20 1. what should be the specific algorithm to calculate MRTs 2. what should be the endpoint of the detours =20 ARC seems to me as a specific combination of 1+2. ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: rtgwg@ietf.org Subject: FW: draft-thubert-rtgwg-arc [resending due to excess size ] =20 Dear Routing area; =20 About http://www.ietf.org/id/draft-thubert-rtgwg-arc-00.txt =20 The ARC technology derives from some internal research at cisco, and follow= ing that line of thought, we found a number of interesting properties that = we want to share with you. =20 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. Ins= tead of following the arrows along a path, a packet will cascade from arc t= o arc, each arc providing at least 2 edges that the packet can use to progr= ess. Certainly, ARCs can be used for fast reroute, but there are tons of ot= her applications. This particular draft mainly presents the concepts, and w= ill defrer to more drafts to specify actual solutions for the specific prob= lems that we want to address with ARCs. =20 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 wh= ich simple DAGS cannot apply and where even the MRT approach is not suffici= ent. =20 As you go through the draft, you'll find that an ARC topology is made of mu= ltiple 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 SP= F 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 re= dundancy. =20 =20 An ARC topology can be exploited in classical routing or in MPLS. The recov= ery can be data plane or control plane which provides additional capabiliti= es. Because ARCs are (at least) dual ended, an ARC topology also enables lo= ad balancing and a recursive overflow management to take the traffic away f= rom the pain points. There's probably a lot more, but we'll have to discove= r that together. =20 About IPR: Stewart recommended that I talk to Alia (and effectively Joel) i= n Taipei to make sure that the IPR cisco has on ARC is not on the way of MR= T, and we concluded that these were effectively 2 different technologies. S= o cisco did not claim IPR regarding MRT but we certainly have IPR on ARCs. = We'll post ASAP on that. =20 Please let us know if this approach triggers interest. We wish to discuss A= RCs during the RTGWG meeting in Atlanta and will be asking for a slot from = the chairs. =20 Cheers, =20 Pascal =20 From Andras.Csaszar@ericsson.com Wed Oct 3 09:39:29 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FDC21F8624 for ; Wed, 3 Oct 2012 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT2hyXwpk2aq for ; Wed, 3 Oct 2012 09:39:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DA39B21F8552 for ; Wed, 3 Oct 2012 09:39:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-fe-506c6a3d519f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 86.EC.17130.E3A6C605; Wed, 3 Oct 2012 18:39:26 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.116]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Oct 2012 18:39:25 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , "Pascal Thubert (pthubert)" , "rtgwg@ietf.org" Date: Wed, 3 Oct 2012 18:39:25 +0200 Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeAAArs9jQ== Message-ID: Accept-Language: hu-HU, en-US Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvra5dVk6AwYynKhYzprxjtLjw5jez A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXR8vgMS8FOzYrjy84yNzD+VOhi5OSQEDCR mHvhFBuELSZx4d56IJuLQ0jgFKPEpicfmCGcBYwSZ+fvYgGpYhPwlDg29TFYlYjACkaJPZ// MIMkWARUJH60fWMFsYWB7FmH74DZIgKqEivvb2SCsJ0kri59xwhi8wq4Scz9uwBstZCAr8SS E8vZuxg5OBgFZCUerrUACTMLiEtMXPyEEeI6AYkle84zQ9iiEi8f/wMbzyggI/Fh6SE2iHo9 iRtTp0DZ2hLLFr5mhlglKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfXSy3K TC4uzs/TK07dxAiMhoNbfhvsYNx0X+wQozQHi5I4r57qfn8hgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjIIzTrx7cHL9vCqb5952mWe/Ht5+tVa1sKFgsb5kuXkq58kFXSJtX8sUNugHmHww O9TT4rJwTS53mlTBr8eqDCkJHD1u0gckVH+uuLrubJ3IoaYlLJN9rGdPiKr9xPX/TptlwZmO xJBdBx3vmLdPq5/hfvX5u40vEw0Mn137yDtrxXqTOUoxSUosxRmJhlrMRcWJAGelcURUAgAA X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:39:29 -0000 Hi, unsurprisingly I agree with G=E1bor (since we discussed this today), bu= t 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 al= gorithm and a detour endpoint selection method, both of which are work in p= rogress, then maybe ARC should be merged into the MRT algorithm draft on th= e long run. Then the WG should perform a careful analysis to decide which alg to mandat= e. Andr=E1s Sent from my mobile G=E1bor S=E1ndor Enyedi ezt =EDrta: 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 t= hat the phrase "ARC" is what MRT calls "ear". To be more precise, ARCs seem= s to be special ears, which must meet with some extra requirement, namely t= hat you can get a shortest path along a well defined order of the ears. Cou= ld you please read through the MRT draft and help me to find the fundamenta= l difference between the concept of ear and ARC? Gabor PS: No doubt, there is some difference between the two techniques, since pa= ckets leave the detour when it leaves an ARC/ear (if I understood that corr= ectly). 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 t= he endpoint of the ear. Actually this is a special case of what we call "en= dpoint selection" (and currently working on); MRT detours do not need to en= d at the destination, but packets can be put back to the shortest path at s= everal other nodes (e.g. at a node closer to the destination), so that is w= orth 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: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: rtgwg@ietf.org 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 follow= ing 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. Ins= tead of following the arrows along a path, a packet will cascade from arc t= o arc, each arc providing at least 2 edges that the packet can use to progr= ess. Certainly, ARCs can be used for fast reroute, but there are tons of ot= her applications. This particular draft mainly presents the concepts, and w= ill defrer to more drafts to specify actual solutions for the specific prob= lems 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 wh= ich simple DAGS cannot apply and where even the MRT approach is not suffici= ent. As you go through the draft, you'll find that an ARC topology is made of mu= ltiple 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 SP= F 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 re= dundancy. An ARC topology can be exploited in classical routing or in MPLS. The recov= ery can be data plane or control plane which provides additional capabiliti= es. Because ARCs are (at least) dual ended, an ARC topology also enables lo= ad balancing and a recursive overflow management to take the traffic away f= rom the pain points. There's probably a lot more, but we'll have to discove= r that together. About IPR: Stewart recommended that I talk to Alia (and effectively Joel) i= n Taipei to make sure that the IPR cisco has on ARC is not on the way of MR= T, and we concluded that these were effectively 2 different technologies. S= o 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 A= RCs during the RTGWG meeting in Atlanta and will be asking for a slot from = the chairs. Cheers, Pascal _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From pthubert@cisco.com Wed Oct 3 10:23:25 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476E621F8501 for ; Wed, 3 Oct 2012 10:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkT9ge-juSRP for ; Wed, 3 Oct 2012 10:23:20 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6721F8495 for ; Wed, 3 Oct 2012 10:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8207; q=dns/txt; s=iport; t=1349284999; x=1350494599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0QbOawtUPZYTKkoOp71j1YBiDiVQnclXHXMaVHY7z+s=; b=OYjfn+jwp9Spw6wVIJUlgWrRcLbtB0EMRdT24SVMrL+8PMEjMY6Sgjak mgEewJBX/GKGj/Z/URaJb3C3jhFXGDR1QuMyr4RF318KTttDYii0NxeWJ LKCMWn0kZQovgsXjT0WrzCsV7nAeBrX75wYSSLkuVum3v7sPRxgwlajIB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFp0bFCtJXG//2dsb2JhbABFvnaBCIIgAQEBBBIBFFIQAgEIEQQBAQsdBzIUCQgBAQQBDQUIARIHDIdXC5dTn3eLI4VaYAMmAod7iVs6kXOBaYJtgWUIKg X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="127966122" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 03 Oct 2012 17:23:16 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q93HNGvs006743 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 17:23:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.4]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 12:23:16 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , "Patrice Bellagamba (pbellaga)" , "joel.halpern@ericsson.comb" , "Alia Atlas (akatlas@gmail.com)" Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeAAAEquIA== Date: Wed, 3 Oct 2012 17:23:15 +0000 Deferred-Delivery: Wed, 3 Oct 2012 17:23:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--63.713200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:23:25 -0000 Hi Gabor: [Gabor] I think Alia was wrong, and ARC is extremely close to MRT. Unfortun= ately, 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, A= RCs 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 e= ars. Could you please read through the MRT draft and help me to find the fu= ndamental difference between the concept of ear and ARC? [Pascal] I'll have a close look at those ears... Alia showed Joel and I an = algorithm in which I did not recognize -at all- anything related to ARCs, b= ut I'm certainly willing to go to the bottom of it. I hope we can chat at the next IETF and we'll figure if cisco needs to publ= ish some IPR about MRT drafts and/or to present additional potential prior = art to the USPTO for our pending claims. In any case I'll focus on the technical for now: [Pascal] It is important to note that including the shortest path is not a = requirement for ARCs but just a preferred option for our applications. Conc= eptually you could pick a first arbitrary sequence of nodes with the edges = at the destination, call that an arc and add it to the destination. And ag= ain till you can't form ARCs anymore. You'll end up with an ARC set that le= ads to the destination with no loop and a plan B for everyone in the set. T= he algorithm in the draft can be optimized to cash on already explored stuf= f, but variations would be expected to give the same result, that is join t= ogether the lowest shortest-paths into an arc, and then attach all possible= buttressing arcs to reinforce that structure. And again. After playing a n= umber of such variations, I found that this particular expression of the oL= AF algorithm was the easiest to communicate. [Pascal] From the FRR perspective, the fundamental difference, IMHO, is tha= t ARC does not build trees (one red and one blue tree as I understand MRT d= oes) but a DAG of ARCs that cascades to the destination(s). With blue and r= ed trees, upon a first failure we need to paint the packet, say, in blue. I= f the blue tree is broken later then we're screwed - at least that is my un= derstanding. ARCs, on the other hand, create small domains where the error = isolation and correction is contained. Once you leave an ARC, the packet is= cleaned pure white again, and it can face the next breakage in another ARC= down the cascade. Thus ARCs can sustain multiple breakages, at least one p= er ARC. And in a classical mesh, most ARCs are collapsed in one node. So th= at is a great many breakages.=20 [Pascal] There are other differences:=20 -> ARC is an approach rather than a FRR solution, a new tool for us to play= with that replaces arrows with arcs in the way we figure routing graphs. T= he possibilities are quite something.=20 -> The ARC generalization (comb) is multi ended, and can sustain more break= ages, something like a non-equal cost multipath version of an ARC or an ear= if you like. [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 t= hat correctly). However, this behavior can easily be reproduced with MRT, i= f 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 ne= ed to end at the destination, but packets can be put back to the shortest p= ath at several other nodes (e.g. at a node closer to the destination), so t= hat 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. =20 [Pascal] I think you understand it well, and your proposition is beyond wha= t I gathered about MRT. I'm not aware of detours though I could figure stuf= f from the name and your explanation. Certainly great discussions ahead. =20 [Gabor] Currently with MRT we are working on 1. what should be the specific algorithm to calculate MRTs 2. what should b= e the endpoint of the detours =20 [Pascal] Then you have a proposal on the table based on ARCs : ) Conceptual= ly, it's not really detours, rather walking the current ARC or Comb till yo= u find an exit to cascade into - that is another ARC that's nearer to the d= estination. Probably we may end up computing similar if not the same result= . On the way ARCs will allow you to simplify the visualization of the netwo= rk, and will play ball with routing hierarchies, load balancing, etc... =20 [Gabor] ARC seems to me as a specific combination of 1+2. [Pascal] I agree that ARC can help solve problems 1 and 2. And other proble= ms as well. ARCs can be used to solve the Olympic rings problem in MPLS-TP = for instance. Then again greats talks ahead.=20 Thanks for all this Gabor, Cheers, Pascal ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: rtgwg@ietf.org Subject: FW: draft-thubert-rtgwg-arc [resending due to excess size ] =20 Dear Routing area; =20 About http://www.ietf.org/id/draft-thubert-rtgwg-arc-00.txt =20 The ARC technology derives from some internal research at cisco, and follow= ing that line of thought, we found a number of interesting properties that = we want to share with you. =20 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. Ins= tead of following the arrows along a path, a packet will cascade from arc t= o arc, each arc providing at least 2 edges that the packet can use to progr= ess. Certainly, ARCs can be used for fast reroute, but there are tons of ot= her applications. This particular draft mainly presents the concepts, and w= ill defrer to more drafts to specify actual solutions for the specific prob= lems that we want to address with ARCs. =20 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 wh= ich simple DAGS cannot apply and where even the MRT approach is not suffici= ent. =20 As you go through the draft, you'll find that an ARC topology is made of mu= ltiple 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 SP= F 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 re= dundancy. =20 =20 An ARC topology can be exploited in classical routing or in MPLS. The recov= ery can be data plane or control plane which provides additional capabiliti= es. Because ARCs are (at least) dual ended, an ARC topology also enables lo= ad balancing and a recursive overflow management to take the traffic away f= rom the pain points. There's probably a lot more, but we'll have to discove= r that together. =20 About IPR: Stewart recommended that I talk to Alia (and effectively Joel) i= n Taipei to make sure that the IPR cisco has on ARC is not on the way of MR= T, and we concluded that these were effectively 2 different technologies. S= o cisco did not claim IPR regarding MRT but we certainly have IPR on ARCs. = We'll post ASAP on that. =20 Please let us know if this approach triggers interest. We wish to discuss A= RCs during the RTGWG meeting in Atlanta and will be asking for a slot from = the chairs. =20 Cheers, =20 Pascal =20 From pthubert@cisco.com Wed Oct 3 12:12:17 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442CF1F042B for ; Wed, 3 Oct 2012 12:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuuRySeaROZB for ; Wed, 3 Oct 2012 12:12:16 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4395B1F0429 for ; Wed, 3 Oct 2012 12:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6301; q=dns/txt; s=iport; t=1349291536; x=1350501136; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ggs2dBsoNjbpydE2/3OcdW+A/qqvY48AYyb2QspdtlQ=; b=J90o+ytN4iS3/kWiXLhKVGpMH2FTHIDuGL1iNzH9odvO/5pumAk6K1St rYZoykCPKpuKQzJd4GHaj55bvSeoZpXm0Yy7u6dAOevXFYNkiPAj7Q6qT MgaxhoYQrr9Z+iDEon4VDTaHkG5J9Jb8SSnXH+G/eNO6q1d1NsS3wfxrN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL6NbFCtJXG+/2dsb2JhbABFvnmBCIIgAQEBBAEBAQ8BWxcEAgEIEQQBAQsdBycLFAkIAQEEARIIARIHh2MLl1KgA4sjhVpgA4gjihWRc4Fpgm2CFw X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="128007696" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 03 Oct 2012 19:12:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q93JCEDM030060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Oct 2012 19:12:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.4]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 14:12:13 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= , =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , "rtgwg@ietf.org" Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeAAArs9jQAE71Ng Date: Wed, 3 Oct 2012 19:11:51 +0000 Deferred-Delivery: Wed, 3 Oct 2012 19:11:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--53.046100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:12:17 -0000 Hello Andr=E1s, I certainly agree that have common objectives. I have trouble finding the common ancestry closer than SPF, since here we a= re building one DAG of ARCs as opposed to two trees of arrows;=20 but then that may be my lack of understanding of MRT and maybe behind the s= cene there's more commonality than meet my eye. Anyway your kind words indicate that we have a common thinking and yes, it = would be neat to converge, once ARCs mature a bit with the help of the WG. I'll unicast you and G=E1bor some slideware which illustrates the current d= raft and an example application to MPLS-TP. That might help you figure commonalities and differences. If others want it please let me know :) Cheers, Pascal -----Original Message----- From: Andr=E1s Cs=E1sz=E1r [mailto:Andras.Csaszar@ericsson.com]=20 Sent: mercredi 3 octobre 2012 18:39 To: G=E1bor S=E1ndor Enyedi; Pascal Thubert (pthubert); rtgwg@ietf.org Subject: RE: draft-thubert-rtgwg-arc Hi, unsurprisingly I agree with G=E1bor (since we discussed this today), bu= t 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 al= gorithm and a detour endpoint selection method, both of which are work in p= rogress, then maybe ARC should be merged into the MRT algorithm draft on th= e long run. Then the WG should perform a careful analysis to decide which alg to mandat= e. Andr=E1s Sent from my mobile G=E1bor S=E1ndor Enyedi ezt =EDrta: 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 t= hat the phrase "ARC" is what MRT calls "ear". To be more precise, ARCs seem= s to be special ears, which must meet with some extra requirement, namely t= hat you can get a shortest path along a well defined order of the ears. Cou= ld you please read through the MRT draft and help me to find the fundamenta= l difference between the concept of ear and ARC? Gabor PS: No doubt, there is some difference between the two techniques, since pa= ckets leave the detour when it leaves an ARC/ear (if I understood that corr= ectly). 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 t= he endpoint of the ear. Actually this is a special case of what we call "en= dpoint selection" (and currently working on); MRT detours do not need to en= d at the destination, but packets can be put back to the shortest path at s= everal other nodes (e.g. at a node closer to the destination), so that is w= orth 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 b= e the endpoint of the detours ARC seems to me as a specific combination of 1+2. ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: rtgwg@ietf.org 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 follow= ing 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. Ins= tead of following the arrows along a path, a packet will cascade from arc t= o arc, each arc providing at least 2 edges that the packet can use to progr= ess. Certainly, ARCs can be used for fast reroute, but there are tons of ot= her applications. This particular draft mainly presents the concepts, and w= ill defrer to more drafts to specify actual solutions for the specific prob= lems 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 wh= ich simple DAGS cannot apply and where even the MRT approach is not suffici= ent. As you go through the draft, you'll find that an ARC topology is made of mu= ltiple 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 SP= F 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 re= dundancy. An ARC topology can be exploited in classical routing or in MPLS. The recov= ery can be data plane or control plane which provides additional capabiliti= es. Because ARCs are (at least) dual ended, an ARC topology also enables lo= ad balancing and a recursive overflow management to take the traffic away f= rom the pain points. There's probably a lot more, but we'll have to discove= r that together. About IPR: Stewart recommended that I talk to Alia (and effectively Joel) i= n Taipei to make sure that the IPR cisco has on ARC is not on the way of MR= T, and we concluded that these were effectively 2 different technologies. S= o 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 A= RCs during the RTGWG meeting in Atlanta and will be asking for a slot from = the chairs. Cheers, Pascal _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From aretana@cisco.com Thu Oct 4 12:31:50 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CE821F871C for ; Thu, 4 Oct 2012 12:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADs02VsJtkly for ; Thu, 4 Oct 2012 12:31:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B90EA21F8707 for ; Thu, 4 Oct 2012 12:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=861; q=dns/txt; s=iport; t=1349379109; x=1350588709; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=mTj3Yy8aCi9y9h/4woUSJOxy+LfXXdWJilZ+PYv3h3E=; b=gzgd99U2WmZIY2qQxFonow/5+41moqUuGJvT1kwkQksdyUPL6uC6w87f bPKu1/qeR9Z2Fw87CgIDfG74CRKGQip82ybyEBk3AY0GIkTowkWh14xjf Xh+qHn050w07iHN9z9bPYHCFV90NQbqsx5CpSYByGJdCjpAPPkpJbSwB6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAC/jbVCtJXHA/2dsb2JhbABFhUi5RIEIgiABAQEEEgEnUQEIIhRCGwEGAwIEEwgah2OWa4EooBeQe2ADpCyBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,537,1344211200"; d="scan'208";a="125401225" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 04 Oct 2012 19:31:49 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q94JVnpd001585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Oct 2012 19:31:49 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.153]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Thu, 4 Oct 2012 14:31:48 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: FW: rtgwg - Requested session has been scheduled for IETF 85 Thread-Topic: rtgwg - Requested session has been scheduled for IETF 85 Thread-Index: AQHNomDNuU/kppUiy0SyMf6XCgZ6JZepmcoA Date: Thu, 4 Oct 2012 19:31:48 +0000 Message-ID: In-Reply-To: <20121004184809.13141.73476.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.164] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19238.000 x-tm-as-result: No--28.183300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 19:31:50 -0000 FYI. I have received 2-3 requests for time at the meeting. Please send any others along. We will not only want to have slides beforehand (ideally *before* the Friday before IETF), but we also want to ask the presenters to please start discussions on your drafts on the list as soon as possible. Don't just inform the list of the new draft, but please highlight the main points where you would like focus and feedback. We all know how hard it is to find time to read all the drafts before the meeting, so the objective is to enhance the discussions and take the most advantage of the meeting time. Thanks! Alvaro. On 10/4/12 2:48 PM, ""IETF Secretariat"" wrote: >rtgwg Session 1 (1:30:00) > Monday, Afternoon Session I 1300-1500 > Room Name: Salon E > --------------------------------------------- > From gabor.sandor.enyedi@ericsson.com Fri Oct 5 02:54:34 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9789D21F859F for ; Fri, 5 Oct 2012 02:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_BEEF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhRAMEJBh78j for ; Fri, 5 Oct 2012 02:54:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86121F859A for ; Fri, 5 Oct 2012 02:54:26 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-35-506eae50236f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 06.7D.25676.05EAE605; Fri, 5 Oct 2012 11:54:25 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.2.76]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 5 Oct 2012 11:54:24 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "Pascal Thubert (pthubert)" Date: Fri, 5 Oct 2012 11:54:23 +0200 Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeAAAEquIABVuIMw Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvrW7gurwAg2OLuS0+PbzEbLH95jFW i3PbpzNZzJjyjtHiwpvfzA6sHlN+b2T16D/4gNVj56y77B5LlvxkCmCJ4rJJSc3JLEst0rdL 4Mr4deMkY8HrhIqjrS9YGxi3eHUxcnJICJhI7F5+jhHCFpO4cG89WxcjF4eQwClGiQnTH7NA OPMZJe49PsQMUsUmECyx/cEGNhBbBKh7w8nXjCBFzAIzmSTOPr7BApJgEVCROL/0ETuILQxk zzp8hxWiQVVi5f2NTBC2m8S+yd/A4rwC4RLnzjWD9QoJ3GWUuPI3HMTmFPCV+PfxNNAyDg5G AVmJh2stQMLMAuISt57MZ4K4WkBiyZ7zzBC2qMTLx//ARjIKyEh8WHqIDaJeT+LG1ClQtrbE soWvmSHWCkqcnPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGIVzEzNz0suN9FKLMpOLi/Pz9IpT NzEC4+3glt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaO 46fj3XSvy1w2bnkk+X726Qezjkx546l2Q+XDjMdfU9JW7lhuct/sRF/bU+3z1Zp3xVfePR// 9NmchzNm83zoX3Xtcqye3aRFYVqu1qsVzwbOapVYXP31fZI4k5uPduO/9Ir++O1zFy51D81n u/PG+Gp8XebLVYuOHpo0qcw5TONsuOkSu1MMSizFGYmGWsxFxYkA4ugVToUCAAA= Cc: "joel.halpern@ericsson.comb" , "Patrice Bellagamba \(pbellaga\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 09:54:34 -0000 Hi Pascal, Just some notes and a simple example, which may help to find the common poi= nts: - You should probably not focus on the trees (they are not so important, ju= st useful to make the concept easier to understand), but on the GADAG (Gene= ralized Almost Directed Acyclic Graph). This is the graph we get, if we com= bine our ears. This is something like a partial order of the nodes in the n= etwork. As far as I understood, you also have an order in the ARCs, and if = you cannot get out along the increasing direction, you try the decreasing (= or vice versa). The difference is that not all nodes are in a common order,= just those in the same ARC. - Here is a simple example graph. Keep in mind that this example is really = simple and useful only for some rough understanding; some problems do not s= how up, thus I don't cover all the details. Let the destination be [Omega],= and find the ARCs/ears and the GADAG in that (now, we are not interested i= n shortest paths, but have some arbitrary algorithm): [Omega]----[A]-------[E] | | | | | | | | | [D]--------[C]-------[F] | | | | | | [G]--------[H]-------[I] Start from the Omega, let the first ARC be made up by D-C-A, and use this o= rder (i.e. D[C]------>[F] Finally, we find ARC/ear G-H-I. For ears, we need to consider that D[C]------>[F] | ^ | | V | [G]------->[H]------>[I] The graph view is extremely similar: [Omega]<---[A]<------[E] ^ ^ ^ | # # | V V [D]<=3D=3D=3D=3D=3D=3D>[C]<------[F] ^ ^ | | | | [G]<=3D=3D=3D=3D=3D=3D>[H]<=3D=3D=3D=3D=3D>[I] (where # is the vertical version of =3D ) How can we use the GADAG for routing? Start from a given node, and always i= ncrease; you will get to Omega (use the direction of the edges; when multip= le edges go out from that node, select one of them). This is the increasing= path. The decreasing path is the one you get when you always move in the o= pposite direction; you get to Omega as well (this is the reason why we call= this as an Almost DAG; if you remove the root/Omega, you get a DAG). What is important to note that if there is a directed path from X to Y, the= n Y>X. But in general GADAGs there can be such X and Y, where neither X>Y, = nor Y>X. Thus GADAG is representing a PARTIAL order in general. This partia= l order is a total order in the previous example. Endpoint selection is a method to select detour endpoints other than Omega.= For example if node [I] goes down, and the shortest path from D to Omega d= oesn't go through [I], H can select D as an endpoint. Sending packets to ot= her node than Omega is simple, since with a single GADAG we can compute inc= reasing and decreasing path not only to the Omega, but to all the nodes in = the network; but this is an other story far beyond the complexity we can di= scuss in this mail... :) BR, Gabor -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Wednesday, October 03, 2012 7:23 PM To: G=E1bor S=E1ndor Enyedi; Patrice Bellagamba (pbellaga); joel.halpern@er= icsson.comb; Alia Atlas (akatlas@gmail.com) Cc: rtgwg@ietf.org Subject: RE: draft-thubert-rtgwg-arc Hi Gabor: [Gabor] I think Alia was wrong, and ARC is extremely close to MRT. Unfortun= ately, 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, A= RCs 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 e= ars. Could you please read through the MRT draft and help me to find the fu= ndamental difference between the concept of ear and ARC? [Pascal] I'll have a close look at those ears... Alia showed Joel and I an = algorithm in which I did not recognize -at all- anything related to ARCs, b= ut I'm certainly willing to go to the bottom of it. I hope we can chat at the next IETF and we'll figure if cisco needs to publ= ish some IPR about MRT drafts and/or to present additional potential prior = art to the USPTO for our pending claims. In any case I'll focus on the technical for now: [Pascal] It is important to note that including the shortest path is not a = requirement for ARCs but just a preferred option for our applications. Conc= eptually you could pick a first arbitrary sequence of nodes with the edges = at the destination, call that an arc and add it to the destination. And ag= ain till you can't form ARCs anymore. You'll end up with an ARC set that le= ads to the destination with no loop and a plan B for everyone in the set. T= he algorithm in the draft can be optimized to cash on already explored stuf= f, but variations would be expected to give the same result, that is join t= ogether the lowest shortest-paths into an arc, and then attach all possible= buttressing arcs to reinforce that structure. And again. After playing a n= umber of such variations, I found that this particular expression of the oL= AF algorithm was the easiest to communicate. [Pascal] From the FRR perspective, the fundamental difference, IMHO, is tha= t ARC does not build trees (one red and one blue tree as I understand MRT d= oes) but a DAG of ARCs that cascades to the destination(s). With blue and r= ed trees, upon a first failure we need to paint the packet, say, in blue. I= f the blue tree is broken later then we're screwed - at least that is my un= derstanding. ARCs, on the other hand, create small domains where the error = isolation and correction is contained. Once you leave an ARC, the packet is= cleaned pure white again, and it can face the next breakage in another ARC= down the cascade. Thus ARCs can sustain multiple breakages, at least one p= er ARC. And in a classical mesh, most ARCs are collapsed in one node. So th= at is a great many breakages.=20 [Pascal] There are other differences:=20 -> ARC is an approach rather than a FRR solution, a new tool for us to play= with that replaces arrows with arcs in the way we figure routing graphs. T= he possibilities are quite something.=20 -> The ARC generalization (comb) is multi ended, and can sustain more break= ages, something like a non-equal cost multipath version of an ARC or an ear= if you like. [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 t= hat correctly). However, this behavior can easily be reproduced with MRT, i= f 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 ne= ed to end at the destination, but packets can be put back to the shortest p= ath at several other nodes (e.g. at a node closer to the destination), so t= hat 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. =20 [Pascal] I think you understand it well, and your proposition is beyond wha= t I gathered about MRT. I'm not aware of detours though I could figure stuf= f from the name and your explanation. Certainly great discussions ahead. =20 [Gabor] 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 =20 [Pascal] Then you have a proposal on the table based on ARCs : ) Conceptual= ly, it's not really detours, rather walking the current ARC or Comb till yo= u find an exit to cascade into - that is another ARC that's nearer to the d= estination. Probably we may end up computing similar if not the same result= . On the way ARCs will allow you to simplify the visualization of the netwo= rk, and will play ball with routing hierarchies, load balancing, etc... =20 [Gabor] ARC seems to me as a specific combination of 1+2. [Pascal] I agree that ARC can help solve problems 1 and 2. And other proble= ms as well. ARCs can be used to solve the Olympic rings problem in MPLS-TP = for instance. Then again greats talks ahead.=20 Thanks for all this Gabor, Cheers, Pascal ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Tuesday, October 02, 2012 6:48 PM To: rtgwg@ietf.org Subject: FW: draft-thubert-rtgwg-arc [resending due to excess size ] =20 Dear Routing area; =20 About http://www.ietf.org/id/draft-thubert-rtgwg-arc-00.txt =20 The ARC technology derives from some internal research at cisco, and follow= ing that line of thought, we found a number of interesting properties that = we want to share with you. =20 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. Ins= tead of following the arrows along a path, a packet will cascade from arc t= o arc, each arc providing at least 2 edges that the packet can use to progr= ess. Certainly, ARCs can be used for fast reroute, but there are tons of ot= her applications. This particular draft mainly presents the concepts, and w= ill defrer to more drafts to specify actual solutions for the specific prob= lems that we want to address with ARCs. =20 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 wh= ich simple DAGS cannot apply and where even the MRT approach is not suffici= ent. =20 As you go through the draft, you'll find that an ARC topology is made of mu= ltiple 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 SP= F 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 re= dundancy. =20 =20 An ARC topology can be exploited in classical routing or in MPLS. The recov= ery can be data plane or control plane which provides additional capabiliti= es. Because ARCs are (at least) dual ended, an ARC topology also enables lo= ad balancing and a recursive overflow management to take the traffic away f= rom the pain points. There's probably a lot more, but we'll have to discove= r that together. =20 About IPR: Stewart recommended that I talk to Alia (and effectively Joel) i= n Taipei to make sure that the IPR cisco has on ARC is not on the way of MR= T, and we concluded that these were effectively 2 different technologies. S= o cisco did not claim IPR regarding MRT but we certainly have IPR on ARCs. = We'll post ASAP on that. =20 Please let us know if this approach triggers interest. We wish to discuss A= RCs during the RTGWG meeting in Atlanta and will be asking for a slot from = the chairs. =20 Cheers, =20 Pascal =20 From pthubert@cisco.com Sun Oct 7 23:42:38 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768E121F86BD for ; Sun, 7 Oct 2012 23:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_BEEF=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJTvt4pyUrqP for ; Sun, 7 Oct 2012 23:42:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9495121F8694 for ; Sun, 7 Oct 2012 23:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25341; q=dns/txt; s=iport; t=1349678554; x=1350888154; h=from:to:cc:subject:date:message-id:references: mime-version; bh=k1ks+moKPhtgdGZcsliXS42T3LjyAdCmEGF+kMTimss=; b=HmzW6qmaXEc6crLMY6dSvy2/ZyofM26BAGQt4soLa1mYiUinu5YLzhbZ 8lvx9FxpvEL9uIoy4zkgTAlbGrlbAwSQAUQ2brA/27mKIiESZxmBmxNVy rTUQU8JjZ/TiBSRWOIW6tynRwplrfvUc5IbfQsw7VC1nr5iM36wKMeT+2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGN1clCtJV2a/2dsb2JhbABFgku8VoEIgiEBAQQSARQGTBACAQgQEhYOMiUCBA4NGodjmTufCotRCBCFFmADiCOJXTqRdoFpgm2BYzQ X-IronPort-AV: E=Sophos;i="4.80,551,1344211200"; d="scan'208,217";a="129227141" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 08 Oct 2012 06:42:33 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q986gX12003525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Oct 2012 06:42:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Mon, 8 Oct 2012 01:42:32 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Subject: RE: draft-thubert-rtgwg-arc Thread-Topic: draft-thubert-rtgwg-arc Thread-Index: Ac2gfGXH1Pj5gJ+wQwa1LH0T5a4abwAQOszgAC9aEeAAAEquIABVuIMwAHD7vlAAIecSYA== Date: Mon, 8 Oct 2012 06:42:31 +0000 Deferred-Delivery: Mon, 8 Oct 2012 06:42:00 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.119] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19252.004 x-tm-as-result: No--49.639600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8221BDB2Dxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "joel.halpern@ericsson.comb" , "Patrice Bellagamba \(pbellaga\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 06:42:38 -0000 --_000_E045AECD98228444A58C61C200AE1BD8221BDB2Dxmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello G=E1bor [] resending got bounced... I snipped the original xchg. [] I had to use HTML and play with fonts t be able to format your drawings.= Please bear with me... - You should probably not focus on the trees (they are not so important, ju= st useful to make the concept easier to understand), but on the GADAG (Gene= ralized Almost Directed Acyclic Graph). This is the graph we get, if we com= bine our ears. This is something like a partial order of the nodes in the n= etwork. As far as I understood, you also have an order in the ARCs, and if = you cannot get out along the increasing direction, you try the decreasing (= or vice versa). The difference is that not all nodes are in a common order,= just those in the same ARC. [] Looks like ears and arcs could obtain similar results on a given use cas= e. This certainly does not mean we are using the same tool but clearly indi= cates that agree on what the improvement is about. Great :) And yes, we have an order between ARCs (they form a DAG) but what happens i= nside an ARC could be anything as long as you do not loop and yet explore a= ll the possible exits. IOW what you do inside an ARC is not necessarily cor= related to what you do outside, where you're going etc... I think it is important to create subdomains that isolate a problem. This h= as interesting properties when you start looking at routing hierarchies. I'= m a bit enthusiastic about ARCs because they really open avenues for thinki= ng and yet do not yield additional complexity. In fact, the DAG of ARCs top= ology is largely a simplification from the original mesh. - Here is a simple example graph. Keep in mind that this example is really = simple and useful only for some rough understanding; some problems do not s= how up, thus I don't cover all the details. Let the destination be [Omega],= and find the ARCs/ears and the GADAG in that (now, we are not interested i= n shortest paths, but have some arbitrary algorithm): [Omega]----[A]-------[E] | | | | | | | | | [D]--------[C]-------[F] | | | | | | [G]--------[H]-------[I] Start from the Omega, let the first ARC be made up by D-C-A, and use this o= rder (i.e. D[C]------>[F] Finally, we find ARC/ear G-H-I. For ears, we need to consider that D[C]------>[F] | ^ | | V | [G]------->[H]------>[I] [] If I'm with you ... Either you follow the arrows to the end or you follo= w the reverse arrows to the end. Either way you reach omega. I'm still confused what happens on a double bre= akage, say F has a packet and Both D-omega and F-E are broken... : The graph view is extremely similar [Omega]<---[A]<------[E] ^ ^ ^ | # # | V V [D]<=3D=3D=3D=3D=3D=3D>[C]<------[F] ^ ^ | | | | [G]<=3D=3D=3D=3D=3D=3D>[H]<=3D=3D=3D=3D=3D>[I] (where # is the vertical version of =3D ) [] With the ARC approach, if F has a packet to omega and F-E is broken, F = hands the pak to C; if D is shortest path then C passes the pak D along AR= C D=3DC=3DA. If D-omega is broken then the pak sent the other way (over a = backup label along the ARC of MPLS is the name of the game). So the pak end= s up doing F, C, D, C, A, Omega. [] Yep, that's what ARCs will give you. Note that if H is cursor, it may di= stribute traffic to its left and right for instance. F can further distribu= te between E and C, etc. ARCs have properties way beyond FRR How can we use the GADAG for routing? Start from a given node, and always i= ncrease; you will get to Omega (use the direction of the edges; when multip= le edges go out from that node, select one of them). This is the increasing= path. The decreasing path is the one you get when you always move in the o= pposite direction; you get to Omega as well (this is the reason why we call= this as an Almost DAG; if you remove the root/Omega, you get a DAG). [] again yes, and I like it :) And yes the ears could be collocated with A= RCs. Though rapidly ARCs will build more complex and robust structures, eg = combs, which will make the ears look like Frankenstein's ; ) What is important to note that if there is a directed path from X to Y, the= n Y>X. But in general GADAGs there can be such X and Y, where neither X>Y, = nor Y>X. Thus GADAG is representing a PARTIAL order in general. This partia= l order is a total order in the previous example. [] There are cool properties with the fact that ARCs are local constructs w= hereas the partial order has to be end to end on a path. Now an ARC must ha= ve a metric that is more than that of the ARCs it ends into (to form a DAG)= . Endpoint selection is a method to select detour endpoints other than Omega.= For example if node [I] goes down, and the shortest path from D to Omega d= oesn't go through [I], H can select D as an endpoint. Sending packets to ot= her node than Omega is simple, since with a single GADAG we can compute inc= reasing and decreasing path not only to the Omega, but to all the nodes in = the network; but this is an other story far beyond the complexity we can di= scuss in this mail... :) [] Please save some time for chats in Atlanta, Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD8221BDB2Dxmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello G=E1bor

 

[] resending = got bounced… I snipped the original xchg.

 

[] I had to use= HTML and play with fonts t be able to format your drawings. Please bear wi= th me…

 

- You should probably not focus on the trees (the= y are not so important, just useful to make the concept easier to understan= d), but on the GADAG (Generalized Almost Directed Acyclic Graph). This is t= he graph we get, if we combine our ears. This is something like a partial order of the nodes in the network. = As far as I understood, you also have an order in the ARCs, and if you cann= ot get out along the increasing direction, you try the decreasing (or vice = versa). The difference is that not all nodes are in a common order, just those in the same ARC.

 

[] Looks like e= ars and arcs could obtain similar results on a given use case. This certain= ly does not mean we are using the same tool but clearly indicates that agre= e on what the improvement is about. Great J

 

And yes, we hav= e an order between ARCs (they form a DAG) but what happens inside an ARC co= uld be anything as long as you do not loop and yet explore all the possible= exits. IOW what you do inside an ARC is not necessarily correlated to what you do outside, where you’re g= oing etc...  

 

I think it is i= mportant to create subdomains that isolate a problem. This has interesting = properties when you start looking at routing hierarchies. I’m a bit e= nthusiastic about ARCs because they really open avenues for thinking and yet do not yield additional complexity. In f= act, the DAG of ARCs topology is largely a simplification from the original= mesh.

 

 

- Here is a simple example graph. Keep in mind th= at this example is really simple and useful only for some rough understandi= ng; some problems do not show up, thus I don't cover all the details. Let t= he destination be [Omega], and find the ARCs/ears and the GADAG in that (now, we are not interested in shortes= t paths, but have some arbitrary algorithm):

 

 

[Omega]----[A]-------[E]

|          |  &nb= sp;      |

|          |  &nb= sp;      |

|          |  &nb= sp;      |

[D]--------[C]-------[F]

|            = ;        |

|            = ;        |

|            = ;        |

[G]--------[H]-------[I]

 

Start from the Omega, let the first ARC be made u= p by D-C-A, and use this order (i.e. D<C<A). Let the first ear be the= same. Then the second ARC/ear can be E-F. However, with ears, you'll need = to keep up order. The ear is connected to the previous at A and C, and C<A (we defined that for the previous ear)= , so we must have that C<F<E<A. Graphically, we can represent that= with a directed graph, where edges are always pointing to the increasing d= irection:

 

[Omega]<---[A]<------[E]

|          ^  &nb= sp;      ^

|          |  &nb= sp;      |

V          |  &nb= sp;      |

[D]------->[C]------>[F]

 

Finally, we find ARC/ear G-H-I. For ears, we need= to consider that D<F, so we will have that D<G<H<I<F.<= /o:p>

 

Thus, we will have this GADAG:

 

[Omega]<---[A]<------[E]

|          ^  &nb= sp;      ^

|          |  &nb= sp;      |

V          |  &nb= sp;      |

[D]------->[C]------>[F]

|            = ;        ^

|            = ;        |

V            = ;        |

[G]------->[H]------>[I]

 

[] If I’m with you … Either you follow the= arrows to the end or you follow the reverse arrows to the end.<= /span>

Either way you reach omega. I’m still confused w= hat happens on a double breakage, say F has a packet and Both D-omega and F= -E are broken…

 

: The graph view is extremely similar

 

[Omega]<---[A]<------[E]

^          ^  &nb= sp;      ^

|          #  &nb= sp;      #

|          V  &nb= sp;      V

[D]<=3D=3D=3D=3D=3D=3D>[C]<------[F]

^            = ;        ^

|            = ;        |

|            = ;        |

[G]<=3D=3D=3D=3D=3D=3D>[H]<=3D=3D=3D=3D=3D>[I]

 

(where # is the vertical version of =3D )

 

[] With the ARC approach, if F has a packet=  to omega and F-E is broken, F hands the pak to C;  if D is shor= test path then C passes the pak D along ARC D=3DC=3DA. If D-omega is broken= then the pak  sent the other way (over a backup label along the ARC of MPLS is the name of the game). So the pak ends up d= oing F, C, D, C, A, Omega.

 

[] Yep, that= 217;s what ARCs will give you. Note that if H is cursor, it may distribute = traffic to its left and right for instance. F can further distribute betwee= n E and C, etc. ARCs have properties way beyond FRR

 

How can we use the GADAG for routing? Start from = a given node, and always increase; you will get to Omega (use the direction= of the edges; when multiple edges go out from that node, select one of the= m). This is the increasing path. The decreasing path is the one you get when you always move in the opposite di= rection; you get to Omega as well (this is the reason why we call this as a= n Almost DAG; if you remove the root/Omega, you get a DAG).

[] again yes, a= nd  I like it J And yes the ears could be collocated with = ARCs. Though rapidly ARCs will build more complex and robust structures, eg= combs, which will make the ears look like Frankenstein’s ; )

 

What is important to note that if there is a dire= cted path from X to Y, then Y>X. But in general GADAGs there can be such= X and Y, where neither X>Y, nor Y>X. Thus GADAG is representing a PA= RTIAL order in general. This partial order is a total order in the previous example.

 

[] There= are cool properties with the fact that ARCs are local constructs whereas t= he partial order has to be end to end on a path. Now an ARC must have a met= ric that is more than that of the ARCs it ends into (to form a DAG).

 

Endpoint selection is a method to select detour e= ndpoints other than Omega. For example if node [I] goes down, and the short= est path from D to Omega doesn't go through [I], H can select D as an endpo= int. Sending packets to other node than Omega is simple, since with a single GADAG we can compute increasing = and decreasing path not only to the Omega, but to all the nodes in the netw= ork; but this is an other story far beyond the complexity we can discuss in= this mail... :)

 

[] Please save some time for chats in Atlan= ta,

 

Cheers,

 

Pascal

--_000_E045AECD98228444A58C61C200AE1BD8221BDB2Dxmbrcdx01ciscoc_-- From pthubert@cisco.com Thu Oct 11 07:46:04 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4792921F8709 for ; Thu, 11 Oct 2012 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sdyMBKC5jlE for ; Thu, 11 Oct 2012 07:46:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 711BE21F86C3 for ; Thu, 11 Oct 2012 07:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1349966763; x=1351176363; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/CoKc/CtkkxWkCXcsj5L2cYNydQm5oEEy3mJrsqIPQM=; b=kQtALtTINIE9PTUt5RoruASFAtp+VL6d7iHrwll7KEO2yFN1u9pSOc/b AkULuDGjSbAhPQbioQfcTKrVAf+gK6A4OlZaLk0ksWA89cR2BFIS9aQyv Ukb1ieyWqhPVNYyhAENT9asmjTPEBY6FZ8iqu6f/RtH9TQ24HfdlRvU+5 E=; X-IronPort-AV: E=Sophos;i="4.80,572,1344211200"; d="scan'208";a="130582796" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2012 14:46:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9BEk3J1015903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Oct 2012 14:46:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 09:46:02 -0500 From: "Pascal Thubert (pthubert)" To: "rtgwg@ietf.org" Subject: draft-thubert-rtgwg-arc-bicast-00.txt Thread-Topic: draft-thubert-rtgwg-arc-bicast-00.txt Thread-Index: Ac2nvxzeZRNKNpmfTSKf6gpNk8BQdg== Date: Thu, 11 Oct 2012 14:46:01 +0000 Deferred-Delivery: Thu, 11 Oct 2012 14:46:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.99] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--27.754700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 14:46:04 -0000 SGk6DQoNClRoaXMgaXMgYW4gZXhhbXBsZSBhcHBsaWNhdGlvbiBvZiBBUkNzIChkcmFmdC10aHVi ZXJ0LXJ0Z3dnLWFyYyksIGluIHRoaXMgcGFydGljdWxhciBjYXNlIHRvIGJpY2FzdGluZy4gDQpI b3BlZnVsbHkgYSAwMSB3aWxsIHNvb24gZGV0YWlscyB0aGUgYXBwbGljYWJpbGl0eSBpbiBtdWx0 aWNhc3QgZW52aXJvbm1lbnRzLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogamV1ZGkgMTEgb2N0b2JyZSAyMDEyIDE2 OjQzDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IGljZUBjaXNjby5jb20NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtdGh1YmVydC1ydGd3Zy1h cmMtYmljYXN0LTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC10aHViZXJ0 LXJ0Z3dnLWFyYy1iaWNhc3QtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFBhc2NhbCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K RmlsZW5hbWU6CSBkcmFmdC10aHViZXJ0LXJ0Z3dnLWFyYy1iaWNhc3QNClJldmlzaW9uOgkgMDAN ClRpdGxlOgkJIEFwcGx5aW5nIEF2YWlsYWJsZSBSb3V0aW5nIENvbnN0cnVjdHMgdG8gYmljYXN0 aW5nDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0xMC0xMQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXRodWJlcnQtcnRnd2ctYXJjLWJpY2FzdC0w MC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC10aHViZXJ0LXJ0Z3dnLWFyYy1iaWNhc3QNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC1ydGd3Zy1hcmMtYmljYXN0LTAwDQoNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IGludHJvZHVjZXMgbWV0aG9kcyB0aGF0IGxldmVyYWdl IHRoZSBjb25jZXB0IG9mIEFSQyB0bw0KICAgZW5hYmxlIGJpY2FzdGluZyBvcGVyYXRpb25zLg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From pthubert@cisco.com Sat Oct 13 09:58:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF04821F8503 for ; Sat, 13 Oct 2012 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.148 X-Spam-Level: X-Spam-Status: No, score=-8.148 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjtzcGmrUjp9 for ; Sat, 13 Oct 2012 09:58:40 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2312421F84FD for ; Sat, 13 Oct 2012 09:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24986; q=dns/txt; s=iport; t=1350147520; x=1351357120; h=from:to:cc:subject:date:message-id:mime-version; bh=9WhagAD5sgtIS1z0KR98i4genmzMhVOSG+hpFzhV0Cc=; b=U901p8VMrfmcG+QDVDyHPIdDxz3EKjqoFVvZTKNgBBAhHer1LCO+Xf4x DGpPAaY/PAys/VHIGaKnsQT20biikkLnIIarUzjAsRHDOx85QONZgvi0G Q2/0YcLZI5erdI0CA9e9m3LqRk34ab+doWcR9tkI6Gk3xmTBKFBMfhlGr o=; X-IronPort-AV: E=Sophos;i="4.80,580,1344211200"; d="scan'208,217";a="131327251" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 13 Oct 2012 16:58:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9DGwdBX030819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 13 Oct 2012 16:58:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Sat, 13 Oct 2012 11:58:39 -0500 From: "Pascal Thubert (pthubert)" To: "rtgwg@ietf.org" Subject: Ears and ARCs Thread-Topic: Ears and ARCs Thread-Index: Ac2pY+C0voTGprBRTzSEqczmjWB0zQ== Date: Sat, 13 Oct 2012 16:58:37 +0000 Deferred-Delivery: Sat, 13 Oct 2012 16:58:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.106] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19268.004 x-tm-as-result: No--36.050300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD8221C5F69xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "Dirk Anteunis \(danteuni\)" , "Patrice Bellagamba \(pbellaga\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 16:58:43 -0000 --_000_E045AECD98228444A58C61C200AE1BD8221C5F69xmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG: I received an unicast a question that was, bascally, what's the difference = between MRT and ARCs. >From the draft, hopefully it appears that an ARC is a new tool with new pro= perties, up to us to find interesting applications and maybe find new solut= ions to existing problems. The core of that tool is the reversible link, so= that we form downwards U-shaped arcs as opposed to arrows for routing. But maybe the simpler approach is to make an exercise and see what we get -= my current understanding here, G=E1bor please correct me if I'm wrong -. So, say we have this simple network. 2 --- 3 | | | | 1 --- 4 | | | | Destination I illustrated naming the routers with a value that matches my understanding= of the values of the partial order, to make things simple. We end up with 2 ARCs and 2 ears, which are basically collocated. The ARC v= iew is 2 <=3D> 3 | | where links 2 - 3 and 1 - 4 are reversible. V V 1 <=3D> 4 | | V V Destination (Omega) A first property of the ARCs can be seen immediately. ARCs are hierarchical= routing friendly. We can collapse each ARC to simplify the representation which becomes: 2 | | V V 1 | | V V Destination If we break any link both ears and ARCs provide an alternate route, that's = FRR for you. Now let us see what happens with more than one breakage. There are double breakages that isolate a piece of the network, say if link= s 2 - 1 and 3 - 4 both break, there is no solution in the world that can ke= ep 3 connected to the Destination. Say now that 3 - 4 and 1 - Destination are both broken a 2 has a packet to = send. 2 --- 3 | | V X 1 --- 4 | | X V -------------Destination (Omega) - With ears, using the increasing order 2 will pass to 3, and 3 to 4 will f= ail. So the packet is switched to decreasing order and the packet reaches 1 via = 2. 1 fails to send to the destination and we are screwed. PPPPP>> <3 2<=3D=3Dp=3D3 2 --- 3 2 --- 3 2 --- 3 -p= -> in shortest path | | | | p | | | | | =3Dp=3D= > vs. returned V X V X V X V X V X pa= cket 1 --- 4 1 --- 4 1 --- 4 1=3D=3Dp=3D>4 1 --- 4 | | | | | | | | | p packet = reaches Omega X V X V X V X V V V ------------------------------------------------------------------Destina= tion (Omega) say that bad luck again the shortest path for 2 is via 1. 2 passes to 1 and since the ARC is exited the marking is removed. 1 fails to send to the destination, marks the packet and sends it along its= ARC. Packet reaches Destination via 4. IOW, ARCs form isolated recovery domains and allow up to as many breakages = as the ARC or Comb has exits, with no disruption. Also, ARCs can form multi-ended structures called combs with better recover= y capabilities than a 2-ended structure. For bicasting, the difference will be a bit more subtle. In a biconnected g= raph, ears will build non congruent path every time, but they might be far = away from shortest. ARCs will attempt to stay closer to shortest but may in= cur collisions, which are then resolved. Then ARCs can be employed for other purposes. We have an interesting approa= ch to the Olympic rings issue for instance. Cheers, Pascal --_000_E045AECD98228444A58C61C200AE1BD8221C5F69xmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Dear WG:

=  

= I received an unicast a question that was, bascally, what’s the diffe= rence between MRT and ARCs.

=  

= >From the draft, hopefully it appears that an ARC is a new tool with new pro= perties, up to us to find interesting applications and maybe find new solut= ions to existing problems. The core of that tool is the reversible link, so that we form downwards U-shaped arcs as opposed= to arrows for routing.

=  

= But maybe the simpler approach is to make an exercise and see what we get &= #8211; my current understanding here, G=E1bor please correct me if I’= m wrong -.

=  

= So, say we have this simple network.

=  

=   |     |

 |     |

 1 --- 4

 |     |

  |     |

Destination

=  

= I illustrated naming the routers with a value that matches my understanding= of the values of the partial order, to make things simple.

=  

= We end up with 2 ARCs and 2 ears, which are basically collocated. The ARC v= iew is

=  

=  

=  

=  2 <=3D> 3

=  |     |       =    where links 2 – 3 and 1 – 4 are reversible.

=   V     V

 1 <=3D> 4

  |     |

  V     V

= Destination (Omega)

=  

= A first property of the ARCs can be seen immediately. ARCs are hierarchical= routing friendly.

= We can collapse each ARC to simplify the representation which becomes:=

=  

=    2

=   | |

=   V V

=    1

=   | |

=   V V

= Destination

=  

=  

= If we break any link both ears and ARCs provide an alternate route, that= 217;s FRR for you. Now let us see what happens with more than one breakage.=

= There are double breakages that isolate a piece of the network, say if link= s 2 – 1 and 3 – 4 both break, there is no solution in the world= that can keep 3 connected to the Destination.

=  

= Say now that 3 – 4 and 1 – Destination are both broken a 2 has = a packet to send.

=  

=  

=  2 --- 3

 |     |     =    

  V     X

 1 --- 4

  |     |

  X     V

-------------Destination (Omega)

 

 

= - With ears, using the increasing order 2 will pass to 3, and 3 to 4 will f= ail.

= So the packet is switched to decreasing order and the packet reaches 1 via = 2.

= 1 fails to send to the destination and we are screwed.

=  

=  

=  PPPPP>>       <<ppppp =       2 --- 3      PPP pa= cket progressing in increasing order

=  |     |       |&nbs= p;    |       p  &nb= sp;  |      ppp packet progressing in decreas= ing order

=   V     X       V &n= bsp;   X       p  &n= bsp;  X    

=   1 --- 4       1 --- 4   = ;    V --- 4      When packet = reaches 1 must be dropped  

=   |     |       = ;|     |       | &nb= sp;   |      because increasing again ma= y cause a loop           =  

=   X     V       = ;X     V       X  &n= bsp;  V       

=   -----------------------------------------Destination (Omega)

 

 

= - With ARCS, say that bad luck the shortest path is via 3. 2 passes to 3 an= d 3 to 4 will fail.

= So 3 u-turns the packet along the ARC, back to 2.

= Some tagging indicates that the packet was u-turned which can happen only o= nce in that ARC.

=  

=  2--p->3       2<=3D=3Dp=3D3 =       2 --- 3       = 2 --- 3       2 --- 3   -p-> in = shortest path  

=   |     |       = ;|     |       p &nb= sp;   |       |   &n= bsp; |       |     | = ;  =3Dp=3D> vs. returned        =

=   V     X       = ;V     X       V &nb= sp;   X       V   &n= bsp; X       V     X = ;       packet

=  1 --- 4       1 --- 4    = ;   1 --- 4       1=3D=3Dp=3D&= gt;4       1 --- 4

=   |     |       |&nb= sp;    |       |  &n= bsp;  |       |     = |       |     p &nbs= p; packet reaches Omega

  X     V     &nbs= p; X     V       X &= nbsp;   V       X  &= nbsp;  V       V    = V

  --------------------------------------------------------= ----------Destination (Omega)

 

= say that bad luck again the shortest path for 2 is via 1.=

= 2 passes to 1 and since the ARC is exited the marking is removed.

= 1 fails to send to the destination, marks the packet and sends it along its= ARC.

= Packet reaches Destination via 4.

=  

=  

= IOW, ARCs form isolated recovery domains and allow up to as many breakages = as the ARC or Comb has exits, with no disruption.

=  

= Also, ARCs can form multi-ended structures called combs with better recover= y capabilities than a 2-ended structure.

=  

= For bicasting, the difference will be a bit more subtle. In a biconnected g= raph, ears will build non congruent path every time, but they might be far = away from shortest. ARCs will attempt to stay closer to shortest but may incur collisions, which are then resolved.=

=  

= Then ARCs can be employed for other purposes. We have an interesting approa= ch to the Olympic rings issue for instance.

=  

= Cheers,

=  

= Pascal

=  

--_000_E045AECD98228444A58C61C200AE1BD8221C5F69xmbrcdx01ciscoc_-- From gabor.sandor.enyedi@ericsson.com Tue Oct 16 03:09:15 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4DC21F8793 for ; Tue, 16 Oct 2012 03:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_PILL=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWyg2XjYwboZ for ; Tue, 16 Oct 2012 03:09:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3353521F8743 for ; Tue, 16 Oct 2012 03:09:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-b7-507d3248077b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 67.A1.04547.8423D705; Tue, 16 Oct 2012 12:09:12 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.45]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 16 Oct 2012 12:09:12 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "Pascal Thubert (pthubert)" , "rtgwg@ietf.org" Date: Tue, 16 Oct 2012 12:09:11 +0200 Subject: RE: Ears and ARCs Thread-Topic: Ears and ARCs Thread-Index: Ac2pY+C0voTGprBRTzSEqczmjWB0zQCGn6dA Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvra6HUW2AwfQGA4szC7Itzm2fzmQx Y8o7RosLb34zO7B4TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZZx7KFeyxrmh9cpK1gXGl ZhcjJ4eEgInEp02TmCBsMYkL99azdTFycQgJnGKU2PN7DZQzh1Fi4sVDjCBVbALBEtsfbGAD sUUEIiXuPdwJZjMLZEvs+d7MDmKzCKhKXNx/nbmLkYNDWEBKonmrM4gpIiAtsbOJH6LTSGLp hqdgE3kFwiW+H/zCDGILCfhI7Jr5GWwip4CvxI+OE6wgrYwCshIP11pALBKXuPVkPtTJAhJL 9pxnhrBFJV4+/scKYjMKyEh8WHoI6jA9iRtTp0DZ2hLLFr5mhlgrKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiFM5NzMxJLzfSSy3KTC4uzs/TK07dxAiMo4NbfqvuYLxzTuQQozQHi5I4 r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGNsU5v7VdOuXWVxUvOmX5+rQnlyniaKW bg2Pt7xYGikcL5wRtV7nVpHszq/33uR4Bk6f2//y5pzU8qUxf6U01s9M7tbpPnZRpuHDM0d2 L4sixoBahhpdG5+CCSZf2owbvNseTeGKfDI9s2Bi9JnnBgbv7r89I21x9fqPiVtdtpt8T2uO 7LAKVGIpzkg01GIuKk4EANbyfTBxAgAA Cc: "Dirk Anteunis \(danteuni\)" , "Patrice Bellagamba \(pbellaga\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 10:09:15 -0000 Great summarization, thanks. Just some small notes to this, which may make = the difference a bit clearer for the WG: =20 - In basic version, MRT can correct one failure, while ARCs can correct one= per ARC, which means that if there is a lucky multi-failure situation, ARC= s may solve it, while the basic MRT can't. - Current MRT is designed in this way (i.e. that it can avoid only one fail= ure), since avoiding multiple failures has its price: in some single failur= e cases, you may need to reroute packets multiple times with ARCs. Since re= routing means that a packet is using links and nodes multiple times (once i= n both direction), we thought that this is a greater problem then to wait f= or IGP when there are multiple unrelated failures at the same time. As an example consider a network very similar to the one in Pascal's exampl= e: 2 -- X1 -- 3 | | | | 1 -- X2 -- 4 | | | | ---Omega --- Let the ARCs be similar: 2<=3D> X1 <=3D>3 | | V V 1<=3D> X2 <=3D>4 | | | | -->Omega <-- If now node 1 goes down, then node 2 will reroute, packet will be decapsula= ted at node 4, and if we're unlucky and the shortest path would be 4->X2->1= ->Omega, X2 will need to reroute again. =20 So there is a * tradeoff *: basic MRT avoids single node or link failures, = while ARCs may hit a single failures multiple times. It's a management deci= sion which one is better. =20 What is important to mention is that all the previous was true for basic MR= T. However, it is very easy to see that the endpoint of the MRT detour is n= ot needed to be terminated at the destination (e.g. the egress router), but= it can be at several other nodes, e.g. at nodes, which are strictly closer= to the destination; this is what we call "endpoint selection". Naturally, = it is possible to select not only closer nodes as endpoints, when we can gu= arantee to avoid loops, so with some endpoint selection algorithm we may hi= t a single failure multiple times. The most exciting is that with a proper = ear selection (i.e. with selecting the ears using the algorithm described i= n ARC draft), and using proper endpoint selection (i.e. endpoint is the end= of the ear), we can get EXACTLY the same packet path, as with ARCs. :) Mor= eover, if I understood ARCs correctly, we can even reproduce the effect of = "combs". =20 Thus, I think that there is so much common in the two approaches that we ma= y need to consider to merge the two together somehow. =20 Gabor =20 ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Saturday, October 13, 2012 6:59 PM To: rtgwg@ietf.org Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) Subject: Ears and ARCs Dear WG: =20 I received an unicast a question that was, bascally, what's the difference = between MRT and ARCs. =20 >From the draft, hopefully it appears that an ARC is a new tool with new pro= perties, up to us to find interesting applications and maybe find new solut= ions to existing problems. The core of that tool is the reversible link, so= that we form downwards U-shaped arcs as opposed to arrows for routing. =20 But maybe the simpler approach is to make an exercise and see what we get -= my current understanding here, G=E1bor please correct me if I'm wrong -. =20 So, say we have this simple network.=20 =20 2 --- 3 | | | | 1 --- 4 | | | | Destination =20 I illustrated naming the routers with a value that matches my understanding= of the values of the partial order, to make things simple. =20 We end up with 2 ARCs and 2 ears, which are basically collocated. The ARC v= iew is =20 =20 =20 2 <=3D> 3 | | where links 2 - 3 and 1 - 4 are reversible. V V 1 <=3D> 4 | | V V Destination (Omega) =20 A first property of the ARCs can be seen immediately. ARCs are hierarchical= routing friendly.=20 We can collapse each ARC to simplify the representation which becomes: =20 2 | | V V 1 | | V V Destination =20 =20 If we break any link both ears and ARCs provide an alternate route, that's = FRR for you. Now let us see what happens with more than one breakage. There are double breakages that isolate a piece of the network, say if link= s 2 - 1 and 3 - 4 both break, there is no solution in the world that can ke= ep 3 connected to the Destination.=20 =20 Say now that 3 - 4 and 1 - Destination are both broken a 2 has a packet to = send. =20 =20 2 --- 3 | | =20 V X 1 --- 4 | | X V -------------Destination (Omega) =20 =20 - With ears, using the increasing order 2 will pass to 3, and 3 to 4 will f= ail.=20 So the packet is switched to decreasing order and the packet reaches 1 via = 2. 1 fails to send to the destination and we are screwed. =20 =20 PPPPP>> <3 2<=3D=3Dp=3D3 2 --- 3 2 --- 3 2 --- 3 -p= -> in shortest path =20 | | | | p | | | | | =3Dp=3D= > vs. returned =20 V X V X V X V X V X pa= cket 1 --- 4 1 --- 4 1 --- 4 1=3D=3Dp=3D>4 1 --- 4 | | | | | | | | | p packet = reaches Omega X V X V X V X V V V ------------------------------------------------------------------Destina= tion (Omega) =20 say that bad luck again the shortest path for 2 is via 1. 2 passes to 1 and since the ARC is exited the marking is removed. 1 fails to send to the destination, marks the packet and sends it along its= ARC. Packet reaches Destination via 4. =20 =20 IOW, ARCs form isolated recovery domains and allow up to as many breakages = as the ARC or Comb has exits, with no disruption. =20 Also, ARCs can form multi-ended structures called combs with better recover= y capabilities than a 2-ended structure. =20 For bicasting, the difference will be a bit more subtle. In a biconnected g= raph, ears will build non congruent path every time, but they might be far = away from shortest. ARCs will attempt to stay closer to shortest but may in= cur collisions, which are then resolved. =20 Then ARCs can be employed for other purposes. We have an interesting approa= ch to the Olympic rings issue for instance. =20 Cheers, =20 Pascal =20 From adrian@olddog.co.uk Tue Oct 16 20:42:46 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC52011E809B for ; Tue, 16 Oct 2012 20:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpE3rK5S1rxk for ; Tue, 16 Oct 2012 20:42:45 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 707F111E8097 for ; Tue, 16 Oct 2012 20:42:36 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9H3gYP3009439; Wed, 17 Oct 2012 04:42:34 +0100 Received: from 950129200 (ip-64-134-64-1.public.wayport.net [64.134.64.1]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q9H3gV0j009429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 04:42:33 +0100 From: "Adrian Farrel" To: Subject: AD review of draft-ietf-rtgwg-ipfrr-notvia-addresses Date: Wed, 17 Oct 2012 04:42:33 +0100 Message-ID: <05f201cdac19$72ac3260$58049720$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2sGTJmW66ysl61Tdae3e+mP1Kjfg== Content-Language: en-gb Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 03:42:47 -0000 Hi, I've done my usual AD review of your draft prior to issuing IETF last call and passing the I-D for IESG evaluation. The main purpose of the review is to catch issues that might come up in later reviews and to ensure that the document is ready for publication as and RFC. I only have a small point that needs to be resolved in a new revision of the document, so I will put it into "Revised I-D Needed" state in the data tracker and wait to hear from you. But I would also like the document shepherd to make an update to the write-up as described below. As always, all my comments are up for discussion and negotiation. Thanks for the work, Adrian === The Shepherd write-up says... > There is consensus in the WG to proceed with publication. Looking at the mailing list, I see no comments positive or negative during WG last call. What is more, I see no discussion of the I-D going back four years (at which point I lost the will to search further). How do you justify there being WG consensus for this document? I think this issue can be resolved by a revision to the write-up with some explanation of the justification for publishing this as a WG document. I would also like the write-up to explain the purpose of the document as discussed in the following point. --- I was also unclear why you want to publish the document at all. I see a note from Alvaro (extending the WG last call for an extra week) that says: > this document is being published as an Informational RFC for > completeness purposes...as has been discussed in the mailing list and > live meetings. So I think that gives me the intended purpose: completeness. But I don't know what that means, and the document doesn't help me at all. Furthermore, I couldn't find the discussion of this intention to publish on the mailing list. Based on some conversations with Stewart, I understand that the idea here is to capture the current state of discussions in the WG so that they are not lost. But I also assume that the WG has no interest in pursuing these ideas further. So it would be reasonable to add a significant note to the Abstract and the Introduction about the purpose. This would say something along the lines of... The idea is to capture the current state of discussions in the WG so that they are not lost, can be referenced, and might be picked up again later. The WG currently has no interest in pursuing these ideas further. It is not intended that this document as currently written should form the basis of an implementation or deployment. With this in mind, my review is considerably lighter than it would be for a standards track protocol specification, and I think the document will be fine for advancement. From pthubert@cisco.com Thu Oct 18 11:06:34 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE16F21F84BC for ; Thu, 18 Oct 2012 11:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.049 X-Spam-Level: X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MANGLED_PILL=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y59pnnJVKxuB for ; Thu, 18 Oct 2012 11:06:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A596921F84BB for ; Thu, 18 Oct 2012 11:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9248; q=dns/txt; s=iport; t=1350583593; x=1351793193; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hom6uWKiAFMGLezDeCxq0JImiEgZ/vXQ2UitrMBT7lI=; b=VgdHnbP+v6mRH94ipgvuB8e8VixzGEqym50IXXKzY3Vtza5wMYaNCFBs +731Ueo+7fUyjim/4qNWGsfA2Flb/c3cJuR24aOuXhTesnGEOShK4EVj5 leunJOyeafe9lQLXWwj7/VeLCIQ39LeRg88ru3hfTsbrAok23aESQGuN8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUGAHpEgFCtJXG//2dsb2JhbABFvCWEK4EIgiABAQEDARIBFD4UBQcGARgBBAEBCx05FAkJAQQBDQUIEwcMh1AGnHagN4tYhWJgAyYCh3uKF5F6gWuCb4FlCCo X-IronPort-AV: E=Sophos;i="4.80,608,1344211200"; d="scan'208";a="133132127" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 18 Oct 2012 18:06:33 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9II6X0M021084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 18:06:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.23]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 13:06:32 -0500 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= , "rtgwg@ietf.org" Subject: more subtle differences between Ears and ARCs Thread-Topic: more subtle differences between Ears and ARCs Thread-Index: Ac2tWGEJhqH4UppIRxecIBVy+Uo2tA== Date: Thu, 18 Oct 2012 18:06:31 +0000 Deferred-Delivery: Thu, 18 Oct 2012 17:46:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.246] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--37.026500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dirk Anteunis \(danteuni\)" , "Patrice Bellagamba \(pbellaga\)" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:06:35 -0000 Hello G=E1bor > So there is a * tradeoff *: basic MRT avoids single node or link failures= , while ARCs may hit a single failures multiple times. It's a management de= cision which one is better. Resisting multiple breakages is probably the most evident difference but mo= re subtle ones exist:=20 1) ARCs always bring you back quickly to a shortest path that is followed t= ill the end or the next breakage. With MRT, once we are in a plan B, that plan B cannot be qualified vs. shor= test path, and it can be a large detour. 2) ARCs have generalized the concept of the destination as well.=20 For instance Omega can be the set of border routers between this area and t= hat area, and the lowest ARC can actually join shortest path to two differe= nt border routers. 3) ARCs enable load balancing with recursive properties. If an ARC is congested at one edge, traffic can be more balanced towards th= e other. If both edges are congested, the congestion can be pushed back to = the edge of incoming ARCs. In fact, the red and blue tree are completely non overlapping and that's pr= obably an exaggerated property that yields a heavy cost.=20 With ARCs, we never to build end to end non-congruent paths though we know = they exist.=20 Did you consider how that impacts the bi-casting solutions?=20 Cheers, Pascal -----Original Message----- From: G=E1bor S=E1ndor Enyedi [mailto:gabor.sandor.enyedi@ericsson.com]=20 Sent: mardi 16 octobre 2012 12:09 To: Pascal Thubert (pthubert); rtgwg@ietf.org Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) Subject: RE: Ears and ARCs Great summarization, thanks. Just some small notes to this, which may make = the difference a bit clearer for the WG: =20 - In basic version, MRT can correct one failure, while ARCs can correct one= per ARC, which means that if there is a lucky multi-failure situation, ARC= s may solve it, while the basic MRT can't. - Current MRT is designed in this way (i.e. that it can avoid only one fail= ure), since avoiding multiple failures has its price: in some single failur= e cases, you may need to reroute packets multiple times with ARCs. Since re= routing means that a packet is using links and nodes multiple times (once i= n both direction), we thought that this is a greater problem then to wait f= or IGP when there are multiple unrelated failures at the same time. As an example consider a network very similar to the one in Pascal's exampl= e: 2 -- X1 -- 3 | | | | 1 -- X2 -- 4 | | | | ---Omega --- Let the ARCs be similar: 2<=3D> X1 <=3D>3 | | V V 1<=3D> X2 <=3D>4 | | | | -->Omega <-- If now node 1 goes down, then node 2 will reroute, packet will be decapsula= ted at node 4, and if we're unlucky and the shortest path would be 4->X2->1= ->Omega, X2 will need to reroute again. =20 So there is a * tradeoff *: basic MRT avoids single node or link failures, = while ARCs may hit a single failures multiple times. It's a management deci= sion which one is better. =20 What is important to mention is that all the previous was true for basic MR= T. However, it is very easy to see that the endpoint of the MRT detour is n= ot needed to be terminated at the destination (e.g. the egress router), but= it can be at several other nodes, e.g. at nodes, which are strictly closer= to the destination; this is what we call "endpoint selection". Naturally, = it is possible to select not only closer nodes as endpoints, when we can gu= arantee to avoid loops, so with some endpoint selection algorithm we may hi= t a single failure multiple times. The most exciting is that with a proper = ear selection (i.e. with selecting the ears using the algorithm described i= n ARC draft), and using proper endpoint selection (i.e. endpoint is the end= of the ear), we can get EXACTLY the same packet path, as with ARCs. :) Mor= eover, if I understood ARCs correctly, we can even reproduce the effect of = "combs". =20 Thus, I think that there is so much common in the two approaches that we ma= y need to consider to merge the two together somehow. =20 Gabor =20 ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of P= ascal Thubert (pthubert) Sent: Saturday, October 13, 2012 6:59 PM To: rtgwg@ietf.org Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) Subject: Ears and ARCs Dear WG: =20 I received an unicast a question that was, bascally, what's the difference = between MRT and ARCs. =20 >From the draft, hopefully it appears that an ARC is a new tool with new pro= perties, up to us to find interesting applications and maybe find new solut= ions to existing problems. The core of that tool is the reversible link, so= that we form downwards U-shaped arcs as opposed to arrows for routing. =20 But maybe the simpler approach is to make an exercise and see what we get -= my current understanding here, G=E1bor please correct me if I'm wrong -. =20 So, say we have this simple network.=20 =20 2 --- 3 | | | | 1 --- 4 | | | | Destination =20 I illustrated naming the routers with a value that matches my understanding= of the values of the partial order, to make things simple. =20 We end up with 2 ARCs and 2 ears, which are basically collocated. The ARC v= iew is =20 =20 =20 2 <=3D> 3 | | where links 2 - 3 and 1 - 4 are reversible. V V 1 <=3D> 4 | | V V Destination (Omega) =20 A first property of the ARCs can be seen immediately. ARCs are hierarchical= routing friendly.=20 We can collapse each ARC to simplify the representation which becomes: =20 2 | | V V 1 | | V V Destination =20 =20 If we break any link both ears and ARCs provide an alternate route, that's = FRR for you. Now let us see what happens with more than one breakage. There are double breakages that isolate a piece of the network, say if link= s 2 - 1 and 3 - 4 both break, there is no solution in the world that can ke= ep 3 connected to the Destination.=20 =20 Say now that 3 - 4 and 1 - Destination are both broken a 2 has a packet to = send. =20 =20 2 --- 3 | | =20 V X 1 --- 4 | | X V -------------Destination (Omega) =20 =20 - With ears, using the increasing order 2 will pass to 3, and 3 to 4 will f= ail.=20 So the packet is switched to decreasing order and the packet reaches 1 via = 2. 1 fails to send to the destination and we are screwed. =20 =20 PPPPP>> <3 2<=3D=3Dp=3D3 2 --- 3 2 --- 3 2 --- 3 -p= -> in shortest path =20 | | | | p | | | | | =3Dp=3D= > vs. returned =20 V X V X V X V X V X pa= cket 1 --- 4 1 --- 4 1 --- 4 1=3D=3Dp=3D>4 1 --- 4 | | | | | | | | | p packet = reaches Omega X V X V X V X V V V ------------------------------------------------------------------Destina= tion (Omega) =20 say that bad luck again the shortest path for 2 is via 1. 2 passes to 1 and since the ARC is exited the marking is removed. 1 fails to send to the destination, marks the packet and sends it along its= ARC. Packet reaches Destination via 4. =20 =20 IOW, ARCs form isolated recovery domains and allow up to as many breakages = as the ARC or Comb has exits, with no disruption. =20 Also, ARCs can form multi-ended structures called combs with better recover= y capabilities than a 2-ended structure. =20 For bicasting, the difference will be a bit more subtle. In a biconnected g= raph, ears will build non congruent path every time, but they might be far = away from shortest. ARCs will attempt to stay closer to shortest but may in= cur collisions, which are then resolved. =20 Then ARCs can be employed for other purposes. We have an interesting approa= ch to the Olympic rings issue for instance. =20 Cheers, =20 Pascal =20 From dirk.anteunis@cisco.com Fri Oct 19 01:26:56 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D1D21F84A2 for ; Fri, 19 Oct 2012 01:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XuK5xxy13u5 for ; Fri, 19 Oct 2012 01:26:55 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3410721F843D for ; Fri, 19 Oct 2012 01:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2310; q=dns/txt; s=iport; t=1350635215; x=1351844815; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=HR/d22sdbzhMpVjSCS4lA4aCUaR3hCkQ/1NIrD9gOpM=; b=TANbmdtPF2xfG9V8aL1Iyaw/LurIJBO3nqjB5tTEEvfMTW4kwg3z7VyM FJZhYRNyFHrkwnLnjd/zFuDmObnaoPIDHmcQCcUXSXT6TixvyIM5LxoF6 2G5V9pab7qAbHzfOrJwa83g5BEeNUsa+DqSLe4azEXCsKt6FF1NM7nUFJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFANgVCQ/khM/2dsb2JhbABFwF2BCIIgAQEBBAEBAQ8BJTYKDQQLEAEEAQEBCRYIBwkDAgECARUfCQgTBgIBAQUZh2ILnSygI4tYgx+DIwOOAYdqgRWNNIFrgnE X-IronPort-AV: E=Sophos;i="4.80,612,1344211200"; d="scan'208";a="8927584" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 19 Oct 2012 08:26:54 +0000 Received: from printer-nice-144-254-53-94.cisco.com (printer-nice-144-254-53-94.cisco.com [144.254.53.94]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9J8Qr6X025576 for ; Fri, 19 Oct 2012 08:26:53 GMT Message-ID: <50810ECD.9020405@cisco.com> Date: Fri, 19 Oct 2012 10:26:53 +0200 From: Dirk User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: draft-thubert-rtgwg-arc-bicast-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 08:26:56 -0000 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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: jeudi 11 octobre 2012 16:43 > To: Pascal Thubert (pthubert) > Cc: ice@cisco.com > 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 > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From internet-drafts@ietf.org Fri Oct 19 11:55:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CD121F87A3; Fri, 19 Oct 2012 11:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVAMPC8Vla+Z; Fri, 19 Oct 2012 11:55:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0657621F87A2; Fri, 19 Oct 2012 11:55:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-framework-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121019185506.13244.5932.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 11:55:06 -0700 Cc: rtgwg@ietf.org X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:55:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Area Working Group Working Group = of the IETF. Title : Composite Link Framework in Multi Protocol Label Switchi= ng (MPLS) Author(s) : So Ning Dave McDysan Eric Osborne Lucy Yong Curtis Villamizar Filename : draft-ietf-rtgwg-cl-framework-02.txt Pages : 43 Date : 2012-10-19 Abstract: This document specifies a framework for support of composite link in MPLS networks. A composite link consists of a group of homogenous or non-homogenous links that have the same forward adjacency and can be considered as a single TE link or an IP link in routing. A composite link relies on its component links to carry the traffic over the composite link. Applicability is described for a single pair of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of layer networks connecting MPLS-capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-framework-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtgwg-cl-framework-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From curtis@occnc.com Fri Oct 19 12:12:22 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C2221F87A3 for ; Fri, 19 Oct 2012 12:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKGlQbXaQ4xA for ; Fri, 19 Oct 2012 12:12:22 -0700 (PDT) Received: from gateway1.orleans.occnc.com (gateway1.orleans.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id C573B21F878C for ; Fri, 19 Oct 2012 12:12:21 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id q9JJCI0H038298; Fri, 19 Oct 2012 15:12:19 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201210191912.q9JJCI0H038298@gateway1.orleans.occnc.com> To: rtgwg@ietf.org Subject: draft-ietf-rtgwg-cl-framework-02 - please comment From: Curtis Villamizar Date: Fri, 19 Oct 2012 15:12:18 -0400 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:12:22 -0000 RTGWG, An update to draft-ietf-rtgwg-cl-framework-02 has just been submitted. Please read this document and comment prior to the WG meeting. I've requested a long time slot so we can get into any technical issues with the document. Significant changes are: 1. New "1.5 Document Issues" subsection (part of "Introduction"). The purpose of this section is to focus co-author and WG discussion on things in the document that are known to need attention. Please read and comment on this. It wouldn't hurt to read the whole document, but at least read this 1.5 pages. 2. Entropy label is featured more prominently as *the solution* to carrying LSP with strict packet ordering, particularly when carrying such LSP within other larger LSP. Changes to referenced drafts: 1. draft-ietf-mpls-entropy-label completed the IETF process and is now in the editor's queue. 2. draft-villamizar-mpls-tp-multipath has been simplified down from 35 pages to 9 pages and essentially just proposes to use ELI and EL to support MPLS-TP LSP over MPLS LSP as a client layer. Extensive discussion of multipath and TP requirements are removed. Alternates other than EL are removed. Suggestions that another method of limiting label stack depeth based on LSP lookup is removed, therefore the one Infinera IPR can be removed. 3. a lot of drafts referenced by CL framework are expired and only partially meet the set of requirements defined in CL requirements in the area they address. For example, if there really is interest in meeting the delay requirements, then the delay metric draft needs to be picked up, dusted off, checked agains CL requirements, edited as needed, and resubmited. A list of drafts that have expired is in "Document Issues" subsection. See you in Atlanta. Regardless of whether you are going, please comment on the WG mailing list. Thanks, Curtis ------- Forwarded Message From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-rtgwg-cl-framework-02.txt Message-ID: <20121019185506.13244.5932.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2012 11:55:06 -0700 Cc: rtgwg@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Area Working Group Working Group of the IETF. Title : Composite Link Framework in Multi Protocol Label Switching (MPLS) Author(s) : So Ning Dave McDysan Eric Osborne Lucy Yong Curtis Villamizar Filename : draft-ietf-rtgwg-cl-framework-02.txt Pages : 43 Date : 2012-10-19 Abstract: This document specifies a framework for support of composite link in MPLS networks. A composite link consists of a group of homogenous or non-homogenous links that have the same forward adjacency and can be considered as a single TE link or an IP link in routing. A composite link relies on its component links to carry the traffic over the composite link. Applicability is described for a single pair of MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of layer networks connecting MPLS-capable nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-cl-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtgwg-cl-framework-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-cl-framework-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ------- End of Forwarded Message From stephane.litkowski@orange.com Mon Oct 22 06:06:58 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FE021F8B72 for ; Mon, 22 Oct 2012 06:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raG2tex5bdIT for ; Mon, 22 Oct 2012 06:06:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09021F846C for ; Mon, 22 Oct 2012 06:06:57 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8299232448A for ; Mon, 22 Oct 2012 15:06:56 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 648D923804B for ; Mon, 22 Oct 2012 15:06:56 +0200 (CEST) Received: from PUEXCB2F.nanterre.francetelecom.fr ([10.64.14.45]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 22 Oct 2012 15:06:56 +0200 From: To: "rtgwg@ietf.org" Date: Mon, 22 Oct 2012 15:06:54 +0200 Subject: I-D Action: draft-litkowski-rtgwg-lfa-manageability-00.txt Thread-Topic: I-D Action: draft-litkowski-rtgwg-lfa-manageability-00.txt Thread-Index: Ac2wVhwp3HfgLfC+SsWt3bMIsyYHsg== Message-ID: <31224_1350911216_508544F0_31224_2_1_EEE55384044474429A926C625D0FCC810421D50081@PUEXCB2F.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_EEE55384044474429A926C625D0FCC810421D50081PUEXCB2Fnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 13:06:58 -0000 --_000_EEE55384044474429A926C625D0FCC810421D50081PUEXCB2Fnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, We submitted last week a new draft concerning operation of LFA and especial= ly how to manage tie breakers. We would be pleased to receive feedbacks on what is currently described and= possibily some other topics we would need to address based on your own exp= eriences. Thanks in advance, Stephane -------------------- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Operational management of Loop Free Alternates Author(s) : Stephane Litkowski Bruno Decraene Clarence Filsfils Kamran Raza Filename : draft-litkowski-rtgwg-lfa-manageability-00.txt Pages : 16 Date : 2012-10-15 Abstract: Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic. Following first deployment experience, this document provides operational feedback on LFA, highlights some limitations and proposes a set of refinements to address those limitations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-lfa-manageability There's also a htmlized version available at: http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-manageability-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_EEE55384044474429A926C625D0FCC810421D50081PUEXCB2Fnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 folks,
 
We submit= ted last=20 week a new draft concerning operation of LFA and especially how to manage t= ie=20 breakers.
We would = be pleased=20 to receive feedbacks on what is currently described and possibily some othe= r=20 topics we would need to address based on your own=20 experiences.
 
Thanks in= =20 advance,
 
Stephane
 
--------------------
 
A New Internet-Draft is available fro= m the=20 on-line Internet-Drafts=20 directories.


Title       &nb= sp;  =20 : Operational management of Loop Free=20 Alternates
Author(s)       : Stephane=20 Litkowski
          &n= bsp;            = ;  =20 Bruno=20 Decraene
          &nb= sp;            =   =20 Clarence=20 Filsfils
          &nb= sp;            =   =20 Kamran Raza
Filename        :=20 draft-litkowski-rtgwg-lfa-manageability-00.txt
Pages   &= nbsp;      =20 : 16
Date          &n= bsp;=20 : 2012-10-15

Abstract:
   Loop Free Alternates (LFA), a= s=20 defined in RFC 5286 is an IP Fast
   ReRoute (IP FRR) mechanis= m=20 enabling traffic protection for IP
   traffic.  Following= =20 first deployment experience, this document
   provides operati= onal=20 feedback on LFA, highlights some limitations and
   proposes a= set=20 of refinements to address those limitations.


The IETF datatracke= r=20 status page for this draft is:
https://datatracker.ietf.org/doc/draft-litkowski-rtgwg-lfa-m= anageability

There's=20 also a htmlized version available at:
http://tools.ietf.org/html/draft-litkowski-rtgwg-lfa-managea= bility-00


Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

 
 
 
_____=
___________________________________________________________________________=
_________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_EEE55384044474429A926C625D0FCC810421D50081PUEXCB2Fnante_-- From bruno.decraene@orange.com Mon Oct 22 07:28:55 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED52D21F894D for ; Mon, 22 Oct 2012 07:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRW-ThsR2lSQ for ; Mon, 22 Oct 2012 07:28:54 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C009821F8A62 for ; Mon, 22 Oct 2012 07:28:53 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B389D18C347; Mon, 22 Oct 2012 16:28:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8903B4C069; Mon, 22 Oct 2012 16:28:52 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 22 Oct 2012 16:28:52 +0200 From: To: Ahmed Bashandy Subject: RE: I-D Action: draft-rtgwg-bgp-pic-00.txt Thread-Topic: I-D Action: draft-rtgwg-bgp-pic-00.txt Thread-Index: AQHNn+Q9oqJGmysl/0iR4YxQB6CuyJfFgQmg Date: Mon, 22 Oct 2012 14:28:52 +0000 Message-ID: <23179_1350916132_50855824_23179_2723_2_53C29892C857584299CBF5D05346208A0DAF95@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <20121001140838.25089.41031.idtracker@ietfa.amsl.com> <5069ADDB.1040404@cisco.com> In-Reply-To: <5069ADDB.1040404@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.22.133424 Cc: "Pradosh Mohapatra \(pmohapat\)" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:28:55 -0000 Hi Ahmed, 1) Multiple layer of BGP indirections In addition to your 2 examples, could you please add an example with the se= amless MPLS architecture where a VPN (BGP) routes is resolved using a RFC 3= 107 (BGP) routes, itself resolved using an IGP route. Hence 2 levels of ind= irections: BGP =1B$B"*=1B(B BGP =1B$B"*=1B(B IGP. In the same vein, could the draft indicate the number of such indirection t= hat an implementation compliant with your draft must support? 2) BGP Best external Could you please elaborate on how PIC edge behaves for non labeled BGP rout= es when BGP best external is used? In particular, a priori, it looks to me = that the backup egress PE would loop back to packets to the nominal egress = PE (which would itself loop it back to the backup PE). Thanks, Regards, Bruno From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= hmed Bashandy Sent: Monday, October 01, 2012 4:51 PM To: rtgwg@ietf.org Cc: Pradosh Mohapatra (pmohapat) Subject: Fwd: I-D Action: draft-rtgwg-bgp-pic-00.txt Hi, This draft provides an overview of BGP prefix independent convergence and h= ow it is possible to achieve sub-second and, for certain local failures, su= b-50msec convergence using hierarchical and shared FIB chain design All comments and suggestions are most welcomed Thanks Ahmed -------- Original Message --------=20 Subject:=20 I-D Action: draft-rtgwg-bgp-pic-00.txt Date:=20 Mon, 1 Oct 2012 07:08:38 -0700 From:=20 Reply-To:=20 To:=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Abstract Author(s) : Ahmed Bashandy Clarence Filsfils Prodosh Mohapatra Filename : draft-rtgwg-bgp-pic-00.txt Pages : 19 Date : 2012-10-01 Abstract: In the network comprising thousands of iBGP peers exchanging millions of routes, many routes are reachable via more than one path. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed a technique by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding chains in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete transparency and automation, and zero management and provisioning effort The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rtgwg-bgp-pic There's also a htmlized version available at: http://tools.ietf.org/html/draft-rtgwg-bgp-pic-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From pthubert@cisco.com Mon Oct 22 09:20:04 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B8721F8A6E for ; Mon, 22 Oct 2012 09:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKIh9QVBuDrz for ; Mon, 22 Oct 2012 09:20:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 66E0F21F89B3 for ; Mon, 22 Oct 2012 09:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4641; q=dns/txt; s=iport; t=1350922803; x=1352132403; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZH5/eo7+I9AsirA5SGThp9Ma+QaA8dkmFkkwHbcZdmQ=; b=bpIEvMfzId+p5rWzAOxGOis7eghvcNLbfY8vHjBI4ceXkpLMXwgyciYl BO/wbc5T7VUy01/QjcxAUr2u3/3KdRp8aoRHtqyl3C2dgywn3aGSV1pDn 3hCaiFBxUJ6ewGaeY7WmAKZCKBqRNskKJBLQ4EhfQIr6/IXovAQMR/pR9 w=; X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="134171192" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 22 Oct 2012 16:20:03 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9MGK20V009509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 16:20:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 11:20:02 -0500 From: "Pascal Thubert (pthubert)" To: Dirk , "rtgwg@ietf.org" Subject: RE: draft-thubert-rtgwg-arc-bicast-00.txt Thread-Topic: draft-thubert-rtgwg-arc-bicast-00.txt Thread-Index: AQHNsHEWGb3G1t9LAEa1icJ9J4P68w== Date: Mon, 22 Oct 2012 16:20:02 +0000 Deferred-Delivery: Mon, 22 Oct 2012 16:20:00 +0000 Message-ID: References: <50810ECD.9020405@cisco.com> In-Reply-To: <50810ECD.9020405@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--43.562300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:20:04 -0000 Hi Dirk: Thanks a bunch for your comments. For the (PIM-like) upward bi-casting operation we do untangle the paths, a= nd that is probably worth the pain since we are paving the way for high vol= umes 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 reduc= e the chances of collisions, but not to add too much complexity in the proc= ess.=20 The proposed algorithm is a simple inheritance, and does not require any gl= obal knowledge, so it can work in a DV type operation. I'm unclear whether such simple computation can really untangle links easil= y. 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 i= nherited the idea that we need completely non-congruent paths to get redund= ancy. This is probably doubly a mistake:=20 IOH, one gets more than he bargained for, since the non-congruent path allo= w redundancy even if all the nodes on a same path break, though the first b= reakage on that path already condemns that path. What's the point? OTOH, the real life cases of multiple breakages like Shared Risk Link Group= s are not nicely aligned along a single path so the full separation of the = 2 path does not provide additional guarantees.=20 ARCs do not pay the price of determining non-congruent paths to the destina= tion. ARCs only find non-congruent paths to 2 close Safe Nodes which are, = in many occasions, neighbors. From this results an economy of computation a= nd 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: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of D= irk Sent: vendredi 19 octobre 2012 10:27 To: rtgwg@ietf.org 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 cro= ssing paths, but also the shorter the paths are (except for pathological li= nk 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 sign= alling 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 environme= nts. > > Cheers, > > Pascal > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: jeudi 11 octobre 2012 16:43 > To: Pascal Thubert (pthubert) > Cc: ice@cisco.com > Subject: New Version Notification for=20 > 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-bicas= t-00 > > > Abstract: > This draft introduces methods that leverage the concept of ARC to > enable bicasting operations. > > > = =20 > > > The IETF Secretariat > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From srini@ece.arizona.edu Mon Oct 22 11:45:40 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF30E21F84DC for ; Mon, 22 Oct 2012 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PILL=2.3, MANGLED_SOLTNS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm2P278bUD31 for ; Mon, 22 Oct 2012 11:45:30 -0700 (PDT) Received: from smtpgate.email.arizona.edu (odessa.email.arizona.edu [128.196.130.200]) by ietfa.amsl.com (Postfix) with ESMTP id 149AB21F849D for ; Mon, 22 Oct 2012 11:45:29 -0700 (PDT) Received: from mailgators_amavis (nexavir.email.arizona.edu [128.196.130.233]) by smtpgate.email.arizona.edu (Postfix) with ESMTP id 8BF646A8BA4 for ; Mon, 22 Oct 2012 11:45:29 -0700 (MST) X-Virus-Scanned: amavisd-new at email.arizona.edu Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by smtpgate.email.arizona.edu (Postfix) with ESMTPSA id 45EF56A8CD6 for ; Mon, 22 Oct 2012 11:45:25 -0700 (MST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2138646pad.31 for ; Mon, 22 Oct 2012 11:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.88.4 with SMTP id bc4mr28216663pab.42.1350931524628; Mon, 22 Oct 2012 11:45:24 -0700 (PDT) Received: by 10.66.221.69 with HTTP; Mon, 22 Oct 2012 11:45:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 11:45:24 -0700 Message-ID: Subject: Re: rtgwg Digest, Vol 94, Issue 12 From: Srini To: rtgwg@ietf.org, pthubert@cisco.com, gabor.sandor.enyedi@ericsson.com, pbellaga@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:45:41 -0000 Dear Pascal & Gabor: I was looking at the examples that Pascal gave. One of the key points that's missed in MRT can tolerate at most one link failure in an ear. Once the packet moves from one ear to another, it can tolerate another failure. If you assume that you have one bit that indicates whether you have seen a failure or not, you can view it as this being reset every time the packet moves from one ear to another. This property is well-known, please see the paper below: Path Splicing with Guaranteed Fault Tolerance T. Erlebach and A. Mereu GLOBECOM 2009 With this the behavior of MRT and ARC are the same in the examples that Pascale listed out in the email below. Best regards, Srini. Associate Professor, ECE & CS University of Arizona http://srini.ca On Thu, Oct 18, 2012 at 12:00 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/rtgwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send rtgwg mailing list submissions to > rtgwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rtgwg > or, via email, send a message with subject or body 'help' to > rtgwg-request@ietf.org > > You can reach the person managing the list at > rtgwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of rtgwg digest..." > > Today's Topics: > > 1. more subtle differences between Ears and ARCs > (Pascal Thubert (pthubert)) > 2. (no subject) > > > ---------- Forwarded message ---------- > From: "Pascal Thubert (pthubert)" > To: "G=E1bor S=E1ndor Enyedi" , "rtgwg@= ietf.org" > Cc: "Dirk Anteunis \(danteuni\)" , "Patrice Bellagamb= a \(pbellaga\)" > Date: Thu, 18 Oct 2012 18:06:31 +0000 > Subject: more subtle differences between Ears and ARCs > Hello G=E1bor > >> So there is a * tradeoff *: basic MRT avoids single node or link failure= s, while ARCs may hit a single failures multiple times. It's a management d= ecision which one is better. > > Resisting multiple breakages is probably the most evident difference but = more subtle ones exist: > > 1) ARCs always bring you back quickly to a shortest path that is followed= till the end or the next breakage. > With MRT, once we are in a plan B, that plan B cannot be qualified vs. sh= ortest path, and it can be a large detour. > > 2) ARCs have generalized the concept of the destination as well. > For instance Omega can be the set of border routers between this area and= that area, and the lowest ARC can actually join shortest path to two diffe= rent border routers. > > 3) ARCs enable load balancing with recursive properties. > If an ARC is congested at one edge, traffic can be more balanced towards = the other. If both edges are congested, the congestion can be pushed back t= o the edge of incoming ARCs. > > In fact, the red and blue tree are completely non overlapping and that's = probably an exaggerated property that yields a heavy cost. > With ARCs, we never to build end to end non-congruent paths though we kno= w they exist. > > Did you consider how that impacts the bi-casting solutions? > > Cheers, > > Pascal > > > -----Original Message----- > From: G=E1bor S=E1ndor Enyedi [mailto:gabor.sandor.enyedi@ericsson.com] > Sent: mardi 16 octobre 2012 12:09 > To: Pascal Thubert (pthubert); rtgwg@ietf.org > Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) > Subject: RE: Ears and ARCs > > Great summarization, thanks. Just some small notes to this, which may mak= e the difference a bit clearer for the WG: > > - In basic version, MRT can correct one failure, while ARCs can correct o= ne per ARC, which means that if there is a lucky multi-failure situation, A= RCs may solve it, while the basic MRT can't. > - Current MRT is designed in this way (i.e. that it can avoid only one fa= ilure), since avoiding multiple failures has its price: in some single fail= ure cases, you may need to reroute packets multiple times with ARCs. Since = rerouting means that a packet is using links and nodes multiple times (once= in both direction), we thought that this is a greater problem then to wait= for IGP when there are multiple unrelated failures at the same time. > As an example consider a network very similar to the one in Pascal's exam= ple: > > 2 -- X1 -- 3 > | | > | | > 1 -- X2 -- 4 > | | > | | > ---Omega --- > > Let the ARCs be similar: > > 2<=3D> X1 <=3D>3 > | | > V V > 1<=3D> X2 <=3D>4 > | | > | | > -->Omega <-- > > If now node 1 goes down, then node 2 will reroute, packet will be decapsu= lated at node 4, and if we're unlucky and the shortest path would be 4->X2-= >1->Omega, X2 will need to reroute again. > > So there is a * tradeoff *: basic MRT avoids single node or link failures= , while ARCs may hit a single failures multiple times. It's a management de= cision which one is better. > > What is important to mention is that all the previous was true for basic = MRT. However, it is very easy to see that the endpoint of the MRT detour is= not needed to be terminated at the destination (e.g. the egress router), b= ut it can be at several other nodes, e.g. at nodes, which are strictly clos= er to the destination; this is what we call "endpoint selection". Naturally= , it is possible to select not only closer nodes as endpoints, when we can = guarantee to avoid loops, so with some endpoint selection algorithm we may = hit a single failure multiple times. The most exciting is that with a prope= r ear selection (i.e. with selecting the ears using the algorithm described= in ARC draft), and using proper endpoint selection (i.e. endpoint is the e= nd of the ear), we can get EXACTLY the same packet path, as with ARCs. :) M= oreover, if I understood ARCs correctly, we can even reproduce the effect o= f "combs". > > Thus, I think that there is so much common in the two approaches that we = may need to consider to merge the two together somehow. > > Gabor > > > > > ________________________________ > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of= Pascal Thubert (pthubert) > Sent: Saturday, October 13, 2012 6:59 PM > To: rtgwg@ietf.org > Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) > Subject: Ears and ARCs > > > > Dear WG: > > > > I received an unicast a question that was, bascally, what's the differenc= e between MRT and ARCs. > > > > > > ---------- Forwarded message ---------- > From: > To: > Cc: > Date: > Subject: > perties, up to us to find interesting applications and maybe find new sol= ut=3D > ions to existing problems. The core of that tool is the reversible link, = so=3D > that we form downwards U-shaped arcs as opposed to arrows for routing. > > =3D20 > > But maybe the simpler approach is to make an exercise and see what we get= -=3D > my current understanding here, G=3DE1bor please correct me if I'm wrong = -. > > =3D20 > > So, say we have this simple network.=3D20 > > =3D20 > > 2 --- 3 > > | | > > | | > > 1 --- 4 > > | | > > | | > > Destination > > =3D20 > > I illustrated naming the routers with a value that matches my understandi= ng=3D > of the values of the partial order, to make things simple. > > =3D20 > > We end up with 2 ARCs and 2 ears, which are basically collocated. The ARC= v=3D > iew is > > =3D20 > > =3D20 > > =3D20 > > 2 <=3D3D> 3 > > | | where links 2 - 3 and 1 - 4 are reversible. > > V V > > 1 <=3D3D> 4 > > | | > > V V > > Destination (Omega) > > =3D20 > > A first property of the ARCs can be seen immediately. ARCs are hierarchic= al=3D > routing friendly.=3D20 > > We can collapse each ARC to simplify the representation which becomes: > > =3D20 > > 2 > > | | > > V V > > 1 > > | | > > V V > > Destination > > =3D20 > > =3D20 > > If we break any link both ears and ARCs provide an alternate route, that'= s =3D > FRR for you. Now let us see what happens with more than one breakage. > > There are double breakages that isolate a piece of the network, say if li= nk=3D > s 2 - 1 and 3 - 4 both break, there is no solution in the world that can = ke=3D > ep 3 connected to the Destination.=3D20 > > =3D20 > > Say now that 3 - 4 and 1 - Destination are both broken a 2 has a packet t= o =3D > send. > > =3D20 > > =3D20 > > 2 --- 3 > > | | =3D20 > > V X > > 1 --- 4 > > | | > > X V > > -------------Destination (Omega) > > =3D20 > > =3D20 > > - With ears, using the increasing order 2 will pass to 3, and 3 to 4 will= f=3D > ail.=3D20 > > So the packet is switched to decreasing order and the packet reaches 1 vi= a =3D > 2. > > 1 fails to send to the destination and we are screwed. > > =3D20 > > =3D20 > > PPPPP>> < ing order > > | | | | p | ppp packet progressing in decre= as=3D > ing order > > V X V X p X =3D20 > > 1 --- 4 1 --- 4 V --- 4 When packet reaches 1 must be = dr=3D > opped =3D20 > > | | | | | | because increasing again may c= au=3D > se a loop =3D20 > > X V X V X V =3D20 > > -----------------------------------------Destination (Omega) > > =3D20 > > =3D20 > > - With ARCS, say that bad luck the shortest path is via 3. 2 passes to 3 = an=3D > d 3 to 4 will fail.=3D20 > > So 3 u-turns the packet along the ARC, back to 2.=3D20 > > Some tagging indicates that the packet was u-turned which can happen only= o=3D > nce in that ARC. > > =3D20 > > 2--p->3 2<=3D3D=3D3Dp=3D3D3 2 --- 3 2 --- 3 2 --= - 3 -p=3D > -> in shortest path =3D20 > > | | | | p | | | | | =3D3D= p=3D3D=3D >> vs. returned =3D20 > > V X V X V X V X V X = pa=3D > cket > > 1 --- 4 1 --- 4 1 --- 4 1=3D3D=3D3Dp=3D3D>4 1 --= - 4 > > | | | | | | | | | p packe= t =3D > reaches Omega > > X V X V X V X V V V > > ------------------------------------------------------------------Desti= na=3D > tion (Omega) > > =3D20 > > say that bad luck again the shortest path for 2 is via 1. > > 2 passes to 1 and since the ARC is exited the marking is removed. > > 1 fails to send to the destination, marks the packet and sends it along i= ts=3D > ARC. > > Packet reaches Destination via 4. > > =3D20 > > =3D20 > > IOW, ARCs form isolated recovery domains and allow up to as many breakage= s =3D > as the ARC or Comb has exits, with no disruption. > > =3D20 > > Also, ARCs can form multi-ended structures called combs with better recov= er=3D > y capabilities than a 2-ended structure. > > =3D20 > > For bicasting, the difference will be a bit more subtle. In a biconnected= g=3D > raph, ears will build non congruent path every time, but they might be fa= r =3D > away from shortest. ARCs will attempt to stay closer to shortest but may = in=3D > cur collisions, which are then resolved. > > =3D20 > > Then ARCs can be employed for other purposes. We have an interesting appr= oa=3D > ch to the Olympic rings issue for instance. > > =3D20 > > Cheers, > > =3D20 > > Pascal > > =3D20 > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From pthubert@cisco.com Tue Oct 23 02:41:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C884321F861F for ; Tue, 23 Oct 2012 02:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.049 X-Spam-Level: X-Spam-Status: No, score=-8.049 tagged_above=-999 required=5 tests=[AWL=-2.050, BAYES_00=-2.599, MANGLED_PILL=2.3, MANGLED_SOLTNS=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhjgJwEJ3BBT for ; Tue, 23 Oct 2012 02:41:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2D921F8617 for ; Tue, 23 Oct 2012 02:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13912; q=dns/txt; s=iport; t=1350985265; x=1352194865; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=flgQFKSdXM0i/KtE269Nf3kmpvqUNJnBugHQVgf8FqQ=; b=RVQQwrWnrUslMCoAwqneNuvlmda/vV3uIwbWo34lR0xQ0ZSPA9Q0QItW sw3OkzNsU5xq4WO4KvOgKuqNIdR0Tq6xyLzIwRLOOcgQLjK2wI08TaYEK m9ExjnPyHUYTkkEw9rqD2n/2qyrXXk21IzzySmkuGdHQZ8IGesEFaYhZP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAAVlhlCtJV2Z/2dsb2JhbABEDr0jhDKBCIIeAQEBBAEBAQ8BFCcXCRcEAgEIEAEDAQEBAQoCARoHJwoBFAkIAgQBEggTAgQBDIdWC5xVj1yQR4tfhX5gAyYCh32KGoRJjTeBa4IyPYFjAggNHg X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134395218" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2012 09:41:04 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9N9f4Ln003198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 09:41:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 04:41:04 -0500 From: "Pascal Thubert (pthubert)" To: Srini , "rtgwg@ietf.org" , "gabor.sandor.enyedi@ericsson.com" , "Patrice Bellagamba (pbellaga)" Subject: RE: rtgwg Digest, Vol 94, Issue 12 Thread-Topic: rtgwg Digest, Vol 94, Issue 12 Thread-Index: AQHNsIVoaKtgmit4zkCktmctNJf+RJfGnl7w Date: Tue, 23 Oct 2012 09:41:03 +0000 Deferred-Delivery: Tue, 23 Oct 2012 09:40:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--57.172500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:41:06 -0000 Hello Srini: All the trouble is to determine whether a second reroute will place you bac= k on the way of the first failure. If you can't avoid that then the traffic could end up following a path that= looks like the infinite sign, between twisted ears (that must hurt!). If ears are organized as ARCs, that is they form a directed acyclic graph, = and packets can exit each end of the ear, then we have the desired properti= es.=20 But then, hey, ears became ARCs in the process; just place a cursor somewhe= re and that we inherit all sorts of good properties on the way like shortes= t path, load balancing and optimized bicasting.=20 In the meantime, the partial order that G=E1bor described in this thread in= end-to-end, and so it builds 2 non-congruent end-to-end paths. Though this is what he, too, clearly wants to achieve next, the current des= cription fails to isolate and organize smaller recovery domains, like ARCs. The paper you indicate seems to be generalizing MRT to build more than 2 tr= ees; how does this change the bottom line? Cheers, Pascal -----Original Message----- From: Srini [mailto:srini@ece.arizona.edu]=20 Sent: lundi 22 octobre 2012 20:45 To: rtgwg@ietf.org; Pascal Thubert (pthubert); gabor.sandor.enyedi@ericsson= .com; Patrice Bellagamba (pbellaga) Subject: Re: rtgwg Digest, Vol 94, Issue 12 Dear Pascal & Gabor: I was looking at the examples that Pascal gave. One of the key points that= 's missed in MRT can tolerate at most one link failure in an ear. Once the packet moves from one ear to another, it can tolerate another fail= ure. If you assume that you have one bit that indicates whether you have s= een a failure or not, you can view it as this being reset every time the pa= cket moves from one ear to another. This property is well-known, please see the paper below: Path Splicing with Guaranteed Fault Tolerance T. Erlebach and A. Mereu GLOB= ECOM 2009 With this the behavior of MRT and ARC are the same in the examples that Pas= cale listed out in the email below. Best regards, Srini. Associate Professor, ECE & CS University of Arizona http://srini.ca On Thu, Oct 18, 2012 at 12:00 PM, wrote: > If you have received this digest without all the individual message=20 > attachments you will need to update your digest options in your list=20 > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/rtgwg > > Click the 'Unsubscribe or edit options' button, log in, and set "Get=20 > MIME or Plain Text Digests?" to MIME. You can set this option=20 > globally for all the list digests you receive at this point. > > > > Send rtgwg mailing list submissions to > rtgwg@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rtgwg > or, via email, send a message with subject or body 'help' to > rtgwg-request@ietf.org > > You can reach the person managing the list at > rtgwg-owner@ietf.org > > When replying, please edit your Subject line so it is more specific=20 > than "Re: Contents of rtgwg digest..." > > Today's Topics: > > 1. more subtle differences between Ears and ARCs > (Pascal Thubert (pthubert)) > 2. (no subject) > > > ---------- Forwarded message ---------- > From: "Pascal Thubert (pthubert)" > To: "G=E1bor S=E1ndor Enyedi" ,=20 > "rtgwg@ietf.org" > Cc: "Dirk Anteunis \(danteuni\)" , "Patrice=20 > Bellagamba \(pbellaga\)" > Date: Thu, 18 Oct 2012 18:06:31 +0000 > Subject: more subtle differences between Ears and ARCs Hello G=E1bor > >> So there is a * tradeoff *: basic MRT avoids single node or link failure= s, while ARCs may hit a single failures multiple times. It's a management d= ecision which one is better. > > Resisting multiple breakages is probably the most evident difference but = more subtle ones exist: > > 1) ARCs always bring you back quickly to a shortest path that is followed= till the end or the next breakage. > With MRT, once we are in a plan B, that plan B cannot be qualified vs. sh= ortest path, and it can be a large detour. > > 2) ARCs have generalized the concept of the destination as well. > For instance Omega can be the set of border routers between this area and= that area, and the lowest ARC can actually join shortest path to two diffe= rent border routers. > > 3) ARCs enable load balancing with recursive properties. > If an ARC is congested at one edge, traffic can be more balanced towards = the other. If both edges are congested, the congestion can be pushed back t= o the edge of incoming ARCs. > > In fact, the red and blue tree are completely non overlapping and that's = probably an exaggerated property that yields a heavy cost. > With ARCs, we never to build end to end non-congruent paths though we kno= w they exist. > > Did you consider how that impacts the bi-casting solutions? > > Cheers, > > Pascal > > > -----Original Message----- > From: G=E1bor S=E1ndor Enyedi [mailto:gabor.sandor.enyedi@ericsson.com] > Sent: mardi 16 octobre 2012 12:09 > To: Pascal Thubert (pthubert); rtgwg@ietf.org > Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) > Subject: RE: Ears and ARCs > > Great summarization, thanks. Just some small notes to this, which may mak= e the difference a bit clearer for the WG: > > - In basic version, MRT can correct one failure, while ARCs can correct o= ne per ARC, which means that if there is a lucky multi-failure situation, A= RCs may solve it, while the basic MRT can't. > - Current MRT is designed in this way (i.e. that it can avoid only one fa= ilure), since avoiding multiple failures has its price: in some single fail= ure cases, you may need to reroute packets multiple times with ARCs. Since = rerouting means that a packet is using links and nodes multiple times (once= in both direction), we thought that this is a greater problem then to wait= for IGP when there are multiple unrelated failures at the same time. > As an example consider a network very similar to the one in Pascal's exam= ple: > > 2 -- X1 -- 3 > | | > | | > 1 -- X2 -- 4 > | | > | | > ---Omega --- > > Let the ARCs be similar: > > 2<=3D> X1 <=3D>3 > | | > V V > 1<=3D> X2 <=3D>4 > | | > | | > -->Omega <-- > > If now node 1 goes down, then node 2 will reroute, packet will be decapsu= lated at node 4, and if we're unlucky and the shortest path would be 4->X2-= >1->Omega, X2 will need to reroute again. > > So there is a * tradeoff *: basic MRT avoids single node or link failures= , while ARCs may hit a single failures multiple times. It's a management de= cision which one is better. > > What is important to mention is that all the previous was true for basic = MRT. However, it is very easy to see that the endpoint of the MRT detour is= not needed to be terminated at the destination (e.g. the egress router), b= ut it can be at several other nodes, e.g. at nodes, which are strictly clos= er to the destination; this is what we call "endpoint selection". Naturally= , it is possible to select not only closer nodes as endpoints, when we can = guarantee to avoid loops, so with some endpoint selection algorithm we may = hit a single failure multiple times. The most exciting is that with a prope= r ear selection (i.e. with selecting the ears using the algorithm described= in ARC draft), and using proper endpoint selection (i.e. endpoint is the e= nd of the ear), we can get EXACTLY the same packet path, as with ARCs. :) M= oreover, if I understood ARCs correctly, we can even reproduce the effect o= f "combs". > > Thus, I think that there is so much common in the two approaches that we = may need to consider to merge the two together somehow. > > Gabor > > > > > ________________________________ > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf=20 > Of Pascal Thubert (pthubert) > Sent: Saturday, October 13, 2012 6:59 PM > To: rtgwg@ietf.org > Cc: Dirk Anteunis (danteuni); Patrice Bellagamba (pbellaga) > Subject: Ears and ARCs > > > > Dear WG: > > > > I received an unicast a question that was, bascally, what's the differenc= e between MRT and ARCs. > > > > > > ---------- Forwarded message ---------- > From: > To: > Cc: > Date: > Subject: > perties, up to us to find interesting applications and maybe find new=20 > solut=3D ions to existing problems. The core of that tool is the=20 > reversible link, so=3D that we form downwards U-shaped arcs as opposed t= o arrows for routing. > > =3D20 > > But maybe the simpler approach is to make an exercise and see what we=20 > get -=3D my current understanding here, G=3DE1bor please correct me if I= 'm wrong -. > > =3D20 > > So, say we have this simple network.=3D20 > > =3D20 > > 2 --- 3 > > | | > > | | > > 1 --- 4 > > | | > > | | > > Destination > > =3D20 > > I illustrated naming the routers with a value that matches my=20 > understanding=3D of the values of the partial order, to make things simp= le. > > =3D20 > > We end up with 2 ARCs and 2 ears, which are basically collocated. The=20 > ARC v=3D iew is > > =3D20 > > =3D20 > > =3D20 > > 2 <=3D3D> 3 > > | | where links 2 - 3 and 1 - 4 are reversible. > > V V > > 1 <=3D3D> 4 > > | | > > V V > > Destination (Omega) > > =3D20 > > A first property of the ARCs can be seen immediately. ARCs are=20 > hierarchical=3D routing friendly.=3D20 > > We can collapse each ARC to simplify the representation which becomes: > > =3D20 > > 2 > > | | > > V V > > 1 > > | | > > V V > > Destination > > =3D20 > > =3D20 > > If we break any link both ears and ARCs provide an alternate route,=20 > that's =3D FRR for you. Now let us see what happens with more than one br= eakage. > > There are double breakages that isolate a piece of the network, say if=20 > link=3D s 2 - 1 and 3 - 4 both break, there is no solution in the world=20 > that can ke=3D ep 3 connected to the Destination.=3D20 > > =3D20 > > Say now that 3 - 4 and 1 - Destination are both broken a 2 has a=20 > packet to =3D send. > > =3D20 > > =3D20 > > 2 --- 3 > > | | =3D20 > > V X > > 1 --- 4 > > | | > > X V > > -------------Destination (Omega) > > =3D20 > > =3D20 > > - With ears, using the increasing order 2 will pass to 3, and 3 to 4=20 > will f=3D > ail.=3D20 > > So the packet is switched to decreasing order and the packet reaches 1=20 > via =3D 2. > > 1 fails to send to the destination and we are screwed. > > =3D20 > > =3D20 > > PPPPP>> < ing order > > | | | | p | ppp packet progressing in decre= as=3D > ing order > > V X V X p X =3D20 > > 1 --- 4 1 --- 4 V --- 4 When packet reaches 1 must be = dr=3D > opped =3D20 > > | | | | | | because increasing again may c= au=3D > se a loop =3D20 > > X V X V X V =3D20 > > -----------------------------------------Destination (Omega) > > =3D20 > > =3D20 > > - With ARCS, say that bad luck the shortest path is via 3. 2 passes to=20 > 3 an=3D d 3 to 4 will fail.=3D20 > > So 3 u-turns the packet along the ARC, back to 2.=3D20 > > Some tagging indicates that the packet was u-turned which can happen=20 > only o=3D nce in that ARC. > > =3D20 > > 2--p->3 2<=3D3D=3D3Dp=3D3D3 2 --- 3 2 --- 3 2 --= - 3 -p=3D > -> in shortest path =3D20 > > | | | | p | | | | | =3D3D= p=3D3D=3D >> vs. returned =3D20 > > V X V X V X V X V X = pa=3D > cket > > 1 --- 4 1 --- 4 1 --- 4 1=3D3D=3D3Dp=3D3D>4 1 --= - 4 > > | | | | | | | | | p packe= t =3D > reaches Omega > > X V X V X V X V V V > > =20 > ------------------------------------------------------------------Dest > ina=3D > tion (Omega) > > =3D20 > > say that bad luck again the shortest path for 2 is via 1. > > 2 passes to 1 and since the ARC is exited the marking is removed. > > 1 fails to send to the destination, marks the packet and sends it=20 > along its=3D ARC. > > Packet reaches Destination via 4. > > =3D20 > > =3D20 > > IOW, ARCs form isolated recovery domains and allow up to as many=20 > breakages =3D as the ARC or Comb has exits, with no disruption. > > =3D20 > > Also, ARCs can form multi-ended structures called combs with better=20 > recover=3D y capabilities than a 2-ended structure. > > =3D20 > > For bicasting, the difference will be a bit more subtle. In a=20 > biconnected g=3D raph, ears will build non congruent path every time,=20 > but they might be far =3D away from shortest. ARCs will attempt to stay=20 > closer to shortest but may in=3D cur collisions, which are then resolved. > > =3D20 > > Then ARCs can be employed for other purposes. We have an interesting=20 > approa=3D ch to the Olympic rings issue for instance. > > =3D20 > > Cheers, > > =3D20 > > Pascal > > =3D20 > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From ice@cisco.com Tue Oct 23 13:19:26 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6402321F8647 for ; Tue, 23 Oct 2012 13:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.832 X-Spam-Level: X-Spam-Status: No, score=-7.832 tagged_above=-999 required=5 tests=[AWL=2.767, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+-Fcoyj5a10 for ; Tue, 23 Oct 2012 13:19:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9E21F842E for ; Tue, 23 Oct 2012 13:19:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9NK4dBM022637 for ; Tue, 23 Oct 2012 22:04:39 +0200 (CEST) Received: from ams-iwijnand-8716.cisco.com (ams-iwijnand-8716.cisco.com [10.55.191.151]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9NK4buK011414 for ; Tue, 23 Oct 2012 22:04:38 +0200 (CEST) From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: draft-wijnands-rtgwg-mcast-frr-tn-00.txt Date: Tue, 23 Oct 2012 22:03:05 +0200 References: <20121015192211.10211.80884.idtracker@ietfa.amsl.com> To: rtgwg@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:19:26 -0000 Hi Folks, I like to encourage the WG to read through this draft so that we can = have productive discussion at the IETF. In short, this draft proposes two enhancements to Multicast Only Fast = ReRoute (draft-ietf-rtgwg-mofrr-00). 1. A router on the tree that detects a failure on its upstream (RPF) = interface injects a Downstream Tree Notification (DTN) down the tree to = notify (potential) downstream MoFRR routers. When a downstream MoFRR = router has received such notification, it will switch to the backup = path. The notification is sent as data down the tree and forwarded as = 'normal' data by non-MoFRR routers. In order to allow Fast Convergence = to happen, originating and processing of the TN message must happen in = the data-plane, similar to how BFD packets are processed in the = data-plane. The big different with BFD is that TN packets are not = periodic, but only triggered when a failure happens. 2. With normal MoFRR, packets are received over two diverse paths to the = MoFRR router. While in many cases this is not considered to be a = problem, there are situations where the additional bandwidth may be = worth saving. For this cases we are proposing to join the backup path in = 'standby' mode, such that forwarding state is programmed, but no data is = actually forwarded. When a failure has happened on the tree (detected by = Downstream TN or directly connected link failure) an Upstream Tree = Notification (UTN) is originated up the tree to reset the non-forwarding = state. This notification is also originated and processed in the = data-plane. Note, this is optional functionality. The main advantage of = this draft comes from option 1. Thx, Andras, Jeff and Ice. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-wijnands-rtgwg-mcast-frr-tn-00.txt > Date: 15 Oct 2012 21:22:11 GMT+02:00 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Tree Notification to Improve Multicast Fast = Reroute > Author(s) : IJsbrand Wijnands > Andras Csaszar > Jeff Tantsura > Filename : draft-wijnands-rtgwg-mcast-frr-tn-00.txt > Pages : 18 > Date : 2012-10-15 >=20 > Abstract: > This draft proposes using dataplane triggered notifications in order > to support multicast fast reroute methods in various ways. Sending > such notifications down the tree can be used to trigger fail-over in > nodes not adjacent to the failure. Sending such dataplane > notification up the tree can help to activate pre-built standby > backup tree segments. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wijnands-rtgwg-mcast-frr-tn >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-wijnands-rtgwg-mcast-frr-tn-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From aretana@cisco.com Wed Oct 24 03:48:25 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438B521F8BD2 for ; Wed, 24 Oct 2012 03:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piIaXN6sZDa9 for ; Wed, 24 Oct 2012 03:48:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 82AFD21F8BE4 for ; Wed, 24 Oct 2012 03:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3555; q=dns/txt; s=iport; t=1351075704; x=1352285304; h=from:to:subject:date:message-id:mime-version; bh=EJzM0JvidQNGwEDPYdQ2fC8/rH5+uIh9SJZgWUyFxLQ=; b=OknJ4yRDtH29Itzru2f5SuE4Q+qAXINEdIQdn/S9wHIpFA9nH7rgxqxO QhB8OT3LlYEMNxlD85XWYd0ievzPlA0mHYP3OH4V1r5z5rzO+5FCD0/rb Vf6m5jPo7mEZoQ8/bdun8ngRilyJCYWT77f3Mvzm3VHxGMTDaUFT7KLF7 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAHANnGh1CtJV2Z/2dsb2JhbABDAYJKhGW6TYEIgiABBBIBeAEMHg8CRScEGwEZh2ILmWqBK6ABjzkBgjFgA5JBkgCBa4Jvghg X-IronPort-AV: E=Sophos;i="4.80,639,1344211200"; d="scan'208,217";a="134823238" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 24 Oct 2012 10:48:24 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9OAmOSB012784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Oct 2012 10:48:24 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.50]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 05:48:23 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Preliminary Agenda Posted Thread-Topic: Preliminary Agenda Posted Thread-Index: AQHNsdUWbonwo8QkpkSQCJRpXHb0gg== Date: Wed, 24 Oct 2012 10:48:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.233.21] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--42.117000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94EA9214Bxmbalnx15ciscocom_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:48:25 -0000 --_000_BBD66FD99311804F80324E8139B3C94EA9214Bxmbalnx15ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/85/agenda/agenda-85-rtgwg As you can see, we have received a significant number of presentation reque= sts and are virtually out of time. Please let me know if I have missed any= one, made any typos or have any late requests. I have asked all the presenters to start a discussion on the list about the= ir drafts, pointing out the parts they would like the most feedback on. Th= e intention is to both have an idea of the initial interest and for the con= tent to not be completely new at the in-person meeting, hopefully resulting= in better discussions. Most authors have in fact sent some good informati= on to the list =97 please take a look and make comments on line. Note to presenters: The time on the agenda includes presentation and discu= ssion, so please plan accordingly. You MUST send your slides to the chairs= before the day of the meeting (local Atlanta time). Given that the WG mee= ting is scheduled for Monday (Nov/5 at 1pm in Salon E), we SHOULD receive a= ll presentations by the end of the day on Friday Nov/2 (pick your favorite = timezone). The chairs MAY change the order of the presentations based on s= lide availability. Thanks! Alvaro. --_000_BBD66FD99311804F80324E8139B3C94EA9214Bxmbalnx15ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4FBF2464D519A94B9EFD472EE71DE599@cisco.com> Content-Transfer-Encoding: quoted-printable

As you can see, we have received a significant number of presentation = requests and are virtually out of time.  Please let me know if I have = missed anyone, made any typos or have any late requests.

I have asked all the presenters to start a discussion on the list abou= t their drafts, pointing out the parts they would like the most feedback on= .  The intention is to both have an idea of the initial interest and f= or the content to not be completely new at the in-person meeting, hopefully resulting in better discussions.  = ;Most authors have in fact sent some good information to the list =97 pleas= e take a look and make comments on line.

Note to presenters:  The time on the agenda includes presentation= and discussion, so please plan accordingly.  You MUST send your slide= s to the chairs before = ;the day of the meeting (local Atlanta time).  Given that the WG meeting is scheduled for Monday (Nov/5 at 1pm in Salon E), we SHOUL= D receive all presentations by the end of the day on Friday Nov/2 (pick you= r favorite timezone).  The chairs MAY change the order of the presenta= tions based on slide availability.

Thanks!

Alvaro.
--_000_BBD66FD99311804F80324E8139B3C94EA9214Bxmbalnx15ciscocom_-- From aretana@cisco.com Wed Oct 31 20:50:43 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC46621F857C for ; Wed, 31 Oct 2012 20:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKrw+yz-uqa2 for ; Wed, 31 Oct 2012 20:50:43 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA77621F85CD for ; Wed, 31 Oct 2012 20:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5354; q=dns/txt; s=iport; t=1351741842; x=1352951442; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DuS5QLZyBDqpQQsMRqM4GOAY2PpEDZJ8Xu5io0xDOGI=; b=nDhuuQuyUNGVJRFvq4taTfLaiUbxDiVEHnY5m0ETrpPust7vojVzS2U+ qAxaQEcmvnxCvLKpECGzPxFjJgY1R2vul8JFappMTMdAlxjInIIqZhL5W Wc/1SOS1G+xNaWKeLV5H9Lr868lGW1ijoW7hSyRdavWcDwcb9fXo4Jsz6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEFAB3wkVCtJXG8/2dsb2JhbABEiHa4LIJAgQiCHgEBAQQSAXYCAQwNAwECHgoHMhQHAggCBBMUDodkC5sIoCEEi3iFWmEDkkSDMo5XgWuBLoFBgWQ X-IronPort-AV: E=Sophos;i="4.80,691,1344211200"; d="scan'208,217";a="137630700" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2012 03:50:42 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA13ogDM004120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Nov 2012 03:50:42 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.50]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 22:50:41 -0500 From: "Alvaro Retana (aretana)" To: "rtgwg@ietf.org" Subject: Fwd: Help the NomCom: Community Feedback Thread-Topic: Help the NomCom: Community Feedback Thread-Index: AQHNt97hUJV6rw3y3U+f3L3nSn+klZfUWGGL Date: Thu, 1 Nov 2012 03:50:41 +0000 Message-ID: References: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> In-Reply-To: <20121101031318.29487.88368.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--34.169300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_AA84CF7F7BFF47D281DFBD778086CBD9ciscocom_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 03:50:43 -0000 --_000_AA84CF7F7BFF47D281DFBD778086CBD9ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please provide input to the NomCom. Sent from my iPod Begin forwarded message: From: NomCom Chair > Date: November 1, 2012 1:13:18 AM GMT-02:00 To: Working Group Chairs > Subject: Help the NomCom: Community Feedback The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 4. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12@ietf.org. Additionally, the NomCom is= happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org --_000_AA84CF7F7BFF47D281DFBD778086CBD9ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please provide input to the NomCom.

Sent from my iPod

Begin forwarded message:

From: NomCom Chair <nomcom-chair@ietf.org>
Date: November 1, 2012 1:13:18 AM GMT-02:00
To: Working Group Chairs <wg= chairs@ietf.org>
Subject: Help the NomCom: Community Feedback

The IETF Nominations Committee (NomCom) continues to seek input = from
the IETF Community. The NomCom would greatly appreciate any help you<= /span>
could provide in making members of your working group aware of ways i= n
which they can provide valuable feedback to the NomCom.

In order to ensure that your input is received in time to be useful, = the
NomCom needs to receive community feedback on or before Sunday, Novem= ber 4.

The final list of candidates (as per RFC 5680) that the NomCom is
considering for open positions can be found at:
https://www= .ietf.org/group/nomcom/2012/input/

The NomCom will be holding office hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes
comments on specific individuals, as well as general feedback related= to
any of the positions that NomCom is considering.

Note: A list of leadership positions that the NomCom is considering c= an be
found at: https:/= /www.ietf.org/group/nomcom/2012/

If the NomCom office hours are inconvenient for you or if you cannot =
attend IETF 85, the NomCom is happy to take community input via email=
to nomcom12@ietf.org. Additi= onally, the NomCom is happy to arrange a
meeting outside of office hours, just send us email and we can set
something up.

Comments on specific candidates can also be provided to the NomCom
via the web feedback tool:
https://www= .ietf.org/group/nomcom/2012/input/

Thank you for your help,
- Matt Lepinski
 nomcom-chair@ietf.org<= /a>
--_000_AA84CF7F7BFF47D281DFBD778086CBD9ciscocom_--