From nobody Tue Aug 1 00:42:14 2017 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 9791B132A8C; Tue, 1 Aug 2017 00:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkqSlSZE0Lgw; Tue, 1 Aug 2017 00:42:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443B5132A98; Tue, 1 Aug 2017 00:42:09 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-f5-598030ce7119 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.F4.06959.EC030895; Tue, 1 Aug 2017 09:42:07 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 1 Aug 2017 09:42:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Xbh0RB8/aHBNo7KM0B3vSGt6+fCpXpktIquzKuEIZg8=; b=JgTBWX4xYeXeb9zGvs0uO/r0iv0tYFH/y/T03R943UgQrND7qXBlFslXe+jrBDd4wzD6hfpfcenpRTRZZhNwg6lKQ6zIDFZqQRGvyJ+n/o/sd/+ePWNyfkFXsHd75OxyMZ9XI88KPyNFvJ+cgQxIzvuSbCAUz7HxWRH2CHQYYrw= Received: from HE1PR07MB1708.eurprd07.prod.outlook.com (10.166.124.150) by HE1PR07MB3193.eurprd07.prod.outlook.com (10.170.245.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Tue, 1 Aug 2017 07:42:04 +0000 Received: from HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71]) by HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71%13]) with mapi id 15.01.1320.010; Tue, 1 Aug 2017 07:42:04 +0000 From: Sikhivahan Gundu To: "Ahmed Bashandy (bashandy)" , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" , Stewart Bryant Subject: RE: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Topic: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Index: AQHS/s4TUl1vutply0WzIUPGFdTcIaJvH4nQ Date: Tue, 1 Aug 2017 07:42:04 +0000 Message-ID: References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> In-Reply-To: <596C668E.9050106@cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.16.128.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3193; 7:OVZo1HCOoToISpATKbYjnTqzrDnoBiMCi7Sl/LEVWk5cmtdVm5cY4cooug4Ry2pMwtydux7isDRSzX4HA03pODWYABcoiN3h0ojZKude3k9cZn82GHnH6XvRelWZaHEKbRxDISPFaBj7yc0wd3yZvJjoYX2zc4n9rU9gx0SRaLzr/7Sa3pSLSdUj0R+PgWod+q/l1ktth0qOUs6LMBxzltO5nW/XURpduh3WvBoI3szGiAGcsjhKhpm8uww41OMmFg53MJGToPih7ZR0/RqkDVPkY6sDBiCBPp6XqcrsL55cBq6Xw9PzJ8dBFgNWy6FxKcOmsUG1zTq160Y305U61i6978q5h2P9W766b0hw22qSr8abMxJ0h/Y5cJlxArrPQFehnm3kwZXB2I8tpwnTDQAObojY5RTOEVenOVVCo39O3ce5RzdUn+EKId7XYf30xp+RLPuukuGJqeGoUXD0os3xvbcbImSKigHhXVFMpwbxroJ8uTGCfITHZtkkOw1UUh5cuNXGK8qgV6Pe87uOX293za0UGNBG/nRm/qfbxkEZoNSZXNZpttm/D6EgMS5yu1i26VarDh6vdthervKHXeEvqbt0YFaJtsI5Tai4sC3Bm/aXS1DMmnOslW6c6U33q9iow6oQ4JVFuUr3WmeSNAgDF+F2hUxzshZHpHhbLEgWSrGSi2SS3f9yIiuCUE9kBGAs5iMUojg9KNdTxxhf8QzvPWjoWKaNmKQB+5yquM3JckYtK6HbuB6qm//AOx+iMJLQAM1T4FJ4EhuYd1wVsymzj80Dq+HkaBR57NdqsAs= x-ms-office365-filtering-correlation-id: eb7cc874-a035-4c32-c2c6-08d4d8b0ce03 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB3193; x-ms-traffictypediagnostic: HE1PR07MB3193: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3193; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3193; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(39860400002)(199003)(377424004)(13464003)(189002)(6506006)(2906002)(478600001)(105586002)(101416001)(2900100001)(5250100002)(14454004)(66066001)(2501003)(966005)(33656002)(6246003)(38730400002)(39060400002)(189998001)(74316002)(106356001)(236005)(8936002)(76176999)(55016002)(54906002)(7696004)(3846002)(54896002)(6306002)(9326002)(102836003)(6116002)(97736004)(53936002)(790700001)(50986999)(54356999)(7736002)(81156014)(81166006)(53546010)(6436002)(5660300001)(86362001)(230783001)(3660700001)(9686003)(99286003)(3280700002)(4326008)(2950100002)(25786009)(8676002)(229853002)(68736007)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3193; H:HE1PR07MB1708.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sikhivahan.gundu@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB1708E945640F865CA32D85F7EAB30HE1PR07MB1708eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 07:42:04.6716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3193 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85247L0WkqPmhizCDT8jJMR0XZl5Q0k/qQRlArD2rqJjsq qX0YSR/SLMM5mxFzOG+TCepiSl7azGQgTYPMEsFbmje8FF6YSptnQt9+7/P/P1deEhdaOX5k piyPVsik2SIun9CkmP3P2iOUqRH6cU/J544RQjJmr8QkfcY6XDK87MAlDatKFMuJVznaOPHa udvxXTUTvHi9fgdLJu7wL6bR2ZkFtCL80n1+Ru/AEi/XVoke7402c5XopRKVIg8SqChQ9+5h pYhPCqlPCKq/mXD2MYigW7/NdbkIqhyHv1NSVlBjUP269SBdSE0j+NEjcjGXiobdiXrMxd5U KgxpNg8q4VQJgn7zNM8leFEJUDo25zYlwq+RKpxlMTTpv/PYbidhcUpNuFhA3YW2vU1nM9LZ 7AE8N3q50IM6DbbZUy4HogJgq3X/wI1TvvBzVouxm1Gg77bjLPvAwsw+h2URdGh+uz0B8FVb hlxjAjXJhXctOwQrXIfKF1s4K0xjoDa3uyuFgEqncmcngLXb4q6aBeM2k/umVg6YWiQsHwf1 Tj2HLWTnQkfJH4K9HA2NxmeoAoXW/Dc5y3LYqJtCNQf7HwObZpZg42eg9sMGl+VQaNAt4Yc8 9HEG+z9ei3gG5MPQDJOTLhaH0YrMhwwjl4XJ6Lx25PxZFpPjfCeyzF+xIopEIk9BGyhThRxp AVOYY0VA4iJvQVOwMyRIkxYW0Qr5PUV+Ns1YkT9JiHwFsb3DKUIqXZpHZ9F0Lq04VDHSw0+J bm188V22aadmq5Lb/RaPGB5FDb652miZ74sJN6uN0YG64p68lbKgSFNSW9CrZijeDV4eMKze 3KzIv9A551cf+KS2q0iZsVO41vN2W7HNPXotSXj5hmPd0H8uLnVj/WmiLkY1qhHHqC1F0vfp Mtw2OiknwlYm1k4U5jct8MrjRASTIY0MwRWM9B+SBZJcVQMAAA== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 07:42:13 -0000 --_000_HE1PR07MB1708E945640F865CA32D85F7EAB30HE1PR07MB1708eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft mandates using "post-convergence path" as the backup path. It states one advantage, among others, of doing so as follows: "This .. helps to reduce the amount of path changes and hence service transients: one transition (pre-convergence to post-convergence) instead of two (pre-convergence to FRR and then post-convergence)". This suggests to me that the assumption here is that the post-convergence path can be uniquely determined in advance. However, SRLG introduces ambiguity. To illustrate the point, let us say a loop-free alternative has two options: one link (L1) is of the same metric value as the primary link and is also in the same SRLG as the primary; the second option (L2) is in a different SRLG and has higher metric. The actual post-convergence path would depend on whether or not L1 also failed along with the primary, so is not uniquely computed in advance. If TI-LFA picks L1, there might not be a guaranteed backup. If it picks L2, there'd be two link transitions because L2 would not be in a (strict) SPF- computed post-convergence path. A third option, of course, is to give up declaring that there is no TI-LFA backup, but it'd be preferable to have some backup than have none at all. What do the authors suggest for this situation? Thanks, Sikhi From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (ba= shandy) Sent: 17 July 2017 12:56 To: rtgwg@ietf.org Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx= t Hi, A new version of the ti-lfa draft has been posted to address Stewart Bryant= 's comments Thanks Ahmed -------- Original Message -------- Subject: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Date: Mon, 17 Jul 2017 00:19:37 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Topology Independent Fast Reroute using Segment R= outing Authors : Ahmed Bashandy Clarence Filsfils Bruno Decraene Stephane Litkowski Pierre Francois Filename : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx= t Pages : 12 Date : 2017-07-17 Abstract: This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lf= a/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-= ti-lfa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-bashandy-rtgwg-segment-routing-ti= -lfa-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. 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 --_000_HE1PR07MB1708E945640F865CA32D85F7EAB30HE1PR07MB1708eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft mandates using “post-convergence = path” as the backup path. 

It states one advantage, among others, of doing s= o as follows:

 

“This .. helps to reduce the amount of path= changes and hence service

transients: one transition (pre-convergence to po= st-convergence) instead

of two (pre-convergence to FRR and then post-conv= ergence)”.

 

This suggests to me that the assumption here is t= hat the post-convergence

path can be uniquely determined in advance.<= /o:p>

 

However, SRLG introduces ambiguity. To illustrate= the point,  let us say a

loop-free alternative has two options: one  = link (L1) is of the same metric

value as the primary link and is also in the same= SRLG as the primary; the

second option (L2) is in a different SRLG and has= higher metric.

 

The actual post-convergence path would depend on = whether or not L1

also failed along with the primary, so is not uni= quely computed in advance.

If TI-LFA picks L1, there might not be a guarante= ed backup. If it picks L2,

there’d be two link transitions because L2 = would not be in a (strict) SPF-

computed post-convergence path. A third option, o= f course, is to give up

declaring that there is no TI-LFA backup, but it&= #8217;d be preferable to have

some backup than have none at all.

 

What do the authors suggest for this situation?

 

Thanks,

Sikhi

 

 

F= rom: rtgwg [mail= to:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stew= art@g3ysx.org.uk>
Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lf= a-01.txt

 

Hi,

A new version of the ti-lfa draft has been posted to= address Stewart Bryant's comments

Thanks

Ahmed


-------- Original Message --------

Subjec= t:

I-D Action: draft-bashandy-rtgwg-segment-routing-ti-= lfa-01.txt

Date: =

Mon, 17 Jul 2017 00:19:37 -0700

From: =

internet= -drafts@ietf.org

Reply-= To:

internet= -drafts@ietf.org

To:

<i-d-ann= ounce@ietf.org>

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
 
 
        Title   &nbs=
p;       : Topology Independent Fast Reroute =
using Segment Routing
        Authors   &n=
bsp;     : Ahmed Bashandy
           &nbs=
p;            &=
nbsp; Clarence Filsfils
           &nbs=
p;            &=
nbsp; Bruno Decraene
           &nbs=
p;            &=
nbsp; Stephane Litkowski
           &nbs=
p;            &=
nbsp; Pierre Francois
        Filename   &=
nbsp;    : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx=
t
        Pages   &nbs=
p;       : 12
        Date    =
;        : 2017-07-17
 
Abstract:
   This document presents Topology Independent Loop-free Alt=
ernate Fast
   Re-route (TI-LFA), aimed at providing protection of node =
and
   adjacency segments within the Segment Routing (SR) framew=
ork.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR conc=
epts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed f=
orwarding
   (DLFA).  It extends these concepts to provide guaran=
teed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR =
path selection
   approach establishing protection over post-convergence pa=
ths from
   the point of local repair, dramatically reducing the oper=
ational
   need to control the tie-breaks among various FRR options.=

 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-s=
egment-routing-ti-lfa/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-r=
outing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-bash=
andy-rtgwg-segment-routing-ti-lfa-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-bashandy=
-rtgwg-segment-routing-ti-lfa-01
 
 
Please note that it may take a couple of minutes from the time of subm=
ission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-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.iet=
f.org/ietf/1shadow-sites.txt


 

 

--_000_HE1PR07MB1708E945640F865CA32D85F7EAB30HE1PR07MB1708eurp_-- From nobody Wed Aug 2 06:31:55 2017 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 CC5591320D9 for ; Wed, 2 Aug 2017 06:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.289 X-Spam-Level: X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ttzUKFrIMdW for ; Wed, 2 Aug 2017 06:31:52 -0700 (PDT) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8D31320D4 for ; Wed, 2 Aug 2017 06:31:51 -0700 (PDT) Received: from [193.109.255.99] by server-6.bemta-6.messagelabs.com id 95/EF-03937-644D1895; Wed, 02 Aug 2017 13:31:50 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhTYRTHe+62u6t447r5cloGOWeY5poV1Zf ojaKoQIgIxai7vG6jbdrulNmHnNCiNCMhQUe1VWtkCqUZli8UasNpZZkvEfaqgs0ssA+WE2nb M83uh8vvOf//85w/h0MJJO2kjOIsZs5kZPVyMlK4ae1vRfqegdIsVU1V+tbX3/2CHWify/WHy ETZIp1RnW85IdLesDlQwVCsxdM+Q1rRnLQMRVJC5rwAqhvbxMGDhKkkoK7lDYEPnxA4yr+QZS iCIplt0Fj3IcQxTDJU2G0hljI0zP+8LcR1Cbiq20WYlTBy3RryCBkFDLaOhDw0kwM9nb1EkBE TBzM99SEWMPHwfswRYmAYcLX1CTDHwrfReRH2q+HT+E2E64lw99XzsGcV9DvKUTA0MJ9JuPWr OSwcgvpOZ4CpACdB08Qx7PlJgM1zIdwsFYYfesJ8AJzuWTHmU+A+VyHGF3pFcKfJEe6cAMNTX hILL0mYLpsN3ZYwJ6H72i8hHosMPgxcRJgTYGIEj0XAGGFw3E/gUUSDt2ZMeAWtsS+ZgH2Jzb 7EhuvrwNk6TWJOA/fNScECv3g2SiytO5H4HkrhOVMRZ0rfoFKqTTqN1mxgdfr0DNVmpYHjeVb D6Vk1rzyZb2hEgSVaFvgeo1l3ZgdaQRHyWDrxUkmWZLk6P7dYy/La46ZCPcd3oASKkgPtfVua JYk2cRrOkqfTBzZxQQYqSh5DFwZlmi9gDbxOg6UetJHq8HfPEJQn+JcIjflGThZPHwxamaBVW 2hcfGhhq/vRKpmURoFokqgCzmTQmf/XfSieQnIp3RR8JUpnNC/28wWiEIEoc2dDUczsP0lmRQ rbbn9Zosu39+rvOF8leiKrqi0xpKjHu0pya8cirCIorzSqppKKavdnrPlhe9KyArz3bQ4Fv1o 7vvzp9i1T52v804cvNz+yTqqGznQpPjY0FDOEckKlsT/IkfXlrD+9Pe/dzuLUgfqKtJXbhvnn w8nOI0e/NpH6RKo2e5dut1zIa9mMVIGJZ/8C5ZUtntADAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-48.messagelabs.com!1501680706!122464141!1 X-Originating-IP: [52.41.248.36] X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 29251 invoked from network); 2 Aug 2017 13:31:49 -0000 Received: from ec2-52-41-248-36.us-west-2.compute.amazonaws.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-7.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Aug 2017 13:31:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l7bTdb1MkX2Cbf2FTk/Gf2SlMwlTNA2en8+blOfBZeI=; b=RgRw2Acykp4rJ/PEjLdIWJq4bcmtXOk5KMRniGzCALUUxvSlJeeE+CKvN4ZsiGRuCivwg+Lb7H/V3nSKAN5XQYygAgwsCtmvFSlbihKlpSmepKEeWfIzEsyTchMDwil2PH+Awyy+6CPBGDfzWIEv0HLFgGrvpGdV7B6rTqeHkDI= Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1716.eurprd03.prod.outlook.com (10.167.88.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Wed, 2 Aug 2017 13:31:45 +0000 Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::7db0:4329:703e:58b4]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::7db0:4329:703e:58b4%14]) with mapi id 15.01.1304.023; Wed, 2 Aug 2017 13:31:45 +0000 From: Alexander Vainshtein To: "rtgwg@ietf.org" Subject: test Thread-Topic: test Thread-Index: AdMLk6R5uk1fkCElR9azWDcHGa5x9Q== Date: Wed, 2 Aug 2017 13:31:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.177.44.123] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR03MB1716; 7:d43zv2fQZxUgIKab+4hlkdUjiTCfRhREWf5df3IbuZg9j/wd0/viPsbHKlJXC60ctn62faCRst/WFJfxkU2BruRRg0KKq8LJMacZxzhSzKsKWl5QeHjHDOa+N85EXtSzCQTtYjKiUK2Afqzip+SJoqyLJGcgxynPCrJTZCpDHpz/X/cN1YsofqkN1YNVQwxqPukY0ncsy0bRNNHDDB0fpUV12fWalQVB3CiYybgSYQ4N1enhI+7T4jsXVBf9OkY7GQK1gI/4+pg/xoqi2chlzVeDq7DDrFCLyHqf+gLC972vkQNpJKZn3GorF8oYN1Rd/oxiW3er5tNFIUdZ/p/6xIHCm1lHBfW/u3MeUqkq1aChdWe7Y5exvbMaKpSOM2tVD2UxUhyLT2RG1eiKknTSkl/FPuvBk+8uJjIZ4QZhrbJc+UlT3ef06e8wjKEJslbvXUhiuDQbxntJ9/pYJBFzHpWx+FYYleCcqhjMWPKTdYNOAu7tZZUcyfnTwTP8GwudPDDaCBt4/RM4H+a/OR+howe6M3U/4UhO8BGFwcEZVIx/1oxHfGsekbfHvcRc1iqSwXy/VaRUXuMZ4dAIPwkxoU+jmFckmqlyq8dkhHl56XMHJEN9gTKB35JnBzpCHxOijnsXWro4lM9nDZzMZNlWH0vjS7jSWiexeifM/+2n1LpakOsgshQuB6/9ZxywfdcqbJso0aAd9IyPNop05cHSoAGA1bGT4/tA2sT5Ymi/hq5PZUSm+yIIxpLnzFHJSJqpv0G4kgo87BqKW9djUR5bsyOWAuFFe75WKvPGWdN6xV0= x-ms-office365-filtering-correlation-id: e45373ab-d6ac-4d2b-9d44-08d4d9aad19f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR03MB1716; x-ms-traffictypediagnostic: AM4PR03MB1716: x-exchange-antispam-report-test: UriScan:(21748063052155)(279101305709854); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1716; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1716; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(252514010)(199003)(189002)(3846002)(8676002)(99286003)(68736007)(9686003)(66066001)(53936002)(7696004)(74316002)(7116003)(54896002)(6306002)(5250100002)(2351001)(97736004)(5640700003)(54356999)(6436002)(221733001)(2906002)(25786009)(106356001)(3480700004)(478600001)(105586002)(2900100001)(1730700003)(8936002)(50986999)(55016002)(72206003)(558084003)(33656002)(6116002)(7736002)(3280700002)(102836003)(86362001)(3660700001)(790700001)(6506006)(2501003)(189998001)(81156014)(5660300001)(14454004)(81166006)(110136004)(5630700001)(6916009)(38730400002)(101416001)(217283001)(220243001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1716; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR03MB17139936F14B87B0CEC4C4FF9DB00AM4PR03MB1713eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 13:31:44.9711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1716 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:31:54 -0000 --_000_AM4PR03MB17139936F14B87B0CEC4C4FF9DB00AM4PR03MB1713eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Testing mu subscription - please ignore. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM4PR03MB17139936F14B87B0CEC4C4FF9DB00AM4PR03MB1713eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Testing mu subscription – please ignore.=

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266= 302

Email:   Alexander.Vainshtein@ecitele.com=

 


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM4PR03MB17139936F14B87B0CEC4C4FF9DB00AM4PR03MB1713eurp_-- From nobody Wed Aug 2 08:14:24 2017 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 EDBCC13212C; Wed, 2 Aug 2017 08:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzgeiTQepRpj; Wed, 2 Aug 2017 08:14:21 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CE0128C9C; Wed, 2 Aug 2017 08:14:21 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id m85so44425322wma.1; Wed, 02 Aug 2017 08:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Wmu+AHgsfd4YW6alcso143uaYgG1FJ/gsDvLb8bxCSc=; b=WDBz4i8DJmnsTfbSuYqlzytE8Xh3Qt0DfomVhmuLl7WleqCmwEQaIPq7rcGkxP/lLk /IkFE69x+OI3xPjWs//ffwNSxIEGp8zBgSJFWThi2kytLRMmsThHwNzmnYBhyNfThiSD MDfR98+nSYxnk3E4VRNW4R8QoPv+05KPSoQND+1GtnhhWRU8/W3XnYuxRkFgplHO9z+A DwMECzggkCAUiw+AIEkXD41pf2uCRyx+54G7RKWnbxwfnpbZ23ZfkxG/Q8SaitfEQiSZ fWcOAMeU1Gnh4RE/Tk2yzewcta70oR87YZyhPvnYw/A9He6Udyc9v3WcBs2qUFB3bZ2P C43Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Wmu+AHgsfd4YW6alcso143uaYgG1FJ/gsDvLb8bxCSc=; b=qqlh/JN9n8RJEBokiGnAxNhN0JYAP8LH9ssawpqBRdfBUD+KaUDzRmfSzqZwR1xYuP OsROMuSlouzGDoMVE25LQ+G5mFp8y1r4ep0WzoXFev1QMY+Cu6CgTzGbBr3LnYtQcnIW ocBQ56rhjc8AcqW680TE6gBzdGP6DfhCZBTVXaXD7lvof9tApEPQacxrbCE0miLq41z7 nSG2YPS3SK5AXZulTbse7fV9W4Bt7DfZIzWFAuWdVc3n82ZNp/I2BEBUY6sbMCbdgRTU w4TBMOmvUNHsxKR8Nbk9EUJyMq2EBTSRJIWRg72/WpJEy+brsbZQGfMyaQOARcorbe7x Ct9A== X-Gm-Message-State: AIVw11371VnmIVm1KhfTOKMlvFb+xHazCf0rnsWjCtKQTYuKUqGKPmVo 9QtFIKk4AHSOlyzj/H4= X-Received: by 10.28.33.67 with SMTP id h64mr3970669wmh.87.1501686859551; Wed, 02 Aug 2017 08:14:19 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 194sm3535003wmu.38.2017.08.02.08.14.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 08:14:19 -0700 (PDT) Subject: Fwd: New Version Notification for draft-bryant-rtgwg-param-sync-03.txt References: <150168670034.5735.9904459987136374343.idtracker@ietfa.amsl.com> To: "rtgwg@ietf.org" , "rtgwg-chairs@ietf.org" From: Stewart Bryant X-Forwarded-Message-Id: <150168670034.5735.9904459987136374343.idtracker@ietfa.amsl.com> Message-ID: <850df623-6ea9-9996-54ef-a1460d6b1133@gmail.com> Date: Wed, 2 Aug 2017 16:14:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150168670034.5735.9904459987136374343.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------E13A3E62831A4041F8E76EB1" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:14:23 -0000 This is a multi-part message in MIME format. --------------E13A3E62831A4041F8E76EB1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have incorporated the edits proposed by Chris after the last IETF and would like to request WG adoption for this draft. - Stewart -------- Forwarded Message -------- Subject: New Version Notification for draft-bryant-rtgwg-param-sync-03.txt Date: Wed, 02 Aug 2017 08:11:40 -0700 From: internet-drafts@ietf.org To: Stewart Bryant , Chris Bowers , Alia Atlas A new version of I-D, draft-bryant-rtgwg-param-sync-03.txt has been successfully submitted by Stewart Bryant and posted to the IETF repository. Name: draft-bryant-rtgwg-param-sync Revision: 03 Title: Routing Timer Parameter Synchronization Document date: 2017-08-02 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-03.txt Status: https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/ Htmlized: https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-bryant-rtgwg-param-sync-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-03 Abstract: This document describes a mechanism for a link state routing protocol to coordinate the value of a routing timer parameter amongst routers in the flooding domain. The document also defines the solution to one specific case: the agreement of a common convergence timer value for use by routers in network convergence. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------E13A3E62831A4041F8E76EB1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


I have incorporated the edits proposed by Chris after the last IETF and would like to request WG adoption for this draft.

- Stewart

-------- Forwarded Message --------
Subject: New Version Notification for draft-bryant-rtgwg-param-sync-03.txt
Date: Wed, 02 Aug 2017 08:11:40 -0700
From: internet-drafts@ietf.org
To: Stewart Bryant <stewart.bryant@gmail.com>, Chris Bowers <cbowers@juniper.net>, Alia Atlas <akatlas@gmail.com> 


A new version of I-D, draft-bryant-rtgwg-param-sync-03.txt
has been successfully submitted by Stewart Bryant and posted to the
IETF repository.

Name:		draft-bryant-rtgwg-param-sync
Revision:	03
Title:		Routing Timer Parameter Synchronization
Document date:	2017-08-02
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-bryant-rtgwg-param-sync-03.txt
Status:         https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/
Htmlized:       https://tools.ietf.org/html/draft-bryant-rtgwg-param-sync-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bryant-rtgwg-param-sync-03
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bryant-rtgwg-param-sync-03

Abstract:
   This document describes a mechanism for a link state routing protocol
   to coordinate the value of a routing timer parameter amongst routers
   in the flooding domain.  The document also defines the solution to
   one specific case: the agreement of a common convergence timer value
   for use by routers in network convergence.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------E13A3E62831A4041F8E76EB1-- From nobody Fri Aug 4 12:46:27 2017 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 EBEC21201F2; Fri, 4 Aug 2017 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aop2HMJwz3e1; Fri, 4 Aug 2017 12:46:23 -0700 (PDT) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621951270AC; Fri, 4 Aug 2017 12:46:23 -0700 (PDT) Received: by mail-pg0-x243.google.com with SMTP id 123so2616833pga.5; Fri, 04 Aug 2017 12:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=4N9DWYHzKrQS7d2enBm5+Zos55L4NrTrDWLogP8DcoM=; b=gZMOodWrHbU8TaT6c6Kr4fUGmaefyTRJNNwuJnRnqhWgMpsGOEUx3IfvVUiMj1SgV+ jUkAb68pfa1lAdxcx48zNr6i56mXrGcdpnS5hldieRFk7+5hieafARtR7zln2/Yg/oKe l+WA/GW8M4hS7410fKA9PwTT46f84S1D2hqDo7S0XF3K69c5rm8Ze8snLrwqo+OSv4pU Zk6b+Xd/rBQN+jBk3Q4CLDtLA2/n4UrOPUsZ/9+uKhqfLh2WkA8dS0BoUtN2QlKOxrsx 8tRBn6dcrJdBZm4KJmEuBGq5bg88K0PQZcAaALqBVZyumjAhUv1i26XIvg5Abwm0Qbae V5Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=4N9DWYHzKrQS7d2enBm5+Zos55L4NrTrDWLogP8DcoM=; b=oAzfnF234Cpp22PPAaLeKdhOg/f2Pek+/kQX7mA+Fn/wRJ65DlrlREzamY/0PJHnUD asOnU/2ye0ce6ITboF3MsZLM4aV340LOxI2Ke0e+Z80s5JA6xL0Uw3OxaQ7C0JXomDSU GmdeWDGGzDAIdWM++JXMo0CLhL1ZAAt3z03kwOa8uuEkpAsG1JNcuUrLx8Bozg+/Avza prspJOily6NHUSdud6Tu8HOTvXFiS6/HlfSOk9q9c24L7G7IyVK3ZPGXgb0WehC/+2n/ SZd1zigw8ocwMZ6s2to6jZrz1ko012rw9+HQ+u3LmdLwkCZ6wTIU6OIHMaGfRdFRKPMz wIpg== X-Gm-Message-State: AIVw113NVWm3e+2/OaWr8EJOnqYk3lbcUQOQDh3wWV+tmPtpHAGP958u jjRrGBCiAMmwkvjV X-Received: by 10.98.0.149 with SMTP id 143mr3598808pfa.180.1501875982641; Fri, 04 Aug 2017 12:46:22 -0700 (PDT) Received: from [192.168.253.230] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.75]) by smtp.gmail.com with ESMTPSA id p9sm4109883pgn.87.2017.08.04.12.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 12:46:21 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Fri, 04 Aug 2017 12:46:20 -0700 Subject: Request for WG adoption of for draft-bryant-rtgwg-param-sync From: Jeff Tantsura To: RTGWG CC: 'rtgwg-chairs' , Message-ID: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> Thread-Topic: Request for WG adoption of for draft-bryant-rtgwg-param-sync Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 19:46:25 -0000 Dear RTGWG, The authors have requested the RTGWG to adopt for draft-bryant-rtgwg-param-sync as the working group document. WG expressed support during the last RTGWG meeting and the authors have addressed all the comments received. Please indicate support or no-support by August 18, 2017. If you are listed as a document author or contributor please respond to this email stating of whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. Cheers, Jeff From nobody Fri Aug 4 12:49:11 2017 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 117DE126BFD; Fri, 4 Aug 2017 12:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZi7xETzWqbK; Fri, 4 Aug 2017 12:49:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0901201F2; Fri, 4 Aug 2017 12:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22813; q=dns/txt; s=iport; t=1501876145; x=1503085745; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=5Ia31oDi6bw+rprraDRfhxwIltPWGjg5i7KqdagrSfc=; b=LFVMntSxgfH4YvZDI6vmc/gGdOZMFWPffsu53E+2v5JK86VgQsbgMijK pxgwZp5mPcqaLVWiuMqV4f5nW4A7gcL/t0p4cGOT42Wz2o1ZrY6Rc+q2D ZHWpc7TBxa6208jq1DO7+WoEXBbwPrwP8GrrABdQMph63V4IGVQey9xSA w=; X-IronPort-AV: E=Sophos;i="5.41,322,1498521600"; d="scan'208,217";a="276934920" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Aug 2017 19:49:05 +0000 Received: from [10.154.131.155] ([10.154.131.155]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v74Jn49l017110; Fri, 4 Aug 2017 19:49:04 GMT Message-ID: <5984CFB0.3070908@cisco.com> Date: Fri, 04 Aug 2017 12:49:04 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sikhivahan Gundu , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" , Stewart Bryant Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000808050303040308010906" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 19:49:09 -0000 This is a multi-part message in MIME format. --------------000808050303040308010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit HI, All members of the same SRLG group are assumed to fail if one of them fails. Going back to you example - L1 is in the same SRLG group as the primary link while L2 is belongs a different group - Hence if the primary link fails, only "L1" will fail and L2 will not - Hence only L2 is candidate to become a backup path while L1 is not - Hence there is no ambiguity Thanks Ahmed On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote: > > Hi, > > The draft mandates using "post-convergence path" as the backup path. > > It states one advantage, among others, of doing so as follows: > > "This .. helps to reduce the amount of path changes and hence service > > transients: one transition (pre-convergence to post-convergence) instead > > of two (pre-convergence to FRR and then post-convergence)". > > This suggests to me that the assumption here is that the post-convergence > > path can be uniquely determined in advance. > > However, SRLG introduces ambiguity. To illustrate the point, let us > say a > > loop-free alternative has two options: one link (L1) is of the same > metric > > value as the primary link and is also in the same SRLG as the primary; > the > > second option (L2) is in a different SRLG and has higher metric. > > The actual post-convergence path would depend on whether or not L1 > > also failed along with the primary, so is not uniquely computed in > advance. > > If TI-LFA picks L1, there might not be a guaranteed backup. If it > picks L2, > > there'd be two link transitions because L2 would not be in a (strict) SPF- > > computed post-convergence path. A third option, of course, is to give up > > declaring that there is no TI-LFA backup, but it'd be preferable to have > > some backup than have none at all. > > What do the authors suggest for this situation? > > Thanks, > > Sikhi > > > > *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Ahmed > Bashandy (bashandy) > *Sent:* 17 July 2017 12:56 > *To:* rtgwg@ietf.org > *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant > > *Subject:* Fwd: I-D Action: > draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > Hi, > > A new version of the ti-lfa draft has been posted to address Stewart > Bryant's comments > > Thanks > > Ahmed > > > -------- Original Message -------- > > *Subject: * > > > > I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > *Date: * > > > > Mon, 17 Jul 2017 00:19:37 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *Reply-To: * > > > > internet-drafts@ietf.org > > *To: * > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Topology Independent Fast Reroute using Segment Routing > Authors : Ahmed Bashandy > Clarence Filsfils > Bruno Decraene > Stephane Litkowski > Pierre Francois > Filename : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > Pages : 12 > Date : 2017-07-17 > > Abstract: > This document presents Topology Independent Loop-free Alternate Fast > Re-route (TI-LFA), aimed at providing protection of node and > adjacency segments within the Segment Routing (SR) framework. This > Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being > LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding > (DLFA). It extends these concepts to provide guaranteed coverage in > any IGP network. A key aspect of TI-LFA is the FRR path selection > approach establishing protection over post-convergence paths from > the point of local repair, dramatically reducing the operational > need to control the tie-breaks among various FRR options. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > 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 > orftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------000808050303040308010906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit HI,

All members of the same SRLG group are assumed to fail if one of them fails.

Going back to you example
- L1 is in the same SRLG group as the primary link while L2 is belongs a different group
- Hence if the primary link fails, only "L1" will fail and L2 will not
- Hence only L2 is candidate to become a backup path while L1 is not
- Hence there is no ambiguity

Thanks

Ahmed


On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote:

Hi,

 

The draft mandates using “post-convergence path” as the backup path. 

It states one advantage, among others, of doing so as follows:

 

“This .. helps to reduce the amount of path changes and hence service

transients: one transition (pre-convergence to post-convergence) instead

of two (pre-convergence to FRR and then post-convergence)”.

 

This suggests to me that the assumption here is that the post-convergence

path can be uniquely determined in advance.

 

However, SRLG introduces ambiguity. To illustrate the point,  let us say a

loop-free alternative has two options: one  link (L1) is of the same metric

value as the primary link and is also in the same SRLG as the primary; the

second option (L2) is in a different SRLG and has higher metric.

 

The actual post-convergence path would depend on whether or not L1

also failed along with the primary, so is not uniquely computed in advance.

If TI-LFA picks L1, there might not be a guaranteed backup. If it picks L2,

there’d be two link transitions because L2 would not be in a (strict) SPF-

computed post-convergence path. A third option, of course, is to give up

declaring that there is no TI-LFA backup, but it’d be preferable to have

some backup than have none at all.

 

What do the authors suggest for this situation?

 

Thanks,

Sikhi

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Hi,

A new version of the ti-lfa draft has been posted to address Stewart Bryant's comments

Thanks

Ahmed


-------- Original Message --------

Subject:

I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

Date:

Mon, 17 Jul 2017 00:19:37 -0700

From:

internet-drafts@ietf.org

Reply-To:

internet-drafts@ietf.org

To:

<i-d-announce@ietf.org>

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
 
        Title           : Topology Independent Fast Reroute using Segment Routing
        Authors         : Ahmed Bashandy
                          Clarence Filsfils
                          Bruno Decraene
                          Stephane Litkowski
                          Pierre Francois
        Filename        : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
        Pages           : 12
        Date            : 2017-07-17
 
Abstract:
   This document presents Topology Independent Loop-free Alternate Fast
   Re-route (TI-LFA), aimed at providing protection of node and
   adjacency segments within the Segment Routing (SR) framework.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
   (DLFA).  It extends these concepts to provide guaranteed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR path selection
   approach establishing protection over post-convergence paths from
   the point of local repair, dramatically reducing the operational
   need to control the tie-breaks among various FRR options.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
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

 

 


--------------000808050303040308010906-- From nobody Fri Aug 4 13:53:15 2017 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 6FBFC1241F5; Fri, 4 Aug 2017 13:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhFbVPJbhTyJ; Fri, 4 Aug 2017 13:53:12 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92527124217; Fri, 4 Aug 2017 13:53:12 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id d71so25461023oih.0; Fri, 04 Aug 2017 13:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HOBgUxZR/zcZGblmsAFTYzgiXXCbwtjonMzzlELTLQs=; b=cETHMULTM7U9kc1lc3qn6/uASILyNlBCXCiSXNjfsc87c5fBEpzjHBw7dB+T5860sw MaJ8jj0cS1wcO3rRWiMXcjL1g2JoO+yXdlXUHRLYrjpsYeryUj7aGRxEg+MVn4j3MUb0 /8vrQuT8s3CUv37Mv1QNCU+QlW2ENn8y3Ei01I94ZLQFYR9NzXnrPE1dsDQ7jxmc8Puj Z0CC6MgS9Yyfv3U7Mr9h6NsKzgY3vlyY90SUWAK3MdhmiltJa3yi2k/zbopBpWCbYUB+ FOAVt1IHouw5Tvp2jnIP3fkvDZT5KSgUnBj7KnWfMt21HbZJJqjzWw3GUZU2Pnv1TS7Z gHKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HOBgUxZR/zcZGblmsAFTYzgiXXCbwtjonMzzlELTLQs=; b=C0S0+LrbKW25Cc/IJgO5Uu4frW2E708mJd/Ayr7zigFAyYuO1DBdiQcCxWMUxZU5QK 8eDz0P8L3zm+0KKlYDu5o8XrgGRycoB4xCaH1IcQdMNWdwAiplTuYL0a96cxU0PFk2/J Rdgu0z2wF3hFPJUEQsxRTBsziwnG4qnrk4MWcZnjQYdkLUAPHwb8qM36j7ZEUBBQrvwS ylTSVqgH93v87oBzXm721svKehMRrD0/9n6/8GypgqXJf40fbYJe+OQBUCMDQw3+sbYE pFqebW6uYsqsi0/IdaQ2V2DNgDmnOnDXQS4Lv5sPE021GthWJa32PG9E8/RfvUFMxkY7 vWSw== X-Gm-Message-State: AIVw112O+AvjnPX2mdKsDW3u31Sy1i0QTINN4uW4Xi5WI8vpAAvla+d9 DK4H7V6m+XR0qqw2hMfE+xi/2WioAQ== X-Received: by 10.202.8.67 with SMTP id 64mr2826069oii.305.1501879991977; Fri, 04 Aug 2017 13:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.232.34 with HTTP; Fri, 4 Aug 2017 13:52:51 -0700 (PDT) In-Reply-To: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> References: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> From: "Andrew G. Malis" Date: Fri, 4 Aug 2017 16:52:51 -0400 Message-ID: Subject: Re: Request for WG adoption of for draft-bryant-rtgwg-param-sync To: Jeff Tantsura Cc: RTGWG , draft-bryant-rtgwg-param-sync@ietf.org, rtgwg-chairs Content-Type: multipart/alternative; boundary="94eb2c12e4146acc1f0555f3af3f" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 20:53:14 -0000 --94eb2c12e4146acc1f0555f3af3f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve read the draft, and it=E2=80=99s useful functionality. I suppo= rt its adoption. Cheers, Andy On Fri, Aug 4, 2017 at 3:46 PM, Jeff Tantsura wrote: > Dear RTGWG, > > The authors have requested the RTGWG to adopt for > draft-bryant-rtgwg-param-sync as the working group document. > > WG expressed support during the last RTGWG meeting and the authors have > addressed all the comments received. > Please indicate support or no-support by August 18, 2017. > > If you are listed as a document author or contributor please respond to > this email stating of whether or not you are aware of any relevant IPR. T= he > response needs to be sent to the RTGWG mailing list. The document will no= t > advance to the next stage until a response has been received from each > author and each individual that has contributed to the document. > > Cheers, > Jeff > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --94eb2c12e4146acc1f0555f3af3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve read the draft, and it=E2=80=99s useful funct= ionality. I support its adoption.

Cheers,
Andy=


On Fri, Aug 4, 2017 at 3:46 PM, Jeff Tantsura &= lt;jefftant.ie= tf@gmail.com> wrote:
Dear R= TGWG,

The authors have requested the RTGWG to adopt for draft-bryant-rtgwg-param-= sync as the working group document.

WG expressed support during the last RTGWG meeting and the authors have add= ressed all the comments received.
Please indicate support or no-support by August 18, 2017.

If you are listed as a document author or contributor please respond to thi= s email stating of whether or not you are aware of any relevant IPR. The re= sponse needs to be sent to the RTGWG mailing list. The document will not ad= vance to the next stage until a response has been received from each author= and each individual that has contributed to the document.

Cheers,
Jeff



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--94eb2c12e4146acc1f0555f3af3f-- From nobody Fri Aug 4 14:44:49 2017 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 D47681241F5; Fri, 4 Aug 2017 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-6-sBPSd0nB; Fri, 4 Aug 2017 14:44:46 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E7F12708C; Fri, 4 Aug 2017 14:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1779; q=dns/txt; s=iport; t=1501883086; x=1503092686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fJXGNPHE5oWP9KHzPO6wWbv5Atd3gGeCwEg2DTx7XaU=; b=BVxavu3aVwWvPFAzlQh3A9+e3iOPThK05NIxQRgnIHmKP+DzC+wDdN9B eXpLYDZZ/664Q/kMkZnp8ai/KNdMWK8d7Ty4hxRxy+9Ex6Ksa3bmgm0rE 4aogVYPTbV+vZ6cF/YnKSRK7SeAtJY7SxAy6DwQIn7FFwb06xt5e0+Iwo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAABE6oRZ/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgiQB4FulhUOggQhC4UbAoRLPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMBATg0BgUMBAIBCBEEAQEfCQcnCxQJCAIEAQ0FCIonELExi0cBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMoggKBTIUKgSSDGQMBEgGGEwWQcY8UApQkghi?= =?us-ascii?q?FWIpicJURAR84fwt3FR8qhxp2hzaBI4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,322,1498521600"; d="scan'208";a="276935809" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 21:44:45 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v74Lii81011981 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 21:44:45 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 16:44:44 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Fri, 4 Aug 2017 16:44:44 -0500 From: "Les Ginsberg (ginsberg)" To: Jeff Tantsura , RTGWG CC: "draft-bryant-rtgwg-param-sync@ietf.org" , "'rtgwg-chairs'" Subject: RE: Request for WG adoption of for draft-bryant-rtgwg-param-sync Thread-Topic: Request for WG adoption of for draft-bryant-rtgwg-param-sync Thread-Index: AQHTDVplaZAvk+2sXU2UnDK8J1jbm6J0ufqA Date: Fri, 4 Aug 2017 21:44:44 +0000 Message-ID: References: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> In-Reply-To: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.27.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:44:48 -0000 I appreciate that the authors have modified the draft in response to some c= omments I made - and I believe the changes satisfy my concerns. I support WG adoption with one significant caveat - the title of the docume= nt needs to be modified to accurately reflect the scope of the revised draf= t. This is now confined to defining how to advertise "routing timer paramet= ers" - it is no longer a generalized "any flavor of routing parameter" - wh= ich is one of the points I made in my objections. Please modify the name to accurately reflect the redefined scope. Les > -----Original Message----- > From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsura > Sent: Friday, August 04, 2017 12:46 PM > To: RTGWG > Cc: draft-bryant-rtgwg-param-sync@ietf.org; 'rtgwg-chairs' > Subject: Request for WG adoption of for draft-bryant-rtgwg-param-sync >=20 > Dear RTGWG, >=20 > The authors have requested the RTGWG to adopt for draft-bryant-rtgwg- > param-sync as the working group document. >=20 > WG expressed support during the last RTGWG meeting and the authors have > addressed all the comments received. > Please indicate support or no-support by August 18, 2017. >=20 > If you are listed as a document author or contributor please respond to t= his > email stating of whether or not you are aware of any relevant IPR. The > response needs to be sent to the RTGWG mailing list. The document will no= t > advance to the next stage until a response has been received from each > author and each individual that has contributed to the document. >=20 > Cheers, > Jeff >=20 >=20 >=20 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From nobody Fri Aug 4 14:48:50 2017 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 C1F7F12708C; Fri, 4 Aug 2017 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKyiz36P_cNo; Fri, 4 Aug 2017 14:48:47 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C1212711E; Fri, 4 Aug 2017 14:48:46 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id y67so3760477wrb.3; Fri, 04 Aug 2017 14:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=EuJs2EWIg+0u7JxLL0bJ3jZMgLD93gu0nSa8CIU8L88=; b=mYSf8TyrhWSH7ruauRWdPdFgExqdXFwUGgpUEHFCr16zeHuL5QwVcahZtvZ8SRp1lI x88hJ04pHBMZf3pbjnQT7wqL2K0qbfYzeWCyjZKsAKoBL1R12wClPlIYTuzjVQaVnX2d 9SHIV2arPUBciVVhFbmtTWxBKWxG5l1Jjjp5GuQdugAQuZHFc0MTDw2Evr8bbEwnV5yD 1VMeuM6thMdyr7w/nmEBHO9KkGFy57n0bweOwcopv4lO5RSrhS0UDmjixQBwrDmkKCtl NY99llk4Hcn0xf60jpzBKYWE/Q9kXiPgi6yRzx6GSR+Fx+1yaPikYL+qrnIyA3u0E1bS TEKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=EuJs2EWIg+0u7JxLL0bJ3jZMgLD93gu0nSa8CIU8L88=; b=VdaCxjVOa2FB05RSSHgI3slnm01znUwlqX2yFdKqmzQn5zOk/z/IKEFDRo4jX3iB4H ynIHBlabXbdpL6Ww74oJ8H4TBUaJdcsHzNWMY5TNC66bA9uiKDij3yGkGFXEYQ4OhE+i VsvPK4qFRz2LWjER7la19oC9KrkKl6zXnorqfTRq1x5ffY6Hhwg+pno+XDuE2V4zY8+A pwmQH+9I45S16tBsV7FxFIqSbvwOsNgF+sogw7p0pzj+ZCae1Rk0Vzx+yPXCVFT0lGue a5U7ZumFFtmJ6lWyRPyAbBY4INBIKd63b1DQO3okytrrUUVdSWr0mrUvzqWtIhlH5Wwv 1UJA== X-Gm-Message-State: AIVw112YKGAjPVO6l3PGzoLysBw8tSvhTOS6zWJvNh3pTrGG0sQVzJd5 c+j/yKKqP+y4vw== X-Received: by 10.223.169.51 with SMTP id u48mr2732536wrc.109.1501883325402; Fri, 04 Aug 2017 14:48:45 -0700 (PDT) Received: from [192.168.3.102] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id e76sm4498158wmd.36.2017.08.04.14.48.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Aug 2017 14:48:44 -0700 (PDT) References: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <80BF560A-6D02-40FF-9E9D-918EDDB6F66A@gmail.com> Cc: Jeff Tantsura , RTGWG , "draft-bryant-rtgwg-param-sync@ietf.org" , rtgwg-chairs X-Mailer: iPad Mail (13G36) From: Gmail Subject: Re: Request for WG adoption of for draft-bryant-rtgwg-param-sync Date: Fri, 4 Aug 2017 22:48:43 +0100 To: "Les Ginsberg (ginsberg)" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 21:48:50 -0000 NP, we should also change the draft name, but suggest that is done when the a= doption poll completes. Stewart Sent from my iPad > On 4 Aug 2017, at 22:44, Les Ginsberg (ginsberg) wrot= e: >=20 > I appreciate that the authors have modified the draft in response to some c= omments I made - and I believe the changes satisfy my concerns. >=20 > I support WG adoption with one significant caveat - the title of the docum= ent needs to be modified to accurately reflect the scope of the revised draf= t. This is now confined to defining how to advertise "routing timer paramete= rs" - it is no longer a generalized "any flavor of routing parameter" - whic= h is one of the points I made in my objections. >=20 > Please modify the name to accurately reflect the redefined scope. >=20 > Les >=20 >=20 >> -----Original Message----- >> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsura >> Sent: Friday, August 04, 2017 12:46 PM >> To: RTGWG >> Cc: draft-bryant-rtgwg-param-sync@ietf.org; 'rtgwg-chairs' >> Subject: Request for WG adoption of for draft-bryant-rtgwg-param-sync >>=20 >> Dear RTGWG, >>=20 >> The authors have requested the RTGWG to adopt for draft-bryant-rtgwg- >> param-sync as the working group document. >>=20 >> WG expressed support during the last RTGWG meeting and the authors have >> addressed all the comments received. >> Please indicate support or no-support by August 18, 2017. >>=20 >> If you are listed as a document author or contributor please respond to t= his >> email stating of whether or not you are aware of any relevant IPR. The >> response needs to be sent to the RTGWG mailing list. The document will no= t >> advance to the next stage until a response has been received from each >> author and each individual that has contributed to the document. >>=20 >> Cheers, >> Jeff >>=20 >>=20 >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg From nobody Fri Aug 4 15:12:25 2017 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 32527126D46; Fri, 4 Aug 2017 15:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3dn5y5xEgkT; Fri, 4 Aug 2017 15:12:21 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896D3128BC8; Fri, 4 Aug 2017 15:12:21 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id t86so2966063pfe.1; Fri, 04 Aug 2017 15:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=QtUzcQ3vdYH+DVth/HuxJZtW8MYgRqrkeUPVLtwGAkg=; b=u7hh3OC0t1TSa9IYj3G6QqgHkjXBdyQ1qbVhwcptE/uiF7Ju5asFOaOrSaCctmqkDB 0cY+HhTp5QdHu7WeLjuyZEWyQWg75YWFNQ6seqZNNdlVkDAvHSHpOtiLJDDuhs+H6zta gA8gwLoUHPJAMomp6fG86kPAec2o9Qilt67hHFOcemUcIR71Jgv1U2OV40Ze0Xc+0NjZ OSxZUi69DHxzSGx5UN4ImWezhvDpayArGIKGwlSfWUXU1o+5Wy2OezdDTr/1If+gUkOW QjB3HTElmfwhjhj6igdHRAd44/Rjvq83ivCmUybNqn7TVJFos3ZtwDY1ZY+D3k744PO2 Ca1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=QtUzcQ3vdYH+DVth/HuxJZtW8MYgRqrkeUPVLtwGAkg=; b=MRMup2ufRgCn241QbQK9IdkBAH8ri+zgDqVQi7aS9mO5I2EDTArnodkKd3FmY29Nnz 9nlPH1N0nrwtXjT9XQ92Xji2EK7o7r6fmheIwXx6b2w27uP3uP2ikOnzGW6SWPzDsDGN GKtPUqPWHHATZiGDN7b0D1OTgbBbrVRUETIHxyIO9kdjLS9iHCP1fG1e7UI76tR7FCeI KgsbLQGhcv0cJCTZ8fu6EZLAFzliLadr6c//9eghBZdMub/M1mvRXG0ONX2HrlQwOeME 3GJfJTDl4EDv/dXdWN5JqVo/tFimjonZ1b/utwGbUJAVJEbAX1uUZ26IA+wgR8qfltb7 GaYQ== X-Gm-Message-State: AIVw1107p52zX6AWO+uqo+fViQ2QPGcCcztVb5JmLtXqSbmkimz/L5g8 IeQWKw5pnL+VGQ== X-Received: by 10.98.11.135 with SMTP id 7mr4083672pfl.45.1501884741017; Fri, 04 Aug 2017 15:12:21 -0700 (PDT) Received: from [192.168.253.230] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.75]) by smtp.gmail.com with ESMTPSA id 74sm9121892pfk.58.2017.08.04.15.12.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 15:12:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Fri, 04 Aug 2017 15:12:18 -0700 Subject: Re: Request for WG adoption of for draft-bryant-rtgwg-param-sync From: Jeff Tantsura To: Gmail , "Les Ginsberg (ginsberg)" CC: RTGWG , "draft-bryant-rtgwg-param-sync@ietf.org" , rtgwg-chairs Message-ID: <857BE46D-92EB-4F69-8D03-867B17201B3E@gmail.com> Thread-Topic: Request for WG adoption of for draft-bryant-rtgwg-param-sync References: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> <80BF560A-6D02-40FF-9E9D-918EDDB6F66A@gmail.com> In-Reply-To: <80BF560A-6D02-40FF-9E9D-918EDDB6F66A@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 22:12:24 -0000 I=E2=80=99m Ok with this approach. When/if the draft gets adopted the new version would be published with the = new name. Cheers, Jeff P.S. Stewart =E2=80=93 Unless you have changed your name to =E2=80=9CGmail=E2=80=9D, you migh= t want to change it to reflect your real name ;-) -----Original Message----- From: Gmail Date: Friday, August 4, 2017 at 14:48 To: "Les Ginsberg (ginsberg)" Cc: Jeff Tantsura , RTGWG , "draft= -bryant-rtgwg-param-sync@ietf.org" ,= rtgwg-chairs Subject: Re: Request for WG adoption of for draft-bryant-rtgwg-param-sync NP, we should also change the draft name, but suggest that is done when= the adoption poll completes. =20 Stewart =20 Sent from my iPad =20 > On 4 Aug 2017, at 22:44, Les Ginsberg (ginsberg) = wrote: >=20 > I appreciate that the authors have modified the draft in response to = some comments I made - and I believe the changes satisfy my concerns. >=20 > I support WG adoption with one significant caveat - the title of the = document needs to be modified to accurately reflect the scope of the revised= draft. This is now confined to defining how to advertise "routing timer par= ameters" - it is no longer a generalized "any flavor of routing parameter" -= which is one of the points I made in my objections. >=20 > Please modify the name to accurately reflect the redefined scope. >=20 > Les >=20 >=20 >> -----Original Message----- >> From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Jeff Tantsu= ra >> Sent: Friday, August 04, 2017 12:46 PM >> To: RTGWG >> Cc: draft-bryant-rtgwg-param-sync@ietf.org; 'rtgwg-chairs' >> Subject: Request for WG adoption of for draft-bryant-rtgwg-param-syn= c >>=20 >> Dear RTGWG, >>=20 >> The authors have requested the RTGWG to adopt for draft-bryant-rtgwg= - >> param-sync as the working group document. >>=20 >> WG expressed support during the last RTGWG meeting and the authors h= ave >> addressed all the comments received. >> Please indicate support or no-support by August 18, 2017. >>=20 >> If you are listed as a document author or contributor please respond= to this >> email stating of whether or not you are aware of any relevant IPR. T= he >> response needs to be sent to the RTGWG mailing list. The document wi= ll not >> advance to the next stage until a response has been received from ea= ch >> author and each individual that has contributed to the document. >>=20 >> Cheers, >> Jeff >>=20 >>=20 >>=20 >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg =20 From nobody Sun Aug 6 22:45:11 2017 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 046E0128BC8; Sun, 6 Aug 2017 22:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BDZD4wxDdv6; Sun, 6 Aug 2017 22:45:06 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42B68128A32; Sun, 6 Aug 2017 22:45:04 -0700 (PDT) X-AuditID: c1b4fb2d-c3b2c9c000005f66-37-5987fe5e3df0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.95.24422.E5EF7895; Mon, 7 Aug 2017 07:45:03 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 7 Aug 2017 07:45:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k58lMElRRsJ1jKtluyOa3crrdbS6a2okvsW4jyAuxVg=; b=Za86J8T8Zb55+PHeZCNgEB6YyFKRgKaShdlv6iQMVisGSjK0V3st+U5HSVm8Pa4QqanF5JIY++TMbRK2lAt/hlA4JstMFl1tPEUXfm1ZIs7HddO2g+8T6URYqO8hRBakb0aqYMcoWQee/8ONV0582a+g+fe885B2u3427XC7VUU= Received: from HE1PR07MB1708.eurprd07.prod.outlook.com (10.166.124.150) by HE1PR07MB3162.eurprd07.prod.outlook.com (10.170.245.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Mon, 7 Aug 2017 05:45:00 +0000 Received: from HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71]) by HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71%13]) with mapi id 15.01.1320.012; Mon, 7 Aug 2017 05:45:00 +0000 From: Sikhivahan Gundu To: "Ahmed Bashandy (bashandy)" , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" , Stewart Bryant Subject: RE: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Topic: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Index: AQHS/s4TUl1vutply0WzIUPGFdTcIaJvH4nQgAWYTgCAApE/AA== Date: Mon, 7 Aug 2017 05:45:00 +0000 Message-ID: References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> In-Reply-To: <5984CFB0.3070908@cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.16.128.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3162; 6:R084WSYKN7ui1GCvBMS0mpKqMfI1sTKwQ4YhMP4nxkZK0HLf84IyPt/KuXdfUn+yl0R64fwSvg8QLnhdl/ADN5qskJjAX0NtYECLcmXCymIf2d2oDI6XLGKogzaBDNT0VcKu3HO4NUZHczyQkYdeZF+MYfJyY/W7JCfPXSrt9ShsZrjfNA0srwRBlAUogOdJDNUekR97DDfVVVIEpcTPJJK9xA2MZXEcmlEj9VhnMAnnBq9Jd5Q2bg8kekixqOYZuregPlAKmHuQUJNoXlRwlcBAFJpe0UHG4mPKFa/Rp+elHkxUfUmDYvA8bD95+menovpqWrUSFkqgvBLB+fY5IQ==; 5:vwZ4I8/dCKCCCNLNAvp3/BNmxXsbd9HjrGGAdRwRjpDTvBy+MA4AS/drO+qOt3e0FgpvbKBObH0kobqwYxCeSGnmaWY7UEiMPiij9DUt9zBEM711hPSBPhVoBYRaZGl4NJDdiO4n7ddNAsBGsNMT3w==; 24:Yv/WIBjuT+DUS80aDPZJzII4mGQ0rSFjZ7TCjZw1oRurnYkmoOTYMZ1yAi1s6js+finXkUIcR17BC/AH1V8Nf4ao2mfyX6XY/+a6ri4eoy8=; 7:v4Lt4PrFoApx/k8zbKqDyV7sRPjseTwwRp1dmU8i5irBP11g5k8vTJrmi3dFX9Tf9jUOB4qOsoIqm8EjxXtYuunAT6rSBLfgStv7dJVhGBDtaKffsvk007h6vhc6Ca+e5YuFWPKmVnmzYNu7ZGdB4u55rW5pb7IAgrEZHjGgxP3t6uMsrCtAhn0HkPaK80+bqhZzGwJErS0cmjvy2xstWNCc+AN/i4WbLEMsp4E/E9s= x-ms-office365-filtering-correlation-id: 107ac9dc-9ac3-4122-4cbe-08d4dd577193 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603120)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB3162; x-ms-traffictypediagnostic: HE1PR07MB3162: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(95692535739014)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3162; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3162; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(13464003)(377454003)(377424004)(24454002)(189002)(199003)(39060400002)(33656002)(76176999)(50986999)(54356999)(38730400002)(3660700001)(478600001)(3280700002)(93886004)(7736002)(101416001)(55016002)(4326008)(106356001)(54896002)(105586002)(54906002)(230783001)(6306002)(6436002)(25786009)(81166006)(81156014)(5660300001)(7696004)(8676002)(9686003)(3846002)(102836003)(6116002)(2906002)(790700001)(53936002)(74316002)(6246003)(66066001)(99286003)(9326002)(8936002)(236005)(229853002)(2501003)(86362001)(966005)(5250100002)(68736007)(2900100001)(6506006)(2950100002)(97736004)(53546010)(606006)(14454004)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3162; H:HE1PR07MB1708.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sikhivahan.gundu@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB170870985873654D8C0BC340EAB50HE1PR07MB1708eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 05:45:00.2673 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3162 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOTvfts/R4uQFX037Y1R4yWUlskrEkshqhRmURqVTP1Scl/ap pCFYZoJdLCtrs5qmKV00S0PNu3lLzRsSq5zRvKBoKUUOsSS3T8H/fu/7PM95z3k5NLZs5tvT UbEJjCpWoZQIRJQ6sMrLLXgpM8i9YATL2isGKJmu7w5P1lhaiGX9M4tYVjybhnz4fncXX/P9 tBOn/Go0eqFfUdECz586LfIKZ5RRSYxqu3eIKLKoeYQf/6MTXSiY6sZp6PIrlIVoGogHTH07 mYVEtCVpRdA3+wBnIYvlogOBuok1CRS5gSFHNyfgXLk8GLpk5HOFAUFer45nigiIJ/zVPzWz NQmCHvU8NpkwSUfwvsogNAlW5Ahk6SZWTHIYH7iHOd4Ps82DZg9FNsPClXdmFpMzUFY+R3HT hhBk65cEJsGCOMOjhjZzGBFHMJYtUSbGxBa+jGnNA4AQKKrrwxzbwNToEp9jCVSoJ1c8jjCo vYZMA4BcFUJeQ6GQE45C5dvHFLclAw+alFzbBXILp1bOiYaHxmy8ysaFborjFj58fSnmog5w fVbKHf9dACX/nqwsmIGS0gx0C7lq1lxbsxzBJA7Ku/w15udvgA/qMYqzbIP82l8Cjl2huGAa r3JP0yhvbT8fCZ8jG5Zh2ZiInbukjCoqjGXjYqWxTMIbtPyxmisX3arRi+l9LYjQSLJO7Dud GWTJVySxyTEtCGgssRbHRC23xOGK5BRGFResSlQybAvaSFMSW7FPQ3+gJYlQJDDRDBPPqFZV Hm1hn4ZCZtxv1lTs7glzbPD1rhOfKOnV1R7/WFk/c96m2uPwzxSne31SuXSgK6Bq7/349GPy dgd1qTYgQ3tguPF3vTzSoM9AcQtOw5+sHHN6/hDkea7Rbo9hpi3UedLuWajd5/RD7R1bs+cX c+UXUw+KvNcnGTsTU7fcdjvLK9/UqrTXj0soNlKxwwWrWMV/xpFID1QDAAA= Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 05:45:10 -0000 --_000_HE1PR07MB170870985873654D8C0BC340EAB50HE1PR07MB1708eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your response. >> - Hence if the primary link fails, only "L1" will fail and L2 will not L1 _may_ fail, with high probability, but it may also not fail. If it does not fail, there is a second transitioning of the post-primary-failure link from FRR-backup (L2) to post-convergence link (L1), because L1 has a smaller metric. By "ambiguity", I meant that backup calculation taking SRLG into account is based on speculated topology, whereas computation of post-convergence path, ie, SPF, is based on actual topology. This seems needs reconciling since in TI-LFA the backup is by definition the post-convergence path, with a single path-transition after link-failure as the intended outcome. Do I understand correctly that the draft prefers to relax that expectation for SRLG? Thanks, Sikhi From: Ahmed Bashandy (bashandy) [mailto:bashandy@cisco.com] Sent: 05 August 2017 01:19 To: Sikhivahan Gundu ; rtgwg@ietf.org Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt HI, All members of the same SRLG group are assumed to fail if one of them fails= . Going back to you example - L1 is in the same SRLG group as the primary link while L2 is belongs a di= fferent group - Hence if the primary link fails, only "L1" will fail and L2 will not - Hence only L2 is candidate to become a backup path while L1 is not - Hence there is no ambiguity Thanks Ahmed On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote: Hi, The draft mandates using "post-convergence path" as the backup path. It states one advantage, among others, of doing so as follows: "This .. helps to reduce the amount of path changes and hence service transients: one transition (pre-convergence to post-convergence) instead of two (pre-convergence to FRR and then post-convergence)". This suggests to me that the assumption here is that the post-convergence path can be uniquely determined in advance. However, SRLG introduces ambiguity. To illustrate the point, let us say a loop-free alternative has two options: one link (L1) is of the same metric value as the primary link and is also in the same SRLG as the primary; the second option (L2) is in a different SRLG and has higher metric. The actual post-convergence path would depend on whether or not L1 also failed along with the primary, so is not uniquely computed in advance. If TI-LFA picks L1, there might not be a guaranteed backup. If it picks L2, there'd be two link transitions because L2 would not be in a (strict) SPF- computed post-convergence path. A third option, of course, is to give up declaring that there is no TI-LFA backup, but it'd be preferable to have some backup than have none at all. What do the authors suggest for this situation? Thanks, Sikhi From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (ba= shandy) Sent: 17 July 2017 12:56 To: rtgwg@ietf.org Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx= t Hi, A new version of the ti-lfa draft has been posted to address Stewart Bryant= 's comments Thanks Ahmed -------- Original Message -------- Subject: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Date: Mon, 17 Jul 2017 00:19:37 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Topology Independent Fast Reroute using Segment R= outing Authors : Ahmed Bashandy Clarence Filsfils Bruno Decraene Stephane Litkowski Pierre Francois Filename : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx= t Pages : 12 Date : 2017-07-17 Abstract: This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lf= a/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-= ti-lfa-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-bashandy-rtgwg-segment-routing-ti= -lfa-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. 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 --_000_HE1PR07MB170870985873654D8C0BC340EAB50HE1PR07MB1708eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks for your response.

 

>> - Hence if the primary link fails, only "L1" will fail and= L2 will not

 

L1 _may_ fail, with high probability, but it = may also not fail. If it does

not fail, there is a second transitioning of the pos= t-primary-failure

link from FRR-backup (L2) to post-convergence link (= L1), because L1

has a smaller metric.

 

By “ambiguity”, I meant that backup calculation taking = SRLG into

account is  based on speculated topology,  whereas comput= ation of

post-convergence path, ie, SPF, is based on actual topology.  = This

seems needs reconciling since in  TI-LFA the backup is by defi= nition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly tha= t

the draft prefers to relax that expectation for SRLG?

 

Thanks,

Sikhi

 

 

F= rom: Ahmed Basha= ndy (bashandy) [mailto:bashandy@cisco.com]
Sent: 05 August 2017 01:19
To: Sikhivahan Gundu <sikhivahan.gundu@ericsson.com>; rtgwg@ie= tf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stew= art@g3ysx.org.uk>
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa= -01.txt

 

HI,

All members of the same SRLG group are assumed to fail if one of them fails= .

Going back to you example
- L1 is in the same SRLG group as the primary link while L2 is belongs a di= fferent group
- Hence if the primary link fails, only "L1" will fail and L2 wil= l not
- Hence only L2 is candidate to become a backup path while L1 is not
- Hence there is no ambiguity

Thanks

Ahmed

On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote:

Hi,

 

The draft mandates using “post-convergence = path” as the backup path. 

It states one advantage, among others, of doing s= o as follows:

 

“This .. helps to reduce the amount of path= changes and hence service

transients: one transition (pre-convergence to po= st-convergence) instead

of two (pre-convergence to FRR and then post-conv= ergence)”.

 

This suggests to me that the assumption here is t= hat the post-convergence

path can be uniquely determined in advance.<= /o:p>

 

However, SRLG introduces ambiguity. To illustrate= the point,  let us say a

loop-free alternative has two options: one  = link (L1) is of the same metric

value as the primary link and is also in the same= SRLG as the primary; the

second option (L2) is in a different SRLG and has= higher metric.

 

The actual post-convergence path would depend on = whether or not L1

also failed along with the primary, so is not uni= quely computed in advance.

If TI-LFA picks L1, there might not be a guarante= ed backup. If it picks L2,

there’d be two link transitions because L2 = would not be in a (strict) SPF-

computed post-convergence path. A third option, o= f course, is to give up

declaring that there is no TI-LFA backup, but it&= #8217;d be preferable to have

some backup than have none at all.

 

What do the authors suggest for this situation?

 

Thanks,

Sikhi

 

 

F= rom: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lf= a-01.txt

 

Hi,

A new version of the ti-lfa draft has been posted to= address Stewart Bryant's comments

Thanks

Ahmed


-------- Original Message --------

Subjec= t:

I-D Action: draft-bashandy-rtgwg-segment-routing-ti-= lfa-01.txt

Date: =

Mon, 17 Jul 2017 00:19:37 -0700

From: =

internet= -drafts@ietf.org

Reply-= To:

internet= -drafts@ietf.org

To:

<i-d-ann= ounce@ietf.org>

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.
 
 
        Title   &nbs=
p;       : Topology Independent Fast Reroute =
using Segment Routing
        Authors   &n=
bsp;     : Ahmed Bashandy
           &nbs=
p;            &=
nbsp; Clarence Filsfils
           &nbs=
p;            &=
nbsp; Bruno Decraene
           &nbs=
p;            &=
nbsp; Stephane Litkowski
           &nbs=
p;            &=
nbsp; Pierre Francois
        Filename   &=
nbsp;    : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.tx=
t
        Pages   &nbs=
p;       : 12
        Date    =
;        : 2017-07-17
 
Abstract:
   This document presents Topology Independent Loop-free Alt=
ernate Fast
   Re-route (TI-LFA), aimed at providing protection of node =
and
   adjacency segments within the Segment Routing (SR) framew=
ork.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR conc=
epts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed f=
orwarding
   (DLFA).  It extends these concepts to provide guaran=
teed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR =
path selection
   approach establishing protection over post-convergence pa=
ths from
   the point of local repair, dramatically reducing the oper=
ational
   need to control the tie-breaks among various FRR options.=

 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-s=
egment-routing-ti-lfa/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-r=
outing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-bash=
andy-rtgwg-segment-routing-ti-lfa-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-bashandy=
-rtgwg-segment-routing-ti-lfa-01
 
 
Please note that it may take a couple of minutes from the time of subm=
ission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-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.iet=
f.org/ietf/1shadow-sites.txt


 

 

 

--_000_HE1PR07MB170870985873654D8C0BC340EAB50HE1PR07MB1708eurp_-- From nobody Mon Aug 7 01:40:28 2017 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 B62AF13218E for ; Mon, 7 Aug 2017 01:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcwEG-BofobT for ; Mon, 7 Aug 2017 01:40:26 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAEE1288B8 for ; Mon, 7 Aug 2017 01:40:25 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1dedaH-001g8X-Nc; Mon, 07 Aug 2017 10:40:22 +0200 Date: Mon, 7 Aug 2017 10:40:21 +0200 From: David Lamparter To: Fred Baker Cc: Matthieu Boutier , Anton Smirnov , "rtgwg@ietf.org" Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Message-ID: <20170807084021.GR773745@eidolon> References: <20170719172913.GU773745@eidolon> <670146D0-A26A-4AA5-AC6C-253B81271C12@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <670146D0-A26A-4AA5-AC6C-253B81271C12@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 08:40:28 -0000 On Thu, Jul 27, 2017 at 07:23:46PM -0700, Fred Baker wrote: > > On Jul 27, 2017, at 2:06 AM, Matthieu Boutier wrote: > > > > Did you agree that: > > > > 1. destination first give the correct behaviour as-is. > > > > 2. source first needs extra mechanism and route duplication. > > Actually, I don't. I can produce cases in which source first gives the > wrong route, and in which destination first gives the wrong route. The > only way I see to make doing either one first *always* gives the right > result is if a small set of routes is duplicated. You're right, and we have a SNAFU in terminology here. rtgwg-dst-src-routing isn't suggesting "destination-first". It's "destination-first with fallthrough". The set of routes that need to be duplicated for destination-first is exactly this small set that is covered by fallthrough. Duplicating these routes is what appendix A.1. of dst-src-routing-05 is describing; particularly because this duplication significantly reduces worst-case forwarding/lookup cost - going from "129x129" to "129+129". [Conversely, appendix A.2. describes translation to "source-first".] I'll check the draft for whether this terminology SNAFU is in there too. It explicitly describes the fallthrough as backtracking, so it's definitely not a content/specification issue, but it may well be jumbled wording. FWIW, the Linux kernel implements "destination-first with fallthrough" plus the separate source-first policy routing feature. Also, somewhat relatedly, there were quite a few caching issues back when this was fresh. > The issue is when prefixes overlap. If you have sources S1 and S2, > destinations D1 and D2, D1 is a more specific of D2, and D1 is > advertised by S1 but not S2, and D2 is advertised by S2. If you are > looking from S1, you should find S1->D1, and if you are looking from > S2, you should find S2->D2. If you look destination first, and happen > to be looking from S2, I think you wind up trying to find S2->D1, > which doesn't exist. Right, hence the fallthrough from D1 to D2. > Every time I get my head into this space, I have to rethink it, and > the emails I wrote a few years back are unavailable to me now as I am > no longer at Cisco. I need to think the source version through again. > But you get the idea. I have pretty much convinced myself that you > need to duplicate S2->D2 as S2->D1 but with the next hop associated > with S2->D2 in order to make destination first work. There is a > similar case regarding source-first lookup. Source-first lookup simply requires a lot more duplicated routes to get the same local connectivity coverage. (And fallthrough doesn't help, because the source-first entry would usually have a default route.) > This is the reason I have suggested a PATRICIA algorithm or something > like it that looks up both addresses at the same time. I've tried to describe the behaviour in terms of functional requirements; hence A.1 and A.2 as appendixes describing efficient implementation choices. Cheers, -David From nobody Mon Aug 7 01:56:44 2017 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 76B0C13218F for ; Mon, 7 Aug 2017 01:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDHq5ZSnYiSu for ; Mon, 7 Aug 2017 01:56:41 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E918D132193 for ; Mon, 7 Aug 2017 01:56:40 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1dedq0-001gPY-SC; Mon, 07 Aug 2017 10:56:37 +0200 Date: Mon, 7 Aug 2017 10:56:36 +0200 From: David Lamparter To: "Acee Lindem (acee)" Cc: Matthieu Boutier , David Lamparter , "rtgwg@ietf.org" , Anton Smirnov Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Message-ID: <20170807085636.GS773745@eidolon> References: <20170719172913.GU773745@eidolon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 08:56:42 -0000 On Wed, Jul 26, 2017 at 12:16:17AM +0000, Acee Lindem (acee) wrote: > I must admit that I had always thought that the source-routing paradigm in > draft-troan-homenet-sadr-01.txt was backward with the destination address > Longest Prefix Match (LPM) being done prior to the source address lookup. > Rather I think if were going to standardize in the RTG WG, it should be > the FIB organization described in section 3 of > draft-ietf-rtgwg-enterprise-pa-multihoming-01.txt. Note that doing the > source address lookup first maps directly to the PA multi-homing > use-case. I see both a misunderstanding and an internal contradiction here. The misunderstanding is that enterprise-pa-multihoming is describing source-first RIB or protocol behaviour. It isn't - it's describing a destination-first RIB and a source-first FIB translation. Conversely, rtgwg-dst-src-routing isn't specifying a dst-first FIB, see below. This is also where this contradicts itself; the PA multi-homing use-case does *not* map to source-first. If it did, you wouldn't need the route duplication. In fact, the PA multihoming case -- just like homenet -- needs destination-first to get local connectivity up and running. Also, and very importantly, I really don't want to go around telling people how to run their FIBs. It doesn't matter, as long as they're forwarding packets in a manner confirming to the spec. This is also why I've moved A.1 and A.2 into the appendix on the -05 rev of the draft; I felt these suggestions on how to efficiently operate this on a source-first (A.2) or destination-first (A.1) FIB are most appropriate in an appendix. On Wed, Jul 26, 2017 at 08:52:53PM +0000, Acee Lindem (acee) wrote: > I believe the tables could be similarly collapsed giving source address > higher precedence than destination address. Do you disagree? They can be, this is described in appendix A.2. of dst-src-routing-05. This does result in more duplicated routes than the other way around, but it's a perfectly viable implementation choice. That said, it makes no sense to use this in routing protocol signaling, or even the RIB. This is a FIB implementation detail. For protocol and RIB operation, destination-first-with-fallthrough provides the semantics that make the most sense to describe a network and get it up and running -- even if all of the routers have source-first FIBs and perform this translation step on installing a route. Cheers, -David From nobody Mon Aug 7 02:04:11 2017 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 33F40127601 for ; Mon, 7 Aug 2017 02:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hueDkmXkMvxE for ; Mon, 7 Aug 2017 02:04:08 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB925132452 for ; Mon, 7 Aug 2017 02:04:08 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1dedxF-001gXD-Ov; Mon, 07 Aug 2017 11:04:06 +0200 Date: Mon, 7 Aug 2017 11:04:05 +0200 From: David Lamparter To: Matthieu Boutier Cc: Chris Bowers , David Lamparter , "rtgwg@ietf.org" , Anton Smirnov , Jen Linkova Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Message-ID: <20170807090405.GT773745@eidolon> References: <20170719172913.GU773745@eidolon> <20170720074132.GW773745@eidolon> <9BF40E52-63D7-4B04-815A-64F863241010@irif.fr> <489E14E1-04F2-45A4-A85D-A0B132740BE0@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <489E14E1-04F2-45A4-A85D-A0B132740BE0@irif.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:04:10 -0000 On Fri, Jul 28, 2017 at 02:42:59PM +0200, Matthieu Boutier wrote: [snip] > Perhaps having something like the following(?): > > 3. Forwarding tables representations > 3.1. Source Address Dependant Forwarding tables > -> this is just a dump of the announces > 3.2. Source-Prefix-Scoped Forwarding Tables > -> using "Generating Source-Prefix-Scoped Forwarding Tables v2" > 3.3. Examples It's already there: if you look at -04 of the draft, your 3.1 is 3.1, and your 3.2 is 3.4 ;) In the -05 version I've moved this to the new appendix A. Note as mentioned in my reply to Fred, we actually have 3 cases here: - "d-s-ft" destination-first with fallthrough / backtracking - "d-s" destination-first - "s-d" source-first The way the draft is outlined uses "d-s-ft" to specify expected behaviour and has A.1 / A.2 describing translations to "d-s" & "s-d". -David - From nobody Mon Aug 7 02:12:19 2017 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 98079127601 for ; Mon, 7 Aug 2017 02:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KQM-cSOnvzE for ; Mon, 7 Aug 2017 02:12:15 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F237131C96 for ; Mon, 7 Aug 2017 02:12:15 -0700 (PDT) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id v779C6AS017888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Aug 2017 11:12:06 +0200 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id v779C5nw030705; Mon, 7 Aug 2017 11:12:05 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id AABFCEB36A; Mon, 7 Aug 2017 11:12:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id fmyPi0suH2Gx; Mon, 7 Aug 2017 11:12:04 +0200 (CEST) Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 10303EB342; Mon, 7 Aug 2017 11:12:03 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing From: Matthieu Boutier In-Reply-To: <20170807090405.GT773745@eidolon> Date: Mon, 7 Aug 2017 11:12:02 +0200 Cc: Chris Bowers , "rtgwg@ietf.org" , Anton Smirnov , Jen Linkova Content-Transfer-Encoding: 7bit Message-Id: <1734FEDE-636A-447A-ACE4-527D9FCB481D@irif.fr> References: <20170719172913.GU773745@eidolon> <20170720074132.GW773745@eidolon> <9BF40E52-63D7-4B04-815A-64F863241010@irif.fr> <489E14E1-04F2-45A4-A85D-A0B132740BE0@irif.fr> <20170807090405.GT773745@eidolon> To: David Lamparter X-Mailer: Apple Mail (2.3124) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 07 Aug 2017 11:12:06 +0200 (CEST) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 07 Aug 2017 11:12:06 +0200 (CEST) X-Miltered: at korolev with ID 59882EE6.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 59882EE5.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 59882EE6.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 59882EE5.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 59882EE6.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 59882EE5.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:12:18 -0000 Hi David, > It's already there I was speaking about rtgwg-enterprise-pa-multihoming. ;-) Thanks by the way for your explanations in your two previous mails. I think this really helps us understand each other. Cheers, Matthieu From nobody Mon Aug 7 02:14:06 2017 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 94D3E131EC3 for ; Mon, 7 Aug 2017 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=g3ysx-org-uk.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQpTPONaQl6X for ; Mon, 7 Aug 2017 02:14:02 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D7F131DAC for ; Mon, 7 Aug 2017 02:14:01 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m85so2168537wma.0 for ; Mon, 07 Aug 2017 02:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=g3ysx-org-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=s8hLD+nAzLNCqGBy/c9efBUT0yKEAYbQoHdleqrB6SE=; b=A6oFx5JCfldvPLWg5tuMfXyPzT2ssGoUaF8BL60fL/f7XlZ/8NnVF04vLIx5tJnHEb rHKpMYQKTDMGqBQklYQ5eO9dndXSUZzgwQCvUP9uQhSvcjFd+7ORARry5kttmbv1b3Gx j296jxQUi35UzjtYw3nvYAmYyQ4CZT2APn2i0FDnMX3w8zTtanmynrFLqYtFQzsD0+QN 5HwyoBreTCq9a8w9aOVCwdSg5/5oZN1e65PpOKSHp8f61nxN7dYhij7+Ft+amMwIbbUs KteEg7Ht6EQeM1Cc+8Ve4lcT+nHQ4LfNC0WRrRFDKmJESTdhCBkFHtE474ANDaxcfBTx 4RHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=s8hLD+nAzLNCqGBy/c9efBUT0yKEAYbQoHdleqrB6SE=; b=Uhua9Z2q9wsKbmEC68/eHA/m7yfKXTdB6puOJskI+C0Jkwkwf+fWC1Q8xI5DODijvK JAwjkKvYQiBCzEGbHfK6F3lAANkS0lCQF5tvezIV/kfAt5FEphV+xCRhiZXLkoTY+c5g TA/wDm97htaA4zqo7irIx07oQHjJYf16M780v/L/39vIPMAFdi77bLFrqpPrAK4oKapF eO/mGmn+CtlDS4fORRai7FmA2g3O0mf8c3Ky1aYgjaXv6/EU3vNcqcAW1T9oopVhxPKc pu6IICL5OcSwVjsA0P6X3Y5fuRrzj/tnkE74DV5neUcORDb9ZMvVGdD9JqB0BbfXLL7M 2TCw== X-Gm-Message-State: AHYfb5jWLKkG2s99XOw23w3SRPQyLqotdniLo1mxaZ63qHsdp7PIXyeJ ZGdL4LQNnfoy1dzb X-Received: by 10.28.23.195 with SMTP id 186mr180214wmx.173.1502097240383; Mon, 07 Aug 2017 02:14:00 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 9sm11591600wmo.35.2017.08.07.02.13.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 02:13:59 -0700 (PDT) Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt To: Sikhivahan Gundu , "Ahmed Bashandy (bashandy)" , "rtgwg@ietf.org" Cc: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> From: Stewart Bryant Message-ID: Date: Mon, 7 Aug 2017 10:13:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E64E9A60D8F1B961938D1112" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:14:05 -0000 This is a multi-part message in MIME format. --------------E64E9A60D8F1B961938D1112 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 07/08/2017 06:45, Sikhivahan Gundu wrote: > > By “ambiguity”, I meant that backup calculation taking SRLG into > > account is based on speculated topology, whereas computation of > > post-convergence path, ie, SPF, is based on actual topology. This > > seems needs reconciling since in TI-LFA the backup is by definition > > the post-convergence path, with a single path-transition after > > link-failure as the intended outcome. Do I understand correctly that > > the draft prefers to relax that expectation for SRLG? > > Yes, that is a good point, in the event of an incomplete failure of an SRLG, there may not be congruence between the FRR path and the post convergence path. This certainly needs further study. * A--------//---------B | | | * | cost 2 C-------------------D | | | | cost 100 E-------------------F AB + CD in same SRLG TiLFA path is ACEFDB Post convergence path is ACDB In this case I think that the impact is just more SR hops in the repair path than might be needed without the SRLG, but we do need to be sure that there are no pathological cases in topologies that lack the proposed congruence, and as Sikhivahan notes this effect does need to be clarified in the text. - Stewart --------------E64E9A60D8F1B961938D1112 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 



Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 
 --------------E64E9A60D8F1B961938D1112-- From nobody Mon Aug 7 02:25:01 2017 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 12F2A13218F for ; Mon, 7 Aug 2017 02:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa4PghVT9RTl for ; Mon, 7 Aug 2017 02:24:58 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C95131EC3 for ; Mon, 7 Aug 2017 02:24:58 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1deeHN-001gpd-TU; Mon, 07 Aug 2017 11:24:54 +0200 Date: Mon, 7 Aug 2017 11:24:53 +0200 From: David Lamparter To: Matthieu Boutier Cc: David Lamparter , Chris Bowers , "rtgwg@ietf.org" , Anton Smirnov , Jen Linkova Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Message-ID: <20170807092453.GU773745@eidolon> References: <20170719172913.GU773745@eidolon> <20170720074132.GW773745@eidolon> <9BF40E52-63D7-4B04-815A-64F863241010@irif.fr> <489E14E1-04F2-45A4-A85D-A0B132740BE0@irif.fr> <20170807090405.GT773745@eidolon> <1734FEDE-636A-447A-ACE4-527D9FCB481D@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1734FEDE-636A-447A-ACE4-527D9FCB481D@irif.fr> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:25:00 -0000 On Mon, Aug 07, 2017 at 11:12:02AM +0200, Matthieu Boutier wrote: > Hi David, > > > It's already there > > I was speaking about rtgwg-enterprise-pa-multihoming. ;-) Oh, sorry, I jumped over because the section numbers were so similar ;-D -David > Thanks by the way for your explanations in your two previous > mails. I think this really helps us understand each other. > > Cheers, > Matthieu > From nobody Mon Aug 7 02:27:40 2017 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 C5B17132194 for ; Mon, 7 Aug 2017 02:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9qsHbTVFUGX for ; Mon, 7 Aug 2017 02:27:37 -0700 (PDT) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119C613218F for ; Mon, 7 Aug 2017 02:27:37 -0700 (PDT) Received: from equinox by eidolon.nox.tf with local (Exim 4.89) (envelope-from ) id 1deeJx-001gzo-L2; Mon, 07 Aug 2017 11:27:34 +0200 Date: Mon, 7 Aug 2017 11:27:33 +0200 From: David Lamparter To: Chris Bowers Cc: Matthieu Boutier , David Lamparter , "rtgwg@ietf.org" , Anton Smirnov , Jen Linkova Subject: Re: Persistent loops when mixing rtgwg-enterprise-pa-multihoming and rtgwg-dst-src-routing Message-ID: <20170807092733.GV773745@eidolon> References: <20170719172913.GU773745@eidolon> <20170720074132.GW773745@eidolon> <9BF40E52-63D7-4B04-815A-64F863241010@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 09:27:39 -0000 On Thu, Jul 27, 2017 at 05:55:01PM +0000, Chris Bowers wrote: > With the proposed generalization of rule #3, together with a clarification that the source-prefix-scoped > forwarding table should be chosen based on longest source prefix match with the source address of the packet, > I think we are in agreement that the forwarding behavior described in rtgwg-enterprise-pa-multihoming > Is identical to that described in rtgwg-dst-src-routing. > > If anyone thinks that the forwarding behaviors (after the proposed generalization and clarification in > rtgwg-enterprise-pa-multihoming) are different, please speak up and provide an example. Indeed this fixes pa-multihoming's section 3 to correspond to dst-src-routing's section A.2. > Assuming that the forwarding behaviors are identical, we can now ask the question: Is it useful to have > two different representations of the same forwarding behavior? I think it is. Sure, it's a cool feature to be able to show different perspectives of the same RIB. The same, it's nice to be able to install this into a FIB that is organised in a different way in silicon. However, we need a non-ambiguous specification for the RIB (and in extension the routing protocols). I've had conversations at IETF99 that consider using BGP to signal an application service provider's service into an enterprise IS-IS domain. To make this entire topic work without huge kludges, we need an uniform understanding of what a (D,S) route in the RIB means. I think the pa-multihoming draft is actively counterproductive to this. It doesn't even specify what a (D,S) route means to begin with, it heads straight for installation instructions for a source-first RIB. It makes no mention that these generated tables aren't what the routing protocol would advertise; it lacks all of the larger interaction considerations that are in dst-src-routing sections 4 and 5. Basically, I can use pa-multihoming to put together a script for my DHCP client that makes the appropriate calls to update some static routes and policies in an enterprise network. dst-src-routing tries to properly describe the foundation of an useful dst-src routing system. (And it doesn't do so in an arbitrarily limited scope to set off in.) That said, I will go through the dst-src-routing draft to edit to make more clear that it is a behavioural specification with (at least) 3 implementation possibilities. The mails I've been sending today have made perfectly clear to me that this is not at all obvious from the draft - it should be. My bad. > It is not the case that "All the section 3 is about what to do if we don't have native destination-first SADR > tables but only policy routing." If the two representations produce the same forwarding behavior, then one > should be free to implement using either representation. Yep, either of the 3 representations, one of which is described in pa-multihoming, and all 3 of which are in dst-src-routing ;) (*SCNR*) > I think that enterprise network operators are going to have a very difficult time understanding > destination-first SADR forwarding tables. Instead, operators are very familiar with simple > destination-based forwarding tables. I think that operators will find it much easier to understand and > troubleshoot when this forwarding behavior is represented using a set of source-prefix-scoped > destination-based forwarding tables. > > When routing protocols are working properly, it shouldn't matter. But when packets are not going where the > network operator wants them to, they are going to want to be able to troubleshoot this by looking at the > forwarding tables. Absolutely, as long as we're in agreement on what specifically a (D,S) route in the RIB means. We seem to have consensus that this is destination-first with fallthrough, as that's now what both drafts are describing. Cheers, -David From nobody Mon Aug 7 11:23:17 2017 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 C7E06132369; Mon, 7 Aug 2017 11:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtGDF90jHF_e; Mon, 7 Aug 2017 11:23:12 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901B9132461; Mon, 7 Aug 2017 11:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31808; q=dns/txt; s=iport; t=1502130192; x=1503339792; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2HUrg7CB16W7qxvqtlA5/7/xPO3gsH74B8BpwJNR7bY=; b=I4bo9NjyiuqWT1VJsN2Evsrot6Rx2fxSPSPfArxO1Jj6qrqElXTDo4+3 oGePqGVLknaa6P4MCAxl9pcu/su0VWXiLfgbdx0fUPjX86Tt8eJufd6F9 5bIowaay++lRKtXbGb/rYcdsSm/4Ny+fYLYc8YzhciYa5c/bNaMOvW+IS 4=; X-IronPort-AV: E=Sophos;i="5.41,339,1498521600"; d="scan'208,217";a="468046260" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2017 18:23:11 +0000 Received: from [10.154.131.17] ([10.154.131.17]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v77INB6p001710; Mon, 7 Aug 2017 18:23:11 GMT Message-ID: <5988B00F.8060702@cisco.com> Date: Mon, 07 Aug 2017 11:23:11 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Sikhivahan Gundu , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" , Stewart Bryant Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050109040402060001090103" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:23:16 -0000 This is a multi-part message in MIME format. --------------050109040402060001090103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am not aware of such thing as "speculative, ambiguous, probabilistic, stocastic,..., etc" SRLG. SRLG is one member fails, all members fail. I presumed that this is understood from the many responses and discussions that we had. However I will explicitly define the term "SRLG" in the draft Thanks Ahmed On 8/6/2017 10:45 PM, Sikhivahan Gundu wrote: > > Hi, > > Thanks for your response. > > >> - Hence if the primary link fails, only "L1" will fail and L2 will not > > L1 _/may/_ fail, with high probability, but it may also not fail. If > it does > > not fail, there is a second transitioning of the post-primary-failure > > link from FRR-backup (L2) to post-convergence link (L1), because L1 > > has a smaller metric. > > By "ambiguity", I meant that backup calculation taking SRLG into > > account is based on speculated topology, whereas computation of > > post-convergence path, ie, SPF, is based on actual topology. This > > seems needs reconciling since in TI-LFA the backup is by definition > > the post-convergence path, with a single path-transition after > > link-failure as the intended outcome. Do I understand correctly that > > the draft prefers to relax that expectation for SRLG? > > Thanks, > > Sikhi > > *From:*Ahmed Bashandy (bashandy) [mailto:bashandy@cisco.com] > *Sent:* 05 August 2017 01:19 > *To:* Sikhivahan Gundu ; rtgwg@ietf.org > *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant > > *Subject:* Re: I-D Action: > draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > HI, > > All members of the same SRLG group are assumed to fail if one of them > fails. > > Going back to you example > - L1 is in the same SRLG group as the primary link while L2 is belongs > a different group > - Hence if the primary link fails, only "L1" will fail and L2 will not > - Hence only L2 is candidate to become a backup path while L1 is not > - Hence there is no ambiguity > > Thanks > > Ahmed > > On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote: > > Hi, > > The draft mandates using "post-convergence path" as the backup path. > > It states one advantage, among others, of doing so as follows: > > "This .. helps to reduce the amount of path changes and hence service > > transients: one transition (pre-convergence to post-convergence) > instead > > of two (pre-convergence to FRR and then post-convergence)". > > This suggests to me that the assumption here is that the > post-convergence > > path can be uniquely determined in advance. > > However, SRLG introduces ambiguity. To illustrate the point, let > us say a > > loop-free alternative has two options: one link (L1) is of the > same metric > > value as the primary link and is also in the same SRLG as the > primary; the > > second option (L2) is in a different SRLG and has higher metric. > > The actual post-convergence path would depend on whether or not L1 > > also failed along with the primary, so is not uniquely computed in > advance. > > If TI-LFA picks L1, there might not be a guaranteed backup. If it > picks L2, > > there'd be two link transitions because L2 would not be in a > (strict) SPF- > > computed post-convergence path. A third option, of course, is to > give up > > declaring that there is no TI-LFA backup, but it'd be preferable > to have > > some backup than have none at all. > > What do the authors suggest for this situation? > > Thanks, > > Sikhi > > > > *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Ahmed > Bashandy (bashandy) > *Sent:* 17 July 2017 12:56 > *To:* rtgwg@ietf.org > *Cc:* rtgwg-chairs@ietf.org ; > pfrpfr@gmail.com ; Stewart Bryant > > *Subject:* Fwd: I-D Action: > draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > Hi, > > A new version of the ti-lfa draft has been posted to address > Stewart Bryant's comments > > Thanks > > Ahmed > > > -------- Original Message -------- > > *Subject: * > > > > I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > *Date: * > > > > Mon, 17 Jul 2017 00:19:37 -0700 > > *From: * > > > > internet-drafts@ietf.org > > *Reply-To: * > > > > internet-drafts@ietf.org > > *To: * > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Topology Independent Fast Reroute using Segment Routing > > Authors : Ahmed Bashandy > > Clarence Filsfils > > Bruno Decraene > > Stephane Litkowski > > Pierre Francois > > Filename : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > Pages : 12 > > Date : 2017-07-17 > > > > Abstract: > > This document presents Topology Independent Loop-free Alternate Fast > > Re-route (TI-LFA), aimed at providing protection of node and > > adjacency segments within the Segment Routing (SR) framework. This > > Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being > > LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding > > (DLFA). It extends these concepts to provide guaranteed coverage in > > any IGP network. A key aspect of TI-LFA is the FRR path selection > > approach establishing protection over post-convergence paths from > > the point of local repair, dramatically reducing the operational > > need to control the tie-breaks among various FRR options. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > > https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > 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 > > orftp://ftp.ietf.org/ietf/1shadow-sites.txt > --------------050109040402060001090103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am not aware of such thing as "speculative, ambiguous, probabilistic, stocastic,..., etc" SRLG.

SRLG is one member fails, all members fail. I presumed that this is understood from the many responses and discussions that we had. However I will explicitly define the term "SRLG" in the draft

Thanks

Ahmed

On 8/6/2017 10:45 PM, Sikhivahan Gundu wrote:

Hi,

 

Thanks for your response.

 

>> - Hence if the primary link fails, only "L1" will fail and L2 will not

 

L1 _may_ fail, with high probability, but it may also not fail. If it does

not fail, there is a second transitioning of the post-primary-failure

link from FRR-backup (L2) to post-convergence link (L1), because L1

has a smaller metric.

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 

Thanks,

Sikhi

 

 

From: Ahmed Bashandy (bashandy) [mailto:bashandy@cisco.com]
Sent: 05 August 2017 01:19
To: Sikhivahan Gundu <sikhivahan.gundu@ericsson.com>; rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

HI,

All members of the same SRLG group are assumed to fail if one of them fails.

Going back to you example
- L1 is in the same SRLG group as the primary link while L2 is belongs a different group
- Hence if the primary link fails, only "L1" will fail and L2 will not
- Hence only L2 is candidate to become a backup path while L1 is not
- Hence there is no ambiguity

Thanks

Ahmed

On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote:

Hi,

 

The draft mandates using “post-convergence path” as the backup path. 

It states one advantage, among others, of doing so as follows:

 

“This .. helps to reduce the amount of path changes and hence service

transients: one transition (pre-convergence to post-convergence) instead

of two (pre-convergence to FRR and then post-convergence)”.

 

This suggests to me that the assumption here is that the post-convergence

path can be uniquely determined in advance.

 

However, SRLG introduces ambiguity. To illustrate the point,  let us say a

loop-free alternative has two options: one  link (L1) is of the same metric

value as the primary link and is also in the same SRLG as the primary; the

second option (L2) is in a different SRLG and has higher metric.

 

The actual post-convergence path would depend on whether or not L1

also failed along with the primary, so is not uniquely computed in advance.

If TI-LFA picks L1, there might not be a guaranteed backup. If it picks L2,

there’d be two link transitions because L2 would not be in a (strict) SPF-

computed post-convergence path. A third option, of course, is to give up

declaring that there is no TI-LFA backup, but it’d be preferable to have

some backup than have none at all.

 

What do the authors suggest for this situation?

 

Thanks,

Sikhi

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Hi,

A new version of the ti-lfa draft has been posted to address Stewart Bryant's comments

Thanks

Ahmed


-------- Original Message --------

Subject:

I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

Date:

Mon, 17 Jul 2017 00:19:37 -0700

From:

internet-drafts@ietf.org

Reply-To:

internet-drafts@ietf.org

To:

<i-d-announce@ietf.org>

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
 
        Title           : Topology Independent Fast Reroute using Segment Routing
        Authors         : Ahmed Bashandy
                          Clarence Filsfils
                          Bruno Decraene
                          Stephane Litkowski
                          Pierre Francois
        Filename        : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
        Pages           : 12
        Date            : 2017-07-17
 
Abstract:
   This document presents Topology Independent Loop-free Alternate Fast
   Re-route (TI-LFA), aimed at providing protection of node and
   adjacency segments within the Segment Routing (SR) framework.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
   (DLFA).  It extends these concepts to provide guaranteed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR path selection
   approach establishing protection over post-convergence paths from
   the point of local repair, dramatically reducing the operational
   need to control the tie-breaks among various FRR options.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
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

 

 

 


--------------050109040402060001090103-- From nobody Mon Aug 7 11:23:51 2017 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 C6DB5132373; Mon, 7 Aug 2017 11:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKQ4LF4D2Ggo; Mon, 7 Aug 2017 11:23:48 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE4113240F; Mon, 7 Aug 2017 11:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8722; q=dns/txt; s=iport; t=1502130225; x=1503339825; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8ta5T/vr9jU9iOrOdxfRSVyI1KYxCzv2+ZtwLg5qGxs=; b=b/qDxzKSZdmLKBVRM157ezJC/ynqTPDAh/PATPUlWx34fmZXyQZNrf/w 5ZtjLooavjvnHHsYdYgRYKrnQlYcB1EPaX3ypKqWlqACPOnRPOvkmkSTt mBCSIyrC2+OtHlZcK83fFaOhbSCDvL+9fxzOqZEMtFq0Gp5l5UAg6WjrK c=; X-IronPort-AV: E=Sophos;i="5.41,339,1498521600"; d="scan'208,217";a="282746873" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Aug 2017 18:23:44 +0000 Received: from [10.154.131.17] ([10.154.131.17]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v77INiKo012687; Mon, 7 Aug 2017 18:23:44 GMT Message-ID: <5988B030.8080001@cisco.com> Date: Mon, 07 Aug 2017 11:23:44 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stewart Bryant , Sikhivahan Gundu , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000701020008060802000902" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 18:23:50 -0000 This is a multi-part message in MIME format. --------------000701020008060802000902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit See my reply to Sikhi Thanks Ahmed On 8/7/2017 2:13 AM, Stewart Bryant wrote: > > > > On 07/08/2017 06:45, Sikhivahan Gundu wrote: >> >> By “ambiguity”, I meant that backup calculation taking SRLG into >> >> account is based on speculated topology, whereas computation of >> >> post-convergence path, ie, SPF, is based on actual topology. This >> >> seems needs reconciling since in TI-LFA the backup is by definition >> >> the post-convergence path, with a single path-transition after >> >> link-failure as the intended outcome. Do I understand correctly that >> >> the draft prefers to relax that expectation for SRLG? >> >> > > Yes, that is a good point, in the event of an incomplete failure > of an SRLG, there may not be congruence between the > FRR path and the post convergence path. This certainly > needs further study. > > * > A--------//---------B > | | > | * | cost 2 > C-------------------D > | | > | | cost 100 > E-------------------F > > > AB + CD in same SRLG > > TiLFA path is ACEFDB > > Post convergence path is ACDB > > In this case I think that the impact is just more SR hops in the > repair path than might be needed without the SRLG, but we do need to > be sure that there are no pathological cases in > topologies that lack the proposed congruence, and as > Sikhivahan notes this effect does need to be clarified in the > text. > > - Stewart > > > > --------------000701020008060802000902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit See my reply to Sikhi

Thanks

Ahmed


On 8/7/2017 2:13 AM, Stewart Bryant wrote:



On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 



Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 

--------------000701020008060802000902-- From nobody Mon Aug 7 12:47:25 2017 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 70E9612EC13 for ; Mon, 7 Aug 2017 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fye-Cp1C5bn5 for ; Mon, 7 Aug 2017 12:47:14 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2BF13251F for ; Mon, 7 Aug 2017 12:47:12 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 33so5353969wrz.4 for ; Mon, 07 Aug 2017 12:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=yKZKqbkRN0kjVtQ6O13CsVPnp514mMbvYJ7vRcdHf14=; b=mkHQgLpyCjmcSfCKnt22Om0gR6zyTC1MWH1K/4gMIB+cXWAnhTIUPgh7zVmZXikAKB bgffl/1tGfVLhIuv/I1g/b20U+y4VZxTE28Cj8JfZAK7F4lFh3rzu5JdZxE7yBdl6mEf RhEPytUlc6p80gHN9Q1MUkuA9ptGIdZrQCCrZDZJOy79NgClhdM9SFC9X/Pov2J83o4g PiRioMil4+izOgvTYiufPDaudQD4rFfMuMkQdw7eKyPBZ4MO91BGaPrdMdjEWpLwevgW QJQpAPw4F1yxD1YaiQ13OdeY6cge1uO5Cz9zaBjWgcxH2gHTLcZpoJLBXWcXtE8BCDVA iDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yKZKqbkRN0kjVtQ6O13CsVPnp514mMbvYJ7vRcdHf14=; b=DM8WHMirUsZ5ZyVya8X/NaJdPOGkH3NSCT7wg9XYCZgBhpi3UlY926aRw3OxyZxO52 WePu8wBy/2XhBtElvg55NuwH52L3sfj5sXD98P+Y36daVbXB7ylMNBmWAHWuxvve6TQ6 RuIST3fLLt1/XHyPo9v02H9Gr9Rm62AqM5TsJrUxN5z6HgsC8fMozxNt6wVWm924AD5G aSfeBF8I1P3/4IVCVJDtv7lZ+8QHFTAfwLsMKiKDvBkvGnAzoiaaQGU04xHfQtKkXGYS ROohG2abp5PWW0QCyMvXnbJgzo5Gbljfdfff8gXv/aQrTTTVg0GXCAfPAbswRapqZDFn XCQA== X-Gm-Message-State: AHYfb5jl2CD0Oby2fz3DrJkTOlTa8W+4YnNTSoGWe6TJv6QwlquQxU2n Uh5sEgAgjFa5sgh4FBg= X-Received: by 10.223.139.23 with SMTP id n23mr1137146wra.249.1502135230411; Mon, 07 Aug 2017 12:47:10 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id d19sm9094103wrb.93.2017.08.07.12.47.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 12:47:09 -0700 (PDT) Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt To: "Ahmed Bashandy (bashandy)" References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B00F.8060702@cisco.com> Cc: "rtgwg@ietf.org" From: Stewart Bryant Message-ID: <927e8a8c-12ac-92d8-2fd7-e8b94b0f08b6@gmail.com> Date: Mon, 7 Aug 2017 20:47:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5988B00F.8060702@cisco.com> Content-Type: multipart/alternative; boundary="------------05FA068FA5022A2AB143DD9E" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 19:47:24 -0000 This is a multi-part message in MIME format. --------------05FA068FA5022A2AB143DD9E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: > I am not aware of such thing as "speculative, ambiguous, > probabilistic, stocastic,..., etc" SRLG. > > SRLG is one member fails, all members fail. I presumed that this is > understood from the many responses and discussions that we had. > However I will explicitly define the term "SRLG" in the draft No. SRLG is where when one member fails you treat as if all members have failed. Routing then works out what actually happened. - Stewart > > Thanks > > Ahmed > > On 8/6/2017 10:45 PM, Sikhivahan Gundu wrote: >> >> Hi, >> >> Thanks for your response. >> >> >> - Hence if the primary link fails, only "L1" will fail and L2 will not >> >> L1 _/may/_ fail, with high probability, but it may also not fail. If >> it does >> >> not fail, there is a second transitioning of the post-primary-failure >> >> link from FRR-backup (L2) to post-convergence link (L1), because L1 >> >> has a smaller metric. >> >> By “ambiguity”, I meant that backup calculation taking SRLG into >> >> account is based on speculated topology, whereas computation of >> >> post-convergence path, ie, SPF, is based on actual topology. This >> >> seems needs reconciling since in TI-LFA the backup is by definition >> >> the post-convergence path, with a single path-transition after >> >> link-failure as the intended outcome. Do I understand correctly that >> >> the draft prefers to relax that expectation for SRLG? >> >> Thanks, >> >> Sikhi >> >> *From:*Ahmed Bashandy (bashandy) [mailto:bashandy@cisco.com] >> *Sent:* 05 August 2017 01:19 >> *To:* Sikhivahan Gundu ; rtgwg@ietf.org >> *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant >> >> *Subject:* Re: I-D Action: >> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >> >> HI, >> >> All members of the same SRLG group are assumed to fail if one of them >> fails. >> >> Going back to you example >> - L1 is in the same SRLG group as the primary link while L2 is >> belongs a different group >> - Hence if the primary link fails, only "L1" will fail and L2 will not >> - Hence only L2 is candidate to become a backup path while L1 is not >> - Hence there is no ambiguity >> >> Thanks >> >> Ahmed >> >> On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote: >> >> Hi, >> >> The draft mandates using “post-convergence path” as the backup path. >> >> It states one advantage, among others, of doing so as follows: >> >> “This .. helps to reduce the amount of path changes and hence >> service >> >> transients: one transition (pre-convergence to post-convergence) >> instead >> >> of two (pre-convergence to FRR and then post-convergence)”. >> >> This suggests to me that the assumption here is that the >> post-convergence >> >> path can be uniquely determined in advance. >> >> However, SRLG introduces ambiguity. To illustrate the point, let >> us say a >> >> loop-free alternative has two options: one link (L1) is of the >> same metric >> >> value as the primary link and is also in the same SRLG as the >> primary; the >> >> second option (L2) is in a different SRLG and has higher metric. >> >> The actual post-convergence path would depend on whether or not L1 >> >> also failed along with the primary, so is not uniquely computed >> in advance. >> >> If TI-LFA picks L1, there might not be a guaranteed backup. If it >> picks L2, >> >> there’d be two link transitions because L2 would not be in a >> (strict) SPF- >> >> computed post-convergence path. A third option, of course, is to >> give up >> >> declaring that there is no TI-LFA backup, but it’d be preferable >> to have >> >> some backup than have none at all. >> >> What do the authors suggest for this situation? >> >> Thanks, >> >> Sikhi >> >> *From:*rtgwg [mailto:rtgwg-bounces@ietf.org] *On Behalf Of *Ahmed >> Bashandy (bashandy) >> *Sent:* 17 July 2017 12:56 >> *To:* rtgwg@ietf.org >> *Cc:* rtgwg-chairs@ietf.org ; >> pfrpfr@gmail.com ; Stewart Bryant >> >> *Subject:* Fwd: I-D Action: >> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >> >> Hi, >> >> A new version of the ti-lfa draft has been posted to address >> Stewart Bryant's comments >> >> Thanks >> >> Ahmed >> >> >> -------- Original Message -------- >> >> *Subject: * >> >> >> >> I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >> >> *Date: * >> >> >> >> Mon, 17 Jul 2017 00:19:37 -0700 >> >> *From: * >> >> >> >> internet-drafts@ietf.org >> >> *Reply-To: * >> >> >> >> internet-drafts@ietf.org >> >> *To: * >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> >> >> >> Title : Topology Independent Fast Reroute using Segment Routing >> >> Authors : Ahmed Bashandy >> >> Clarence Filsfils >> >> Bruno Decraene >> >> Stephane Litkowski >> >> Pierre Francois >> >> Filename : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >> >> Pages : 12 >> >> Date : 2017-07-17 >> >> >> >> Abstract: >> >> This document presents Topology Independent Loop-free Alternate Fast >> >> Re-route (TI-LFA), aimed at providing protection of node and >> >> adjacency segments within the Segment Routing (SR) framework. This >> >> Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being >> >> LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding >> >> (DLFA). It extends these concepts to provide guaranteed coverage in >> >> any IGP network. A key aspect of TI-LFA is the FRR path selection >> >> approach establishing protection over post-convergence paths from >> >> the point of local repair, dramatically reducing the operational >> >> need to control the tie-breaks among various FRR options. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/ >> >> >> >> There are also htmlized versions available at: >> >> https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 >> >> https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01 >> >> >> >> A diff from the previous version is available at: >> >> https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01 >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> >> until the htmlized version and diff are available at tools.ietf.org. >> >> >> >> 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 >> >> orftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------05FA068FA5022A2AB143DD9E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:
I am not aware of such thing as "speculative, ambiguous, probabilistic, stocastic,..., etc" SRLG.

SRLG is one member fails, all members fail. I presumed that this is understood from the many responses and discussions that we had. However I will explicitly define the term "SRLG" in the draft

No. SRLG is where when one member fails you treat as if all members have failed. Routing then works out what actually happened.

- Stewart


Thanks

Ahmed

On 8/6/2017 10:45 PM, Sikhivahan Gundu wrote:

Hi,

 

Thanks for your response.

 

>> - Hence if the primary link fails, only "L1" will fail and L2 will not

 

L1 _may_ fail, with high probability, but it may also not fail. If it does

not fail, there is a second transitioning of the post-primary-failure

link from FRR-backup (L2) to post-convergence link (L1), because L1

has a smaller metric.

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 

Thanks,

Sikhi

 

 

From: Ahmed Bashandy (bashandy) [mailto:bashandy@cisco.com]
Sent: 05 August 2017 01:19
To: Sikhivahan Gundu <sikhivahan.gundu@ericsson.com>; rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

HI,

All members of the same SRLG group are assumed to fail if one of them fails.

Going back to you example
- L1 is in the same SRLG group as the primary link while L2 is belongs a different group
- Hence if the primary link fails, only "L1" will fail and L2 will not
- Hence only L2 is candidate to become a backup path while L1 is not
- Hence there is no ambiguity

Thanks

Ahmed

On 8/1/2017 12:42 AM, Sikhivahan Gundu wrote:

Hi,

 

The draft mandates using “post-convergence path” as the backup path. 

It states one advantage, among others, of doing so as follows:

 

“This .. helps to reduce the amount of path changes and hence service

transients: one transition (pre-convergence to post-convergence) instead

of two (pre-convergence to FRR and then post-convergence)”.

 

This suggests to me that the assumption here is that the post-convergence

path can be uniquely determined in advance.

 

However, SRLG introduces ambiguity. To illustrate the point,  let us say a

loop-free alternative has two options: one  link (L1) is of the same metric

value as the primary link and is also in the same SRLG as the primary; the

second option (L2) is in a different SRLG and has higher metric.

 

The actual post-convergence path would depend on whether or not L1

also failed along with the primary, so is not uniquely computed in advance.

If TI-LFA picks L1, there might not be a guaranteed backup. If it picks L2,

there’d be two link transitions because L2 would not be in a (strict) SPF-

computed post-convergence path. A third option, of course, is to give up

declaring that there is no TI-LFA backup, but it’d be preferable to have

some backup than have none at all.

 

What do the authors suggest for this situation?

 

Thanks,

Sikhi

 

 

From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Ahmed Bashandy (bashandy)
Sent: 17 July 2017 12:56
To: rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com; Stewart Bryant <stewart@g3ysx.org.uk>
Subject: Fwd: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Hi,

A new version of the ti-lfa draft has been posted to address Stewart Bryant's comments

Thanks

Ahmed


-------- Original Message --------

Subject:

I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

Date:

Mon, 17 Jul 2017 00:19:37 -0700

From:

internet-drafts@ietf.org

Reply-To:

internet-drafts@ietf.org

To:

<i-d-announce@ietf.org>

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
 
        Title           : Topology Independent Fast Reroute using Segment Routing
        Authors         : Ahmed Bashandy
                          Clarence Filsfils
                          Bruno Decraene
                          Stephane Litkowski
                          Pierre Francois
        Filename        : draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt
        Pages           : 12
        Date            : 2017-07-17
 
Abstract:
   This document presents Topology Independent Loop-free Alternate Fast
   Re-route (TI-LFA), aimed at providing protection of node and
   adjacency segments within the Segment Routing (SR) framework.  This
   Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being
   LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
   (DLFA).  It extends these concepts to provide guaranteed coverage in
   any IGP network.  A key aspect of TI-LFA is the FRR path selection
   approach establishing protection over post-convergence paths from
   the point of local repair, dramatically reducing the operational
   need to control the tie-breaks among various FRR options.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bashandy-rtgwg-segment-routing-ti-lfa/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-bashandy-rtgwg-segment-routing-ti-lfa-01
 
 
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
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

 

 

 




_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--------------05FA068FA5022A2AB143DD9E-- From nobody Mon Aug 7 12:48:36 2017 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 8338E1324D6; Mon, 7 Aug 2017 12:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otOPf8jwAq3c; Mon, 7 Aug 2017 12:48:30 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87231326AA; Mon, 7 Aug 2017 12:48:20 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id m85so15078385wma.0; Mon, 07 Aug 2017 12:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=lVv15J/slsSdQLB+KJHASq3AykwY0CPmj4cqGSAOkmU=; b=HEk6LAkBXD8VD0Vb0hEYMsq40v7c3CxoiAJUfAuNrn7mpOlRras4wGkpmVFqBzJAex +qnQ9WqjaDiqQYbPBtTDgkXZVJX8ndI2+IJ7/L3n0KSDTw+AuZj5wAFesxYpy6MQz7tv NEpVia95ra5puwVo5bHZ4q3ezuStHuAby946/GCioZIznVos56K8bTg6TIJ8NsGpxxty 6swecywGzPCm7uH3L1RRlc3LhyIhnS3khs1YdcCqjM9/PLwFGqcfoWbhlnXG6DQ1aSNE XgBVGZQSCR/aMy5SujUSzUgRh/Z5HcE3mvgld/RjOESck1iGw4oykZf3FN4bzCLYEb1K 4A2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=lVv15J/slsSdQLB+KJHASq3AykwY0CPmj4cqGSAOkmU=; b=atWawsmGLrbdCuNFTz14k4rlj4Xn7+AyrjIe+ya1OGnSj3FylIUSIX3kI2qtKQLBfC TGuhnA1hA/DLqc+rWI5FC4+pGPg50rCmKJJ+eU7l3YHY/dBjsrKpa53rtbT1wZ8CgW++ 6iMbnOWTMKFNaw9XW3SIKWJA59eu1ld7Bp3CrKW5xSd7v+C7vzQmwQWWuuaZcwbCyRi4 CWLPabG2tBI92NneUfUUNm0BlcPR07LBeOxwyh26OS9SPL5RKTij3tEN59grtlUFyfOR jq0+oWAM1luhaQKyGUD6Fd+zb9PlWYHZtZchk/NbujjRH4yqicwNRAKgkBEMEr9jicdu oitg== X-Gm-Message-State: AHYfb5j4KBWw8ILmXDTjewUWq5O9FMubYASdqc5SlqhyBSrE2Tn+JgKY SBp6sx0llXp0pA== X-Received: by 10.28.93.138 with SMTP id r132mr1407015wmb.24.1502135299509; Mon, 07 Aug 2017 12:48:19 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id p192sm15779wme.12.2017.08.07.12.48.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 12:48:19 -0700 (PDT) Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt To: "Ahmed Bashandy (bashandy)" , Stewart Bryant , Sikhivahan Gundu , "rtgwg@ietf.org" Cc: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B030.8080001@cisco.com> From: Stewart Bryant Message-ID: <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> Date: Mon, 7 Aug 2017 20:48:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5988B030.8080001@cisco.com> Content-Type: multipart/alternative; boundary="------------E5BE63EAF5CAE976B854C574" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 19:48:34 -0000 This is a multi-part message in MIME format. --------------E5BE63EAF5CAE976B854C574 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Your answer did not address the issue below, which is one of a class of issues related to SRLG. - Stewart On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: > See my reply to Sikhi > > Thanks > > Ahmed > > > On 8/7/2017 2:13 AM, Stewart Bryant wrote: >> >> >> >> On 07/08/2017 06:45, Sikhivahan Gundu wrote: >>> >>> By “ambiguity”, I meant that backup calculation taking SRLG into >>> >>> account is based on speculated topology, whereas computation of >>> >>> post-convergence path, ie, SPF, is based on actual topology. This >>> >>> seems needs reconciling since in TI-LFA the backup is by definition >>> >>> the post-convergence path, with a single path-transition after >>> >>> link-failure as the intended outcome. Do I understand correctly that >>> >>> the draft prefers to relax that expectation for SRLG? >>> >>> >> >> Yes, that is a good point, in the event of an incomplete failure >> of an SRLG, there may not be congruence between the >> FRR path and the post convergence path. This certainly >> needs further study. >> >> * >> A--------//---------B >> | | >> | * | cost 2 >> C-------------------D >> | | >> | | cost 100 >> E-------------------F >> >> >> AB + CD in same SRLG >> >> TiLFA path is ACEFDB >> >> Post convergence path is ACDB >> >> In this case I think that the impact is just more SR hops in the >> repair path than might be needed without the SRLG, but we do need to >> be sure that there are no pathological cases in >> topologies that lack the proposed congruence, and as >> Sikhivahan notes this effect does need to be clarified in the >> text. >> >> - Stewart >> >> >> >> > > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg --------------E5BE63EAF5CAE976B854C574 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Your answer did not address the issue below, which is one of a class of issues related to SRLG.

- Stewart


On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:
See my reply to Sikhi

Thanks

Ahmed


On 8/7/2017 2:13 AM, Stewart Bryant wrote:



On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 



Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 
 



_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

--------------E5BE63EAF5CAE976B854C574-- From nobody Mon Aug 7 13:04:39 2017 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 69E02132758; Mon, 7 Aug 2017 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPyEQY_FPYPQ; Mon, 7 Aug 2017 13:04:36 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46FB413277B; Mon, 7 Aug 2017 13:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13715; q=dns/txt; s=iport; t=1502136275; x=1503345875; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HuGdGw6MdV/3DumfnyL7iLVPb91s7ipPd6fcqmeRRoE=; b=SSg5rxMcibfTm/WlAlRO4EaBuaJKDmxn1Rmj09t0iQUCF18x49affjgx PACp8ChHCr6+ssbCejg2myTMXmAowUw3aRbdQpyC4BhHENyOO+ORF/XGj NH5fWxJ+KVHzQl7BEUsoartvn0Du8oaqNOwpmskY3qsX8t5+4vywsvJVI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAACMx4hZ/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44IkAWBbog2iCyFMw6CBCEBCoUbAoRbPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQMBAStBCxACAQgRBAEBFhIHIQYLFAkIAgQBDQUIiUNMAxUQr?= =?us-ascii?q?kUnhwwNhA4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMoggKDL4MngleBWQF4CYU?= =?us-ascii?q?1BYlvlWQ8Ao8+hGqSVYwtiVoBHziBCncVSYUXHIFndohdgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,339,1498521600"; d="scan'208,217";a="277900837" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2017 20:04:34 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v77K4Xiu012734 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Aug 2017 20:04:33 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 7 Aug 2017 16:04:32 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 7 Aug 2017 16:04:32 -0400 From: "Ahmed Bashandy (bashandy)" To: Stewart Bryant , Stewart Bryant , Sikhivahan Gundu , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" Subject: RE: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Topic: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Thread-Index: AQHS/s0UOH2rEJV8wEWTuDjp0BV0SaJXbAIAgBgMyACABQzEAIAEQIMAgAA6YoCAACRCAIAAjPmA//+9EvA= Date: Mon, 7 Aug 2017 20:04:32 +0000 Message-ID: <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B030.8080001@cisco.com> <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> In-Reply-To: <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.160.78] Content-Type: multipart/alternative; boundary="_000_849700d9f030475a852096bfa51766fbXCHRTP020ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:04:38 -0000 --_000_849700d9f030475a852096bfa51766fbXCHRTP020ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart I already replied to Sikhi explaining the concept of the SRLG used in this = draft and the intent to make it even clearer. IMO the scope of the draft is very clear from the draft itself as well as t= he numerous responses during the previous IETF and the mailing list. The issue below is *out of scope* of the draft and hence I have no plans on= addressing it. I hope you don't insist on pushing out-of-scope topics down the throat of t= his draft :) Ahmed From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: Monday, August 07, 2017 12:48 PM To: Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; rtgwg@ietf= .org Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt Your answer did not address the issue below, which is one of a class of iss= ues related to SRLG. - Stewart On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: See my reply to Sikhi Thanks Ahmed On 8/7/2017 2:13 AM, Stewart Bryant wrote: On 07/08/2017 06:45, Sikhivahan Gundu wrote: By "ambiguity", I meant that backup calculation taking SRLG into account is based on speculated topology, whereas computation of post-convergence path, ie, SPF, is based on actual topology. This seems needs reconciling since in TI-LFA the backup is by definition the post-convergence path, with a single path-transition after link-failure as the intended outcome. Do I understand correctly that the draft prefers to relax that expectation for SRLG? Yes, that is a good point, in the event of an incomplete failure of an SRLG, there may not be congruence between the FRR path and the post convergence path. This certainly needs further study. * A--------//---------B | | | * | cost 2 C-------------------D | | | | cost 100 E-------------------F AB + CD in same SRLG TiLFA path is ACEFDB Post convergence path is ACDB In this case I think that the impact is just more SR hops in the repair path than might be needed without the SRLG, but we do need to be sure that there are no pathological cases in topologies that lack the proposed congruence, and as Sikhivahan notes this effect does need to be clarified in the text. - Stewart _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg --_000_849700d9f030475a852096bfa51766fbXCHRTP020ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stewart

 

I already replied to <= /span>Sikhi explaining the concept = of the SRLG used in this draft and the intent to make it even clearer.=

 

IMO the scope of the d= raft is very clear from the draft itself as well as the numerous responses = during the previous IETF and the mailing list.

 

The issue below is *out of scope* of the draft and hence I have no plans on addressing it.

 

I hope you don’t= insist on pushing out-of-scope topics down the throat of this draft :)

 

Ahmed

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, August 07, 2017 12:48 PM
To: Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; rtg= wg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa= -01.txt

 

Your answer did not address the issue below, which is one of a class of = issues related to SRLG.

- Stewart

 

On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote= :

See my reply to Sikhi

Thanks

Ahmed

On 8/7/2017 2:13 AM, Stewart Bryant wrote:

 

 

On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 <= /o:p>

By “ambiguity= ”, I meant that backup calculation taking SRLG into

account is  ba= sed on speculated topology,  whereas computation of

post-convergence pa= th, ie, SPF, is based on actual topology.  This

seems needs reconci= ling since in  TI-LFA the backup is by definition

the post-convergenc= e path, with a single path-transition after

link-failure as the= intended outcome. Do I understand correctly that

the draft prefers t= o relax that expectation for SRLG?

 <= /o:p>

 


Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|           &nbs= p;       |
|  *          &n= bsp;     | cost 2
C-------------------D
|           &nbs= p;       |
|               =    | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect do= es need to be clarified in the
text.

- Stewart



 





_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ie=
tf.org/mailman/listinfo/rtgwg

 

--_000_849700d9f030475a852096bfa51766fbXCHRTP020ciscocom_-- From nobody Mon Aug 7 13:34:28 2017 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 2A5B21323C0 for ; Mon, 7 Aug 2017 13:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=g3ysx-org-uk.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rPZAy2IpMXL for ; Mon, 7 Aug 2017 13:34:24 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E3A1323A1 for ; Mon, 7 Aug 2017 13:34:23 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id d40so2267090wma.3 for ; Mon, 07 Aug 2017 13:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=g3ysx-org-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=X2qEAIPSBwBbZSF9RWddkZm4jxVAn1WYJwpygRDWRW8=; b=DNSmW3iY4qPSc3TSQ9MotnSrJEfqWOUVDHxRJkb24v9qGZ9EsEC+BoHYyApa+X8OnL 7vLTdE5NMK7+v6NtW/CopVQVun3q08Jwt6NW9BXN2Sb76okzaUAao6fUiPzRVXTSy7eD iLH8cke5C4bRq+BgN/um0XZ7/MvqoftZmx9+2HskTsqToiUS8ZmcU3Zykz2hH12hSmfx BAfJgEtXbYdW+SQRNSbzOcB9CBIJG4wvhU8InkWv8IiaYUnatrHCjV8YhFkqVzDezkFK TJwuppKxglTxacnZT5Q+oFIyTZ4vz2wd+M6agveeZ8DowQDIyjcYtBhmVuqByPjpBpxI 2dgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=X2qEAIPSBwBbZSF9RWddkZm4jxVAn1WYJwpygRDWRW8=; b=PumFNnp5sn7Rsscg0wEhgFEywc+ee1t++5Vsby6MnajimWvLCZnaKZlbIU3hnoJRfQ TAIaHN5MN7KT6sQD4KU++uL7CJXQwhMzqzes7C3ROK2fV+PrV5FhE7xPmZ2rrLBTpVOa ChqNWJuQVGRb5IgYIdaN6J7aqiRbC96d4EsAbczjUvsEzz/003Nw+Nc5M3EGI6Dt0gT1 ZF4SQb2u06qNXz02iyx6kjsQQ0hzXEwDUD8BPRdmmFSlkzioS/tM7DBGKvMlovIzSzFC 01XxbaL3wcYnUYIzYEva4gIS3hJ4rFSwns2BvqXT2OF9IGqdAWFTPzZhNsgDdiHULHLe PGvA== X-Gm-Message-State: AHYfb5hEBE0TgztKjpMTzOomIZAYLJIgL148/EiaAIGrhNWgfwsc0RUj FTkPieVKIYdmGCEZ X-Received: by 10.28.47.84 with SMTP id v81mr1375795wmv.57.1502138062064; Mon, 07 Aug 2017 13:34:22 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id f80sm80897wmh.16.2017.08.07.13.34.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 13:34:21 -0700 (PDT) Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt To: "Ahmed Bashandy (bashandy)" , Stewart Bryant , Sikhivahan Gundu , "rtgwg@ietf.org" Cc: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B030.8080001@cisco.com> <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> From: Stewart Bryant Message-ID: <893ad668-9f62-51a1-0835-7841e919e63c@g3ysx.org.uk> Date: Mon, 7 Aug 2017 21:34:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> Content-Type: multipart/alternative; boundary="------------FEE04FCD8ADF01B9CEFFE6AD" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 20:34:27 -0000 This is a multi-part message in MIME format. --------------FEE04FCD8ADF01B9CEFFE6AD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Ahmed, The WG decides what is in or out of scope for a WG draft, and it does this via the rough consensus of the WG, not the view of the authors. Of course if you wish to refocus this as an independent draft and submit via the ISE. If you do, you are welcome and I will leave you to it. Meanwhile the draft really has to discuss SRLGs are they are in real life, not as you would wish them to be. Another type of false SRLG btw is when you are doing node protection (you normally treat a node as an SRLG), but only a line interface has failed. - Stewart On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote: > > Stewart > > I already replied to Sikhi explaining the concept of the SRLG used in > this draft and the intent to make it even clearer. > > IMO the scope of the draft is very clear from the draft itself as well > as the numerous responses during the previous IETF and the mailing list. > > The issue below is **out of scope** of the draft and hence I have no > plans on addressing it. > > I hope you don’t insist on pushing out-of-scope topics down the throat > of this draft :) > > Ahmed > > *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com] > *Sent:* Monday, August 07, 2017 12:48 PM > *To:* Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; > rtgwg@ietf.org > *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com > *Subject:* Re: I-D Action: > draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt > > Your answer did not address the issue below, which is one of a class > of issues related to SRLG. > > - Stewart > > On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: > > See my reply to Sikhi > > Thanks > > Ahmed > > On 8/7/2017 2:13 AM, Stewart Bryant wrote: > > On 07/08/2017 06:45, Sikhivahan Gundu wrote: > > By “ambiguity”, I meant that backup calculation taking > SRLG into > > account is based on speculated topology, whereas > computation of > > post-convergence path, ie, SPF, is based on actual > topology. This > > seems needs reconciling since in TI-LFA the backup is by > definition > > the post-convergence path, with a single path-transition > after > > link-failure as the intended outcome. Do I understand > correctly that > > the draft prefers to relax that expectation for SRLG? > > > Yes, that is a good point, in the event of an incomplete failure > of an SRLG, there may not be congruence between the > FRR path and the post convergence path. This certainly > needs further study. > > * > A--------//---------B > | | > | * | cost 2 > C-------------------D > | | > | | cost 100 > E-------------------F > > > AB + CD in same SRLG > > TiLFA path is ACEFDB > > Post convergence path is ACDB > > In this case I think that the impact is just more SR hops in the > repair path than might be needed without the SRLG, but we do > need to > be sure that there are no pathological cases in > topologies that lack the proposed congruence, and as > Sikhivahan notes this effect does need to be clarified in the > text. > > - Stewart > > > > > > > > _______________________________________________ > > rtgwg mailing list > > rtgwg@ietf.org > > https://www.ietf.org/mailman/listinfo/rtgwg > --------------FEE04FCD8ADF01B9CEFFE6AD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Ahmed,

The WG decides what is in or out of scope for a WG draft, and it does this via the rough consensus of the WG, not the view of the authors.

Of course if you wish to refocus this as an independent draft and submit via the ISE. If you do, you are welcome and I will leave you to it.

Meanwhile the draft really has to discuss SRLGs are they are in real life, not as you would wish them to be.

Another type of false SRLG btw is when you are doing node protection (you normally treat a node as an SRLG), but only a line interface has failed.

- Stewart




On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote:

Stewart

 

I already replied to Sikhi explaining the concept of the SRLG used in this draft and the intent to make it even clearer.

 

IMO the scope of the draft is very clear from the draft itself as well as the numerous responses during the previous IETF and the mailing list.

 

The issue below is *out of scope* of the draft and hence I have no plans on addressing it.

 

I hope you don’t insist on pushing out-of-scope topics down the throat of this draft :)

 

Ahmed

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, August 07, 2017 12:48 PM
To: Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Your answer did not address the issue below, which is one of a class of issues related to SRLG.

- Stewart

 

On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:

See my reply to Sikhi

Thanks

Ahmed

On 8/7/2017 2:13 AM, Stewart Bryant wrote:

 

 

On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 

 


Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 





_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

 


--------------FEE04FCD8ADF01B9CEFFE6AD-- From nobody Mon Aug 7 18:01:18 2017 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 E75BE131D1E; Mon, 7 Aug 2017 18:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I6qxpw_EIdc; Mon, 7 Aug 2017 18:01:12 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0117.outbound.protection.outlook.com [104.47.41.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 281C2131CEA; Mon, 7 Aug 2017 18:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mEt+ttE77StdLuPPFh3IxyL51yI5SZ0dzwg278BL+9s=; b=JA76E8belDEGEeE8wP5ofF/tzrMLIZcQfedqxcWuXZtrvqfR4/LSBpgMoaSDZWCn3IKRoatddKTOxA0dXw8QYiE538SwmzxKP3cSS5Nbokn5GZexbIx80IH5N7skKJqnnyeoBOHSRHTZT+lL48iNDwRPiwmFSibXa9Es1Kq9sGM= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB3551.namprd05.prod.outlook.com (10.174.250.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Tue, 8 Aug 2017 01:01:06 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.1341.010; Tue, 8 Aug 2017 01:01:06 +0000 From: Chris Bowers To: "stephane.litkowski@orange.com" , "draft-ietf-rtgwg-uloop-delay@ietf.org" CC: "rtgwg@ietf.org" Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/w== Date: Tue, 8 Aug 2017 01:01:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3551; 6:5H2dSgtY5RhVSNZBuRKejch76ue1SOi5DRxrdp41kheQwfOYd6ZQlmG3HAc7LasteuIaqUktE6z0uSFJGVx524pVmFdphENeVUp54T681rn9fhcocu+BH31+Z2NBQxIRlwL77u7ZOoP8ZXY2CCktAclhDFbo19xAGwL2+u5gHQAvCp5XXH4xBuzNr4lyWrCqq+nj7HU7tlqZtyyTyn3O5rtCWJ0pcYhsD+nfWp8W1urXQegdQK6L5RZDM88Q5FAZlNauzLcho9YY0rK00p0TrWi2QzrusK+0L4flHYSrzg/0Lxb7F1jxDpaX++Cjs5YswyMothpq8fAK8UH+nZbFDg==; 5:qInXFNLjtWdsx+j/qupErmWll5++JJji+xfVmz/AUWqxoDjToqlUh+zsgwc+yLJCizVOfK8/z1I8ZKAmK1KokAd+Gv5NoBXRO3ErI0lFD0N9PFcr4vP+mA+1q+S14N5iUOe/QX5lIcevQ59wiq5MWA==; 24:wjhObCtxCIAU/GLdtRcY01QujvzjASEU95B8E5U8+WU02WnCt0n35t+S1Amr7/EsBLnddXsG2xdVEZu6irfUDEc1fAQclL1jQ6WLTiVJpQE=; 7:ASqCWj4yQG0CjH3Ni79a7nrZdUQ7nhVrCOLPnVFGIg0pi/bRwuwVacEj7CnuXOggd9p2W/8kl7KzS9oHIetVZHhvj/hBC7SWRx02vjb7ab/kzXTtg7lFBd0XvWkzja8X1pXNmySkIWpZkaEUivlYtntj91OvLLdAsMDFTZyJxXjETFH2QiYBgbgg6MaoNJ7uMlmee3A3j4bfXuzx0Hwrg5sxHkPtcn/x5hgTGSyppbU= x-ms-office365-filtering-correlation-id: 2339dfcd-a34b-45cb-a93c-08d4ddf8f342 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3551; x-ms-traffictypediagnostic: MWHPR05MB3551: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3551; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3551; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39410400002)(39400400002)(189002)(37854004)(199003)(7696004)(99286003)(3846002)(55016002)(102836003)(3660700001)(966005)(6116002)(25786009)(230783001)(5660300001)(4326008)(38730400002)(66066001)(2906002)(2900100001)(53366004)(53936002)(9686003)(6306002)(86362001)(68736007)(3280700002)(53376002)(105586002)(106356001)(8936002)(50986999)(54356999)(101416001)(81156014)(81166006)(8676002)(6436002)(33656002)(14454004)(2501003)(97736004)(189998001)(478600001)(74316002)(6506006)(77096006)(305945005)(7736002)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3551; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB2829961037B7A03049D677E0A98A0MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 01:01:06.7536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3551 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 01:01:17 -0000 --_000_MWHPR05MB2829961037B7A03049D677E0A98A0MWHPR05MB2829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has no= t been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR= . =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris --_000_MWHPR05MB2829961037B7A03049D677E0A98A0MWHPR05MB2829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors,
 
I’m in the process of doing the Shepherd write-up for draft-ietf= -rtgwg-uloop-delay-05.txt. 
 
In reading the latest version of the document, I wrote down some feedb= ack.
A diff can be found at:
 
 
Most of the feedback is related to clarifying language and typos. = ; However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the lis= t.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[CB]  I find the examples presented in section 1 and section 2.1 = to
be confusing.  The conclusion drawn in the last paragraph of sect= ion
2.1 does not seem to follow from these examples.
 
Section 1 (figure 1) shows an example of micro-loops occuring when sho= rtest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR. 
 
Section 2.1 (figure 2) also shows an example of micro-loops occuring w= hen
shortest path forwarding is used and the metrics are such that LFA and= rLFA
produce no backup paths from the PLR.  However, in this example, =
a one-hop RSVP tunnel is provisioned to provide link protection for on= e of
the links.  However, even with this one-hop RSVP tunnel the examp= le
demonstrates that micro-loops can occur.
 
The last paragraph asserts that:
"The issue described here is completely independent of the fast-<= /div>
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)."
 
There are two problems with this assertion.
 
Problem 1) I don't think that the assertion is correct for RSVP TE-FRR= in general.
 
For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S = to D. 
Before the failure of the link C-B, this LSP would follow the path
S-E-C-B-A-D.  Immediately after the failure of link C-B, the LSP = would
follow the path S-E-C-E-A-B-A-D using the bypass LSP at C.  Once = S is
made aware of the failure.  S will resignal the LSP to take the p= ath S-E-A-D. 
At no time would looping occur. 
 
I assume that it wasn't the initial intention to claim that RSVP TE-FR= R suffers from
micro-looping, but the text currently reads that way.  The assert= ion of the last
paragraph should be qualified to talk about how microloops will still = affect traffic
forwarded hop-by-hop over links protected with one-hop RSVP-signaled L= SPs.
 
Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it h= as not
been demonstrated with the examples provided.  I think it may ins= tead be
the case that the assertion nay not be true for local LFA in some circ= umstances.
In particular, if traffic to a given destination can be protected for = a given
failure by the PLR using a local LFA that is the same as the post conv= ergence
path, then that traffic will not be subject to microloops.
 
Perhaps the overall intention of the example in figure 2 using
links protected with one-hop RSVP-signaled LSPs was to say that no
matter how much flexibility you give yourself in building a backup pat= h
from the PLR, if the PLR stops using the backup path before other rout= ers
stop sending traffic to the PLR, then you can still have forwarding lo= ops.
However, I think the complexity and detail of the example using one-ho= p
RSVP-signaled LSPs ends up confusing the matter.
 
The text should either work more systematically through examples to
substantiate the assertion, or the assertion should be scaled back.&nb= sp;
Regardless, the assertion needs to be clarified with respect to RSVP-T= E FRR.
 
=3D=3D=3D=3D=3D=3D 
Section 4.4
 
[CB]  It would be good to write out exactly what the modified ver= sion of step 5
looks like so there is no confusion. Something like:
 
5.  Upon SPF_DELAY timer expiration, the SPF is computed.  I= f the condition
of a single local link-down event have been met, then an update of the=
RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs.  Ot= herwise,
the RIB and FIB update is scheduled immediately.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
   Such a delay
   SHOULD only be introduced if all the LSDB modifications p= rocessed are
   only reporting a single local link down event (Section 4.= 3).  If a
   subsequent LSP/LSA is received/updated and a new SPF comp= utation is
   triggered before the expiration of ULOOP_DELAY_DOWN_TIMER= , then the
   same evaluation SHOULD be performed.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D  
[CB] What should one do if the evaluation of a subsequent LSP/LSA fail= s
at this point?  Do you go ahead and update the FIB with the forwa= rding
entries that you were waiting to do?  Or do you do a new SPF with= the
new information?  Or is it up to the implementation?
=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
I also ran the idnits check which show  the following issues.
Can you get rid of the unused references and move RFC 5715 from Normat= ive to informational so that idnits will run clean? 
 
 
Thanks,
Chris
 
 
 --_000_MWHPR05MB2829961037B7A03049D677E0A98A0MWHPR05MB2829namp_-- From nobody Tue Aug 8 06:25:03 2017 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 4C131132412 for ; Tue, 8 Aug 2017 06:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uewLBd1u1tuY for ; Tue, 8 Aug 2017 06:24:57 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2C0132397 for ; Tue, 8 Aug 2017 06:24:40 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 58E541C05C1; Tue, 8 Aug 2017 15:24:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 3645816007D; Tue, 8 Aug 2017 15:24:39 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0352.000; Tue, 8 Aug 2017 15:24:38 +0200 From: To: Chris Bowers CC: RTGWG , "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieA Date: Tue, 8 Aug 2017 13:24:38 +0000 Message-ID: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EA08A36OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 13:25:00 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921EA08A36OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has not been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR. =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921EA08A36OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chris,

 <= /p>

Thanks for the review. I&= #8217;m updating the document to reflect your proposals.<= /p>

Couple of comments:<= /o:p>

- =          s/“otherwis= e the standard IP convergence MUST be used.”/ “otherwise the st= andard IP convergence MUST used”. It does not sound good to me but ma= y be because of an English grammar issue on my side. Could you confirm the chan= ge ?

 <= /span>

- =          Regarding your ma= in comment on section 1 and 2.1, I do not agree about your statement on RSV= P-FRR. First there are multiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no stri= ct ERO

o   RSVP with CSPF at= head end (strict ERO)

- =          Regarding your co= mment on section 4.4, here is my new text proposal to fit your comment:

            =            

“Upon an adjacency/link down event, this document introduces a cha= nge

   in step 5 (<xref target=3D"description-current"= ;/>) in order to delay the local convergence compared to the<= /span>

   network wide convergence. The new step 5 is described below= :”

           5. Upon SPF= _DELAY timer expiration, the SPF is computed. If the condition of a single = local link-down event has been met and if the new convergence did not trigger a stop of the ULOOP_DELAY_DOWN_= TIMER , then an update of the RIB and the FIB SHOULD be delayed for ULOOP_D= ELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immedia= tely.

 

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”

 <= /p>

Brgds,<= /p>

 <= /p>

Stephane

 <= /p>

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.= org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing the S= hepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the do= cument, I wrote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to clar= ifying language and typos.  However there

are few comments that I think are more = substantive so I am

reproducing them below since they shoul= d probably discussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

[CB]  I find the examples presente= d in section 1 and section 2.1 to

be confusing.  The conclusion draw= n in the last paragraph of section

2.1 does not seem to follow from these = examples.

 

Section 1 (figure 1) shows an example o= f micro-loops occuring when shortest

path forwarding is used and the metrics= are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp;

 

Section 2.1 (figure 2) also shows an ex= ample of micro-loops occuring when

shortest path forwarding is used and th= e metrics are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp; However, in this example,

a one-hop RSVP tunnel is provisioned to= provide link protection for one of

the links.  However, even with thi= s one-hop RSVP tunnel the example

demonstrates that micro-loops can occur= .

 

The last paragraph asserts that:

"The issue described here is compl= etely independent of the fast-

reroute mechanism involved (TE FRR, LFA= /rLFA, MRT ...)."

 

There are two problems with this assert= ion.

 

Problem 1) I don't think that the asser= tion is correct for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there would = be an RSVP-signaled LSP from S to D. 

Before the failure of the link C-B, thi= s LSP would follow the path

S-E-C-B-A-D.  Immediately after th= e failure of link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D using t= he bypass LSP at C.  Once S is

made aware of the failure.  S will= resignal the LSP to take the path S-E-A-D. 

At no time would looping occur. 

 

I assume that it wasn't the initial int= ention to claim that RSVP TE-FRR suffers from

micro-looping, but the text currently r= eads that way.  The assertion of the last

paragraph should be qualified to talk a= bout how microloops will still affect traffic

forwarded hop-by-hop over links protect= ed with one-hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be correct= for LFA/rLFA and MRT, but it has not

been demonstrated with the examples pro= vided.  I think it may instead be

the case that the assertion nay not be = true for local LFA in some circumstances.

In particular, if traffic to a given de= stination can be protected for a given

failure by the PLR using a local LFA th= at is the same as the post convergence

path, then that traffic will not be sub= ject to microloops.

 

Perhaps the overall intention of the ex= ample in figure 2 using

links protected with one-hop RSVP-signa= led LSPs was to say that no

matter how much flexibility you give yo= urself in building a backup path

from the PLR, if the PLR stops using th= e backup path before other routers

stop sending traffic to the PLR, then y= ou can still have forwarding loops.

However, I think the complexity and det= ail of the example using one-hop

RSVP-signaled LSPs ends up confusing th= e matter.

 

The text should either work more system= atically through examples to

substantiate the assertion, or the asse= rtion should be scaled back. 

Regardless, the assertion needs to be c= larified with respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write ou= t exactly what the modified version of step 5

looks like so there is no confusion. So= mething like:

 

5.  Upon SPF_DELAY timer expiratio= n, the SPF is computed.  If the condition

of a single local link-down event have = been met, then an update of the

RIB and the FIB is scheduled in ULOOP_D= ELAY_DOWN_TIMER msecs.  Otherwise,

the RIB and FIB update is scheduled imm= ediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

   Such a delay

   SHOULD only be introduced = if all the LSDB modifications processed are

   only reporting a single lo= cal link down event (Section 4.3).  If a

   subsequent LSP/LSA is rece= ived/updated and a new SPF computation is

   triggered before the expir= ation of ULOOP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD be = performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D  

[CB] What should one do if the evaluati= on of a subsequent LSP/LSA fails

at this point?  Do you go ahead an= d update the FIB with the forwarding

entries that you were waiting to do?&nb= sp; Or do you do a new SPF with the

new information?  Or is it up to t= he implementation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

I also ran the idnits check which show&= nbsp; the following issues.

Can you get rid of the unused reference= s and move RFC 5715 from Normative to informational so that idnits will run= clean? 

 

 

Thanks,

Chris

 

 

______________________________________________________________________=
___________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921EA08A36OPEXCLILMA4corp_-- From nobody Tue Aug 8 07:04:47 2017 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 C5CB0132476 for ; Tue, 8 Aug 2017 07:04:45 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX-vKBBsLx6d for ; Tue, 8 Aug 2017 07:04:42 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0108.outbound.protection.outlook.com [104.47.41.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DBA132452 for ; Tue, 8 Aug 2017 07:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XgMFOA5xrAn7C3qW8eUafXy4gRIAEcc8XA0Xej5Qsu8=; b=RLTYCez7f3hCHrtTnnKl3MVU0zxFc1mzL0usJQyShzVes/loxoAoQbpDAUog/zhUt/KvlGIZA04LbLfHK4MPmgKCnnjW5mIAGySU1hVhME+pM5hCka9CBpGFrEnJCozcCqQ1ZWQ4moFchkX5lXZIR/+JWRVnqnPU+qXGpS9iAwI= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB3504.namprd05.prod.outlook.com (10.174.250.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Tue, 8 Aug 2017 14:04:40 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.1341.010; Tue, 8 Aug 2017 14:04:40 +0000 From: Chris Bowers To: "stephane.litkowski@orange.com" CC: RTGWG , "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieAAAJIxSA= Date: Tue, 8 Aug 2017 14:04:40 +0000 Message-ID: References: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3504; 6:ytQKCwXQ24oXSepEfiiecTCWZqrhTGFl4x4DbaTeJHU41hsyDgkblzIOgIss3l0cfncqRaJbeF6htZypWHnCopXkZtzZV72cPkxKIhUY1JxrbNTwpuVUQEYz3Ze8+WZ/ZyIgb7LCpZ+LAagksJlTcey9Z2VMzypYyGaw4fN3Oi713Zd8WZazpkkV3gsfyaCIu7x1PQnuxBNKBQgmI7cIaKviikz9j/w2mabtCHuIGGFFa4a7AmarOrpHGkoYNFKkxCI2pi9L8raUfHHG9WdGYPBK0/dZThK357SF2qMRg8bwPNR4jBFRAGu4GGVlZx8ncZ1iITlCFqO3IpAJTvefrA==; 5:S237iTw/3FT2lkHr+1PllxWgGyVuK+l4V9G4L/Q85VQF+qLNi9CTFZbmPO68vo4BMYeuQEiyPVOBZlsSk5EqbCbqIrbytHjXHTZNHqQ3oFYt6c8EroTb7eDagGI0pXZESQNHwXpxoWnkHdXSk6w3yA==; 24:4DpK8dS7qRh9Fn6rSlfny1osIwkTyY5CpvV2miaAmeZyAGNM7DePDVSB4e+wvMd5ld2e3cqbl3REJvYKKamTDyYP6WNaG27lOUVa+H1sSRs=; 7:Vk7OLVyEtUJOiC3ZO2+HQf5jG5yhvMcTvewXvDkyvt/ODq9a8ia8iIGcAgNw5QMbtluwep/5dmCxPvaA061zbADk6sNt7j8AkOJz5xg++l7Ljr7U6BO7sQXuPe2DmxWn2R8/kkbszoIIcKNkKBNoe/zeiDnVnZ51feE/Ci3L4VxSNwjhbDlGOC8hwnP+4RB5nwe5L7x9uT30KgOdc3y7WGKYTDcIpznz89fpcLepsEA= x-ms-office365-filtering-correlation-id: c12336e6-5216-4606-8e1a-08d4de666985 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3504; x-ms-traffictypediagnostic: MWHPR05MB3504: x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008)(18271650672692)(21748063052155)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3504; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3504; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39410400002)(39840400002)(39860400002)(39400400002)(39850400002)(377454003)(189002)(199003)(51914003)(37854004)(68736007)(7696004)(74316002)(97736004)(5660300001)(478600001)(6506006)(189998001)(230783001)(25786009)(5640700003)(55016002)(99286003)(9686003)(53936002)(77096006)(5630700001)(6306002)(54906002)(6246003)(4326008)(19609705001)(53946003)(86362001)(236005)(229853002)(54896002)(38730400002)(110136004)(7736002)(53366004)(53376002)(6436002)(3280700002)(105586002)(2950100002)(54356999)(81156014)(81166006)(8676002)(5890100001)(966005)(8936002)(50986999)(6916009)(76176999)(2501003)(2900100001)(106356001)(2351001)(101416001)(3660700001)(102836003)(6116002)(790700001)(2906002)(14454004)(3846002)(53546010)(561944003)(33656002)(66066001)(606006)(493534005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3504; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB282938E44A09FB1F2C34B881A98A0MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 14:04:40.3848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3504 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 14:04:46 -0000 --_000_MWHPR05MB282938E44A09FB1F2C34B881A98A0MWHPR05MB2829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephane, See responses inline with [CB]. Chris From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 8, 2017 8:25 AM To: Chris Bowers Cc: RTGWG ; draft-ietf-rtgwg-uloop-delay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? [CB] You are correct. That proposed change is a mistake on my part. - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." [CB] "when the primary path is an hop by hop defined path" is somewhat amb= iguous. How about "when the primary path uses hop-by-hop routing" ? For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. [CB] OK. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." [CB] This text seems clearer. Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.tx= t Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has no= t been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR= . =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_MWHPR05MB282938E44A09FB1F2C34B881A98A0MWHPR05MB2829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephane,

 

See responses inline with [CB].<= /o:p>

 

Chris

 

From: stephane.litkowski@orange.com = [mailto:stephane.litkowski@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers <cbowers@juniper.net>
Cc: RTGWG <rtgwg@ietf.org>; draft-ietf-rtgwg-uloop-delay@tools= .ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi Chris,

 

Thanks for the review. I’m upda= ting the document to reflect your proposals.

Couple of comments:=

-   =        s/“otherwise the standa= rd IP convergence MUST be used.”/ “otherwise the standard IP co= nvergence MUST used”. It does not sound good to me but may be because of an English grammar issue on my side. Could you confirm the chan= ge ?

 

[CB]  You are correct.  Tha= t proposed change is a mistake on my part.

 

-   =        Regarding your main comment o= n section 1 and 2.1, I do not agree about your statement on RSVP-FRR. First= there are multiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO<= /o:p>

o   RSVP with CSPF at head end (s= trict ERO)

Your state= ment is true only for the third case where an RSVP tunnel between S and D e= xists with its path computed by S =3D> no uloop in that case for sure. But as soon as you rely on distributed convergence, yo= u will fall into a loop even if you use RSVP-FRR. I will precise in the tex= t that we are in an LDP scenario for example. Here is a text proposal:=

“In = the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T, pr= ovisioned on C and terminating on B, is used to protect the traffic against C-B link failure (IGP shortcut is activated on C).R= 21;

“The= issue described here is completely independent of the fast-reroute mechani= sm involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop by hop defined path.”

 

 

[CB] “whe= n the primary path is an hop by hop defined path”  is somewhat a= mbiguous.

How about “when the primary path uses hop-by-hop routing” ?

 

 = ;

For the LF= A case, yes, there are some cases where there is no loop, but it is topolog= y dependent. I’m not sure that we need to give such precision as if the LFA is on the postconvergence path, this means that th= e postconvergence is loopfree, so there will be no local microloop in any c= ase.

 = ;

[CB]  OK. 

 = ;

-   =        Regarding your comment on sec= tion 4.4, here is my new text proposal to fit your comment:

 &nb= sp;            =          

“Up= on an adjacency/link down event, this document introduces a change

 &nb= sp; in step 5 (<xref target=3D"description-current"/>) in o= rder to delay the local convergence compared to the

 &nb= sp; network wide convergence. The new step 5 is described below:”

 &nb= sp;         5. Upon SPF_DELAY timer= expiration, the SPF is computed. If the condition of a single local link-d= own event has been met and if the new convergence did not trigger a stop of the ULOOP_DELAY_DOWN_= TIMER , then an update of the RIB and the FIB SHOULD be delayed for ULOOP_D= ELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immedia= tely.

&nbs= p;

If a new = convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_DELAY_DOW= N_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”

 

[CB]  This text seems clearer.

 

Brgds,

 

Stephane

 

 

From: Chris Bowers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing the Shepherd writ= e-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the document, I wr= ote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to clarifying langu= age and typos.  However there

are few comments that I think are more substantive = so I am

reproducing them below since they should probably d= iscussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

[CB]  I find the examples presented in section= 1 and section 2.1 to

be confusing.  The conclusion drawn in the las= t paragraph of section

2.1 does not seem to follow from these examples.

 

Section 1 (figure 1) shows an example of micro-loop= s occuring when shortest

path forwarding is used and the metrics are such th= at LFA and rLFA

produce no backup paths from the PLR. 

 

Section 2.1 (figure 2) also shows an example of mic= ro-loops occuring when

shortest path forwarding is used and the metrics ar= e such that LFA and rLFA

produce no backup paths from the PLR.  However= , in this example,

a one-hop RSVP tunnel is provisioned to provide lin= k protection for one of

the links.  However, even with this one-hop RS= VP tunnel the example

demonstrates that micro-loops can occur.=

 

The last paragraph asserts that:<= /p>

"The issue described here is completely indepe= ndent of the fast-

reroute mechanism involved (TE FRR, LFA/rLFA, MRT .= ..)."

 

There are two problems with this assertion.

 

Problem 1) I don't think that the assertion is corr= ect for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there would be an RSVP-s= ignaled LSP from S to D. 

Before the failure of the link C-B, this LSP would = follow the path

S-E-C-B-A-D.  Immediately after the failure of= link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D using the bypass LS= P at C.  Once S is

made aware of the failure.  S will resignal th= e LSP to take the path S-E-A-D. 

At no time would looping occur. 

 

I assume that it wasn't the initial intention to cl= aim that RSVP TE-FRR suffers from

micro-looping, but the text currently reads that wa= y.  The assertion of the last

paragraph should be qualified to talk about how mic= roloops will still affect traffic

forwarded hop-by-hop over links protected with one-= hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be correct for LFA/rLF= A and MRT, but it has not

been demonstrated with the examples provided. = I think it may instead be

the case that the assertion nay not be true for loc= al LFA in some circumstances.

In particular, if traffic to a given destination ca= n be protected for a given

failure by the PLR using a local LFA that is the sa= me as the post convergence

path, then that traffic will not be subject to micr= oloops.

 

Perhaps the overall intention of the example in fig= ure 2 using

links protected with one-hop RSVP-signaled LSPs was= to say that no

matter how much flexibility you give yourself in bu= ilding a backup path

from the PLR, if the PLR stops using the backup pat= h before other routers

stop sending traffic to the PLR, then you can still= have forwarding loops.

However, I think the complexity and detail of the e= xample using one-hop

RSVP-signaled LSPs ends up confusing the matter.

 

The text should either work more systematically thr= ough examples to

substantiate the assertion, or the assertion should= be scaled back. 

Regardless, the assertion needs to be clarified wit= h respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write out exactly wh= at the modified version of step 5

looks like so there is no confusion. Something like= :

 

5.  Upon SPF_DELAY timer expiration, the SPF i= s computed.  If the condition

of a single local link-down event have been met, th= en an update of the

RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TI= MER msecs.  Otherwise,

the RIB and FIB update is scheduled immediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

   Such a delay

   SHOULD only be introduced if all the L= SDB modifications processed are

   only reporting a single local link dow= n event (Section 4.3).  If a

   subsequent LSP/LSA is received/updated= and a new SPF computation is

   triggered before the expiration of ULO= OP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD be performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D  

[CB] What should one do if the evaluation of a subs= equent LSP/LSA fails

at this point?  Do you go ahead and update the= FIB with the forwarding

entries that you were waiting to do?  Or do yo= u do a new SPF with the

new information?  Or is it up to the implement= ation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I also ran the idnits check which show  the fo= llowing issues.

Can you get rid of the unused references and move R= FC 5715 from Normative to informational so that idnits will run clean? = ;

 

 

Thanks,

Chris

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_MWHPR05MB282938E44A09FB1F2C34B881A98A0MWHPR05MB2829namp_-- From nobody Tue Aug 8 08:20:24 2017 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 B49E213234E for ; Tue, 8 Aug 2017 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rRL8s9UpX1E for ; Tue, 8 Aug 2017 08:20:18 -0700 (PDT) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7712132496 for ; Tue, 8 Aug 2017 08:20:17 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4FCD2120692; Tue, 8 Aug 2017 17:20:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 2556640064; Tue, 8 Aug 2017 17:20:16 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0352.000; Tue, 8 Aug 2017 17:20:15 +0200 From: To: Chris Bowers CC: RTGWG , "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieAAAJIxSAAA2K9IA== Date: Tue, 8 Aug 2017 15:20:15 +0000 Message-ID: <21996_1502205616_5989D6B0_21996_381_1_9E32478DFA9976438E7A22F69B08FF921EA08B2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EA08B2FOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:20:22 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921EA08B2FOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Chris, I will post a new revision with those changes. From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 16:05 To: LITKOWSKI Stephane OBS/OINIS Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Stephane, See responses inline with [CB]. Chris From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 8, 2017 8:25 AM To: Chris Bowers > Cc: RTGWG >; draft-ietf-rtgwg-uloop-d= elay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? [CB] You are correct. That proposed change is a mistake on my part. - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." [CB] "when the primary path is an hop by hop defined path" is somewhat amb= iguous. How about "when the primary path uses hop-by-hop routing" ? For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. [CB] OK. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." [CB] This text seems clearer. Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has not been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR. =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921EA08B2FOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Chris, I will post= a new revision with those changes.

 <= /p>

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Stephane,

 <= /p>

See responses inline with= [CB].

 <= /p>

Chris

 <= /p>

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers <cbowers@= juniper.net>
Cc: RTGWG <rtgwg@ietf.org&g= t;; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi Chris,

 <= /p>

Thanks for the review. I&= #8217;m updating the document to reflect your proposals.<= /p>

Couple of comments:<= /o:p>

- &nbs= p;        s/“otherwise the standard IP conver= gence MUST be used.”/ “otherwise the standard IP convergence MU= ST used”. It does not sound good to me but may be because of an Engli= sh grammar issue on my side. Could you confirm the change ?=

 <= /p>

[CB]  You are correc= t.  That proposed change is a mistake on my part.

 <= /span>

- &nbs= p;        Regarding your main comment on section 1 = and 2.1, I do not agree about your statement on RSVP-FRR. First there are m= ultiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO=

o   RSVP with CSPF at head end (strict ERO)

 <= /p>

 <= /p>

[CB] “when the prim= ary path is an hop by hop defined path”  is somewhat ambiguous.<= o:p>

How about “when the= primary path uses hop-by-hop routing” ?

 <= /p>

[CB]  OK. 

- &nbs= p;        Regarding your comment on section 4.4, he= re is my new text proposal to fit your comment:

            =            

“Upon an adjacency/link down event, this document introduces a cha= nge

   in step 5 (<xref target=3D"description-current"= ;/>) in order to delay the local convergence compared to the<= /span>

   network wide convergence. The new step 5 is described below= :”

           5. Upon SPF= _DELAY timer expiration, the SPF is computed. If the condition of a single = local link-down event has been met and if the new convergence did not trigger a stop of the ULOOP_DELAY_DOWN_= TIMER , then an update of the RIB and the FIB SHOULD be delayed for ULOOP_D= ELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immedia= tely.

 

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”

 <= /p>

[CB]  This text seem= s clearer.

 <= /p>

Brgds,<= /p>

 <= /p>

Stephane

 <= /p>

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing the S= hepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the do= cument, I wrote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to clar= ifying language and typos.  However there

are few comments that I think are more = substantive so I am

reproducing them below since they shoul= d probably discussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

[CB]  I find the examples presente= d in section 1 and section 2.1 to

be confusing.  The conclusion draw= n in the last paragraph of section

2.1 does not seem to follow from these = examples.

 

Section 1 (figure 1) shows an example o= f micro-loops occuring when shortest

path forwarding is used and the metrics= are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp;

 

Section 2.1 (figure 2) also shows an ex= ample of micro-loops occuring when

shortest path forwarding is used and th= e metrics are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp; However, in this example,

a one-hop RSVP tunnel is provisioned to= provide link protection for one of

the links.  However, even with thi= s one-hop RSVP tunnel the example

demonstrates that micro-loops can occur= .

 

The last paragraph asserts that:

"The issue described here is compl= etely independent of the fast-

reroute mechanism involved (TE FRR, LFA= /rLFA, MRT ...)."

 

There are two problems with this assert= ion.

 

Problem 1) I don't think that the asser= tion is correct for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there would = be an RSVP-signaled LSP from S to D. 

Before the failure of the link C-B, thi= s LSP would follow the path

S-E-C-B-A-D.  Immediately after th= e failure of link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D using t= he bypass LSP at C.  Once S is

made aware of the failure.  S will= resignal the LSP to take the path S-E-A-D. 

At no time would looping occur. 

 

I assume that it wasn't the initial int= ention to claim that RSVP TE-FRR suffers from

micro-looping, but the text currently r= eads that way.  The assertion of the last

paragraph should be qualified to talk a= bout how microloops will still affect traffic

forwarded hop-by-hop over links protect= ed with one-hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be correct= for LFA/rLFA and MRT, but it has not

been demonstrated with the examples pro= vided.  I think it may instead be

the case that the assertion nay not be = true for local LFA in some circumstances.

In particular, if traffic to a given de= stination can be protected for a given

failure by the PLR using a local LFA th= at is the same as the post convergence

path, then that traffic will not be sub= ject to microloops.

 

Perhaps the overall intention of the ex= ample in figure 2 using

links protected with one-hop RSVP-signa= led LSPs was to say that no

matter how much flexibility you give yo= urself in building a backup path

from the PLR, if the PLR stops using th= e backup path before other routers

stop sending traffic to the PLR, then y= ou can still have forwarding loops.

However, I think the complexity and det= ail of the example using one-hop

RSVP-signaled LSPs ends up confusing th= e matter.

 

The text should either work more system= atically through examples to

substantiate the assertion, or the asse= rtion should be scaled back. 

Regardless, the assertion needs to be c= larified with respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write ou= t exactly what the modified version of step 5

looks like so there is no confusion. So= mething like:

 

5.  Upon SPF_DELAY timer expiratio= n, the SPF is computed.  If the condition

of a single local link-down event have = been met, then an update of the

RIB and the FIB is scheduled in ULOOP_D= ELAY_DOWN_TIMER msecs.  Otherwise,

the RIB and FIB update is scheduled imm= ediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

   Such a delay

   SHOULD only be introduced = if all the LSDB modifications processed are

   only reporting a single lo= cal link down event (Section 4.3).  If a

   subsequent LSP/LSA is rece= ived/updated and a new SPF computation is

   triggered before the expir= ation of ULOOP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD be = performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D  

[CB] What should one do if the evaluati= on of a subsequent LSP/LSA fails

at this point?  Do you go ahead an= d update the FIB with the forwarding

entries that you were waiting to do?&nb= sp; Or do you do a new SPF with the

new information?  Or is it up to t= he implementation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

I also ran the idnits check which show&= nbsp; the following issues.

Can you get rid of the unused reference= s and move RFC 5715 from Normative to informational so that idnits will run= clean? 

 

 

Thanks,

Chris

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921EA08B2FOPEXCLILMA4corp_-- From nobody Tue Aug 8 08:25:51 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64513233A; Tue, 8 Aug 2017 08:25:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-uloop-delay-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150220594888.12432.16774321443270169362@ietfa.amsl.com> Date: Tue, 08 Aug 2017 08:25:48 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 15:25:49 -0000 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 WG of the IETF. Title : Micro-loop prevention by introducing a local convergence delay Authors : Stephane Litkowski Bruno Decraene Clarence Filsfils Pierre Francois Filename : draft-ietf-rtgwg-uloop-delay-06.txt Pages : 22 Date : 2017-08-08 Abstract: This document describes a mechanism for link-state routing protocols to prevent local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network wide convergence. As this mechanism delays the IGP convergence it may only be used for planned maintenance or when fast reroute protects the traffic between the link failure time and the IGP convergence. The proposed mechanism is limited to the link down event in order to keep the mechanism simple. Simulations using real network topologies have been performed and show that local loops are a significant portion (>50%) of the total forwarding loops. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-uloop-delay-06 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-uloop-delay-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-uloop-delay-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 8 12:09:05 2017 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 D0285132A21; Tue, 8 Aug 2017 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHBtRSBG5Kt4; Tue, 8 Aug 2017 12:09:02 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0129.outbound.protection.outlook.com [104.47.32.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C9D13232F; Tue, 8 Aug 2017 12:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cvnAyv2NM3mEXa+nmPcZn/zq+g605L9Cx/upZQQIo4Y=; b=G8FA1R9R6rsRpXANukaJJUOwdWw3XVzaSB2EM9PCmP0qEXo7tqVimS5+eaxbkXU3Yt/j6k5QZB9wR+zRepKs/+7q+QHMpFGleNXfyEmVIbNNYBFpkC4Z5I+PEaIHEE7HUjMBVNNMzykQntiNB7Zv+lQAxQVS1IX72o+mzPjACO4= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB3087.namprd05.prod.outlook.com (10.173.228.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Tue, 8 Aug 2017 19:09:00 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.1341.010; Tue, 8 Aug 2017 19:09:00 +0000 From: Chris Bowers To: Jeff Tantsura , RTGWG CC: 'rtgwg-chairs' , "draft-bryant-rtgwg-param-sync@ietf.org" Subject: RE: Request for WG adoption of for draft-bryant-rtgwg-param-sync Thread-Topic: Request for WG adoption of for draft-bryant-rtgwg-param-sync Thread-Index: AQHTDVpc+6oQFGcdU0WOy+26Yg9ZnaJ62Fwg Date: Tue, 8 Aug 2017 19:09:00 +0000 Message-ID: References: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> In-Reply-To: <54854841-A47A-46B8-9563-4C7901179AF2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3087; 6:df8fTqqtazwQFgL/I1QbIN2OUc4CE3PaBKKAXIWzI+bVqFU9LVP+ipEawES5jzsOqy6rDIw2VQ5Zwgwzhg8/Iu3ycOo3iuz86H3J/CEvkdNo3g745X3qg5srkYsR8HjM8iWYk33EfC0TFE4hnXofuBDDtJs1zEvqiLcBM8hRd+FrarjP1O+IrYVcgoBtcGnmlesfP/mTZ0tBVpGLigTP0/+OqENGGY8Tu0eBRg1P5BX7BPFYVUU+Ldr5S+vFUIykAFSbUPh4+WvIgLsan1ecH7hzkPYeT8JWQUshjqhuy9Uc3yTuShiKxW/OdN1oSKER+Zoz88w6cm8VhDxHGZr6GA==; 5:xDcM+NRdcae6/bcNE2xP6+G7vCavQiZpnbo6UN97c4UteNP4GBNUj8yHpboHpMSufZfcgg017oUUyUt86zlT+NLPcNsybq+qRy3bYifUpwq7XS05tbwtbrLOl8dhpyirk7rWy3Xgln971fS0wWm/fg==; 24:rlfonl8yCCaGbIOYRgoMyBMkAzO2FFA5qa6nU+AcSxfoMKaEmjXFvRG+G9W74+7HFqLfA0Th1nrddbij4vK4X2iAx8OXwNTI4To44tUz8mM=; 7:4wn1UB+gyGwOcKFU0eOI/lAeP9jAJklWdbsSghihi8GlJi+DUqwSxtfoEMrNUhYhC2aSXLnsjZBZIpbamfY03wNLuJ+zwYgo9QfYYAjV0W6xG3FB8rvQq9W7l9S/znlVinozLzAwBllfvcP27CNlfAgSQOaA0rXXTCMGQgg0I3WPhXw7LBmSGb+ugypGafBOrLjB1VHnlutygywj3l/GZ8uApd8fB7YnwIvKD7jw/f8= x-ms-office365-filtering-correlation-id: e88ec586-6220-404b-0d20-08d4de90ed63 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3087; x-ms-traffictypediagnostic: MWHPR05MB3087: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3087; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3087; x-forefront-prvs: 03932714EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39850400002)(39860400002)(39410400002)(39400400002)(13464003)(189002)(377454003)(199003)(25786009)(8676002)(101416001)(106356001)(478600001)(8936002)(68736007)(81166006)(81156014)(4326008)(53546010)(413944005)(14454004)(105586002)(189998001)(66066001)(99286003)(55016002)(54906002)(9686003)(102836003)(305945005)(6116002)(2950100002)(3846002)(229853002)(86362001)(7696004)(3660700001)(5660300001)(7736002)(6506006)(50986999)(77096006)(33656002)(76176999)(230783001)(74316002)(2906002)(54356999)(38730400002)(6246003)(6436002)(2900100001)(39060400002)(53936002)(97736004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3087; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2017 19:09:00.4024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3087 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 19:09:04 -0000 RGVhciBSVEdXRywNCg0KSSBhbSBhIGNvLWF1dGhvciwgYW5kIEkgc3VwcG9ydCB0aGUgZHJhZnQu DQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQoNCkNocmlzDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZm dGFudC5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEF1Z3VzdCA0LCAyMDE3IDI6NDYg UE0NClRvOiBSVEdXRyA8cnRnd2dAaWV0Zi5vcmc+DQpDYzogJ3J0Z3dnLWNoYWlycycgPHJ0Z3dn LWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWJyeWFudC1ydGd3Zy1wYXJhbS1zeW5jQGll dGYub3JnDQpTdWJqZWN0OiBSZXF1ZXN0IGZvciBXRyBhZG9wdGlvbiBvZiBmb3IgZHJhZnQtYnJ5 YW50LXJ0Z3dnLXBhcmFtLXN5bmMNCg0KRGVhciBSVEdXRywNCg0KVGhlIGF1dGhvcnMgaGF2ZSBy ZXF1ZXN0ZWQgdGhlIFJUR1dHIHRvIGFkb3B0IGZvciBkcmFmdC1icnlhbnQtcnRnd2ctcGFyYW0t c3luYyBhcyB0aGUgd29ya2luZyBncm91cCBkb2N1bWVudC4gDQoNCldHIGV4cHJlc3NlZCBzdXBw b3J0IGR1cmluZyB0aGUgbGFzdCBSVEdXRyBtZWV0aW5nIGFuZCB0aGUgYXV0aG9ycyBoYXZlIGFk ZHJlc3NlZCBhbGwgdGhlIGNvbW1lbnRzIHJlY2VpdmVkLg0KUGxlYXNlIGluZGljYXRlIHN1cHBv cnQgb3Igbm8tc3VwcG9ydCBieSBBdWd1c3QgMTgsIDIwMTcuDQoNCklmIHlvdSBhcmUgbGlzdGVk IGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRo aXMgZW1haWwgc3RhdGluZyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSBy ZWxldmFudCBJUFIuIFRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBSVEdXRyBt YWlsaW5nIGxpc3QuIFRoZSBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0 YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh bmQgZWFjaCBpbmRpdmlkdWFsIHRoYXQgaGFzIGNvbnRyaWJ1dGVkIHRvIHRoZSBkb2N1bWVudC4N Cg0KQ2hlZXJzLA0KSmVmZiANCg0KDQoNCg== From nobody Wed Aug 9 03:19:10 2017 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 9FE71132144 for ; Wed, 9 Aug 2017 03:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQsS7bhQ3Axa for ; Wed, 9 Aug 2017 03:19:00 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9A3132153 for ; Wed, 9 Aug 2017 03:18:55 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-62-598ae18d8b57 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.ED.06959.D81EA895; Wed, 9 Aug 2017 12:18:53 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 9 Aug 2017 12:18:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IzbmdKiKYTVVQILUdIRi3sAeeTSox3C8eacfHplVeqY=; b=TEzecOifPXs1SNUhnMY9qb2VMZG/KKxjyizSRnMWTO9XjJ4Nt79c/JPnBdT5l/ivwurWHbvma00CZXADqxTepoVNBotCh2J3qZ9vrX3rWd8sbdAy95MriigMGvUDSoJ98b+QaZmBSQ4JIv3HEqhv7IlJ9LGFNO12kNXqzuAqG7U= Received: from HE1PR07MB1708.eurprd07.prod.outlook.com (10.166.124.150) by HE1PR07MB1642.eurprd07.prod.outlook.com (10.166.124.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Wed, 9 Aug 2017 10:18:50 +0000 Received: from HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71]) by HE1PR07MB1708.eurprd07.prod.outlook.com ([fe80::3540:7f26:748d:aa71%13]) with mapi id 15.01.1320.018; Wed, 9 Aug 2017 10:18:50 +0000 From: Sikhivahan Gundu To: "stephane.litkowski@orange.com" , "Chris Bowers" CC: "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" , RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieAAAJIxSAAA2K9IAAe/WLA Date: Wed, 9 Aug 2017 10:18:50 +0000 Message-ID: References: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <21996_1502205616_5989D6B0_21996_381_1_9E32478DFA9976438E7A22F69B08FF921EA08B2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <21996_1502205616_5989D6B0_21996_381_1_9E32478DFA9976438E7A22F69B08FF921EA08B2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.16.128.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1642; 6:3bUglB+Ytl76GahIxcMDEF68tgHfH4OvBu4kyKWZnEwXJl//oplOCkqzE5avFjvEmjBlyoZybRtKU2XKq2NciJ3gLWYwxbMBZ7qcR7ZZi6Tewy8bjKTdCVTe+end47LEtD0Zketox0687MehYJ8pFtJQbjRtrPJnnSu14lia7hoQbzb65R044SNHqY3HPCbea+0mHm2jynkddgqtR5cR8wenHTjqRjVtHf6mFqbakDbrDHoPwScEYLvLK0MDS6/Co8sb1+7ppqJnMVzxoZOztN9a64oamFdKDZa8zct2pTqIkmv4k+dxi+ieRRrlfRxOAs9qs/oguZOYV+hKG3iAsA==; 5:5gjVdJJdDyCksx29C5QdAmE1+PASB4R2MbsH2yYdKcDPCK2fLMS02JnRr3taV0vlinYaOi9siccIREoZzSdVcTrSXgK4XxH1Accn1FzClOqYWq2/pUN2yBSoyrES6aNFQmt6P+KMDGAmR+noPaQZFA==; 24:h00C4xu2M6AGzsjRBiczJiGSrRcVZch3iImSV4jXy3phNkVZcG2cEKOJe4FgY4CgGLx6gjer/njbmtuGbPxZ6X0c/MmWmykwuNhpJglnTU4=; 7:spPuQ53i1J7JERv1nsQDwyeXVj33QboIkcBlaxKTEXyPgm93awU9kkbbgZBR+4Dsqg0wiPVNOJ4glU09xXsxp8o5dC+CnDd+jAw3iQWPmJRM6fdabFUGDYgUL8iltPdI8Sp9vjF+XBXaPqsKbItLeOsmW3MJFDI4IrObvcR1jZzeJ734krulv+V67uXL7miskaG70MC7w+bE82t70OC/ZDrvVdCOumsdwr63PBcLpfE= x-ms-office365-filtering-correlation-id: bd136700-f292-4ece-f9dd-08d4df1007c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB1642; x-ms-traffictypediagnostic: HE1PR07MB1642: x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008)(18271650672692)(21748063052155)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1642; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1642; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(39400400002)(377454003)(51914003)(37854004)(189002)(199003)(68736007)(2906002)(229853002)(99286003)(54906002)(8666007)(9326002)(55016002)(7736002)(478600001)(97736004)(6506006)(4326008)(54896002)(6306002)(189998001)(9686003)(8936002)(236005)(50986999)(2950100002)(2900100001)(25786009)(53946003)(54356999)(76176999)(5890100001)(53546010)(101416001)(5250100002)(38730400002)(53376002)(53366004)(14454004)(105586002)(86362001)(66066001)(790700001)(3660700001)(3846002)(1941001)(561944003)(6116002)(102836003)(230783001)(606006)(2501003)(3280700002)(33656002)(74316002)(8676002)(93886004)(6246003)(966005)(6436002)(81156014)(81166006)(106356001)(5660300001)(53936002)(7696004)(493534005)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB1642; H:HE1PR07MB1708.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=sikhivahan.gundu@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB1708B04E7BFFF20F6FF7F008EA8B0HE1PR07MB1708eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 10:18:50.7143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1642 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+c45286kwddSfNOUGBqipSUpI0PtD2UQgWiESqhDTypOZztm ahmidpsKSaSo1bSmYl4CEzVL84YiKdOsBEHyVt7FvKR5q52dCf7343me93svfDQpbRXY0LEJ SYwmQamSCS2oouAmqzN5E9qQsw2LHvKtt37y6sJNJB9c3CHlG60TAl9Kodf/JRQjmd9Eiuxf fULF+vCaMIAKtbgYxahikxmNm3eERcx8VyOZuNhGpUzo8okMNLlHapGYBnweytcHCC2yoKW4 G0F2YTHBGVLci2A1K5gzKJxHwv5KnZBPFRDwPWPUXDKJoLusFXElQuwJu2PlpnJLHAfre90U xyROhYH2eVPmGA6EjYaXRqaNmSB4bEjh4/4wvbVrkinsAMu6EE6W4Ouws1FN8q2qSFjfbhJx hhg/QrDSfI9jhO1gs27f3MoaRqd1BL8aBv1Hg3lNK5ib2hfwLIN3RbPmjB180eUgrgHgByIY r5xDvHEFFmpmKd6YJGBzoJLkpgPsDIYWMY/p8DNXzsfj4LfhM8nHhwWwvdUg4o0TMNs1YH6n WQQ9D8tJ/r4MVNbeR0+QS/GhwXlWw/w/Ayo2XeAo9BVNU7x+Gko/rAp5doGKsgXygPvbp4jD eikSvUFWLMOy8dHu7q6MJjaSZdUJrglMUj0yfqqOhp0Lzahj5lInwjSSHZFc7teGSAXKZDY1 vhMBTcosJceNf04qiVKmpjEadbjmlophO5EtTcmsJb5tg8FSHK1MYuIYJpHRHLgELbbJQDZx VWIfu4D3VTl+9id7w9Sq5Xrv7JGlG5LGioKStSGhbvzrCwcfP2mt/6pXyli6BGe9DttP779T 3NcS5Ki6Zn8qP9x5SJ0bMedm/4OhZmdkr5oDrZ0dn4Xqt3N6NK5ef9jbVyOXnDw/tT1dth1M 63SILvG4+bzlbk1v5oRTrjZNRrExynPOpIZV/gcqEQzVUAMAAA== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:19:08 -0000 --_000_HE1PR07MB1708B04E7BFFF20F6FF7F008EA8B0HE1PR07MB1708eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Requesting a couple of clarifications. >> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped Do we stop the timer if "new convergence" is a result only of links coming up, i.e, no links have failed? My interpretation of the old text, as well= as the revision, is that we don't, but in the light of the discussion that this pa= ssage triggered, it seems better to have the interpretation validated, as below: Imagining the IGP router to be in one of two states: -- NORMAL-UPDATE state (FIB updated "normally"), also the initial state, -- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of t= ime), the draft seems to suggest the following state transitions. I'd greatly app= reciate validation. ---------------------------+-----------------------------------------------= -------+-------------------------+ current state | event = | next state | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | DELAYED-UPDATE | ---------------------------+ one local link failure = +-------------------------+ DELAYED-UPDATE | = | NORMAL-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | one remote link failure | = | ---------------------------+ OR = | NORMAL-UPDATE | DELAYED-UPDATE | two or more (any kind of) link failures | = | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | NORMAL-UPDATE | ---------------------------+ no link failures (only link-up's) = +--------------------------+ DELAYED-UPDATE | = | DELAYED-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ Second: remote loops are illustrated as a non-applicable scenario for this solution. How about local link failures that do not lead to (local) loops? Applying the delay in such a case may result in packet loss if there is no FRR backup. OTOH, detecting that a local loop will form involves more computation. Thanks, Sikhi From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of stephane.litkowski= @orange.com Sent: 08 August 2017 20:50 To: Chris Bowers Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Thanks Chris, I will post a new revision with those changes. From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 16:05 To: LITKOWSKI Stephane OBS/OINIS Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Stephane, See responses inline with [CB]. Chris From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 8, 2017 8:25 AM To: Chris Bowers > Cc: RTGWG >; draft-ietf-rtgwg-uloop-d= elay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? [CB] You are correct. That proposed change is a mistake on my part. - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." [CB] "when the primary path is an hop by hop defined path" is somewhat amb= iguous. How about "when the primary path uses hop-by-hop routing" ? For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. [CB] OK. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." [CB] This text seems clearer. Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.tx= t Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has no= t been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR= . =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_HE1PR07MB1708B04E7BFFF20F6FF7F008EA8B0HE1PR07MB1708eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 =

Requesting a couple of c= larifications.

 

>> If a new convergence occurs while ULOO= P_DELAY_DOWN_TIMER is running, ULOOP_DELAY_DOWN_TIMER is stopped

 

Do we stop the timer if =  “new convergence” is a result only of links coming

up, i.e, no links have f= ailed?  My interpretation of the old text,  as well as the

revision, is that we don= ’t, but in the light of the discussion that this passage

triggered, it seems bett= er to have the interpretation validated, as below:

Imagining the IGP router= to be in one of two states:

-- NORMAL-UPDATE state (= FIB updated “normally”), also the initial state,

-- and DELAYED-UPDATE st= ate (FIB updated after ULOOP_DELAY_TIMER units of time),

   <= /o:p>

the draft seems to sugge= st the following state transitions. I’d greatly appreciate=

validation.

 

---------------------------+-----------------= -------------------------------------+-------------------------+

     current state  = ;      |       =             &nb= sp;            =   event          &nb= sp;             = ;     |        =  next state      |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      | DELAYED-UPDATE |

---------------------------+   = ;             &= nbsp; one local link failure       =            +---------= ----------------+         =        

DELAYED-UPDATE    |  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =        | NORMAL-UPDATE |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;            &= nbsp;  one remote link failure      &nbs= p;      |       &nbs= p;            &= nbsp;           &nbs= p;  |

---------------------------+   = ;            &n= bsp;            &nbs= p;       OR     = ;            &n= bsp;            = ; | NORMAL-UPDATE |

DELAYED-UPDATE    |  two or m= ore (any kind of) link failures   |     =             &nb= sp;            =     |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;             =             &nb= sp;            =             &nb= sp;            =       | NORMAL-UPDATE |

---------------------------+   &nbs= p;       no link failures (only link-up'= s)       +--------------------------+=

DELAYED-UPDATE    |  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =        | DELAYED-UPDATE |

---------------------------+-----------------= -------------------------------------+-------------------------+

 

Second: remote loops are illustrated as a non-app= licable scenario for this

solution. How about local link failures that do n= ot lead to (local) loops?

Applying the delay in such a case may result in p= acket loss if there is no

FRR backup.  OTOH, detecting that a local lo= op will form  involves more

computation.   

 

Thanks,

Sikhi

 =

 =

From: = rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: 08 August 2017 20:50
To: Chris Bowers <cbowers@juniper.net>
Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG <rtgwg@iet= f.org>
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Thanks Chris, I will p= ost a new revision with those changes.

 

 

From: Ch= ris Bowers [mailto:cbowers@juniper.n= et]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Stephane,

 

See responses inline w= ith [CB].

 

Chris

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers <cbowers@= juniper.net>
Cc: RTGWG <rtgwg@ietf.org&g= t;; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi Chris,

 

Thanks for the review.= I’m updating the document to reflect your proposals.

Couple of comments:

-          s/“otherwise the standard IP con= vergence MUST be used.”/ “otherwise the standard IP convergence= MUST used”. It does not sound good to me but may be because of an English grammar issue on my side. Could you confirm the change ?

 

[CB]  You are cor= rect.  That proposed change is a mistake on my part.=

 

-          Regarding your main comment on section= 1 and 2.1, I do not agree about your statement on RSVP-FRR. First there ar= e multiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO= )

Your statement is true only for the third case where an RSVP tunnel = between S and D exists with its path computed by S =3D> no uloop in that case for sure. But as soon as you rely on distrib= uted convergence, you will fall into a loop even if you use RSVP-FRR. I wil= l precise in the text that we are in an LDP scenario for example. Here is a= text proposal:

“In the Figure 2, we consider an IP/LDP routed network. An RSV= P-TE tunnel T, provisioned on C and terminating on B, is used to protect the traffic against C-B link failure (IGP shortcut is acti= vated on C).”

“The issue described here is completely independent of the fas= t-reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop by hop defined path.”

 

 

[CB] “when the p= rimary path is an hop by hop defined path”  is somewhat ambiguou= s.

How about “when = the primary path uses hop-by-hop routing” ?

 

 

For the LFA case, yes, there are some cases where there is no loop, = but it is topology dependent. I’m not sure that we need to give such precision as if the LFA is on the postconvergence path, = this means that the postconvergence is loopfree, so there will be no local = microloop in any case.

 

[CB]  OK. 

 

-          Regarding your comment on section 4.4,= here is my new text proposal to fit your comment:

           &n= bsp;           

“Upon an adjacency/link down event, this document introduces a= change

   in step 5 (<xref target=3D"description-current&= quot;/>) in order to delay the local convergence compared to the

   network wide convergence. The new step 5 is described b= elow:”

           5. Upon= SPF_DELAY timer expiration, the SPF is computed. If the condition of a sin= gle local link-down event has been met and if the new convergence did not trigger a stop of the ULOO= P_DELAY_DOWN_TIMER , then an update of the RIB and the FIB SHOULD be delaye= d for ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be up= dated immediately.

 

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running,= ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”<= /span>

 

[CB]  This text s= eems clearer.

 

Brgds,

 

Stephane

 

 

From: Ch= ris Bowers [mailto:cbowers@juniper.n= et]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing th= e Shepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the= document, I wrote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to c= larifying language and typos.  However there

are few comments that I think are mo= re substantive so I am

reproducing them below since they sh= ould probably discussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[CB]  I find the examples prese= nted in section 1 and section 2.1 to

be confusing.  The conclusion d= rawn in the last paragraph of section

2.1 does not seem to follow from the= se examples.

 

Section 1 (figure 1) shows an exampl= e of micro-loops occuring when shortest

path forwarding is used and the metr= ics are such that LFA and rLFA

produce no backup paths from the PLR= . 

 

Section 2.1 (figure 2) also shows an= example of micro-loops occuring when

shortest path forwarding is used and= the metrics are such that LFA and rLFA

produce no backup paths from the PLR= .  However, in this example,

a one-hop RSVP tunnel is provisioned= to provide link protection for one of

the links.  However, even with = this one-hop RSVP tunnel the example

demonstrates that micro-loops can oc= cur.

 

The last paragraph asserts that:

"The issue described here is co= mpletely independent of the fast-

reroute mechanism involved (TE FRR, = LFA/rLFA, MRT ...)."

 

There are two problems with this ass= ertion.

 

Problem 1) I don't think that the as= sertion is correct for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there wou= ld be an RSVP-signaled LSP from S to D. 

Before the failure of the link C-B, = this LSP would follow the path

S-E-C-B-A-D.  Immediately after= the failure of link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D usin= g the bypass LSP at C.  Once S is

made aware of the failure.  S w= ill resignal the LSP to take the path S-E-A-D. 

At no time would looping occur. = ;

 

I assume that it wasn't the initial = intention to claim that RSVP TE-FRR suffers from

micro-looping, but the text currentl= y reads that way.  The assertion of the last

paragraph should be qualified to tal= k about how microloops will still affect traffic

forwarded hop-by-hop over links prot= ected with one-hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be corr= ect for LFA/rLFA and MRT, but it has not

been demonstrated with the examples = provided.  I think it may instead be

the case that the assertion nay not = be true for local LFA in some circumstances.

In particular, if traffic to a given= destination can be protected for a given

failure by the PLR using a local LFA= that is the same as the post convergence

path, then that traffic will not be = subject to microloops.

 

Perhaps the overall intention of the= example in figure 2 using

links protected with one-hop RSVP-si= gnaled LSPs was to say that no

matter how much flexibility you give= yourself in building a backup path

from the PLR, if the PLR stops using= the backup path before other routers

stop sending traffic to the PLR, the= n you can still have forwarding loops.

However, I think the complexity and = detail of the example using one-hop

RSVP-signaled LSPs ends up confusing= the matter.

 

The text should either work more sys= tematically through examples to

substantiate the assertion, or the a= ssertion should be scaled back. 

Regardless, the assertion needs to b= e clarified with respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write= out exactly what the modified version of step 5

looks like so there is no confusion.= Something like:

 

5.  Upon SPF_DELAY timer expira= tion, the SPF is computed.  If the condition

of a single local link-down event ha= ve been met, then an update of the

RIB and the FIB is scheduled in ULOO= P_DELAY_DOWN_TIMER msecs.  Otherwise,

the RIB and FIB update is scheduled = immediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

   Such a delay=

   SHOULD only be introduc= ed if all the LSDB modifications processed are

   only reporting a single= local link down event (Section 4.3).  If a

   subsequent LSP/LSA is r= eceived/updated and a new SPF computation is

   triggered before the ex= piration of ULOOP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD = be performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D &nb= sp;

[CB] What should one do if the evalu= ation of a subsequent LSP/LSA fails

at this point?  Do you go ahead= and update the FIB with the forwarding

entries that you were waiting to do?=   Or do you do a new SPF with the

new information?  Or is it up t= o the implementation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I also ran the idnits check which sh= ow  the following issues.

Can you get rid of the unused refere= nces and move RFC 5715 from Normative to informational so that idnits will = run clean? 

 

 

Thanks,

Chris

 

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_HE1PR07MB1708B04E7BFFF20F6FF7F008EA8B0HE1PR07MB1708eurp_-- From nobody Wed Aug 9 04:37:37 2017 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 5A0B8132153 for ; Wed, 9 Aug 2017 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e69Avjj2Xmf5 for ; Wed, 9 Aug 2017 04:37:32 -0700 (PDT) Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6074F131D32 for ; Wed, 9 Aug 2017 04:37:31 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 7CAE0C07B1; Wed, 9 Aug 2017 13:37:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 427651C0066; Wed, 9 Aug 2017 13:37:29 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Wed, 9 Aug 2017 13:37:28 +0200 From: To: Sikhivahan Gundu , Chris Bowers CC: "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" , RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieAAAJIxSAAA2K9IAAe/WLAAAtG12A= Date: Wed, 9 Aug 2017 11:37:28 +0000 Message-ID: <4324_1502278649_598AF3F9_4324_398_1_9E32478DFA9976438E7A22F69B08FF921EA1819D@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <21996_1502205616_5989D6B0_21996_381_1_9E32478DFA9976438E7A22F69B08FF921EA08B2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EA1819DOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 11:37:36 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921EA1819DOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your feedback, please find some comments inline. Brgds, Stephane From: Sikhivahan Gundu [mailto:sikhivahan.gundu@ericsson.com] Sent: Wednesday, August 09, 2017 12:19 To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi, Requesting a couple of clarifications. >> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped Do we stop the timer if "new convergence" is a result only of links coming up, i.e, no links have failed? My interpretation of the old text, as well= as the revision, is that we don't, but in the light of the discussion that this pa= ssage triggered, it seems better to have the interpretation validated, as below: [SLI] Let's that you have a convergence triggered by a local link down, thi= s convergence will apply the ULOOP_DELAY_DOWN_TIMER. If during the timer run, a new topology change occurs (metric change, link = up or down whatever it is local or remote), we need to update the FIB witho= ut anymore delaying with the latest topology. If we do not do so, the local router will use an N-2 FIB version while the = other routers will start to use the latest version N this could cause side = effects. Imagining the IGP router to be in one of two states: -- NORMAL-UPDATE state (FIB updated "normally"), also the initial state, -- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of t= ime), the draft seems to suggest the following state transitions. I'd greatly app= reciate validation. ---------------------------+-----------------------------------------------= -------+-------------------------+ current state | event = | next state | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | DELAYED-UPDATE | ---------------------------+ one local link failure = +-------------------------+ DELAYED-UPDATE | = | NORMAL-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | one remote link failure | = | ---------------------------+ OR = | NORMAL-UPDATE | DELAYED-UPDATE | two or more (any kind of) link failures | = | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | NORMAL-UPDATE | ---------------------------+ no link failures (only link-up's) = +--------------------------+ DELAYED-UPDATE | = | DELAYED-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ [SLI] The last line should be current state DELAYED-UPDATE , next state NOR= MAL-UPDATE. Second: remote loops are illustrated as a non-applicable scenario for this solution. How about local link failures that do not lead to (local) loops? Applying the delay in such a case may result in packet loss if there is no FRR backup. OTOH, detecting that a local loop will form involves more computation. [SLI] I agree with you, that's why the draft encourages to use the mechanis= m in combination with FRR. The draft does not prevent an implementation to = detect if a loop exists or not before applying the mechanism. Thanks, Sikhi From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of stephane.litkowski= @orange.com Sent: 08 August 2017 20:50 To: Chris Bowers > Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG > Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Thanks Chris, I will post a new revision with those changes. From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 16:05 To: LITKOWSKI Stephane OBS/OINIS Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Stephane, See responses inline with [CB]. Chris From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 8, 2017 8:25 AM To: Chris Bowers > Cc: RTGWG >; draft-ietf-rtgwg-uloop-d= elay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? [CB] You are correct. That proposed change is a mistake on my part. - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." [CB] "when the primary path is an hop by hop defined path" is somewhat amb= iguous. How about "when the primary path uses hop-by-hop routing" ? For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. [CB] OK. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." [CB] This text seems clearer. Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has not been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR. =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921EA1819DOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Thanks for your feedback,= please find some comments inline.

 <= /p>

Brgds,<= /p>

 <= /p>

Stephane

 <= /p>

 <= /p>

From: Sikhivah= an Gundu [mailto:sikhivahan.gundu@ericsson.com]
Sent: Wednesday, August 09, 2017 12:19
To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers
Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi,

 =

Requesting a couple of c= larifications.

 

>> If a new convergence occurs while ULOOP_D= ELAY_DOWN_TIMER is running, ULOOP_DELAY_DOWN_TIMER is stopped

 

Do we stop the timer if =  “new convergence” is a result only of links coming

up, i.e, no links have f= ailed?  My interpretation of the old text,  as well as the

revision, is that we don= ’t, but in the light of the discussion that this passage

triggered, it seems bett= er to have the interpretation validated, as below:

 = ;

[SLI] Let&= #8217;s that you have a convergence triggered by a local link down, this co= nvergence will apply the ULOOP_DELAY_DOWN_TIMER.

If during = the timer run, a new topology change occurs (metric change, link up or down= whatever it is local or remote), we need to update the FIB without anymore delaying with the latest topology.

If we do n= ot do so, the local router will use an N-2 FIB version while the other rout= ers will start to use the latest version N this could cause side effects.

 = ;

 = ;

Imagining the IGP router= to be in one of two states:

-- NORMAL-UPDATE state (= FIB updated “normally”), also the initial state,

-- and DELAYED-UPDATE st= ate (FIB updated after ULOOP_DELAY_TIMER units of time),

   <= /o:p>

the draft seems to sugge= st the following state transitions. I’d greatly appreciate=

validation.

 

---------------------------&= #43;------------------------------------------------------+------------= -------------+

     cur= rent state        |   &nb= sp;            =             &nb= sp;     event       =              &n= bsp;        |    &nb= sp;    next state      |<= /o:p>

---------------------------&= #43;------------------------------------------------------+------------= -------------+

NORMAL-UPDATE  &nb= sp; |           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          | DELAYED-UPDATE |=

---------------------------&= #43;            = ;      one local link failure   &nb= sp;            =   +-------------------------+     &nb= sp;          

DELAYED-UPDATE  &n= bsp; |           &nb= sp;            =             &nb= sp;            =             &nb= sp;          | NORMAL-UPDATE |=

---------------------------&= #43;------------------------------------------------------+------------= -------------+

NORMAL-UPDATE  &nb= sp; |           &nbs= p;      one remote link failure   &= nbsp;         |    &= nbsp;           &nbs= p;            &= nbsp;     |

---------------------------&= #43;            = ;             &= nbsp;          OR &n= bsp;            = ;            &n= bsp;    | NORMAL-UPDATE |

DELAYED-UPDATE  &n= bsp; |  two or more (any kind of) link failures   | &nb= sp;            =             &nb= sp;       |

---------------------------&= #43;------------------------------------------------------+------------= -------------+

NORMAL-UPDATE  &nb= sp; |           &nbs= p;             =             &nb= sp;            =             &nb= sp;         | NORMAL-UPDATE |<= o:p>

---------------------------&= #43;           no link fa= ilures (only link-up's)       +----------= ----------------+

DELAYED-UPDATE  &n= bsp; |           &nb= sp;            =             &nb= sp;            =             &nb= sp;          | DELAYED-UPDATE = |

---------------------------&= #43;------------------------------------------------------+------------= -------------+

 

[SLI= ] The last line should be current state DELAYED-UPDATE , next state NORMAL-= UPDATE.

 

 

Second: remote loops are ill= ustrated as a non-applicable scenario for this

solution. How about local li= nk failures that do not lead to (local) loops?

Applying the delay in such a= case may result in packet loss if there is no

FRR backup.  OTOH, dete= cting that a local loop will form  involves more

computation.   

 

[SLI= ] I agree with you, that’s why the draft encourages to use the mechan= ism in combination with FRR. The draft does not prevent an implementation t= o detect if a loop exists or not before applying the mechanism.

 

 

Thanks,

Sikhi

 =

 =

From: rtgwg = [mailto:rtgwg-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 08 August 2017 20:50
To: Chris Bowers <cbowers@= juniper.net>
Cc: d= raft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG <rtgwg@ietf.org>
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Thanks Chris, I will post= a new revision with those changes.

 <= /p>

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Stephane,

 <= /p>

See responses inline with= [CB].

 <= /p>

Chris

 <= /p>

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers <cbowers@= juniper.net>
Cc: RTGWG <rtgwg@ietf.org&g= t;; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi Chris,

 <= /p>

Thanks for the review. I&= #8217;m updating the document to reflect your proposals.<= /p>

Couple of comments:<= /o:p>

- &nbs= p;        s/“otherwise the standard IP conver= gence MUST be used.”/ “otherwise the standard IP convergence MU= ST used”. It does not sound good to me but may be because of an Engli= sh grammar issue on my side. Could you confirm the change ?=

 <= /p>

[CB]  You are correc= t.  That proposed change is a mistake on my part.

 <= /span>

- &nbs= p;        Regarding your main comment on section 1 = and 2.1, I do not agree about your statement on RSVP-FRR. First there are m= ultiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO=

o   RSVP with CSPF at head end (strict ERO)

 <= /p>

 <= /p>

[CB] “when the prim= ary path is an hop by hop defined path”  is somewhat ambiguous.<= o:p>

How about “when the= primary path uses hop-by-hop routing” ?

 <= /p>

[CB]  OK. 

- &nbs= p;        Regarding your comment on section 4.4, he= re is my new text proposal to fit your comment:

            =            

“Upon an adjacency/link down event, this document introduces a cha= nge

   in step 5 (<xref target=3D"description-current"= ;/>) in order to delay the local convergence compared to the<= /span>

   network wide convergence. The new step 5 is described below= :”

           5. Upon SPF= _DELAY timer expiration, the SPF is computed. If the condition of a single = local link-down event has been met and if the new convergence did not trigger a stop of the ULOOP_DELAY_DOWN_= TIMER , then an update of the RIB and the FIB SHOULD be delayed for ULOOP_D= ELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immedia= tely.

 

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”

 <= /p>

[CB]  This text seem= s clearer.

 <= /p>

Brgds,<= /p>

 <= /p>

Stephane

 <= /p>

 <= /p>

From: Chris Bo= wers [mailto:cbowers@juniper.net]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing the S= hepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the do= cument, I wrote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to clar= ifying language and typos.  However there

are few comments that I think are more = substantive so I am

reproducing them below since they shoul= d probably discussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

[CB]  I find the examples presente= d in section 1 and section 2.1 to

be confusing.  The conclusion draw= n in the last paragraph of section

2.1 does not seem to follow from these = examples.

 

Section 1 (figure 1) shows an example o= f micro-loops occuring when shortest

path forwarding is used and the metrics= are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp;

 

Section 2.1 (figure 2) also shows an ex= ample of micro-loops occuring when

shortest path forwarding is used and th= e metrics are such that LFA and rLFA

produce no backup paths from the PLR.&n= bsp; However, in this example,

a one-hop RSVP tunnel is provisioned to= provide link protection for one of

the links.  However, even with thi= s one-hop RSVP tunnel the example

demonstrates that micro-loops can occur= .

 

The last paragraph asserts that:

"The issue described here is compl= etely independent of the fast-

reroute mechanism involved (TE FRR, LFA= /rLFA, MRT ...)."

 

There are two problems with this assert= ion.

 

Problem 1) I don't think that the asser= tion is correct for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there would = be an RSVP-signaled LSP from S to D. 

Before the failure of the link C-B, thi= s LSP would follow the path

S-E-C-B-A-D.  Immediately after th= e failure of link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D using t= he bypass LSP at C.  Once S is

made aware of the failure.  S will= resignal the LSP to take the path S-E-A-D. 

At no time would looping occur. 

 

I assume that it wasn't the initial int= ention to claim that RSVP TE-FRR suffers from

micro-looping, but the text currently r= eads that way.  The assertion of the last

paragraph should be qualified to talk a= bout how microloops will still affect traffic

forwarded hop-by-hop over links protect= ed with one-hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be correct= for LFA/rLFA and MRT, but it has not

been demonstrated with the examples pro= vided.  I think it may instead be

the case that the assertion nay not be = true for local LFA in some circumstances.

In particular, if traffic to a given de= stination can be protected for a given

failure by the PLR using a local LFA th= at is the same as the post convergence

path, then that traffic will not be sub= ject to microloops.

 

Perhaps the overall intention of the ex= ample in figure 2 using

links protected with one-hop RSVP-signa= led LSPs was to say that no

matter how much flexibility you give yo= urself in building a backup path

from the PLR, if the PLR stops using th= e backup path before other routers

stop sending traffic to the PLR, then y= ou can still have forwarding loops.

However, I think the complexity and det= ail of the example using one-hop

RSVP-signaled LSPs ends up confusing th= e matter.

 

The text should either work more system= atically through examples to

substantiate the assertion, or the asse= rtion should be scaled back. 

Regardless, the assertion needs to be c= larified with respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write ou= t exactly what the modified version of step 5

looks like so there is no confusion. So= mething like:

 

5.  Upon SPF_DELAY timer expiratio= n, the SPF is computed.  If the condition

of a single local link-down event have = been met, then an update of the

RIB and the FIB is scheduled in ULOOP_D= ELAY_DOWN_TIMER msecs.  Otherwise,

the RIB and FIB update is scheduled imm= ediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

   Such a delay

   SHOULD only be introduced = if all the LSDB modifications processed are

   only reporting a single lo= cal link down event (Section 4.3).  If a

   subsequent LSP/LSA is rece= ived/updated and a new SPF computation is

   triggered before the expir= ation of ULOOP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD be = performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D  

[CB] What should one do if the evaluati= on of a subsequent LSP/LSA fails

at this point?  Do you go ahead an= d update the FIB with the forwarding

entries that you were waiting to do?&nb= sp; Or do you do a new SPF with the

new information?  Or is it up to t= he implementation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

I also ran the idnits check which show&= nbsp; the following issues.

Can you get rid of the unused reference= s and move RFC 5715 from Normative to informational so that idnits will run= clean? 

 

 

Thanks,

Chris

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921EA1819DOPEXCLILMA4corp_-- From nobody Wed Aug 9 15:03:54 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 819721323C6; Wed, 9 Aug 2017 15:03:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The RTGWG WG has placed draft-bryant-rtgwg-param-sync in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150231623252.11867.14248050155693004672.idtracker@ietfa.amsl.com> Date: Wed, 09 Aug 2017 15:03:52 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:03:53 -0000 The RTGWG WG has placed draft-bryant-rtgwg-param-sync in state Call For Adoption By WG Issued (entered by Jeff Tantsura) The document is available at https://datatracker.ietf.org/doc/draft-bryant-rtgwg-param-sync/ From nobody Wed Aug 9 15:12:11 2017 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 E4C1613228D for ; Wed, 9 Aug 2017 15:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e24S6j2FZiD8 for ; Wed, 9 Aug 2017 15:12:08 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110CA132195 for ; Wed, 9 Aug 2017 15:12:08 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v189so33312587pgd.2 for ; Wed, 09 Aug 2017 15:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=dVll2qHsNODW/M7CamT2ge7DCOaazO358w7TqrToKxE=; b=dfxsJcAn8xBIpBKS/t8UM0uAiWN0IUtmjXOnhhy1c/0fvmX6+jDUU85ZZ3r0ZtQxL1 oj6SE6XeOeMQ0RBo5O30nuFCgIpaSnXoEnIa/WbKtEM2lOEngoJGWprw6tgbX7ADcI7C 1guN1f5lSlPKZ20zun4xzj2dKm8KaGyrDi2r81BgymjpDVidpsCCTG1CDlpnqC1O0Qou nuAw55JJAjTzcG1ptqljKhneI1MlXBPCKRlWb+X3iM/fk7MmNSg0dgikdK8/XvgA8ouo doomDPUMJIsM2Ryo1p9YphV4ofLlKTECgrpsk/rcn5Co5+cpF2WlUWwza5tSp0o+rtVV h5KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=dVll2qHsNODW/M7CamT2ge7DCOaazO358w7TqrToKxE=; b=FQsjvG2RrMKq4Ri8BZYP5PLPA+GxirLyJbb63yngRMo1wFINmdjbksEp+dQgCm07wL ZRN9RAPj5+h/jFvROYQMZjGtt//8jc2eAc4EuLX3V8RxPAdYftK8efNbdVXbjxJYxjvN GRWJdYq/bDNh7szsghnY8zlSptKdWK6JuyRVD66PECmr+NYv19EQXTKVjoOfS8lzDWYM QePb9IyOh3NUEsRZ5yAEajWBreW6HjldyjRNAIf57QeXLk24/6YRcaQGnXQ76ZWCWBN7 zgCR3Au7wO+GPcxfFmo0z5t9cZqhcBLB3TtzT3SBa8F8d89CySu+KwEXXiZw+Nn4+ed7 7bEQ== X-Gm-Message-State: AHYfb5iuLwAEAkiEQfojxVN1ufV+iOpCLTeoSnCALdHqZx9/WNpqoB+l uPh++6xHELaUj+Ce X-Received: by 10.84.217.220 with SMTP id d28mr10856566plj.340.1502316727271; Wed, 09 Aug 2017 15:12:07 -0700 (PDT) Received: from [192.168.254.68] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.75]) by smtp.gmail.com with ESMTPSA id q5sm8811885pgn.21.2017.08.09.15.12.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 15:12:06 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.24.1.170721 Date: Wed, 09 Aug 2017 15:12:05 -0700 Subject: RTGWG minutes IETF99 From: Jeff Tantsura To: RTGWG CC: rtgwg-chairs Message-ID: <12515254-D4A6-40A0-A3EE-4AF50330FAC0@gmail.com> Thread-Topic: RTGWG minutes IETF99 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 22:12:10 -0000 RTGWG, The minutes have been published at: https://datatracker.ietf.org/meeting/99/materials/minutes-99-rtgwg Please provide your comments. Thanks! Jeff & Chris From nobody Thu Aug 10 01:00:36 2017 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 A2B85132643 for ; Thu, 10 Aug 2017 01:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b_2PH6RAx6h for ; Thu, 10 Aug 2017 01:00:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511C3132640 for ; Thu, 10 Aug 2017 01:00:21 -0700 (PDT) X-AuditID: c1b4fb25-9d2719c000001eeb-1d-598c1293988f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.A2.07915.3921C895; Thu, 10 Aug 2017 10:00:20 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 10 Aug 2017 10:00:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ArsBWzfv74K6vFW1BY6iaimRnwcihRFKZEt7aFlzUEA=; b=UU/VQWiB3Cg5JlX2M82QAUr0DOeCHB+gg2so65XNo+2EBAYEQq+i6EsXKB889r22GCmz75d8Vv2UCHfRN4S7LZ0J69z6bEZEtsGzsPhsYYSVECLnQDEfSazAZKXHG5VBumCnldf57b1g1wFt6Rjvxf1jfYHAbwdHUcXO+jrA1bw= Received: from VI1PR07MB1709.eurprd07.prod.outlook.com (10.166.143.17) by VI1PR07MB3181.eurprd07.prod.outlook.com (10.175.243.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Thu, 10 Aug 2017 07:59:59 +0000 Received: from VI1PR07MB1709.eurprd07.prod.outlook.com ([fe80::f8c4:2d65:c44e:5866]) by VI1PR07MB1709.eurprd07.prod.outlook.com ([fe80::f8c4:2d65:c44e:5866%14]) with mapi id 15.01.1341.013; Thu, 10 Aug 2017 07:59:59 +0000 From: Sikhivahan Gundu To: "stephane.litkowski@orange.com" , "Chris Bowers" CC: "draft-ietf-rtgwg-uloop-delay@tools.ietf.org" , RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Topic: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt Thread-Index: AdMP3yX5N8zZ03GxRHi9+6FucgpQ/wAY/ieAAAJIxSAAA2K9IAAe/WLAAAtG12AAIt6E8A== Date: Thu, 10 Aug 2017 07:59:59 +0000 Message-ID: References: <9941_1502198679_5989BB97_9941_419_1_9E32478DFA9976438E7A22F69B08FF921EA08A36@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <21996_1502205616_5989D6B0_21996_381_1_9E32478DFA9976438E7A22F69B08FF921EA08B2F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4324_1502278649_598AF3F9_4324_398_1_9E32478DFA9976438E7A22F69B08FF921EA1819D@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <4324_1502278649_598AF3F9_4324_398_1_9E32478DFA9976438E7A22F69B08FF921EA1819D@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sikhivahan.gundu@ericsson.com; x-originating-ip: [125.16.128.122] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3181; 6:pLGOYk6DNbIPoBTmKX6MmVcdbp37f77EpJul0p/gNgG43XtIX3CuBVO9HNTlKNJ0JADN8j+IUm7J23AGsisBTYwFU5et0wQVaTuuwWt5irAIL8gN+yUluZyPV7z9Wty8Sry0p0SblTy5nJcXpFD/ZoGQWc3nMD4wIkBZyzaLpTxAN3/L2iZkYI0bpY/XZq9vTcu7ulM+e0IwRcgPO7ymgD5QnnZSdX7rVtvAx74zPDVWfuym4EMTRed/JqpYroKG4NoVBjCctolWHG81gaAJp7HL6u5Id+0A+DWOgKjh/ZKjdMSbMtuT9fZhceDhc9y1bJgmsqGt2W9HF1RsF2hQuQ==; 5:iOK9JqRnTmc5EEblabviZGex7YAoxLlHDbZqnFDJf2yED4FD0cUR8ZjCxyrHnKotK8IW1Yx63/etcQmFhbOyyTanQ7VqgXHyj0jbBlN0Ysu/SjxpI8LZX+4kQ+nZ7Vo3RJLCZYimdZ3kJXi5RBD4GQ==; 24:eshbxwsxlg6DGnATDsF0YNrmx3vwIk5Pjp2YqOyviaRIS/vmaB6GL+ej8RZiqtJUHFwZ+XopsWdq3xzP5oeB7L6+sRNWmUepYjiupEKZUJE=; 7:H19ZABhlwH4tL8jdY1m6BIt36U7a3eXXzGusPImTG4aN8Lgk226qsQT4CWK+whfy4ukul54BoCZuLmscrw8FuD00z26L9ErhJEGwyM91GLi5E2v+EEuDOauUsWLupywuoI+cP93lIVqwqcB6LJ/24Sf1ORorqRvXAsGolf8lZsF2xxsydIQu2f3XwdXvTb4S3DgqdkCFxEFNSXJE9mQp0PidlHxoEUgytrIOxW0cH7c= x-ms-office365-filtering-correlation-id: 3bcf45c9-bb17-46f6-91ba-08d4dfc5cc5d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR07MB3181; x-ms-traffictypediagnostic: VI1PR07MB3181: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(138986009662008)(18271650672692)(21748063052155)(211171220733660); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3181; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3181; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39850400002)(39450400003)(39410400002)(39400400002)(39860400002)(189002)(37854004)(51914003)(377454003)(199003)(478600001)(790700001)(97736004)(53376002)(102836003)(86362001)(68736007)(230783001)(2501003)(229853002)(3846002)(6116002)(8676002)(8666007)(74316002)(1941001)(7696004)(3660700001)(38730400002)(81156014)(2950100002)(81166006)(53366004)(6436002)(5660300001)(5890100001)(189998001)(6246003)(8936002)(53936002)(25786009)(2906002)(101416001)(9326002)(50986999)(54356999)(105586002)(5250100002)(3280700002)(6506006)(4326008)(236005)(54896002)(54906002)(14454004)(7736002)(6306002)(606006)(93886004)(66066001)(55016002)(966005)(53946003)(33656002)(99286003)(106356001)(561944003)(76176999)(2900100001)(16200700003)(53546010)(9686003)(493534005)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3181; H:VI1PR07MB1709.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1709736191F032C7170E722AEA880VI1PR07MB1709eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2017 07:59:59.5380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3181 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbv3a7TyW0qnnwpWgihZWaW+yCSVLAvQSTka+TSyxR12p2a L2RipuaUSehMJV1hGQoGTdPIxKamK23DJYZRvs3K0iRfUNFpujvBb//z//3POQ+Hh8SEOsKN TJCn0YxcmiTi8vHq8PawExXC0gi/8UpH8dqLi+LmqlUkNs5tYOKVt5PEOVzS0LDOkYzmj/Ak BT/0XMmyaYl7GY/kB8XRSQkZNHMyOIYf/1D1EUtt6yQyu+qz81D/PF6C7EigAmBY1cQrQXxS SPUiqPh5F2OLAQQTLeVWglNlGIwvVeIsUXNAtfmeYItpBNsVX63DuNRZ2Pz2lLOrnalEWLb0 Wn2MyoKh7t9oVztRV2CltW5HkzuZULhvyGTjV6HA2GiN45QXfJiqt44RUNGgXO/ksrvWcKj+ PGot7KhCBBrtJ2I3hShPWG3Zsi1zhTEz2w0UBQ2dBozVLjA7vWXLx0CRoQCxvgi01b9seU8Y rlei3QVAFfJg0VhhO9Ml0NSX4yyY4oByYZRggTf0DIzYOsoQ1NZM2kAi9BQtcVhgIkBVq+Kx wAO0C49so4Z4cM9cjJcjn5p9b2d1Chgbx1CN9QoHQF9txln/OGjeLHJZ7QPPHv/B9vRg9zRn v69BvCbkoqAVN5Jl/qd9aSYhVqFIkfvK6bSXaOdnvWvd8OpAprkQHaJIJHIQqOxLI4SENEOR laxDQGIiZ8HKlDJCKIiTZmXTTMp1Jj2JVuiQO4mLXAUhXcZwISWTptGJNJ1KM3uUQ9q55SEU GWSwzASHxR5s65uIvxOl9nu0+ooOG3ntt/03WDvUkK5cG4wOVFuIB06TAfSZbI+FVFm+Pqf4 qMzexWxZmFLn6o88l844mprqohaD+FXu/enHQuXnA24yOV1Z7cOHO+Ylyf/0XwIjmNmevtzb /ovth8puXXNwvND8va74icYiwhXx0lPeGKOQ/gevGvYdVQMAAA== Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 08:00:35 -0000 --_000_VI1PR07MB1709736191F032C7170E722AEA880VI1PR07MB1709eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephane, >> If during the timer run, a new topology change occurs (metric change, li= nk up or down whatever it is local or remote), we need to update the I've been wrongly assuming that the delay is applied only to those entries that are likely to cause microloops, but now realize the draft is advocating delaying the entire IGP routing table. In that case, any topology change that follows the original link failure will of course have to abort the delay. Thanks for the clarification. Sikhi From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: 09 August 2017 17:07 To: Sikhivahan Gundu ; Chris Bowers Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi, Thanks for your feedback, please find some comments inline. Brgds, Stephane From: Sikhivahan Gundu [mailto:sikhivahan.gundu@ericsson.com] Sent: Wednesday, August 09, 2017 12:19 To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi, Requesting a couple of clarifications. >> If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULO= OP_DELAY_DOWN_TIMER is stopped Do we stop the timer if "new convergence" is a result only of links coming up, i.e, no links have failed? My interpretation of the old text, as well= as the revision, is that we don't, but in the light of the discussion that this pa= ssage triggered, it seems better to have the interpretation validated, as below: [SLI] Let's that you have a convergence triggered by a local link down, thi= s convergence will apply the ULOOP_DELAY_DOWN_TIMER. If during the timer run, a new topology change occurs (metric change, link = up or down whatever it is local or remote), we need to update the FIB witho= ut anymore delaying with the latest topology. If we do not do so, the local router will use an N-2 FIB version while the = other routers will start to use the latest version N this could cause side = effects. Imagining the IGP router to be in one of two states: -- NORMAL-UPDATE state (FIB updated "normally"), also the initial state, -- and DELAYED-UPDATE state (FIB updated after ULOOP_DELAY_TIMER units of t= ime), the draft seems to suggest the following state transitions. I'd greatly app= reciate validation. ---------------------------+-----------------------------------------------= -------+-------------------------+ current state | event = | next state | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | DELAYED-UPDATE | ---------------------------+ one local link failure = +-------------------------+ DELAYED-UPDATE | = | NORMAL-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | one remote link failure | = | ---------------------------+ OR = | NORMAL-UPDATE | DELAYED-UPDATE | two or more (any kind of) link failures | = | ---------------------------+-----------------------------------------------= -------+-------------------------+ NORMAL-UPDATE | = | NORMAL-UPDATE | ---------------------------+ no link failures (only link-up's) = +--------------------------+ DELAYED-UPDATE | = | DELAYED-UPDATE | ---------------------------+-----------------------------------------------= -------+-------------------------+ [SLI] The last line should be current state DELAYED-UPDATE , next state NOR= MAL-UPDATE. Second: remote loops are illustrated as a non-applicable scenario for this solution. How about local link failures that do not lead to (local) loops? Applying the delay in such a case may result in packet loss if there is no FRR backup. OTOH, detecting that a local loop will form involves more computation. [SLI] I agree with you, that's why the draft encourages to use the mechanis= m in combination with FRR. The draft does not prevent an implementation to = detect if a loop exists or not before applying the mechanism. Thanks, Sikhi From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of stephane.litkowski= @orange.com Sent: 08 August 2017 20:50 To: Chris Bowers > Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG > Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Thanks Chris, I will post a new revision with those changes. From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 16:05 To: LITKOWSKI Stephane OBS/OINIS Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Stephane, See responses inline with [CB]. Chris From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Tuesday, August 8, 2017 8:25 AM To: Chris Bowers > Cc: RTGWG >; draft-ietf-rtgwg-uloop-d= elay@tools.ietf.org Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-0= 5.txt Hi Chris, Thanks for the review. I'm updating the document to reflect your proposals. Couple of comments: - s/"otherwise the standard IP convergence MUST be used."/ "otherw= ise the standard IP convergence MUST used". It does not sound good to me bu= t may be because of an English grammar issue on my side. Could you confirm = the change ? [CB] You are correct. That proposed change is a mistake on my part. - Regarding your main comment on section 1 and 2.1, I do not agree= about your statement on RSVP-FRR. First there are multiple deployment styl= es of RSVP FRR: o LDP tunneling o RSVP with no strict ERO o RSVP with CSPF at head end (strict ERO) Your statement is true only for the third case where an RSVP tunnel between= S and D exists with its path computed by S =3D> no uloop in that case for = sure. But as soon as you rely on distributed convergence, you will fall int= o a loop even if you use RSVP-FRR. I will precise in the text that we are i= n an LDP scenario for example. Here is a text proposal: "In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T= , provisioned on C and terminating on B, is used to protect the traffic aga= inst C-B link failure (IGP shortcut is activated on C)." "The issue described here is completely independent of the fast-reroute mec= hanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop= by hop defined path." [CB] "when the primary path is an hop by hop defined path" is somewhat amb= iguous. How about "when the primary path uses hop-by-hop routing" ? For the LFA case, yes, there are some cases where there is no loop, but it = is topology dependent. I'm not sure that we need to give such precision as = if the LFA is on the postconvergence path, this means that the postconverge= nce is loopfree, so there will be no local microloop in any case. [CB] OK. - Regarding your comment on section 4.4, here is my new text propo= sal to fit your comment: "Upon an adjacency/link down event, this document introduces a change in step 5 () in order to delay the= local convergence compared to the network wide convergence. The new step 5 is described below:" 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the = condition of a single local link-down event has been met and if the new con= vergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an upd= ate of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER mse= cs. Otherwise, the RIB and FIB SHOULD be updated immediately. If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running, ULOOP_= DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of th= e new convergence event." [CB] This text seems clearer. Brgds, Stephane From: Chris Bowers [mailto:cbowers@juniper.net] Sent: Tuesday, August 08, 2017 03:01 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org Cc: rtgwg@ietf.org Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.tx= t Authors, I'm in the process of doing the Shepherd write-up for draft-ietf-rtgwg-uloo= p-delay-05.txt. In reading the latest version of the document, I wrote down some feedback. A diff can be found at: https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f= 3fc5b2c89dc65f813b992921d685049a4a4bd http://bit.ly/2vJqoq2 Most of the feedback is related to clarifying language and typos. However = there are few comments that I think are more substantive so I am reproducing them below since they should probably discussed on the list. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] I find the examples presented in section 1 and section 2.1 to be confusing. The conclusion drawn in the last paragraph of section 2.1 does not seem to follow from these examples. Section 1 (figure 1) shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. Section 2.1 (figure 2) also shows an example of micro-loops occuring when shortest path forwarding is used and the metrics are such that LFA and rLFA produce no backup paths from the PLR. However, in this example, a one-hop RSVP tunnel is provisioned to provide link protection for one of the links. However, even with this one-hop RSVP tunnel the example demonstrates that micro-loops can occur. The last paragraph asserts that: "The issue described here is completely independent of the fast- reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)." There are two problems with this assertion. Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in g= eneral. For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D. Before the failure of the link C-B, this LSP would follow the path S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is made aware of the failure. S will resignal the LSP to take the path S-E-A-= D. At no time would looping occur. I assume that it wasn't the initial intention to claim that RSVP TE-FRR suf= fers from micro-looping, but the text currently reads that way. The assertion of the= last paragraph should be qualified to talk about how microloops will still affec= t traffic forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs. Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has no= t been demonstrated with the examples provided. I think it may instead be the case that the assertion nay not be true for local LFA in some circumsta= nces. In particular, if traffic to a given destination can be protected for a giv= en failure by the PLR using a local LFA that is the same as the post convergen= ce path, then that traffic will not be subject to microloops. Perhaps the overall intention of the example in figure 2 using links protected with one-hop RSVP-signaled LSPs was to say that no matter how much flexibility you give yourself in building a backup path from the PLR, if the PLR stops using the backup path before other routers stop sending traffic to the PLR, then you can still have forwarding loops. However, I think the complexity and detail of the example using one-hop RSVP-signaled LSPs ends up confusing the matter. The text should either work more systematically through examples to substantiate the assertion, or the assertion should be scaled back. Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR= . =3D=3D=3D=3D=3D=3D Section 4.4 [CB] It would be good to write out exactly what the modified version of st= ep 5 looks like so there is no confusion. Something like: 5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition of a single local link-down event have been met, then an update of the RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB update is scheduled immediately. =3D=3D=3D=3D=3D=3D=3D=3D=3D Such a delay SHOULD only be introduced if all the LSDB modifications processed are only reporting a single local link down event (Section 4.3). If a subsequent LSP/LSA is received/updated and a new SPF computation is triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the same evaluation SHOULD be performed. =3D=3D=3D=3D=3D=3D=3D=3D=3D [CB] What should one do if the evaluation of a subsequent LSP/LSA fails at this point? Do you go ahead and update the FIB with the forwarding entries that you were waiting to do? Or do you do a new SPF with the new information? Or is it up to the implementation? =3D=3D=3D=3D=3D=3D=3D=3D=3D I also ran the idnits check which show the following issues. Can you get rid of the unused references and move RFC 5715 from Normative t= o informational so that idnits will run clean? https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/dra= ft-ietf-rtgwg-uloop-delay-05.txt Thanks, Chris ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_VI1PR07MB1709736191F032C7170E722AEA880VI1PR07MB1709eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephane,<= /span>

 =

>> If during the timer run, a new topology change occurs= (metric change, link up or down whatever it is local or remote), we need t= o update the

 =

I’ve been wrongly = assuming that the delay is applied only to those

entries that are likely = to cause microloops, but now realize the draft

is advocating delaying t= he entire IGP routing table. In that case, any

topology change that fol= lows the original link failure will of course

have to abort the delay.=

 =

Thanks for the clarifica= tion.

 =

Sikhi<= /p>

 =

 =

From: = stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: 09 August 2017 17:07
To: Sikhivahan Gundu <sikhivahan.gundu@ericsson.com>; Chris Bo= wers <cbowers@juniper.net>
Cc: draft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG <rtgwg@iet= f.org>
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi,<= /p>

 

Thanks for your feedba= ck, please find some comments inline.

 

Brgds,

 

Stephane

 

 

From: Si= khivahan Gundu [mailto:sik= hivahan.gundu@ericsson.com]
Sent: Wednesday, August 09, 2017 12:19
To: LITKOWSKI Stephane OBS/OINIS; Chris Bowers
Cc: d= raft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi,

 

Requesting a couple of clarifications.

 

>> If a new convergence occurs while ULOO= P_DELAY_DOWN_TIMER is running, ULOOP_DELAY_DOWN_TIMER is stopped

 

Do we stop the timer if  “new convergenc= e” is a result only of links coming

up, i.e, no links have failed?  My interpretat= ion of the old text,  as well as the

revision, is that we don’t, but in the light = of the discussion that this passage

triggered, it seems better to have the interpretati= on validated, as below:

 

[SLI] Let’s that you have a con= vergence triggered by a local link down, this convergence will apply the UL= OOP_DELAY_DOWN_TIMER.

If during the timer run, a new topolo= gy change occurs (metric change, link up or down whatever it is local or re= mote), we need to update the FIB without anymore delaying with the latest topology.

If we do not do so, the local router = will use an N-2 FIB version while the other routers will start to use the l= atest version N this could cause side effects.

 

 

Imagining the IGP router to be in one of two states= :

-- NORMAL-UPDATE state (FIB updated “normally= ”), also the initial state,

-- and DELAYED-UPDATE state (FIB updated after ULOO= P_DELAY_TIMER units of time),

   

the draft seems to suggest the following state tran= sitions. I’d greatly appreciate

validation.

 

---------------------------+-----------------= -------------------------------------+-------------------------+

     current state  = ;      |       =             &nb= sp;            =   event          &nb= sp;             = ;     |        =  next state      |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      | DELAYED-UPDATE |

---------------------------+   = ;             &= nbsp; one local link failure       =            +---------= ----------------+         =        

DELAYED-UPDATE    |  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =        | NORMAL-UPDATE |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;            &= nbsp;  one remote link failure      &nbs= p;      |       &nbs= p;            &= nbsp;           &nbs= p;  |

---------------------------+   = ;            &n= bsp;            &nbs= p;       OR     = ;            &n= bsp;            = ; | NORMAL-UPDATE |

DELAYED-UPDATE    |  two or m= ore (any kind of) link failures   |     =             &nb= sp;            =     |

---------------------------+-----------------= -------------------------------------+-------------------------+

NORMAL-UPDATE    |  &nbs= p;             =             &nb= sp;            =             &nb= sp;            =       | NORMAL-UPDATE |

---------------------------+   &nbs= p;       no link failures (only link-up'= s)       +--------------------------+=

DELAYED-UPDATE    |  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =        | DELAYED-UPDATE |

---------------------------+-----------------= -------------------------------------+-------------------------+

 

[SLI] The last line= should be current state DELAYED-UPDATE , next state NORMAL-UPDATE.

 

 

Second: remote loops are illustrated as a non-app= licable scenario for this

solution. How about local link failures that do n= ot lead to (local) loops?

Applying the delay in such a case may result in p= acket loss if there is no

FRR backup.  OTOH, detecting that a local lo= op will form  involves more

computation.   

 

[SLI] I agree with = you, that’s why the draft encourages to use the mechanism in combinat= ion with FRR. The draft does not prevent an implementation to detect if a l= oop exists or not before applying the mechanism.

 

 

Thanks,

Sikhi

 

 

From: = rtgwg [mailto:rtgwg-bounces@ietf.= org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: 08 August 2017 20:50
To: Chris Bowers <cbowers@= juniper.net>
Cc: d= raft-ietf-rtgwg-uloop-delay@tools.ietf.org; RTGWG <rtgwg@ietf.org>
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Thanks Chris, I will p= ost a new revision with those changes.

 

 

From: Ch= ris Bowers [mailto:cbowers@juniper.n= et]
Sent: Tuesday, August 08, 2017 16:05
To: LITKOWSKI Stephane OBS/OINIS
Cc: RTGWG; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Stephane,

 

See responses inline w= ith [CB].

 

Chris

 

From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
Sent: Tuesday, August 8, 2017 8:25 AM
To: Chris Bowers <cbowers@= juniper.net>
Cc: RTGWG <rtgwg@ietf.org&g= t;; draft-ietf-rtgwg-uloop-delay@tools.ietf.org
Subject: RE: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-= delay-05.txt

 

Hi Chris,

 

Thanks for the review.= I’m updating the document to reflect your proposals.

Couple of comments:

-          s/“otherwise the standard IP con= vergence MUST be used.”/ “otherwise the standard IP convergence= MUST used”. It does not sound good to me but may be because of an English grammar issue on my side. Could you confirm the change ?

 

[CB]  You are cor= rect.  That proposed change is a mistake on my part.=

 

-          Regarding your main comment on section= 1 and 2.1, I do not agree about your statement on RSVP-FRR. First there ar= e multiple deployment styles of RSVP FRR:

o   LDP tunneling

o   RSVP with no strict ERO

o   RSVP with CSPF at head end (strict ERO= )

Your statement is true only for the third case where an RSVP tunnel = between S and D exists with its path computed by S =3D> no uloop in that case for sure. But as soon as you rely on distrib= uted convergence, you will fall into a loop even if you use RSVP-FRR. I wil= l precise in the text that we are in an LDP scenario for example. Here is a= text proposal:

“In the Figure 2, we consider an IP/LDP routed network. An RSV= P-TE tunnel T, provisioned on C and terminating on B, is used to protect the traffic against C-B link failure (IGP shortcut is acti= vated on C).”

“The issue described here is completely independent of the fas= t-reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop by hop defined path.”

 

 

[CB] “when the p= rimary path is an hop by hop defined path”  is somewhat ambiguou= s.

How about “when = the primary path uses hop-by-hop routing” ?

 

 

For the LFA case, yes, there are some cases where there is no loop, = but it is topology dependent. I’m not sure that we need to give such precision as if the LFA is on the postconvergence path, = this means that the postconvergence is loopfree, so there will be no local = microloop in any case.

 

[CB]  OK. 

 

-          Regarding your comment on section 4.4,= here is my new text proposal to fit your comment:

           &n= bsp;           

“Upon an adjacency/link down event, this document introduces a= change

   in step 5 (<xref target=3D"description-current&= quot;/>) in order to delay the local convergence compared to the

   network wide convergence. The new step 5 is described b= elow:”

           5. Upon= SPF_DELAY timer expiration, the SPF is computed. If the condition of a sin= gle local link-down event has been met and if the new convergence did not trigger a stop of the ULOO= P_DELAY_DOWN_TIMER , then an update of the RIB and the FIB SHOULD be delaye= d for ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be up= dated immediately.

 

If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running,= ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of the new convergence event.”<= /span>

 

[CB]  This text s= eems clearer.

 

Brgds,

 

Stephane

 

 

From: Ch= ris Bowers [mailto:cbowers@juniper.n= et]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-rtgwg-uloop-delay@ietf.org
Cc: rtgwg@ietf.org
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-dela= y-05.txt

 

Authors,

 

I’m in the process of doing th= e Shepherd write-up for draft-ietf-rtgwg-uloop-delay-05.txt. 

 

In reading the latest version of the= document, I wrote down some feedback.

A diff can be found at:

 

 

Most of the feedback is related to c= larifying language and typos.  However there

are few comments that I think are mo= re substantive so I am

reproducing them below since they sh= ould probably discussed on the list.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[CB]  I find the examples prese= nted in section 1 and section 2.1 to

be confusing.  The conclusion d= rawn in the last paragraph of section

2.1 does not seem to follow from the= se examples.

 

Section 1 (figure 1) shows an exampl= e of micro-loops occuring when shortest

path forwarding is used and the metr= ics are such that LFA and rLFA

produce no backup paths from the PLR= . 

 

Section 2.1 (figure 2) also shows an= example of micro-loops occuring when

shortest path forwarding is used and= the metrics are such that LFA and rLFA

produce no backup paths from the PLR= .  However, in this example,

a one-hop RSVP tunnel is provisioned= to provide link protection for one of

the links.  However, even with = this one-hop RSVP tunnel the example

demonstrates that micro-loops can oc= cur.

 

The last paragraph asserts that:

"The issue described here is co= mpletely independent of the fast-

reroute mechanism involved (TE FRR, = LFA/rLFA, MRT ...)."

 

There are two problems with this ass= ertion.

 

Problem 1) I don't think that the as= sertion is correct for RSVP TE-FRR in general.

 

For classical RSVP TE-FRR, there wou= ld be an RSVP-signaled LSP from S to D. 

Before the failure of the link C-B, = this LSP would follow the path

S-E-C-B-A-D.  Immediately after= the failure of link C-B, the LSP would

follow the path S-E-C-E-A-B-A-D usin= g the bypass LSP at C.  Once S is

made aware of the failure.  S w= ill resignal the LSP to take the path S-E-A-D. 

At no time would looping occur. = ;

 

I assume that it wasn't the initial = intention to claim that RSVP TE-FRR suffers from

micro-looping, but the text currentl= y reads that way.  The assertion of the last

paragraph should be qualified to tal= k about how microloops will still affect traffic

forwarded hop-by-hop over links prot= ected with one-hop RSVP-signaled LSPs.

 

Problem 2) The assertion may be corr= ect for LFA/rLFA and MRT, but it has not

been demonstrated with the examples = provided.  I think it may instead be

the case that the assertion nay not = be true for local LFA in some circumstances.

In particular, if traffic to a given= destination can be protected for a given

failure by the PLR using a local LFA= that is the same as the post convergence

path, then that traffic will not be = subject to microloops.

 

Perhaps the overall intention of the= example in figure 2 using

links protected with one-hop RSVP-si= gnaled LSPs was to say that no

matter how much flexibility you give= yourself in building a backup path

from the PLR, if the PLR stops using= the backup path before other routers

stop sending traffic to the PLR, the= n you can still have forwarding loops.

However, I think the complexity and = detail of the example using one-hop

RSVP-signaled LSPs ends up confusing= the matter.

 

The text should either work more sys= tematically through examples to

substantiate the assertion, or the a= ssertion should be scaled back. 

Regardless, the assertion needs to b= e clarified with respect to RSVP-TE FRR.

 

=3D=3D=3D=3D=3D=3D 

Section 4.4

 

[CB]  It would be good to write= out exactly what the modified version of step 5

looks like so there is no confusion.= Something like:

 

5.  Upon SPF_DELAY timer expira= tion, the SPF is computed.  If the condition

of a single local link-down event ha= ve been met, then an update of the

RIB and the FIB is scheduled in ULOO= P_DELAY_DOWN_TIMER msecs.  Otherwise,

the RIB and FIB update is scheduled = immediately.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

   Such a delay=

   SHOULD only be introduc= ed if all the LSDB modifications processed are

   only reporting a single= local link down event (Section 4.3).  If a

   subsequent LSP/LSA is r= eceived/updated and a new SPF computation is

   triggered before the ex= piration of ULOOP_DELAY_DOWN_TIMER, then the

   same evaluation SHOULD = be performed.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D &nb= sp;

[CB] What should one do if the evalu= ation of a subsequent LSP/LSA fails

at this point?  Do you go ahead= and update the FIB with the forwarding

entries that you were waiting to do?=   Or do you do a new SPF with the

new information?  Or is it up t= o the implementation?

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I also ran the idnits check which sh= ow  the following issues.

Can you get rid of the unused refere= nces and move RFC 5715 from Normative to informational so that idnits will = run clean? 

 

 

Thanks,

Chris

 

 

_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
_________________________________________________=
________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir=
 des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les piece=
s jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message=
 a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
--_000_VI1PR07MB1709736191F032C7170E722AEA880VI1PR07MB1709eurp_-- From nobody Tue Aug 15 09:23:57 2017 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 0D59E13234C; Tue, 15 Aug 2017 09:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBH-piE9h5eq; Tue, 15 Aug 2017 09:23:53 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4833132191; Tue, 15 Aug 2017 09:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19387; q=dns/txt; s=iport; t=1502814232; x=1504023832; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3S0K96m6EtVs43riZ8EgSxC5S0USJIRh4BHcsnt+Kig=; b=Wq7coyzgum3GlR5Ak2GDooSqseQIr/QLy5qxU/VFsPiY8RwUMs4r0TFW OuTymrzdjMqHKnWBXd2eXSjxN97kWdv4YZ9jW6W1A/RaogL9vwolSYt5n ooR3Yp1zm2bA4hpYz9CotDCm3CBW4o6CYHaOhDA1msi1fiTbT5VeUGmaE g=; X-IronPort-AV: E=Sophos;i="5.41,378,1498521600"; d="scan'208,217";a="470155821" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2017 16:23:52 +0000 Received: from [10.24.47.33] ([10.24.47.33]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7FGNoNK019487; Tue, 15 Aug 2017 16:23:51 GMT Message-ID: <59932016.3020201@cisco.com> Date: Tue, 15 Aug 2017 09:23:50 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stewart Bryant , Stewart Bryant , Sikhivahan Gundu , "rtgwg@ietf.org" CC: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B030.8080001@cisco.com> <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> <893ad668-9f62-51a1-0835-7841e919e63c@g3ysx.org.uk> In-Reply-To: <893ad668-9f62-51a1-0835-7841e919e63c@g3ysx.org.uk> Content-Type: multipart/alternative; boundary="------------040700000703010002090602" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:23:55 -0000 This is a multi-part message in MIME format. --------------040700000703010002090602 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Stewart If you think that there are other problems that needs to be addressed, do not attempt to push it down the throat of our draft. Instead put out your own proposal. But make sure that it has enough merit to convince the WG that it is better or more comprehensive instead of attempting to point out fictitious problems in others' proposals. Ahmed On 8/7/2017 1:34 PM, Stewart Bryant wrote: > > Ahmed, > > The WG decides what is in or out of scope for a WG draft, and it does > this via the rough consensus of the WG, not the view of the authors. > > Of course if you wish to refocus this as an independent draft and > submit via the ISE. If you do, you are welcome and I will leave you to it. > > Meanwhile the draft really has to discuss SRLGs are they are in real > life, not as you would wish them to be. > > Another type of false SRLG btw is when you are doing node protection > (you normally treat a node as an SRLG), but only a line interface has > failed. > > - Stewart > > > > > On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote: >> >> Stewart >> >> I already replied to Sikhi explaining the concept of the SRLG used in >> this draft and the intent to make it even clearer. >> >> IMO the scope of the draft is very clear from the draft itself as >> well as the numerous responses during the previous IETF and the >> mailing list. >> >> The issue below is **out of scope** of the draft and hence I have no >> plans on addressing it. >> >> I hope you don’t insist on pushing out-of-scope topics down the >> throat of this draft :) >> >> Ahmed >> >> *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com] >> *Sent:* Monday, August 07, 2017 12:48 PM >> *To:* Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; >> rtgwg@ietf.org >> *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com >> *Subject:* Re: I-D Action: >> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >> >> Your answer did not address the issue below, which is one of a class >> of issues related to SRLG. >> >> - Stewart >> >> On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: >> >> See my reply to Sikhi >> >> Thanks >> >> Ahmed >> >> On 8/7/2017 2:13 AM, Stewart Bryant wrote: >> >> On 07/08/2017 06:45, Sikhivahan Gundu wrote: >> >> By “ambiguity”, I meant that backup calculation taking >> SRLG into >> >> account is based on speculated topology, whereas >> computation of >> >> post-convergence path, ie, SPF, is based on actual >> topology. This >> >> seems needs reconciling since in TI-LFA the backup is by >> definition >> >> the post-convergence path, with a single path-transition >> after >> >> link-failure as the intended outcome. Do I understand >> correctly that >> >> the draft prefers to relax that expectation for SRLG? >> >> >> Yes, that is a good point, in the event of an incomplete failure >> of an SRLG, there may not be congruence between the >> FRR path and the post convergence path. This certainly >> needs further study. >> >> * >> A--------//---------B >> | | >> | * | cost 2 >> C-------------------D >> | | >> | | cost 100 >> E-------------------F >> >> >> AB + CD in same SRLG >> >> TiLFA path is ACEFDB >> >> Post convergence path is ACDB >> >> In this case I think that the impact is just more SR hops in the >> repair path than might be needed without the SRLG, but we do >> need to >> be sure that there are no pathological cases in >> topologies that lack the proposed congruence, and as >> Sikhivahan notes this effect does need to be clarified in the >> text. >> >> - Stewart >> >> >> >> >> >> >> >> _______________________________________________ >> >> rtgwg mailing list >> >> rtgwg@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtgwg >> > --------------040700000703010002090602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Stewart

If you think that there are other problems that needs to be addressed, do not attempt to push it down the throat of our draft. Instead put out your own proposal. But make sure that it has enough merit to convince the WG that it is better or more comprehensive instead of attempting to point out fictitious problems in others' proposals.

Ahmed



On 8/7/2017 1:34 PM, Stewart Bryant wrote:

Ahmed,

The WG decides what is in or out of scope for a WG draft, and it does this via the rough consensus of the WG, not the view of the authors.

Of course if you wish to refocus this as an independent draft and submit via the ISE. If you do, you are welcome and I will leave you to it.

Meanwhile the draft really has to discuss SRLGs are they are in real life, not as you would wish them to be.

Another type of false SRLG btw is when you are doing node protection (you normally treat a node as an SRLG), but only a line interface has failed.

- Stewart




On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote:

Stewart

 

I already replied to Sikhi explaining the concept of the SRLG used in this draft and the intent to make it even clearer.

 

IMO the scope of the draft is very clear from the draft itself as well as the numerous responses during the previous IETF and the mailing list.

 

The issue below is *out of scope* of the draft and hence I have no plans on addressing it.

 

I hope you don’t insist on pushing out-of-scope topics down the throat of this draft :)

 

Ahmed

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, August 07, 2017 12:48 PM
To: Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Your answer did not address the issue below, which is one of a class of issues related to SRLG.

- Stewart

 

On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:

See my reply to Sikhi

Thanks

Ahmed

On 8/7/2017 2:13 AM, Stewart Bryant wrote:

 

 

On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 

 


Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 





_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

 



--------------040700000703010002090602-- From nobody Tue Aug 15 10:17:40 2017 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 29383132143; Tue, 15 Aug 2017 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAj9XyZ-K1nT; Tue, 15 Aug 2017 10:17:36 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BE013228D; Tue, 15 Aug 2017 10:17:36 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id m85so13303341wma.0; Tue, 15 Aug 2017 10:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=btIwUdeimJKJtO9wITkQ7yw0ZvinnF8ny+h83PJWRWw=; b=Ei43Cs+dkMGVuJ295oJKLuHw/3awuBqmghbEvVlV83brsg4o1kdTG1Wyhx9cYWS3w8 3RHzj4dtJVeuMjoKKNMkOUO/Er6fkzuuKvm+mWSKEIw36FjKPPj4OWVYV0z312bPW2Gm CbhLal/KWGgdp5K32UbiXE/zXzU1ogQmwb2ls6SqvyJin3VPL/H3+3M68B7iRgEWJJNI uebchbdcq3QIfn+smaNvQxgu3+bhxxAcEb/zLcFNYEYaRa6CrJZlgvRO6owPW/vkRoC5 ejIu1UGD3jS/pJoE8WLS14wT/AGRFY7uPn3n53mNmzkmhU3AfzxpV73aBqdv1VLap7gR +ksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=btIwUdeimJKJtO9wITkQ7yw0ZvinnF8ny+h83PJWRWw=; b=pCSVUGRc5F82Fps3dX8z0Wfsgh1EDRUtIyw98IZtF+qCA57ztNJB3docOlbYdmp7fv BzrpgMhxqYglUx5ocQVdQzvV9RG4k2v9u3SHhMkaamcFzUHozUt+KpfvxbTBCPrteE+Z q8FYnWvDmTBGjGCCyTrhxDd5BD78P9/qmsdP0EXKIz1S/d06oWnWCyhe6eQgW+ta1bPG 96VYLUOkRmX+ibU1G9+DECDD4CAX5lo8UQRCeztQC+EXD3OjrWfrgBKXLBO+BV0CEsfI MQ5fvORXiHLtN9uSa8LmiCIOFaq8mXaNU2cfz69e+Mg+2YcuLUfwiXAkOfeEzeoIisPU KhHw== X-Gm-Message-State: AHYfb5jxj8HK/kRkCWuOrjkfwpxQ1ZleaFvlEjtmVFz/VULSNC167+8L w6s3S5ymLvwgUA== X-Received: by 10.28.174.7 with SMTP id x7mr2200601wme.43.1502817454648; Tue, 15 Aug 2017 10:17:34 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 140sm2097527wmx.1.2017.08.15.10.17.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 10:17:33 -0700 (PDT) Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt To: "Ahmed Bashandy (bashandy)" , Sikhivahan Gundu , "rtgwg@ietf.org" Cc: "rtgwg-chairs@ietf.org" , "pfrpfr@gmail.com" References: <150027597752.32726.7270829130613224040@ietfa.amsl.com> <596C668E.9050106@cisco.com> <5984CFB0.3070908@cisco.com> <5988B030.8080001@cisco.com> <9ecd1975-e34e-6d6a-6d6f-0e62dc4c48b5@gmail.com> <849700d9f030475a852096bfa51766fb@XCH-RTP-020.cisco.com> <893ad668-9f62-51a1-0835-7841e919e63c@g3ysx.org.uk> <59932016.3020201@cisco.com> From: Stewart Bryant Message-ID: <17afcbce-7ced-9a34-4c41-7c37edfaf107@gmail.com> Date: Tue, 15 Aug 2017 18:17:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <59932016.3020201@cisco.com> Content-Type: multipart/alternative; boundary="------------AE3155AC2DB10AC0BAA3F794" Content-Language: en-GB Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:17:39 -0000 This is a multi-part message in MIME format. --------------AE3155AC2DB10AC0BAA3F794 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Ahmed, Let us consider this "fiction". RFC4202 section 2.3 defines a shared risk link group as: "A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set." The key work is MAY. This means that there is some probability that all members of the SRLG failed, and that there is some other probability that they did not all fail. In your draft you calculate your repair action on the assumption that they all failed and assert that this will be congruent with the post convergence path. However from the definition of SRLG we can see that they may not have all failed, in which case some of the not failed elements of the SRLG will normally remain in service, and may provide a better path than the path avoiding all elements of the SRLG. If this is the case the calculated repair path may not be congruent with the post convergence path. Thus using the standard definition of SRLG this fundamental assertion in your proposal seems to me to fail. You could introduce and alternative definition of SRLG: "A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure will effect all links in the set." However in practice this definition can only be true if on seeing the failure of a single element of the SRLG you take all elements of the SRLG out of service. This seems wasteful of resources, but if that is what you mean your draft needs to specify this definition and action. Alternatively your draft needs to state that full congruence may not occur and analyse the consequences of this. Regards Stewart On 15/08/2017 17:23, Ahmed Bashandy (bashandy) wrote: > > Stewart > > If you think that there are other problems that needs to be addressed, > do not attempt to push it down the throat of our draft. Instead put > out your own proposal. But make sure that it has enough merit to > convince the WG that it is better or more comprehensive instead of > attempting to point out fictitious problems in others' proposals. > > Ahmed > > > > On 8/7/2017 1:34 PM, Stewart Bryant wrote: >> >> Ahmed, >> >> The WG decides what is in or out of scope for a WG draft, and it does >> this via the rough consensus of the WG, not the view of the authors. >> >> Of course if you wish to refocus this as an independent draft and >> submit via the ISE. If you do, you are welcome and I will leave you >> to it. >> >> Meanwhile the draft really has to discuss SRLGs are they are in real >> life, not as you would wish them to be. >> >> Another type of false SRLG btw is when you are doing node protection >> (you normally treat a node as an SRLG), but only a line interface has >> failed. >> >> - Stewart >> >> >> >> >> On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote: >>> >>> Stewart >>> >>> I already replied to Sikhi explaining the concept of the SRLG used >>> in this draft and the intent to make it even clearer. >>> >>> IMO the scope of the draft is very clear from the draft itself as >>> well as the numerous responses during the previous IETF and the >>> mailing list. >>> >>> The issue below is **out of scope** of the draft and hence I have no >>> plans on addressing it. >>> >>> I hope you don’t insist on pushing out-of-scope topics down the >>> throat of this draft :) >>> >>> Ahmed >>> >>> *From:*Stewart Bryant [mailto:stewart.bryant@gmail.com] >>> *Sent:* Monday, August 07, 2017 12:48 PM >>> *To:* Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; >>> rtgwg@ietf.org >>> *Cc:* rtgwg-chairs@ietf.org; pfrpfr@gmail.com >>> *Subject:* Re: I-D Action: >>> draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt >>> >>> Your answer did not address the issue below, which is one of a class >>> of issues related to SRLG. >>> >>> - Stewart >>> >>> On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote: >>> >>> See my reply to Sikhi >>> >>> Thanks >>> >>> Ahmed >>> >>> On 8/7/2017 2:13 AM, Stewart Bryant wrote: >>> >>> On 07/08/2017 06:45, Sikhivahan Gundu wrote: >>> >>> By “ambiguity”, I meant that backup calculation taking >>> SRLG into >>> >>> account is based on speculated topology, whereas >>> computation of >>> >>> post-convergence path, ie, SPF, is based on actual >>> topology. This >>> >>> seems needs reconciling since in TI-LFA the backup is >>> by definition >>> >>> the post-convergence path, with a single path-transition >>> after >>> >>> link-failure as the intended outcome. Do I understand >>> correctly that >>> >>> the draft prefers to relax that expectation for SRLG? >>> >>> >>> Yes, that is a good point, in the event of an incomplete failure >>> of an SRLG, there may not be congruence between the >>> FRR path and the post convergence path. This certainly >>> needs further study. >>> >>> * >>> A--------//---------B >>> | | >>> | * | cost 2 >>> C-------------------D >>> | | >>> | | cost 100 >>> E-------------------F >>> >>> >>> AB + CD in same SRLG >>> >>> TiLFA path is ACEFDB >>> >>> Post convergence path is ACDB >>> >>> In this case I think that the impact is just more SR hops in the >>> repair path than might be needed without the SRLG, but we do >>> need to >>> be sure that there are no pathological cases in >>> topologies that lack the proposed congruence, and as >>> Sikhivahan notes this effect does need to be clarified in the >>> text. >>> >>> - Stewart >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> rtgwg mailing list >>> >>> rtgwg@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >> > --------------AE3155AC2DB10AC0BAA3F794 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Ahmed,

Let us consider this "fiction".

RFC4202 section 2.3 defines a shared risk link group as:

"A set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set."

The key work is MAY.

This means that there is some probability that all members of the SRLG failed, and that there is some other probability that they did not all fail.

In your draft you calculate your repair action on the assumption that they all failed and assert that this will be congruent with the post convergence path.

However from the definition of SRLG we can see that they may not have all failed, in which case some of the not failed elements of the SRLG will normally remain in service, and may provide a better path than the path avoiding all elements of the SRLG.  If this is the case the calculated repair path may not be congruent with the post convergence path.

Thus using the standard definition of SRLG this fundamental assertion in your proposal seems to me to fail.

You could introduce and alternative definition of SRLG:


"A set of links may constitute a 'shared risk link group' (SRLG) if  they share a resource whose failure will effect all links in the set."

However in practice this definition can only be true if on seeing the failure of a single element of the SRLG you take all elements of the SRLG out of service. This seems wasteful of resources, but if that is what you mean your draft needs to specify this definition and action.

Alternatively your draft needs to state that full congruence may not occur and analyse the consequences of this.

Regards

Stewart


On 15/08/2017 17:23, Ahmed Bashandy (bashandy) wrote:

Stewart

If you think that there are other problems that needs to be addressed, do not attempt to push it down the throat of our draft. Instead put out your own proposal. But make sure that it has enough merit to convince the WG that it is better or more comprehensive instead of attempting to point out fictitious problems in others' proposals.

Ahmed



On 8/7/2017 1:34 PM, Stewart Bryant wrote:

Ahmed,

The WG decides what is in or out of scope for a WG draft, and it does this via the rough consensus of the WG, not the view of the authors.

Of course if you wish to refocus this as an independent draft and submit via the ISE. If you do, you are welcome and I will leave you to it.

Meanwhile the draft really has to discuss SRLGs are they are in real life, not as you would wish them to be.

Another type of false SRLG btw is when you are doing node protection (you normally treat a node as an SRLG), but only a line interface has failed.

- Stewart




On 07/08/2017 21:04, Ahmed Bashandy (bashandy) wrote:

Stewart

 

I already replied to Sikhi explaining the concept of the SRLG used in this draft and the intent to make it even clearer.

 

IMO the scope of the draft is very clear from the draft itself as well as the numerous responses during the previous IETF and the mailing list.

 

The issue below is *out of scope* of the draft and hence I have no plans on addressing it.

 

I hope you don’t insist on pushing out-of-scope topics down the throat of this draft :)

 

Ahmed

 

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Monday, August 07, 2017 12:48 PM
To: Ahmed Bashandy (bashandy); Stewart Bryant; Sikhivahan Gundu; rtgwg@ietf.org
Cc: rtgwg-chairs@ietf.org; pfrpfr@gmail.com
Subject: Re: I-D Action: draft-bashandy-rtgwg-segment-routing-ti-lfa-01.txt

 

Your answer did not address the issue below, which is one of a class of issues related to SRLG.

- Stewart

 

On 07/08/2017 19:23, Ahmed Bashandy (bashandy) wrote:

See my reply to Sikhi

Thanks

Ahmed

On 8/7/2017 2:13 AM, Stewart Bryant wrote:

 

 

On 07/08/2017 06:45, Sikhivahan Gundu wrote:

 

By “ambiguity”, I meant that backup calculation taking SRLG into

account is  based on speculated topology,  whereas computation of

post-convergence path, ie, SPF, is based on actual topology.  This

seems needs reconciling since in  TI-LFA the backup is by definition

the post-convergence path, with a single path-transition after

link-failure as the intended outcome. Do I understand correctly that

the draft prefers to relax that expectation for SRLG?

 

 


Yes, that is a good point, in the event of an incomplete failure
of an SRLG, there may not be congruence between the
FRR path and the post convergence path. This certainly
needs further study.

   *
A--------//---------B
|                   |
|  *                | cost 2
C-------------------D
|                   |
|                   | cost 100
E-------------------F


AB + CD in same SRLG

TiLFA path is ACEFDB

Post convergence path is ACDB

In this case I think that the impact is just more SR hops in the
repair path than might be needed without the SRLG, but we do need to
be sure  that there are no pathological  cases in
topologies that lack the proposed congruence, and as
Sikhivahan notes this effect does need to be clarified in the
text.

- Stewart



 





_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

 




--------------AE3155AC2DB10AC0BAA3F794-- From nobody Wed Aug 16 14:54:41 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9F8132031; Wed, 16 Aug 2017 14:54:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: akatlas@gmail.com, jefftant.ietf@gmail.com, rtgwg-chairs@ietf.org, rtgwg@ietf.org Subject: rtgwg - New Meeting Session Request for IETF 100 X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150292047976.15097.10837339993654148559.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 14:54:39 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 21:54:40 -0000 A new meeting session request has just been submitted by Jeff Tantsura, a Chair of the rtgwg working group. --------------------------------------------------------- Working Group Name: Routing Area Working Group Area Name: Routing Area Session Requester: Jeff Tantsura Number of Sessions: 2 Length of Session(s): 2 Hours, 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: isis mpls ospf pce idr spring Second Priority: bess bier teas ccamp i2rs netmod Third Priority: bfd detnet lime nvo3 pim netconf People who must be present: Alia Atlas Jeff Tantsura Chris Bowers Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Aug 19 11:45:15 2017 Return-Path: X-Original-To: rtgwg@ietf.org Delivered-To: rtgwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A271329C0; Sat, 19 Aug 2017 11:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtgwg@ietf.org Subject: I-D Action: draft-ietf-rtgwg-routing-types-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150316830643.5723.2034174131750029961@ietfa.amsl.com> Date: Sat, 19 Aug 2017 11:45:06 -0700 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 18:45:06 -0000 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 WG of the IETF. Title : Routing Area Common YANG Data Types Authors : Xufeng Liu Yingzhen Qu Acee Lindem Christian Hopps Lou Berger Filename : draft-ietf-rtgwg-routing-types-09.txt Pages : 39 Date : 2017-08-19 Abstract: This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-09 https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-routing-types-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-routing-types-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 29 09:54:28 2017 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 C0487132D59 for ; Tue, 29 Aug 2017 09:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf4l_hQzMq0W for ; Tue, 29 Aug 2017 09:54:25 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D50132C4D for ; Tue, 29 Aug 2017 09:54:25 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id BF8CB1E064E for ; Tue, 29 Aug 2017 10:54:23 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 34uK1w01S2SSUrH014uNA9; Tue, 29 Aug 2017 10:54:23 -0600 X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=Hsoq25NeZv6fqVdDJ98A:9 a=8GDItUJANxTe_aPZ:21 a=0_fy-1t0hktONJUn:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:Subject:From:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=QFJ9hS4/jdeZcTfd5nLEKxjFq2xPn41+ens9CoWMz64=; b=AB4T+o7TJGJOwiMP9NODvYz2c0 4qdGK7E2ChQ35hc02Ue2JJ81uefAPgXrBm3Imzfsd8TbgVnBLLFnwRficFWVvCHLc6vpBpyABCvf4 Tpet/oit3eqP8x3l0P8MAMO0T; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:44356 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmjmN-000DoZ-OC; Tue, 29 Aug 2017 10:54:19 -0600 To: Routing WG From: Lou Berger Subject: Do you care that schema mount extension isn't a node? Cc: "draft-ietf-rtgwg-ni-model@ietf.org" , "draft-ietf-rtgwg-lne-model@ietf.org" Message-ID: Date: Tue, 29 Aug 2017 12:54:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dmjmN-000DoZ-OC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:44356 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 16:54:27 -0000 Hi,     I'm not sure how many folks are tacking the netmod list, so I wanted to raise a point here based on a discussion going on there.  It looks like we (authors of the NI and LNE docs) understood the draft-ietf-netmod-schema-mount defined extension mount-point  as defining a node, similar to a container, in the data tree *but* the schema-mount authors intended the extension to not define a node and to just identify that the node containing the extension was where mounted modules exist.  This isn't too big a deal, but it does mean we now need to put each mount point in its own container.  The tree representation won't materially change, but the yang module will.  An example is provided below. So the question is does anyone care about this?  If not, the module/document updates are fairly straight forward.  If you do care, now is the time to speak up, preferably by joining the netmod discussion. Lou (as contributor) For example in draft-ietf-rtgwg-ni-model: OLD     choice root-type {       description         "Well known mount points.";       yangmnt:mount-point "vrf-root" {         description           "Root for L3VPN type models. This will typically            not be an inline type mount point.";       }       yangmnt:mount-point "vsi-root" {         description           "Root for L2VPN type models. This will typically            not be an inline type mount point.";       }       yangmnt:mount-point "vv-root" {         description           "Root models that support both L2VPN type bridging            and L3VPN type routing. This will typically            not be an inline type mount point.";       } NEW     choice root-type {       description         "Well known mount points.";         container vrf-root {           description             "Container for mount point.";           yangmnt:mount-point "vrf-root" {             description               "Root for L3VPN type models. This will typically                not be an inline type mount point.";           }         }         container vsi-root {           description             "Container for mount point.";           yangmnt:mount-point "vsi-root" {             description               "Root for L2VPN type models. This will typically                not be an inline type mount point.";           }         }         container vv-root {           description             "Container for mount point.";           yangmnt:mount-point "vv-root" {             description               "Root models that support both L2VPN type bridging                and L3VPN type routing. This will typically                not be an inline type mount point.";           }         }     } From nobody Tue Aug 29 11:01:20 2017 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 089291329BD; Tue, 29 Aug 2017 11:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQhY0rPBgCoJ; Tue, 29 Aug 2017 11:01:08 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B98C1321AF; Tue, 29 Aug 2017 11:01:08 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id d17so16273757lfe.1; Tue, 29 Aug 2017 11:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=+otYG/I+7snEjZtY0FwNP3HAWWRSygtdbHM97CuYR0o=; b=FgjSogclV/pFNXilh1XpTpVEaOWipB7r+kfI1Xg3puSkqf1+PgcYCw+9SaHeAvpxeY cmP/7ZzfFK649QT0dmwFHYHN1izoAnC2fh2uzIfmJOvW3O9aVz8R9lvePus/s1N2ydS4 ClPA8fmO5tvaQAXPYOYAmJO/6bXQ7fLlWYv+i3XmW/0tCHHME6s3Usw4Wn9ybZC+pgeR a7r9itp3QyvUnWfiAV6KfRVyFrQQyB6kE3w2GJGYVSoBFxWSEJ6ofYX4AhCJuOcxbbNv TzF5oBbXBru9dPO/AfEdeupRhL89xFVivvMSgYjKabYiPsSbXAHoc5+p7gd0IimieJga a3sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=+otYG/I+7snEjZtY0FwNP3HAWWRSygtdbHM97CuYR0o=; b=qz6gvvmOw+WL/QnDmyhNtDX4biN0nJEVBUHHDv0k3NJlt0oPrYiyIK4gWpYzkm6h+0 RuWCy4FWVwinf8xY7tHpsXsGdS5y/7M2RjFyc4Yqn8zXXq1DehyrU7fOPVgztXzHu+OR Ji5F0zcIDRwDy3eb7LFzHv5Ygr64P4L5d/rWk0ezG11DTuhB0Tvgn5nFDqDdiWTEc1oF irMlBMNyKbPOamxekzw34bspA6oxMIiIhhtliSHEtqMi1r7hg1SPsNYf5yEh+EKRdT9i cs0IWhgbYF94BsGoECfaW9u5JwV7OUDK+wCjsq3q/JwNvgxVPO+1k4fW7Lb8cOyMzp5r Lpag== X-Gm-Message-State: AHYfb5iyVHU6BBVcacWaSh4NZ0drc1nTfwWdXUb5iyEkLSOSq9Hn+PT1 9AUUzjFUaodvAFpHAfhVRuU6Jiwbzg== X-Received: by 10.25.41.21 with SMTP id p21mr327408lfp.37.1504029666006; Tue, 29 Aug 2017 11:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.88.81 with HTTP; Tue, 29 Aug 2017 11:01:04 -0700 (PDT) From: Greg Mirsky Date: Tue, 29 Aug 2017 11:01:04 -0700 Message-ID: Subject: Re: draft-nitish-vrrp-bfd To: TABANI Thibault Cc: "draft-nitish-vrrp-bfd@ietf.org" , "nitisgup@cisco.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" Content-Type: multipart/related; boundary="001a114104d0fa0e5e0557e8312d" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 18:01:11 -0000 --001a114104d0fa0e5e0557e8312d Content-Type: multipart/alternative; boundary="001a114104d0fa0e5b0557e8312c" --001a114104d0fa0e5b0557e8312c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Thibault, thank you for your interest in the draft, much appreciated. Please don't be discouraged that it lapsed, we can fix it easily. I think that authors had similar to your idea when we've started thinking about BFD supporting VRRP. And like you we haven't found any reference in existing documents, hence this draft draft-nitish-vrrp-bfd. Would be much obliged if you review and share your comments, suggestion regarding solutions proposed in the draft. Regards, Greg On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault wrote: > Hello, > > > > I am working at improving VRRP convergence time. (target a few 100=E2=80= =99s of > milliseconds) > > > > It appears that VRRP supports BFD health monitoring which might be a > better option than tuning VRRP aggressive timers. > > > > Unfortunately I cannot find any active RFC where VRRP supports BFD. The > only document I found is your draft document: > > > > Fast failure detection in VRRP with BFD > draft-nitish-vrrp-bfd-04 > > > > Unfortunately date expires of this document. As BFD support for VRRP is > implemented on most routers, I suppose that an active RFC might exist on > that specific BFD implementation within VRRP. (new backup advertisement > messages=E2=80=A6.peer table=E2=80=A6.) > > br > > > > > > *Thibault TABANI * > architect Altran Connected Solutions > Altran France > > > *[image: cid:image001.png@01CF8AFD.950B79F0]* > > > > 1, Impasse Charles Trenet > > 44800 Saint-Herblain > France > > Tel. : +33 2 40 67 62 62 <+33%202%2040%2067%2062%2062> > Mob. : +33 6 79 06 33 63 <+33%206%2079%2006%2033%2063> > *thibault.tabani@altran.com * > *www.altran.fr * > > > > [image: Description : Description : cid:image002.png@01CD89E1.42D19210] > [image: Description : Description : > cid:image003.png@01CD89E1.42D19210] [ima= ge: > Description : Description : LinkedIn_signatureMail] > [image: Description : > Description : pictog_viadeo] > > > --001a114104d0fa0e5b0557e8312c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thibault,
thank you for your interest in the draft,= much appreciated. Please don't be discouraged that it lapsed, we can f= ix it easily. I think that authors had similar to your idea when we've = started thinking about BFD supporting VRRP. And like you we haven't fou= nd any reference in existing documents, hence this draft draft-nitish-vrrp-= bfd. Would be much obliged if you review and share your comments, suggestio= n regarding solutions proposed in the draft.

Regar= ds,
Greg

On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault <thi= bault.tabani@altran.com> wrote:

Hello,

=C2=A0

I am working at improving VRRP = convergence time. (target a few 100=E2=80=99s of milliseconds)

=C2=A0

It appears that VRRP supports B= FD health monitoring which might be a better option than tuning VRRP aggres= sive timers.

=C2=A0

Unfortunately I cannot find any= active RFC where VRRP supports BFD. The only document I found is your draf= t document:

=C2=A0

Fast failure detection in VRRP = with BFD
draft-nitish-vrrp-bfd-= 04

=C2=A0

Unfortunately date expires of t= his document.=C2=A0 As BFD support for VRRP is implemented on most routers,= I suppose that an active RFC might exist on that specific BFD implementati= on within VRRP. (new backup advertisement messages=E2=80=A6.peer table=E2=80=A6.)

br

=C2=A0

=C2=A0

T= hibault TABANI
architect Altran Connected Solutions
Altran France

<= br> 3D"cid:image001.png@01CF8AFD.950B79F0"

<= u>=C2=A0

1, Impasse Charles Trenet

44800 S= aint-Herblain
France

Tel. : = +33 2 40 67 62 62
Mob. : +33 6 79 06 33 63
thibault.taba= ni@altran.com
www.altran.f= r<= /u>

= =C2=A0

3D"Description=C2=A0:3D"Description=<= a href=3D"http://linkedin.com/company/altran-france" target=3D"_blank">3D"Description=C2=A0:3D"De=

=C2=A0


--001a114104d0fa0e5b0557e8312c-- --001a114104d0fa0e5e0557e8312d Content-Type: image/jpeg; name="image005.jpg" Content-Disposition: inline; filename="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 57b62f2ead5dbaf4_0.5 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2Q== --001a114104d0fa0e5e0557e8312d Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 57b62f2ead5dbaf4_0.2 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC --001a114104d0fa0e5e0557e8312d Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 57b62f2ead5dbaf4_0.3 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJggg== --001a114104d0fa0e5e0557e8312d Content-Type: image/png; name="image004.png" Content-Disposition: inline; filename="image004.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 57b62f2ead5dbaf4_0.4 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYII= --001a114104d0fa0e5e0557e8312d Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 57b62f2ead5dbaf4_0.1 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCC --001a114104d0fa0e5e0557e8312d-- From nobody Wed Aug 30 22:51:29 2017 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 9E6BB1321EC; Wed, 30 Aug 2017 22:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.518 X-Spam-Level: X-Spam-Status: No, score=-14.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14K2CqaEbIQY; Wed, 30 Aug 2017 22:51:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79163132191; Wed, 30 Aug 2017 22:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52679; q=dns/txt; s=iport; t=1504158683; x=1505368283; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OPnOaPSLG1q+nchlf8NRd+mumOAmNjNygfnGq/0rRwA=; b=czF7J0VF/cKGYFE0hWD8k3pdEn5vuIJ+2ToLbiKka8GlTkTaCpf5m3O6 ypapgTCCYUcLLr16DEqB+PpiqmrqGxZ9ElQHTHZfjjENhUcL9f89MeXrb fjxNO2QQ5ZtJzKAwK/2vUPpmIoXPOv5LT7YNp8ntVabYp9ZYb22pYeNxz A=; X-Files: image001.png, image002.png, image003.png, image004.png, image005.jpg : 6451, 970, 950, 1272, 10079 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgBko6dZ/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFQeDcJo+gXF3hE+Cc48hA1wHASSFGwIahA9DFAECAQE?= =?us-ascii?q?BAQEBAWsohRgBAQEBAwUeAggBGzAQAgEIEQMBAgYBAQEKFQMCAgIFEAoFDBQJC?= =?us-ascii?q?AIEAQ0EAQ4NiX4DFRCuEoInJ4cQDYN/AQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+?= =?us-ascii?q?DKoICgU6BYyuCSDWCRhEzAYEmWwkWCIJVMIIxBYgdgW2TLgOCdTwChlgBBnqHf?= =?us-ascii?q?oR2DIIGWoEUg3kSiReBSYxOAgspiTkHATYhTj93FVsBhQUcgWd2iSWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="png'150?jpg'150,145?scan'150,145,208,217,150,145";a="287403790" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 05:51:19 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v7V5pII0027034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 05:51:19 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 01:51:18 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 01:51:17 -0400 From: "Nitish Gupta (nitisgup)" To: "thibault.tabani@altran.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" CC: "draft-nitish-vrrp-bfd@ietf.org" , "gregimirsky@gmail.com" , "Aditya Dogra (addogra)" , "colin@doch.org.uk" , "jefftant.ietf@gmail.com" Subject: Re: draft-nitish-vrrp-bfd Thread-Topic: draft-nitish-vrrp-bfd Thread-Index: AQHTIPDPqLd77Ub+ukaX9C4xggrCwqKdxioA Date: Thu, 31 Aug 2017 05:51:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.109.105] Content-Type: multipart/related; boundary="_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 05:51:27 -0000 --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: multipart/alternative; boundary="_000_EE790B272DC34BEE9D5A6B75178C1604ciscocom_" --_000_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhpYmF1bHQsDQoNClRoYW5rcyBmb3IgdGhlIGludGVyZXN0IGluIHRoZSBEcmFmdCwgYXBw cmVjaWF0ZSBpdC4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGxldCB1cyBrbm93IGlmIHlv dSBoYXZlIGFueSBjb21tZW50cywgc3VnZ2VzdGlvbnMuDQoNCkhpIFJUR1dHL1JUR0JGRCwNCg0K VGhlcmUgd2VyZSB0d28gc29sdXRpb25zIHByb3Bvc2VkIGluIHRoZSBkcmFmdC4NCk9uZSBwZXJ0 YWlucyB0byBtYWtpbmcgYSBwZWVyIHRhYmxlIGluIFZSUlAgYW5kIHVzZXMgcDJwIEJGRC4NClRo ZSBzZWNvbmQgc29sdXRpb24gcGVydGFpbnMgdG8gcDJtcCBCRkQuDQoNCldoaWxlIHdlIHdlcmUg d29ya2luZyBvbiB0aGUgZHJhZnQgdGhlcmUgd2FzIGFuIElQUiBhc3NvY2lhdGVkIHRvIHRoZSBE UkFGVCBhbmQgdGhlIFdHIGZlbHQgdGhhdCB3ZSBuZWVkIHRvIHdhaXQgdW50aWwgd2UgY2FuIHNl ZSB0aGUgSVBSIGFuZCB3aGF0IGl0cyBhc3NvY2lhdGVkIHRvLg0KV2UgY2FuIHNlZSB0aGF0IHRo ZSBJUFIgaXMgYXZhaWxhYmxlIGZvciB1cyB0byB2aWV3IGFuZCB3ZSBjYW4gc2VlIHRoYXQgdGhl IElQUiBpcyBhc3NvY2lhdGVkIHRvIHAybXAgQkZELg0KDQpodHRwczovL3d3dy5nb29nbGUuY29t L3BhdGVudHMvVVMyMDE3MDAwNTkxNQ0KDQpXZSBhcmUgZ29pbmcgdG8gc3VibWl0IGEgZHJhZnQg d2l0aCB0aGUgcDJwIEJGRCBzbyB0aGF0IHdlIGNhbiBjb250aW51ZSB3b3JraW5nIG9uIHRoZSBE cmFmdC4NClRoZXJlIHdhcyBsb3Qgb2YgaW50ZXJlc3QgbGFzdCB0aW1lIGFzIHdlbGwsIGp1c3Qg YmVjYXVzZSBvZiB0aGUgSVBSIGNsYWltIHdlIGhhZCBzdG9wcGVkIHRoZSB3b3JrLg0KDQpUaGFu a3MsDQpOaXRpc2gNCg0KRnJvbTogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT4N CkRhdGU6IFR1ZXNkYXksIEF1Z3VzdCAyOSwgMjAxNyBhdCAxMTowMSBBTQ0KVG86IFRBQkFOSSBU aGliYXVsdCA8dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb20+DQpDYzogImRyYWZ0LW5pdGlzaC12 cnJwLWJmZEBpZXRmLm9yZyIgPGRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZz4sICJOaXRp c2ggR3VwdGEgKG5pdGlzZ3VwKSIgPG5pdGlzZ3VwQGNpc2NvLmNvbT4sICJydGctYmZkQGlldGYu b3JnIiA8cnRnLWJmZEBpZXRmLm9yZz4sICJydGd3Z0BpZXRmLm9yZyIgPHJ0Z3dnQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmVzZW50LUZyb206IDxhbGlh cy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRvOiA8bml0aXNndXBAY2lzY28uY29tPiwgPGFk ZG9ncmFAY2lzY28uY29tPiwgPGNvbGluQGRvY2gub3JnLnVrPiwgPGdyZWdpbWlyc2t5QGdtYWls LmNvbT4sIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4NClJlc2VudC1EYXRlOiBUdWVzZGF5LCBB dWd1c3QgMjksIDIwMTcgYXQgMTE6MDEgQU0NCg0KSGkgVGhpYmF1bHQsDQp0aGFuayB5b3UgZm9y IHlvdXIgaW50ZXJlc3QgaW4gdGhlIGRyYWZ0LCBtdWNoIGFwcHJlY2lhdGVkLiBQbGVhc2UgZG9u J3QgYmUgZGlzY291cmFnZWQgdGhhdCBpdCBsYXBzZWQsIHdlIGNhbiBmaXggaXQgZWFzaWx5LiBJ IHRoaW5rIHRoYXQgYXV0aG9ycyBoYWQgc2ltaWxhciB0byB5b3VyIGlkZWEgd2hlbiB3ZSd2ZSBz dGFydGVkIHRoaW5raW5nIGFib3V0IEJGRCBzdXBwb3J0aW5nIFZSUlAuIEFuZCBsaWtlIHlvdSB3 ZSBoYXZlbid0IGZvdW5kIGFueSByZWZlcmVuY2UgaW4gZXhpc3RpbmcgZG9jdW1lbnRzLCBoZW5j ZSB0aGlzIGRyYWZ0IGRyYWZ0LW5pdGlzaC12cnJwLWJmZC4gV291bGQgYmUgbXVjaCBvYmxpZ2Vk IGlmIHlvdSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMsIHN1Z2dlc3Rpb24gcmVnYXJk aW5nIHNvbHV0aW9ucyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMsDQpHcmVnDQoN Ck9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0IDk6MjAgQU0sIFRBQkFOSSBUaGliYXVsdCA8dGhpYmF1 bHQudGFiYW5pQGFsdHJhbi5jb208bWFpbHRvOnRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPj4g d3JvdGU6DQpIZWxsbywNCg0KSSBhbSB3b3JraW5nIGF0IGltcHJvdmluZyBWUlJQIGNvbnZlcmdl bmNlIHRpbWUuICh0YXJnZXQgYSBmZXcgMTAw4oCZcyBvZiBtaWxsaXNlY29uZHMpDQoNCkl0IGFw cGVhcnMgdGhhdCBWUlJQIHN1cHBvcnRzIEJGRCBoZWFsdGggbW9uaXRvcmluZyB3aGljaCBtaWdo dCBiZSBhIGJldHRlciBvcHRpb24gdGhhbiB0dW5pbmcgVlJSUCBhZ2dyZXNzaXZlIHRpbWVycy4N Cg0KVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmaW5kIGFueSBhY3RpdmUgUkZDIHdoZXJlIFZSUlAg c3VwcG9ydHMgQkZELiBUaGUgb25seSBkb2N1bWVudCBJIGZvdW5kIGlzIHlvdXIgZHJhZnQgZG9j dW1lbnQ6DQoNCkZhc3QgZmFpbHVyZSBkZXRlY3Rpb24gaW4gVlJSUCB3aXRoIEJGRA0KZHJhZnQt bml0aXNoLXZycnAtYmZkLTA0DQoNClVuZm9ydHVuYXRlbHkgZGF0ZSBleHBpcmVzIG9mIHRoaXMg ZG9jdW1lbnQuICBBcyBCRkQgc3VwcG9ydCBmb3IgVlJSUCBpcyBpbXBsZW1lbnRlZCBvbiBtb3N0 IHJvdXRlcnMsIEkgc3VwcG9zZSB0aGF0IGFuIGFjdGl2ZSBSRkMgbWlnaHQgZXhpc3Qgb24gdGhh dCBzcGVjaWZpYyBCRkQgaW1wbGVtZW50YXRpb24gd2l0aGluIFZSUlAuIChuZXcgYmFja3VwIGFk dmVydGlzZW1lbnQgbWVzc2FnZXPigKYucGVlciB0YWJsZeKApi4pDQpicg0KDQoNClRoaWJhdWx0 IFRBQkFOSQ0KYXJjaGl0ZWN0IEFsdHJhbiBDb25uZWN0ZWQgU29sdXRpb25zDQpBbHRyYW4gRnJh bmNlDQoNCltpZDppbWFnZTAwMS5wbmdAMDFDRjhBRkQuOTUwQjc5RjBdDQoNCjEsIEltcGFzc2Ug Q2hhcmxlcyBUcmVuZXQNCjQ0ODAwIFNhaW50LUhlcmJsYWluDQpGcmFuY2UNClRlbC4gOiArMzMg MiA0MCA2NyA2MiA2Mjx0ZWw6KzMzJTIwMiUyMDQwJTIwNjclMjA2MiUyMDYyPg0KTW9iLiA6ICsz MyA2IDc5IDA2IDMzIDYzPHRlbDorMzMlMjA2JTIwNzklMjAwNiUyMDMzJTIwNjM+DQp0aGliYXVs dC50YWJhbmlAYWx0cmFuLmNvbTxtYWlsdG86dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb20+DQp3 d3cuYWx0cmFuLmZyPGh0dHA6Ly93d3cuYWx0cmFuLmZyLz4NCg0KW2VzY3JpcHRpb27CoDogRGVz Y3JpcHRpb27CoDogY2lkOmltYWdlMDAyLnBuZ0AwMUNEODlFMS40MkQxOTIxMF08aHR0cDovL2Zh Y2Vib29rLmNvbS9BbHRyYW5GcmFuY2U+W2VzY3JpcHRpb27CoDogRGVzY3JpcHRpb27CoDogY2lk OmltYWdlMDAzLnBuZ0AwMUNEODlFMS40MkQxOTIxMF08aHR0cDovL3R3aXR0ZXIuY29tL0FsdHJh bkZyYW5jZT5bZXNjcmlwdGlvbsKgOiBEZXNjcmlwdGlvbsKgOiBMaW5rZWRJbl9zaWduYXR1cmVN YWlsXTxodHRwOi8vbGlua2VkaW4uY29tL2NvbXBhbnkvYWx0cmFuLWZyYW5jZT5bZXNjcmlwdGlv bsKgOiBEZXNjcmlwdGlvbsKgOiBwaWN0b2dfdmlhZGVvXTxodHRwOi8vd3d3LnZpYWRlby5jb20v ZnIvY29tcGFueS9hbHRyYW4+DQoNCg0K --_000_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9CE34D8DA3528042A36BEA22C2101CE9@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLW0tMzg4MTIzNTUz NzQ2NjM0ODczMmZpbGVuYW1lDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTM4ODEyMzU1Mzc0 NjYzNDg3MzJmaWxlbmFtZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxl LW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIFRoaWJhdWx0LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmkiPlRoYW5rcyBmb3IgdGhlIGludGVyZXN0IGluIHRoZSBEcmFmdCwgYXBwcmVjaWF0 ZSBpdC4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBoYXZl IGFueSBjb21tZW50cywgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkg UlRHV0cvUlRHQkZELDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZXJlIHdlcmUgdHdvIHNv bHV0aW9ucyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+T25lIHBlcnRhaW5zIHRvIG1ha2luZyBhIHBlZXIgdGFibGUgaW4gVlJSUCBh bmQgdXNlcyBwMnAgQkZELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRo ZSBzZWNvbmQgc29sdXRpb24gcGVydGFpbnMgdG8gcDJtcCBCRkQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+V2hpbGUgd2Ugd2VyZSB3b3JraW5nIG9uIHRoZSBkcmFmdCB0aGVyZSB3YXMgYW4g SVBSIGFzc29jaWF0ZWQgdG8gdGhlIERSQUZUIGFuZCB0aGUgV0cgZmVsdCB0aGF0IHdlIG5lZWQg dG8gd2FpdCB1bnRpbCB3ZSBjYW4gc2VlIHRoZSBJUFIgYW5kIHdoYXQgaXRzIGFzc29jaWF0ZWQg dG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+V2UgY2FuIHNlZSB0aGF0 IHRoZSBJUFIgaXMgYXZhaWxhYmxlIGZvciB1cyB0byB2aWV3IGFuZCB3ZSBjYW4gc2VlIHRoYXQg dGhlIElQUiBpcyBhc3NvY2lhdGVkIHRvIHAybXAgQkZELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli cmkiPmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vcGF0ZW50cy9VUzIwMTcwMDA1OTE1PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+V2UgYXJlIGdvaW5nIHRvIHN1Ym1pdCBhIGRyYWZ0IHdpdGggdGhl IHAycCBCRkQgc28gdGhhdCB3ZSBjYW4gY29udGludWUgd29ya2luZyBvbiB0aGUgRHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhlcmUgd2FzIGxvdCBvZiBpbnRl cmVzdCBsYXN0IHRpbWUgYXMgd2VsbCwganVzdCBiZWNhdXNlIG9mIHRoZSBJUFIgY2xhaW0gd2Ug aGFkIHN0b3BwZWQgdGhlIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk5pdGlzaDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkdyZWcgTWlyc2t5 ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXks IEF1Z3VzdCAyOSwgMjAxNyBhdCAxMTowMSBBTTxicj4NCjxiPlRvOiA8L2I+VEFCQU5JIFRoaWJh dWx0ICZsdDt0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O2RyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtbml0aXNo LXZycnAtYmZkQGlldGYub3JnJmd0OywgJnF1b3Q7Tml0aXNoIEd1cHRhIChuaXRpc2d1cCkmcXVv dDsgJmx0O25pdGlzZ3VwQGNpc2NvLmNvbSZndDssICZxdW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVv dDsgJmx0O3J0Zy1iZmRAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtydGd3Z0BpZXRmLm9yZyZxdW90OyAm bHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBkcmFmdC1uaXRp c2gtdnJycC1iZmQ8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGll dGYub3JnJmd0Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDtuaXRpc2d1cEBjaXNjby5jb20m Z3Q7LCAmbHQ7YWRkb2dyYUBjaXNjby5jb20mZ3Q7LCAmbHQ7Y29saW5AZG9jaC5vcmcudWsmZ3Q7 LCAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0OywgJmx0O2plZmZ0YW50LmlldGZAZ21haWwu Y29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+VHVlc2RheSwgQXVndXN0IDI5LCAyMDE3 IGF0IDExOjAxIEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBUaGliYXVsdCwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+dGhhbmsgeW91IGZvciB5b3VyIGludGVyZXN0IGluIHRoZSBkcmFm dCwgbXVjaCBhcHByZWNpYXRlZC4gUGxlYXNlIGRvbid0IGJlIGRpc2NvdXJhZ2VkIHRoYXQgaXQg bGFwc2VkLCB3ZSBjYW4gZml4IGl0IGVhc2lseS4gSSB0aGluayB0aGF0IGF1dGhvcnMgaGFkIHNp bWlsYXIgdG8geW91ciBpZGVhIHdoZW4gd2UndmUgc3RhcnRlZCB0aGlua2luZyBhYm91dCBCRkQg c3VwcG9ydGluZyBWUlJQLiBBbmQgbGlrZQ0KIHlvdSB3ZSBoYXZlbid0IGZvdW5kIGFueSByZWZl cmVuY2UgaW4gZXhpc3RpbmcgZG9jdW1lbnRzLCBoZW5jZSB0aGlzIGRyYWZ0IGRyYWZ0LW5pdGlz aC12cnJwLWJmZC4gV291bGQgYmUgbXVjaCBvYmxpZ2VkIGlmIHlvdSByZXZpZXcgYW5kIHNoYXJl IHlvdXIgY29tbWVudHMsIHN1Z2dlc3Rpb24gcmVnYXJkaW5nIHNvbHV0aW9ucyBwcm9wb3NlZCBp biB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5HcmVnPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMjksIDIwMTcgYXQgOToyMCBBTSwgVEFCQU5JIFRo aWJhdWx0ICZsdDs8YSBocmVmPSJtYWlsdG86dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb20iIHRh cmdldD0iX2JsYW5rIj50aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+SGVsbG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIHdvcmtpbmcgYXQgaW1wcm92aW5n IFZSUlAgY29udmVyZ2VuY2UgdGltZS4gKHRhcmdldCBhIGZldyAxMDDigJlzIG9mIG1pbGxpc2Vj b25kcyk8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBhcHBlYXJzIHRoYXQgVlJSUCBzdXBwb3J0cyBCRkQg aGVhbHRoIG1vbml0b3Jpbmcgd2hpY2ggbWlnaHQgYmUgYSBiZXR0ZXIgb3B0aW9uIHRoYW4gdHVu aW5nIFZSUlAgYWdncmVzc2l2ZSB0aW1lcnMuPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VW5mb3J0dW5hdGVs eSBJIGNhbm5vdCBmaW5kIGFueSBhY3RpdmUgUkZDIHdoZXJlIFZSUlAgc3VwcG9ydHMgQkZELiBU aGUgb25seSBkb2N1bWVudCBJIGZvdW5kIGlzIHlvdXIgZHJhZnQgZG9jdW1lbnQ6PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+RmFzdCBmYWlsdXJlIGRldGVjdGlvbiBpbiBWUlJQIHdpdGggQkZEPGJyPg0KPHNw YW4gY2xhc3M9ImdtYWlsLW0tMzg4MTIzNTUzNzQ2NjM0ODczMmZpbGVuYW1lIj5kcmFmdC1uaXRp c2gtdnJycC1iZmQtMDQ8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VW5mb3J0dW5hdGVseSBkYXRl IGV4cGlyZXMgb2YgdGhpcyBkb2N1bWVudC4mbmJzcDsgQXMgQkZEIHN1cHBvcnQgZm9yIFZSUlAg aXMgaW1wbGVtZW50ZWQgb24gbW9zdCByb3V0ZXJzLCBJIHN1cHBvc2UgdGhhdCBhbiBhY3RpdmUg UkZDIG1pZ2h0IGV4aXN0IG9uIHRoYXQgc3BlY2lmaWMgQkZEIGltcGxlbWVudGF0aW9uDQogd2l0 aGluIFZSUlAuIChuZXcgYmFja3VwIGFkdmVydGlzZW1lbnQgbWVzc2FnZXPigKYucGVlciB0YWJs ZeKApi4pPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+YnI8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzVDN0Y5MiI+ VGhpYmF1bHQgVEFCQU5JDQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM1OTU5NTkiPjxicj4NCmFyY2hpdGVjdCBBbHRy YW4gQ29ubmVjdGVkIFNvbHV0aW9ucyA8YnI+DQpBbHRyYW4gRnJhbmNlPC9zcGFuPjxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xv cjojNUM3RjkyIj48YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzVDN0Y5MiI+PGltZyBi b3JkZXI9IjAiIHdpZHRoPSIxNTIiIGhlaWdodD0iODYiIGlkPSJfeDAwMDBfaTEwNjUiIHNyYz0i Y2lkOmltYWdlMDAxLnBuZ0AwMUQzMjFFMi43RjE3QUQ2MCIgYWx0PSJpZDppbWFnZTAwMS5wbmdA MDFDRjhBRkQuOTUwQjc5RjAiPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzdGN0Y3RiI+Jm5ic3A7PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNDA0MDQwIj4xLCBJbXBhc3NlIENo YXJsZXMgVHJlbmV0PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM0MDQwNDAiPjQ0ODAwIFNhaW50LUhlcmJsYWluPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Nv bG9yOiM1OTU5NTkiPjxicj4NCkZyYW5jZTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNTk1OTU5Ij5UZWwuIDoNCjxh IGhyZWY9InRlbDomIzQzOzMzJTIwMiUyMDQwJTIwNjclMjA2MiUyMDYyIiB0YXJnZXQ9Il9ibGFu ayI+JiM0MzszMyAyIDQwIDY3IDYyIDYyPC9hPjxicj4NCk1vYi4gOiA8YSBocmVmPSJ0ZWw6JiM0 MzszMyUyMDYlMjA3OSUyMDA2JTIwMzMlMjA2MyIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7MzMgNiA3 OSAwNiAzMyA2MzwvYT48YnI+DQo8L3NwYW4+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6Ymx1ZSI+PGEgaHJlZj0ibWFpbHRvOnRoaWJh dWx0LnRhYmFuaUBhbHRyYW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGhpYmF1bHQudGFiYW5pQGFs dHJhbi5jb208L2E+PC9zcGFuPjwvdT48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNTk1OTU5Ij48YnI+DQo8L3NwYW4+PC91Pjx1Pjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YTtjb2xvcjojNTk1OTU5Ij48YSBocmVmPSJodHRwOi8vd3d3LmFsdHJhbi5mci8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+d3d3LmFsdHJhbi5mcjwvc3Bhbj48L2E+PC9zcGFu PjwvdT48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYTtjb2xvcjojNTk1OTU5Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9 Imh0dHA6Ly9mYWNlYm9vay5jb20vQWx0cmFuRnJhbmNlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOiM1OTU5NTk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIw IiB3aWR0aD0iMjUiIGhlaWdodD0iMjMiIGlkPSJfeDAwMDBfaTEwNjYiIHNyYz0iY2lkOmltYWdl MDAyLnBuZ0AwMUQzMjFFMi43RjE3QUQ2MCIgYWx0PSJlc2NyaXB0aW9uJm5ic3A7OiBEZXNjcmlw dGlvbiZuYnNwOzogY2lkOmltYWdlMDAyLnBuZ0AwMUNEODlFMS40MkQxOTIxMCI+PC9zcGFuPjwv YT48YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vQWx0cmFuRnJhbmNlIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTk7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcg Ym9yZGVyPSIwIiB3aWR0aD0iMjUiIGhlaWdodD0iMjMiIGlkPSJfeDAwMDBfaTEwNjciIHNyYz0i Y2lkOmltYWdlMDAzLnBuZ0AwMUQzMjFFMi43RjE3QUQ2MCIgYWx0PSJlc2NyaXB0aW9uJm5ic3A7 OiBEZXNjcmlwdGlvbiZuYnNwOzogY2lkOmltYWdlMDAzLnBuZ0AwMUNEODlFMS40MkQxOTIxMCI+ PC9zcGFuPjwvYT48YSBocmVmPSJodHRwOi8vbGlua2VkaW4uY29tL2NvbXBhbnkvYWx0cmFuLWZy YW5jZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+ PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNSIgaGVpZ2h0PSIyMyIgaWQ9Il94MDAwMF9pMTA2OCIg c3JjPSJjaWQ6aW1hZ2UwMDQucG5nQDAxRDMyMUUyLjdGMTdBRDYwIiBhbHQ9ImVzY3JpcHRpb24m bmJzcDs6IERlc2NyaXB0aW9uJm5ic3A7OiBMaW5rZWRJbl9zaWduYXR1cmVNYWlsIj48L3NwYW4+ PC9hPjxhIGhyZWY9Imh0dHA6Ly93d3cudmlhZGVvLmNvbS9mci9jb21wYW55L2FsdHJhbiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3Jk ZXI9IjAiIHdpZHRoPSIyNiIgaGVpZ2h0PSIyNSIgaWQ9Il94MDAwMF9pMTA2OSIgc3JjPSJjaWQ6 aW1hZ2UwMDUuanBnQDAxRDMyMUUyLjdGMTdBRDYwIiBhbHQ9ImVzY3JpcHRpb24mbmJzcDs6IERl c2NyaXB0aW9uJm5ic3A7OiBwaWN0b2dfdmlhZGVvIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EE790B272DC34BEE9D5A6B75178C1604ciscocom_-- --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=6451; creation-date="Thu, 31 Aug 2017 05:51:17 GMT"; modification-date="Thu, 31 Aug 2017 05:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCCAA== --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=970; creation-date="Thu, 31 Aug 2017 05:51:17 GMT"; modification-date="Thu, 31 Aug 2017 05:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AA== --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=950; creation-date="Thu, 31 Aug 2017 05:51:17 GMT"; modification-date="Thu, 31 Aug 2017 05:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJgggA= --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=1272; creation-date="Thu, 31 Aug 2017 05:51:17 GMT"; modification-date="Thu, 31 Aug 2017 05:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYIIA --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=10079; creation-date="Thu, 31 Aug 2017 05:51:17 GMT"; modification-date="Thu, 31 Aug 2017 05:51:17 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2QA= --_008_EE790B272DC34BEE9D5A6B75178C1604ciscocom_-- From nobody Wed Aug 30 23:39:34 2017 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 F25791321A2; Wed, 30 Aug 2017 23:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.518 X-Spam-Level: X-Spam-Status: No, score=-14.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxgjBfNL0Kid; Wed, 30 Aug 2017 23:39:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC908124207; Wed, 30 Aug 2017 23:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56075; q=dns/txt; s=iport; t=1504161567; x=1505371167; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XmXC+r4WG6/SMe8ONnHzmGlznSUpc9iLs1cyq6ousuc=; b=SpQb1AhIuHPEYziz+O094DxIxDGzNPIfxAhpIkUDZ5vZaI4ER9MRrSE3 g0by7npBN01+49rM47VauY2vXGRaNk/YW9dueAtRJZgaNIcEQpAD72ThB amTB5onArHgOcJIgLTkabkjnMlyRw8hE30LffJGvS7pxtqvpg6Fatcy2m g=; X-Files: image001.png, image002.png, image003.png, image004.png, image005.jpg : 6452, 971, 951, 1273, 10080 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAwDZrqdZ/49dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFQeDcJo+gU8id4RPgnOPIQNcBwEkhRsCGoQQQxQBAgE?= =?us-ascii?q?BAQEBAQFrKIUYAQEBAQMFHgIIARswEAIBCBEDAQIGAQEBChUDAgICBRAKBQwUC?= =?us-ascii?q?QgCBAENBAEODYl+AxUQrl2CJyeHEA2DfwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4?= =?us-ascii?q?PgyqCAoFOgWMrC4I9NYJGETMBgSZbCRYIglUwgjEFiB2BbZMuA4J1PAKGWAEGe?= =?us-ascii?q?od+hHaCElqBFIN5EokXgUmMTgILKYk5BwE2IU4/dxVbAYUFHIFndgGJJIEPAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="png'150?jpg'150,145?scan'150,145,208,217,150,145";a="474386479" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 06:39:15 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v7V6dE8u028841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 06:39:14 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 02:39:13 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 02:39:13 -0400 From: "Nitish Gupta (nitisgup)" To: "thibault.tabani@altran.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" CC: "draft-nitish-vrrp-bfd@ietf.org" , "gregimirsky@gmail.com" , "Aditya Dogra (addogra)" , "colin@doch.org.uk" , "jefftant.ietf@gmail.com" Subject: Re: draft-nitish-vrrp-bfd Thread-Topic: draft-nitish-vrrp-bfd Thread-Index: AQHTIPDPqLd77Ub+ukaX9C4xggrCwqKdxioAgAANY4A= Date: Thu, 31 Aug 2017 06:39:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.109.105] Content-Type: multipart/related; boundary="_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:39:31 -0000 --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: multipart/alternative; boundary="_000_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_" --_000_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCB0aGUgZHJhZnQgZm9yIFZSUlAgd2l0aCBwMnAg QkZELg0KUGxlYXNlIHJldmlldyBhbmQgbGV0IHVzIGtub3cgeW91ciBjb21tZW50cyBhbmQgc3Vn Z2VzdGlvbnMuDQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbml0 aXNoLXZycnAtYmZkLXAycC0wMC50eHQNCg0KVGhhbmtzLA0KTml0aXNoDQpGcm9tOiAiTml0aXNo IEd1cHRhIChuaXRpc2d1cCkiIDxuaXRpc2d1cEBjaXNjby5jb20+DQpEYXRlOiBXZWRuZXNkYXks IEF1Z3VzdCAzMCwgMjAxNyBhdCAxMDo1MSBQTQ0KVG86ICJ0aGliYXVsdC50YWJhbmlAYWx0cmFu LmNvbSIgPHRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPiwgInJ0Zy1iZmRAaWV0Zi5vcmciIDxy dGctYmZkQGlldGYub3JnPiwgInJ0Z3dnQGlldGYub3JnIiA8cnRnd2dAaWV0Zi5vcmc+DQpDYzog ImRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZyIgPGRyYWZ0LW5pdGlzaC12cnJwLWJmZEBp ZXRmLm9yZz4sICJncmVnaW1pcnNreUBnbWFpbC5jb20iIDxncmVnaW1pcnNreUBnbWFpbC5jb20+ LCAiQWRpdHlhIERvZ3JhIChhZGRvZ3JhKSIgPGFkZG9ncmFAY2lzY28uY29tPiwgImNvbGluQGRv Y2gub3JnLnVrIiA8Y29saW5AZG9jaC5vcmcudWs+LCAiamVmZnRhbnQuaWV0ZkBnbWFpbC5jb20i IDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBkcmFmdC1uaXRpc2gtdnJy cC1iZmQNCg0KSGkgVGhpYmF1bHQsDQoNClRoYW5rcyBmb3IgdGhlIGludGVyZXN0IGluIHRoZSBE cmFmdCwgYXBwcmVjaWF0ZSBpdC4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIGxldCB1cyBr bm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cywgc3VnZ2VzdGlvbnMuDQoNCkhpIFJUR1dHL1JU R0JGRCwNCg0KVGhlcmUgd2VyZSB0d28gc29sdXRpb25zIHByb3Bvc2VkIGluIHRoZSBkcmFmdC4N Ck9uZSBwZXJ0YWlucyB0byBtYWtpbmcgYSBwZWVyIHRhYmxlIGluIFZSUlAgYW5kIHVzZXMgcDJw IEJGRC4NClRoZSBzZWNvbmQgc29sdXRpb24gcGVydGFpbnMgdG8gcDJtcCBCRkQuDQoNCldoaWxl IHdlIHdlcmUgd29ya2luZyBvbiB0aGUgZHJhZnQgdGhlcmUgd2FzIGFuIElQUiBhc3NvY2lhdGVk IHRvIHRoZSBEUkFGVCBhbmQgdGhlIFdHIGZlbHQgdGhhdCB3ZSBuZWVkIHRvIHdhaXQgdW50aWwg d2UgY2FuIHNlZSB0aGUgSVBSIGFuZCB3aGF0IGl0cyBhc3NvY2lhdGVkIHRvLg0KV2UgY2FuIHNl ZSB0aGF0IHRoZSBJUFIgaXMgYXZhaWxhYmxlIGZvciB1cyB0byB2aWV3IGFuZCB3ZSBjYW4gc2Vl IHRoYXQgdGhlIElQUiBpcyBhc3NvY2lhdGVkIHRvIHAybXAgQkZELg0KDQpodHRwczovL3d3dy5n b29nbGUuY29tL3BhdGVudHMvVVMyMDE3MDAwNTkxNQ0KDQpXZSBhcmUgZ29pbmcgdG8gc3VibWl0 IGEgZHJhZnQgd2l0aCB0aGUgcDJwIEJGRCBzbyB0aGF0IHdlIGNhbiBjb250aW51ZSB3b3JraW5n IG9uIHRoZSBEcmFmdC4NClRoZXJlIHdhcyBsb3Qgb2YgaW50ZXJlc3QgbGFzdCB0aW1lIGFzIHdl bGwsIGp1c3QgYmVjYXVzZSBvZiB0aGUgSVBSIGNsYWltIHdlIGhhZCBzdG9wcGVkIHRoZSB3b3Jr Lg0KDQpUaGFua3MsDQpOaXRpc2gNCg0KRnJvbTogR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdt YWlsLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEF1Z3VzdCAyOSwgMjAxNyBhdCAxMTowMSBBTQ0KVG86 IFRBQkFOSSBUaGliYXVsdCA8dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb20+DQpDYzogImRyYWZ0 LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZyIgPGRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9y Zz4sICJOaXRpc2ggR3VwdGEgKG5pdGlzZ3VwKSIgPG5pdGlzZ3VwQGNpc2NvLmNvbT4sICJydGct YmZkQGlldGYub3JnIiA8cnRnLWJmZEBpZXRmLm9yZz4sICJydGd3Z0BpZXRmLm9yZyIgPHJ0Z3dn QGlldGYub3JnPg0KU3ViamVjdDogUmU6IGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmVzZW50LUZy b206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRvOiA8bml0aXNndXBAY2lzY28u Y29tPiwgPGFkZG9ncmFAY2lzY28uY29tPiwgPGNvbGluQGRvY2gub3JnLnVrPiwgPGdyZWdpbWly c2t5QGdtYWlsLmNvbT4sIDxqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4NClJlc2VudC1EYXRlOiBU dWVzZGF5LCBBdWd1c3QgMjksIDIwMTcgYXQgMTE6MDEgQU0NCg0KSGkgVGhpYmF1bHQsDQp0aGFu ayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QgaW4gdGhlIGRyYWZ0LCBtdWNoIGFwcHJlY2lhdGVkLiBQ bGVhc2UgZG9uJ3QgYmUgZGlzY291cmFnZWQgdGhhdCBpdCBsYXBzZWQsIHdlIGNhbiBmaXggaXQg ZWFzaWx5LiBJIHRoaW5rIHRoYXQgYXV0aG9ycyBoYWQgc2ltaWxhciB0byB5b3VyIGlkZWEgd2hl biB3ZSd2ZSBzdGFydGVkIHRoaW5raW5nIGFib3V0IEJGRCBzdXBwb3J0aW5nIFZSUlAuIEFuZCBs aWtlIHlvdSB3ZSBoYXZlbid0IGZvdW5kIGFueSByZWZlcmVuY2UgaW4gZXhpc3RpbmcgZG9jdW1l bnRzLCBoZW5jZSB0aGlzIGRyYWZ0IGRyYWZ0LW5pdGlzaC12cnJwLWJmZC4gV291bGQgYmUgbXVj aCBvYmxpZ2VkIGlmIHlvdSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMsIHN1Z2dlc3Rp b24gcmVnYXJkaW5nIHNvbHV0aW9ucyBwcm9wb3NlZCBpbiB0aGUgZHJhZnQuDQoNClJlZ2FyZHMs DQpHcmVnDQoNCk9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0IDk6MjAgQU0sIFRBQkFOSSBUaGliYXVs dCA8dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb208bWFpbHRvOnRoaWJhdWx0LnRhYmFuaUBhbHRy YW4uY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KSSBhbSB3b3JraW5nIGF0IGltcHJvdmluZyBWUlJQ IGNvbnZlcmdlbmNlIHRpbWUuICh0YXJnZXQgYSBmZXcgMTAw4oCZcyBvZiBtaWxsaXNlY29uZHMp DQoNCkl0IGFwcGVhcnMgdGhhdCBWUlJQIHN1cHBvcnRzIEJGRCBoZWFsdGggbW9uaXRvcmluZyB3 aGljaCBtaWdodCBiZSBhIGJldHRlciBvcHRpb24gdGhhbiB0dW5pbmcgVlJSUCBhZ2dyZXNzaXZl IHRpbWVycy4NCg0KVW5mb3J0dW5hdGVseSBJIGNhbm5vdCBmaW5kIGFueSBhY3RpdmUgUkZDIHdo ZXJlIFZSUlAgc3VwcG9ydHMgQkZELiBUaGUgb25seSBkb2N1bWVudCBJIGZvdW5kIGlzIHlvdXIg ZHJhZnQgZG9jdW1lbnQ6DQoNCkZhc3QgZmFpbHVyZSBkZXRlY3Rpb24gaW4gVlJSUCB3aXRoIEJG RA0KZHJhZnQtbml0aXNoLXZycnAtYmZkLTA0DQoNClVuZm9ydHVuYXRlbHkgZGF0ZSBleHBpcmVz IG9mIHRoaXMgZG9jdW1lbnQuICBBcyBCRkQgc3VwcG9ydCBmb3IgVlJSUCBpcyBpbXBsZW1lbnRl ZCBvbiBtb3N0IHJvdXRlcnMsIEkgc3VwcG9zZSB0aGF0IGFuIGFjdGl2ZSBSRkMgbWlnaHQgZXhp c3Qgb24gdGhhdCBzcGVjaWZpYyBCRkQgaW1wbGVtZW50YXRpb24gd2l0aGluIFZSUlAuIChuZXcg YmFja3VwIGFkdmVydGlzZW1lbnQgbWVzc2FnZXPigKYucGVlciB0YWJsZeKApi4pDQpicg0KDQoN ClRoaWJhdWx0IFRBQkFOSQ0KYXJjaGl0ZWN0IEFsdHJhbiBDb25uZWN0ZWQgU29sdXRpb25zDQpB bHRyYW4gRnJhbmNlDQoNCltjaWQ6aW1hZ2UwMDEucG5nQDAxRDMyMUU5LjMxMTg1MDkwXQ0KDQox LCBJbXBhc3NlIENoYXJsZXMgVHJlbmV0DQo0NDgwMCBTYWludC1IZXJibGFpbg0KRnJhbmNlDQpU ZWwuIDogKzMzIDIgNDAgNjcgNjIgNjI8dGVsOiszMyUyMDIlMjA0MCUyMDY3JTIwNjIlMjA2Mj4N Ck1vYi4gOiArMzMgNiA3OSAwNiAzMyA2Mzx0ZWw6KzMzJTIwNiUyMDc5JTIwMDYlMjAzMyUyMDYz Pg0KdGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb208bWFpbHRvOnRoaWJhdWx0LnRhYmFuaUBhbHRy YW4uY29tPg0Kd3d3LmFsdHJhbi5mcjxodHRwOi8vd3d3LmFsdHJhbi5mci8+DQoNCltzY3JpcHRp b27CoDogRGVzY3JpcHRpb27CoDogY2lkOmltYWdlMDAyLnBuZ0AwMUNEODlFMS40MkQxOTIxMF08 aHR0cDovL2ZhY2Vib29rLmNvbS9BbHRyYW5GcmFuY2U+W3NjcmlwdGlvbsKgOiBEZXNjcmlwdGlv bsKgOiBjaWQ6aW1hZ2UwMDMucG5nQDAxQ0Q4OUUxLjQyRDE5MjEwXTxodHRwOi8vdHdpdHRlci5j b20vQWx0cmFuRnJhbmNlPltzY3JpcHRpb27CoDogRGVzY3JpcHRpb27CoDogTGlua2VkSW5fc2ln bmF0dXJlTWFpbF08aHR0cDovL2xpbmtlZGluLmNvbS9jb21wYW55L2FsdHJhbi1mcmFuY2U+W3Nj cmlwdGlvbsKgOiBEZXNjcmlwdGlvbsKgOiBwaWN0b2dfdmlhZGVvXTxodHRwOi8vd3d3LnZpYWRl by5jb20vZnIvY29tcGFueS9hbHRyYW4+DQoNCg0K --_000_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <66D4FA00595BB94486DB4D908528B2A5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLW0tMzg4MTIzNTUz NzQ2NjM0ODczMmZpbGVuYW1lDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTM4ODEyMzU1Mzc0 NjYzNDg3MzJmaWxlbmFtZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5IaSBBbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+V2UgaGF2ZSBzdWJtaXR0ZWQg dGhlIGRyYWZ0IGZvciBWUlJQIHdpdGggcDJwIEJGRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5QbGVhc2UgcmV2aWV3IGFuZCBsZXQgdXMga25vdyB5b3VyIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2E7Y29sb3I6IzAwMDBFOSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LW5pdGlzaC12cnJwLWJmZC1wMnAtMDAudHh0PC9zcGFuPjwvdT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Tml0aXNo PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayI+JnF1b3Q7Tml0aXNoIEd1cHRhIChuaXRpc2d1cCkmcXVvdDsgJmx0O25p dGlzZ3VwQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBBdWd1c3Qg MzAsIDIwMTcgYXQgMTA6NTEgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O3RoaWJhdWx0LnRhYmFu aUBhbHRyYW4uY29tJnF1b3Q7ICZsdDt0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSZndDssICZx dW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Zy1iZmRAaWV0Zi5vcmcmZ3Q7LCAmcXVv dDtydGd3Z0BpZXRmLm9yZyZxdW90OyAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtkcmFmdC1uaXRpc2gtdnJycC1iZmRAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0 LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZyZndDssICZxdW90O2dyZWdpbWlyc2t5QGdtYWlsLmNv bSZxdW90OyAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0OywgJnF1b3Q7QWRpdHlhIERvZ3Jh IChhZGRvZ3JhKSZxdW90OyAmbHQ7YWRkb2dyYUBjaXNjby5jb20mZ3Q7LCAmcXVvdDtjb2xpbkBk b2NoLm9yZy51ayZxdW90OyAmbHQ7Y29saW5AZG9jaC5vcmcudWsmZ3Q7LCAmcXVvdDtqZWZmdGFu dC5pZXRmQGdtYWlsLmNvbSZxdW90OyAmbHQ7amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBkcmFmdC1uaXRpc2gtdnJycC1iZmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkgVGhpYmF1bHQsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzIGZvciB0aGUgaW50ZXJlc3QgaW4gdGhlIERyYWZ0LCBh cHByZWNpYXRlIGl0LiBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgbGV0IHVzIGtub3cgaWYg eW91IGhhdmUgYW55IGNvbW1lbnRzLCBzdWdnZXN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpIj5IaSBSVEdXRy9SVEdCRkQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhlcmUgd2Vy ZSB0d28gc29sdXRpb25zIHByb3Bvc2VkIGluIHRoZSBkcmFmdC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj5PbmUgcGVydGFpbnMgdG8gbWFraW5nIGEgcGVlciB0YWJsZSBp biBWUlJQIGFuZCB1c2VzIHAycCBCRkQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+VGhlIHNlY29uZCBzb2x1dGlvbiBwZXJ0YWlucyB0byBwMm1wIEJGRC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpIj5XaGlsZSB3ZSB3ZXJlIHdvcmtpbmcgb24gdGhlIGRyYWZ0IHRoZXJl IHdhcyBhbiBJUFIgYXNzb2NpYXRlZCB0byB0aGUgRFJBRlQgYW5kIHRoZSBXRyBmZWx0IHRoYXQg d2UgbmVlZCB0byB3YWl0IHVudGlsIHdlIGNhbiBzZWUgdGhlIElQUiBhbmQgd2hhdCBpdHMgYXNz b2NpYXRlZCB0by48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBjYW4g c2VlIHRoYXQgdGhlIElQUiBpcyBhdmFpbGFibGUgZm9yIHVzIHRvIHZpZXcgYW5kIHdlIGNhbiBz ZWUgdGhhdCB0aGUgSVBSIGlzIGFzc29jaWF0ZWQgdG8gcDJtcCBCRkQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9wYXRlbnRzL1VTMjAxNzAwMDU5MTU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBhcmUgZ29pbmcgdG8gc3VibWl0IGEgZHJhZnQg d2l0aCB0aGUgcDJwIEJGRCBzbyB0aGF0IHdlIGNhbiBjb250aW51ZSB3b3JraW5nIG9uIHRoZSBE cmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGVyZSB3YXMgbG90 IG9mIGludGVyZXN0IGxhc3QgdGltZSBhcyB3ZWxsLCBqdXN0IGJlY2F1c2Ugb2YgdGhlIElQUiBj bGFpbSB3ZSBoYWQgc3RvcHBlZCB0aGUgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5U aGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Tml0aXNoPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+R3Jl ZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgQXVndXN0IDI5LCAyMDE3IGF0IDExOjAxIEFNPGJyPg0KPGI+VG86IDwvYj5UQUJB TkkgVGhpYmF1bHQgJmx0O3RoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+JnF1b3Q7ZHJhZnQtbml0aXNoLXZycnAtYmZkQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFm dC1uaXRpc2gtdnJycC1iZmRAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtOaXRpc2ggR3VwdGEgKG5pdGlz Z3VwKSZxdW90OyAmbHQ7bml0aXNndXBAY2lzY28uY29tJmd0OywgJnF1b3Q7cnRnLWJmZEBpZXRm Lm9yZyZxdW90OyAmbHQ7cnRnLWJmZEBpZXRmLm9yZyZndDssICZxdW90O3J0Z3dnQGlldGYub3Jn JnF1b3Q7ICZsdDtydGd3Z0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IGRy YWZ0LW5pdGlzaC12cnJwLWJmZDxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+Jmx0O25pdGlzZ3VwQGNp c2NvLmNvbSZndDssICZsdDthZGRvZ3JhQGNpc2NvLmNvbSZndDssICZsdDtjb2xpbkBkb2NoLm9y Zy51ayZndDssICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20mZ3Q7LCAmbHQ7amVmZnRhbnQuaWV0 ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5UdWVzZGF5LCBBdWd1c3Qg MjksIDIwMTcgYXQgMTE6MDEgQU08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFRoaWJhdWx0LCA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QgaW4g dGhlIGRyYWZ0LCBtdWNoIGFwcHJlY2lhdGVkLiBQbGVhc2UgZG9uJ3QgYmUgZGlzY291cmFnZWQg dGhhdCBpdCBsYXBzZWQsIHdlIGNhbiBmaXggaXQgZWFzaWx5LiBJIHRoaW5rIHRoYXQgYXV0aG9y cyBoYWQgc2ltaWxhciB0byB5b3VyIGlkZWEgd2hlbiB3ZSd2ZSBzdGFydGVkIHRoaW5raW5nIGFi b3V0IEJGRCBzdXBwb3J0aW5nIFZSUlAuIEFuZCBsaWtlDQogeW91IHdlIGhhdmVuJ3QgZm91bmQg YW55IHJlZmVyZW5jZSBpbiBleGlzdGluZyBkb2N1bWVudHMsIGhlbmNlIHRoaXMgZHJhZnQgZHJh ZnQtbml0aXNoLXZycnAtYmZkLiBXb3VsZCBiZSBtdWNoIG9ibGlnZWQgaWYgeW91IHJldmlldyBh bmQgc2hhcmUgeW91ciBjb21tZW50cywgc3VnZ2VzdGlvbiByZWdhcmRpbmcgc29sdXRpb25zIHBy b3Bvc2VkIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAyOSwgMjAxNyBhdCA5OjIwIEFNLCBU QUJBTkkgVGhpYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFu LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIGFtIHdvcmtpbmcgYXQgaW1wcm92aW5nIFZSUlAgY29udmVy Z2VuY2UgdGltZS4gKHRhcmdldCBhIGZldyAxMDDigJlzIG9mIG1pbGxpc2Vjb25kcyk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGFwcGVhcnMgdGhhdCBWUlJQIHN1cHBvcnRzIEJGRCBo ZWFsdGggbW9uaXRvcmluZyB3aGljaCBtaWdodCBiZSBhIGJldHRlciBvcHRpb24gdGhhbiB0dW5p bmcgVlJSUCBhZ2dyZXNzaXZlIHRpbWVycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlVu Zm9ydHVuYXRlbHkgSSBjYW5ub3QgZmluZCBhbnkgYWN0aXZlIFJGQyB3aGVyZSBWUlJQIHN1cHBv cnRzIEJGRC4gVGhlIG9ubHkgZG9jdW1lbnQgSSBmb3VuZCBpcyB5b3VyIGRyYWZ0IGRvY3VtZW50 OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RmFzdCBmYWlsdXJlIGRldGVjdGlvbiBpbiBW UlJQIHdpdGggQkZEPGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLW0tMzg4MTIzNTUzNzQ2NjM0ODcz MmZpbGVuYW1lIj5kcmFmdC1uaXRpc2gtdnJycC1iZmQtMDQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5VbmZvcnR1bmF0ZWx5IGRhdGUgZXhwaXJlcyBvZiB0aGlzIGRvY3VtZW50 LiZuYnNwOyBBcyBCRkQgc3VwcG9ydCBmb3IgVlJSUCBpcyBpbXBsZW1lbnRlZCBvbiBtb3N0IHJv dXRlcnMsIEkgc3VwcG9zZSB0aGF0IGFuIGFjdGl2ZSBSRkMgbWlnaHQgZXhpc3Qgb24gdGhhdCBz cGVjaWZpYyBCRkQgaW1wbGVtZW50YXRpb24NCiB3aXRoaW4gVlJSUC4gKG5ldyBiYWNrdXAgYWR2 ZXJ0aXNlbWVudCBtZXNzYWdlc+KApi5wZWVyIHRhYmxl4oCmLik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+YnI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzVDN0Y5MiI+VGhp YmF1bHQgVEFCQU5JDQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM1OTU5NTkiPjxicj4NCmFyY2hpdGVjdCBBbHRyYW4g Q29ubmVjdGVkIFNvbHV0aW9ucyA8YnI+DQpBbHRyYW4gRnJhbmNlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzVDN0Y5MiI+PGJyPg0KPC9zcGFuPjwv Yj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhO2NvbG9yOiM1QzdGOTIiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTUyIiBoZWln aHQ9Ijg2IiBpZD0iX3gwMDAwX2kxMDY1IiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFEMzIxRTku MzExODUwOTAiPjwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh O2NvbG9yOiM3RjdGN0YiPiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM0MDQwNDAiPjEsIEltcGFzc2Ug Q2hhcmxlcyBUcmVuZXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Nv bG9yOiM0MDQwNDAiPjQ0ODAwIFNhaW50LUhlcmJsYWluPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM1OTU5NTkiPjxicj4NCkZy YW5jZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU5NTk1 OSI+VGVsLiA6DQo8YSBocmVmPSJ0ZWw6JiM0MzszMyUyMDIlMjA0MCUyMDY3JTIwNjIlMjA2MiIg dGFyZ2V0PSJfYmxhbmsiPiYjNDM7MzMgMiA0MCA2NyA2MiA2MjwvYT48YnI+DQpNb2IuIDogPGEg aHJlZj0idGVsOiYjNDM7MzMlMjA2JTIwNzklMjAwNiUyMDMzJTIwNjMiIHRhcmdldD0iX2JsYW5r Ij4mIzQzOzMzIDYgNzkgMDYgMzMgNjM8L2E+PGJyPg0KPC9zcGFuPjx1PjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsdWUiPjxhIGhyZWY9 Im1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRoaWJh dWx0LnRhYmFuaUBhbHRyYW4uY29tPC9hPjwvc3Bhbj48L3U+PHU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU5NTk1OSI+PGJyPg0KPC9z cGFuPjwvdT48dT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU5NTk1OSI+PGEgaHJlZj0iaHR0cDovL3d3dy5hbHRyYW4u ZnIvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPnd3dy5hbHRyYW4uZnI8L3Nw YW4+PC9hPjwvc3Bhbj48L3U+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9y OiM1OTU5NTkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRlIiPjxhIGhyZWY9Imh0dHA6Ly9mYWNlYm9vay5jb20vQWx0cmFuRnJhbmNl IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1OTU5NTk7dGV4dC1kZWNvcmF0 aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjUiIGhlaWdodD0iMjMiIGlkPSJfeDAw MDBfaTEwNjYiIHNyYz0iY2lkOmltYWdlMDAyLnBuZ0AwMUQzMjFFOS4zMTE4NTA5MCIgYWx0PSJz Y3JpcHRpb24mbmJzcDs6IERlc2NyaXB0aW9uJm5ic3A7OiBjaWQ6aW1hZ2UwMDIucG5nQDAxQ0Q4 OUUxLjQyRDE5MjEwIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9BbHRy YW5GcmFuY2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OTt0ZXh0 LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNSIgaGVpZ2h0PSIyMyIg aWQ9Il94MDAwMF9pMTA2NyIgc3JjPSJjaWQ6aW1hZ2UwMDMucG5nQDAxRDMyMUU5LjMxMTg1MDkw IiBhbHQ9InNjcmlwdGlvbiZuYnNwOzogRGVzY3JpcHRpb24mbmJzcDs6IGNpZDppbWFnZTAwMy5w bmdAMDFDRDg5RTEuNDJEMTkyMTAiPjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cDovL2xpbmtlZGlu LmNvbS9jb21wYW55L2FsdHJhbi1mcmFuY2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjUiIGhlaWdodD0i MjMiIGlkPSJfeDAwMDBfaTEwNjgiIHNyYz0iY2lkOmltYWdlMDA0LnBuZ0AwMUQzMjFFOS4zMTE4 NTA5MCIgYWx0PSJzY3JpcHRpb24mbmJzcDs6IERlc2NyaXB0aW9uJm5ic3A7OiBMaW5rZWRJbl9z aWduYXR1cmVNYWlsIj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHA6Ly93d3cudmlhZGVvLmNvbS9m ci9jb21wYW55L2FsdHJhbiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29y YXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyNiIgaGVpZ2h0PSIyNSIgaWQ9Il94 MDAwMF9pMTA2OSIgc3JjPSJjaWQ6aW1hZ2UwMDUuanBnQDAxRDMyMUU5LjMxMTg1MDkwIiBhbHQ9 InNjcmlwdGlvbiZuYnNwOzogRGVzY3JpcHRpb24mbmJzcDs6IHBpY3RvZ192aWFkZW8iPjwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_-- --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=6452; creation-date="Thu, 31 Aug 2017 06:39:13 GMT"; modification-date="Thu, 31 Aug 2017 06:39:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCCAAA= --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=971; creation-date="Thu, 31 Aug 2017 06:39:13 GMT"; modification-date="Thu, 31 Aug 2017 06:39:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AAA= --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=951; creation-date="Thu, 31 Aug 2017 06:39:13 GMT"; modification-date="Thu, 31 Aug 2017 06:39:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJgggAA --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=1273; creation-date="Thu, 31 Aug 2017 06:39:13 GMT"; modification-date="Thu, 31 Aug 2017 06:39:13 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYIIAAA== --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: inline; filename="image005.jpg"; size=10080; creation-date="Thu, 31 Aug 2017 06:39:13 GMT"; modification-date="Thu, 31 Aug 2017 06:39:13 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2QAA --_008_FCB81B1088454ED3BBDD19EEADBF39A0ciscocom_-- From nobody Thu Aug 31 02:55:58 2017 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 D30CB132D47; Thu, 31 Aug 2017 02:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.518 X-Spam-Level: X-Spam-Status: No, score=-14.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62Aizzk6E0wn; Thu, 31 Aug 2017 02:55:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154B0132D41; Thu, 31 Aug 2017 02:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58512; q=dns/txt; s=iport; t=1504173353; x=1505382953; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=K1eJqEvxEDv+EClq5gbQ5eU+OhJfY9FHEJyEk5TgAYQ=; b=YVwiNPmxoNqeEaDvVkAInL39p75mEEhSNeJOkNtQTfqqNMUg+c45kttw TYgZLVX1YOOCGAdPGMweImDDL8qdJco6FTe5jht6+81Lq3xdTGm+MlNaZ +zIA6+WAxcPZnpH531JkwvkHu8uYd60Defjnp3d3RudLSO7qdIC0H5C3Z g=; X-Files: image001.png, image002.png, image003.png, image004.png, image005.jpg : 6451, 970, 950, 1272, 10079 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAwBI3KdZ/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFQeDcJo+gXF3hE+Cc48hA1wHASSFGwIahBlDFAECAQE?= =?us-ascii?q?BAQEBAWsohRgBAQEBAwUeAggBGzAQAgEIEQMBAgYBAQEKDgcDAgICFQoFDBQJC?= =?us-ascii?q?AIEAQ0EAQ4NiX4DFRCwJYInJ4cSDYN/AQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+?= =?us-ascii?q?DKoICgzGCczWCRhEzAYEmWwkWCIJVgmEFiB2BbZMxA4J1PAKEN4IhAQZ6iACEd?= =?us-ascii?q?oITWoEUg3kSiRmBSYxOAgspiTkHATYhTj93FYVhHIFndokugQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,451,1498521600"; d="png'150?jpg'150,145?scan'150,145,208,217,150,145";a="292662781" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Aug 2017 09:55:51 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7V9tpJW030234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 31 Aug 2017 09:55:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 05:55:50 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Thu, 31 Aug 2017 05:55:50 -0400 From: "Acee Lindem (acee)" To: "Nitish Gupta (nitisgup)" , "thibault.tabani@altran.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" CC: "colin@doch.org.uk" , "draft-nitish-vrrp-bfd@ietf.org" , "Aditya Dogra (addogra)" Subject: Re: draft-nitish-vrrp-bfd Thread-Topic: draft-nitish-vrrp-bfd Thread-Index: AQHTIPDTV6qxk41fsEyAvy6buwPgj6KeO3+AgAABMYA= Date: Thu, 31 Aug 2017 09:55:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/mixed; boundary="_008_D5CD54E2C53E2aceeciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 09:55:57 -0000 --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: multipart/alternative; boundary="_000_D5CD54E2C53E2aceeciscocom_" --_000_D5CD54E2C53E2aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTml0aXNoLA0KDQpJcnJlc3BlY3RpdmUgb2YgYW55IElQUiBkaXNjdXNzaW9ucywgQkZEIGlz IGluaGVyZW50bHkgYSBQMlAgcHJvdG9jb2wgYW5kLCBjb25zZXF1ZW50bHksIEkgd291bGQgdm90 ZSBmb3IgUDJQIHBlZXIgdGFibGUuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogcnRnd2cgPHJ0 Z3dnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBi ZWhhbGYgb2YgIk5pdGlzaCBHdXB0YSAobml0aXNndXApIiA8bml0aXNndXBAY2lzY28uY29tPG1h aWx0bzpuaXRpc2d1cEBjaXNjby5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEF1Z3VzdCAzMSwgMjAx NyBhdCAxOjUxIEFNDQpUbzogInRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPG1haWx0bzp0aGli YXVsdC50YWJhbmlAYWx0cmFuLmNvbT4iIDx0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbTxtYWls dG86dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb20+PiwgInJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1iZmRAaWV0Zi5vcmc+IiA8cnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRm Lm9yZz4+LCBSb3V0aW5nIFdHIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+ Pg0KQ2M6ICJjb2xpbkBkb2NoLm9yZy51azxtYWlsdG86Y29saW5AZG9jaC5vcmcudWs+IiA8Y29s aW5AZG9jaC5vcmcudWs8bWFpbHRvOmNvbGluQGRvY2gub3JnLnVrPj4sICJkcmFmdC1uaXRpc2gt dnJycC1iZmRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZz4i IDxkcmFmdC1uaXRpc2gtdnJycC1iZmRAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LW5pdGlzaC12cnJw LWJmZEBpZXRmLm9yZz4+LCAiQWRpdHlhIERvZ3JhIChhZGRvZ3JhKSIgPGFkZG9ncmFAY2lzY28u Y29tPG1haWx0bzphZGRvZ3JhQGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBSZTogZHJhZnQtbml0aXNo LXZycnAtYmZkDQoNCkhpIFRoaWJhdWx0LA0KDQpUaGFua3MgZm9yIHRoZSBpbnRlcmVzdCBpbiB0 aGUgRHJhZnQsIGFwcHJlY2lhdGUgaXQuIFBsZWFzZSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBsZXQg dXMga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMsIHN1Z2dlc3Rpb25zLg0KDQpIaSBSVEdX Ry9SVEdCRkQsDQoNClRoZXJlIHdlcmUgdHdvIHNvbHV0aW9ucyBwcm9wb3NlZCBpbiB0aGUgZHJh ZnQuDQpPbmUgcGVydGFpbnMgdG8gbWFraW5nIGEgcGVlciB0YWJsZSBpbiBWUlJQIGFuZCB1c2Vz IHAycCBCRkQuDQpUaGUgc2Vjb25kIHNvbHV0aW9uIHBlcnRhaW5zIHRvIHAybXAgQkZELg0KDQpX aGlsZSB3ZSB3ZXJlIHdvcmtpbmcgb24gdGhlIGRyYWZ0IHRoZXJlIHdhcyBhbiBJUFIgYXNzb2Np YXRlZCB0byB0aGUgRFJBRlQgYW5kIHRoZSBXRyBmZWx0IHRoYXQgd2UgbmVlZCB0byB3YWl0IHVu dGlsIHdlIGNhbiBzZWUgdGhlIElQUiBhbmQgd2hhdCBpdHMgYXNzb2NpYXRlZCB0by4NCldlIGNh biBzZWUgdGhhdCB0aGUgSVBSIGlzIGF2YWlsYWJsZSBmb3IgdXMgdG8gdmlldyBhbmQgd2UgY2Fu IHNlZSB0aGF0IHRoZSBJUFIgaXMgYXNzb2NpYXRlZCB0byBwMm1wIEJGRC4NCg0KaHR0cHM6Ly93 d3cuZ29vZ2xlLmNvbS9wYXRlbnRzL1VTMjAxNzAwMDU5MTUNCg0KV2UgYXJlIGdvaW5nIHRvIHN1 Ym1pdCBhIGRyYWZ0IHdpdGggdGhlIHAycCBCRkQgc28gdGhhdCB3ZSBjYW4gY29udGludWUgd29y a2luZyBvbiB0aGUgRHJhZnQuDQpUaGVyZSB3YXMgbG90IG9mIGludGVyZXN0IGxhc3QgdGltZSBh cyB3ZWxsLCBqdXN0IGJlY2F1c2Ugb2YgdGhlIElQUiBjbGFpbSB3ZSBoYWQgc3RvcHBlZCB0aGUg d29yay4NCg0KVGhhbmtzLA0KTml0aXNoDQoNCkZyb206IEdyZWcgTWlyc2t5IDxncmVnaW1pcnNr eUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+DQpEYXRlOiBUdWVzZGF5 LCBBdWd1c3QgMjksIDIwMTcgYXQgMTE6MDEgQU0NClRvOiBUQUJBTkkgVGhpYmF1bHQgPHRoaWJh dWx0LnRhYmFuaUBhbHRyYW4uY29tPG1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbT4+ DQpDYzogImRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtbml0aXNo LXZycnAtYmZkQGlldGYub3JnPiIgPGRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZzxtYWls dG86ZHJhZnQtbml0aXNoLXZycnAtYmZkQGlldGYub3JnPj4sICJOaXRpc2ggR3VwdGEgKG5pdGlz Z3VwKSIgPG5pdGlzZ3VwQGNpc2NvLmNvbTxtYWlsdG86bml0aXNndXBAY2lzY28uY29tPj4sICJy dGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPiIgPHJ0Zy1iZmRAaWV0Zi5v cmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+PiwgInJ0Z3dnQGlldGYub3JnPG1haWx0bzpydGd3 Z0BpZXRmLm9yZz4iIDxydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IGRyYWZ0LW5pdGlzaC12cnJwLWJmZA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnPj4NClJlc2VudC1Ubzog PG5pdGlzZ3VwQGNpc2NvLmNvbTxtYWlsdG86bml0aXNndXBAY2lzY28uY29tPj4sIDxhZGRvZ3Jh QGNpc2NvLmNvbTxtYWlsdG86YWRkb2dyYUBjaXNjby5jb20+PiwgPGNvbGluQGRvY2gub3JnLnVr PG1haWx0bzpjb2xpbkBkb2NoLm9yZy51az4+LCA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0 bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiwgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPG1haWx0 bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4+DQpSZXNlbnQtRGF0ZTogVHVlc2RheSwgQXVndXN0 IDI5LCAyMDE3IGF0IDExOjAxIEFNDQoNCkhpIFRoaWJhdWx0LA0KdGhhbmsgeW91IGZvciB5b3Vy IGludGVyZXN0IGluIHRoZSBkcmFmdCwgbXVjaCBhcHByZWNpYXRlZC4gUGxlYXNlIGRvbid0IGJl IGRpc2NvdXJhZ2VkIHRoYXQgaXQgbGFwc2VkLCB3ZSBjYW4gZml4IGl0IGVhc2lseS4gSSB0aGlu ayB0aGF0IGF1dGhvcnMgaGFkIHNpbWlsYXIgdG8geW91ciBpZGVhIHdoZW4gd2UndmUgc3RhcnRl ZCB0aGlua2luZyBhYm91dCBCRkQgc3VwcG9ydGluZyBWUlJQLiBBbmQgbGlrZSB5b3Ugd2UgaGF2 ZW4ndCBmb3VuZCBhbnkgcmVmZXJlbmNlIGluIGV4aXN0aW5nIGRvY3VtZW50cywgaGVuY2UgdGhp cyBkcmFmdCBkcmFmdC1uaXRpc2gtdnJycC1iZmQuIFdvdWxkIGJlIG11Y2ggb2JsaWdlZCBpZiB5 b3UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9uIHJlZ2FyZGluZyBz b2x1dGlvbnMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBU dWUsIEF1ZyAyOSwgMjAxNyBhdCA5OjIwIEFNLCBUQUJBTkkgVGhpYmF1bHQgPHRoaWJhdWx0LnRh YmFuaUBhbHRyYW4uY29tPG1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbT4+IHdyb3Rl Og0KSGVsbG8sDQoNCkkgYW0gd29ya2luZyBhdCBpbXByb3ZpbmcgVlJSUCBjb252ZXJnZW5jZSB0 aW1lLiAodGFyZ2V0IGEgZmV3IDEwMOKAmXMgb2YgbWlsbGlzZWNvbmRzKQ0KDQpJdCBhcHBlYXJz IHRoYXQgVlJSUCBzdXBwb3J0cyBCRkQgaGVhbHRoIG1vbml0b3Jpbmcgd2hpY2ggbWlnaHQgYmUg YSBiZXR0ZXIgb3B0aW9uIHRoYW4gdHVuaW5nIFZSUlAgYWdncmVzc2l2ZSB0aW1lcnMuDQoNClVu Zm9ydHVuYXRlbHkgSSBjYW5ub3QgZmluZCBhbnkgYWN0aXZlIFJGQyB3aGVyZSBWUlJQIHN1cHBv cnRzIEJGRC4gVGhlIG9ubHkgZG9jdW1lbnQgSSBmb3VuZCBpcyB5b3VyIGRyYWZ0IGRvY3VtZW50 Og0KDQpGYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZSUlAgd2l0aCBCRkQNCmRyYWZ0LW5pdGlz aC12cnJwLWJmZC0wNA0KDQpVbmZvcnR1bmF0ZWx5IGRhdGUgZXhwaXJlcyBvZiB0aGlzIGRvY3Vt ZW50LiAgQXMgQkZEIHN1cHBvcnQgZm9yIFZSUlAgaXMgaW1wbGVtZW50ZWQgb24gbW9zdCByb3V0 ZXJzLCBJIHN1cHBvc2UgdGhhdCBhbiBhY3RpdmUgUkZDIG1pZ2h0IGV4aXN0IG9uIHRoYXQgc3Bl Y2lmaWMgQkZEIGltcGxlbWVudGF0aW9uIHdpdGhpbiBWUlJQLiAobmV3IGJhY2t1cCBhZHZlcnRp c2VtZW50IG1lc3NhZ2Vz4oCmLnBlZXIgdGFibGXigKYuKQ0KYnINCg0KDQpUaGliYXVsdCBUQUJB TkkNCmFyY2hpdGVjdCBBbHRyYW4gQ29ubmVjdGVkIFNvbHV0aW9ucw0KQWx0cmFuIEZyYW5jZQ0K DQpbaWQ6aW1hZ2UwMDEucG5nQDAxQ0Y4QUZELjk1MEI3OUYwXQ0KDQoxLCBJbXBhc3NlIENoYXJs ZXMgVHJlbmV0DQo0NDgwMCBTYWludC1IZXJibGFpbg0KRnJhbmNlDQpUZWwuIDogKzMzIDIgNDAg NjcgNjIgNjI8dGVsOiszMyUyMDIlMjA0MCUyMDY3JTIwNjIlMjA2Mj4NCk1vYi4gOiArMzMgNiA3 OSAwNiAzMyA2Mzx0ZWw6KzMzJTIwNiUyMDc5JTIwMDYlMjAzMyUyMDYzPg0KdGhpYmF1bHQudGFi YW5pQGFsdHJhbi5jb208bWFpbHRvOnRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPg0Kd3d3LmFs dHJhbi5mcjxodHRwOi8vd3d3LmFsdHJhbi5mci8+DQoNCltlc2NyaXB0aW9uwqA6IERlc2NyaXB0 aW9uwqA6IGNpZDppbWFnZTAwMi5wbmdAMDFDRDg5RTEuNDJEMTkyMTBdPGh0dHA6Ly9mYWNlYm9v ay5jb20vQWx0cmFuRnJhbmNlPltlc2NyaXB0aW9uwqA6IERlc2NyaXB0aW9uwqA6IGNpZDppbWFn ZTAwMy5wbmdAMDFDRDg5RTEuNDJEMTkyMTBdPGh0dHA6Ly90d2l0dGVyLmNvbS9BbHRyYW5GcmFu Y2U+W2VzY3JpcHRpb27CoDogRGVzY3JpcHRpb27CoDogTGlua2VkSW5fc2lnbmF0dXJlTWFpbF08 aHR0cDovL2xpbmtlZGluLmNvbS9jb21wYW55L2FsdHJhbi1mcmFuY2U+W2VzY3JpcHRpb27CoDog RGVzY3JpcHRpb27CoDogcGljdG9nX3ZpYWRlb108aHR0cDovL3d3dy52aWFkZW8uY29tL2ZyL2Nv bXBhbnkvYWx0cmFuPg0KDQoNCg== --_000_D5CD54E2C53E2aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBOaXRpc2gs Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JcnJlc3BlY3RpdmUgb2YgYW55 IElQUiBkaXNjdXNzaW9ucywgQkZEIGlzIGluaGVyZW50bHkgYSBQMlAgcHJvdG9jb2wgYW5kLCBj b25zZXF1ZW50bHksIEkgd291bGQgdm90ZSBmb3IgUDJQIHBlZXIgdGFibGUuJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+cnRnd2cgJmx0OzxhIGhyZWY9Im1haWx0 bzpydGd3Zy1ib3VuY2VzQGlldGYub3JnIj5ydGd3Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg b24gYmVoYWxmIG9mICZxdW90O05pdGlzaCBHdXB0YSAobml0aXNndXApJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bml0aXNndXBAY2lzY28uY29tIj5uaXRpc2d1cEBjaXNjby5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNk YXksIEF1Z3VzdCAzMSwgMjAxNyBhdCAxOjUxIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnRoaWJhdWx0LnRhYmFu aUBhbHRyYW4uY29tIj50aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbTwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSI+dGhpYmF1bHQudGFiYW5p QGFsdHJhbi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5v cmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mZ3Q7LA0KIFJvdXRpbmcgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpjb2xpbkBkb2NoLm9yZy51ayI+Y29saW5AZG9jaC5vcmcudWs8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86Y29saW5AZG9jaC5vcmcudWsiPmNvbGluQGRvY2gub3JnLnVrPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1uaXRpc2gtdnJycC1iZmRAaWV0Zi5v cmciPmRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpkcmFmdC1uaXRpc2gtdnJycC1iZmRAaWV0Zi5vcmciPmRyYWZ0LW5pdGlzaC12cnJw LWJmZEBpZXRmLm9yZzwvYT4mZ3Q7LA0KICZxdW90O0FkaXR5YSBEb2dyYSAoYWRkb2dyYSkmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzphZGRvZ3JhQGNpc2NvLmNvbSI+YWRkb2dyYUBjaXNjby5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+UmU6IGRyYWZ0LW5pdGlzaC12cnJwLWJmZDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t OnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zOm12 PSJodHRwOi8vbWFjVm1sU2NoZW1hVXJpIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVD LWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9Iktl eXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHlsZT52 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2Rl ZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUg e2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLW0tMzg4MTIzNTUzNzQ2 NjM0ODczMmZpbGVuYW1lDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTM4ODEyMzU1Mzc0NjYz NDg3MzJmaWxlbmFtZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8ZGl2IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+SGkgVGhpYmF1bHQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhh bmtzIGZvciB0aGUgaW50ZXJlc3QgaW4gdGhlIERyYWZ0LCBhcHByZWNpYXRlIGl0LiBQbGVhc2Ug cmV2aWV3IHRoZSBkcmFmdCBhbmQgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRz LCBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBSVEdXRy9SVEdCRkQs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhlcmUgd2VyZSB0d28gc29sdXRpb25zIHByb3Bv c2VkIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5P bmUgcGVydGFpbnMgdG8gbWFraW5nIGEgcGVlciB0YWJsZSBpbiBWUlJQIGFuZCB1c2VzIHAycCBC RkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhlIHNlY29uZCBzb2x1 dGlvbiBwZXJ0YWlucyB0byBwMm1wIEJGRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XaGls ZSB3ZSB3ZXJlIHdvcmtpbmcgb24gdGhlIGRyYWZ0IHRoZXJlIHdhcyBhbiBJUFIgYXNzb2NpYXRl ZCB0byB0aGUgRFJBRlQgYW5kIHRoZSBXRyBmZWx0IHRoYXQgd2UgbmVlZCB0byB3YWl0IHVudGls IHdlIGNhbiBzZWUgdGhlIElQUiBhbmQgd2hhdCBpdHMgYXNzb2NpYXRlZCB0by48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5XZSBjYW4gc2VlIHRoYXQgdGhlIElQUiBpcyBh dmFpbGFibGUgZm9yIHVzIHRvIHZpZXcgYW5kIHdlIGNhbiBzZWUgdGhhdCB0aGUgSVBSIGlzIGFz c29jaWF0ZWQgdG8gcDJtcCBCRkQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PGEgaHJlZj0i aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9wYXRlbnRzL1VTMjAxNzAwMDU5MTUiPmh0dHBzOi8vd3d3 Lmdvb2dsZS5jb20vcGF0ZW50cy9VUzIwMTcwMDA1OTE1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh bGlicmkiPldlIGFyZSBnb2luZyB0byBzdWJtaXQgYSBkcmFmdCB3aXRoIHRoZSBwMnAgQkZEIHNv IHRoYXQgd2UgY2FuIGNvbnRpbnVlIHdvcmtpbmcgb24gdGhlIERyYWZ0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZXJlIHdhcyBsb3Qgb2YgaW50ZXJlc3QgbGFzdCB0 aW1lIGFzIHdlbGwsIGp1c3QgYmVjYXVzZSBvZiB0aGUgSVBSIGNsYWltIHdlIGhhZCBzdG9wcGVk IHRoZSB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5OaXRpc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5HcmVnIE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9h PiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgQXVndXN0IDI5LCAyMDE3IGF0IDExOjAx IEFNPGJyPg0KPGI+VG86IDwvYj5UQUJBTkkgVGhpYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0 aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSI+dGhpYmF1bHQudGFiYW5pQGFsdHJhbi5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LW5pdGlzaC12 cnJwLWJmZEBpZXRmLm9yZyI+ZHJhZnQtbml0aXNoLXZycnAtYmZkQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LW5pdGlzaC12cnJwLWJmZEBpZXRmLm9yZyI+ZHJh ZnQtbml0aXNoLXZycnAtYmZkQGlldGYub3JnPC9hPiZndDssICZxdW90O05pdGlzaCBHdXB0YSAo bml0aXNndXApJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bml0aXNndXBAY2lzY28uY29tIj5u aXRpc2d1cEBjaXNjby5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRnLWJm ZEBpZXRmLm9yZyI+cnRnLWJmZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpydGctYmZkQGlldGYub3JnIj5ydGctYmZkQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzpydGd3Z0BpZXRmLm9yZyI+cnRnd2dAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IGRyYWZ0LW5pdGlzaC12cnJwLWJmZDxicj4NCjxiPlJlc2Vu dC1Gcm9tOiA8L2I+Jmx0OzxhIGhyZWY9Im1haWx0bzphbGlhcy1ib3VuY2VzQGlldGYub3JnIj5h bGlhcy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOm5pdGlzZ3VwQGNpc2NvLmNvbSI+bml0aXNndXBAY2lzY28uY29tPC9h PiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86YWRkb2dyYUBjaXNjby5jb20iPmFkZG9ncmFAY2lz Y28uY29tPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86Y29saW5AZG9jaC5vcmcudWsiPmNv bGluQGRvY2gub3JnLnVrPC9hPiZndDssICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OywNCiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmplZmZ0YW50LmlldGZAZ21haWwuY29tIj5qZWZmdGFudC5pZXRmQGdtYWlsLmNvbTwv YT4mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5UdWVzZGF5LCBBdWd1c3QgMjksIDIwMTcg YXQgMTE6MDEgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIFRoaWJhdWx0LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj50aGFuayB5b3UgZm9yIHlvdXIgaW50ZXJlc3QgaW4gdGhlIGRyYWZ0 LCBtdWNoIGFwcHJlY2lhdGVkLiBQbGVhc2UgZG9uJ3QgYmUgZGlzY291cmFnZWQgdGhhdCBpdCBs YXBzZWQsIHdlIGNhbiBmaXggaXQgZWFzaWx5LiBJIHRoaW5rIHRoYXQgYXV0aG9ycyBoYWQgc2lt aWxhciB0byB5b3VyIGlkZWEgd2hlbiB3ZSd2ZSBzdGFydGVkIHRoaW5raW5nIGFib3V0IEJGRCBz dXBwb3J0aW5nIFZSUlAuIEFuZCBsaWtlDQogeW91IHdlIGhhdmVuJ3QgZm91bmQgYW55IHJlZmVy ZW5jZSBpbiBleGlzdGluZyBkb2N1bWVudHMsIGhlbmNlIHRoaXMgZHJhZnQgZHJhZnQtbml0aXNo LXZycnAtYmZkLiBXb3VsZCBiZSBtdWNoIG9ibGlnZWQgaWYgeW91IHJldmlldyBhbmQgc2hhcmUg eW91ciBjb21tZW50cywgc3VnZ2VzdGlvbiByZWdhcmRpbmcgc29sdXRpb25zIHByb3Bvc2VkIGlu IHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAyOSwgMjAxNyBhdCA5OjIwIEFNLCBUQUJBTkkgVGhp YmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0bzp0aGliYXVsdC50YWJhbmlAYWx0cmFuLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnRoaWJhdWx0LnRhYmFuaUBhbHRyYW4uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gd29ya2luZyBhdCBpbXByb3Zpbmcg VlJSUCBjb252ZXJnZW5jZSB0aW1lLiAodGFyZ2V0IGEgZmV3IDEwMOKAmXMgb2YgbWlsbGlzZWNv bmRzKTxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IGFwcGVhcnMgdGhhdCBWUlJQIHN1cHBvcnRzIEJGRCBo ZWFsdGggbW9uaXRvcmluZyB3aGljaCBtaWdodCBiZSBhIGJldHRlciBvcHRpb24gdGhhbiB0dW5p bmcgVlJSUCBhZ2dyZXNzaXZlIHRpbWVycy48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VbmZvcnR1bmF0ZWx5 IEkgY2Fubm90IGZpbmQgYW55IGFjdGl2ZSBSRkMgd2hlcmUgVlJSUCBzdXBwb3J0cyBCRkQuIFRo ZSBvbmx5IGRvY3VtZW50IEkgZm91bmQgaXMgeW91ciBkcmFmdCBkb2N1bWVudDo8c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5GYXN0IGZhaWx1cmUgZGV0ZWN0aW9uIGluIFZSUlAgd2l0aCBCRkQ8YnI+DQo8c3Bh biBjbGFzcz0iZ21haWwtbS0zODgxMjM1NTM3NDY2MzQ4NzMyZmlsZW5hbWUiPmRyYWZ0LW5pdGlz aC12cnJwLWJmZC0wNDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5VbmZvcnR1bmF0ZWx5IGRhdGUg ZXhwaXJlcyBvZiB0aGlzIGRvY3VtZW50LiZuYnNwOyBBcyBCRkQgc3VwcG9ydCBmb3IgVlJSUCBp cyBpbXBsZW1lbnRlZCBvbiBtb3N0IHJvdXRlcnMsIEkgc3VwcG9zZSB0aGF0IGFuIGFjdGl2ZSBS RkMgbWlnaHQgZXhpc3Qgb24gdGhhdCBzcGVjaWZpYyBCRkQgaW1wbGVtZW50YXRpb24NCiB3aXRo aW4gVlJSUC4gKG5ldyBiYWNrdXAgYWR2ZXJ0aXNlbWVudCBtZXNzYWdlc+KApi5wZWVyIHRhYmxl 4oCmLik8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5icjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNUM3RjkyIj5U aGliYXVsdCBUQUJBTkkNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzU5NTk1OSI+PGJyPg0KYXJjaGl0ZWN0IEFsdHJh biBDb25uZWN0ZWQgU29sdXRpb25zIDxicj4NCkFsdHJhbiBGcmFuY2U8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9y OiM1QzdGOTIiPjxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojNUM3RjkyIj48aW1nIGJv cmRlcj0iMCIgd2lkdGg9IjE1MiIgaGVpZ2h0PSI4NiIgaWQ9Il94MDAwMF9pMTA2NSIgc3JjPSJj aWQ6aW1hZ2UwMDEucG5nQDAxRDMyMUUyLjdGMTdBRDYwIiBhbHQ9ImlkOmltYWdlMDAxLnBuZ0Aw MUNGOEFGRC45NTBCNzlGMCI+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjojN0Y3RjdGIj4mbmJzcDs8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM0MDQwNDAiPjEsIEltcGFzc2UgQ2hh cmxlcyBUcmVuZXQ8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzQwNDA0MCI+NDQ4MDAgU2FpbnQtSGVyYmxhaW48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29s b3I6IzU5NTk1OSI+PGJyPg0KRnJhbmNlPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM1OTU5NTkiPlRlbC4gOg0KPGEg aHJlZj0idGVsOiYjNDM7MzMlMjAyJTIwNDAlMjA2NyUyMDYyJTIwNjIiIHRhcmdldD0iX2JsYW5r Ij4mIzQzOzMzIDIgNDAgNjcgNjIgNjI8L2E+PGJyPg0KTW9iLiA6IDxhIGhyZWY9InRlbDomIzQz OzMzJTIwNiUyMDc5JTIwMDYlMjAzMyUyMDYzIiB0YXJnZXQ9Il9ibGFuayI+JiM0MzszMyA2IDc5 IDA2IDMzIDYzPC9hPjxicj4NCjwvc3Bhbj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibHVlIj48YSBocmVmPSJtYWlsdG86dGhpYmF1 bHQudGFiYW5pQGFsdHJhbi5jb20iIHRhcmdldD0iX2JsYW5rIj50aGliYXVsdC50YWJhbmlAYWx0 cmFuLmNvbTwvYT48L3NwYW4+PC91Pjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOiM1OTU5NTkiPjxicj4NCjwvc3Bhbj48L3U+PHU+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh O2NvbG9yOiM1OTU5NTkiPjxhIGhyZWY9Imh0dHA6Ly93d3cuYWx0cmFuLmZyLyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj53d3cuYWx0cmFuLmZyPC9zcGFuPjwvYT48L3NwYW4+ PC91PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0 aWNhO2NvbG9yOiM1OTU5NTkiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0i aHR0cDovL2ZhY2Vib29rLmNvbS9BbHRyYW5GcmFuY2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6IzU5NTk1OTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAi IHdpZHRoPSIyNSIgaGVpZ2h0PSIyMyIgaWQ9Il94MDAwMF9pMTA2NiIgc3JjPSJjaWQ6aW1hZ2Uw MDIucG5nQDAxRDMyMUUyLjdGMTdBRDYwIiBhbHQ9ImVzY3JpcHRpb24mbmJzcDs6IERlc2NyaXB0 aW9uJm5ic3A7OiBjaWQ6aW1hZ2UwMDIucG5nQDAxQ0Q4OUUxLjQyRDE5MjEwIj48L3NwYW4+PC9h PjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9BbHRyYW5GcmFuY2UiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iY29sb3I6IzU5NTk1OTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBi b3JkZXI9IjAiIHdpZHRoPSIyNSIgaGVpZ2h0PSIyMyIgaWQ9Il94MDAwMF9pMTA2NyIgc3JjPSJj aWQ6aW1hZ2UwMDMucG5nQDAxRDMyMUUyLjdGMTdBRDYwIiBhbHQ9ImVzY3JpcHRpb24mbmJzcDs6 IERlc2NyaXB0aW9uJm5ic3A7OiBjaWQ6aW1hZ2UwMDMucG5nQDAxQ0Q4OUUxLjQyRDE5MjEwIj48 L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHA6Ly9saW5rZWRpbi5jb20vY29tcGFueS9hbHRyYW4tZnJh bmNlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48 aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjI1IiBoZWlnaHQ9IjIzIiBpZD0iX3gwMDAwX2kxMDY4IiBz cmM9ImNpZDppbWFnZTAwNC5wbmdAMDFEMzIxRTIuN0YxN0FENjAiIGFsdD0iZXNjcmlwdGlvbiZu YnNwOzogRGVzY3JpcHRpb24mbmJzcDs6IExpbmtlZEluX3NpZ25hdHVyZU1haWwiPjwvc3Bhbj48 L2E+PGEgaHJlZj0iaHR0cDovL3d3dy52aWFkZW8uY29tL2ZyL2NvbXBhbnkvYWx0cmFuIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRl cj0iMCIgd2lkdGg9IjI2IiBoZWlnaHQ9IjI1IiBpZD0iX3gwMDAwX2kxMDY5IiBzcmM9ImNpZDpp bWFnZTAwNS5qcGdAMDFEMzIxRTIuN0YxN0FENjAiIGFsdD0iZXNjcmlwdGlvbiZuYnNwOzogRGVz Y3JpcHRpb24mbmJzcDs6IHBpY3RvZ192aWFkZW8iPjwvc3Bhbj48L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D5CD54E2C53E2aceeciscocom_-- --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=6451; creation-date="Thu, 31 Aug 2017 09:55:50 GMT"; modification-date="Thu, 31 Aug 2017 09:55:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCCAA== --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: attachment; filename="image002.png"; size=970; creation-date="Thu, 31 Aug 2017 09:55:50 GMT"; modification-date="Thu, 31 Aug 2017 09:55:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AA== --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: attachment; filename="image003.png"; size=950; creation-date="Thu, 31 Aug 2017 09:55:50 GMT"; modification-date="Thu, 31 Aug 2017 09:55:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJgggA= --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: attachment; filename="image004.png"; size=1272; creation-date="Thu, 31 Aug 2017 09:55:50 GMT"; modification-date="Thu, 31 Aug 2017 09:55:50 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYIIA --_008_D5CD54E2C53E2aceeciscocom_ Content-Type: image/jpeg; name="image005.jpg" Content-Description: image005.jpg Content-Disposition: attachment; filename="image005.jpg"; size=10079; creation-date="Thu, 31 Aug 2017 09:55:50 GMT"; modification-date="Thu, 31 Aug 2017 09:55:50 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2QA= --_008_D5CD54E2C53E2aceeciscocom_-- From nobody Thu Aug 31 06:10:30 2017 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 866CF132D91; Thu, 31 Aug 2017 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.997 X-Spam-Level: X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y74f3otk3uiU; Thu, 31 Aug 2017 06:10:24 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547E5132DFC; Thu, 31 Aug 2017 06:10:14 -0700 (PDT) Received: by mail-oi0-f48.google.com with SMTP id w10so5001477oie.1; Thu, 31 Aug 2017 06:10:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7OZy0JZNkicx+ZsjpVQYEa9hDqHkpa7C0BQGoUG5XYI=; b=C+mI2wOo7D8lLG7kLn13k4uDdOwcyFp216i+hs5eA055dp+6siVNXHdqHpKg18HAGh SBcbfnGKZkErzBKGXr6JA/F97MmvXm0+YOCsbVkvb2OPZTiznF7fcJmEkzmhg5xACeIe bcBBflcAHpDboeslazJ/5habziDJywItLDAJ/LpUpgP285y7wYwO8ujrU5jEgwfVZG8Q qMLWNnvFgNXz2WNxcWgFcKODIANTGtXaRNSzPQNbkpKpmMpCfGd8Q8x4J1kD+oOCpkfz ZjSvkf8v8c9AJqrhOHQwUfMkVg6CUVchOGz8x8ii4j8l8dBJk1ju8hHq6ufmn2l3Rkdb Fa9Q== X-Gm-Message-State: AHYfb5jV5SLoThDvG7dPPLo1PpPmBJUXnEJ8+/HmlhyJD1WrrvOF3Cae f2dADH58raykx7oinPgjZW//vD9skQ== X-Google-Smtp-Source: ADKCNb5V05fEDkcBzHPemV6VjqAba8MNKCra/yUWhairGQHafn+iM7IlHfKBiHpBwLXoOeQTtAoY9V1J51IyiFFe2Vg= X-Received: by 10.202.196.135 with SMTP id u129mr5688355oif.241.1504185013315; Thu, 31 Aug 2017 06:10:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Colin Docherty Date: Thu, 31 Aug 2017 13:10:02 +0000 Message-ID: Subject: Re: draft-nitish-vrrp-bfd To: "Acee Lindem (acee)" , "Nitish Gupta (nitisgup)" , "thibault.tabani@altran.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" Cc: "draft-nitish-vrrp-bfd@ietf.org" , "Aditya Dogra (addogra)" Content-Type: multipart/related; boundary="001a113e2bb865658405580c5d13" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 13:10:28 -0000 --001a113e2bb865658405580c5d13 Content-Type: multipart/alternative; boundary="001a113e2bb865658205580c5d12" --001a113e2bb865658205580c5d12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Totally agree. Colin. On Thu, 31 Aug 2017 at 10:56 Acee Lindem (acee) wrote: > Hi Nitish, > > Irrespective of any IPR discussions, BFD is inherently a P2P protocol and= , > consequently, I would vote for P2P peer table. > > Thanks, > Acee > > From: rtgwg on behalf of "Nitish Gupta > (nitisgup)" > Date: Thursday, August 31, 2017 at 1:51 AM > To: "thibault.tabani@altran.com" , " > rtg-bfd@ietf.org" , Routing WG > Cc: "colin@doch.org.uk" , " > draft-nitish-vrrp-bfd@ietf.org" , "Aditya > Dogra (addogra)" > Subject: Re: draft-nitish-vrrp-bfd > > Hi Thibault, > > > > Thanks for the interest in the Draft, appreciate it. Please review the > draft and let us know if you have any comments, suggestions. > > > > Hi RTGWG/RTGBFD, > > > > There were two solutions proposed in the draft. > > One pertains to making a peer table in VRRP and uses p2p BFD. > > The second solution pertains to p2mp BFD. > > > > While we were working on the draft there was an IPR associated to the > DRAFT and the WG felt that we need to wait until we can see the IPR and > what its associated to. > > We can see that the IPR is available for us to view and we can see that > the IPR is associated to p2mp BFD. > > > > https://www.google.com/patents/US20170005915 > > > > We are going to submit a draft with the p2p BFD so that we can continue > working on the Draft. > > There was lot of interest last time as well, just because of the IPR clai= m > we had stopped the work. > > > > Thanks, > > Nitish > > > > *From: *Greg Mirsky > *Date: *Tuesday, August 29, 2017 at 11:01 AM > *To: *TABANI Thibault > *Cc: *"draft-nitish-vrrp-bfd@ietf.org" , > "Nitish Gupta (nitisgup)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtgwg@ietf.org" > *Subject: *Re: draft-nitish-vrrp-bfd > *Resent-From: * > *Resent-To: *, , , > , > *Resent-Date: *Tuesday, August 29, 2017 at 11:01 AM > > > > Hi Thibault, > > thank you for your interest in the draft, much appreciated. Please don't > be discouraged that it lapsed, we can fix it easily. I think that authors > had similar to your idea when we've started thinking about BFD supporting > VRRP. And like you we haven't found any reference in existing documents, > hence this draft draft-nitish-vrrp-bfd. Would be much obliged if you revi= ew > and share your comments, suggestion regarding solutions proposed in the > draft. > > > > Regards, > > Greg > > > > On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault < > thibault.tabani@altran.com> wrote: > > Hello, > > > > I am working at improving VRRP convergence time. (target a few 100=E2=80= =99s of > milliseconds) > > > > It appears that VRRP supports BFD health monitoring which might be a > better option than tuning VRRP aggressive timers. > > > > Unfortunately I cannot find any active RFC where VRRP supports BFD. The > only document I found is your draft document: > > > > Fast failure detection in VRRP with BFD > draft-nitish-vrrp-bfd-04 > > > > Unfortunately date expires of this document. As BFD support for VRRP is > implemented on most routers, I suppose that an active RFC might exist on > that specific BFD implementation within VRRP. (new backup advertisement > messages=E2=80=A6.peer table=E2=80=A6.) > > br > > > > > > *Thibault TABANI * > architect Altran Connected Solutions > Altran France > > > *[image: id:image001.png@01CF8AFD.950B79F0]* > > > > 1, Impasse Charles Trenet > > 44800 Saint-Herblain > France > > Tel. : +33 2 40 67 62 62 <+33%202%2040%2067%2062%2062> > Mob. : +33 6 79 06 33 63 <+33%206%2079%2006%2033%2063> > *thibault.tabani@altran.com * > *www.altran.fr * > > > > [image: escription : Description : cid:image002.png@01CD89E1.42D19210] > [image: escription : Description : > cid:image003.png@01CD89E1.42D19210] [ima= ge: > escription : Description : LinkedIn_signatureMail] > [image: escription : > Description : pictog_viadeo] > > > > > > --001a113e2bb865658205580c5d12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Totally agree.

Colin.

On Thu, 31 Aug 2017 at 10:56 Acee Li= ndem (acee) <acee@cisco.com> wr= ote:
Hi Nitish,=C2=A0

Irrespective of any IPR discussions, BFD is inherently a P2P protocol = and, consequently, I would vote for P2P peer table.=C2=A0

Thanks,
Acee=C2=A0

From: rtgwg <rtgwg-bounces@ietf.org> on = behalf of "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Date: Thursday, August 31, 2017 at = 1:51 AM
To: "thibault.tabani@altran.com"= <thibau= lt.tabani@altran.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Routing WG <rtgwg@i= etf.org>
Cc: "colin@doch.org.uk" <colin@doch.org.uk>, "= draft-n= itish-vrrp-bfd@ietf.org" <draft-nitish-vrrp-bfd@ietf.org>, "Aditya Dogra (addogra)" <addogra@cisco.com>
Subject: Re: draft-nitish-vrrp-bfd<= br>

Hi Thibault,

=C2=A0

Thanks for the interest in the Draft, appreciate it. Please review the dra= ft and let us know if you have any comments, suggestions.

=C2=A0

Hi RTGWG/RTGBFD,

=C2=A0

There were two solutions proposed in the draft.

One pertains to making a peer table in VRRP and uses p2p BFD.

The second solution pertains to p2mp BFD.

=C2=A0

While we were working on the draft there was an IPR associated to the DRAF= T and the WG felt that we need to wait until we can see the IPR and what it= s associated to.

We can see that the IPR is available for us to view and we can see that th= e IPR is associated to p2mp BFD.

=C2=A0

https://www.google.com/patents/US20170005915

=C2=A0

We are going to submit a draft with the p2p BFD so that we can continue wo= rking on the Draft.

There was lot of interest last time as well, just because of the IPR claim= we had stopped the work.

=C2=A0

Thanks,

Nitish

=C2=A0

=C2=A0

Hi Thibault,

thank you for your interest in the draft, much appre= ciated. Please don't be discouraged that it lapsed, we can fix it easil= y. I think that authors had similar to your idea when we've started thi= nking about BFD supporting VRRP. And like you we haven't found any reference in existing documents, hence this d= raft draft-nitish-vrrp-bfd. Would be much obliged if you review and share y= our comments, suggestion regarding solutions proposed in the draft.<= u>

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault <= ;thibault.t= abani@altran.com> wrote:

Hello,

=C2=A0

I am working at improving VRRP convergence time. (ta= rget a few 100=E2=80=99s of milliseconds)

=C2=A0

It appears that VRRP supports BFD health monitoring = which might be a better option than tuning VRRP aggressive timers.

=C2=A0

Unfortunately I cannot find any active RFC where VRR= P supports BFD. The only document I found is your draft document:

=C2=A0

Fast failure detection in VRRP with BFD
dra= ft-nitish-vrrp-bfd-04

=C2=A0

Unfortunately date expires of this document.=C2=A0 A= s BFD support for VRRP is implemented on most routers, I suppose that an ac= tive RFC might exist on that specific BFD implementation within VRRP. (new backup advertisement messages=E2=80=A6.peer table=E2=80= =A6.)

br

=C2=A0

=C2=A0

Thibault TABANI
architect Altran Connected Solutions
Altran France


=C2=A0=

1, Impa= sse Charles Trenet

44800 Saint-Herblain
France

Tel. : +33 2 40 67 6= 2 62
Mob. : +33 6 = 79 06 33 63
= thibault.ta= bani@altran.com
www.altran.fr

=C2=A0

3D"escription=C2=A0:3D"escription=C2=A0:3D"escription=C2=A0:= 3D"escription=C2=A0:=

=C2=A0

=C2=A0

--001a113e2bb865658205580c5d12-- --001a113e2bb865658405580c5d13 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <15e3869802d4cff311> X-Attachment-Id: 15e3869802d4cff311 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCCAA== --001a113e2bb865658405580c5d13 Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <15e3869802f5b16b22> X-Attachment-Id: 15e3869802f5b16b22 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AA== --001a113e2bb865658405580c5d13 Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: <15e38698030692e333> X-Attachment-Id: 15e38698030692e333 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJgggA= --001a113e2bb865658405580c5d13 Content-Type: image/png; name="image004.png" Content-Disposition: inline; filename="image004.png" Content-Transfer-Encoding: base64 Content-ID: <15e386980307745b44> X-Attachment-Id: 15e386980307745b44 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYIIA --001a113e2bb865658405580c5d13 Content-Type: image/jpeg; name="image005.jpg" Content-Disposition: inline; filename="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: <15e386980318546ed5> X-Attachment-Id: 15e386980318546ed5 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2QA= --001a113e2bb865658405580c5d13 Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <> X-Attachment-Id: iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AA== --001a113e2bb865658405580c5d13-- From nobody Thu Aug 31 10:20:21 2017 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 15275132E11; Thu, 31 Aug 2017 10:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHL34WlqUNtG; Thu, 31 Aug 2017 10:20:13 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61572132025; Thu, 31 Aug 2017 10:20:13 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id r187so698459pfr.3; Thu, 31 Aug 2017 10:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmUb20nK9/9oN36b0LY7rR/UEt7ZC7+K359DC5/vAc0=; b=nL/XUHkpyGH8qzmIpCo2pQQKK64N6QEKR7EhWynEcnZwUdhj3WPqTYk4BsxXaqlJhY 3dTUFx9+Uct+XXcUVnpNVUuMl6Ui8n13kL24Mjp8Mw3aDxXgZclM+yjJjKovkK9LlGnX PpXJ+682bM+GDZwh52UPjpLSZcuLXjwZwHi3XTgpVL20VJtF420OLwqow+97pC1zB2PL 9hGmu738gxWhJ0ziAePpVXV1jBUwghYEQ543Nr/5I+OS/9yEYw7/KEhzl2XLQB2JwXiQ a5RcnsQHzjjkhtUr6E44JjA1YMX9yf0IIGtDXrWHN0OL6YNpP+bZmxyPnDN+BoKMgk/A 9ZIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmUb20nK9/9oN36b0LY7rR/UEt7ZC7+K359DC5/vAc0=; b=OFfACJLYDuSmxjMD5SdBii6uHQg2w+N6+CR3EaU3NmSkEXYuSBQ/Zsuvv+lAd5vyDi 3B7+kSpbBw5atgxwh3E55psruvvoUwOwGpkPlEEzXnT0iTUcGAQRvCQ4ZgFV1rY4xFRr xb5aIEyuuIkDJQU1ODfBNB4v4hoFtQBImAIS3Y0q31oAiBbcP+sumwtNpBcfNV15qaDz XkbH/Wu6A+8FRt3M/ZoJREQOmVL8TQfyjpPJEnzj6jfIBIUQ5Ab/FEqPCYl+0jWTsujj cizfO+/kxnvdU0d7aDiKqmEKPSBkSdzuG+bpTIuk1rYpNf+1vbWKGSaO/LsKlfDPIYh7 OXmA== X-Gm-Message-State: AHYfb5jAbu/S2d2QY3wBVZn/qSUL6raI3jI1xc/oUHnHkvPKFPEUjDtk KsuD5H3iHnibxks7HqstnfD6qPRWsg== X-Google-Smtp-Source: ADKCNb6+xcaY1LjZi2pWlwWehpFJA1fytLzxEeMXuN9uZjoB62xAkogyhOXyPAO9xRG+fZvuhF30IbfBOqhb3sr3Zsc= X-Received: by 10.99.4.135 with SMTP id 129mr3306631pge.57.1504200012428; Thu, 31 Aug 2017 10:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.182.110 with HTTP; Thu, 31 Aug 2017 10:20:11 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 31 Aug 2017 10:20:11 -0700 Message-ID: Subject: Re: draft-nitish-vrrp-bfd To: "Acee Lindem (acee)" Cc: "Nitish Gupta (nitisgup)" , "thibault.tabani@altran.com" , "rtg-bfd@ietf.org" , "rtgwg@ietf.org" , "colin@doch.org.uk" , "draft-nitish-vrrp-bfd@ietf.org" , "Aditya Dogra (addogra)" Content-Type: multipart/related; boundary="001a114f174e6a292b05580fdbd4" Archived-At: X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:20:20 -0000 --001a114f174e6a292b05580fdbd4 Content-Type: multipart/alternative; boundary="001a114f174e6a292905580fdbd3" --001a114f174e6a292905580fdbd3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Acee, I'd refer to BFD for Multipoint Networks that being prepared for publication. I believe that this very nicely matches VRRP scenario when Backup need to monitor the Master and Master doesn't have to know about the Backup at all. Appreciate your consideration and comments. Regards, Greg On Thu, Aug 31, 2017 at 2:55 AM, Acee Lindem (acee) wrote: > Hi Nitish, > > Irrespective of any IPR discussions, BFD is inherently a P2P protocol and= , > consequently, I would vote for P2P peer table. > > Thanks, > Acee > > From: rtgwg on behalf of "Nitish Gupta > (nitisgup)" > Date: Thursday, August 31, 2017 at 1:51 AM > To: "thibault.tabani@altran.com" , " > rtg-bfd@ietf.org" , Routing WG > Cc: "colin@doch.org.uk" , "draft-nitish-vrrp-bfd@ietf. > org" , "Aditya Dogra (addogra)" < > addogra@cisco.com> > Subject: Re: draft-nitish-vrrp-bfd > > Hi Thibault, > > > > Thanks for the interest in the Draft, appreciate it. Please review the > draft and let us know if you have any comments, suggestions. > > > > Hi RTGWG/RTGBFD, > > > > There were two solutions proposed in the draft. > > One pertains to making a peer table in VRRP and uses p2p BFD. > > The second solution pertains to p2mp BFD. > > > > While we were working on the draft there was an IPR associated to the > DRAFT and the WG felt that we need to wait until we can see the IPR and > what its associated to. > > We can see that the IPR is available for us to view and we can see that > the IPR is associated to p2mp BFD. > > > > https://www.google.com/patents/US20170005915 > > > > We are going to submit a draft with the p2p BFD so that we can continue > working on the Draft. > > There was lot of interest last time as well, just because of the IPR clai= m > we had stopped the work. > > > > Thanks, > > Nitish > > > > *From: *Greg Mirsky > *Date: *Tuesday, August 29, 2017 at 11:01 AM > *To: *TABANI Thibault > *Cc: *"draft-nitish-vrrp-bfd@ietf.org" , > "Nitish Gupta (nitisgup)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org>, "rtgwg@ietf.org" > *Subject: *Re: draft-nitish-vrrp-bfd > *Resent-From: * > *Resent-To: *, , , > , > *Resent-Date: *Tuesday, August 29, 2017 at 11:01 AM > > > > Hi Thibault, > > thank you for your interest in the draft, much appreciated. Please don't > be discouraged that it lapsed, we can fix it easily. I think that authors > had similar to your idea when we've started thinking about BFD supporting > VRRP. And like you we haven't found any reference in existing documents, > hence this draft draft-nitish-vrrp-bfd. Would be much obliged if you revi= ew > and share your comments, suggestion regarding solutions proposed in the > draft. > > > > Regards, > > Greg > > > > On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault < > thibault.tabani@altran.com> wrote: > > Hello, > > > > I am working at improving VRRP convergence time. (target a few 100=E2=80= =99s of > milliseconds) > > > > It appears that VRRP supports BFD health monitoring which might be a > better option than tuning VRRP aggressive timers. > > > > Unfortunately I cannot find any active RFC where VRRP supports BFD. The > only document I found is your draft document: > > > > Fast failure detection in VRRP with BFD > draft-nitish-vrrp-bfd-04 > > > > Unfortunately date expires of this document. As BFD support for VRRP is > implemented on most routers, I suppose that an active RFC might exist on > that specific BFD implementation within VRRP. (new backup advertisement > messages=E2=80=A6.peer table=E2=80=A6.) > > br > > > > > > *Thibault TABANI * > architect Altran Connected Solutions > Altran France > > > *[image: id:image001.png@01CF8AFD.950B79F0]* > > > > 1, Impasse Charles Trenet > > 44800 Saint-Herblain > France > > Tel. : +33 2 40 67 62 62 <+33%202%2040%2067%2062%2062> > Mob. : +33 6 79 06 33 63 <+33%206%2079%2006%2033%2063> > *thibault.tabani@altran.com * > *www.altran.fr * > > > > [image: escription : Description : cid:image002.png@01CD89E1.42D19210] > [image: escription : Description : > cid:image003.png@01CD89E1.42D19210] [ima= ge: > escription : Description : LinkedIn_signatureMail] > [image: escription : > Description : pictog_viadeo] > > > > > > --001a114f174e6a292905580fdbd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Acee,
I'd refer to BFD for Multip= oint Networks that being prepared for publication. I believe that this = very nicely matches VRRP scenario when Backup need to monitor the Master an= d Master doesn't have to know about the Backup at all.
Apprec= iate your consideration and comments.

Regards,
Greg

On Thu, Aug 31, 2017 at 2:55 AM, Acee Lindem (acee) <acee@cisco.com= > wrote:
Hi Nitish,=C2=A0

Irrespective of any IPR discussions, BFD is inherently a P2P protocol = and, consequently, I would vote for P2P peer table.=C2=A0

Thanks,
Acee=C2=A0

From: rtgwg <rtgwg-bounces@ietf.org> on = behalf of "Nitish Gupta (nitisgup)" <nitisgup@cisco.com>
Date: Thursday, August 31, 2017 at = 1:51 AM
To: "thibault.tabani@altran.com"= <thibau= lt.tabani@altran.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Routing WG <rtgwg@i= etf.org>
Cc: "colin@doch.org.uk" <colin@doch.org.uk>, "= draft-n= itish-vrrp-bfd@ietf.org" <draft-nitish-vrrp-bfd@ietf.org= >, "Aditya Dogra (addogra)" <addogra@cisco.com>
Subject: Re: draft-nitish-vrrp-bfd<= br>

Hi Thibault,

=C2=A0

Thanks for the interest in the Draft, appreciate it. Please review the dra= ft and let us know if you have any comments, suggestions.

=C2=A0

Hi RTGWG/RTGBFD,

=C2=A0

There were two solutions proposed in the draft.

One pertains to making a peer table in VRRP and uses p2p BFD.

The second solution pertains to p2mp BFD.

=C2=A0

While we were working on the draft there was an IPR associated to the DRAF= T and the WG felt that we need to wait until we can see the IPR and what it= s associated to.

We can see that the IPR is available for us to view and we can see that th= e IPR is associated to p2mp BFD.

=C2=A0

https://www.google.com/patents/US20170005915=

=C2=A0

We are going to submit a draft with the p2p BFD so that we can continue wo= rking on the Draft.

There was lot of interest last time as well, just because of the IPR claim= we had stopped the work.

=C2=A0

Thanks,

Nitish

=C2=A0

=C2=A0

Hi Thibault,

thank you for your interest in the draft, much appre= ciated. Please don't be discouraged that it lapsed, we can fix it easil= y. I think that authors had similar to your idea when we've started thi= nking about BFD supporting VRRP. And like you we haven't found any reference in existing documents, hence this d= raft draft-nitish-vrrp-bfd. Would be much obliged if you review and share y= our comments, suggestion regarding solutions proposed in the draft.<= u>

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Aug 29, 2017 at 9:20 AM, TABANI Thibault <= ;thibault.t= abani@altran.com> wrote:

Hello,

=C2=A0

I am working at improving VRRP convergence time. (ta= rget a few 100=E2=80=99s of milliseconds)

=C2=A0

It appears that VRRP supports BFD health monitoring = which might be a better option than tuning VRRP aggressive timers.

=C2=A0

Unfortunately I cannot find any active RFC where VRR= P supports BFD. The only document I found is your draft document:

=C2=A0

Fast failure detection in VRRP with BFD
dr= aft-nitish-vrrp-bfd-04

=C2=A0

Unfortunately date expires of this document.=C2=A0 A= s BFD support for VRRP is implemented on most routers, I suppose that an ac= tive RFC might exist on that specific BFD implementation within VRRP. (new backup advertisement messages=E2=80=A6.peer table=E2=80= =A6.)

br

=C2=A0

=C2=A0

Thibault TABANI
architect Altran Connected Solutions
Altran France


3D"id:image001.png@01CF8AFD.950B79F0"<= /u>

=C2=A0=

1, Impa= sse Charles Trenet

44800 Saint-Herblain
France

Tel. : +33 2 40 67 6= 2 62
Mob. : +33 6 = 79 06 33 63
= thibault.ta= bani@altran.com
www.altran.fr

=C2=A0

3D"escription=C2=A0:3D"escription=C2=A0:= 3D"escription=C2=A0:

=C2=A0

=C2=A0

--001a114f174e6a292905580fdbd3-- --001a114f174e6a292b05580fdbd4 Content-Type: image/png; name="image004.png" Content-Disposition: inline; filename="image004.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b476782e7d2236f8_0.4 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAYAAAD+4+QTAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAR3SURBVEjH nZRrTJNnHMX5tGwJynqFQpGMbZH4ZXMx2TK3mCxmybYPc8mmyYhbAEUZIKAoAxEYIIPB3ASHXBQU FLnV0hbKrcjFoMDoKDMMJq5cVMApIuOm3M7+z9OClIJs/pPTt817+fWc5zyvTePNQYj3neOSLGhv Fpd471mIPc9A7EXyyCRlQPR1OkRfMaVBtPs0l9A9lct2ZzJe885ER98DLB2bRxNP8GGCFrZeWZD6 nOeS7DfDvLMXgRKvsyaY5zIg0+60RRgDZVS0W0LYR3xZO9bto4f75ULqS/om5ylwwZ33MthSdx5m GLl74Ytk7Eoqw+PpWUvIn4OP4BpcAJHfRdgfIPmT/C5woGj/ee7Sbk/WEmD2IpBDPU0OGWw9Renq kw3jvVFLCBv3zAaIAy7BPvCSCUQS+l7A1hg1ilqMCLp4nQN5lAtiMG/rOF/6MhUlzX9ZQ0ra+iEK zIfsUAEcgvI5zNYnF9GqNn6+sXsITgF5EBBI7JPDJVxaGLM7Vhbmxj25yhoyODqF9xMrIDlIkOBC OBwshCSoAG9GqRBS1IodKTrujoFYnFKKk0XMIhUQYGlhBOTKLSgPw2NTlhA2EZp2CA8VweFwEWQk QWABj7GmcwDRGgO2UQtruwaR32yEorUH/cPjUPzagy2RSu5woTDcHQHV+l5rSE3XEF45pob0iAKy EAXsCBJWYopLe+MOPv2l1nzlPNQUb1vfMP9VaujnDsW+T9v5oscZBOQ0WkOmZ+ewPaUWIgYJVeJl cnXk8m/8nKq9n0Pm5uehp80mCsjHzvR6wgFjj2ewMazYop1sS7DSDIxMWEL4ntF1QvitEk7hKggO KxCiMpggBnJyug7EQEP3PdgR5JOUGszOzWOcIG7hSt5Oh0CTpAdMIF3HXWvIH0OjkB3TwClCw2Gh 6t9NkXQMYEf6Vf79uvE+XzsGZTM1Mwe3iBJeFN5OKg1rKGtnuEJvDWE3fH6uCaJwNcRH1Qi4bMAw vXpyWnrxcVoDhv6ZgubGXR7pRxQfa6Xx/hg2RqogCTYVRkZHe2rpOorvneOl1hA2GU09sAvXwPE7 LTbFV2HbqXpsTqrGqzFavHfyCrYkVkFGcbpGabD1hA7vJlVBHqbkZWFirWRia9ZMrleEGIcn8NbP dZBEl0NGkkaWcTlGlXF3EnIpjyzlsbJIRSFKOB5V8bLYBRdjc5wWOU1G6824fPYUGzjEOa4Kzscr 4RxbAXkMUznk5JCLoE4EW1g/5s6/SM//pNVbeKUpv/k3HOKq4RyvM4G4KjlQHmuGkWQEWh+qwvbU el6OlWZVyPiTWbyd1ghHgmz4oQYbEugYX83FgE4EE1KErydUI07XhYeT06s9anUIm6gr3RB9r4NL Uq0JZBZzKI2txK48PVrvjGCteSbkWv8IXH5qgPzHOricqIOcYGKCvnHqKrL1tzEzN4//Ms+EsD3z WaEB0sQ6LmcC+Ws70Tsyif8zNmtdcLLlNgRJ9fggV4/KWw/wPLMm5NbDScRf68PQ+BM87/wLQxbB 4ovOpisAAAAASUVORK5CYIIA --001a114f174e6a292b05580fdbd4 Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b476782e7d2236f8_0.3 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAM1SURBVDhP dVQhdNswED2lXSSVTB6KxwxdlrGGrdC0MDBjHVvZCksHBwsztrINFqYsZg00tN8bsMHek9x10/7J btqk6T3nIsu6r//vThLL2p5er4gckXri+6FzpLppmCJ+fVxkMRcpPc+ORpglGoyNOjQY8pvmuM4r 0pLDwwzjhQG/9kNSwwMsqh0tyipsRQP8jpMYG2tFFvsSfPjiWyKZKOysXDCeDJ4dNrrzJL2zdlHV T7BikxgFCK0MEwpUwOEkfTvPxqdpAjg8PUHWpUgEskKYSOela9a8oDaF7sBLP/DSjmbpCGsm2Cfo ApuOXs0uJI9J8uuyYjTWCDtJ4pANiXzCrykwP6IsicMzOkmTk2T0bmSA0SVXhLRelyxTeO/xB9jz m2JZN1oMrb9TJAW137Mxgp5b4+gsXy2LRqkh0oYFUI3FPS/EjEeRBgk/UEI6avsK7sJC2Vk08xoM h1x0yF1UTc8LIXnjzhdFn4PQIj+ytOum+Yqr3pUXtmrqVe1QKynp31+e+fXbzdLkEQtTH/NqWdZR 15OK5scp+EL+jJsZEA5VQPa7kkqSLbX790KQ/7NPiVK9xm7DiVGoI4D0wR58icQQAS5LIjyT2BxG Cj4KrAEkaXh/7/f2BDgXjdvgBSXT6xVygc2FFO/fmM9jbovOQiOwRyIu8qKo0UDOi6HwSL9CZ2zw QtxRFHH7KOVbv6jtVQGJvfUtTIQsJkqHVpMBSKIxIXwDi2XGaFqOkhrVdJdFfVk04MuP49xB97ei yZHW18iHwK6WWoRA+4ZGQGD16U1R8RXgOLuuDS0fahgGaAUQ53PGtMi2LlZmdhhlo2dYCPmyan6W NVfBkhei9Z7HiLUsqfUtNyCffIbGeZgmpr9z1ulYDyCziyRNAMIJwBgPZgH0ioYAwsdE08Uk+ZT2 QAjZ1tghfsirEhKsFVL6tgUoW0CvLcWaslE0S8wWj91Yl5W7vC0jHHLkS0oHuAc7ivU0Nilfn9u2 G2vl6DxH3UJDWes0E0PHTFOT7ULpUHdj4cNZXuVBptL6OMTPUrOtapPZi1hXlft626SxmsVm99Xz XCTur51WWj8vbf3S513z/wH+e9GA8nn/xAAAAABJRU5ErkJgggA= --001a114f174e6a292b05580fdbd4 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b476782e7d2236f8_0.1 iVBORw0KGgoAAAANSUhEUgAAAJgAAABWCAYAAAAzIF/lAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAABiySURBVHja 7Z0HfFRV2sYvNRQLRXc/0f12XdddV9ddd3VVEBEbKirrioIIiCiioiiofBYUCyC9pJIOJISEQEIC gYSSkBAgEEgjvU9JmZaZZCY9kzzfe+6ZyUxCEpLQgt43v+d378zcmTtz7/8+5z3vOTMRAOglSbpC KhQghRRXLkwSYFJcyaiQAJNCAkwKCTAppJAAk0ICTIpfG2BKjQlRiTK47E7BV+4n8O6ao3hr1RFR H2yKxTL/swg8kovEXDUaGs1dvlZ1fRP84ovhE1sE37gi+JC8jxVCpqvp9DmmuiYEJMjhfbwYvidk Np20LuXtpLDpVFv5nFbC51w5fM6WwzuxDNuTVaiqt73n2OIqeJyhx5PUHUgDn2R7aeGTrodPhl5c epNCcyuRpKlDZWPzJZ2VslozDilr4JZuwJIELebGqDD7aDlmR6vwTqwKSxNp3zlGnKZ9GS/Dvg6W 1GJDeiU+TDJgdoIes0/rMSfRgM9S6Xjkm5Cga0BtU8vlA8zc0oKQo7l4fUkY/neyBwY/thnCwxsg PLIRwqObIIwljSM95ghhgjOEJ5wx8AUPPLBgN1bsTEKZobbDvckJVuHV7RBe8IYwZSvJV1wPOSPv 9B3KVEYMe2sXhGk7IcwMgjCL1mfv4ZoTAuHtUAhzSe/shTAvDMJ74aT9XPNJ70dA+PAAhAUHIXwU CeGTQ1wfkT6PRpbGBvdrAVkQPj4K4cvjFsVD+PokhG9OQViaAOG7M6RECMtIP5yD8FOSTcuTIaxI waAN6fiTVy4Wx5Qi39DQo7MRUWzC1IMlGOObD8E5B4IjvZ/N2bQkOTHRfc65XC556O9VgHt2yfHV 2QoUmRp7tK/EigbMOanDmJBSCAEKCH6kACWEnSVcgaRdZaL6hZTj/sMarMg0Ql1nvjTAMosrMPnT EDg8uA4DH1qHG8Zvxk1PueLGp1wwmEASxjuRCKwnnNDvGVf0J7AGvuhJoLhDeMYNwkQX3DE7ADuO F16wN4W2GkNnESiv+kF4YwfXa37Yd07Z6TtUqI24ZT7BNJf0HoE0j0B6bx/Xh/u5FhBEHxNEC0mf EEifRtm0iIF0BMJnpM8Jnv+LgbCE9HkMBn4dhxw7wGYG0wn8Ig7C96e4fiCofiSofiKglpNWElQr CaafSatTIKxJtWldGtca0s90e0UyRjpmwDPDcNGzoDA24hUCS9hEQG3M4iC55UHYwkDK5bC5kFxp 3Z3g8yyA4MVUCMEjX9x2lL8MW8jVLha15hZ8cU6PwTsJpm1ygomWu0q4dhNse8q4Qkh7VVyhpBBS cDnujNIiWFnbe8CmLiJXuP07jBi7ESMmOGK46F4bMZBc6/ev+WL8J6F4/qv9GLcwBH94czv6Pecu OphATtdvihe5ErnTJLrveQ94RGVfANgwBtjU7gPGHGyw6GCBEN6k5cxgcrHd5GD0PueEcr2/j8Nl D9gi0se0Pj/C5l4f0X0LCbiFh7mDLY5Gpqq6dV+z2gP2IwG2LMHmYN+e5hId7Cw9nsRldbCfCbp1 5yGsJ208z2FblQbfzK4hm3eETuyPKdyxGEgMqM05omuN8C3Av0MUeC6iBOP2KjBmRxEBls/BY4D5 kHxJniT3AixP1Xe6nypqTl+K0dBzZBB2kGMFWuAKKuHuxRRoca+gUu5ge8o5ZOFqrhC1CJxTnql3 gB09I8NT8wJxG7nTqInOuHOKJ6YujUBwTB5U+lpYW+Jmakb1xjpEp5Rg1jpyhGe3kIt5cMBe8aF1 Twx7ZSuS87WXBJihpgE/hmfhy5B0fLM3wya6bylp7tYkjPrsIHcye8AIrpFfRePtHefx7cE8fHPA TnT7q4hcfBNVAHV1Y+eAfXsSf3ZJw3dxpfiGKdYitn68TNS38WX4lJrDKXtl+P0WAmRFKodsA4Ms XYRshGsWZFWdN5cny2rw5B4ZRnjkYuiWHNzqnY9J4Upsy6lCSXUTHWu+HVtUNphxrKwW8+LU6MdA Y07GAPMl8LwLxdtHSjt2mHdOaGmbYu5aTIEcqn60PuGwGl8kG+BSUA33whqsz63G3EQ97ookoIKZ m1kAC9eI6k+QRZXX9y4HY/DkKQ04X6BFqbZbpMJ5Hx3MSQTZS+Ri/yHAXqH86mk3zF4fc0mAdSe8 KIEX5ofzZpIB9kmUmHu5xst79DoXAEY52H+C8rr9fFVtExZG05W/OtUGGBM1mWvO6bp8LoOnwNiE dH0DFARVd8I/twqDvQs4WAywrUWii006VI72KflR6jQIvsXcuayAbVfgvggVDjEgWzpO4nXUCVqb ZcRQBpfoZATYfo0I3L3RFahuau45YL2NN9ZGi1C1AvaiF373biAqTHVXFLBkRSX6f0xN4UcRHLCF kRjwSSROySovDbCv4jF5Z26PXoNdnPdvzeGQWQGjZnJ6hBJXIhad1lGulm8DjJrMIX4y5BvbJv2v xqg5YAEWwCipv3d/GZQ13UvagxS1GMRysTALYEyhauyU1149wI6eU6Df89Zm0lcEbeirW5FBHYcr CdjpIv0FgA39NBLpJVVXHTAW0w8oeD5mBYyayfHBRVcEsGTqDQ72seRiDDBfDlmE0tZ5YaWIEcEM KjkHjJrFAf4KHCit7dG+5pw1UE6msgG2V4Pppw1XD7DqukaMmuEnOpcIGKnfFB/EpZdfdcCGEGBp ymsD2Lid1GytautgU8LluFLx590K3rO0A2yvwgYYy8mE7ZTY+1sAI9DujyhHg7lnta0jqnr0I9cS 9lkAo+bywWhdV6/TNWBVlGCfpyT9aKIcAYez4RaahjUBSfhu6xks255IOotF7iexwOk4PnKOx3zH 47hp+nbKw7xbARNe9kZ0aul1C9iLPQQsKEuPQaz3uL5tDrYsQdOt55soic+oqMfRkhr45xnhmlmJ NdQz/DZRi+/O6rCMtPCkFgvi1VhIej9OhdH+xTwP22ppJgm27YW23jFb5/mXBbBtckyN1fb4OMur zbj5gJYn+wwwAu23UTqUdN7MXgiYQm2Cx17KGb7chwemb8UtT7ti0NhNGCAWVzdDGEtipYvHHUlO Nk1wEmtgwst2Sb4FsJi06xewyYG5YsLMCtmN9qKuXRPlWw20ZMXHs9QTXBJXDocNlvKENcmnHuUQ x0xkVXTe41JTE7Yty4DpB0twl38hhnpYal/W4qpYYM3mpQmrWLHVNY/Xy3zsknxLou9pV0Zg1XjB py1g0+J6DhjL10YfbAvYyEM6FHcHsAZzM1Z6nsRdz7lhwN9XY/C/1mL4uE24eYKjWGRlxdYbKIEf Tj3F4c9twdDnt2DIC+4Y9JKnqP4kgYnlX+0Ai75eAVt2CjevScK/vbPwoFcW/uWdbZNvDh4k/ZN0 x5ZMDFybymthVvdigLFyxYoUrEnqvAfpmFKBP/oSJOsz6DmZHCYXS6HVnSDawpYkzzxe//IqsMnb rg5mBYwtvQoRJLM5mGcHgL3eC8AUBNKodoCNIsBkFwOssroBry8OxaB7VmDUw+vxG4Lq1omOGP2k M24ipxrAnIsNE10wVLSZuxer7j/pwssUL7cDjIA7dv46BYxV8r8/bSmysvUzpESun85xoJhWJttV 8y2F1vVpGLk5A8sT1B3uq56c743DpRDWksttIrBcc7jccjlgDDQ2RNQ6VJTTdqiIiUHIKvk+7QCj 22F2Odg1B2zB8kMYePdyjCFobnt8M377hCNG0PrAh9bjtkluGD9/F95cdhCLNx7Dj76n8TPlX64h afAMT4dHWDrc956H/9Fc+Mfm47Y5ARAme7X2Ih2mbkNKsf76BozB9Z0dYD8k2o0/sgo+aW1aW8AI uEd3FEDZSU1r6Sk6SatpeydWvc/mcLFmkGAbQI51f5AML1OT+UGcGkvP6LAixYBNaQZ4ZlfBI6sK 7iQ/ytECC0y4k7YVq/qdJPnXFLCkHBVuJdf6n4c3YMxjmzBmwmbc9OhG3P6MK1ZtP4M8uR5Nzd3v bdw9P1gcJrIvU5wv1F2fgJFuXp2EhzzS8ZA7ySODy5PklSk2m3/xysZop3RelmCwrbUbKiLobnHK xP7CtmOExVWNuMGVuVOmJbfig9kOtP7FCTWSdfWo60EP74HQrnuR1xSw1d4JcPjrStxBjsUA+w3p VmoWIxOKe/wGTLWN+BO5XStgU3xw42vbkCO/Th2M9SID88QLrLG9zFympmYUETD78yvxUgidxJXt hopWpeIW92yU1ticzON8BW1DOZdzFgeM1M8xC94XGbPsKFgl/f4QO8AIrn7bihGrqu8bgH3wQySG 3fezCNjtBNcND67FfxeF9upEG6rrcfvbO8VxSJ7g+2D0m36Q64zXL2A9LFO8d7iEu1mboaI0uKbY Ev1FsWUEWLoNsI2ZuCegEE29+Ow1BNg/QtsCNmB7Mc5o+whgc7/ejxv+tgq3WwAbTr3HGV+G9+pE K3XVuJHVwayF1pe8MObdQKgrazsGbAbplW3YdaoYlxJ9qdDKTsII50yek9kVWucReK0QHi29ALCH d/Wu0m9oMOMPQXI+m8IC2NAdMmRXNfYNwJasi8bQe21N5OhHN+Duye4o01X3+A2EnZG1HSqa7Im/ fhwCYx3/sHJNNYbMbAfYf7Zi7b70XwxgLMYFtqvkUzL/Ypis9fGfErVtAaNEf7hbNs5p63v+2TX1 GMhKFtahIu9CjN4ph8ZuYuA1BSwsJg/D7l+FMWM3ioCxXuQQcrFpX4Sjpr77pq0kd3pgwR4+F8xa pnjOA09+HdG6Tbm+FqPeDmoL2Ov+uHtRGBILtKimHM7c3PMpwH0NsBkdjEU+ZjcWGV9aI7qW4GSX 5G/Kwrjdcqhru3/MKxua8fSBUj4J0VqmoN7kPSHKNp2EawoYg2jiW/4YTs3kHeM5YKwO5vDPtXh6 fhDC4gqgN154ZTVS22+g+9OKdNiwJxV3zQ2E8LRr20IrwfbGGtt0nSZzM/79+T7KzXxtgLEmkyAb 9FYg/vrZfjyy7BCeXBWDiT9btOoYJq6OxcQ1cVyrSWvjCJ7KPgvYnChll4PdZuokTNor5z1OK2Cs TEGQ3bOjEAG5VSjvYGoyG01gUGXrG+CWWcmTexEuuzqYRwGejSxv87xrXgc7fb4MvyOwbvzHarFM IRZan3DE4Ec2YBg1nfe9sQ0vLg7FrB+jRL1EedvYhXtw9yx/DGXVezZM9KybbUarFbBn3bF8d1qb PToeoKt2Em03zZ8DxppMphmkaczRSNMCIEzfyTUjiIvNxWdis1pn70Z0tqbPAvZWpPKisyly9PUY 45HDe5NWwFwtxVXSbdsK8Xi4ElMjS/Aa6YUDJXg4TIm7AmUYzuaAsWEi9/wLK/nuBViQoOtbgLGI TZTjLy9swSByspHUXDLAbnnKGSMnOmHweEf0YxX8RzbxsUjLnHzhaRfKudwx6EVPDBCHiry4WJLP mkpSjKWKb436JjOmOdJJfN5LzL+E6Zbe5IwArjcJqlkE1OxdXHN2c72zh+tt0rt7EZtjO0AJhXo+ o/UD0kf8Cx4DPj6IVEXPAJsRRCd3caw4k1XUkuOYtCOnxydi5kEFr4mtt9TEKB97NOjC7yicU9Xg 3u35HDLHbFsl39VSqXeyq+Sz6r6LZejII7/tUBGTt2XatEseggrb5s/ueQSYF8HnZ5lR4SvDf2M1 Pf5ccgLpRjbYHWaZURGuwY1R3RyLZFFcXoVFa47id8+4YADlYf0fXIfBD2/AoMc2Y/Bjjhgw3gn9 2fx75lgTHPmAN/tW0URnPtDNmkgCbMQbfvjL/GB86H4SjeYLc6oW+vM9mofHvzmIkfOCMfjtXXCY GwyHd5h2w2HeHji8F0IKhcP7e0lhcPiQtID0AVuGIz7PBlhisR7DFh2EwycH4LA4Eg6LInHz51E4 38P5YHNDcjHk63gMW3lG1NBlp/Df4Pwen4h3D5VgKLnWMMcMUUMJsmdCijvcls0YXRKvxmjvPP6F j42WbxJZv+jhbAHL1fKlD+ZcLtaB7nw+2ZAc7Qb/YvwxWIG3YtUwtfsqm0+BCQ7bZBgSqMCQICUc /BWYGa/r8edig91jIrUYsk+NIREaDCEXG3NYJ4LXLcCswaZLu4WkYs73B/HMh8H4+0w/3DvLD/dR rsaW/6LcbDw1mVOWRmD6ysP41O0E1ganIOh4IY6nl0FGoDaYu5esy7UmJCsMSKWcqjtKschk1wGp bWhqfcy6TCupRF1jj75iBbmBckpylUxtnajzmtou59J32pRUNYrPtX+dosquX0dmahLzqpmHSjEu RI4/BhThD6Q7xWUx/hYsw1hqIp+npnLakXJ8cFyNlckV8Ms3ivO9cmifnVX/dfXNSKG8Lc3QKCpF 3yg2dz0NVmDOrGxEquV12JLdbmju5XwwMSFtaUFldT30JEMNLU314hdozS29+iKmFN0IdmT1lMxX EBh8aUY1uVLT9XfMpZ8OkEICTAoJMCmkkACTQgJMCgkwKaSQAJNCAkwKCTAppJAAk0ICTAoJMCmk kACTQgJMCikkwKSQAJNCAkwKKSTApJAAk0ICTAopJMCkkACTQgJMCikkwKSQAJNCCgkwKSTApJAA k0IKCbCLRXNzM5oaG9BQV4PGxnq09OKnPKX4lQPW0tICs7kJjQ31qKs1odpoQJVBA722FDqVApry YqhLC6EpKxZvV1WoxW3qCTpzE/u5KOkXhSTAwNzITG7UiIb6WtRWV8FUVYHKChUqNCXQquQiQAwk VQkXW1eXFkHDRI9pyorE2+rWx4ugLZdBT883VuroNY0ipM2Sy/2yAWsW3aiOu5GJ3EjP3KiMu1GZ TASjFSJ7kESIeigGXKnttTSl3OUMBC4DuL62Gk1NjZB+Nu06A4y7UYPNjchBKvVq0U2sbmSFqI0b lfUSpG7L5nJWMaiZSxoNWvG9svdsJuh+xU7XVwBrEd2oScyNqinv0VtyI6sbFdu5UUE7N7rSIPUU ukKUK/NFaahZNdFnaaJOA7tI2NIKXMuvw+quLmDswLIDXF9fY8mN9JQbcTfSteZGRV3kRn1X1vfN luzz1JiqqEPRaHcNtbR+ftaUsqa9ni4oTVUdVJU14pL9TGlNQ5P4O/oSYF2BZDZbemrVdKAtuZGO 3EithPZy50bXHCzuqqwTUEVNN2sWu+tO7L+asN+7LTfUIKu0EqcK1DiSqcS+NDlJgah0BeJyy5As 1yKnzIAirRFltG2F+Du5jeIveDf3bSfsPWAtLfxqFHOjGiPvqXWQG6nbudH1ClJ7t7LmXeyiYRcR OxaXI9j/EVBX1SKj1IDjeeUITSqG78kcuMZkwInkFpsJ7xPZ8EvIQ2BiPvamFCOSQIzJLsXJgnKc k2nF5xZpjFBWVENjrEVlTYP4i9tmc8vVbpovBliL6EYsd7DWjYyVWhgsbsRyDFt3vi/nRpfTrQpF t2IXE6uPsQvtSgdzuVJ9Dc4rKxBNIAWfK4R3fLYIm1NMOpyPpcPlGIdvS1wm3EkecVnwOJ4FnxM5 8DuVSzAWYM+5IoSnyHCIXDKenDGhSINUhQ655ZWQ60wijHqCke2P/dufy8AiB8yaG7R1I9VFc6Nf ght1K3G3fGZ2UbFjc7ncqrfBcjTWTBaoq3AyX4V9qTLsOJ0PT4KOAcbkGZ8lOp1VXvEcOCZ3EtvG zbItg9Ernm+39WQuAs7kIySpCGGpVnckGAtUSCEYs8r0KCR3LK2sFd+Dqa7L0kyFwA4Ya9KsuZH6 F5IbXZ6kvUBcN+jKUVdj6rPDR+wEs39qptRXI01RgSNZJQg+Wyg2rVviOEwMLAaQD93n24HY/czt fEQYs0VA7WEUZXFI/lo5oosGkTNWd/5f+SoEg04FlbLguuipXRWwrLmVSiFW7dm45PUYrAOgNdaJ zd+J/HJyIxm2U97mSXCwptSdwGOOx4Dy7QQ63y5hzBZB8zudJ7pYp4CxMgEvEv6KoWp1qyIYtGXk VkaxwPtLCuZyVbUNUFDizzoChzKU2EUux1zLvZ3LdRc05nQ7qDnto4BZ6lsWqTtVYVvZVc7bVPDb 3a/uTKVt62t8nFEuVt9ZaeXXFPXUs9SQy2WW6nGckv6wZBm2UYdAbBZjeWfBqwuX6x5gliayyxNb 0j2pOlGbk2oPGfXGmFivTMwDLaqgZJoNuTDpNaViRZ+J5UJs0FoU9eJYtZ+JwcFySauqTZWosYgN TLOOC1N9XbXY82NiHRpW7GwgsRkWUrDOXgsqyeWKtUacLdYgKkMh9j6Zq7XNv7K7Dxgrglqnp7Be ks5ycq0n1XpirWLbGw1cbFzQKlbCsJ3UqtaTypJjNhAsis21ohNqVZOlqs2HT8ytYrUaq6QZMtfY 5ZqaxeJueolerLWFJBVjG/U0mbs5x2RgKzmesSvA2AkVT7DZLJYr+DiZNA1Fio6jiVzOUNOAQk0V ThWoxFyuy16kdMikuNToopGRAJPiioYEmBQSYFJIgEkhRYdhYoBVSJJ0hVTw/3g5kT2LNCOQAAAA AElFTkSuQmCCAA== --001a114f174e6a292b05580fdbd4 Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b476782e7d2236f8_0.2 iVBORw0KGgoAAAANSUhEUgAAABkAAAAXCAIAAABxgXNEAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANJSURBVDhP lVQrcNtAEF25su+upBKToMoUprCoTFOkMIcl0NBhKWtgyhqWsAaGljWshi6rWcSiMpnZTCdPZtS3 d4odpw7oWrPy/d69fbsrJx9/0wtdEymimrQiWWtNUhJ7Ik3bhrGdlRobiC7O8jxL7J5enu4ttFYK O0g66pGorwBL0swIIbawcAevmc0e++msXG9w7h+q0y8/6hpwVNfUtzcQNaQFiUY3gPv44T0mszSW Uv0uypvb6fq878vbryPP4PbiKEjikNdqUn3XNU+v7yr5rkcOKADo8zjHc5BESRzsx4E0ZK1fLDTQ uxjxSpPIMH8WTtuSblhCrUHHboU+d5NiMi110ygl4CEdVJvdVxusbD8KfZ8cR7ouuS77fp+gFzIi YSwfbFaU59d3t3czzDy2jsuySul5kMykgZUhRItI+WZ7v/FQMAj906M0Cj2LFUXh+CQ7yhJNLYZO 25pAdFUti5LDZCzYYbYH4cXA5A4/LhEZht7xMLG6wgJPjoZJHIdYcpFuIXDYFsB0Nt9gxZEXRX6z 0gipoUY4AvEtNf2azS1/JsDD8ndRoQxxbQu9mD8HOpneb7BwOVRjNtqRg7dO2/N9VZbVxc2kKPlO 2KyYn19PAOeDS6/HBWgfcw1WuxgxRja5BhHfqoU3Za80d8STIRlm9FxW4sKU1WKJDGywTJgBKsFR ggsLXoJ+l0RA4CJlWkIII6tjqt82jPSKstpgMTUUraS2hRB9Ys/stq0WA9E0eoCWaHltLWZRLraw 8jRiKhzqm67p+H+XR3O/cqCUVD1iDxHAFYHvReHncbaFhQykSbhcIpuWUvcx6PL4RNOs8Lp516Oj /avzYZZEqDguvLVNfs0vTeuipZumAWjoe2HAMlXz+s98AQXAfWmCj2NvPEwhtD3+Egs19enyrqp4 62AwWK1WRjUemtjxR2jdBIF3mEbHedequ7Ewe/29QA8/nbTnbRF1X8csjYYZum6jo8Xa0stOIZsA smrAo+WBYqmFvjwbpWfHyb9AO2K0cKeXExumpWO/rocf3p/k+Bza6R32Ui+75fukRKRoagChmUdG l7XG/4dVzvX5FWfz5HAvPwheZfJiATWx025/PjxU9WurO+f/AuGBrJ2oZ6UiAAAAAElFTkSuQmCC AA== --001a114f174e6a292b05580fdbd4 Content-Type: image/jpeg; name="image005.jpg" Content-Disposition: inline; filename="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: b476782e7d2236f8_0.5 /9j/4QTDRXhpZgAATU0AKgAAAAgADAEAAAMAAAABACIAAAEBAAMAAAABACEAAAECAAMAAAADAAAA ngEGAAMAAAABAAIAAAESAAMAAAABAAEAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAApAEbAAUAAAAB AAAArAEoAAMAAAABAAIAAAExAAIAAAAeAAAAtAEyAAIAAAAUAAAA0odpAAQAAAABAAAA6AAAASAA CAAIAAgADqYAAAAnEAAOpgAAACcQQWRvYmUgUGhvdG9zaG9wIENTNiAoV2luZG93cykAMjAxMzow MjoxMyAxODozMDoxNwAAAAAEkAAABwAAAAQwMjIxoAEAAwAAAAH//wAAoAIABAAAAAEAAAAaoAMA BAAAAAEAAAAZAAAAAAAAAAYBAwADAAAAAQAGAAABGgAFAAAAAQAAAW4BGwAFAAAAAQAAAXYBKAAD AAAAAQACAAACAQAEAAAAAQAAAX4CAgAEAAAAAQAAAz0AAAAAAAAASAAAAAEAAABIAAAAAf/Y/+0A DEFkb2JlX0NNAAL/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMV ExMYEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQO Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoD ASIAAhEBAxEB/90ABAAC/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDU6vhfZOoXUjRm7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMD Z9N22weU72rNOK52e/OFjDSSXttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcET qa+idaxTXabA0NNx/rna/T+p7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJ oyxox4R7XvA1+jw8Mv0k+2dDZ9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaG mHWO0Ahdp2QsX+a+bvyrM572fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/m LRgJ06s/0T2f0PZ/b/3zD+v9z9L3P+c//9n/7QyiUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAAAA8c AVoAAxslRxwCAAACWbcAOEJJTQQlAAAAAAAQ/bunQeEGH/PaAZu8hO6nizhCSU0EOgAAAAABIQAA ABAAAAABAAAAAAALcHJpbnRPdXRwdXQAAAAFAAAAAFBzdFNib29sAQAAAABJbnRlZW51bQAAAABJ bnRlAAAAAENscm0AAAAPcHJpbnRTaXh0ZWVuQml0Ym9vbAAAAAALcHJpbnRlck5hbWVURVhUAAAA GgBcAFwAUABzAHMALQAyADAAcAAtAHYAZQBsAGkALQAwADEAXABMAE8ATgBEAFIARQBTAAAAAAAP cHJpbnRQcm9vZlNldHVwT2JqYwAAABEARgBvAHIAbQBhAHQAIABkACcA6QBwAHIAZQB1AHYAZQAA AAAACnByb29mU2V0dXAAAAABAAAAAEJsdG5lbnVtAAAADGJ1aWx0aW5Qcm9vZgAAAAlwcm9vZkNN WUsAOEJJTQQ7AAAAAAItAAAAEAAAAAEAAAAAABJwcmludE91dHB1dE9wdGlvbnMAAAAXAAAAAENw dG5ib29sAAAAAABDbGJyYm9vbAAAAAAAUmdzTWJvb2wAAAAAAENybkNib29sAAAAAABDbnRDYm9v bAAAAAAATGJsc2Jvb2wAAAAAAE5ndHZib29sAAAAAABFbWxEYm9vbAAAAAAASW50cmJvb2wAAAAA AEJja2dPYmpjAAAAAQAAAAAAAFJHQkMAAAADAAAAAFJkICBkb3ViQG/gAAAAAAAAAAAAR3JuIGRv dWJAb+AAAAAAAAAAAABCbCAgZG91YkBv4AAAAAAAAAAAAEJyZFRVbnRGI1JsdAAAAAAAAAAAAAAA AEJsZCBVbnRGI1JsdAAAAAAAAAAAAAAAAFJzbHRVbnRGI1B4bEBYAAAAAAAAAAAACnZlY3RvckRh dGFib29sAQAAAABQZ1BzZW51bQAAAABQZ1BzAAAAAFBnUEMAAAAATGVmdFVudEYjUmx0AAAAAAAA AAAAAAAAVG9wIFVudEYjUmx0AAAAAAAAAAAAAAAAU2NsIFVudEYjUHJjQFkAAAAAAAAAAAAQY3Jv cFdoZW5QcmludGluZ2Jvb2wAAAAADmNyb3BSZWN0Qm90dG9tbG9uZwAAAAAAAAAMY3JvcFJlY3RM ZWZ0bG9uZwAAAAAAAAANY3JvcFJlY3RSaWdodGxvbmcAAAAAAAAAC2Nyb3BSZWN0VG9wbG9uZwAA AAAAOEJJTQPtAAAAAAAQAGAAAAABAAIAYAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAAAAA/gAAA OEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAAAAEAOEJJ TScQAAAAAAAKAAEAAAAAAAAAAjhCSU0D9QAAAAAASAAvZmYAAQBsZmYABgAAAAAAAQAvZmYAAQCh mZoABgAAAAAAAQAyAAAAAQBaAAAABgAAAAAAAQA1AAAAAQAtAAAABgAAAAAAAThCSU0D+AAAAAAA cAAA/////////////////////////////wPoAAAAAP////////////////////////////8D6AAA AAD/////////////////////////////A+gAAAAA/////////////////////////////wPoAAA4 QklNBAgAAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeAAAAAAAEAAAAADhCSU0EGgAAAAADVQAA AAYAAAAAAAAAAAAAABkAAAAaAAAAEABwAGkAYwB0AG8ALQBmAGIAIABjAG8AcABpAGUAIAA0AAAA AQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAaAAAAGQAAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAABAAAAABAAAAAAAAbnVsbAAAAAIAAAAGYm91bmRzT2JqYwAAAAEAAAAA AABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAATGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAA GQAAAABSZ2h0bG9uZwAAABoAAAAGc2xpY2VzVmxMcwAAAAFPYmpjAAAAAQAAAAAABXNsaWNlAAAA EgAAAAdzbGljZUlEbG9uZwAAAAAAAAAHZ3JvdXBJRGxvbmcAAAAAAAAABm9yaWdpbmVudW0AAAAM RVNsaWNlT3JpZ2luAAAADWF1dG9HZW5lcmF0ZWQAAAAAVHlwZWVudW0AAAAKRVNsaWNlVHlwZQAA AABJbWcgAAAABmJvdW5kc09iamMAAAABAAAAAAAAUmN0MQAAAAQAAAAAVG9wIGxvbmcAAAAAAAAA AExlZnRsb25nAAAAAAAAAABCdG9tbG9uZwAAABkAAAAAUmdodGxvbmcAAAAaAAAAA3VybFRFWFQA AAABAAAAAAAAbnVsbFRFWFQAAAABAAAAAAAATXNnZVRFWFQAAAABAAAAAAAGYWx0VGFnVEVYVAAA AAEAAAAAAA5jZWxsVGV4dElzSFRNTGJvb2wBAAAACGNlbGxUZXh0VEVYVAAAAAEAAAAAAAlob3J6 QWxpZ25lbnVtAAAAD0VTbGljZUhvcnpBbGlnbgAAAAdkZWZhdWx0AAAACXZlcnRBbGlnbmVudW0A AAAPRVNsaWNlVmVydEFsaWduAAAAB2RlZmF1bHQAAAALYmdDb2xvclR5cGVlbnVtAAAAEUVTbGlj ZUJHQ29sb3JUeXBlAAAAAE5vbmUAAAAJdG9wT3V0c2V0bG9uZwAAAAAAAAAKbGVmdE91dHNldGxv bmcAAAAAAAAADGJvdHRvbU91dHNldGxvbmcAAAAAAAAAC3JpZ2h0T3V0c2V0bG9uZwAAAAAAOEJJ TQQoAAAAAAAMAAAAAj/wAAAAAAAAOEJJTQQRAAAAAAABAQA4QklNBBQAAAAAAAQAAAAIOEJJTQQM AAAAAANZAAAAAQAAABoAAAAZAAAAUAAAB9AAAAM9ABgAAf/Y/+0ADEFkb2JlX0NNAAL/7gAOQWRv YmUAZIAAAAAB/9sAhAAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwMDBEMDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0LCw0ODRAODhAUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwM EQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAZABoDASIAAhEBAxEB/90ABAAC/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUGBwgJ CgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0coLRQwcl klPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIEQVFhcSITBTKBkRSh sUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0ZeLys4TD03Xj80aUpIW0 lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMBAAIRAxEAPwDU6vhfZOoXUjRm 7ez+q73D/NSx+j32kNsLajaP0Ze4B3iHGv6W1/8AVW/9Z8Vv6DMDZ9N22weU72rNOK52e/OFjDSS XttLhpu4a9p936OfoLEy4BDPMEEi7A/R4Z+ounDMZY4m60onrcETqa+idaxTXabA0NNx/rna/T+p 7l2+5vj5/Jed5Qbdk2OqB22PJY3vBPtGi3/X6z/3Hs/ofp8fn/vJoyxox4R7XvA1+jw8Mv0k+2dD Z9z2j/evij0f/9D0vOxm5WJbQfz2+0/yh7m/9JcnidJysyzbWzaGmHWO0Ahdp2QsX+a+bvyrM572 fdxe5xfLrw/u/o8Tc5T3eDJ7df4X/ctPp/RsTBh4HqXd7Hc/2G/mLRgJ06s/0T2f0PZ/b/3zD+v9 z9L3P+c//9kAOEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgA bwBwAAAAEwBBAGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwA2AAAAAQA4QklNBAYA AAAAAAcACAAAAAEBAP/hDpdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvADw/eHBhY2tldCBi ZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1s bnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMy1jMDExIDY2 LjE0NTY2MSwgMjAxMi8wMi8wNi0xNDo1NjoyNyAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC9tbS8iIHhtbG5zOnN0RXZ0PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvc1R5cGUv UmVzb3VyY2VFdmVudCMiIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4x LyIgeG1sbnM6cGhvdG9zaG9wPSJodHRwOi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIiB4 bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iIHhtcE1NOkRvY3VtZW50SUQ9 IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiB4bXBNTTpJbnN0YW5jZUlEPSJ4bXAu aWlkOjE4NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiB4bXBNTTpPcmlnaW5hbERvY3Vt ZW50SUQ9IkFGNUYyOEIxNjg5M0Q2MUZDOUZBRDJGMUMzMzREMUMyIiBkYzpmb3JtYXQ9ImltYWdl L2pwZWciIHBob3Rvc2hvcDpDb2xvck1vZGU9IjMiIHhtcDpDcmVhdGVEYXRlPSIyMDEzLTAyLTEz VDE4OjI0OjU5KzAxOjAwIiB4bXA6TW9kaWZ5RGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTow MCIgeG1wOk1ldGFkYXRhRGF0ZT0iMjAxMy0wMi0xM1QxODozMDoxNyswMTowMCI+IDx4bXBNTTpI aXN0b3J5PiA8cmRmOlNlcT4gPHJkZjpsaSBzdEV2dDphY3Rpb249InNhdmVkIiBzdEV2dDppbnN0 YW5jZUlEPSJ4bXAuaWlkOjE3NUQxNDYyRkU3NUUyMTE4NTA4QjQ5RTFGMkY4MkZEIiBzdEV2dDp3 aGVuPSIyMDEzLTAyLTEzVDE4OjMwOjE3KzAxOjAwIiBzdEV2dDpzb2Z0d2FyZUFnZW50PSJBZG9i ZSBQaG90b3Nob3AgQ1M2IChXaW5kb3dzKSIgc3RFdnQ6Y2hhbmdlZD0iLyIvPiA8cmRmOmxpIHN0 RXZ0OmFjdGlvbj0ic2F2ZWQiIHN0RXZ0Omluc3RhbmNlSUQ9InhtcC5paWQ6MTg1RDE0NjJGRTc1 RTIxMTg1MDhCNDlFMUYyRjgyRkQiIHN0RXZ0OndoZW49IjIwMTMtMDItMTNUMTg6MzA6MTcrMDE6 MDAiIHN0RXZ0OnNvZnR3YXJlQWdlbnQ9IkFkb2JlIFBob3Rvc2hvcCBDUzYgKFdpbmRvd3MpIiBz dEV2dDpjaGFuZ2VkPSIvIi8+IDwvcmRmOlNlcT4gPC94bXBNTTpIaXN0b3J5PiA8cGhvdG9zaG9w OkRvY3VtZW50QW5jZXN0b3JzPiA8cmRmOkJhZz4gPHJkZjpsaT4yNzdFNDEzRjE5NDUzMTMxQkRC QzMxMDI0Qzk0OUM5NTwvcmRmOmxpPiA8cmRmOmxpPjUwREExRkE0QkNCMjYyQjBCNUQ0NjJCMTYx MjFEQTQ4PC9yZGY6bGk+IDxyZGY6bGk+NzI1NEYyNzYzQUI5QTc5REVFQzQ0MTc0NEQwQUJGMTg8 L3JkZjpsaT4gPHJkZjpsaT5GRUFCM0E2QUJBMDRFQjUwOTMyMzA3Rjk0MDRBOENEQTwvcmRmOmxp PiA8L3JkZjpCYWc+IDwvcGhvdG9zaG9wOkRvY3VtZW50QW5jZXN0b3JzPiA8L3JkZjpEZXNjcmlw dGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1wbWV0YT4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8P3hwYWNrZXQgZW5kPSJ3Ij8+/+4ADkFkb2JlAGRA AAAAAf/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGQAaAwERAAIRAQMRAf/dAAQABP/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAAC AQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIK GcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdo aWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT1 9vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB 0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0 laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkq OkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8APp8vOl36c+QPZOzaZZabBLmZNzbWZg6xx7c3D/uS oNPkUU8S4xC9KhS9oacAgaTbjB718qbhyJ7rbp+6tQS/QKvpkU9Rxx10q9r+Zpeb/azbI9zkVjYO Wb17T58fnXrrr74h743bUY7Fbkn23safe+Lgk2XPuveeGotw0zSyfxDH5mu2Y08+cOHz1FQ1UUcs lEZqeQwzxqI9bhvk32wu5Z7PaObLgIbicGPuGFPxebYNfMUPSXmL3RWSWS95egd/BhdX0oxBZaAD VQLUeYBr0LeQ2Xt34E/NDoSbbW/6rd9NiKXbGQ7LrvHHTQRrvStrMVuCnjxyPUPR0Um2qyKsSkeV pTLBDI0l2KCTGteXfYP3v5amsbrxFlSNSK1H6p0moAHAf4fn0BbafmH3R9puZxcwaQkshGKf2YDD iSeOD5cR1tMff0H/ACuU3+a+8/z8X/AT/la/V/mP9r/T76ffvXbP+UtOHi8T8Prw4dYO/SyfwH0/ P0+3r//Q2Zv5nXVlGW6u7ugxS1x2pm6fbO8KdURoarBmsi3DiRNE0TpURJVQVNGBKfFaqEbXUkHB H74PJ12s/JvN+229bSOULK4FdPcNNSPIgGlaY6yb+7tzFPMeceVLu+0rLAzIc5IWjUFeJqD+R49E ql6vrq/vbcvf0G7tpV+w6/LZnduK31lNw4mKOgjz61tPQ4rceLyFQ+cpH2XRZHwyY8Uwq3NBBS0y OkwLQSsE93vd1vl7zXE+2RLE0baaeFRSWH9qakkDgBwpmvUiWN/NabFY7Nb8pXEe5KZUY5b6irLR l/SVVFK9xdqBtR0laEkvZ9Njd79jb2y+06KtbGbn3lmqnbeHgpkkybUFbkqiPB49qOg+6ipaj7CN IoaaI2WRSsYIX3C/Mm6x87e6NlvGzyPuv0+lREoINVNFbV+oBQmtNPlx6mXYbWPkf23vNs5hvI7O W6RiXIqAXWhFCVLU9aiteHVt399fmN/z5/sL/sjP+4//ABZpP+P2/wCd7+r/AIG/9Mf/AAK95p/v L3H/AOjJcf8AJN+n+Nv+cnwf8Z4/0usM/wBzcnf9NBb/AO5Wv4B/vHx/7Hy6/9HeC7y65ou1upt8 bEqU1yZzA1S4qYMQ0Gdx4XJ4ashe4MclPk6SJrj/ABJv7i73L5Tuebva7mflRjq3NbZtDUqda5Qj zr5V6OuVOYJOXOadh3KJ6JLONWaYOGB+RUmv+x1r3dU/FHs/unOtiduYBcfQYysfH5zdecp2ocHg 6ijkmpaqKCWKnjmkrqYwnx01GkmvT428cY8i8pvbL2Y9yudtzXaUncbXBMyXJOrgTROC+gbzHn10 X5793uSuU9jhtHtQd6EKtBQLU6hVic4BNMmo/wAHV1Xx++GfU3QC02Zo6WHd2+kiWGq3tnqaH7um aQKJ4tv40maDAQNLcu4Z6lxw8zce+k3tX93P269sZfqordJt7kXuZ6mh86amP+DrCHnv3Y5i5xhC 77dtHtq/CikBc+bEBa/IcB9vRzPs4f8Ajn/b1f7D/jl9P8z/ALR+n/D3PP7vsP8AlDj/AN5HUXaz /v1uPr/s9f/S35W/zY/4IP8Aej7TSfFcf80T/l68P7a26D/q3/j2pf8Atc7l/wDegyHuNPan/khS /wDPVN/1cboQ8w/7kwf80l/wDoRV/S/+sv8AvQ9yfJ/ajoOXH9iep3t3q3X/2QA= --001a114f174e6a292b05580fdbd4--