From nobody Mon Feb 2 21:55:56 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9B1A6EDB; Mon, 2 Feb 2015 21:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 je_mKTY-zCax; Mon, 2 Feb 2015 21:55:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058CF1A3B9D; Mon, 2 Feb 2015 21:55:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOS05017; Tue, 03 Feb 2015 05:55:48 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Feb 2015 05:55:47 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 3 Feb 2015 13:55:44 +0800 From: Mingui Zhang To: "rtg-bfd@ietf.org" , "trill@ietf.org" Subject: FW: I-D Action: draft-zhang-trill-p2mp-bfd-00.txt Thread-Topic: I-D Action: draft-zhang-trill-p2mp-bfd-00.txt Thread-Index: AQHQP178M+RT+d4wp0GOQTY6hu09x5zeacmQ Date: Tue, 3 Feb 2015 05:55:43 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AB2D6D0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 05:55:53 -0000 Hi, We've just post the draft on "Point to Multipoint BFD for TRILL".=20 Now, forwarding the notification to both BFD and TRILL lists. Welcome to yo= ur comments!=20 Thanks, Mingui >-----Original Message----- >From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >internet-drafts@ietf.org >Sent: Tuesday, February 03, 2015 11:10 AM >To: i-d-announce@ietf.org >Subject: I-D Action: draft-zhang-trill-p2mp-bfd-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > > Title : Point to Multipoint BFD for TRILL > Authors : Mingui Zhang > Santosh Pallagatti > Vengada Prasad Govindan > Filename : draft-zhang-trill-p2mp-bfd-00.txt > Pages : 6 > Date : 2015-02-02 > >Abstract: > Point to multipoint (P2MP) BFD is designed to verify multipoint > connectivity. This document specifies the support of P2MP BFD in > TRILL. Similar as TRILL point to point BFD, BFD Control packets in > TRILL P2MP BFD are also transmitted using an extended RBridge > Channel. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-zhang-trill-p2mp-bfd/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-zhang-trill-p2mp-bfd-00 > > >Please note that it may take a couple of minutes from the time of submissi= on >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 From nobody Mon Feb 2 22:12:25 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EBF1A6EF3 for ; Mon, 2 Feb 2015 22:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 DhtdD8wA3OXB for ; Mon, 2 Feb 2015 22:12:22 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477C41A3BA6 for ; Mon, 2 Feb 2015 22:12:22 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 06:11:58 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0075.002; Tue, 3 Feb 2015 06:11:59 +0000 From: Santosh P K To: "rtg-bfd@ietf.org" Subject: FW: New Version Notification for draft-spallagatti-bfd-multipoint-active-tail-00.txt Thread-Topic: New Version Notification for draft-spallagatti-bfd-multipoint-active-tail-00.txt Thread-Index: AQHQP3eak54O03sZGEuLPwB1QcmAXpzecIcw Date: Tue, 3 Feb 2015 06:11:58 +0000 Message-ID: References: <20150203060639.21858.88568.idtracker@ietfa.amsl.com> In-Reply-To: <20150203060639.21858.88568.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.13] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(13464003)(51704005)(40100003)(2656002)(74316001)(122556002)(33656002)(230783001)(50986999)(54356999)(54606007)(76576001)(76176999)(87936001)(99286002)(2900100001)(86362001)(46102003)(102836002)(19580405001)(106116001)(66066001)(2351001)(15975445007)(62966003)(2950100001)(107886001)(2420400003)(450100001)(92566002)(1720100001)(110136001)(77096005)(77156002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2015 06:11:58.9258 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB822 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 06:12:24 -0000 SGVsbG8gQkZEIFdHLA0KCUEgbmV3IGRyYWZ0IGZvciBCRkQgbXVsdGlwb2ludCBhY3RpdmUgdGFp bCBoYXMgYmVlbiBwdWJsaXNoZWQuIFBsZWFzZSByZXZpZXcgYW5kIGdpdmUgbWUgeW91ciBjb21t ZW50cyBvbiB0aGlzIGRyYWZ0LiANCg0KVGhhbmtzDQpTYW50b3NoIFAgSyANCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDAzLCAyMDE1IDExOjM3IEFNDQo+IFRvOiBEYXZpZCBXYXJkOyBEYXZlIEthdHo7IFNhbnRvc2gg UCBLOyBTYW50b3NoIFAgSzsgRGF2ZSBXYXJkOyBEYXZlIEthdHoNCj4gU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zcGFsbGFnYXR0aS1iZmQtbXVsdGlwb2ludC1h Y3RpdmUtDQo+IHRhaWwtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXNwYWxsYWdhdHRpLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsLTAwLnR4dA0KPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNhbnRvc2ggUGFsbGFnYXR0aSBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQtc3BhbGxh Z2F0dGktYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwNCj4gUmV2aXNpb246CTAwDQo+IFRpdGxl OgkJQkZEIE11bHRpcG9pbnQgQWN0aXZlIFRhaWxzLg0KPiBEb2N1bWVudCBkYXRlOgkyMDE1LTAy LTAyDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMTYNCj4gVVJM OiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXNw YWxsYWdhdHRpLWJmZC0NCj4gbXVsdGlwb2ludC1hY3RpdmUtdGFpbC0wMC50eHQNCj4gU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNwYWxsYWdh dHRpLWJmZC1tdWx0aXBvaW50LQ0KPiBhY3RpdmUtdGFpbC8NCj4gSHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNwYWxsYWdhdHRpLWJmZC1tdWx0aXBvaW50 LQ0KPiBhY3RpdmUtdGFpbC0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhY3RpdmUgdGFpbCBleHRlbnNpb25zIHRvIHRoZSBCaWRpcmVjdGlvbmFs DQo+ICAgIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIGZvciBtdWx0aXBvaW50 IGFuZCBtdWx0aWNhc3QNCj4gICAgbmV0d29ya3MuICBDb21tZW50cyBvbiB0aGlzIGRyYWZ0IHNo b3VsZCBiZSBkaXJlY3RlZCB0byBydGctDQo+ICAgIGJmZEBpZXRmLm9yZy4NCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Feb 9 01:34:12 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445651A0118 for ; Mon, 9 Feb 2015 01:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, THIS_AD=0.945] autolearn=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 fH5icsmm-oI5 for ; Mon, 9 Feb 2015 01:34:08 -0800 (PST) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::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 038D71A00E5 for ; Mon, 9 Feb 2015 01:34:03 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id m20so21482911qcx.4 for ; Mon, 09 Feb 2015 01:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R72Jpms+HpZEO3tGwfrEdcI33PKCnPd1R9bPfippPxA=; b=ZwUD6hoiFqfXjCoy1C9165dMenRfvJPrGaLN7BIhgXaPWnH0mtofUSh8kBhkFQvfkz C550wyXhmaLsHthz7x+hkSpCI0/R6gd8KZNF34H84nFGkSPeoFjPtdy3GmcFxfHTmJCm x2fHLT+Vyz9xTLeC8slUACHBI2D65sdLrv+EJeMAOdIDfzE83hgvSfjE9f295UzJgetk F7nIYreaz1WifdrQCoGlB4CVJrUN2FwqKWTYEL+w5bUYpfJ+S6vKqSqA1RSCbh01Zhq9 JAIP/Ttkzg9nGJ4Mctf2hrVkFWAMMxdaK9QY933iSl5JP7R8lo74Yy5mBkhgtKA8cPTG 7Rfw== MIME-Version: 1.0 X-Received: by 10.224.80.135 with SMTP id t7mr25183436qak.65.1423474442220; Mon, 09 Feb 2015 01:34:02 -0800 (PST) Received: by 10.229.158.131 with HTTP; Mon, 9 Feb 2015 01:34:02 -0800 (PST) In-Reply-To: <20150129014358353720.a90afb41@sniff.de> References: <20150124011634812813.dc68c0df@sniff.de> <20150129014358353720.a90afb41@sniff.de> Date: Mon, 9 Feb 2015 15:04:02 +0530 Message-ID: Subject: Re: (about BFD echo) From: Lokesh Bevinamarad To: Marc Binderberger Content-Type: multipart/alternative; boundary=001a11c3bba879e940050ea4783f Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 09:34:10 -0000 --001a11c3bba879e940050ea4783f Content-Type: text/plain; charset=UTF-8 Hello Marc, Thanks for the reply, If we use one knob, I think we will run into an issue that I describe below. Lets say we use one knob to control both Echo-loopback-Advertisement and honouring of it and I want to run echo in only one direction. So when the knob is turned on, my device will advertise echo and honour advertisement from peer as well. When I turn it on in one device, nothing happens because other system may not have the knob turned on and may not honour the advertisement. When I turn it on in other device, both will start sending echo packets to each other But I wanted to run echo in only one direction. So with single knob controlling both, there seems to be no way to run echo in one direction. How do current implementations which use single knob solve this issue? One way to solve this problem is always honour echo advertisement whether or not echo is turned on or off. Regards -Lokesh On Thu, Jan 29, 2015 at 3:13 PM, Marc Binderberger wrote: > Hello Lokesh, > > > I understand that we can use one knob to turn on/off the Echo > advertisement > > (non zero value in echo-rx). > > that's not what I said :-) I said "turn on/off echo". > > Some implementations have a single knob that controls both the > advertisement > as well as the honoring. > > If you like to implement two knobs, one for advertisement and one for > honoring - you are free to do so. > > > Now my question is, does RFC mean that we need another knob to control > the > > options stated above? > > I think RFC is not clear on this aspect. > > To say the least :-) because it deliberately is not saying anything. > > Again, section 6.8.9 says: > > The transmission of BFD Echo packets is otherwise outside the scope > of this specification. > > > Regards, Marc > > > > > > > > Regards > > -Lokesh > > > > > > > > > > On Sat, Jan 24, 2015 at 2:46 PM, Marc Binderberger > wrote: > >> Hello Lokesh, > >> > >> you may have received unicast replies, haven't seen anything on the list > >> though. > >> > >> > >>> echo-rx value in the control packet. But it is up to the other peer if > it > >>> wants to honour this advertisement by sending echo packets. Right? > >> > >> Indeed, from RFC 5880, section 3.2: > >> > >> The Echo function may be enabled individually in each direction. It > >> is enabled in a particular direction only when the system that loops > >> the Echo packets back signals that it will allow it, and when the > >> system that sends the Echo packets decides it wishes to. > >> > >> And section 6.8.9: > >> > >> The transmission of BFD Echo packets is otherwise outside the scope > >> of this specification. > >> > >> > >>> Does RFC mean that whether peer honours the advertisement or not should > >> be > >>> configured by admin? > >> > >> The RFC does not exclude this option and I guess that is what most > >> implementations do - they have a config knob to turn on/off echo. If you > >> come > >> up with a different mechanism you are free to implement it. > >> > >> I assume you understand that "honors the advertisement or not" is only > an > >> option when the peer sends control packets with the "Required Min Echo > RX > >> Interval" field being non-zero. In case the field is zero ... > >> > >> If the Required Min Echo RX Interval field is zero, the > >> transmission of Echo packets, if any, MUST cease. > >> > >> ... you must stop sending echo; there is no option to honor or not. > >> > >> > >> Best regards, > >> Marc > >> > >> > >> > >> > >> On Wed, 21 Jan 2015 17:26:40 +0530, Lokesh Bevinamarad wrote: > >>> Hello All, > >>> As per RFC 5880, if echo function is on, it means that device is > willing > >> to > >>> loopback the peers echo packets and advertises this by setting non zero > >>> echo-rx value in the control packet. But it is up to the other peer if > it > >>> wants to honour this advertisement by sending echo packets. Right? > >>> > >>> I have a doubt here. > >>> Does RFC mean that whether peer honours the advertisement or not should > >> be > >>> configured by admin? > >>> > >>> > >>> > >>> Regards > >>> -Lokesh > > > --001a11c3bba879e940050ea4783f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Marc,
Thanks for th= e reply,

If we use one knob, I think we will run in= to an issue that I describe below.

Lets say we use one knob to= control both Echo-loopback-Advertisement and honouring of it and I want to= run echo in only one direction.
So when the knob is turned o= n, my device will advertise echo and honour advertisement from peer as well= .

When I turn it on in one device, nothing happens because oth= er system may not have the knob turned on and may not honour the advertisem= ent.
When I turn it on in other device, both will start sending ec= ho packets to each other But I wanted to run echo in only one direction.
So with single knob controlling both, there seems to be no = way to run echo in one direction.

How do current im= plementations which use single knob solve this issue?

One way = to solve this problem is always honour echo advertisement whether or not ec= ho is turned on or off.

Regards
-Lokes= h


<= div class=3D"gmail_quote">On Thu, Jan 29, 2015 at 3:13 PM, Marc Binderberge= r <= marc@sniff.de> wrote:
Hello= Lokesh,

> I understand that we can use one knob to turn on/off the Echo advertis= ement
> (non zero value in echo-rx).

that's not what I said :-) I said "turn on/off echo".

Some implementations have a single knob that controls both the advertisemen= t
as well as the honoring.

If you like to implement two knobs, one for advertisement and one for
honoring - you are free to do so.

> Now my question is, does RFC mean that we need another knob to control= the
> options stated above?
> I think RFC is not clear on this aspect.

To say the least :-) because it deliberately is not saying anything.

Again, section 6.8.9 says:

=C2=A0 =C2=A0 The transmission of BFD Echo packets is otherwise outside the= scope
=C2=A0 =C2=A0 of this specification.


Regards, Marc




>
> Regards
> -Lokesh
>
>
>
>
> On Sat, Jan 24, 2015 at 2:46 PM, Marc Binderberger <marc@sniff.de> wrote:
>> Hello Lokesh,
>>
>> you may have received unicast replies, haven't seen anything o= n the list
>> though.
>>
>>
>>> echo-rx value in the control packet. But it is up to the other= peer if it
>>> wants to honour this advertisement by sending echo packets. Ri= ght?
>>
>> Indeed, from RFC 5880, section 3.2:
>>
>>=C2=A0 =C2=A0 The Echo function may be enabled individually in each= direction.=C2=A0 It
>>=C2=A0 =C2=A0 is enabled in a particular direction only when the sy= stem that loops
>>=C2=A0 =C2=A0 the Echo packets back signals that it will allow it, = and when the
>>=C2=A0 =C2=A0 system that sends the Echo packets decides it wishes = to.
>>
>> And section 6.8.9:
>>
>>=C2=A0 =C2=A0 The transmission of BFD Echo packets is otherwise out= side the scope
>>=C2=A0 =C2=A0 of this specification.
>>
>>
>>> Does RFC mean that whether peer honours the advertisement or n= ot should
>> be
>>> configured by admin?
>>
>> The RFC does not exclude this option and I guess that is what most=
>> implementations do - they have a config knob to turn on/off echo. = If you
>> come
>> up with a different mechanism you are free to implement it.
>>
>> I assume you understand that "honors the advertisement or not= " is only an
>> option when the peer sends control packets with the "Required= Min Echo RX
>> Interval" field being non-zero. In case the field is zero ...=
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the Required Min Echo RX Interval fie= ld is zero, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0transmission of Echo packets, if any, MU= ST cease.
>>
>> ... you must stop sending echo; there is no option to honor or not= .
>>
>>
>> Best regards,
>> Marc
>>
>>
>>
>>
>> On Wed, 21 Jan 2015 17:26:40 +0530, Lokesh Bevinamarad wrote:
>>> Hello All,
>>> As per RFC 5880, if echo function is on, it means that device = is willing
>> to
>>> loopback the peers echo packets and advertises this by setting= non zero
>>> echo-rx value in the control packet. But it is up to the other= peer if it
>>> wants to honour this advertisement by sending echo packets. Ri= ght?
>>>
>>> I have a doubt here.
>>> Does RFC mean that whether peer honours the advertisement or n= ot should
>> be
>>> configured by admin?
>>>
>>>
>>>
>>> Regards
>>> -Lokesh
>

--001a11c3bba879e940050ea4783f-- From nobody Mon Feb 9 14:04:40 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D621A8940 for ; Mon, 9 Feb 2015 13:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 v_r2LMkoC_Lg for ; Mon, 9 Feb 2015 13:29:45 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 32ED81A894C for ; Mon, 9 Feb 2015 13:29:45 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C51D6C21E; Mon, 9 Feb 2015 16:29:44 -0500 (EST) Date: Mon, 9 Feb 2015 16:29:44 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [iesg-secretary@ietf.org: Document Action: 'Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide' to Informational RFC (draft-ietf-karp-bfd-analysis-08.txt)] Message-ID: <20150209212944.GC26053@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 21:29:46 -0000 Thanks all who helped drive this to conclusion. At some point it'd be nice to spell out the necessary cryptographic procedures to use non-meticulous mode with stronger auth. -- Jeff ----- Forwarded message from The IESG ----- Date: Mon, 09 Feb 2015 10:27:28 -0800 From: The IESG To: IETF-Announce Cc: RFC Editor Subject: Document Action: 'Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide' to Informational RFC (draft-ietf-karp-bfd-analysis-08.txt) The IESG has approved the following document: - 'Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide' (draft-ietf-karp-bfd-analysis-08.txt) as Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-karp-bfd-analysis/ Technical Summary This document analyzes the security mechanisms for BFD, according to the guidelines set forth in Section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines. In analyzes the current security state of BFD, describes gaps, and discusses work that needs to be done to close those gaps. Working Group Summary The KARP Working Group was happy with the document. There was no controversy. A chair of the BFD WG was active in its development and review, and the document was shown to the BFD WG for review and feedback. The KARP WG has now closed, but WG last call completed while the group was still active. The draft is being advanced as AD Sponsored. Document Quality This document has been reviewed by the KARP Working Group and by the KARP chairs. It does a good job laying out the issues with securing BFD. The level of detail is appropriate to the working group goals as laid out in the charter and the guidelines document. Personnel Brian Weis is the document shepherd. Adrian Farrel is the responsible AD. ----- End forwarded message ----- From nobody Thu Feb 12 10:40:30 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31B31A00A8; Thu, 12 Feb 2015 10:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 jYKvcLH8lgex; Thu, 12 Feb 2015 10:40:21 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4121A1AE5; Thu, 12 Feb 2015 10:40:17 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-c1-54dc93b747d9 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2B.73.25146.7B39CD45; Thu, 12 Feb 2015 12:51:19 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 13:40:16 -0500 From: Gregory Mirsky To: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "spring@ietf.org" Subject: FW: New Version Notification for draft-mirsky-mpls-bfd-directed-02.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-02.txt Thread-Index: AQHQRvHNwCfJMiQTLEK8YUR7hkvUlJztVp0w Date: Thu, 12 Feb 2015 18:40:15 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B900074@eusaamb103.ericsson.se> References: <20150212182905.4209.86980.idtracker@ietfa.amsl.com> In-Reply-To: <20150212182905.4209.86980.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPgu72yXdCDA6vl7K4tXQlq8XnP9sY LY5f+M3owOyxZMlPpgDGKC6blNSczLLUIn27BK6MO4+OsxVsEa1ofnOdqYHxjUgXIyeHhICJ RN/cyawQtpjEhXvr2boYuTiEBI4wSiw68J0dwlnOKLG6YxsjSBWbgJHEi4097CC2iEChxOd9 11hAbGGBQInD174yQcSDJE5d+MQIYRtJPD84jw3EZhFQlfjQ8oK5i5GDg1fAV2LWWVGQsJCA g8SlqUvBRnIKOErsnH2cGcRmBDro+6k1YCOZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/9BPaAk MWnpOVaQ8cwCmhLrd+lDtCpKTOl+CDaeV0BQ4uTMJywTGEVnIZk6C6FjFpKOWUg6FjCyrGLk KC1OLctNNzLcxAiMhGMSbI47GBd8sjzEKMDBqMTD++He7RAh1sSy4srcQ4zSHCxK4rxlVw6G CAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBsiwmZ8Dzum/szQ18xtsBivyknT39bxGv523h3 /8eFH9v+/XLJ72q3cZ9hLrFOniv9Z4FAw/GPYt8iDuoy+lmfYZv4wV+od9XBVVylqo3tHkWK a1+vnu6iH/zr9K8D1yyv6GaVCtaF/TlUMTVAz0lDe23/ntbg3abR4ufMn36Lm6x1oePrBwYl luKMREMt5qLiRADR0u7XZQIAAA== Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:40:24 -0000 RGVhciBBbGwsDQphdXRob3JzIG9mIHR3byBkcmFmdHMsIGRyYWZ0LWNoZW4tbXBscy1iZmQtZW5o YW5jZW1lbnQgYW5kIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZCwgZGVjaWRlZCB0byB3 b3JrIHRvZ2V0aGVyIG9uIHRoZSBwcm9ibGVtcyByZWxhdGVkIHRvIGNvbnRyb2xsaW5nIHJldmVy c2UgcGF0aCBvZiBhIEJGRCBzZXNzaW9uLiBUaGlzIGlzIG5ldyB2ZXJzaW9uIG9mIG91ciBqb2lu dCBlZmZvcnRzIHRvIG1vdmUgdGhlIHdvcmsgZnVydGhlci4gV2UgbmVlZCB5b3VyIGhlbHAgYnkg c2hhcmluZyB5b3VyIGNvbW1lbnRzLCBzdWdnZXN0aW9ucyBiZWZvcmUgdGhlIG1lZXRpbmcgaW4g RGFsbGFzIG9uIHRoZXNlIG1haWxpbmcgbGlzdHMuDQoNCglSZWdhcmRzLA0KCQlHcmVnDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDEyLCAyMDE1IDEwOjI5IEFNDQpUbzogTWFjaCBDaGVuOyBHcmVnb3J5IE1pcnNreTsgSmVm ZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IEplZmYgVGFudHN1cmE7IE1hY2ggQ2hlbiAoR3Vv eWkpOyBJbHlhIFZhcmxhc2hraW47IElseWEgVmFybGFzaGtpbg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDIudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3Rl ZC0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4gUGF0aA0KRG9jdW1lbnQg ZGF0ZToJMjAxNS0wMi0xMg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTANClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVj dGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1p cnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMg0KRGlmZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMg0KDQpB YnN0cmFjdDoNCiAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMg ZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCiAgIGRpcmVjdGlvbmFsIHBhdGhzLiAgV2hlbiBhIEJG RCBzZXNzaW9uIG1vbml0b3JzIGluIGl0cyBmb3J3YXJkDQogICBkaXJlY3Rpb24gYW4gZXhwbGlj aXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpcyBhIG5lZWQgdG8gYmUgYWJsZSB0bw0KICAgZGlyZWN0 IGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHNwZWNpZmljIHBhdGggYXMgcmV2ZXJzZSBkaXJlY3Rp b24gb2YNCiAgIHRoZSBCRkQgc2Vzc2lvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Fri Feb 13 10:31:55 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CB71A0366 for ; Fri, 13 Feb 2015 10:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 2M3s2H9Xge_V for ; Fri, 13 Feb 2015 10:31:43 -0800 (PST) Received: from BAY004-OMC4S15.hotmail.com (bay004-omc4s15.hotmail.com [65.54.190.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4121A0273 for ; Fri, 13 Feb 2015 10:31:43 -0800 (PST) Received: from BAY176-W28 ([65.54.190.201]) by BAY004-OMC4S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 13 Feb 2015 10:31:43 -0800 X-TMN: [/Qx3x5Llfj4rpmERYfRS8AdbHqjxmqF/] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_7a1315a5-b6bf-49e4-8ead-d173ff062e99_" From: Ashesh Mishra To: "rtg-bfd@ietf.org" Subject: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Date: Fri, 13 Feb 2015 10:31:43 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2015 18:31:43.0575 (UTC) FILETIME=[50EA8E70:01D047BB] Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:31:46 -0000 --_7a1315a5-b6bf-49e4-8ead-d173ff062e99_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi BFD Experts=2C The 00 version of BFD Authentication Optimization draft is now online: https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ The draft describes method for selectively authenticating certain BFD frame= s to avoid computational overhead.=20 Thanks=2CAuthors --Ashesh Mishra = --_7a1315a5-b6bf-49e4-8ead-d173ff062e99_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi BFD Experts=2C

The 00 version of BFD Authentication Optimization draft is = now online:


The draft describes method for selectively authenticating certain BFD fr= ames to avoid computational overhead. =3B

Than= ks=2C
Authors


--
Ashesh Mishra = --_7a1315a5-b6bf-49e4-8ead-d173ff062e99_-- From nobody Sun Feb 15 03:08:36 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7521A1ACA for ; Sun, 15 Feb 2015 03:08:34 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 2TSsgEDqzYJb for ; Sun, 15 Feb 2015 03:08:32 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 821141A1AC6 for ; Sun, 15 Feb 2015 03:08:32 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id gq1so33958745obb.2 for ; Sun, 15 Feb 2015 03:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=By7jgHJUFdo14SVp+fdHtN6RrfkmCIJzyk4TwZXqG2c=; b=h80Soa1/NWX8qRUmfpvyMnosCdxdgF4telALZs9dZeOTlduBIA7nANgKkZ3DHUzYbN cVJf3Fjtq4u7La9s0bLRmL+v2/0MSaSdw5DhxjAQk0iwOSW/efoJn3tpkpoyS4DKbWQY IRfWzhGUYEzUOHThnAWZInimeoA+jV/H3zpfEjKco2ic5BzrKRdFObqPlONvuQ6cIDFl PpgOpFBooV5xlFupz4sluoP/dh2Bbx+thSbFZJ+7i86RPFKTG7k0J0StnfdjKLieleLi KWLOBdwISZecTz2ov0UPxsgfnnqJMzeHcHD3x7xHGFGitkQ2mJwtQKrpDrBVHcGMxCl+ R1sQ== MIME-Version: 1.0 X-Received: by 10.60.139.1 with SMTP id qu1mr12057877oeb.83.1423998511816; Sun, 15 Feb 2015 03:08:31 -0800 (PST) Received: by 10.182.15.101 with HTTP; Sun, 15 Feb 2015 03:08:31 -0800 (PST) In-Reply-To: References: <20141125223733023799.7609dd07@sniff.de> Date: Sun, 15 Feb 2015 16:38:31 +0530 Message-ID: Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim From: Glen Kent To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=047d7b4724367525e0050f1e7da9 Archived-At: Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2015 11:08:35 -0000 --047d7b4724367525e0050f1e7da9 Content-Type: text/plain; charset=UTF-8 Nobo, Why do you need this mechanism to discover the remote S-BFD discriminators, when you already have ISIS and OSPF extensions to discover the remote S-BFD targets. Glen On Thu, Jan 29, 2015 at 4:16 AM, Nobo Akiya (nobo) wrote: > > To summarize: > > - I will spawn off a separate thread for the alert discriminator soon. > > Hello BFD WG, > > Finally getting around to follow up on this AI. > > > http://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/?include_text=1 > > The document describes one simple extension: Let's make S-BFD > discriminator zero(0) to have a special meaning. > > The primary driver for this is to allow an S-BFD initiator to discover the > target S-BFD discriminator, by sending an S-BFD ping packet with > your_disc=0 and getting back a valid S-BFD pong packet with "my_disc= discrimiantor>". In other words, when an S-BFD reflector receives an S-BFD > ping packet with your_disc=0, it processes it because S-BFD discriminator > zero(0) has a special meaning. > > Motivation for using this approach to discover the target S-BFD > discriminator is described in Section 2.1 of the document. > > I think it is most important to discuss this, thus let's leave out > discussions on other use of the S-BFD alert discriminator (i.e., Section > 2.2) for now. > > Personally, I think this is very useful extension to the S-BFD mechanism > that we've been working on. I'm curious to see what others think? > > Thanks! > > -Nobo > > --047d7b4724367525e0050f1e7da9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nobo,

Why do you need this m= echanism to discover the remote S-BFD discriminators, when you already have= ISIS and OSPF extensions to discover the remote S-BFD targets.

Glen

On Thu, Jan 29, 2015 at 4:16 AM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
>= ; To summarize:
> - I will spawn off a separate thread for the alert discriminator soon.=

Hello BFD WG,

Finally getting around to follow up on this AI.

http://datatracker.ietf.org/doc= /draft-akiya-bfd-seamless-alert-discrim/?include_text=3D1

The document describes one simple extension: Let's make S-BFD discrimin= ator zero(0) to have a special meaning.

The primary driver for this is to allow an S-BFD initiator to discover the = target S-BFD discriminator, by sending an S-BFD ping packet with your_disc= =3D0 and getting back a valid S-BFD pong packet with "my_disc=3D<S-= BFD discrimiantor>". In other words, when an S-BFD reflector receiv= es an S-BFD ping packet with your_disc=3D0, it processes it because S-BFD d= iscriminator zero(0) has a special meaning.

Motivation for using this approach to discover the target S-BFD discriminat= or is described in Section 2.1 of the document.

I think it is most important to discuss this, thus let's leave out disc= ussions on other use of the S-BFD alert discriminator (i.e., Section 2.2) f= or now.

Personally, I think this is very useful extension to the S-BFD mechanism th= at we've been working on. I'm curious to see what others think?

Thanks!

-Nobo


--047d7b4724367525e0050f1e7da9-- From nobody Mon Feb 16 07:48:42 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7A1A88DA for ; Mon, 16 Feb 2015 07:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 xXwfrA2kiyRm for ; Mon, 16 Feb 2015 07:48:32 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122331A88C3 for ; Mon, 16 Feb 2015 07:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16836; q=dns/txt; s=iport; t=1424101711; x=1425311311; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A+ZNvztsnKHGs/5Sd4ob6Gr3smUTy9plDobdnYUe4V4=; b=UfA782Wse2actgA1jhMiBpvYEQRJoUKiyhZASvFMzLJNEyS8MnP2jug9 ZEa9WHxCqpQqtRXbJbrfbVz56kMAcZ2t5dQegKmbDK9luBTOu1v4mcGph k3YXjO+WmsL6oa/FEDOVtvkjBOF2CxyRcY3lK2NH/sojVqQfhWWBOUw3A E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0GAKkQ4lStJV2Y/2dsb2JhbABcgkNDUloEgn+wCY1DgXCFbwIceUMBAQEBAQF8hAwBAQEDASMKTAULAgEIEQQBAQEKHQMCAgIfERQJAwUCBA4FCIgRAwkIDbZZkRkNhUYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiwyCQ4F5DSQGAYJoLoEUBY1MgWyDV4QagxaLOYYEIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208,217";a="396878766" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 16 Feb 2015 15:48:30 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1GFmUpG006265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 15:48:30 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.130]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:48:30 -0600 From: "Nobo Akiya (nobo)" To: Glen Kent Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAAAB0lM4AAWZpcAAD0O34AAALf5AAx0cNYwA33osIAALwmLYA== Date: Mon, 16 Feb 2015 15:48:29 +0000 Message-ID: References: <20141125223733023799.7609dd07@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.67] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD39447CF8AC9xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 15:48:39 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD39447CF8AC9xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR2xlbiwNCg0KSSBhcHByZWNpYXRlIHlvdSBwcm92aWRpbmcgYSBjb21tZW50IG9uIHRoaXMg dG9waWMuDQoNClllcyB0aGVyZSBhcmUgSVNJUyBhbmQgT1NQRiBleHRlbnNpb25zIHRvIGRpc2Nv dmVyIHJlbW90ZSBTLUJGRCBkaXNjcmltaW5hdG9ycy4gVGhpcyB3aWxsIGNvdmVyIG1hbnkgc2Nl bmFyaW9zIGFuZCBjYW4gYWxzbyBiZSBsZXZlcmFnZWQgdG8gZGV0ZWN0IGRpc2NyaW1pbmF0b3Ig Y29sbGlzaW9ucyB3aXRoaW4gdGhlIElHUCBkb21haW4uIFRoZXJlIGFyZSBjb3VwbGUgb2Ygb3Ro ZXIgc2NlbmFyaW9zIHdoaWNoIHdlIHRoaW5rIGluLWJhbmQgZGlzY292ZXJ5IG9mIHJlbW90ZSBT LUJGRCBkaXNjcmltaW5hdG9ycyAoaS5lLiwgYWxlcnQgZGlzY3JpbWluYXRvcikgd2lsbCBiZSBo ZWxwZnVsLg0KDQpGaXJzdCBpcyBtb25pdG9yaW5nIG9mIGEgdGFyZ2V0IGJleW9uZCB0aGUgSUdQ IGRvbWFpbiAoZS5nLiwgaW50ZXItQVMsIE1TLVBXLCBldGMpLg0KDQpTZWNvbmQgaXMgdXNhZ2Ug b2YgUy1CRkQgaW4gYSBzY2VuYXJpbyB3aGVyZSB0aGVyZSBpcyBubyBJU0lTL09TUEYgcnVubmlu ZyAoZS5nLiwgSVAvTVBMUyBzdGF0aWNhbGx5IHByb3Zpc2lvbmVkIG5ldHdvcmtzLCBUUCwgZXRj KS4NCg0KVGhpcmQgaXMgdG8gYXZvaWQgcmVxdWlyaW5nIHNvbWUgZnVydGhlciBhcHBsaWNhdGlv bnMgdG8gZGVmaW5lIFMtQkZEIGRpc2NyaW1pbmF0b3IgYWR2ZXJ0aXNlbWVudHMgd2hlbiB0aGV5 IHdhbnQgdG8gdXNlIFMtQkZEIChlLmcuLCBzaW1wbGUgdHVubmVscykuDQoNCkkgaG9wZSB0aGlz IGNsYXJpZmllcyB0aGUg4oCcd2h54oCdIHF1ZXN0aW9uLCBidXQgZG8gbGV0IHVzIGtub3cgaWYg eW91IHRoaW5rIGl0IGRvZXNu4oCZdCBvciBpZiB5b3UgdGhpbmsgaXQgZG9lc27igJl0IHByb3Zp ZGUgc3VmZmljaWVudCByZWFzb25zIHRvIGNvbnN0cnVjdCBhbiBpbi1iYW5kIFMtQkZEIGRpc2Ny aW1pbmF0b3IgZGlzY292ZXJ5IG1lY2hhbmlzbS4NCg0KV2UgYWxzbyB0cmllZCB0byBicmllZmx5 IGNhcHR1cmUgdGhlc2UgaW4gc2VjdGlvbiAyLjEgb2YgdGhlIGRvY3VtZW50IChkcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYWxlcnQtZGlzY3JpbSkuIEl0IHdvdWxkIGFsc28gYmUgaGVscGZ1bCBp ZiB5b3UgY2FuIGJyb3dzZSB0aHJvdWdoIHRoZW0uDQoNClRoYW5rcyENCg0KLU5vYm8NCg0KRnJv bTogR2xlbiBLZW50IFttYWlsdG86Z2xlbi5rZW50QGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwg RmVicnVhcnkgMTUsIDIwMTUgNjowOSBBTQ0KVG86IE5vYm8gQWtpeWEgKG5vYm8pDQpDYzogTWFy YyBCaW5kZXJiZXJnZXI7IFNhbSBBbGRyaW47IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1hbmF2QGlvbm9z bmV0d29ya3MuY29tDQpTdWJqZWN0OiBSZTogU2Vla2luZyBvcGluaW9ucyBvbiBkcmFmdC1ha2l5 YS1iZmQtc2VhbWxlc3MtYWxlcnQtZGlzY3JpbQ0KDQpOb2JvLA0KDQpXaHkgZG8geW91IG5lZWQg dGhpcyBtZWNoYW5pc20gdG8gZGlzY292ZXIgdGhlIHJlbW90ZSBTLUJGRCBkaXNjcmltaW5hdG9y cywgd2hlbiB5b3UgYWxyZWFkeSBoYXZlIElTSVMgYW5kIE9TUEYgZXh0ZW5zaW9ucyB0byBkaXNj b3ZlciB0aGUgcmVtb3RlIFMtQkZEIHRhcmdldHMuDQoNCkdsZW4NCg0KT24gVGh1LCBKYW4gMjks IDIwMTUgYXQgNDoxNiBBTSwgTm9ibyBBa2l5YSAobm9ibykgPG5vYm9AY2lzY28uY29tPG1haWx0 bzpub2JvQGNpc2NvLmNvbT4+IHdyb3RlOg0KPiBUbyBzdW1tYXJpemU6DQo+IC0gSSB3aWxsIHNw YXduIG9mZiBhIHNlcGFyYXRlIHRocmVhZCBmb3IgdGhlIGFsZXJ0IGRpc2NyaW1pbmF0b3Igc29v bi4NCg0KSGVsbG8gQkZEIFdHLA0KDQpGaW5hbGx5IGdldHRpbmcgYXJvdW5kIHRvIGZvbGxvdyB1 cCBvbiB0aGlzIEFJLg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFr aXlhLWJmZC1zZWFtbGVzcy1hbGVydC1kaXNjcmltLz9pbmNsdWRlX3RleHQ9MQ0KDQpUaGUgZG9j dW1lbnQgZGVzY3JpYmVzIG9uZSBzaW1wbGUgZXh0ZW5zaW9uOiBMZXQncyBtYWtlIFMtQkZEIGRp c2NyaW1pbmF0b3IgemVybygwKSB0byBoYXZlIGEgc3BlY2lhbCBtZWFuaW5nLg0KDQpUaGUgcHJp bWFyeSBkcml2ZXIgZm9yIHRoaXMgaXMgdG8gYWxsb3cgYW4gUy1CRkQgaW5pdGlhdG9yIHRvIGRp c2NvdmVyIHRoZSB0YXJnZXQgUy1CRkQgZGlzY3JpbWluYXRvciwgYnkgc2VuZGluZyBhbiBTLUJG RCBwaW5nIHBhY2tldCB3aXRoIHlvdXJfZGlzYz0wIGFuZCBnZXR0aW5nIGJhY2sgYSB2YWxpZCBT LUJGRCBwb25nIHBhY2tldCB3aXRoICJteV9kaXNjPTxTLUJGRCBkaXNjcmltaWFudG9yPiIuIElu IG90aGVyIHdvcmRzLCB3aGVuIGFuIFMtQkZEIHJlZmxlY3RvciByZWNlaXZlcyBhbiBTLUJGRCBw aW5nIHBhY2tldCB3aXRoIHlvdXJfZGlzYz0wLCBpdCBwcm9jZXNzZXMgaXQgYmVjYXVzZSBTLUJG RCBkaXNjcmltaW5hdG9yIHplcm8oMCkgaGFzIGEgc3BlY2lhbCBtZWFuaW5nLg0KDQpNb3RpdmF0 aW9uIGZvciB1c2luZyB0aGlzIGFwcHJvYWNoIHRvIGRpc2NvdmVyIHRoZSB0YXJnZXQgUy1CRkQg ZGlzY3JpbWluYXRvciBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEgb2YgdGhlIGRvY3VtZW50 Lg0KDQpJIHRoaW5rIGl0IGlzIG1vc3QgaW1wb3J0YW50IHRvIGRpc2N1c3MgdGhpcywgdGh1cyBs ZXQncyBsZWF2ZSBvdXQgZGlzY3Vzc2lvbnMgb24gb3RoZXIgdXNlIG9mIHRoZSBTLUJGRCBhbGVy dCBkaXNjcmltaW5hdG9yIChpLmUuLCBTZWN0aW9uIDIuMikgZm9yIG5vdy4NCg0KUGVyc29uYWxs eSwgSSB0aGluayB0aGlzIGlzIHZlcnkgdXNlZnVsIGV4dGVuc2lvbiB0byB0aGUgUy1CRkQgbWVj aGFuaXNtIHRoYXQgd2UndmUgYmVlbiB3b3JraW5nIG9uLiBJJ20gY3VyaW91cyB0byBzZWUgd2hh dCBvdGhlcnMgdGhpbms/DQoNClRoYW5rcyENCg0KLU5vYm8NCg0K --_000_CECE764681BE964CBE1DFF78F3CDD39447CF8AC9xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpo b2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgR2xlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYXBwcmVjaWF0ZSB5b3UgcHJv dmlkaW5nIGEgY29tbWVudCBvbiB0aGlzIHRvcGljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzIHRoZXJlIGFyZSBJ U0lTIGFuZCBPU1BGIGV4dGVuc2lvbnMgdG8gZGlzY292ZXIgcmVtb3RlIFMtQkZEIGRpc2NyaW1p bmF0b3JzLiBUaGlzIHdpbGwgY292ZXIgbWFueSBzY2VuYXJpb3MgYW5kIGNhbiBhbHNvIGJlIGxl dmVyYWdlZCB0byBkZXRlY3QgZGlzY3JpbWluYXRvcg0KIGNvbGxpc2lvbnMgd2l0aGluIHRoZSBJ R1AgZG9tYWluLiBUaGVyZSBhcmUgY291cGxlIG9mIG90aGVyIHNjZW5hcmlvcyB3aGljaCB3ZSB0 aGluayBpbi1iYW5kIGRpc2NvdmVyeSBvZiByZW1vdGUgUy1CRkQgZGlzY3JpbWluYXRvcnMgKGku ZS4sIGFsZXJ0IGRpc2NyaW1pbmF0b3IpIHdpbGwgYmUgaGVscGZ1bC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0 IGlzIG1vbml0b3Jpbmcgb2YgYSB0YXJnZXQgYmV5b25kIHRoZSBJR1AgZG9tYWluIChlLmcuLCBp bnRlci1BUywgTVMtUFcsIGV0YykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWNvbmQgaXMgdXNhZ2Ugb2YgUy1CRkQg aW4gYSBzY2VuYXJpbyB3aGVyZSB0aGVyZSBpcyBubyBJU0lTL09TUEYgcnVubmluZyAoZS5nLiwg SVAvTVBMUyBzdGF0aWNhbGx5IHByb3Zpc2lvbmVkIG5ldHdvcmtzLCBUUCwgZXRjKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoaXJkIGlzIHRvIGF2b2lkIHJlcXVpcmluZyBzb21lIGZ1cnRoZXIgYXBwbGljYXRpb25z IHRvIGRlZmluZSBTLUJGRCBkaXNjcmltaW5hdG9yIGFkdmVydGlzZW1lbnRzIHdoZW4gdGhleSB3 YW50IHRvIHVzZSBTLUJGRCAoZS5nLiwgc2ltcGxlIHR1bm5lbHMpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBob3Bl IHRoaXMgY2xhcmlmaWVzIHRoZSDigJx3aHnigJ0gcXVlc3Rpb24sIGJ1dCBkbyBsZXQgdXMga25v dyBpZiB5b3UgdGhpbmsgaXQgZG9lc27igJl0IG9yIGlmIHlvdSB0aGluayBpdCBkb2VzbuKAmXQg cHJvdmlkZSBzdWZmaWNpZW50IHJlYXNvbnMgdG8gY29uc3RydWN0IGFuIGluLWJhbmQNCiBTLUJG RCBkaXNjcmltaW5hdG9yIGRpc2NvdmVyeSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBhbHNvIHRy aWVkIHRvIGJyaWVmbHkgY2FwdHVyZSB0aGVzZSBpbiBzZWN0aW9uIDIuMSBvZiB0aGUgZG9jdW1l bnQgKGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1hbGVydC1kaXNjcmltKS4gSXQgd291bGQgYWxz byBiZSBoZWxwZnVsIGlmIHlvdSBjYW4gYnJvd3NlIHRocm91Z2gNCiB0aGVtLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+LU5vYm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBHbGVuIEtlbnQgW21haWx0bzpn bGVuLmtlbnRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgRmVicnVhcnkg MTUsIDIwMTUgNjowOSBBTTxicj4NCjxiPlRvOjwvYj4gTm9ibyBBa2l5YSAobm9ibyk8YnI+DQo8 Yj5DYzo8L2I+IE1hcmMgQmluZGVyYmVyZ2VyOyBTYW0gQWxkcmluOyBydGctYmZkQGlldGYub3Jn OyBtYW5hdkBpb25vc25ldHdvcmtzLmNvbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU2Vla2lu ZyBvcGluaW9ucyBvbiBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYWxlcnQtZGlzY3JpbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm9ibyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2h5IGRvIHlvdSBuZWVkIHRoaXMgbWVjaGFuaXNtIHRvIGRpc2NvdmVyIHRoZSByZW1vdGUg Uy1CRkQgZGlzY3JpbWluYXRvcnMsIHdoZW4geW91IGFscmVhZHkgaGF2ZSBJU0lTIGFuZCBPU1BG IGV4dGVuc2lvbnMgdG8gZGlzY292ZXIgdGhlIHJlbW90ZSBTLUJGRCB0YXJnZXRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HbGVuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMjksIDIwMTUgYXQg NDoxNiBBTSwgTm9ibyBBa2l5YSAobm9ibykgJmx0OzxhIGhyZWY9Im1haWx0bzpub2JvQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5vYm9AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPiZndDsgVG8gc3VtbWFyaXplOjxicj4NCiZndDsgLSBJIHdpbGwgc3Bhd24gb2ZmIGEgc2Vw YXJhdGUgdGhyZWFkIGZvciB0aGUgYWxlcnQgZGlzY3JpbWluYXRvciBzb29uLjxicj4NCjxicj4N CkhlbGxvIEJGRCBXRyw8YnI+DQo8YnI+DQpGaW5hbGx5IGdldHRpbmcgYXJvdW5kIHRvIGZvbGxv dyB1cCBvbiB0aGlzIEFJLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWFsZXJ0LWRpc2NyaW0vP2luY2x1 ZGVfdGV4dD0xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYWxlcnQtZGlzY3JpbS8/aW5jbHVkZV90ZXh0PTE8 L2E+PGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IGRlc2NyaWJlcyBvbmUgc2ltcGxlIGV4dGVuc2lv bjogTGV0J3MgbWFrZSBTLUJGRCBkaXNjcmltaW5hdG9yIHplcm8oMCkgdG8gaGF2ZSBhIHNwZWNp YWwgbWVhbmluZy48YnI+DQo8YnI+DQpUaGUgcHJpbWFyeSBkcml2ZXIgZm9yIHRoaXMgaXMgdG8g YWxsb3cgYW4gUy1CRkQgaW5pdGlhdG9yIHRvIGRpc2NvdmVyIHRoZSB0YXJnZXQgUy1CRkQgZGlz Y3JpbWluYXRvciwgYnkgc2VuZGluZyBhbiBTLUJGRCBwaW5nIHBhY2tldCB3aXRoIHlvdXJfZGlz Yz0wIGFuZCBnZXR0aW5nIGJhY2sgYSB2YWxpZCBTLUJGRCBwb25nIHBhY2tldCB3aXRoICZxdW90 O215X2Rpc2M9Jmx0O1MtQkZEIGRpc2NyaW1pYW50b3ImZ3Q7JnF1b3Q7LiBJbiBvdGhlciB3b3Jk cywgd2hlbiBhbg0KIFMtQkZEIHJlZmxlY3RvciByZWNlaXZlcyBhbiBTLUJGRCBwaW5nIHBhY2tl dCB3aXRoIHlvdXJfZGlzYz0wLCBpdCBwcm9jZXNzZXMgaXQgYmVjYXVzZSBTLUJGRCBkaXNjcmlt aW5hdG9yIHplcm8oMCkgaGFzIGEgc3BlY2lhbCBtZWFuaW5nLjxicj4NCjxicj4NCk1vdGl2YXRp b24gZm9yIHVzaW5nIHRoaXMgYXBwcm9hY2ggdG8gZGlzY292ZXIgdGhlIHRhcmdldCBTLUJGRCBk aXNjcmltaW5hdG9yIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMSBvZiB0aGUgZG9jdW1lbnQu PGJyPg0KPGJyPg0KSSB0aGluayBpdCBpcyBtb3N0IGltcG9ydGFudCB0byBkaXNjdXNzIHRoaXMs IHRodXMgbGV0J3MgbGVhdmUgb3V0IGRpc2N1c3Npb25zIG9uIG90aGVyIHVzZSBvZiB0aGUgUy1C RkQgYWxlcnQgZGlzY3JpbWluYXRvciAoaS5lLiwgU2VjdGlvbiAyLjIpIGZvciBub3cuPGJyPg0K PGJyPg0KUGVyc29uYWxseSwgSSB0aGluayB0aGlzIGlzIHZlcnkgdXNlZnVsIGV4dGVuc2lvbiB0 byB0aGUgUy1CRkQgbWVjaGFuaXNtIHRoYXQgd2UndmUgYmVlbiB3b3JraW5nIG9uLiBJJ20gY3Vy aW91cyB0byBzZWUgd2hhdCBvdGhlcnMgdGhpbms/PGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tTm9i bzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CECE764681BE964CBE1DFF78F3CDD39447CF8AC9xmbalnx01ciscoc_-- From nobody Tue Feb 17 17:40:39 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430581A9140 for ; Tue, 17 Feb 2015 17:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 ZdkmN4UqjqaN for ; Tue, 17 Feb 2015 17:20:56 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8B21A90E5 for ; Tue, 17 Feb 2015 17:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2097; q=dns/txt; s=iport; t=1424222456; x=1425432056; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=2x5GnXMPSMMXX3n7htywu/cmq8lKH2V79vfUXIXbJl0=; b=bS5b07u2PpmTYUCsKhl0UhncCKdWPfKbhxSv6UcpFIbieVHDaJD9csaP NEdOhI0yDjJiMKXv+H1wdo4SftKzIJBdG05ChpWWcmlzVBFPBt3Yn9rET 2Lx2GP90yFbICGHrHPaWzwVmtWcWAetswhDq2X+w1YMjx5j9u0owT8R3X 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfBQCb6ONU/5FdJa1bgwZSWgTCT4VxAoEcQwEBAQEBAXyEDgEEOj8SARwOFDERJgEEDgUIiBMDEQ3LRw2FNAEBAQEBAQQBAQEBAR2NU4FIEQEfMYMdgRQFjUyBbINXhBqCXjiLOYJGgz4ig25vAYEKOX8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="124528176" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP; 18 Feb 2015 01:20:55 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1I1KtZY005678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 01:20:55 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.130]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 19:20:55 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Very Preliminary IETF92 BFD Agenda Thread-Topic: Very Preliminary IETF92 BFD Agenda Thread-Index: AdBLGOLIKzexSzxpQQmNlJrj/gMRYg== Date: Wed, 18 Feb 2015 01:20:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.79.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Feb 2015 17:40:38 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:20:58 -0000 Hello BFDers, IETF92 is a bit over 30 days away. Jeff and I took an attempt to come up with a very preliminary agenda for IE= TF92 BFD WG session. What we need from you: - If your topic is listed, provide an ACK to Jeff and myself. - If your topic is listed with TBD as Presenter, provide a presenter name t= o Jeff and myself. - If your topic is listed with TBD as Draft, do post your document. Remembe= r the cut-off date of 2015-03-09 (Monday). - If your topic is not listed, email Jeff and myself following data: topic,= draft, presenter and how much time you need. And, as always, we encourage more on-list discussions on various BFD work t= hat are currently going on, which will pave the way for more productive tim= e at IETF92. Thanks! - Nobo & Jeff [snip] IETF 92 - BFD WG Meeting Session Agenda Date: TBD Time: TBD Place: TBD =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D CHAIR(s): Jeffrey Haas Nobo Akiya - WG Statuses and Administrivia 10 minutes Presenter: Co-chairs - BFD Yang 15 minutes Presenter: Reshad Rahman Draft: TBD - BFD Multipoint Data Plane 10 minutes Presenter: Santosh Pallagatti Draft: TBD - S-BFD Alert Discriminator 10 minutes Presenter: Nobo Akiya Draft: http://tools.ietf.org/html/draft-akiya-bfd-seamless-alert-discrim-= 03 - S-BFD VCCV 10 minutes Presenter: TBD Draft: TBD - BFD Authentication 10 minutes Presenter: Ashesh Mishra Draft: http://tools.ietf.org/html/draft-mahesh-bfd-authentication-00 - BFD Stability 10 minutes Presenter: TBD Draft: http://tools.ietf.org/html/draft-ashesh-bfd-stability-01 [Buffer: 15 minutes] [snip] From nobody Tue Feb 17 22:06:35 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20B1A90FB for ; Tue, 17 Feb 2015 22:06:33 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xdCNuk_jf8Jm for ; Tue, 17 Feb 2015 22:06:30 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757E01A902E for ; Tue, 17 Feb 2015 22:06:30 -0800 (PST) Received: from CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) by CO2PR0501MB1016.namprd05.prod.outlook.com (25.160.10.153) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 06:06:10 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 06:06:09 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0087.013; Wed, 18 Feb 2015 06:06:09 +0000 From: Santosh P K To: Ashesh Mishra , "rtg-bfd@ietf.org" Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tbsQZROSH/9kaR7CvCt+VUdZz18Bzg Date: Wed, 18 Feb 2015 06:06:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] authentication-results: outlook.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822;UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(377454003)(74316001)(77096005)(2900100001)(33656002)(2656002)(16236675004)(87936001)(66066001)(19617315012)(99286002)(92566002)(230783001)(19625215002)(50986999)(46102003)(40100003)(76176999)(54356999)(15975445007)(2950100001)(106116001)(107886001)(19300405004)(77156002)(19580395003)(19580405001)(19609705001)(102836002)(122556002)(76576001)(86362001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CO2PR0501MB8236CB53666FBF13372CD4AB32C0CO2PR0501MB823na_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2015 06:06:08.5528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB822 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB1016; X-OriginatorOrg: juniper.net Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 06:06:33 -0000 --_000_CO2PR0501MB8236CB53666FBF13372CD4AB32C0CO2PR0501MB823na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ashesh, I have few questions on this draft. 1. Why do we make an assumptions that BFD need no Auth when BFD is in= UP or not changing the state? Is that because BFD will be demuxed with onl= y discr in the packet? 2. Draft says "For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only. If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled, then the BFD session will fail to come up, because at least one end will expect every frame to be authenticated." It is not clear how does two peers negotiated? Using A bit in the BFD packe= t or through configuration? Or through IGP/BGP? 3. I am not clear what does this below statement mean? "In addition, it states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD Control packet." Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Ashesh Mishra Sent: Saturday, February 14, 2015 12:02 AM To: rtg-bfd@ietf.org Subject: New BFD Authentication Optimization draft draft-mahesh-bfd-authent= ication-00 Hi BFD Experts, The 00 version of BFD Authentication Optimization draft is now online: https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ The draft describes method for selectively authenticating certain BFD frame= s to avoid computational overhead. Thanks, Authors -- Ashesh Mishra --_000_CO2PR0501MB8236CB53666FBF13372CD4AB32C0CO2PR0501MB823na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ashesh,

    I have few questio= ns on this draft.

 

1.   = ;    Why do we make an assumptions= that BFD need no Auth when BFD is in UP or not changing the state? Is that= because BFD will be demuxed with only discr in the packet?

2.   = ;    Draft says<= /p> 

      “For exampl=
e, the two ends can decide

   that BFD frames that indicate a state change = should be authenticated

   and enable authentication on those frames onl= y.  If the two ends have

   not previously negotiated which frames they w= ill transmit or receive

   with authentication enabled, then the BFD ses= sion will fail to come

   up, because at least one end will expect ever= y frame to be

   authenticated.”

 

It is not clear how does two peers ne= gotiated? Using A bit in the BFD packet or through configuration? Or throug= h IGP/BGP?

 

3.   = ;    I am not clear what does this= below statement mean?

         &=
nbsp;          “I=
n addition, it states that an
   implementation SHOULD NOT allow the authentication state =
to be
   changed based on the receipt of a BFD Control packet.”

 

 

Thanks

Santosh P K

 

From: Rtg-bfd [mailto:rtg-bfd-bounce= s@ietf.org] On Behalf Of Ashesh Mishra
Sent: Saturday, February 14, 2015 12:02 AM
To: rtg-bfd@ietf.org
Subject: New BFD Authentication Optimization draft draft-mahesh-bfd-= authentication-00

 

Hi BFD Experts,

 

The 00 version of BFD Authentication Optimization draft is now onlin= e:

 

 

The draft describes method for selectively authenticating certain BF= D frames to avoid computational overhead. 

 

Thanks,

Authors

 

 

--

Ashesh Mishra

--_000_CO2PR0501MB8236CB53666FBF13372CD4AB32C0CO2PR0501MB823na_-- From nobo.akiya.dev@gmail.com Wed Feb 18 05:21:12 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC791A87D9; Wed, 18 Feb 2015 05:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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] autolearn=ham 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 oMvrL7jmlPQP; Wed, 18 Feb 2015 05:21:10 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 BE39C1A87EA; Wed, 18 Feb 2015 05:21:09 -0800 (PST) Received: by lbvp9 with SMTP id p9so1049763lbv.3; Wed, 18 Feb 2015 05:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Ja3qLZZFTQBPSgeNs0pHI4j1prF0KDeMqh2KScmoIVA=; b=QeE+oiZeIkkU9rzCiWJtskCdN1NN8fYRwkCRFwbejpZ72+NBS0nvCQq+U16w8p1wCj PDTVdSL9rkeUZPn1Z5iK33Bji/FDQHV49dE3yEb8E0jXSSwMpjia428G+uMIjjT6GvpR 8DKq7zfpMppaPM7xsjfClzPM5OVH+m7Pjr8QQUKVYjKaWJP+gi9kzprzqp+ywy9jY/Gh z3sSDtoWmNAlPsY2jtQIoBlTizd9CtAgh43B/93A/qfpCAVV6AuobcxQu5xwJIqYdOt3 /ljTn9V9UtUdwp9ao08bFjzycrv0poefs08mCwn/xxqzePXT1iIxhD0ast0K+VcfXj7h muBQ== MIME-Version: 1.0 X-Received: by 10.112.63.165 with SMTP id h5mr17504524lbs.16.1424265668044; Wed, 18 Feb 2015 05:21:08 -0800 (PST) Received: by 10.112.164.65 with HTTP; Wed, 18 Feb 2015 05:21:07 -0800 (PST) Date: Wed, 18 Feb 2015 08:21:07 -0500 Message-ID: Subject: RE: [mpls] Question on draft-mirsky-mpls-bfd-directed From: Nobo Akiya To: Loa Andersson , mpls@ietf.org, draft-mirsky-mpls-bfd-directed@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c3fd94362685050f5cb18e Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 23:46:41 -0000 --001a11c3fd94362685050f5cb18e Content-Type: text/plain; charset=UTF-8 + BFD WG Hi Loa, > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org ] On Behalf Of Loa Andersson > Sent: Monday, February 16, 2015 3:55 AM > To: mpls@ietf.org; draft-mirsky-mpls-bfd-directed@tools.ietf.org > Subject: [mpls] Question on draft-mirsky-mpls-bfd-directed > > Authors, Working Group, > > I started to review draft-mirsky-mpls-bfd-directed, but got stuck on the > problem statement. > > If I understand you correctly, but I admit that I may have misunderstood, > you are saying that the scope of the document are uni- directional explicit > routed LSPs. A typical example would be MPLS-TE LSPs, right? That's not incorrect :) AFAIK, technically correct scope is all BFD session types that are bootstrapped with LSP Ping, with uni-directional traffic engineered paths on SPRING based networks being the primary use case. > > You also say that for such an LSPs the egress would use the shortest path for > its control message, while the ingress will send control messages in-band. > > Now in Asynchronous mode the BFD session will form a loop ingress - > egress - ingress, where ingress to egress is on the the monitored LSP, while > egress to ingress is out-of-band, right? > > You say that since the egress to ingress control message will follow the > shortest path, which might not be co-routed with the ingress to egress LSP, > missing responses can't be taken as an indication of that the uni- directional > LSP needs to be re-routed. > > While I agree with that statement, I don't see that if you give the egress an > explicit return/reverse path that is co-routed with the monitored LSP you > are really in a better shape to draw any conclusions. > Failure to receive egress to ingress control messages does not necessarily > tell you anything about the state of the monitored LSP. You are absolutely right. The egress-to-ingress BFD session not being co-routed is a motivation for this document, but what the proposed mechanism is providing is an ability to bootstrap egress-to-ingress BFD session to take a specific path. Whether such egress-to-ingress sessions are co-routed or otherwise is a choice left to users, and is outside the scope of this document. With SPRING based network, user choosing the co-routed egress-to-ingress path is doable (i.e., it is possible for an element computing the forward stack to compute the reverse stack), but, again, that's outside the scope of this document. I believe you have pointed out this these aspects are slightly confusing/misleading and need to be clarified in the document, and I agree with that. Additionally, I believe the premise is that it's better to take down the uni-directional path based on the failure of user specified egress-to-ingress path instead of an arbitrary egress-to-ingress path. If the egress-to-ingress path can always be guaranteed [automatically] to be co-routed in all cases, then that may be superior. However, I do think what this document is describing is a reasonable improvement over what we have today. Thanks! -Nobo > > /Loa > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --001a11c3fd94362685050f5cb18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+ BFD WG

Hi Loa,

=C2=A0

> -----Original Message-----

> From: mpls [mailto:mpls-bounc= es@ietf.org] On Behalf Of Loa Andersson

> Sent: Monday, February 16, 2015 3:55 AM

> To: mpls@ietf.org; draft-mirsky-mpls-bfd-dire= cted@tools.ietf.org

> Subject: [mpls] Question on draft-mirsky-mpls-bfd-directed

>

> Authors, Working Group,

>

> I started to review draft-mirsky-mpls-bfd-directed, but got stuck on the

> problem statement.

>

> If I understand you correctly, but I admit that I may have misunderstood,

> you are saying that the scope of the document are uni- directional explicit

> routed LSPs. A typical example would be MPLS-TE LSPs, right?

=C2=A0

That's not incorrect :)

=C2=A0

AFAIK, technically correct scope is all BFD session types that are bootstrapped with LSP Ping, with uni-directional traffic engineere= d paths on SPRING based networks being the primary use case.

=C2=A0

>

> You also say that for such an LSPs the egress would use the shortest path for

> its control message, while the ingress will send control messages in-band.

>

> Now in Asynchronous mode the BFD session will form a loop ingress -

> egress - ingress, where ingress to egress is on the the monitored LSP, while

> egress to ingress is out-of-band, right?

>

> You say that since the egress to ingress control message will follow the

> shortest path, which might not be co-routed with the ingress to egress LSP,

> missing responses can't be taken as an indication = of that the uni- directional

> LSP needs to be re-routed.

>

> While I agree with that statement, I don't see tha= t if you give the egress an

> explicit return/reverse path that is co-routed with the monitored LSP you

> are really in a better shape to draw any conclusions.

> Failure to receive egress to ingress control messages does not necessarily

> tell you anything about the state of the monitored LSP.

=C2=A0

You are absolutely right. The egress-to-ingress BFD session not being co-routed is a motivation for this document, but what the proposed mechanism is providing is an ability to bootstrap egress-to-ingres= s BFD session to take a specific path. Whether such egress-to-ingress session= s are co-routed or otherwise is a choice left to users, and is outside the sc= ope of this document. With SPRING based network, user choosing the co-routed egress-to-ingress path is doable (i.e., it is possible for an element compu= ting the forward stack to compute the reverse stack), but, again, that's out= side the scope of this document. I believe you have pointed out this these aspects a= re slightly confusing/misleading and need to be clarified in the document, and= I agree with that.

=C2=A0

Additionally, I believe the premise is that it's better to take down the uni-directional path based on the failure of user specifie= d egress-to-ingress path instead of an arbitrary egress-to-ingress path. If t= he egress-to-ingress path can always be guaranteed [automatically] to be co-ro= uted in all cases, then that may be superior. However, I do think what this docu= ment is describing is a reasonable improvement over what we have today.

=C2=A0

Thanks!

=C2=A0

-Nobo

=C2=A0

>

> /Loa

> --

>

>

> Loa Andersson=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 email: <= a href=3D"mailto:loa@mail01.huawei.com">loa@mail01.huawei.com

> Senior MPLS Expert=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 loa@pi.nu

> Huawei Technologies (consultant)<= font color=3D"#000000" size=3D"3">=C2=A0=C2=A0=C2=A0=C2=A0 phone: +46 739 81 21 64

<= font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

>

> _______________________________________________=

> mpls mailing list

> mpls@ietf.org

> https://www.iet= f.org/mailman/listinfo/mpls

--001a11c3fd94362685050f5cb18e-- From nobody Wed Feb 18 17:01:25 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E321A1BF8 for ; Wed, 18 Feb 2015 17:01:23 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Dt27Kig8cLC7 for ; Wed, 18 Feb 2015 17:01:22 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 09C991A1BF4 for ; Wed, 18 Feb 2015 17:01:22 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wo20so9141078obc.7 for ; Wed, 18 Feb 2015 17:01:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ONj+1i4xtV03w6dt17qiHF/v2WRnvVj9t8vkoE0K5s=; b=RZfQWO/hP+Nqd9suJ7/gBK4he6PwZXykBiYpKLOh4rvGriQiYJ+FAqMGRecThcsJ2Q 9ZOjI8iL+fSa2oz6PcL0kWqYmr5j17ycd99Lz3YQOQWZcgxkI51kCJ18ld+Cxi4g3VOP 1Oo2mELCfHlUz91rAjuFYP0YiNE58tdxGuUC1epQKeFuDOLFEONxzvAIp8cL1rvZ+5ZP yLEupxd2MylY9w4/tMEGQq3xLrriqgJwLXiFTG8jsbPxuAcOP+2w9i/6z/5b06DzlSVX pEWFqdOdwqXsLxc077xe0O2UOESUKTeIbZZMNs7YjiwzlCqs2A8JdnZfQ2Uvd1ZTfEYX MGWQ== MIME-Version: 1.0 X-Received: by 10.182.241.38 with SMTP id wf6mr1298135obc.81.1424307681348; Wed, 18 Feb 2015 17:01:21 -0800 (PST) Received: by 10.76.112.136 with HTTP; Wed, 18 Feb 2015 17:01:21 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 06:31:21 +0530 Message-ID: Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Manav Bhatia To: Santosh P K Content-Type: multipart/alternative; boundary=001a11c30f8065f7d7050f6679b1 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 01:01:24 -0000 --001a11c30f8065f7d7050f6679b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Santosh, Thanks for the review. Comments inline. On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K wrote= : > Hello Ashesh, > > I have few questions on this draft. > > > > 1. Why do we make an assumptions that BFD need no Auth when BFD is > in UP or not changing the state? Is that because BFD will be demuxed with > only discr in the packet? > Yes. > 2. Draft says > > =E2=80=9CFor example, the two ends can decide > > that BFD frames that indicate a state change should be authenticated > > and enable authentication on those frames only. If the two ends have > > not previously negotiated which frames they will transmit or receive > > with authentication enabled, then the BFD session will fail to come > > up, because at least one end will expect every frame to be > > authenticated.=E2=80=9D > > > > It is not clear how does two peers negotiated? Using A bit in the BFD > packet or through configuration? Or through IGP/BGP? > We had intentionally left this unspecified as this is orthogonal to the issue that the draft addresses. This feature can be trivially negotiated by using a new auth TLV type. However, the larger issue is whether the community is comfortable with the core idea that is being proposed here -- on only using authenticated BFD packets when there is a state change. 3. I am not clear what does this below statement mean? > > =E2=80=9CIn addition, it states that an > > implementation SHOULD NOT allow the authentication state to be > > changed based on the receipt of a BFD Control packet.=E2=80=9D > > > .. and neither am I. I'll wait for Ashesh to clarify this. Cheers, Manav --001a11c30f8065f7d7050f6679b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Santosh,

Thank= s for the review. Comments inline.

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <= santoshpk@juniper.net> wrote:

Hello Ashesh,

=C2=A0=C2=A0=C2=A0 I have few questio= ns on this draft.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why do we make an assumptions th= at BFD need no Auth when BFD is in UP or not changing the state? Is that be= cause BFD will be demuxed with only discr in the packet?


Yes.=
=C2=A0

=

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Draft says<= /p> 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CFor exam=
ple, the two ends can decide

=C2=A0=C2=A0 that BFD frames that indicate a state change = should be authenticated

=C2=A0=C2=A0 and enable authentication on those frames onl= y.=C2=A0 If the two ends have

=C2=A0=C2=A0 not previously negotiated which frames they w= ill transmit or receive

=C2=A0=C2=A0 with authentication enabled, then the BFD ses= sion will fail to come

=C2=A0=C2=A0 up, because at least one end will expect ever= y frame to be

=C2=A0=C2=A0 authenticated.=E2=80=9D=

=C2=A0

It is not clear how does two peers ne= gotiated? Using A bit in the BFD packet or through configuration? Or throug= h IGP/BGP?


We had in= tentionally left this unspecified as this is orthogonal to the issue that t= he draft addresses. This feature can be trivially negotiated by using a new= auth TLV type. However, the larger issue is whether the community is comfo= rtable with the core idea that is being proposed here -- on only using auth= enticated BFD packets when there is a state change.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am not clear what does this be= low statement mean?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CIn addition, it states that an
=C2=A0=C2=A0 implementation SHOULD NOT allow the authentication state =
to be
=C2=A0=C2=A0 changed based on the receipt of a BFD Control packet.=E2=80=9D

=C2=A0

<= /blockquote>

.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheer= s, Manav
--001a11c30f8065f7d7050f6679b1-- From nobody Wed Feb 18 18:53:03 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1431A6F03; Wed, 18 Feb 2015 18:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 beK3qFfxrqIx; Wed, 18 Feb 2015 18:52:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76D01A1B56; Wed, 18 Feb 2015 18:52:56 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-cb-54e4fc0453a5 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 03.4C.03307.40CF4E45; Wed, 18 Feb 2015 21:54:28 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Wed, 18 Feb 2015 21:52:54 -0500 From: Gregory Mirsky To: Nobo Akiya , Loa Andersson , "mpls@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" Subject: RE: [mpls] Question on draft-mirsky-mpls-bfd-directed Thread-Topic: [mpls] Question on draft-mirsky-mpls-bfd-directed Thread-Index: AQHQS33LS+erNgAZ2EqZdI4agf/AvZz3RR7A Date: Thu, 19 Feb 2015 02:52:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91103A@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91103Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXRPlC7LnychBl/mWls8XNzDbvFv7hxm i1tLV7JaPDn3jsXi859tjA6sHjtn3WX3WLLkJ5PHrOltbB5fLn9mC2CJ4rJJSc3JLEst0rdL 4MqYuHwfa8GKP4wVC559Z2tgvPGVsYuRk0NCwETi7OQ2KFtM4sK99WwgtpDAEUaJTztCIezl jBK3lvqB2GwCRhIvNvawdzFycYgInGGUePZoMTtIgllAU6LpxGcwW1jATmL/lUNgQ0UE7CVm T13IDmEbSXye8RksziKgKjF7WxvYMl4BX4nVx5rYIZYFSHzeuY61i5GDg1MgUKL7CzNImBHo tu+n1jBBrBKXuPVkPhPEzQISS/acZ4awRSVePv7HCmErSuzrnw51Wr7Ep7O/WSBWCUqcnPmE ZQKj6Cwko2YhKZuFpGwW0BUgn63fpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjBylxalluelG BpsYgXF4TIJNdwfjnpeWhxgFOBiVeHg/HH8cIsSaWFZcmXuIUZqDRUmcd9GDgyFCAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGE2u+ZjpbFrx9/G6P+ns7X78RZsFuEO/6ixn8AtvnXji0VZ3 pcZqV5GYBt8FQjscN/VHLwxa3btp0tecD89bp3b6SKtqf/ow77bInCNSay2VYl+pnVE16BJT kxIvPG72mStueYLAp9OCCleuqy1aXFEU0LeoplBsY/C29jvrTjemWfWs3zo3Q4mlOCPRUIu5 qDgRAOb736WkAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 02:53:00 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91103Aeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9hLCBOb2JvLCBldC4gYWwsDQptYW55IHRoYW5rcyBmb3IgdmVyeSB0aG9yb3VnaCByZXZp ZXcgYW5kIGdyZWF0IGRpc2N1c3Npb24uIE5vYm8gcG9pbnRlZCB0aGF0IGludmVzdGlnYXRpb24g b2YgQkZEIGluIFNlZ21lbnQgUm91dGluZyBuZXR3b3JrLCBib3RoIHdpdGggTVBMUyBhbmQgSVB2 NiBkYXRhIHBsYW5lLCB3YXMgdGhlIG1haW4gbW90aXZhdG9yIGZvciB0aGlzIHByb3Bvc2FsLg0K SSBhZ3JlZSB0aGF0IHRoZSBkb2N1bWVudCBuZWVkcyBpbXByb3ZlbWVudHMgaW4gbnVtYmVyIG9m IHBsYWNlcyBhbmQgZ3JlYXRseSBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zLiBIZW5jZSB0aGUgcXVlc3Rpb24sIHdvdWxkIOKAnGluZ3Jlc3PigJ0v4oCdZWdyZXNz4oCd IGJlIG1vcmUgaW50dWl0aXZlIHRoYW4g4oCcbmVhci1lbmTigJ0v4oCdZmFyLWVuZOKAnT8NCg0K DQogICAgICAgICAgICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZw0KDQpGcm9tOiBOb2JvIEFraXlhIFttYWlsdG86bm9iby5ha2l5YS5kZXZAZ21haWwu Y29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNSA1OjIxIEFNDQpUbzogTG9h IEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzsgZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVk QHRvb2xzLmlldGYub3JnDQpDYzogcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFttcGxz XSBRdWVzdGlvbiBvbiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQNCg0KKyBCRkQgV0cN Cg0KSGkgTG9hLA0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206 IG1wbHMgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb2EgQW5k ZXJzc29uDQoNCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAxNiwgMjAxNSAzOjU1IEFNDQoNCj4g VG86IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBkcmFmdC1taXJza3ktbXBs cy1iZmQtZGlyZWN0ZWRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LW1pcnNreS1tcGxzLWJm ZC1kaXJlY3RlZEB0b29scy5pZXRmLm9yZz4NCg0KPiBTdWJqZWN0OiBbbXBsc10gUXVlc3Rpb24g b24gZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkDQoNCj4NCg0KPiBBdXRob3JzLCBXb3Jr aW5nIEdyb3VwLA0KDQo+DQoNCj4gSSBzdGFydGVkIHRvIHJldmlldyBkcmFmdC1taXJza3ktbXBs cy1iZmQtZGlyZWN0ZWQsIGJ1dCBnb3Qgc3R1Y2sgb24gdGhlDQoNCj4gcHJvYmxlbSBzdGF0ZW1l bnQuDQoNCj4NCg0KPiBJZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwgYnV0IEkgYWRtaXQg dGhhdCBJIG1heSBoYXZlIG1pc3VuZGVyc3Rvb2QsDQoNCj4geW91IGFyZSBzYXlpbmcgdGhhdCB0 aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGFyZSB1bmktIGRpcmVjdGlvbmFsIGV4cGxpY2l0DQoN Cj4gcm91dGVkIExTUHMuIEEgdHlwaWNhbCBleGFtcGxlIHdvdWxkIGJlIE1QTFMtVEUgTFNQcywg cmlnaHQ/DQoNCg0KDQpUaGF0J3Mgbm90IGluY29ycmVjdCA6KQ0KDQoNCg0KQUZBSUssIHRlY2hu aWNhbGx5IGNvcnJlY3Qgc2NvcGUgaXMgYWxsIEJGRCBzZXNzaW9uIHR5cGVzIHRoYXQgYXJlIGJv b3RzdHJhcHBlZCB3aXRoIExTUCBQaW5nLCB3aXRoIHVuaS1kaXJlY3Rpb25hbCB0cmFmZmljIGVu Z2luZWVyZWQgcGF0aHMgb24gU1BSSU5HIGJhc2VkIG5ldHdvcmtzIGJlaW5nIHRoZSBwcmltYXJ5 IHVzZSBjYXNlLg0KDQoNCg0KPg0KDQo+IFlvdSBhbHNvIHNheSB0aGF0IGZvciBzdWNoIGFuIExT UHMgdGhlIGVncmVzcyB3b3VsZCB1c2UgdGhlIHNob3J0ZXN0IHBhdGggZm9yDQoNCj4gaXRzIGNv bnRyb2wgbWVzc2FnZSwgd2hpbGUgdGhlIGluZ3Jlc3Mgd2lsbCBzZW5kIGNvbnRyb2wgbWVzc2Fn ZXMgaW4tYmFuZC4NCg0KPg0KDQo+IE5vdyBpbiBBc3luY2hyb25vdXMgbW9kZSB0aGUgQkZEIHNl c3Npb24gd2lsbCBmb3JtIGEgbG9vcCBpbmdyZXNzIC0NCg0KPiBlZ3Jlc3MgLSBpbmdyZXNzLCB3 aGVyZSBpbmdyZXNzIHRvIGVncmVzcyBpcyBvbiB0aGUgdGhlIG1vbml0b3JlZCBMU1AsIHdoaWxl DQoNCj4gZWdyZXNzIHRvIGluZ3Jlc3MgaXMgb3V0LW9mLWJhbmQsIHJpZ2h0Pw0KDQo+DQoNCj4g WW91IHNheSB0aGF0IHNpbmNlIHRoZSBlZ3Jlc3MgdG8gaW5ncmVzcyBjb250cm9sIG1lc3NhZ2Ug d2lsbCBmb2xsb3cgdGhlDQoNCj4gc2hvcnRlc3QgcGF0aCwgd2hpY2ggbWlnaHQgbm90IGJlIGNv LXJvdXRlZCB3aXRoIHRoZSBpbmdyZXNzIHRvIGVncmVzcyBMU1AsDQoNCj4gbWlzc2luZyByZXNw b25zZXMgY2FuJ3QgYmUgdGFrZW4gYXMgYW4gaW5kaWNhdGlvbiBvZiB0aGF0IHRoZSB1bmktIGRp cmVjdGlvbmFsDQoNCj4gTFNQIG5lZWRzIHRvIGJlIHJlLXJvdXRlZC4NCg0KPg0KDQo+IFdoaWxl IEkgYWdyZWUgd2l0aCB0aGF0IHN0YXRlbWVudCwgSSBkb24ndCBzZWUgdGhhdCBpZiB5b3UgZ2l2 ZSB0aGUgZWdyZXNzIGFuDQoNCj4gZXhwbGljaXQgcmV0dXJuL3JldmVyc2UgcGF0aCB0aGF0IGlz IGNvLXJvdXRlZCB3aXRoIHRoZSBtb25pdG9yZWQgTFNQIHlvdQ0KDQo+IGFyZSByZWFsbHkgaW4g YSBiZXR0ZXIgc2hhcGUgdG8gZHJhdyBhbnkgY29uY2x1c2lvbnMuDQoNCj4gRmFpbHVyZSB0byBy ZWNlaXZlIGVncmVzcyB0byBpbmdyZXNzIGNvbnRyb2wgbWVzc2FnZXMgZG9lcyBub3QgbmVjZXNz YXJpbHkNCg0KPiB0ZWxsIHlvdSBhbnl0aGluZyBhYm91dCB0aGUgc3RhdGUgb2YgdGhlIG1vbml0 b3JlZCBMU1AuDQoNCg0KDQpZb3UgYXJlIGFic29sdXRlbHkgcmlnaHQuIFRoZSBlZ3Jlc3MtdG8t aW5ncmVzcyBCRkQgc2Vzc2lvbiBub3QgYmVpbmcgY28tcm91dGVkIGlzIGEgbW90aXZhdGlvbiBm b3IgdGhpcyBkb2N1bWVudCwgYnV0IHdoYXQgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBpcyBwcm92 aWRpbmcgaXMgYW4gYWJpbGl0eSB0byBib290c3RyYXAgZWdyZXNzLXRvLWluZ3Jlc3MgQkZEIHNl c3Npb24gdG8gdGFrZSBhIHNwZWNpZmljIHBhdGguIFdoZXRoZXIgc3VjaCBlZ3Jlc3MtdG8taW5n cmVzcyBzZXNzaW9ucyBhcmUgY28tcm91dGVkIG9yIG90aGVyd2lzZSBpcyBhIGNob2ljZSBsZWZ0 IHRvIHVzZXJzLCBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gV2l0 aCBTUFJJTkcgYmFzZWQgbmV0d29yaywgdXNlciBjaG9vc2luZyB0aGUgY28tcm91dGVkIGVncmVz cy10by1pbmdyZXNzIHBhdGggaXMgZG9hYmxlIChpLmUuLCBpdCBpcyBwb3NzaWJsZSBmb3IgYW4g ZWxlbWVudCBjb21wdXRpbmcgdGhlIGZvcndhcmQgc3RhY2sgdG8gY29tcHV0ZSB0aGUgcmV2ZXJz ZSBzdGFjayksIGJ1dCwgYWdhaW4sIHRoYXQncyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50LiBJIGJlbGlldmUgeW91IGhhdmUgcG9pbnRlZCBvdXQgdGhpcyB0aGVzZSBhc3BlY3Rz IGFyZSBzbGlnaHRseSBjb25mdXNpbmcvbWlzbGVhZGluZyBhbmQgbmVlZCB0byBiZSBjbGFyaWZp ZWQgaW4gdGhlIGRvY3VtZW50LCBhbmQgSSBhZ3JlZSB3aXRoIHRoYXQuDQoNCg0KDQpBZGRpdGlv bmFsbHksIEkgYmVsaWV2ZSB0aGUgcHJlbWlzZSBpcyB0aGF0IGl0J3MgYmV0dGVyIHRvIHRha2Ug ZG93biB0aGUgdW5pLWRpcmVjdGlvbmFsIHBhdGggYmFzZWQgb24gdGhlIGZhaWx1cmUgb2YgdXNl ciBzcGVjaWZpZWQgZWdyZXNzLXRvLWluZ3Jlc3MgcGF0aCBpbnN0ZWFkIG9mIGFuIGFyYml0cmFy eSBlZ3Jlc3MtdG8taW5ncmVzcyBwYXRoLiBJZiB0aGUgZWdyZXNzLXRvLWluZ3Jlc3MgcGF0aCBj YW4gYWx3YXlzIGJlIGd1YXJhbnRlZWQgW2F1dG9tYXRpY2FsbHldIHRvIGJlIGNvLXJvdXRlZCBp biBhbGwgY2FzZXMsIHRoZW4gdGhhdCBtYXkgYmUgc3VwZXJpb3IuIEhvd2V2ZXIsIEkgZG8gdGhp bmsgd2hhdCB0aGlzIGRvY3VtZW50IGlzIGRlc2NyaWJpbmcgaXMgYSByZWFzb25hYmxlIGltcHJv dmVtZW50IG92ZXIgd2hhdCB3ZSBoYXZlIHRvZGF5Lg0KDQoNCg0KVGhhbmtzIQ0KDQoNCg0KLU5v Ym8NCg0KDQoNCj4NCg0KPiAvTG9hDQoNCj4gLS0NCg0KPg0KDQo+DQoNCj4gTG9hIEFuZGVyc3Nv biAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb208bWFp bHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbT4NCg0KPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAg ICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KDQo+IEh1YXdl aSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0K DQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KPiBtcGxzIG1haWxpbmcgbGlzdA0KDQo+IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= --_000_7347100B5761DC41A166AC17F22DF1121B91103Aeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIExvYSwgTm9ibywgZXQuIGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5tYW55IHRoYW5rcyBmb3IgdmVyeSB0aG9yb3VnaCByZXZpZXcgYW5kIGdyZWF0IGRp c2N1c3Npb24uIE5vYm8gcG9pbnRlZCB0aGF0IGludmVzdGlnYXRpb24gb2YgQkZEIGluIFNlZ21l bnQgUm91dGluZyBuZXR3b3JrLCBib3RoIHdpdGggTVBMUyBhbmQgSVB2NiBkYXRhIHBsYW5lLA0K IHdhcyB0aGUgbWFpbiBtb3RpdmF0b3IgZm9yIHRoaXMgcHJvcG9zYWwuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgZG9jdW1lbnQgbmVlZHMgaW1wcm92ZW1l bnRzIGluIG51bWJlciBvZiBwbGFjZXMgYW5kIGdyZWF0bHkgYXBwcmVjaWF0ZSB5b3VyIGNvbW1l bnRzIGFuZCBzdWdnZXN0aW9ucy4gSGVuY2UgdGhlIHF1ZXN0aW9uLCB3b3VsZCDigJxpbmdyZXNz 4oCdL+KAnWVncmVzc+KAnQ0KIGJlIG1vcmUgaW50dWl0aXZlIHRoYW4g4oCcbmVhci1lbmTigJ0v 4oCdZmFyLWVuZOKAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5vYm8gQWtpeWEgW21haWx0bzpub2JvLmFraXlh LmRldkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAx OCwgMjAxNSA1OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBMb2EgQW5kZXJzc29uOyBtcGxzQGlldGYu b3JnOyBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWRAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFttcGxz XSBRdWVzdGlvbiBvbiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ JiM0MzsgQkZEIFdHPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBMb2EsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBGcm9tOiBtcGxzIFs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOm1wbHMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFpbHRvOm1wbHMt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+XQ0KIE9u IEJlaGFsZiBPZiBMb2EgQW5kZXJzc29uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mZ3Q7IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTYsIDIwMTUgMzo1NSBBTTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBUbzoNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 bXBsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bXBsc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkcmFmdC1taXJza3kt bXBscy1iZmQtZGlyZWN0ZWRAdG9vbHMuaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LW1pcnNr eS1tcGxzLWJmZC1kaXJlY3RlZEB0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZndDsgU3ViamVjdDogW21wbHNdIFF1ZXN0aW9uIG9uIGRyYWZ0LW1p cnNreS1tcGxzLWJmZC1kaXJlY3RlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jmd0Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IEF1dGhvcnMsIFdv cmtpbmcgR3JvdXAsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgSSBzdGFydGVkIHRvIHJldmlldyBk cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQsIGJ1dCBnb3Qgc3R1Y2sgb24gdGhlPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IHByb2JsZW0gc3RhdGVtZW50Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7IElmIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5LCBidXQgSSBh ZG1pdCB0aGF0IEkgbWF5IGhhdmUgbWlzdW5kZXJzdG9vZCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZndDsgeW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgc2NvcGUgb2YgdGhlIGRv Y3VtZW50IGFyZSB1bmktIGRpcmVjdGlvbmFsIGV4cGxpY2l0PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mZ3Q7IHJvdXRlZCBMU1BzLiBBIHR5cGljYWwgZXhhbXBsZSB3b3VsZCBi ZSBNUExTLVRFIExTUHMsIHJpZ2h0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0J3Mgbm90IGluY29y cmVjdCA6KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BRkFJSywgdGVjaG5pY2FsbHkgY29ycmVjdCBzY29w ZSBpcyBhbGwgQkZEIHNlc3Npb24gdHlwZXMgdGhhdCBhcmUgYm9vdHN0cmFwcGVkIHdpdGggTFNQ IFBpbmcsIHdpdGggdW5pLWRpcmVjdGlvbmFsIHRyYWZmaWMgZW5naW5lZXJlZCBwYXRocyBvbiBT UFJJTkcgYmFzZWQNCiBuZXR3b3JrcyBiZWluZyB0aGUgcHJpbWFyeSB1c2UgY2FzZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7 IFlvdSBhbHNvIHNheSB0aGF0IGZvciBzdWNoIGFuIExTUHMgdGhlIGVncmVzcyB3b3VsZCB1c2Ug dGhlIHNob3J0ZXN0IHBhdGggZm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m Z3Q7IGl0cyBjb250cm9sIG1lc3NhZ2UsIHdoaWxlIHRoZSBpbmdyZXNzIHdpbGwgc2VuZCBjb250 cm9sIG1lc3NhZ2VzIGluLWJhbmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m Z3Q7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgTm93IGluIEFzeW5j aHJvbm91cyBtb2RlIHRoZSBCRkQgc2Vzc2lvbiB3aWxsIGZvcm0gYSBsb29wIGluZ3Jlc3MgLTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBlZ3Jlc3MgLSBpbmdyZXNzLCB3 aGVyZSBpbmdyZXNzIHRvIGVncmVzcyBpcyBvbiB0aGUgdGhlIG1vbml0b3JlZCBMU1AsIHdoaWxl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IGVncmVzcyB0byBpbmdyZXNz IGlzIG91dC1vZi1iYW5kLCByaWdodD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBZb3Ugc2F5IHRo YXQgc2luY2UgdGhlIGVncmVzcyB0byBpbmdyZXNzIGNvbnRyb2wgbWVzc2FnZSB3aWxsIGZvbGxv dyB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgc2hvcnRlc3QgcGF0 aCwgd2hpY2ggbWlnaHQgbm90IGJlIGNvLXJvdXRlZCB3aXRoIHRoZSBpbmdyZXNzIHRvIGVncmVz cyBMU1AsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IG1pc3NpbmcgcmVz cG9uc2VzIGNhbid0IGJlIHRha2VuIGFzIGFuIGluZGljYXRpb24gb2YgdGhhdCB0aGUgdW5pLSBk aXJlY3Rpb25hbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBMU1AgbmVl ZHMgdG8gYmUgcmUtcm91dGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0 Ow0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IFdoaWxlIEkgYWdyZWUg d2l0aCB0aGF0IHN0YXRlbWVudCwgSSBkb24ndCBzZWUgdGhhdCBpZiB5b3UgZ2l2ZSB0aGUgZWdy ZXNzIGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7IGV4cGxpY2l0IHJl dHVybi9yZXZlcnNlIHBhdGggdGhhdCBpcyBjby1yb3V0ZWQgd2l0aCB0aGUgbW9uaXRvcmVkIExT UCB5b3U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsgYXJlIHJlYWxseSBp biBhIGJldHRlciBzaGFwZSB0byBkcmF3IGFueSBjb25jbHVzaW9ucy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZndDsgRmFpbHVyZSB0byByZWNlaXZlIGVncmVzcyB0byBpbmdy ZXNzIGNvbnRyb2wgbWVzc2FnZXMgZG9lcyBub3QgbmVjZXNzYXJpbHk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPiZndDsgdGVsbCB5b3UgYW55dGhpbmcgYWJvdXQgdGhlIHN0YXRl IG9mIHRoZSBtb25pdG9yZWQgTFNQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Zb3UgYXJlIGFic29sdXRl bHkgcmlnaHQuIFRoZSBlZ3Jlc3MtdG8taW5ncmVzcyBCRkQgc2Vzc2lvbiBub3QgYmVpbmcgY28t cm91dGVkIGlzIGEgbW90aXZhdGlvbiBmb3IgdGhpcyBkb2N1bWVudCwgYnV0IHdoYXQgdGhlIHBy b3Bvc2VkIG1lY2hhbmlzbSBpcyBwcm92aWRpbmcNCiBpcyBhbiBhYmlsaXR5IHRvIGJvb3RzdHJh cCBlZ3Jlc3MtdG8taW5ncmVzcyBCRkQgc2Vzc2lvbiB0byB0YWtlIGEgc3BlY2lmaWMgcGF0aC4g V2hldGhlciBzdWNoIGVncmVzcy10by1pbmdyZXNzIHNlc3Npb25zIGFyZSBjby1yb3V0ZWQgb3Ig b3RoZXJ3aXNlIGlzIGEgY2hvaWNlIGxlZnQgdG8gdXNlcnMsIGFuZCBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIGRvY3VtZW50LiBXaXRoIFNQUklORyBiYXNlZCBuZXR3b3JrLCB1c2VyIGNo b29zaW5nDQogdGhlIGNvLXJvdXRlZCBlZ3Jlc3MtdG8taW5ncmVzcyBwYXRoIGlzIGRvYWJsZSAo aS5lLiwgaXQgaXMgcG9zc2libGUgZm9yIGFuIGVsZW1lbnQgY29tcHV0aW5nIHRoZSBmb3J3YXJk IHN0YWNrIHRvIGNvbXB1dGUgdGhlIHJldmVyc2Ugc3RhY2spLCBidXQsIGFnYWluLCB0aGF0J3Mg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gSSBiZWxpZXZlIHlvdSBoYXZlIHBv aW50ZWQgb3V0IHRoaXMgdGhlc2UgYXNwZWN0cyBhcmUgc2xpZ2h0bHkNCiBjb25mdXNpbmcvbWlz bGVhZGluZyBhbmQgbmVlZCB0byBiZSBjbGFyaWZpZWQgaW4gdGhlIGRvY3VtZW50LCBhbmQgSSBh Z3JlZSB3aXRoIHRoYXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFkZGl0aW9uYWxseSwgSSBiZWxpZXZl IHRoZSBwcmVtaXNlIGlzIHRoYXQgaXQncyBiZXR0ZXIgdG8gdGFrZSBkb3duIHRoZSB1bmktZGly ZWN0aW9uYWwgcGF0aCBiYXNlZCBvbiB0aGUgZmFpbHVyZSBvZiB1c2VyIHNwZWNpZmllZCBlZ3Jl c3MtdG8taW5ncmVzcyBwYXRoDQogaW5zdGVhZCBvZiBhbiBhcmJpdHJhcnkgZWdyZXNzLXRvLWlu Z3Jlc3MgcGF0aC4gSWYgdGhlIGVncmVzcy10by1pbmdyZXNzIHBhdGggY2FuIGFsd2F5cyBiZSBn dWFyYW50ZWVkIFthdXRvbWF0aWNhbGx5XSB0byBiZSBjby1yb3V0ZWQgaW4gYWxsIGNhc2VzLCB0 aGVuIHRoYXQgbWF5IGJlIHN1cGVyaW9yLiBIb3dldmVyLCBJIGRvIHRoaW5rIHdoYXQgdGhpcyBk b2N1bWVudCBpcyBkZXNjcmliaW5nIGlzIGEgcmVhc29uYWJsZSBpbXByb3ZlbWVudA0KIG92ZXIg d2hhdCB3ZSBoYXZlIHRvZGF5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPi1Ob2JvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+Jmd0OyAvTG9hPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mZ3Q7IC0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jmd0OyBMb2EgQW5kZXJzc29uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVt YWlsOg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmxvYUBtYWlsMDEuaHVhd2VpLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZndDsgU2VuaW9yIE1QTFMgRXhwZXJ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+bG9hQHBpLm51PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBI dWF3ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw aG9uZTogJiM0Mzs0NiA3MzkgODEgMjEgNjQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jmd0OyBtcGxzIG1haWxpbmcgbGlzdDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5tcGxzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jmd0Ow0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91103Aeusaamb103erics_-- From nobody Wed Feb 18 20:34:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46511A01D5; Wed, 18 Feb 2015 20:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XfOCxiEVYIGM; Wed, 18 Feb 2015 20:34:00 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3F81A86DD; Wed, 18 Feb 2015 20:33:59 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.205.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 660D61801587; Thu, 19 Feb 2015 05:33:55 +0100 (CET) Message-ID: <54E567AE.10002@pi.nu> Date: Thu, 19 Feb 2015 12:33:50 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gregory Mirsky , Nobo Akiya , "mpls@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" Subject: Re: [mpls] Question on draft-mirsky-mpls-bfd-directed References: <7347100B5761DC41A166AC17F22DF1121B91103A@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91103A@eusaamb103.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 04:34:04 -0000 Greg and Nobo, On 2015-02-19 10:52, Gregory Mirsky wrote: > Hi Loa, Nobo, et. al, > > many thanks for very thorough review and great discussion. Nobo pointed > that investigation of BFD in Segment Routing network, both with MPLS and > IPv6 data plane, was the main motivator for this proposal. > > I agree that the document needs improvements in number of places and > greatly appreciate your comments and suggestions. Hence the question, > would “ingress”/”egress” be more intuitive than “near-end”/”far-end”? Since we are talking explicitly routed LSPs "ingress/egress" is more intuitive for me. However, there is one question that I don't really grok. If you have a bi-directional co-routed and you are not receiving the egress to ingress control messages, you know that one direction is broken and since you have the requirement that the bi-directional LSP shall be "co-routed" you need to swap over to a stand-by or re-route, for both directions. If you have a uni-directional a co-route the control back from the egress to the ingress, and you are not receiving the egress to ingress control messages, you know that either the uni-directional LSP is broken or that the control channel is. Do you have a way to tell which it is? Do you really want to swap to a stand-by or re-route because the egress to ingress control channel is broken, while the explicit routed LSP is working just fine? /Loa > > Regards, > > Greg > > *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] > *Sent:* Wednesday, February 18, 2015 5:21 AM > *To:* Loa Andersson; mpls@ietf.org; > draft-mirsky-mpls-bfd-directed@tools.ietf.org > *Cc:* rtg-bfd@ietf.org > *Subject:* RE: [mpls] Question on draft-mirsky-mpls-bfd-directed > > + BFD WG > > Hi Loa, > >> -----Original Message----- > >> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > >> Sent: Monday, February 16, 2015 3:55 AM > >> To: mpls@ietf.org ; > draft-mirsky-mpls-bfd-directed@tools.ietf.org > > >> Subject: [mpls] Question on draft-mirsky-mpls-bfd-directed > >> > >> Authors, Working Group, > >> > >> I started to review draft-mirsky-mpls-bfd-directed, but got stuck on the > >> problem statement. > >> > >> If I understand you correctly, but I admit that I may have misunderstood, > >> you are saying that the scope of the document are uni- directional explicit > >> routed LSPs. A typical example would be MPLS-TE LSPs, right? > > That's not incorrect :) > > AFAIK, technically correct scope is all BFD session types that are > bootstrapped with LSP Ping, with uni-directional traffic engineered > paths on SPRING based networks being the primary use case. > >> > >> You also say that for such an LSPs the egress would use the shortest path for > >> its control message, while the ingress will send control messages in-band. > >> > >> Now in Asynchronous mode the BFD session will form a loop ingress - > >> egress - ingress, where ingress to egress is on the the monitored LSP, while > >> egress to ingress is out-of-band, right? > >> > >> You say that since the egress to ingress control message will follow the > >> shortest path, which might not be co-routed with the ingress to egress LSP, > >> missing responses can't be taken as an indication of that the uni- directional > >> LSP needs to be re-routed. > >> > >> While I agree with that statement, I don't see that if you give the egress an > >> explicit return/reverse path that is co-routed with the monitored LSP you > >> are really in a better shape to draw any conclusions. > >> Failure to receive egress to ingress control messages does not necessarily > >> tell you anything about the state of the monitored LSP. > > You are absolutely right. The egress-to-ingress BFD session not being > co-routed is a motivation for this document, but what the proposed > mechanism is providing is an ability to bootstrap egress-to-ingress BFD > session to take a specific path. Whether such egress-to-ingress sessions > are co-routed or otherwise is a choice left to users, and is outside the > scope of this document. With SPRING based network, user choosing the > co-routed egress-to-ingress path is doable (i.e., it is possible for an > element computing the forward stack to compute the reverse stack), but, > again, that's outside the scope of this document. I believe you have > pointed out this these aspects are slightly confusing/misleading and > need to be clarified in the document, and I agree with that. > > Additionally, I believe the premise is that it's better to take down the > uni-directional path based on the failure of user specified > egress-to-ingress path instead of an arbitrary egress-to-ingress path. > If the egress-to-ingress path can always be guaranteed [automatically] > to be co-routed in all cases, then that may be superior. However, I do > think what this document is describing is a reasonable improvement over > what we have today. > > Thanks! > > -Nobo > >> > >> /Loa > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expertloa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Feb 18 21:51:06 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2741A87C5; Wed, 18 Feb 2015 21:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 3xwcSSUhxsya; Wed, 18 Feb 2015 21:51:00 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74B71A8823; Wed, 18 Feb 2015 21:49:49 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-8e-54e5194dbe10 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 22.EC.25146.D4915E45; Wed, 18 Feb 2015 23:59:25 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Thu, 19 Feb 2015 00:49:47 -0500 From: Gregory Mirsky To: Loa Andersson , Nobo Akiya , "mpls@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" Subject: RE: [mpls] Question on draft-mirsky-mpls-bfd-directed Thread-Topic: [mpls] Question on draft-mirsky-mpls-bfd-directed Thread-Index: AQHQS33LS+erNgAZ2EqZdI4agf/AvZz3RR7AgAByPAD//74nEA== Date: Thu, 19 Feb 2015 05:49:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9110DA@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B91103A@eusaamb103.ericsson.se> <54E567AE.10002@pi.nu> In-Reply-To: <54E567AE.10002@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiK6v5NMQg31dWhYPF/ewW/ybO4fZ 4tbSlawWT869Y7H4/GcbowOrx85Zd9k9liz5yeQxa3obm8eXy5/ZAliiuGxSUnMyy1KL9O0S uDKOnu9lLNjlWdFx/yxLA+MJ9y5GTg4JAROJ6c86mCFsMYkL99azdTFycQgJHGGUuLb4CCtI QkhgOaPE2cnGIDabgJHEi4097CBFIgJnGCXW/GhnAkkwC2hKNJ34zA5iCwvYSey/cogRxBYR sJeYPXUhO4TtJHFhzhawehYBVYnvz1+ygNi8Ar4Sp1YfY4bYvJZRYlLfKrBmTgFliSPrroDZ jEDnfT+1BmqZuMStJ/OZIM4WkFiy5zzUC6ISLx//Y4WwlSTmvL4GFOcAO279Ln2IVkWJKd0P 2SH2CkqcnPmEZQKj2CwkU2chdMxC0jELSccCRpZVjBylxalluelGhpsYgXF1TILNcQfjgk+W hxgFOBiVeHg/HH8cIsSaWFZcmXuIUZqDRUmct+zKwRAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjGt590tXScUkyjkneOduyY79ZPDjQRL37ePrFXumcSqquS/etPfftrsnbfREWlrjCh90 uX/sSWDLNfo0b5oe33q9uWHTzyx+8lOJ6ZymypIptgd22SyOPVuyPnyXUFXb0bY9Ndap+1br 7c2Xi+rJ+8x6gMtcSnmRfXPcDycrk/dCAX8L1UseKbEUZyQaajEXFScCAIAtZROMAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 05:51:03 -0000 SGkgTG9hLA0KeW91ciBzY2VuYXJpbyBwZXJmZWN0bHkgaWxsdXN0cmF0ZXMgdGhlIGRpbGVtbWEg b3BlcmF0b3Igd291bGQgZmFjZSB3aGVuIHRyeWluZyB0byBwcm92aWRlIG46bSAgcHJvdGVjdGlv biBmb3IgdW5pLWRpcmVjdGlvbmFsIHRyYW5zcG9ydC4gSWYgb25seSAxKzEgcHJvdGVjdGlvbiBy ZXF1aXJlZCwgdGhlbiBpdCBpcyB0aGUgZWdyZXNzIG5vZGUgdGhhdCB3b3VsZCBkZXRlY3QgYSBk ZWZlY3QgYW5kIGZsaXAgdGhlIHN3aXRjaC4gQnV0IGlmIG46bSAoMToxIGFuZCAxOm4gYXJlIHNw ZWNpYWwgY2FzZXMpIHJlcXVpcmVkIHdlIGhhdmUgdG8gbWFrZSBjZXJ0YWluIGFzc3VtcHRpb25z LiBPYnZpb3VzbHkgd2UgYWx3YXlzIHRyeSB0byBtaW5pbWl6ZSB0aGVtIGJ1dCBhcywgZm9yIGV4 YW1wbGUsIHdpdGggdXNlIG9mIFNQTUUgZm9yIFNlZ21lbnQgT0FNIGluIE1QTFMtVFAsIGNhbm5v dCBlbGltaW5hdGUgY29tcGxldGVseS4gWWVzLCBmYWlsdXJlIG9mIGVncmVzcy10by1pbmdyZXNz IE9BTSBjaGFubmVsIG1heSBoYXBwZW4gd2hpbGUgaW5ncmVzcy10by1lZ3Jlc3MgZmxvdyBpcyBm dWxseSBvcGVyYXRpb25hbCBldmVuIHRob3VnaCBib3RoIGFyZSBjby1yb3V0ZWQuDQoNCglSZWdh cmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb2EgQW5k ZXJzc29uIFttYWlsdG86bG9hQHBpLm51XSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTgs IDIwMTUgODozNCBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBOb2JvIEFraXlhOyBtcGxzQGlldGYu b3JnOyBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWRAdG9vbHMuaWV0Zi5vcmcNCkNjOiBy dGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIFF1ZXN0aW9uIG9uIGRyYWZ0LW1p cnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KDQpHcmVnIGFuZCBOb2JvLA0KDQoNCg0KT24gMjAxNS0w Mi0xOSAxMDo1MiwgR3JlZ29yeSBNaXJza3kgd3JvdGU6DQo+IEhpIExvYSwgTm9ibywgZXQuIGFs LA0KPg0KPiBtYW55IHRoYW5rcyBmb3IgdmVyeSB0aG9yb3VnaCByZXZpZXcgYW5kIGdyZWF0IGRp c2N1c3Npb24uIE5vYm8gDQo+IHBvaW50ZWQgdGhhdCBpbnZlc3RpZ2F0aW9uIG9mIEJGRCBpbiBT ZWdtZW50IFJvdXRpbmcgbmV0d29yaywgYm90aCANCj4gd2l0aCBNUExTIGFuZA0KPiBJUHY2IGRh dGEgcGxhbmUsIHdhcyB0aGUgbWFpbiBtb3RpdmF0b3IgZm9yIHRoaXMgcHJvcG9zYWwuDQo+DQo+ IEkgYWdyZWUgdGhhdCB0aGUgZG9jdW1lbnQgbmVlZHMgaW1wcm92ZW1lbnRzIGluIG51bWJlciBv ZiBwbGFjZXMgYW5kIA0KPiBncmVhdGx5IGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBhbmQgc3Vn Z2VzdGlvbnMuIEhlbmNlIHRoZSBxdWVzdGlvbiwgDQo+IHdvdWxkIOKAnGluZ3Jlc3PigJ0v4oCd ZWdyZXNz4oCdIGJlIG1vcmUgaW50dWl0aXZlIHRoYW4g4oCcbmVhci1lbmTigJ0v4oCdZmFyLWVu ZOKAnT8NCg0KU2luY2Ugd2UgYXJlIHRhbGtpbmcgZXhwbGljaXRseSByb3V0ZWQgTFNQcyAiaW5n cmVzcy9lZ3Jlc3MiIGlzIG1vcmUgaW50dWl0aXZlIGZvciBtZS4NCg0KSG93ZXZlciwgdGhlcmUg aXMgb25lIHF1ZXN0aW9uIHRoYXQgSSBkb24ndCByZWFsbHkgZ3Jvay4NCg0KSWYgeW91IGhhdmUg YSBiaS1kaXJlY3Rpb25hbCBjby1yb3V0ZWQgYW5kIHlvdSBhcmUgbm90IHJlY2VpdmluZyB0aGUg ZWdyZXNzIHRvIGluZ3Jlc3MgY29udHJvbCBtZXNzYWdlcywgeW91IGtub3cgdGhhdCBvbmUgZGly ZWN0aW9uIGlzIGJyb2tlbiBhbmQgc2luY2UgeW91IGhhdmUgdGhlIHJlcXVpcmVtZW50IHRoYXQg dGhlIGJpLWRpcmVjdGlvbmFsIExTUCBzaGFsbCBiZSAiY28tcm91dGVkIiB5b3UgbmVlZCB0byBz d2FwIG92ZXIgdG8gYSBzdGFuZC1ieSBvciByZS1yb3V0ZSwgZm9yIGJvdGggZGlyZWN0aW9ucy4N Cg0KSWYgeW91IGhhdmUgYSB1bmktZGlyZWN0aW9uYWwgYSBjby1yb3V0ZSB0aGUgY29udHJvbCBi YWNrIGZyb20gdGhlIGVncmVzcyB0byB0aGUgaW5ncmVzcywgYW5kIHlvdSBhcmUgbm90IHJlY2Vp dmluZyB0aGUgZWdyZXNzIHRvIGluZ3Jlc3MgY29udHJvbCBtZXNzYWdlcywgeW91IGtub3cgdGhh dCBlaXRoZXIgdGhlIHVuaS1kaXJlY3Rpb25hbCBMU1AgaXMgYnJva2VuIG9yIHRoYXQgdGhlIGNv bnRyb2wgY2hhbm5lbCBpcy4gRG8geW91IGhhdmUgYSB3YXkgdG8gdGVsbCB3aGljaCBpdCBpcz8N Cg0KRG8geW91IHJlYWxseSB3YW50IHRvIHN3YXAgdG8gYSBzdGFuZC1ieSBvciByZS1yb3V0ZSBi ZWNhdXNlIHRoZSBlZ3Jlc3MgdG8gaW5ncmVzcyBjb250cm9sIGNoYW5uZWwgaXMgYnJva2VuLCB3 aGlsZSB0aGUgZXhwbGljaXQgcm91dGVkIExTUCBpcyB3b3JraW5nIGp1c3QgZmluZT8NCg0KL0xv YQ0KDQo+DQo+ICAgICAgICAgICAgICAgICAgUmVnYXJkcywNCj4NCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgR3JlZw0KPg0KPiAqRnJvbToqTm9ibyBBa2l5YSBbbWFpbHRvOm5v Ym8uYWtpeWEuZGV2QGdtYWlsLmNvbV0NCj4gKlNlbnQ6KiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE4 LCAyMDE1IDU6MjEgQU0NCj4gKlRvOiogTG9hIEFuZGVyc3NvbjsgbXBsc0BpZXRmLm9yZzsNCj4g ZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkQHRvb2xzLmlldGYub3JnDQo+ICpDYzoqIHJ0 Zy1iZmRAaWV0Zi5vcmcNCj4gKlN1YmplY3Q6KiBSRTogW21wbHNdIFF1ZXN0aW9uIG9uIGRyYWZ0 LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KPg0KPiArIEJGRCBXRw0KPg0KPiBIaSBMb2EsDQo+ DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPg0KPj4gRnJvbTogbXBscyBbbWFpbHRv Om1wbHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvYSBBbmRlcnNzb24NCj4NCj4+ IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTYsIDIwMTUgMzo1NSBBTQ0KPg0KPj4gVG86ICBtcGxz QGlldGYub3JnIDxtYWlsdG86bXBsc0BpZXRmLm9yZz47DQo+IGRyYWZ0LW1pcnNreS1tcGxzLWJm ZC1kaXJlY3RlZEB0b29scy5pZXRmLm9yZw0KPiA8bWFpbHRvOmRyYWZ0LW1pcnNreS1tcGxzLWJm ZC1kaXJlY3RlZEB0b29scy5pZXRmLm9yZz4NCj4NCj4+IFN1YmplY3Q6IFttcGxzXSBRdWVzdGlv biBvbiBkcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQNCj4NCj4+DQo+DQo+PiBBdXRob3Jz LCBXb3JraW5nIEdyb3VwLA0KPg0KPj4NCj4NCj4+IEkgc3RhcnRlZCB0byByZXZpZXcgZHJhZnQt bWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLCBidXQgZ290IHN0dWNrIG9uIA0KPj4gdGhlDQo+DQo+ PiBwcm9ibGVtIHN0YXRlbWVudC4NCj4NCj4+DQo+DQo+PiBJZiBJIHVuZGVyc3RhbmQgeW91IGNv cnJlY3RseSwgYnV0IEkgYWRtaXQgdGhhdCBJIG1heSBoYXZlIA0KPj4gbWlzdW5kZXJzdG9vZCwN Cj4NCj4+IHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCBhcmUg dW5pLSBkaXJlY3Rpb25hbCANCj4+IGV4cGxpY2l0DQo+DQo+PiByb3V0ZWQgTFNQcy4gQSB0eXBp Y2FsIGV4YW1wbGUgd291bGQgYmUgTVBMUy1URSBMU1BzLCByaWdodD8NCj4NCj4gVGhhdCdzIG5v dCBpbmNvcnJlY3QgOikNCj4NCj4gQUZBSUssIHRlY2huaWNhbGx5IGNvcnJlY3Qgc2NvcGUgaXMg YWxsIEJGRCBzZXNzaW9uIHR5cGVzIHRoYXQgYXJlIA0KPiBib290c3RyYXBwZWQgd2l0aCBMU1Ag UGluZywgd2l0aCB1bmktZGlyZWN0aW9uYWwgdHJhZmZpYyBlbmdpbmVlcmVkIA0KPiBwYXRocyBv biBTUFJJTkcgYmFzZWQgbmV0d29ya3MgYmVpbmcgdGhlIHByaW1hcnkgdXNlIGNhc2UuDQo+DQo+ Pg0KPg0KPj4gWW91IGFsc28gc2F5IHRoYXQgZm9yIHN1Y2ggYW4gTFNQcyB0aGUgZWdyZXNzIHdv dWxkIHVzZSB0aGUgc2hvcnRlc3QgDQo+PiBwYXRoIGZvcg0KPg0KPj4gaXRzIGNvbnRyb2wgbWVz c2FnZSwgd2hpbGUgdGhlIGluZ3Jlc3Mgd2lsbCBzZW5kIGNvbnRyb2wgbWVzc2FnZXMgaW4tYmFu ZC4NCj4NCj4+DQo+DQo+PiBOb3cgaW4gQXN5bmNocm9ub3VzIG1vZGUgdGhlIEJGRCBzZXNzaW9u IHdpbGwgZm9ybSBhIGxvb3AgaW5ncmVzcyAtDQo+DQo+PiBlZ3Jlc3MgLSBpbmdyZXNzLCB3aGVy ZSBpbmdyZXNzIHRvIGVncmVzcyBpcyBvbiB0aGUgdGhlIG1vbml0b3JlZCANCj4+IExTUCwgd2hp bGUNCj4NCj4+IGVncmVzcyB0byBpbmdyZXNzIGlzIG91dC1vZi1iYW5kLCByaWdodD8NCj4NCj4+ DQo+DQo+PiBZb3Ugc2F5IHRoYXQgc2luY2UgdGhlIGVncmVzcyB0byBpbmdyZXNzIGNvbnRyb2wg bWVzc2FnZSB3aWxsIGZvbGxvdyANCj4+IHRoZQ0KPg0KPj4gc2hvcnRlc3QgcGF0aCwgd2hpY2gg bWlnaHQgbm90IGJlIGNvLXJvdXRlZCB3aXRoIHRoZSBpbmdyZXNzIHRvIA0KPj4gZWdyZXNzIExT UCwNCj4NCj4+IG1pc3NpbmcgcmVzcG9uc2VzIGNhbid0IGJlIHRha2VuIGFzIGFuIGluZGljYXRp b24gb2YgdGhhdCB0aGUgdW5pLSANCj4+IGRpcmVjdGlvbmFsDQo+DQo+PiBMU1AgbmVlZHMgdG8g YmUgcmUtcm91dGVkLg0KPg0KPj4NCj4NCj4+IFdoaWxlIEkgYWdyZWUgd2l0aCB0aGF0IHN0YXRl bWVudCwgSSBkb24ndCBzZWUgdGhhdCBpZiB5b3UgZ2l2ZSB0aGUgDQo+PiBlZ3Jlc3MgYW4NCj4N Cj4+IGV4cGxpY2l0IHJldHVybi9yZXZlcnNlIHBhdGggdGhhdCBpcyBjby1yb3V0ZWQgd2l0aCB0 aGUgbW9uaXRvcmVkIExTUCANCj4+IHlvdQ0KPg0KPj4gYXJlIHJlYWxseSBpbiBhIGJldHRlciBz aGFwZSB0byBkcmF3IGFueSBjb25jbHVzaW9ucy4NCj4NCj4+IEZhaWx1cmUgdG8gcmVjZWl2ZSBl Z3Jlc3MgdG8gaW5ncmVzcyBjb250cm9sIG1lc3NhZ2VzIGRvZXMgbm90IA0KPj4gbmVjZXNzYXJp bHkNCj4NCj4+IHRlbGwgeW91IGFueXRoaW5nIGFib3V0IHRoZSBzdGF0ZSBvZiB0aGUgbW9uaXRv cmVkIExTUC4NCj4NCj4gWW91IGFyZSBhYnNvbHV0ZWx5IHJpZ2h0LiBUaGUgZWdyZXNzLXRvLWlu Z3Jlc3MgQkZEIHNlc3Npb24gbm90IGJlaW5nIA0KPiBjby1yb3V0ZWQgaXMgYSBtb3RpdmF0aW9u IGZvciB0aGlzIGRvY3VtZW50LCBidXQgd2hhdCB0aGUgcHJvcG9zZWQgDQo+IG1lY2hhbmlzbSBp cyBwcm92aWRpbmcgaXMgYW4gYWJpbGl0eSB0byBib290c3RyYXAgZWdyZXNzLXRvLWluZ3Jlc3Mg DQo+IEJGRCBzZXNzaW9uIHRvIHRha2UgYSBzcGVjaWZpYyBwYXRoLiBXaGV0aGVyIHN1Y2ggZWdy ZXNzLXRvLWluZ3Jlc3MgDQo+IHNlc3Npb25zIGFyZSBjby1yb3V0ZWQgb3Igb3RoZXJ3aXNlIGlz IGEgY2hvaWNlIGxlZnQgdG8gdXNlcnMsIGFuZCBpcyANCj4gb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4gV2l0aCBTUFJJTkcgYmFzZWQgbmV0d29yaywgdXNlciANCj4gY2hvb3Np bmcgdGhlIGNvLXJvdXRlZCBlZ3Jlc3MtdG8taW5ncmVzcyBwYXRoIGlzIGRvYWJsZSAoaS5lLiwg aXQgaXMgDQo+IHBvc3NpYmxlIGZvciBhbiBlbGVtZW50IGNvbXB1dGluZyB0aGUgZm9yd2FyZCBz dGFjayB0byBjb21wdXRlIHRoZSANCj4gcmV2ZXJzZSBzdGFjayksIGJ1dCwgYWdhaW4sIHRoYXQn cyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiANCj4gSSBiZWxpZXZlIHlvdSBo YXZlIHBvaW50ZWQgb3V0IHRoaXMgdGhlc2UgYXNwZWN0cyBhcmUgc2xpZ2h0bHkgDQo+IGNvbmZ1 c2luZy9taXNsZWFkaW5nIGFuZCBuZWVkIHRvIGJlIGNsYXJpZmllZCBpbiB0aGUgZG9jdW1lbnQs IGFuZCBJIGFncmVlIHdpdGggdGhhdC4NCj4NCj4gQWRkaXRpb25hbGx5LCBJIGJlbGlldmUgdGhl IHByZW1pc2UgaXMgdGhhdCBpdCdzIGJldHRlciB0byB0YWtlIGRvd24gDQo+IHRoZSB1bmktZGly ZWN0aW9uYWwgcGF0aCBiYXNlZCBvbiB0aGUgZmFpbHVyZSBvZiB1c2VyIHNwZWNpZmllZCANCj4g ZWdyZXNzLXRvLWluZ3Jlc3MgcGF0aCBpbnN0ZWFkIG9mIGFuIGFyYml0cmFyeSBlZ3Jlc3MtdG8t aW5ncmVzcyBwYXRoLg0KPiBJZiB0aGUgZWdyZXNzLXRvLWluZ3Jlc3MgcGF0aCBjYW4gYWx3YXlz IGJlIGd1YXJhbnRlZWQgW2F1dG9tYXRpY2FsbHldIA0KPiB0byBiZSBjby1yb3V0ZWQgaW4gYWxs IGNhc2VzLCB0aGVuIHRoYXQgbWF5IGJlIHN1cGVyaW9yLiBIb3dldmVyLCBJIGRvIA0KPiB0aGlu ayB3aGF0IHRoaXMgZG9jdW1lbnQgaXMgZGVzY3JpYmluZyBpcyBhIHJlYXNvbmFibGUgaW1wcm92 ZW1lbnQgDQo+IG92ZXIgd2hhdCB3ZSBoYXZlIHRvZGF5Lg0KPg0KPiBUaGFua3MhDQo+DQo+IC1O b2JvDQo+DQo+Pg0KPg0KPj4gL0xvYQ0KPg0KPj4gLS0NCj4NCj4+DQo+DQo+Pg0KPg0KPj4gTG9h IEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiAgbG9hQG1haWwwMS5odWF3 ZWkuY29tIDxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KPg0KPj4gU2VuaW9yIE1QTFMg RXhwZXJ0bG9hQHBpLm51IDxtYWlsdG86bG9hQHBpLm51Pg0KPg0KPj4gSHVhd2VpIFRlY2hub2xv Z2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+DQo+Pg0KPg0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj4+ IG1wbHMgbWFpbGluZyBsaXN0DQo+DQo+PiAgbXBsc0BpZXRmLm9yZyA8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+DQo+DQo+PiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQo+DQoNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg ICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From nobody Wed Feb 18 23:13:44 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899AC1A8882; Wed, 18 Feb 2015 23:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 k7nRZZUcBxkm; Wed, 18 Feb 2015 23:13:39 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D16DF1A870F; Wed, 18 Feb 2015 23:13:38 -0800 (PST) Received: from [192.168.1.12] (unknown [49.149.205.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CDF801801587; Thu, 19 Feb 2015 08:13:34 +0100 (CET) Message-ID: <54E58D18.6080800@pi.nu> Date: Thu, 19 Feb 2015 15:13:28 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gregory Mirsky , Nobo Akiya , "mpls@ietf.org" , "draft-mirsky-mpls-bfd-directed@tools.ietf.org" Subject: Re: [mpls] Question on draft-mirsky-mpls-bfd-directed References: <7347100B5761DC41A166AC17F22DF1121B91103A@eusaamb103.ericsson.se> <54E567AE.10002@pi.nu> <7347100B5761DC41A166AC17F22DF1121B9110DA@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9110DA@eusaamb103.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 07:13:41 -0000 Greg, On 2015-02-19 13:49, Gregory Mirsky wrote: > Hi Loa, > your scenario perfectly illustrates the dilemma operator would face when trying to provide n:m protection for uni-directional transport. If only 1+1 protection required, then it is the egress node that would detect a defect and flip the switch. But if n:m (1:1 and 1:n are special cases) required we have to make certain assumptions. Obviously we always try to minimize them but as, for example, with use of SPME for Segment OAM in MPLS-TP, cannot eliminate completely. Yes, failure of egress-to-ingress OAM channel may happen while ingress-to-egress flow is fully operational even though both are co-routed. > > Regards, > Greg I understand that we are able to quite easily co-route the explicitly route LSP, and the the egress to ingress control channel. Can you more precisely describe the assumptions you make and what problem you solve? /Loa > > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Wednesday, February 18, 2015 8:34 PM > To: Gregory Mirsky; Nobo Akiya; mpls@ietf.org; draft-mirsky-mpls-bfd-directed@tools.ietf.org > Cc: rtg-bfd@ietf.org > Subject: Re: [mpls] Question on draft-mirsky-mpls-bfd-directed > > Greg and Nobo, > > > > On 2015-02-19 10:52, Gregory Mirsky wrote: >> Hi Loa, Nobo, et. al, >> >> many thanks for very thorough review and great discussion. Nobo >> pointed that investigation of BFD in Segment Routing network, both >> with MPLS and >> IPv6 data plane, was the main motivator for this proposal. >> >> I agree that the document needs improvements in number of places and >> greatly appreciate your comments and suggestions. Hence the question, >> would “ingress”/”egress” be more intuitive than “near-end”/”far-end”? > > Since we are talking explicitly routed LSPs "ingress/egress" is more intuitive for me. > > However, there is one question that I don't really grok. > > If you have a bi-directional co-routed and you are not receiving the egress to ingress control messages, you know that one direction is broken and since you have the requirement that the bi-directional LSP shall be "co-routed" you need to swap over to a stand-by or re-route, for both directions. > > If you have a uni-directional a co-route the control back from the egress to the ingress, and you are not receiving the egress to ingress control messages, you know that either the uni-directional LSP is broken or that the control channel is. Do you have a way to tell which it is? > > Do you really want to swap to a stand-by or re-route because the egress to ingress control channel is broken, while the explicit routed LSP is working just fine? > > /Loa > >> >> Regards, >> >> Greg >> >> *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] >> *Sent:* Wednesday, February 18, 2015 5:21 AM >> *To:* Loa Andersson; mpls@ietf.org; >> draft-mirsky-mpls-bfd-directed@tools.ietf.org >> *Cc:* rtg-bfd@ietf.org >> *Subject:* RE: [mpls] Question on draft-mirsky-mpls-bfd-directed >> >> + BFD WG >> >> Hi Loa, >> >>> -----Original Message----- >> >>> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson >> >>> Sent: Monday, February 16, 2015 3:55 AM >> >>> To: mpls@ietf.org ; >> draft-mirsky-mpls-bfd-directed@tools.ietf.org >> >> >>> Subject: [mpls] Question on draft-mirsky-mpls-bfd-directed >> >>> >> >>> Authors, Working Group, >> >>> >> >>> I started to review draft-mirsky-mpls-bfd-directed, but got stuck on >>> the >> >>> problem statement. >> >>> >> >>> If I understand you correctly, but I admit that I may have >>> misunderstood, >> >>> you are saying that the scope of the document are uni- directional >>> explicit >> >>> routed LSPs. A typical example would be MPLS-TE LSPs, right? >> >> That's not incorrect :) >> >> AFAIK, technically correct scope is all BFD session types that are >> bootstrapped with LSP Ping, with uni-directional traffic engineered >> paths on SPRING based networks being the primary use case. >> >>> >> >>> You also say that for such an LSPs the egress would use the shortest >>> path for >> >>> its control message, while the ingress will send control messages in-band. >> >>> >> >>> Now in Asynchronous mode the BFD session will form a loop ingress - >> >>> egress - ingress, where ingress to egress is on the the monitored >>> LSP, while >> >>> egress to ingress is out-of-band, right? >> >>> >> >>> You say that since the egress to ingress control message will follow >>> the >> >>> shortest path, which might not be co-routed with the ingress to >>> egress LSP, >> >>> missing responses can't be taken as an indication of that the uni- >>> directional >> >>> LSP needs to be re-routed. >> >>> >> >>> While I agree with that statement, I don't see that if you give the >>> egress an >> >>> explicit return/reverse path that is co-routed with the monitored LSP >>> you >> >>> are really in a better shape to draw any conclusions. >> >>> Failure to receive egress to ingress control messages does not >>> necessarily >> >>> tell you anything about the state of the monitored LSP. >> >> You are absolutely right. The egress-to-ingress BFD session not being >> co-routed is a motivation for this document, but what the proposed >> mechanism is providing is an ability to bootstrap egress-to-ingress >> BFD session to take a specific path. Whether such egress-to-ingress >> sessions are co-routed or otherwise is a choice left to users, and is >> outside the scope of this document. With SPRING based network, user >> choosing the co-routed egress-to-ingress path is doable (i.e., it is >> possible for an element computing the forward stack to compute the >> reverse stack), but, again, that's outside the scope of this document. >> I believe you have pointed out this these aspects are slightly >> confusing/misleading and need to be clarified in the document, and I agree with that. >> >> Additionally, I believe the premise is that it's better to take down >> the uni-directional path based on the failure of user specified >> egress-to-ingress path instead of an arbitrary egress-to-ingress path. >> If the egress-to-ingress path can always be guaranteed [automatically] >> to be co-routed in all cases, then that may be superior. However, I do >> think what this document is describing is a reasonable improvement >> over what we have today. >> >> Thanks! >> >> -Nobo >> >>> >> >>> /Loa >> >>> -- >> >>> >> >>> >> >>> Loa Andersson email: loa@mail01.huawei.com >> >>> Senior MPLS Expertloa@pi.nu >> >>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> >>> >> >>> _______________________________________________ >> >>> mpls mailing list >> >>> mpls@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mpls >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Feb 20 03:36:45 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAC1A19F7 for ; Fri, 20 Feb 2015 03:36:44 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kH6IvlZ1rhAD for ; Fri, 20 Feb 2015 03:36:42 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0C91A8881 for ; Fri, 20 Feb 2015 03:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11649; q=dns/txt; s=iport; t=1424432109; x=1425641709; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=OzZldVn/u4XEUOW8HZWmlBGAn8Q71TCRbtMcr0KvCJI=; b=F0jHa8yCgN4sAa7PkPRcqXzm48KH0gJrM1yK7ieIBPA0wItAyKWF+4cX +WcUePUqftQeL6zTvQXtFh30r4+ivd2BAG0eSUsSPHclG6zrdh7lxHBvv Z21ydmu5hLu3TgvrF97NG+X3sg0gO4JdgvZWHq8SdiD9njCt81Pu1mgwP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBQBCG+dU/4kNJK1bgkNDgSwEwEaIGwKBFkMBAQEBAQF8hA8BAgQMbRIBCBEDAQIoJgIRFAkIAgQBDQUUiAcDEc5WDYUyAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sPgkSCGREHhCoFj04Eh3eBRo0khgciggIcFIE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,614,1418083200"; d="scan'208,217";a="125374529" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-3.cisco.com with ESMTP; 20 Feb 2015 11:35:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1KBZ800003244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 11:35:08 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.188]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 05:35:08 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Manav Bhatia , Santosh P K Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tbJgNPo8mXQkqqw7TBgmGJB5z2VxcAgAE9LYCAAp+XAA== Date: Fri, 20 Feb 2015 11:35:07 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.77] Content-Type: multipart/alternative; boundary="_000_D10D17CA2A9F2mmudigonciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 11:36:44 -0000 --_000_D10D17CA2A9F2mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Santosh/Manav, Good idea to have authentication only on negotiated packets. But I have a q= uestion. The draft says it is enough to authenticate the packets which indi= cate a state change. What about =91P=92 bit packets which change the timers= ? An attacker can send a packet with =91P=92 bit and a very big timer value= which may lead to BFD not detecting faults as expected. Though the draft d= oes not specifically say =93state change packets only=94, I did not find th= e =91P=92 bit packets which can change detection timer values. Is this inte= ntional? Thanks Regards Mallik From: Manav Bhatia > Date: Thursday, 19 February 2015 6:31 am To: Santosh P K > Cc: "rtg-bfd@ietf.org" > Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00 Hi Santosh, Thanks for the review. Comments inline. On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K > wrote: Hello Ashesh, I have few questions on this draft. 1. Why do we make an assumptions that BFD need no Auth when BFD is in= UP or not changing the state? Is that because BFD will be demuxed with onl= y discr in the packet? Yes. 2. Draft says =93For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only. If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled, then the BFD session will fail to come up, because at least one end will expect every frame to be authenticated.=94 It is not clear how does two peers negotiated? Using A bit in the BFD packe= t or through configuration? Or through IGP/BGP? We had intentionally left this unspecified as this is orthogonal to the iss= ue that the draft addresses. This feature can be trivially negotiated by us= ing a new auth TLV type. However, the larger issue is whether the community= is comfortable with the core idea that is being proposed here -- on only u= sing authenticated BFD packets when there is a state change. 3. I am not clear what does this below statement mean? =93In addition, it states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD Control packet.=94 .. and neither am I. I'll wait for Ashesh to clarify this. Cheers, Manav --_000_D10D17CA2A9F2mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Santosh/Manav,

Good idea to have authentication only on negotiated packets. But I hav= e a question. The draft says it is enough to authenticate the packets which= indicate a state change. What about =91P=92 bit packets which change the t= imers? An attacker can send a packet with =91P=92 bit and a very big timer value which may lead to BFD not dete= cting faults as expected. Though the draft does not specifically say =93sta= te change packets only=94, I did not find the =91P=92 bit packets which can= change detection timer values. Is this intentional?

Thanks

Regards
Mallik 

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Thursday, 19 February 2015 6:= 31 am
To: Santosh P K <santoshpk@juniper.net>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: New BFD Authentication= Optimization draft draft-mahesh-bfd-authentication-00

Hi Santosh,

Thanks for the review. Comments inline.

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <santoshpk@ju= niper.net> wrote:

Hello Ashesh,<= /p>

    I have few quest= ions on this draft.

 

1.       Why do we make an assumptions = that BFD need no Auth when BFD is in UP or not changing the state? Is that = because BFD will be demuxed with only discr in the packet?


Yes.
 

2.       Draft says

      =93For example,=
 the two ends can decide

   that BFD frames that indicate a state change should b= e authenticated

   and enable authentication on those frames only. = If the two ends have

   not previously negotiated which frames they will tran= smit or receive

   with authentication enabled, then the BFD session wil= l fail to come

   up, because at least one end will expect every frame = to be

   authenticated.=94

 

It is not clear how does two peers = negotiated? Using A bit in the BFD packet or through configuration? Or thro= ugh IGP/BGP?


We had intentionally left this unspecified as this is orthogonal to th= e issue that the draft addresses. This feature can be trivially negotiated = by using a new auth TLV type. However, the larger issue is whether the comm= unity is comfortable with the core idea that is being proposed here -- on only using authenticated BFD packet= s when there is a state change.

3.       I am not clear what does this = below statement mean?

         =
;           =93In =
addition, it states that an
   implementation SHOULD NOT allow the authentication state =
to be
   changed based on the receipt of a BFD Control packet.=94

 


.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheers, Manav
 --_000_D10D17CA2A9F2mmudigonciscocom_-- From nobody Fri Feb 20 04:50:18 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CED1A8ADE for ; Fri, 20 Feb 2015 04:50:16 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vc3mW7pUcTmC for ; Fri, 20 Feb 2015 04:50:13 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 7B3B31A87CA for ; Fri, 20 Feb 2015 04:50:13 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wo20so23898942obc.7 for ; Fri, 20 Feb 2015 04:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WZUgGFkhCfJCGIAlsTWSB8tQ72eW04xNk1AZtSxf7rE=; b=ylmXVPQfgZ1eVry7tiFYyJM+uglnjz7/W5Kzd9yQoF3lsH2XrD/PDIwMkn3EbdPy5w /MeaEFsmwYsvzxgT01E1LEmoNOKZOyv6N0TqanaP31zMDSDxo4GYVqgFte5La6FLo6W/ Wvn89E/X33F7ju0uay/dJrDwzu2fgUzxzS3CA2HpLvkpr7d3964qTiATOyVgQ3RQWPNi Ggixpe2Y1o1epmUAb4YXxWpV9M/LtZLkKqDnk6/hnIjOomfSeB/JUlDo7QsQfGAtqWkD J81kQY5ocBvDIRNNzGin90d41pR9/W3nMRfFQpec8w1l7+NcEcVgrvnj5Pp7Ns9PXp2I 7c6Q== MIME-Version: 1.0 X-Received: by 10.202.133.131 with SMTP id h125mr6032972oid.23.1424436612727; Fri, 20 Feb 2015 04:50:12 -0800 (PST) Received: by 10.76.112.136 with HTTP; Fri, 20 Feb 2015 04:50:12 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 18:20:12 +0530 Message-ID: Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Manav Bhatia To: "MALLIK MUDIGONDA (mmudigon)" Content-Type: multipart/alternative; boundary=001a113e3fa04e89c2050f847e7a Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:50:16 -0000 --001a113e3fa04e89c2050f847e7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mallik, I am not sure why this got missed out. We authenticate a packet if it carries something that has changed -- in your case, the "P" bit. To summarize - The idea is to NOT authenticate the packet if nothing has changed since the last time a BFD packet was sent out. Cheers, Manav On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGONDA (mmudigon) < mmudigon@cisco.com> wrote: > Hi Santosh/Manav, > > Good idea to have authentication only on negotiated packets. But I have > a question. The draft says it is enough to authenticate the packets which > indicate a state change. What about =E2=80=98P=E2=80=99 bit packets which= change the > timers? An attacker can send a packet with =E2=80=98P=E2=80=99 bit and a = very big timer > value which may lead to BFD not detecting faults as expected. Though the > draft does not specifically say =E2=80=9Cstate change packets only=E2=80= =9D, I did not find > the =E2=80=98P=E2=80=99 bit packets which can change detection timer valu= es. Is this > intentional? > > Thanks > > Regards > Mallik > > From: Manav Bhatia > Date: Thursday, 19 February 2015 6:31 am > To: Santosh P K > Cc: "rtg-bfd@ietf.org" > Subject: Re: New BFD Authentication Optimization draft > draft-mahesh-bfd-authentication-00 > > Hi Santosh, > > Thanks for the review. Comments inline. > > On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K > wrote: > >> Hello Ashesh, >> >> I have few questions on this draft. >> >> >> >> 1. Why do we make an assumptions that BFD need no Auth when BFD is >> in UP or not changing the state? Is that because BFD will be demuxed wit= h >> only discr in the packet? >> > > Yes. > > >> 2. Draft says >> >> =E2=80=9CFor example, the two ends can decide >> >> that BFD frames that indicate a state change should be authenticated >> >> and enable authentication on those frames only. If the two ends have >> >> not previously negotiated which frames they will transmit or receive >> >> with authentication enabled, then the BFD session will fail to come >> >> up, because at least one end will expect every frame to be >> >> authenticated.=E2=80=9D >> >> >> >> It is not clear how does two peers negotiated? Using A bit in the BFD >> packet or through configuration? Or through IGP/BGP? >> > > We had intentionally left this unspecified as this is orthogonal to the > issue that the draft addresses. This feature can be trivially negotiated = by > using a new auth TLV type. However, the larger issue is whether the > community is comfortable with the core idea that is being proposed here -= - > on only using authenticated BFD packets when there is a state change. > > 3. I am not clear what does this below statement mean? >> >> =E2=80=9CIn addition, it states that an >> >> implementation SHOULD NOT allow the authentication state to be >> >> changed based on the receipt of a BFD Control packet.=E2=80=9D >> >> >> > > .. and neither am I. > > I'll wait for Ashesh to clarify this. > > Cheers, Manav > --001a113e3fa04e89c2050f847e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mallik,

I am not sure why this got m= issed out. We authenticate a packet if it carries something that has change= d -- in your case, the "P" bit.=C2=A0

To= summarize - The idea is to NOT authenticate the packet if nothing has chan= ged since the last time a BFD packet was sent out.

Cheers, Manav

On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGONDA (mmudigon) <mm= udigon@cisco.com> wrote:
Hi Santosh/Manav,

Good idea to have authentication only on negotiated packets. But I hav= e a question. The draft says it is enough to authenticate the packets which= indicate a state change. What about =E2=80=98P=E2=80=99 bit packets which = change the timers? An attacker can send a packet with =E2=80=98P=E2=80=99 bit and a very big timer value which may lead to = BFD not detecting faults as expected. Though the draft does not specificall= y say =E2=80=9Cstate change packets only=E2=80=9D, I did not find the =E2= =80=98P=E2=80=99 bit packets which can change detection timer values. Is th= is intentional?

Thanks

Regards
Mallik=C2=A0

From: Manav Bhatia <manavbhatia@gmail.com>= ;
Date: Thursday, 19 February 2015 6:= 31 am
To: Santosh P K <santoshpk@juniper.net> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: New BFD Authentication= Optimization draft draft-mahesh-bfd-authentication-00

Hi Santosh,

Thanks for the review. Comments inline.

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <santoshpk@ju= niper.net> wrote:

Hello Ashesh,

=C2=A0=C2=A0=C2=A0 I have few questions on t= his draft.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Why do we make an assumptions that BFD = need no Auth when BFD is in UP or not changing the state? Is that because B= FD will be demuxed with only discr in the packet?


Yes.
=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Draft says

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CFor example, th=
e two ends can decide

=C2=A0=C2=A0 that BFD frames that indicate a state change shou= ld be authenticated

=C2=A0=C2=A0 and enable authentication on those frames only.= =C2=A0 If the two ends have

=C2=A0=C2=A0 not previously negotiated which frames they will = transmit or receive

=C2=A0=C2=A0 with authentication enabled, then the BFD session= will fail to come

=C2=A0=C2=A0 up, because at least one end will expect every fr= ame to be

=C2=A0=C2=A0 authenticated.=E2=80=9D<= /u>

=C2=A0

It is not clear how does two peers negotiate= d? Using A bit in the BFD packet or through configuration? Or through IGP/B= GP?


We had intentionally left this unspecified as this is orthogonal to th= e issue that the draft addresses. This feature can be trivially negotiated = by using a new auth TLV type. However, the larger issue is whether the comm= unity is comfortable with the core idea that is being proposed here -- on only using authenticated BFD packet= s when there is a state change.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I am not clear what does this below sta= tement mean?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80=9CIn a=
ddition, it states that an
=C2=A0=C2=A0 implementation SHOULD NOT allow the authentication state =
to be
=C2=A0=C2=A0 changed based on the receipt of a BFD Control packet.=E2=80=9D

=C2=A0


.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheers, Manav

--001a113e3fa04e89c2050f847e7a-- From nobody Fri Feb 20 05:05:44 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41C91A8AF6 for ; Fri, 20 Feb 2015 05:05:42 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 V9ab28xX2AKW for ; Fri, 20 Feb 2015 05:05:40 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DEF1A8A16 for ; Fri, 20 Feb 2015 05:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15242; q=dns/txt; s=iport; t=1424437540; x=1425647140; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YEXHRyoMCTRYIqFBBDVh5C8s/he0rnpGf1V3Aen+XEs=; b=X/catYelyuCH8GKGXza2zanec58nS6gNVrAOUi5ysNlDmmVBtZvSCdLB VhrcAPws+rDCES5MdPpsqEPSUmJUt5gbVU9Q7/QOrVokMNhcoMYHt1ZXq q5esmE5JcNKqm0PmrO8QMWLo038ZuEJM5lIAt250TxSY9Eh3EFgl28gDG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DOBQC1MOdU/5ldJa1bgkNDgSwEwEaIGwKBF0MBAQEBAQF8hA8BAgQMWxISAQgRAwECKCYCERQJCAIEDgUUiAcDEc5RDYUyAQEBAQEBAQMBAQEBAQEBAQEBAReLD4JEghkRB4QqBY1egXAEh3eBRoEZjAuCSYM+IoICHBSBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,614,1418083200"; d="scan'208,217";a="125402995" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 20 Feb 2015 13:05:39 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1KD5dND020522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 13:05:39 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.188]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 07:05:39 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Manav Bhatia Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tbJgNPo8mXQkqqw7TBgmGJB5z2VxcAgAE9LYCAAp+XAP//uMsAgABgf4A= Date: Fri, 20 Feb 2015 13:05:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.26.77] Content-Type: multipart/alternative; boundary="_000_D10D2EE42AA20mmudigonciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 13:05:43 -0000 --_000_D10D2EE42AA20mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Manav, That clarifies it. Regards Mallik From: Manav Bhatia > Date: Friday, 20 February 2015 6:20 pm To: Cisco Employee > Cc: Santosh P K >, "rtg= -bfd@ietf.org" > Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00 Hi Mallik, I am not sure why this got missed out. We authenticate a packet if it carri= es something that has changed -- in your case, the "P" bit. To summarize - The idea is to NOT authenticate the packet if nothing has ch= anged since the last time a BFD packet was sent out. Cheers, Manav On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGONDA (mmudigon) > wrote: Hi Santosh/Manav, Good idea to have authentication only on negotiated packets. But I have a q= uestion. The draft says it is enough to authenticate the packets which indi= cate a state change. What about =91P=92 bit packets which change the timers= ? An attacker can send a packet with =91P=92 bit and a very big timer value= which may lead to BFD not detecting faults as expected. Though the draft d= oes not specifically say =93state change packets only=94, I did not find th= e =91P=92 bit packets which can change detection timer values. Is this inte= ntional? Thanks Regards Mallik From: Manav Bhatia > Date: Thursday, 19 February 2015 6:31 am To: Santosh P K > Cc: "rtg-bfd@ietf.org" > Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00 Hi Santosh, Thanks for the review. Comments inline. On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K > wrote: Hello Ashesh, I have few questions on this draft. 1. Why do we make an assumptions that BFD need no Auth when BFD is in= UP or not changing the state? Is that because BFD will be demuxed with onl= y discr in the packet? Yes. 2. Draft says =93For example, the two ends can decide that BFD frames that indicate a state change should be authenticated and enable authentication on those frames only. If the two ends have not previously negotiated which frames they will transmit or receive with authentication enabled, then the BFD session will fail to come up, because at least one end will expect every frame to be authenticated.=94 It is not clear how does two peers negotiated? Using A bit in the BFD packe= t or through configuration? Or through IGP/BGP? We had intentionally left this unspecified as this is orthogonal to the iss= ue that the draft addresses. This feature can be trivially negotiated by us= ing a new auth TLV type. However, the larger issue is whether the community= is comfortable with the core idea that is being proposed here -- on only u= sing authenticated BFD packets when there is a state change. 3. I am not clear what does this below statement mean? =93In addition, it states that an implementation SHOULD NOT allow the authentication state to be changed based on the receipt of a BFD Control packet.=94 .. and neither am I. I'll wait for Ashesh to clarify this. Cheers, Manav --_000_D10D2EE42AA20mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5D6D3CAA0C88664488E1E55D94A9FA2D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Manav,

That clarifies it.

Regards
Mallik

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Friday, 20 February 2015 6:20= pm
To: Cisco Employee <mmudigon@cisco.com>
Cc: Santosh P K <santoshpk@juniper.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: New BFD Authentication= Optimization draft draft-mahesh-bfd-authentication-00

Hi Mallik,

I am not sure why this got missed out. We authenticate a packet if it = carries something that has changed -- in your case, the "P" bit.&= nbsp;

To summarize - The idea is to NOT authenticate the packet if nothing h= as changed since the last time a BFD packet was sent out.

Cheers, Manav

On Fri, Feb 20, 2015 at 5:05 PM, MALLIK MUDIGOND= A (mmudigon) <mmudigon@cisco.com> wrote:
Hi Santosh/Manav,

Good idea to have authentication only on negotiated packets. But I hav= e a question. The draft says it is enough to authenticate the packets which= indicate a state change. What about =91P=92 bit packets which change the t= imers? An attacker can send a packet with =91P=92 bit and a very big timer value which may lead to BFD not dete= cting faults as expected. Though the draft does not specifically say =93sta= te change packets only=94, I did not find the =91P=92 bit packets which can= change detection timer values. Is this intentional?

Thanks

Regards
Mallik 

From: Manav Bhatia <manavbhatia@gmail.com>= ;
Date: Thursday, 19 February 2015 6:= 31 am
To: Santosh P K <santoshpk@juniper.net> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: New BFD Authentication= Optimization draft draft-mahesh-bfd-authentication-00

Hi Santosh,

Thanks for the review. Comments inline.

On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K <santoshpk@ju= niper.net> wrote:

Hello Ashesh,<= /p>

    I have few quest= ions on this draft.

 

1.       Why do we make an assumptions = that BFD need no Auth when BFD is in UP or not changing the state? Is that = because BFD will be demuxed with only discr in the packet?


Yes.
 

2.       Draft says

      =93For example,=
 the two ends can decide

   that BFD frames that indicate a state change should b= e authenticated

   and enable authentication on those frames only. = If the two ends have

   not previously negotiated which frames they will tran= smit or receive

   with authentication enabled, then the BFD session wil= l fail to come

   up, because at least one end will expect every frame = to be

   authenticated.=94

 

It is not clear how does two peers = negotiated? Using A bit in the BFD packet or through configuration? Or thro= ugh IGP/BGP?


We had intentionally left this unspecified as this is orthogonal to th= e issue that the draft addresses. This feature can be trivially negotiated = by using a new auth TLV type. However, the larger issue is whether the comm= unity is comfortable with the core idea that is being proposed here -- on only using authenticated BFD packet= s when there is a state change.

3.       I am not clear what does this = below statement mean?

         =
;           =93In =
addition, it states that an
   implementation SHOULD NOT allow the authentication state =
to be
   changed based on the receipt of a BFD Control packet.=94

 


.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheers, Manav

 --_000_D10D2EE42AA20mmudigonciscocom_-- From nobody Sun Feb 22 07:52:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932DA1A1BE5 for ; Sun, 22 Feb 2015 07:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.811 X-Spam-Level: X-Spam-Status: No, score=-11.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 q73t43Y-lIi0 for ; Sun, 22 Feb 2015 07:52:10 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED84F1A1BC7 for ; Sun, 22 Feb 2015 07:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3466; q=dns/txt; s=iport; t=1424620330; x=1425829930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wsIre0p2+N664eXsS60PIveJlEGZlnewVLZBx6RTpVM=; b=ReWo33dv8KcFlVnJyRIbGtWlIylU0C8UyHm8G0SQFliqw30WtX60oNZG K7kX6zvOhaZiY5DDVJsE7zr1OPECcTZIWHnM3u/IFP/4OD3KPtq4NIryE UXc/sStsyjiM+vMNHAuL9beiSVWzq6Iy5PkrXzGn/VI3dYj0n96lz0ogU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBwBD+ulU/5NdJa1bgwaBLASDBL1fiBoCHH1DAQEBAQEBfIQPAQEBAwEjEUUFCwIBBgIRBAEBAwIGHQMCAgIwFAEICAIEAQ0FCAyIEwidWJxsl2EBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcoQ9MQeCaC+BFAEEj1KKXoMVi0WDPiKCMoE8b4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,625,1418083200"; d="scan'208";a="125799616" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP; 22 Feb 2015 15:52:09 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1MFq9hv020844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Feb 2015 15:52:09 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.72]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sun, 22 Feb 2015 09:52:09 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Manav Bhatia , Santosh P K Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tbMrgEolWABEC4J6660DikV5z2VxcAgAE9LYCABUqRAA== Date: Sun, 22 Feb 2015 15:52:08 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 15:52:11 -0000 SGVsbG8gTWFuYXYsDQpPbmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSAobGFjayBvZikgbmVlZCBm b3IgYXV0aGVudGljYXRpbmcgQkZEIHBhY2tldHMgd2hlbiBpbiBVUCBzdGF0ZToNCg0KPiAxLsKg wqDCoMKgwqDCoCBXaHkgZG8gd2UgbWFrZSBhbiBhc3N1bXB0aW9ucyB0aGF0IEJGRCBuZWVkIG5v IEF1dGggd2hlbiBCRkQgaXMgaW4gVVAgb3Igbm90IGNoYW5naW5nIHRoZSBzdGF0ZT8gSXMgdGhh dCBiZWNhdXNlIEJGRCB3aWxsIGJlID4gZGVtdXhlZCB3aXRoIG9ubHkgZGlzY3IgaW4gdGhlIHBh Y2tldD8NCj4gWWVzLg0KDQpJcyBpdCBwb3NzaWJsZSB0aGF0IGEgcmVwbGF5IGF0dGFjayBjb3Vs ZCBiZSBtYWRlIGJ5IGtlZXBpbmcgYSBsaW5rIFVQIHdoZW4gaXQgc2hvdWxkIGhhdmUgYWN0dWFs bHkgYmUgRE9XTi4gSW4gb3RoZXIgd29yZHMsIGRvIHdlIHJ1biB0aGUgcmlzayBvZiBub3QgZGV0 ZWN0aW5nIGEgbGluayBmYWlsdXJlIGR1ZSB0byBhIE1pTSBkb2luZyBhIHJlcGxheSBhdHRhY2s/ DQpQbGVhc2UgbGV0IG1lIGtub3cgeW91ciB0aG91Z2h0cy4NClRoYW5rcw0KUHJhc2FkDQoNCkZy b206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBNYW5hdiBCaGF0aWENClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxOSwgMjAxNSA2OjMxIEFN DQpUbzogU2FudG9zaCBQIEsNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogTmV3 IEJGRCBBdXRoZW50aWNhdGlvbiBPcHRpbWl6YXRpb24gZHJhZnQgZHJhZnQtbWFoZXNoLWJmZC1h dXRoZW50aWNhdGlvbi0wMA0KDQpIaSBTYW50b3NoLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcu IENvbW1lbnRzIGlubGluZS4NCg0KT24gV2VkLCBGZWIgMTgsIDIwMTUgYXQgMTE6MzYgQU0sIFNh bnRvc2ggUCBLIDxzYW50b3NocGtAanVuaXBlci5uZXQ+IHdyb3RlOg0KSGVsbG8gQXNoZXNoLA0K wqDCoMKgIEkgaGF2ZSBmZXcgcXVlc3Rpb25zIG9uIHRoaXMgZHJhZnQuDQrCoA0KMS7CoMKgwqDC oMKgwqAgV2h5IGRvIHdlIG1ha2UgYW4gYXNzdW1wdGlvbnMgdGhhdCBCRkQgbmVlZCBubyBBdXRo IHdoZW4gQkZEIGlzIGluIFVQIG9yIG5vdCBjaGFuZ2luZyB0aGUgc3RhdGU/IElzIHRoYXQgYmVj YXVzZSBCRkQgd2lsbCBiZSBkZW11eGVkIHdpdGggb25seSBkaXNjciBpbiB0aGUgcGFja2V0Pw0K DQpZZXMuDQrCoA0KMi7CoMKgwqDCoMKgwqAgRHJhZnQgc2F5cw0KwqDCoMKgwqDCoCDigJxGb3Ig ZXhhbXBsZSwgdGhlIHR3byBlbmRzIGNhbiBkZWNpZGUNCsKgwqAgdGhhdCBCRkQgZnJhbWVzIHRo YXQgaW5kaWNhdGUgYSBzdGF0ZSBjaGFuZ2Ugc2hvdWxkIGJlIGF1dGhlbnRpY2F0ZWQNCsKgwqAg YW5kIGVuYWJsZSBhdXRoZW50aWNhdGlvbiBvbiB0aG9zZSBmcmFtZXMgb25seS7CoCBJZiB0aGUg dHdvIGVuZHMgaGF2ZQ0KwqDCoCBub3QgcHJldmlvdXNseSBuZWdvdGlhdGVkIHdoaWNoIGZyYW1l cyB0aGV5IHdpbGwgdHJhbnNtaXQgb3IgcmVjZWl2ZQ0KwqDCoCB3aXRoIGF1dGhlbnRpY2F0aW9u IGVuYWJsZWQsIHRoZW4gdGhlIEJGRCBzZXNzaW9uIHdpbGwgZmFpbCB0byBjb21lDQrCoMKgIHVw LCBiZWNhdXNlIGF0IGxlYXN0IG9uZSBlbmQgd2lsbCBleHBlY3QgZXZlcnkgZnJhbWUgdG8gYmUN CsKgwqAgYXV0aGVudGljYXRlZC7igJ0NCsKgDQpJdCBpcyBub3QgY2xlYXIgaG93IGRvZXMgdHdv IHBlZXJzIG5lZ290aWF0ZWQ/IFVzaW5nIEEgYml0IGluIHRoZSBCRkQgcGFja2V0IG9yIHRocm91 Z2ggY29uZmlndXJhdGlvbj8gT3IgdGhyb3VnaCBJR1AvQkdQPw0KDQpXZSBoYWQgaW50ZW50aW9u YWxseSBsZWZ0IHRoaXMgdW5zcGVjaWZpZWQgYXMgdGhpcyBpcyBvcnRob2dvbmFsIHRvIHRoZSBp c3N1ZSB0aGF0IHRoZSBkcmFmdCBhZGRyZXNzZXMuIFRoaXMgZmVhdHVyZSBjYW4gYmUgdHJpdmlh bGx5IG5lZ290aWF0ZWQgYnkgdXNpbmcgYSBuZXcgYXV0aCBUTFYgdHlwZS4gSG93ZXZlciwgdGhl IGxhcmdlciBpc3N1ZSBpcyB3aGV0aGVyIHRoZSBjb21tdW5pdHkgaXMgY29tZm9ydGFibGUgd2l0 aCB0aGUgY29yZSBpZGVhIHRoYXQgaXMgYmVpbmcgcHJvcG9zZWQgaGVyZSAtLSBvbiBvbmx5IHVz aW5nIGF1dGhlbnRpY2F0ZWQgQkZEIHBhY2tldHMgd2hlbiB0aGVyZSBpcyBhIHN0YXRlIGNoYW5n ZS4NCg0KMy7CoMKgwqDCoMKgwqAgSSBhbSBub3QgY2xlYXIgd2hhdCBkb2VzIHRoaXMgYmVsb3cg c3RhdGVtZW50IG1lYW4/DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDi gJxJbiBhZGRpdGlvbiwgaXQgc3RhdGVzIHRoYXQgYW4NCsKgwqAgaW1wbGVtZW50YXRpb24gU0hP VUxEIE5PVCBhbGxvdyB0aGUgYXV0aGVudGljYXRpb24gc3RhdGUgdG8gYmUNCsKgwqAgY2hhbmdl ZCBiYXNlZCBvbiB0aGUgcmVjZWlwdCBvZiBhIEJGRCBDb250cm9sIHBhY2tldC7igJ0NCsKgDQoN Ci4uIGFuZCBuZWl0aGVyIGFtIEkuDQoNCkknbGwgd2FpdCBmb3IgQXNoZXNoIHRvIGNsYXJpZnkg dGhpcy4NCg0KQ2hlZXJzLCBNYW5hdg0K From nobody Sun Feb 22 19:20:23 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F0F1A0141 for ; Sun, 22 Feb 2015 19:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 r0L4kMf-3i2F for ; Sun, 22 Feb 2015 19:20:16 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73A1A013B for ; Sun, 22 Feb 2015 19:20:15 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8F91F2AA0F; Mon, 23 Feb 2015 03:20:12 +0000 (GMT) Date: Sun, 22 Feb 2015 19:20:21 -0800 From: Marc Binderberger To: Ashesh Mishra , Manav Bhatia Message-ID: <20150222192021594337.d1f8ac3e@sniff.de> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-13 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 03:20:18 -0000 Hello Ashesh, Manav et al., your draft brings up a nice idea! Is your proposal really a replacement for the existing authentication=20 mechanism? I would think it is not. My guess is it covers the case when a= =20 remote attacker tries bringing down BFD sessions (?). Which is still fine, kind of "better one bird in the hand than two birds in= =20 the bushes" :-) E.g. as Prasad proposes, a man-in-the-middle could filter out the=20 authenticated Down packet and instead replay/fake Up packets and keeps a=20 session Up. Another aspect is an remote attacker could create Down packets, authenticat= ed=20 with a wrong key. If the rate is high enough then the receiver would strugg= le=20 with the load of the authentication check. Effectively a DoS of the=20 authentication check, which would also affect legitimate Down packets. Regards, Marc On Sun, 22 Feb 2015 15:52:08 +0000, Vengada Prasad Govindan (venggovi) wrot= e: > Hello Manav, > One question regarding the (lack of) need for authenticating BFD packets= =20 > when in UP state: >=20 >> 1. Why do we make an assumptions that BFD need no Auth when BFD is= =20 >> in UP or not changing the state? Is that because BFD will be > demuxed= =20 >> with only discr in the packet? >> Yes. >=20 > Is it possible that a replay attack could be made by keeping a link UP wh= en=20 > it should have actually be DOWN. In other words, do we run the risk of no= t=20 > detecting a link failure due to a MiM doing a replay attack? > Please let me know your thoughts. > Thanks > Prasad >=20 > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia > Sent: Thursday, February 19, 2015 6:31 AM > To: Santosh P K > Cc: rtg-bfd@ietf.org > Subject: Re: New BFD Authentication Optimization draft=20 > draft-mahesh-bfd-authentication-00 >=20 > Hi Santosh, >=20 > Thanks for the review. Comments inline. >=20 > On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K wro= te: > Hello Ashesh, > I have few questions on this draft. > =20 > 1. Why do we make an assumptions that BFD need no Auth when BFD is = in=20 > UP or not changing the state? Is that because BFD will be demuxed with on= ly=20 > discr in the packet? >=20 > Yes. > =20 > 2. Draft says > =B4For example, the two ends can decide > that BFD frames that indicate a state change should be authenticated > and enable authentication on those frames only. If the two ends have > not previously negotiated which frames they will transmit or receive > with authentication enabled, then the BFD session will fail to come > up, because at least one end will expect every frame to be > authenticated.=A1 > =20 > It is not clear how does two peers negotiated? Using A bit in the BFD=20 > packet or through configuration? Or through IGP/BGP? >=20 > We had intentionally left this unspecified as this is orthogonal to the= =20 > issue that the draft addresses. This feature can be trivially negotiated = by=20 > using a new auth TLV type. However, the larger issue is whether the=20 > community is comfortable with the core idea that is being proposed here -= -=20 > on only using authenticated BFD packets when there is a state change. >=20 > 3. I am not clear what does this below statement mean? > =B4In addition, it states that an > implementation SHOULD NOT allow the authentication state to be > changed based on the receipt of a BFD Control packet.=A1 > =20 >=20 > .. and neither am I. >=20 > I'll wait for Ashesh to clarify this. >=20 > Cheers, Manav From nobody Sun Feb 22 21:06:03 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8331A01AA for ; Sun, 22 Feb 2015 21:06:02 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 JDiPKxwQ2bnP for ; Sun, 22 Feb 2015 21:06:00 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (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 D0C9B1A01A5 for ; Sun, 22 Feb 2015 21:05:59 -0800 (PST) Received: by pdjz10 with SMTP id z10so22779035pdj.0 for ; Sun, 22 Feb 2015 21:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=fKr4XoAHNOa71d1WenbTISjigOWX+DvVjDG/m2v/gMo=; b=J8x5QVu3UBwAvmDZpNPH6CiU1qNoCbOZMt8OS7Kr21Xb8Ro9kOgw6HseQLBqN+u8I8 PU9ypQHAewReEh6gXCk58r7ANnyPSxmcPOMZKm44LF4qa8FnCdRnXN2AF2lEV7g4G9hR Cpeqh19dLM9MpzpvmPIczSQIC1K5cYA6PB3lQ10ZVK1zx2bZl7++QYvw4186jnB2eNez 3HN+LztPRj2ayl0Bp0PInar8iF86BdWLe/AfMLef7y+SZPAL3+NMnKDWWin6C+tyawcm sgkFyslBkXNeR7Ownefu7fZwRil17VSWYwVw5/SPPWQLb0o2y3v40Iu0SBvGTbrMdCvp DG4g== X-Received: by 10.68.197.133 with SMTP id iu5mr15997277pbc.131.1424667958957; Sun, 22 Feb 2015 21:05:58 -0800 (PST) Received: from ?IPv6:2602:306:cf77:f4c0:1144:dba:794c:3b41? ([2602:306:cf77:f4c0:1144:dba:794c:3b41]) by mx.google.com with ESMTPSA id wq9sm33969277pbc.85.2015.02.22.21.05.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Feb 2015 21:05:58 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_87C4BFF7-9650-4E73-A16E-A8800650A1FA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Mahesh Jethanandani In-Reply-To: <20150222192021594337.d1f8ac3e@sniff.de> Date: Sun, 22 Feb 2015 21:05:56 -0800 Message-Id: <647779E1-6713-42E8-8D5D-8BD0B17C4F0F@gmail.com> References: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> <20150222192021594337.d1f8ac3e@sniff.de> To: Marc Binderberger X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 05:06:02 -0000 --Apple-Mail=_87C4BFF7-9650-4E73-A16E-A8800650A1FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 22, 2015, at 7:20 PM, Marc Binderberger wrote: >=20 > Hello Ashesh, Manav et al., >=20 > your draft brings up a nice idea! >=20 > Is your proposal really a replacement for the existing authentication=20= > mechanism? I would think it is not. My guess is it covers the case = when a=20 > remote attacker tries bringing down BFD sessions (?). It is a proposal to optimize the current authentication mechanism, = specially because the current mechanism has a significant impact on the = scale of authenticated BFD sessions. >=20 > Which is still fine, kind of "better one bird in the hand than two = birds in=20 > the bushes" :-) >=20 >=20 > E.g. as Prasad proposes, a man-in-the-middle could filter out the=20 > authenticated Down packet and instead replay/fake Up packets and keeps = a=20 > session Up. Yes, that is a possibility. But does that not require a fair amount of = control over the box(es) to be to selectively be able to drop packets. = With that kind of compromised boxes, more harm can be done than keeping = a BFD session up. Anyway, we have a proposal (not in the -00 draft), to every so often = send/receive an authenticated UP packet. It can however extend the time = period of detecting the failure. >=20 > Another aspect is an remote attacker could create Down packets, = authenticated=20 > with a wrong key. If the rate is high enough then the receiver would = struggle=20 > with the load of the authentication check. Effectively a DoS of the=20 > authentication check, which would also affect legitimate Down packets. That problem is no different than todays situation where a flood of = badly authenticated frames can overwhelm the system. >=20 >=20 > Regards, Marc >=20 >=20 >=20 > On Sun, 22 Feb 2015 15:52:08 +0000, Vengada Prasad Govindan (venggovi) = wrote: >> Hello Manav, >> One question regarding the (lack of) need for authenticating BFD = packets=20 >> when in UP state: >>=20 >>> 1. Why do we make an assumptions that BFD need no Auth when = BFD is=20 >>> in UP or not changing the state? Is that because BFD will be > = demuxed=20 >>> with only discr in the packet? >>> Yes. >>=20 >> Is it possible that a replay attack could be made by keeping a link = UP when=20 >> it should have actually be DOWN. In other words, do we run the risk = of not=20 >> detecting a link failure due to a MiM doing a replay attack? >> Please let me know your thoughts. >> Thanks >> Prasad >>=20 >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav = Bhatia >> Sent: Thursday, February 19, 2015 6:31 AM >> To: Santosh P K >> Cc: rtg-bfd@ietf.org >> Subject: Re: New BFD Authentication Optimization draft=20 >> draft-mahesh-bfd-authentication-00 >>=20 >> Hi Santosh, >>=20 >> Thanks for the review. Comments inline. >>=20 >> On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K = wrote: >> Hello Ashesh, >> I have few questions on this draft. >>=20 >> 1. Why do we make an assumptions that BFD need no Auth when BFD = is in=20 >> UP or not changing the state? Is that because BFD will be demuxed = with only=20 >> discr in the packet? >>=20 >> Yes. >>=20 >> 2. Draft says >> =E2=80=9CFor example, the two ends can decide >> that BFD frames that indicate a state change should be = authenticated >> and enable authentication on those frames only. If the two ends = have >> not previously negotiated which frames they will transmit or = receive >> with authentication enabled, then the BFD session will fail to come >> up, because at least one end will expect every frame to be >> authenticated.=E2=80=9D >>=20 >> It is not clear how does two peers negotiated? Using A bit in the BFD=20= >> packet or through configuration? Or through IGP/BGP? >>=20 >> We had intentionally left this unspecified as this is orthogonal to = the=20 >> issue that the draft addresses. This feature can be trivially = negotiated by=20 >> using a new auth TLV type. However, the larger issue is whether the=20= >> community is comfortable with the core idea that is being proposed = here --=20 >> on only using authenticated BFD packets when there is a state change. >>=20 >> 3. I am not clear what does this below statement mean? >> =E2=80=9CIn addition, it states that an >> implementation SHOULD NOT allow the authentication state to be >> changed based on the receipt of a BFD Control packet.=E2=80=9D >>=20 >>=20 >> .. and neither am I. >>=20 >> I'll wait for Ashesh to clarify this. >>=20 >> Cheers, Manav >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_87C4BFF7-9650-4E73-A16E-A8800650A1FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 22, 2015, at 7:20 PM, Marc Binderberger <marc@sniff.de> = wrote:

Hello = Ashesh, Manav et al.,

your draft brings up = a nice idea!

Is your proposal really a = replacement for the existing authentication
mechanism? =  I would think it is not.  My guess is it covers the case when = a
remote attacker tries bringing down BFD sessions = (?).

It is a = proposal to optimize the current authentication mechanism, specially = because the current mechanism has a significant impact on the scale of = authenticated BFD sessions.


Which is still = fine, kind of "better one bird in the hand than two birds in
the bushes" :-)


E.g. as Prasad proposes, a man-in-the-middle could filter out = the
authenticated Down packet and instead replay/fake Up = packets and keeps a
session Up.

Yes, that is a = possibility. But does that not require a fair amount of control over the = box(es) to be to selectively be able to drop packets. With that kind of = compromised boxes, more harm can be done than keeping a BFD session = up.

Anyway, we have a proposal (not = in the -00 draft), to every so often send/receive an authenticated UP = packet. It can however extend the time period of detecting the = failure.


Another aspect is an remote = attacker could create Down packets, authenticated
with a = wrong key. If the rate is high enough then the receiver would struggle =
with the load of the authentication check. Effectively a = DoS of the
authentication check, which would also affect = legitimate Down packets.

That problem is no different than todays situation = where a flood of badly authenticated frames can overwhelm the = system.



Regards, Marc



On Sun, 22 Feb 2015 15:52:08 = +0000, Vengada Prasad Govindan (venggovi) wrote:
Hello Manav,
One question = regarding the (lack of) need for authenticating BFD packets
when in UP state:

1.       Why do = we make an assumptions that BFD need no Auth when BFD is
in= UP or not changing the state? Is that because BFD will be > demuxed =
with only discr in the packet?
Yes.

Is it possible that a replay = attack could be made by keeping a link UP when
it should = have actually be DOWN. In other words, do we run the risk of not
detecting a link failure due to a MiM doing a replay = attack?
Please let me know your thoughts.
Thanks
Prasad

From: = Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav = Bhatia
Sent: Thursday, February 19, 2015 6:31 AM
To: Santosh P K
Cc: rtg-bfd@ietf.org
Subject: Re: New BFD Authentication Optimization draft
draft-mahesh-bfd-authentication-00

Hi Santosh,

Thanks for the = review. Comments inline.

On Wed, Feb 18, = 2015 at 11:36 AM, Santosh P K <santoshpk@juniper.net> wrote:
Hello = Ashesh,
   I have few questions on this = draft.

1. =       Why do we make an assumptions that = BFD need no Auth when BFD is in
UP or not changing the = state? Is that because BFD will be demuxed with only
discr = in the packet?

Yes.

2.       Draft says
     =E2=80=9CFor example, the two = ends can decide
  that BFD frames that indicate = a state change should be authenticated
  and = enable authentication on those frames only.  If the two ends = have
  not previously negotiated which frames = they will transmit or receive
  with = authentication enabled, then the BFD session will fail to come
  up, because at least one end will expect every = frame to be
  authenticated.=E2=80=9D

It is not clear how does two peers negotiated? = Using A bit in the BFD
packet or through configuration? = Or through IGP/BGP?

We had intentionally = left this unspecified as this is orthogonal to the
issue = that the draft addresses. This feature can be trivially negotiated by =
using a new auth TLV type. However, the larger issue is = whether the
community is comfortable with the core idea = that is being proposed here --
on only using = authenticated BFD packets when there is a state change.

3.       I am not clear what = does this below statement mean?
=             &n= bsp;      =E2=80=9CIn addition, it states = that an
  implementation SHOULD NOT allow the = authentication state to be
  changed based on = the receipt of a BFD Control packet.=E2=80=9D


.. and neither am I.

I'll wait for Ashesh to clarify this.

Cheers, Manav


Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_87C4BFF7-9650-4E73-A16E-A8800650A1FA-- From nobody Sun Feb 22 23:21:54 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422CC1A0264 for ; Sun, 22 Feb 2015 23:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=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 HUqMGPzmiDGu for ; Sun, 22 Feb 2015 23:21:50 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B281A0267 for ; Sun, 22 Feb 2015 23:21:50 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 681F62AA0F; Mon, 23 Feb 2015 07:21:47 +0000 (GMT) Date: Sun, 22 Feb 2015 23:21:56 -0800 From: Marc Binderberger To: Mahesh Jethanandani Message-ID: <20150222232156731100.09ac0952@sniff.de> In-Reply-To: <647779E1-6713-42E8-8D5D-8BD0B17C4F0F@gmail.com> References: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> <20150222192021594337.d1f8ac3e@sniff.de> <647779E1-6713-42E8-8D5D-8BD0B17C4F0F@gmail.com> Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-13 Content-Transfer-Encoding: quoted-printable X-Mailer: GyazMail version 1.5.16 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 07:21:52 -0000 Hello Mahesh, >> Is your proposal really a replacement for the existing authentication=20 >> mechanism? I would think it is not. My guess is it covers the case whe= n=20 >> a=20 >> remote attacker tries bringing down BFD sessions (?). >=20 > It is a proposal to optimize the current authentication mechanism,=20 > specially because the current mechanism has a significant impact on the= =20 > scale of authenticated BFD sessions. Okay. As I said: I don't think this is an optimization that otherwise=20 delivers the same as an always-authenticate. This should somehow made clear= =20 in the document. > Yes, that is a possibility. But does that not require a fair amount of=20 > control over the box(es) to be to selectively be able to drop packets. Wi= th=20 > that kind of compromised boxes, more harm can be done than keeping a BFD= =20 > session up. I agree but it should be mentioned that your proposal is not covering all t= he=20 aspects an always-authenticate setup can handle (depending on the=20 authentication procedure details). =20 > Anyway, we have a proposal (not in the -00 draft), to every so often=20 > send/receive an authenticated UP packet. It can however extend the time= =20 > period of detecting the failure. Sure, that would be an idea. > That problem is no different than todays situation where a flood of badly= =20 > authenticated frames can overwhelm the system. ah well - then why bother at all? :-) If I can bring down the systems because you cannot prevent an attacker from= =20 sending authenticated packets to your BFD peers then you have no real=20 solution. And if you start arguing about infrastructure ACL and such to blo= ck=20 such attacks then why would you need authentication? Yes, there is still advantage with your proposal (IMHO) for certain=20 scenarios. The draft should be more explicit what you can solve and what yo= u=20 cannot. Regards, Marc >> On Sun, 22 Feb 2015 15:52:08 +0000, Vengada Prasad Govindan (venggovi)= =20 >> wrote: >>> Hello Manav, >>> One question regarding the (lack of) need for authenticating BFD packet= s=20 >>> when in UP state: >>>=20 >>>> 1. Why do we make an assumptions that BFD need no Auth when BFD = is=20 >>>> in UP or not changing the state? Is that because BFD will be > demuxed= =20 >>>> with only discr in the packet? >>>> Yes. >>>=20 >>> Is it possible that a replay attack could be made by keeping a link UP= =20 >>> when=20 >>> it should have actually be DOWN. In other words, do we run the risk of= =20 >>> not=20 >>> detecting a link failure due to a MiM doing a replay attack? >>> Please let me know your thoughts. >>> Thanks >>> Prasad >>>=20 >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhat= ia >>> Sent: Thursday, February 19, 2015 6:31 AM >>> To: Santosh P K >>> Cc: rtg-bfd@ietf.org >>> Subject: Re: New BFD Authentication Optimization draft=20 >>> draft-mahesh-bfd-authentication-00 >>>=20 >>> Hi Santosh, >>>=20 >>> Thanks for the review. Comments inline. >>>=20 >>> On Wed, Feb 18, 2015 at 11:36 AM, Santosh P K = =20 >>> wrote: >>> Hello Ashesh, >>> I have few questions on this draft. >>>=20 >>> 1. Why do we make an assumptions that BFD need no Auth when BFD i= s=20 >>> in=20 >>> UP or not changing the state? Is that because BFD will be demuxed with= =20 >>> only=20 >>> discr in the packet? >>>=20 >>> Yes. >>>=20 >>> 2. Draft says >>> =B4For example, the two ends can decide >>> that BFD frames that indicate a state change should be authenticated >>> and enable authentication on those frames only. If the two ends have >>> not previously negotiated which frames they will transmit or receive >>> with authentication enabled, then the BFD session will fail to come >>> up, because at least one end will expect every frame to be >>> authenticated.=A1 >>>=20 >>> It is not clear how does two peers negotiated? Using A bit in the BFD= =20 >>> packet or through configuration? Or through IGP/BGP? >>>=20 >>> We had intentionally left this unspecified as this is orthogonal to the= =20 >>> issue that the draft addresses. This feature can be trivially negotiate= d=20 >>> by=20 >>> using a new auth TLV type. However, the larger issue is whether the=20 >>> community is comfortable with the core idea that is being proposed here= =20 >>> --=20 >>> on only using authenticated BFD packets when there is a state change. >>>=20 >>> 3. I am not clear what does this below statement mean? >>> =B4In addition, it states that an >>> implementation SHOULD NOT allow the authentication state to be >>> changed based on the receipt of a BFD Control packet.=A1 >>>=20 >>>=20 >>> .. and neither am I. >>>=20 >>> I'll wait for Ashesh to clarify this. >>>=20 >>> Cheers, Manav >>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 From nobody Mon Feb 23 05:05:10 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C681A1A8F for ; Mon, 23 Feb 2015 05:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 H8bSOAUu9Qd6 for ; Mon, 23 Feb 2015 05:05:00 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0134.outbound.protection.outlook.com [65.55.169.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB501A03A1 for ; Mon, 23 Feb 2015 05:04:59 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 13:04:56 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0093.004; Mon, 23 Feb 2015 13:04:56 +0000 From: Santosh P K To: Mahesh Jethanandani , Marc Binderberger Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tbsQZROSH/9kaR7CvCt+VUdZz18BzggAE/k4CABa/gAIAAwEmAgAAdgACAAILFkA== Date: Mon, 23 Feb 2015 13:04:55 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D41A79E60@xmb-rcd-x15.cisco.com> <20150222192021594337.d1f8ac3e@sniff.de> <647779E1-6713-42E8-8D5D-8BD0B17C4F0F@gmail.com> In-Reply-To: <647779E1-6713-42E8-8D5D-8BD0B17C4F0F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.11] authentication-results: spf=none (sender IP is ) smtp.mailfrom=santoshpk@juniper.net; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 0496DF6962 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(52314003)(199003)(24454002)(51914003)(377454003)(93886004)(46102003)(62966003)(76576001)(101416001)(99286002)(50986999)(74316001)(77156002)(230783001)(66066001)(64706001)(68736005)(77096005)(102836002)(87936001)(2656002)(19580395003)(19580405001)(97736003)(40100003)(122556002)(76176999)(105586002)(33656002)(106116001)(106356001)(2950100001)(2900100001)(92566002)(86362001)(54356999)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.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) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2015 13:04:55.7333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB824 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 13:05:07 -0000 TWFoZXNoIGFuZCBNYW5hdiwNCiAgIA0KDQo+IEFueXdheSwgd2UgaGF2ZSBhIHByb3Bvc2FsIChu b3QgaW4gdGhlIC0wMCBkcmFmdCksIHRvIGV2ZXJ5IHNvIG9mdGVuIHNlbmQvcmVjZWl2ZSBhbiBh dXRoZW50aWNhdGVkIFVQIHBhY2tldC4gSXQgY2FuIGhvd2V2ZXIgZXh0ZW5kIHRoZSB0aW1lIHBl cmlvZCBvZiBkZXRlY3RpbmcgdGhlIGZhaWx1cmUuDQoNCkkgdGhpbmsgd2UgbmVlZCB0byBkbyB0 aGlzIHJhbmRvbWx5IGZvciBmZXcgdGltZXMgdG8gZ2V0IHJpZCBvZiBhbnkgYXR0YWNrIHdoZW4g QkZEIHNlc3Npb24gaXMgVVAuIENvbnNpZGVyIGEgY2FzZSB3aGVyZSBCRkQgY2FuIHJ1biBhdCBp bnRlcnZhbCBvZiAgMy4zIG1zIG9ubHkgaWYgIG5vIGF1dGhlbnRpY2F0aW9uIGlzIGVuYWJsZWQu ICBTbyB3aXRoIGluaXRpYWwgc2xvdyBwYWNrZXRzICg+MSBzZWMgd2hlbiBub3QgVVApIEkgd2ls bCBiZSBhdXRoZW50aWNhdGluZyB0aGUgcGFja2V0cyBhbmQgd2hlbiBzZXNzaW9uIGdvZXMgdG8g VVAgc3RhdGUgd2l0aCBhZ2dyZXNzaXZlIGludGVydmFsIEJGRCB3aWxsIGdvIHdpdGhvdXQgQVVU SC4gSWYgSSB3YW50IHRvIHNlbmQgQkZEIHBhY2tldCB3aXRoIEFVVEggdGhlbiBJIG1pZ2h0IG5l ZWQgdG8gY2hhbmdlIHRoZSBpbnRlcnZhbCBmaXJzdD8gDQoNClNlY29uZGx5IEkgdGhpbmsgd2Ug d2lsbCB0ZXJtaW5hdGUgQXV0aCBvbmNlIHRoZSBCRkQgc2Vzc2lvbiBnb2VzIHRvIFVQIHN0YXRl IGxvY2FsbHkgYW5kIEkgYXNzdW1lIHNvbWUgY29uZmlndXJhdGlvbiB3aWxsIGRlY2lkZSBob3cg cmFuZG9tbHkgdG8gc2VuZCBCRkQgVVAgcGFja2V0cyB3aXRoIEFVVEggc2V0LiBOb3cgYXNzdW1l IHRoYXQgQkZEIG9uIG9uZSBlbmQgaXMgc3R1Y2sgaW4gSU5JVCBzdGF0ZSBkdWUgdG8gcGFja2V0 IGxvc3MgKDIgcGFja2V0IGxvc3MgaWYgbXVsdGlwbGUgaXMgMyksIHNvIGZvciAyIHNlY29uZHMg b25lIHNpZGUgd2hpY2ggaGFzIGFscmVhZHkgcmVhY2ggVVAgc3RhdGUgbWlnaHQgaGF2ZSB0ZXJt aW5hdGVkIEFVVEggYW5kIG90aGVyIHNpZGUgaW4gSU5JVCBtaWdodCBoYXZlIG5vdC4gVGhpcyBj b3VsZCBsZWFkIHRvIHRpbWUgbWlzbWF0Y2ggb24gd2hlbiB0byByYW5kb21seSBzZW5kIFVQIHBh Y2tldHMgd2l0aCBBdXRoIHNldC4gSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgcHJvcGVyIGd1aWRl bGluZXMgb24gd2hlbiB0byB0ZXJtaW5hdGUgdGhlIEFVVEggYW5kIHdoZW4gdG8gc3RhcnQgYWdh aW4gbWF5IGJlIHdpdGggUC9GIG5lZ290aWF0aW9uPyANCg0KVGhhbmtzDQpTYW50b3NoIFAgSyAN Cg0KDQpGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgTWFoZXNoIEpldGhhbmFuZGFuaQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMywg MjAxNSAxMDozNiBBTQ0KVG86IE1hcmMgQmluZGVyYmVyZ2VyDQpDYzogcnRnLWJmZEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IE5ldyBCRkQgQXV0aGVudGljYXRpb24gT3B0aW1pemF0aW9uIGRyYWZ0 IGRyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRpb24tMDANCg0KDQpPbiBGZWIgMjIsIDIwMTUs IGF0IDc6MjAgUE0sIE1hcmMgQmluZGVyYmVyZ2VyIDxtYXJjQHNuaWZmLmRlPiB3cm90ZToNCg0K SGVsbG8gQXNoZXNoLCBNYW5hdiBldCBhbC4sDQoNCnlvdXIgZHJhZnQgYnJpbmdzIHVwIGEgbmlj ZSBpZGVhIQ0KDQpJcyB5b3VyIHByb3Bvc2FsIHJlYWxseSBhIHJlcGxhY2VtZW50IGZvciB0aGUg ZXhpc3RpbmcgYXV0aGVudGljYXRpb24gDQptZWNoYW5pc20/IMKgSSB3b3VsZCB0aGluayBpdCBp cyBub3QuIMKgTXkgZ3Vlc3MgaXMgaXQgY292ZXJzIHRoZSBjYXNlIHdoZW4gYSANCnJlbW90ZSBh dHRhY2tlciB0cmllcyBicmluZ2luZyBkb3duIEJGRCBzZXNzaW9ucyAoPykuDQoNCkl0IGlzIGEg cHJvcG9zYWwgdG8gb3B0aW1pemUgdGhlIGN1cnJlbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNt LCBzcGVjaWFsbHkgYmVjYXVzZSB0aGUgY3VycmVudCBtZWNoYW5pc20gaGFzIGEgc2lnbmlmaWNh bnQgaW1wYWN0IG9uIHRoZSBzY2FsZSBvZiBhdXRoZW50aWNhdGVkIEJGRCBzZXNzaW9ucy4NCg0K DQoNCldoaWNoIGlzIHN0aWxsIGZpbmUsIGtpbmQgb2YgImJldHRlciBvbmUgYmlyZCBpbiB0aGUg aGFuZCB0aGFuIHR3byBiaXJkcyBpbiANCnRoZSBidXNoZXMiIDotKQ0KDQoNCkUuZy4gYXMgUHJh c2FkIHByb3Bvc2VzLCBhIG1hbi1pbi10aGUtbWlkZGxlIGNvdWxkIGZpbHRlciBvdXQgdGhlIA0K YXV0aGVudGljYXRlZCBEb3duIHBhY2tldCBhbmQgaW5zdGVhZCByZXBsYXkvZmFrZSBVcCBwYWNr ZXRzIGFuZCBrZWVwcyBhIA0Kc2Vzc2lvbiBVcC4NCg0KWWVzLCB0aGF0IGlzIGEgcG9zc2liaWxp dHkuIEJ1dCBkb2VzIHRoYXQgbm90IHJlcXVpcmUgYSBmYWlyIGFtb3VudCBvZiBjb250cm9sIG92 ZXIgdGhlIGJveChlcykgdG8gYmUgdG8gc2VsZWN0aXZlbHkgYmUgYWJsZSB0byBkcm9wIHBhY2tl dHMuIFdpdGggdGhhdCBraW5kIG9mIGNvbXByb21pc2VkIGJveGVzLCBtb3JlIGhhcm0gY2FuIGJl IGRvbmUgdGhhbiBrZWVwaW5nIGEgQkZEIHNlc3Npb24gdXAuDQoNCkFueXdheSwgd2UgaGF2ZSBh IHByb3Bvc2FsIChub3QgaW4gdGhlIC0wMCBkcmFmdCksIHRvIGV2ZXJ5IHNvIG9mdGVuIHNlbmQv cmVjZWl2ZSBhbiBhdXRoZW50aWNhdGVkIFVQIHBhY2tldC4gSXQgY2FuIGhvd2V2ZXIgZXh0ZW5k IHRoZSB0aW1lIHBlcmlvZCBvZiBkZXRlY3RpbmcgdGhlIGZhaWx1cmUuDQoNCg0KDQpBbm90aGVy IGFzcGVjdCBpcyBhbiByZW1vdGUgYXR0YWNrZXIgY291bGQgY3JlYXRlIERvd24gcGFja2V0cywg YXV0aGVudGljYXRlZCANCndpdGggYSB3cm9uZyBrZXkuIElmIHRoZSByYXRlIGlzIGhpZ2ggZW5v dWdoIHRoZW4gdGhlIHJlY2VpdmVyIHdvdWxkIHN0cnVnZ2xlIA0Kd2l0aCB0aGUgbG9hZCBvZiB0 aGUgYXV0aGVudGljYXRpb24gY2hlY2suIEVmZmVjdGl2ZWx5IGEgRG9TIG9mIHRoZSANCmF1dGhl bnRpY2F0aW9uIGNoZWNrLCB3aGljaCB3b3VsZCBhbHNvIGFmZmVjdCBsZWdpdGltYXRlIERvd24g cGFja2V0cy4NCg0KVGhhdCBwcm9ibGVtIGlzIG5vIGRpZmZlcmVudCB0aGFuIHRvZGF5cyBzaXR1 YXRpb24gd2hlcmUgYSBmbG9vZCBvZiBiYWRseSBhdXRoZW50aWNhdGVkIGZyYW1lcyBjYW4gb3Zl cndoZWxtIHRoZSBzeXN0ZW0uDQoNCg0KDQoNClJlZ2FyZHMsIE1hcmMNCg0KDQoNCk9uIFN1biwg MjIgRmViIDIwMTUgMTU6NTI6MDggKzAwMDAsIFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5n Z292aSkgd3JvdGU6DQoNCkhlbGxvIE1hbmF2LA0KT25lIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUg KGxhY2sgb2YpIG5lZWQgZm9yIGF1dGhlbnRpY2F0aW5nIEJGRCBwYWNrZXRzIA0Kd2hlbiBpbiBV UCBzdGF0ZToNCg0KDQoxLiDCoMKgwqDCoMKgwqBXaHkgZG8gd2UgbWFrZSBhbiBhc3N1bXB0aW9u cyB0aGF0IEJGRCBuZWVkIG5vIEF1dGggd2hlbiBCRkQgaXMgDQppbiBVUCBvciBub3QgY2hhbmdp bmcgdGhlIHN0YXRlPyBJcyB0aGF0IGJlY2F1c2UgQkZEIHdpbGwgYmUgPiBkZW11eGVkIA0Kd2l0 aCBvbmx5IGRpc2NyIGluIHRoZSBwYWNrZXQ/DQpZZXMuDQoNCklzIGl0IHBvc3NpYmxlIHRoYXQg YSByZXBsYXkgYXR0YWNrIGNvdWxkIGJlIG1hZGUgYnkga2VlcGluZyBhIGxpbmsgVVAgd2hlbiAN Cml0IHNob3VsZCBoYXZlIGFjdHVhbGx5IGJlIERPV04uIEluIG90aGVyIHdvcmRzLCBkbyB3ZSBy dW4gdGhlIHJpc2sgb2Ygbm90IA0KZGV0ZWN0aW5nIGEgbGluayBmYWlsdXJlIGR1ZSB0byBhIE1p TSBkb2luZyBhIHJlcGxheSBhdHRhY2s/DQpQbGVhc2UgbGV0IG1lIGtub3cgeW91ciB0aG91Z2h0 cy4NClRoYW5rcw0KUHJhc2FkDQoNCkZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWENClNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAxOSwgMjAxNSA2OjMxIEFNDQpUbzogU2FudG9zaCBQIEsNCkNjOiBydGctYmZkQGll dGYub3JnDQpTdWJqZWN0OiBSZTogTmV3IEJGRCBBdXRoZW50aWNhdGlvbiBPcHRpbWl6YXRpb24g ZHJhZnQgDQpkcmFmdC1tYWhlc2gtYmZkLWF1dGhlbnRpY2F0aW9uLTAwDQoNCkhpIFNhbnRvc2gs DQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gQ29tbWVudHMgaW5saW5lLg0KDQpPbiBXZWQsIEZl YiAxOCwgMjAxNSBhdCAxMTozNiBBTSwgU2FudG9zaCBQIEsgPHNhbnRvc2hwa0BqdW5pcGVyLm5l dD4gd3JvdGU6DQpIZWxsbyBBc2hlc2gsDQrCoMKgwqBJIGhhdmUgZmV3IHF1ZXN0aW9ucyBvbiB0 aGlzIGRyYWZ0Lg0KDQoxLiDCoMKgwqDCoMKgwqBXaHkgZG8gd2UgbWFrZSBhbiBhc3N1bXB0aW9u cyB0aGF0IEJGRCBuZWVkIG5vIEF1dGggd2hlbiBCRkQgaXMgaW4gDQpVUCBvciBub3QgY2hhbmdp bmcgdGhlIHN0YXRlPyBJcyB0aGF0IGJlY2F1c2UgQkZEIHdpbGwgYmUgZGVtdXhlZCB3aXRoIG9u bHkgDQpkaXNjciBpbiB0aGUgcGFja2V0Pw0KDQpZZXMuDQoNCjIuIMKgwqDCoMKgwqDCoERyYWZ0 IHNheXMNCsKgwqDCoMKgwqDigJxGb3IgZXhhbXBsZSwgdGhlIHR3byBlbmRzIGNhbiBkZWNpZGUN CsKgwqB0aGF0IEJGRCBmcmFtZXMgdGhhdCBpbmRpY2F0ZSBhIHN0YXRlIGNoYW5nZSBzaG91bGQg YmUgYXV0aGVudGljYXRlZA0KwqDCoGFuZCBlbmFibGUgYXV0aGVudGljYXRpb24gb24gdGhvc2Ug ZnJhbWVzIG9ubHkuIMKgSWYgdGhlIHR3byBlbmRzIGhhdmUNCsKgwqBub3QgcHJldmlvdXNseSBu ZWdvdGlhdGVkIHdoaWNoIGZyYW1lcyB0aGV5IHdpbGwgdHJhbnNtaXQgb3IgcmVjZWl2ZQ0KwqDC oHdpdGggYXV0aGVudGljYXRpb24gZW5hYmxlZCwgdGhlbiB0aGUgQkZEIHNlc3Npb24gd2lsbCBm YWlsIHRvIGNvbWUNCsKgwqB1cCwgYmVjYXVzZSBhdCBsZWFzdCBvbmUgZW5kIHdpbGwgZXhwZWN0 IGV2ZXJ5IGZyYW1lIHRvIGJlDQrCoMKgYXV0aGVudGljYXRlZC7igJ0NCg0KSXQgaXMgbm90IGNs ZWFyIGhvdyBkb2VzIHR3byBwZWVycyBuZWdvdGlhdGVkPyBVc2luZyBBIGJpdCBpbiB0aGUgQkZE IA0KcGFja2V0IG9yIHRocm91Z2ggY29uZmlndXJhdGlvbj8gT3IgdGhyb3VnaCBJR1AvQkdQPw0K DQpXZSBoYWQgaW50ZW50aW9uYWxseSBsZWZ0IHRoaXMgdW5zcGVjaWZpZWQgYXMgdGhpcyBpcyBv cnRob2dvbmFsIHRvIHRoZSANCmlzc3VlIHRoYXQgdGhlIGRyYWZ0IGFkZHJlc3Nlcy4gVGhpcyBm ZWF0dXJlIGNhbiBiZSB0cml2aWFsbHkgbmVnb3RpYXRlZCBieSANCnVzaW5nIGEgbmV3IGF1dGgg VExWIHR5cGUuIEhvd2V2ZXIsIHRoZSBsYXJnZXIgaXNzdWUgaXMgd2hldGhlciB0aGUgDQpjb21t dW5pdHkgaXMgY29tZm9ydGFibGUgd2l0aCB0aGUgY29yZSBpZGVhIHRoYXQgaXMgYmVpbmcgcHJv cG9zZWQgaGVyZSAtLSANCm9uIG9ubHkgdXNpbmcgYXV0aGVudGljYXRlZCBCRkQgcGFja2V0cyB3 aGVuIHRoZXJlIGlzIGEgc3RhdGUgY2hhbmdlLg0KDQozLiDCoMKgwqDCoMKgwqBJIGFtIG5vdCBj bGVhciB3aGF0IGRvZXMgdGhpcyBiZWxvdyBzdGF0ZW1lbnQgbWVhbj8NCsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg4oCcSW4gYWRkaXRpb24sIGl0IHN0YXRlcyB0aGF0IGFu DQrCoMKgaW1wbGVtZW50YXRpb24gU0hPVUxEIE5PVCBhbGxvdyB0aGUgYXV0aGVudGljYXRpb24g c3RhdGUgdG8gYmUNCsKgwqBjaGFuZ2VkIGJhc2VkIG9uIHRoZSByZWNlaXB0IG9mIGEgQkZEIENv bnRyb2wgcGFja2V0LuKAnQ0KDQoNCi4uIGFuZCBuZWl0aGVyIGFtIEkuDQoNCkknbGwgd2FpdCBm b3IgQXNoZXNoIHRvIGNsYXJpZnkgdGhpcy4NCg0KQ2hlZXJzLCBNYW5hdg0KDQoNCk1haGVzaCBK ZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQoNCg0KDQoNCg== From nobody Tue Feb 24 13:13:58 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6191A8948 for ; Tue, 24 Feb 2015 13:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 qLgVPKA6ERfz for ; Tue, 24 Feb 2015 13:13:54 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 60B501A8931 for ; Tue, 24 Feb 2015 13:13:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 178C3C212; Tue, 24 Feb 2015 16:13:29 -0500 (EST) Date: Tue, 24 Feb 2015 16:13:29 -0500 From: Jeffrey Haas To: Ashesh Mishra Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Message-ID: <20150224211328.GF25639@pfrc> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:13:55 -0000 On Fri, Feb 13, 2015 at 10:31:43AM -0800, Ashesh Mishra wrote: > Hi BFD Experts, > The 00 version of BFD Authentication Optimization draft is now online: > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > The draft describes method for selectively authenticating certain BFD frames to avoid computational overhead. I have perhaps a rather basic question which I'd been thinking on since it was said this draft may be coming: Is there any reason we couldn't simply use the non-meticulous versions of the keyed authentication and rely on caching? Essentially, in stable state BFD packets will be the same thing over and over again. As long as the sequence number isn't increased, knowing that a given packet has passed authentication previously is sufficient if it's the same packet. Given how small BFD packets are, cache the entire packet? Is the memory at that level of preciousness in the hardware implementations? Basically, in RFC 5880, section 6.8.6, at the procedural component that says "MUST be authenticated", once this step has completed for this sequence number and caching is determined to be okay, store the packet. When the sequence number is seen a second time and the authentication contents are the same, simply compare the bytes of the packet to the cache. I suspect I'm about to get a very strong reality check here. :-) -- Jeff From nobody Tue Feb 24 13:43:37 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78B1A89E1 for ; Tue, 24 Feb 2015 13:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WGfqHXsVVg0e for ; Tue, 24 Feb 2015 13:43:35 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D42111A89FE for ; Tue, 24 Feb 2015 13:43:29 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8EE8CC212; Tue, 24 Feb 2015 16:43:29 -0500 (EST) Date: Tue, 24 Feb 2015 16:43:29 -0500 From: Jeffrey Haas To: Santosh P K Subject: Re: FW: New Version Notification for draft-spallagatti-bfd-multipoint-active-tail-00.txt Message-ID: <20150224214329.GH25639@pfrc> References: <20150203060639.21858.88568.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:43:36 -0000 Santosh, thanks for taking on this work and doing a nice refactoring of the active tail functionality from the core multipoint document. What I would like to recommend for the Working Group with regards to this document based on prior discussion is the following: - Make the status Experimental. Given the lack of implementations of this functionality vs. active development in what is now the core document it seems a good match for it. - Permit the active-tail document to advance simultaneously with the base document if it's considered ready. What are your thoughts? -- Jeff On Tue, Feb 03, 2015 at 06:11:58AM +0000, Santosh P K wrote: > Hello BFD WG, > A new draft for BFD multipoint active tail has been published. Please review and give me your comments on this draft. > > Thanks > Santosh P K > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, February 03, 2015 11:37 AM > > To: David Ward; Dave Katz; Santosh P K; Santosh P K; Dave Ward; Dave Katz > > Subject: New Version Notification for draft-spallagatti-bfd-multipoint-active- > > tail-00.txt > > > > > > A new version of I-D, draft-spallagatti-bfd-multipoint-active-tail-00.txt > > has been successfully submitted by Santosh Pallagatti and posted to the IETF > > repository. > > > > Name: draft-spallagatti-bfd-multipoint-active-tail > > Revision: 00 > > Title: BFD Multipoint Active Tails. > > Document date: 2015-02-02 > > Group: Individual Submission > > Pages: 16 > > URL: http://www.ietf.org/internet-drafts/draft-spallagatti-bfd- > > multipoint-active-tail-00.txt > > Status: https://datatracker.ietf.org/doc/draft-spallagatti-bfd-multipoint- > > active-tail/ > > Htmlized: http://tools.ietf.org/html/draft-spallagatti-bfd-multipoint- > > active-tail-00 > > > > > > Abstract: > > This document describes active tail extensions to the Bidirectional > > Forwarding Detection (BFD) protocol for multipoint and multicast > > networks. Comments on this draft should be directed to rtg- > > bfd@ietf.org. > > > > > > > > > > > > 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 > From nobody Tue Feb 24 15:05:28 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0D91A9069 for ; Tue, 24 Feb 2015 15:05:26 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 znVF5zfza9QC for ; Tue, 24 Feb 2015 15:05:25 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 E668E1A0070 for ; Tue, 24 Feb 2015 15:05:24 -0800 (PST) Received: by mail-oi0-f48.google.com with SMTP id a3so152828oib.7 for ; Tue, 24 Feb 2015 15:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4mBwrZb9540c1qLHQsZFZVAkhTdikHsn71sL9uz5E6Q=; b=akFTAviZb1qLgsmmZHouDuLBo6scvD6/nMy3DpnHzYbWZItqo+qkMPxt9sqo6Eo+Ze evmbZW0d2bDONLGox+H8XIGtRUEvgil6VnjMY5wr317HU+t5lTm1UWdKujNDdVu5Hh8y SgXxHOULt+7dKnbnQpHP8e9GeH1XenkmA5mLBJAvEk3BjsJPvNtT2twPMrZagWaZPMft M53b3Ko4smDVWWN+aaVwDZ0/wgHOVR3fKqydqFmDZ0JdtEisIbTLBBkMxQDJOFQmGhrB /9ZaSc2gMSZljZPVvSCR+9ygn+fiNt9Y05cjzTWnCX599PMz5hr0XxcqzljwdVKx6i2Y qcMg== MIME-Version: 1.0 X-Received: by 10.182.117.226 with SMTP id kh2mr224322obb.58.1424819124204; Tue, 24 Feb 2015 15:05:24 -0800 (PST) Received: by 10.76.112.136 with HTTP; Tue, 24 Feb 2015 15:05:24 -0800 (PST) In-Reply-To: <20150224211328.GF25639@pfrc> References: <20150224211328.GF25639@pfrc> Date: Wed, 25 Feb 2015 04:35:24 +0530 Message-ID: Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Manav Bhatia To: Jeffrey Haas Content-Type: multipart/alternative; boundary=089e015370eec47ac4050fdd8d15 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 23:05:27 -0000 --089e015370eec47ac4050fdd8d15 Content-Type: text/plain; charset=UTF-8 Hi Jeff, I am not sure how easy is it to do this for HW based implementations where you would be required to cache the last good packet heard from all sessions. What we have proposed here requires no change to the current hardware based implementations. Cheers, Manav On Wed, Feb 25, 2015 at 2:43 AM, Jeffrey Haas wrote: > On Fri, Feb 13, 2015 at 10:31:43AM -0800, Ashesh Mishra wrote: > > Hi BFD Experts, > > The 00 version of BFD Authentication Optimization draft is now online: > > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > > The draft describes method for selectively authenticating certain BFD > frames to avoid computational overhead. > > I have perhaps a rather basic question which I'd been thinking on since it > was said this draft may be coming: > > Is there any reason we couldn't simply use the non-meticulous versions of > the keyed authentication and rely on caching? > > Essentially, in stable state BFD packets will be the same thing over and > over again. As long as the sequence number isn't increased, knowing that a > given packet has passed authentication previously is sufficient if it's the > same packet. > > Given how small BFD packets are, cache the entire packet? Is the memory at > that level of preciousness in the hardware implementations? > > Basically, in RFC 5880, section 6.8.6, at the procedural component that > says > "MUST be authenticated", once this step has completed for this sequence > number and caching is determined to be okay, store the packet. When the > sequence number is seen a second time and the authentication contents are > the same, simply compare the bytes of the packet to the cache. > > I suspect I'm about to get a very strong reality check here. :-) > > -- Jeff > > --089e015370eec47ac4050fdd8d15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jeff,

I am not sure how easy is it t= o do this for HW based implementations where you would be required to cache= the last good packet heard from all sessions.

Wha= t we have proposed here requires no change to the current hardware based im= plementations.

Cheers, Manav

On Wed, Feb 25, 2015 at 2:4= 3 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Fri, Feb 13, 2015 at 10:31:43AM -0800, As= hesh Mishra wrote:
> Hi BFD Experts,
> The 00 version of BFD Authentication Optimization draft is now online:=
> https://datatracker.ietf.org/doc/draft-mahesh-bfd= -authentication/
> The draft describes method for selectively authenticating certain BFD = frames to avoid computational overhead.

I have perhaps a rather basic question which I'd been thinking o= n since it
was said this draft may be coming:

Is there any reason we couldn't simply use the non-meticulous versions = of
the keyed authentication and rely on caching?

Essentially, in stable state BFD packets will be the same thing over and over again.=C2=A0 As long as the sequence number isn't increased, knowi= ng that a
given packet has passed authentication previously is sufficient if it's= the
same packet.

Given how small BFD packets are, cache the entire packet?=C2=A0 Is the memo= ry at
that level of preciousness in the hardware implementations?

Basically, in RFC 5880, section 6.8.6, at the procedural component that say= s
"MUST be authenticated", once this step has completed for this se= quence
number and caching is determined to be okay, store the packet.=C2=A0 When t= he
sequence number is seen a second time and the authentication contents are the same, simply compare the bytes of the packet to the cache.

I suspect I'm about to get a very strong reality check here. :-)

-- Jeff


--089e015370eec47ac4050fdd8d15-- From nobody Tue Feb 24 16:01:40 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4AE1A036A for ; Tue, 24 Feb 2015 16:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 3JuCU8rkOLCI for ; Tue, 24 Feb 2015 16:01:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DBA181A0058 for ; Tue, 24 Feb 2015 16:01:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 78A4FC212; Tue, 24 Feb 2015 19:01:37 -0500 (EST) Date: Tue, 24 Feb 2015 19:01:37 -0500 From: Jeffrey Haas To: Manav Bhatia Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Message-ID: <20150225000137.GL25639@pfrc> References: <20150224211328.GF25639@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:01:38 -0000 Manav, On Wed, Feb 25, 2015 at 04:35:24AM +0530, Manav Bhatia wrote: > I am not sure how easy is it to do this for HW based implementations where > you would be required to cache the last good packet heard from all sessions. > > What we have proposed here requires no change to the current hardware based > implementations. But you're requiring changes to state machine behavior that is itself already embedded in the hardware. It's not zero-touch. (That behavior being don't authenticate everything, shift in and out of authentication, etc.) If that's not a valid summary of the proposal, I didn't read carefully enough. Say so and I'll go spend that time. -- Jeff From nobody Tue Feb 24 16:32:51 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D561A1A4E for ; Tue, 24 Feb 2015 16:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 PEjYbiHXJ6n3 for ; Tue, 24 Feb 2015 16:32:46 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6DD1A1A3B for ; Tue, 24 Feb 2015 16:32:46 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-d3-54ecc3dd33e2 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3F.C4.03307.DD3CCE45; Tue, 24 Feb 2015 19:33:01 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 19:32:44 -0500 From: Gregory Mirsky To: Manav Bhatia , Jeffrey Haas Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tadvoqvosDD0+T/Ufc9u97uZ0AsdOAgAAfRQD//8PhUA== Date: Wed, 25 Feb 2015 00:32:44 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se> References: <20150224211328.GF25639@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B91363Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLrHW/fu4TchBrMeyFrsP/iW1eLypDZ2 i89/tjE6MHvsnHWX3WPJkp9MHpd7t7IGMEdx2aSk5mSWpRbp2yVwZexrvMxW8Cuhon/fN9YG xhVxXYwcHBICJhL/ryd0MXICmWISF+6tZ+ti5OIQEjjCKHFrfycrhLOcUWLbkeesIFVsAkYS Lzb2sIPYIgLuEhNXPWUBsZkFNCWaTnwGiwsLREusbzrOClETIzF562Io20li+bHvbCA2i4Cq RPO3d8wgNq+Ar8TL9j4miGULGCXmPlgKNohTIFCi7+dOsAWMQOd9P7WGCWKZuMStJ/OZIM4W kFiy5zwzhC0q8fLxP1YIW0li0tJzrCBfMgvkSxzbYQWxS1Di5MwnLBMYRWchmTQLoWoWkiqI sKbE+l36ENWKElO6H7JD2BoSrXPmsiOLL2BkX8XIUVqcWpabbmSwiREYZcck2HR3MO55aXmI UYCDUYmH1+Dl6xAh1sSy4srcQ4zSHCxK4ryLHhwMERJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cAYXXPCSCdb1kCQvSBs/5PDknttOSfs2caRbqyeNvnZN9WdTjVVsifmbkv+uDL/xZmd/QGt /6fUGLjKtlqeuR1iJtp7jf/jxmCWGSc4So7b59xbGsyhVNLKX1C3OGvFvlMP9x5Ua5vq2fZg V/G2lBdPXdLOXp8ZlyLu0CPxbOX06d8XTbqk9NpNiaU4I9FQi7moOBEAAOsATJMCAAA= Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:32:49 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B91363Eeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQp3aGF0IGV2aWRlbmNlIGF1dGhvcnMgaGF2ZSB0byBzdGF0ZToNCuKAnFdoYXQg d2UgaGF2ZSBwcm9wb3NlZCBoZXJlIHJlcXVpcmVzIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCBo YXJkd2FyZSBiYXNlZCBpbXBsZW1lbnRhdGlvbnMu4oCdDQpIYWQgeW91IHBlcmZvcm1lZCBhIHBv bGw/IFdvdWxkIHlvdSBraW5kbHkgc2hhcmUgdGhlIHJlc3VsdHM/DQoNCiAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206 IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN YW5hdiBCaGF0aWENClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE1IDM6MDUgUE0NClRv OiBKZWZmcmV5IEhhYXMNCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogTmV3IEJG RCBBdXRoZW50aWNhdGlvbiBPcHRpbWl6YXRpb24gZHJhZnQgZHJhZnQtbWFoZXNoLWJmZC1hdXRo ZW50aWNhdGlvbi0wMA0KDQpIaSBKZWZmLA0KDQpJIGFtIG5vdCBzdXJlIGhvdyBlYXN5IGlzIGl0 IHRvIGRvIHRoaXMgZm9yIEhXIGJhc2VkIGltcGxlbWVudGF0aW9ucyB3aGVyZSB5b3Ugd291bGQg YmUgcmVxdWlyZWQgdG8gY2FjaGUgdGhlIGxhc3QgZ29vZCBwYWNrZXQgaGVhcmQgZnJvbSBhbGwg c2Vzc2lvbnMuDQoNCldoYXQgd2UgaGF2ZSBwcm9wb3NlZCBoZXJlIHJlcXVpcmVzIG5vIGNoYW5n ZSB0byB0aGUgY3VycmVudCBoYXJkd2FyZSBiYXNlZCBpbXBsZW1lbnRhdGlvbnMuDQoNCkNoZWVy cywgTWFuYXYNCg0KT24gV2VkLCBGZWIgMjUsIDIwMTUgYXQgMjo0MyBBTSwgSmVmZnJleSBIYWFz IDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiB3cm90ZToNCk9uIEZyaSwg RmViIDEzLCAyMDE1IGF0IDEwOjMxOjQzQU0gLTA4MDAsIEFzaGVzaCBNaXNocmEgd3JvdGU6DQo+ IEhpIEJGRCBFeHBlcnRzLA0KPiBUaGUgMDAgdmVyc2lvbiBvZiBCRkQgQXV0aGVudGljYXRpb24g T3B0aW1pemF0aW9uIGRyYWZ0IGlzIG5vdyBvbmxpbmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRpb24vDQo+IFRoZSBkcmFm dCBkZXNjcmliZXMgbWV0aG9kIGZvciBzZWxlY3RpdmVseSBhdXRoZW50aWNhdGluZyBjZXJ0YWlu IEJGRCBmcmFtZXMgdG8gYXZvaWQgY29tcHV0YXRpb25hbCBvdmVyaGVhZC4NCg0KSSBoYXZlIHBl cmhhcHMgYSByYXRoZXIgYmFzaWMgcXVlc3Rpb24gd2hpY2ggSSdkIGJlZW4gdGhpbmtpbmcgb24g c2luY2UgaXQNCndhcyBzYWlkIHRoaXMgZHJhZnQgbWF5IGJlIGNvbWluZzoNCg0KSXMgdGhlcmUg YW55IHJlYXNvbiB3ZSBjb3VsZG4ndCBzaW1wbHkgdXNlIHRoZSBub24tbWV0aWN1bG91cyB2ZXJz aW9ucyBvZg0KdGhlIGtleWVkIGF1dGhlbnRpY2F0aW9uIGFuZCByZWx5IG9uIGNhY2hpbmc/DQoN CkVzc2VudGlhbGx5LCBpbiBzdGFibGUgc3RhdGUgQkZEIHBhY2tldHMgd2lsbCBiZSB0aGUgc2Ft ZSB0aGluZyBvdmVyIGFuZA0Kb3ZlciBhZ2Fpbi4gIEFzIGxvbmcgYXMgdGhlIHNlcXVlbmNlIG51 bWJlciBpc24ndCBpbmNyZWFzZWQsIGtub3dpbmcgdGhhdCBhDQpnaXZlbiBwYWNrZXQgaGFzIHBh c3NlZCBhdXRoZW50aWNhdGlvbiBwcmV2aW91c2x5IGlzIHN1ZmZpY2llbnQgaWYgaXQncyB0aGUN CnNhbWUgcGFja2V0Lg0KDQpHaXZlbiBob3cgc21hbGwgQkZEIHBhY2tldHMgYXJlLCBjYWNoZSB0 aGUgZW50aXJlIHBhY2tldD8gIElzIHRoZSBtZW1vcnkgYXQNCnRoYXQgbGV2ZWwgb2YgcHJlY2lv dXNuZXNzIGluIHRoZSBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnM/DQoNCkJhc2ljYWxseSwgaW4g UkZDIDU4ODAsIHNlY3Rpb24gNi44LjYsIGF0IHRoZSBwcm9jZWR1cmFsIGNvbXBvbmVudCB0aGF0 IHNheXMNCiJNVVNUIGJlIGF1dGhlbnRpY2F0ZWQiLCBvbmNlIHRoaXMgc3RlcCBoYXMgY29tcGxl dGVkIGZvciB0aGlzIHNlcXVlbmNlDQpudW1iZXIgYW5kIGNhY2hpbmcgaXMgZGV0ZXJtaW5lZCB0 byBiZSBva2F5LCBzdG9yZSB0aGUgcGFja2V0LiAgV2hlbiB0aGUNCnNlcXVlbmNlIG51bWJlciBp cyBzZWVuIGEgc2Vjb25kIHRpbWUgYW5kIHRoZSBhdXRoZW50aWNhdGlvbiBjb250ZW50cyBhcmUN CnRoZSBzYW1lLCBzaW1wbHkgY29tcGFyZSB0aGUgYnl0ZXMgb2YgdGhlIHBhY2tldCB0byB0aGUg Y2FjaGUuDQoNCkkgc3VzcGVjdCBJJ20gYWJvdXQgdG8gZ2V0IGEgdmVyeSBzdHJvbmcgcmVhbGl0 eSBjaGVjayBoZXJlLiA6LSkNCg0KLS0gSmVmZg0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B91363Eeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTWFuYXYsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndoYXQgZXZpZGVuY2UgYXV0aG9ycyBoYXZlIHRvIHN0 YXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxXaGF0IHdlIGhhdmUgcHJvcG9z ZWQgaGVyZSByZXF1aXJlcyBubyBjaGFuZ2UgdG8gdGhlIGN1cnJlbnQgaGFyZHdhcmUgYmFzZWQg aW1wbGVtZW50YXRpb25zLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IYWQgeW91 IHBlcmZvcm1lZCBhIHBvbGw/IFdvdWxkIHlvdSBraW5kbHkgc2hhcmUgdGhlIHJlc3VsdHM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hbmF2IEJoYXRpYTxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNSAzOjA1IFBNPGJyPg0KPGI+VG86 PC9iPiBKZWZmcmV5IEhhYXM8YnI+DQo8Yj5DYzo8L2I+IHJ0Zy1iZmRAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IE5ldyBCRkQgQXV0aGVudGljYXRpb24gT3B0aW1pemF0aW9uIGRy YWZ0IGRyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRpb24tMDA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBKZWZmLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qgc3VyZSBob3cgZWFzeSBpcyBpdCB0byBkbyB0aGlz IGZvciBIVyBiYXNlZCBpbXBsZW1lbnRhdGlvbnMgd2hlcmUgeW91IHdvdWxkIGJlIHJlcXVpcmVk IHRvIGNhY2hlIHRoZSBsYXN0IGdvb2QgcGFja2V0IGhlYXJkIGZyb20gYWxsIHNlc3Npb25zLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0 IHdlIGhhdmUgcHJvcG9zZWQgaGVyZSByZXF1aXJlcyBubyBjaGFuZ2UgdG8gdGhlIGN1cnJlbnQg aGFyZHdhcmUgYmFzZWQgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDI1LCAy MDE1IGF0IDI6NDMgQU0sIEplZmZyZXkgSGFhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBm cmMub3JnIiB0YXJnZXQ9Il9ibGFuayI+amhhYXNAcGZyYy5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+T24gRnJpLCBGZWIgMTMsIDIwMTUgYXQgMTA6MzE6NDNBTSAtMDgwMCwgQXNoZXNoIE1p c2hyYSB3cm90ZTo8YnI+DQomZ3Q7IEhpIEJGRCBFeHBlcnRzLDxicj4NCiZndDsgVGhlIDAwIHZl cnNpb24gb2YgQkZEIEF1dGhlbnRpY2F0aW9uIE9wdGltaXphdGlvbiBkcmFmdCBpcyBub3cgb25s aW5lOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWFoZXNoLWJmZC1hdXRoZW50aWNhdGlvbi8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRp b24vPC9hPjxicj4NCiZndDsgVGhlIGRyYWZ0IGRlc2NyaWJlcyBtZXRob2QgZm9yIHNlbGVjdGl2 ZWx5IGF1dGhlbnRpY2F0aW5nIGNlcnRhaW4gQkZEIGZyYW1lcyB0byBhdm9pZCBjb21wdXRhdGlv bmFsIG92ZXJoZWFkLjxicj4NCjxicj4NCkkgaGF2ZSBwZXJoYXBzIGEgcmF0aGVyIGJhc2ljIHF1 ZXN0aW9uIHdoaWNoIEknZCBiZWVuIHRoaW5raW5nIG9uIHNpbmNlIGl0PGJyPg0Kd2FzIHNhaWQg dGhpcyBkcmFmdCBtYXkgYmUgY29taW5nOjxicj4NCjxicj4NCklzIHRoZXJlIGFueSByZWFzb24g d2UgY291bGRuJ3Qgc2ltcGx5IHVzZSB0aGUgbm9uLW1ldGljdWxvdXMgdmVyc2lvbnMgb2Y8YnI+ DQp0aGUga2V5ZWQgYXV0aGVudGljYXRpb24gYW5kIHJlbHkgb24gY2FjaGluZz88YnI+DQo8YnI+ DQpFc3NlbnRpYWxseSwgaW4gc3RhYmxlIHN0YXRlIEJGRCBwYWNrZXRzIHdpbGwgYmUgdGhlIHNh bWUgdGhpbmcgb3ZlciBhbmQ8YnI+DQpvdmVyIGFnYWluLiZuYnNwOyBBcyBsb25nIGFzIHRoZSBz ZXF1ZW5jZSBudW1iZXIgaXNuJ3QgaW5jcmVhc2VkLCBrbm93aW5nIHRoYXQgYTxicj4NCmdpdmVu IHBhY2tldCBoYXMgcGFzc2VkIGF1dGhlbnRpY2F0aW9uIHByZXZpb3VzbHkgaXMgc3VmZmljaWVu dCBpZiBpdCdzIHRoZTxicj4NCnNhbWUgcGFja2V0Ljxicj4NCjxicj4NCkdpdmVuIGhvdyBzbWFs bCBCRkQgcGFja2V0cyBhcmUsIGNhY2hlIHRoZSBlbnRpcmUgcGFja2V0PyZuYnNwOyBJcyB0aGUg bWVtb3J5IGF0PGJyPg0KdGhhdCBsZXZlbCBvZiBwcmVjaW91c25lc3MgaW4gdGhlIGhhcmR3YXJl IGltcGxlbWVudGF0aW9ucz88YnI+DQo8YnI+DQpCYXNpY2FsbHksIGluIFJGQyA1ODgwLCBzZWN0 aW9uIDYuOC42LCBhdCB0aGUgcHJvY2VkdXJhbCBjb21wb25lbnQgdGhhdCBzYXlzPGJyPg0KJnF1 b3Q7TVVTVCBiZSBhdXRoZW50aWNhdGVkJnF1b3Q7LCBvbmNlIHRoaXMgc3RlcCBoYXMgY29tcGxl dGVkIGZvciB0aGlzIHNlcXVlbmNlPGJyPg0KbnVtYmVyIGFuZCBjYWNoaW5nIGlzIGRldGVybWlu ZWQgdG8gYmUgb2theSwgc3RvcmUgdGhlIHBhY2tldC4mbmJzcDsgV2hlbiB0aGU8YnI+DQpzZXF1 ZW5jZSBudW1iZXIgaXMgc2VlbiBhIHNlY29uZCB0aW1lIGFuZCB0aGUgYXV0aGVudGljYXRpb24g Y29udGVudHMgYXJlPGJyPg0KdGhlIHNhbWUsIHNpbXBseSBjb21wYXJlIHRoZSBieXRlcyBvZiB0 aGUgcGFja2V0IHRvIHRoZSBjYWNoZS48YnI+DQo8YnI+DQpJIHN1c3BlY3QgSSdtIGFib3V0IHRv IGdldCBhIHZlcnkgc3Ryb25nIHJlYWxpdHkgY2hlY2sgaGVyZS4gOi0pPGJyPg0KPGJyPg0KLS0g SmVmZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B91363Eeusaamb103erics_-- From nobody Tue Feb 24 16:33:33 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9B91A1A28 for ; Tue, 24 Feb 2015 16:33:32 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 W5N0Bj7AWmLf for ; Tue, 24 Feb 2015 16:33:30 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 B465E1A1A3B for ; Tue, 24 Feb 2015 16:33:30 -0800 (PST) Received: by mail-oi0-f42.google.com with SMTP id h136so530967oig.1 for ; Tue, 24 Feb 2015 16:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rtHeZWxTXcHTpuqFIzejQkFtpZpYbVKzf/Izpc82CyY=; b=Lt7Lw97yrVumlzE31wFRMK9VE4494avBp2G4mvNNWgd7mkWEFTiWKXAj8GxoFY+Z8r 95klSvpm0fB6p1fmbpf2poInYpaX8zjTjmh7D2VlHJpsdkYePZAEC07s6k/+lvBLnRtf wSd5KWrrUJmv0AX2EBE9KMf8iMonT4HkSvmfPD7h/eqyemRrULuB8Q4uh9jfRY6U+CVt VTVLAXpswgVptJ9M1djSBgIXg1sUX92xDgwTmv3sSbBwX0fye7tlZ+W1vo7+DLT0U66a lwWZXErFoDCRJ4XZy++qG68pjYIPblrG/yloWnCFr8tcTwefJ7X2Oh4/1X9QJgNgZ8oq EtIg== MIME-Version: 1.0 X-Received: by 10.182.119.232 with SMTP id kx8mr377488obb.37.1424824410034; Tue, 24 Feb 2015 16:33:30 -0800 (PST) Received: by 10.76.112.136 with HTTP; Tue, 24 Feb 2015 16:33:29 -0800 (PST) In-Reply-To: <20150225000137.GL25639@pfrc> References: <20150224211328.GF25639@pfrc> <20150225000137.GL25639@pfrc> Date: Wed, 25 Feb 2015 06:03:29 +0530 Message-ID: Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Manav Bhatia To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c2f43ad3dbbd050fdec811 Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:33:32 -0000 --001a11c2f43ad3dbbd050fdec811 Content-Type: text/plain; charset=UTF-8 Jeff, I see your point. Our proposal requires no change at the RX side. If you see an "A" bit, pass it to the crypto module and authenticate the packet. If you dont, then dont. However, the sending side requires some smarts. You turn on Auth if you notice that session state or some parameter has changed. I had spoken to a HW guy earlier and i had learnt that this can be trivially implemented in at least that vendors platform -- will have to hear from other vendors on how trivial/complex this is in theirs. Next, we could do the same for your proposal. However, i have a hunch that what you propose may not work since that requires caching packets for each session. Will have to poll the people for this. Cheers, Manav On Wed, Feb 25, 2015 at 5:31 AM, Jeffrey Haas wrote: > Manav, > > On Wed, Feb 25, 2015 at 04:35:24AM +0530, Manav Bhatia wrote: > > I am not sure how easy is it to do this for HW based implementations > where > > you would be required to cache the last good packet heard from all > sessions. > > > > What we have proposed here requires no change to the current hardware > based > > implementations. > > But you're requiring changes to state machine behavior that is itself > already embedded in the hardware. It's not zero-touch. (That behavior > being don't authenticate everything, shift in and out of authentication, > etc.) > > If that's not a valid summary of the proposal, I didn't read carefully > enough. Say so and I'll go spend that time. > > -- Jeff > --001a11c2f43ad3dbbd050fdec811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jeff,

I see your point. Our proposal re= quires no change at the RX side.

If you see an &qu= ot;A" bit, pass it to the crypto module and authenticate the packet. I= f you dont, then dont.=C2=A0

However, the sending = side requires some smarts. You turn on Auth if you notice that session stat= e or some parameter has changed. I had spoken to a HW guy earlier and i had= learnt that this can be trivially implemented in at least that vendors pla= tform -- will have to hear from other vendors on how trivial/complex this i= s in theirs.

Next, we could do the same for your p= roposal. However, i have a hunch that what you propose may not work since t= hat requires caching packets for each session. Will have to poll the people= for this.

Cheers, Manav

On Wed, Feb 25, 2015 at 5:31 AM, Jeffre= y Haas <jhaas@pfrc.org> wrote:

On Wed, Feb 25, 2015 at 04:35:24AM +0530, Manav Bhatia wrote:
> I am not sure how easy is it to do this for HW based implementations w= here
> you would be required to cache the last good packet heard from all ses= sions.
>
> What we have proposed here requires no change to the current hardware = based
> implementations.

But you're requiring changes to state machine behavior that is i= tself
already embedded in the hardware.=C2=A0 It's not zero-touch.=C2=A0 (Tha= t behavior
being don't authenticate everything, shift in and out of authentication= ,
etc.)

If that's not a valid summary of the proposal, I didn't read carefu= lly
enough.=C2=A0 Say so and I'll go spend that time.

-- Jeff

--001a11c2f43ad3dbbd050fdec811-- From nobody Tue Feb 24 16:35:23 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214CF1A1A28 for ; Tue, 24 Feb 2015 16:35:22 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ktDhxBn7o8LB for ; Tue, 24 Feb 2015 16:35:20 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 BADC21A19E4 for ; Tue, 24 Feb 2015 16:35:19 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so569947obc.9 for ; Tue, 24 Feb 2015 16:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KyyfKhUAS4v3pGMHWVgqwOKxMpTtrjHwXOWnwgokOwI=; b=GbJY4kc45k2sYc7zVVd/pSiRbTgehMHTNGztYgg68/Z0bvUA8Xu2UWtkpUya4fAYSG wPtAGU/nFnHbA4uKdnKW9av7KdLeIIdIigO4dAYGw/o8JgWCpEqMYFtyr3nR6AQfRXNx dCgr/3tQf2ycb6izo4CyIGLkUlQ27LIXUbinmSoK9bsDmCKvJ8oH1bjuFIjbe6CF33Xj LUTkjvoUIwoWg6o6RVupvJrh/yw34Kf4eLzJNyQBOx1rpBSx/1XE+BxI1ca7r/1rt1a7 x9QsUbvC32Gghh/MwftVgM3Py2fxTzI34OwDMtnw0YJyAW4WHXTM1qe/Ey8lOFFIH3sY /zqw== MIME-Version: 1.0 X-Received: by 10.60.97.35 with SMTP id dx3mr461040oeb.6.1424824519005; Tue, 24 Feb 2015 16:35:19 -0800 (PST) Received: by 10.76.112.136 with HTTP; Tue, 24 Feb 2015 16:35:18 -0800 (PST) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se> References: <20150224211328.GF25639@pfrc> <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se> Date: Wed, 25 Feb 2015 06:05:18 +0530 Message-ID: Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 From: Manav Bhatia To: Gregory Mirsky Content-Type: multipart/alternative; boundary=089e01227a1852be5d050fdecfaa Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:35:22 -0000 --089e01227a1852be5d050fdecfaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Greg, It requires no changes on the RX side. I concede that it does require some changes on the TX side. If somebody tells me that this requires changes on the RX side as well, then that vendor's implementation is broken! :-) Cheers, Manav On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky wrote: > Hi Manav, > > what evidence authors have to state: > > =E2=80=9CWhat we have proposed here requires no change to the current har= dware > based implementations.=E2=80=9D > > Had you performed a poll? Would you kindly share the results? > > > > Regards, > > Greg > > > > *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Manav > Bhatia > *Sent:* Tuesday, February 24, 2015 3:05 PM > *To:* Jeffrey Haas > *Cc:* rtg-bfd@ietf.org > *Subject:* Re: New BFD Authentication Optimization draft > draft-mahesh-bfd-authentication-00 > > > > Hi Jeff, > > > > I am not sure how easy is it to do this for HW based implementations wher= e > you would be required to cache the last good packet heard from all sessio= ns. > > > > What we have proposed here requires no change to the current hardware > based implementations. > > > > Cheers, Manav > > > > On Wed, Feb 25, 2015 at 2:43 AM, Jeffrey Haas wrote: > > On Fri, Feb 13, 2015 at 10:31:43AM -0800, Ashesh Mishra wrote: > > Hi BFD Experts, > > The 00 version of BFD Authentication Optimization draft is now online: > > https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ > > The draft describes method for selectively authenticating certain BFD > frames to avoid computational overhead. > > I have perhaps a rather basic question which I'd been thinking on since i= t > was said this draft may be coming: > > Is there any reason we couldn't simply use the non-meticulous versions of > the keyed authentication and rely on caching? > > Essentially, in stable state BFD packets will be the same thing over and > over again. As long as the sequence number isn't increased, knowing that= a > given packet has passed authentication previously is sufficient if it's t= he > same packet. > > Given how small BFD packets are, cache the entire packet? Is the memory = at > that level of preciousness in the hardware implementations? > > Basically, in RFC 5880, section 6.8.6, at the procedural component that > says > "MUST be authenticated", once this step has completed for this sequence > number and caching is determined to be okay, store the packet. When the > sequence number is seen a second time and the authentication contents are > the same, simply compare the bytes of the packet to the cache. > > I suspect I'm about to get a very strong reality check here. :-) > > -- Jeff > > > --089e01227a1852be5d050fdecfaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Greg,

It requires no changes on the = RX side. I concede that it does require some changes on the TX side.
<= div>
If somebody tells me that this requires changes on the R= X side as well, then that vendor's implementation is broken! :-)
<= div>
Cheers, Manav

=
On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky = <gregory.mirsky@ericsson.com> wrote:

Hi Manav,

what evidence authors hav= e to state:

=E2=80=9CWhat we have pro= posed here requires no change to the current hardware based implementations= .=E2=80=9D

Had you performed a poll?= Would you kindly share the results?

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Greg

=C2=A0

From: Rtg-bfd = [mailto:rtg-b= fd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Tuesday, February 24, 2015 3:05 PM
To: Jeffrey Haas
Cc: rtg-bfd@ie= tf.org
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-= bfd-authentication-00

=C2=A0

Hi Jeff,

=C2=A0

I am not sure how easy is it to do this for HW based= implementations where you would be required to cache the last good packet = heard from all sessions.

=C2=A0

What we have proposed here requires no change to the= current hardware based implementations.

=C2=A0

Cheers, Manav

=C2=A0

On Wed, Feb 25, 2015 at 2:43 AM, Jeffrey Haas <jhaas@pfrc.org> wr= ote:

On Fri, Feb 13, 2015 = at 10:31:43AM -0800, Ashesh Mishra wrote:
> Hi BFD Experts,
> The 00 version of BFD Authentication Optimization draft is now online:=
> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/
> The draft describes method for selectively authenticating certain BFD = frames to avoid computational overhead.

I have perhaps a rather basic question which I'd been thinking on since= it
was said this draft may be coming:

Is there any reason we couldn't simply use the non-meticulous versions = of
the keyed authentication and rely on caching?

Essentially, in stable state BFD packets will be the same thing over and over again.=C2=A0 As long as the sequence number isn't increased, knowi= ng that a
given packet has passed authentication previously is sufficient if it's= the
same packet.

Given how small BFD packets are, cache the entire packet?=C2=A0 Is the memo= ry at
that level of preciousness in the hardware implementations?

Basically, in RFC 5880, section 6.8.6, at the procedural component that say= s
"MUST be authenticated", once this step has completed for this se= quence
number and caching is determined to be okay, store the packet.=C2=A0 When t= he
sequence number is seen a second time and the authentication contents are the same, simply compare the bytes of the packet to the cache.

I suspect I'm about to get a very strong reality check here. :-)

-- Jeff

=C2=A0


--089e01227a1852be5d050fdecfaa-- From nobody Tue Feb 24 16:53:01 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8691A0BE8 for ; Tue, 24 Feb 2015 16:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 sJP-vkZp206N for ; Tue, 24 Feb 2015 16:52:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D31061A036F for ; Tue, 24 Feb 2015 16:52:57 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9287FC207; Tue, 24 Feb 2015 19:52:57 -0500 (EST) Date: Tue, 24 Feb 2015 19:52:57 -0500 From: Jeffrey Haas To: Jeffrey Haas Subject: Re: FW: New Version Notification for draft-spallagatti-bfd-multipoint-active-tail-00.txt Message-ID: <20150225005257.GR25639@pfrc> References: <20150203060639.21858.88568.idtracker@ietfa.amsl.com> <20150224214329.GH25639@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150224214329.GH25639@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 00:52:59 -0000 I said, without having cleared my BFD inbox before responding... On Tue, Feb 24, 2015 at 04:43:29PM -0500, Jeffrey Haas wrote: [...] > What I would like to recommend for the Working Group with regards to this > document based on prior discussion is the following: > - Make the status Experimental. Given the lack of implementations of this > functionality vs. active development in what is now the core document it > seems a good match for it. Adrian pointed out the following TRILL document to me: http://tools.ietf.org/html/draft-zhang-trill-p2mp-bfd-00 Since that document is targeted to Standards Track, looks like active-tail needs to stay there too. :-) -- Jeff From nobody Tue Feb 24 17:03:05 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4B51A1A28 for ; Tue, 24 Feb 2015 17:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 Ufm8O4UBq3Iv for ; Tue, 24 Feb 2015 17:03:02 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEE61A0396 for ; Tue, 24 Feb 2015 17:03:01 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-d5-54ecbec684d0 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0D.73.25146.6CEBCE45; Tue, 24 Feb 2015 19:11:18 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Tue, 24 Feb 2015 20:02:55 -0500 From: Gregory Mirsky To: Manav Bhatia Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Topic: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Thread-Index: AQHQR7tadvoqvosDD0+T/Ufc9u97uZ0AsdOAgAAfRQD//8PhUIAAVT0A//+w+TA= Date: Wed, 25 Feb 2015 01:02:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9136A6@eusaamb103.ericsson.se> References: <20150224211328.GF25639@pfrc> <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B9136A6eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonSvfYvjchBnv7rCz2H3zLanF5Uhu7 xec/2xgdmD12zrrL7rFkyU8mj8u9W1kDmKO4bFJSczLLUov07RK4Mtqnrmcv+DGHsWLzv0nM DYwPZjB2MXJySAiYSFyddJ4ZwhaTuHBvPVsXIxeHkMARRonJ0z4yQjjLGSUu/4ToYBMwknix sYcdxBYR0JBofX8ArJtZwEOib+tuNhBbWCBaYn3TcVaImhiJyVsXQ9l+Emsm/wSrZxFQlbh7 +AELiM0r4Cux4sNssLiQwGomiQnTdEBsToFAiWPLNoLtYgS67vupNUwQu8Qlbj2ZzwRxtYDE kj0wH4hKvHz8jxXCVpKYtPQckM0BVJ8vsfS+E8QqQYmTM5+wTGAUnYVk0iyEqllIqiDCmhLr d+lDVCtKTOl+yA5hA/0+Zy47svgCRvZVjBylxalluelGhpsYgZF2TILNcQfjgk+WhxgFOBiV eHgNXr4OEWJNLCuuzD3EKM3BoiTOW3blYIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRra9 LxjTDRhsPt9fZuZU6ZSpdvSCaWZ/5+456n5huxkCtuywOGBiF6u1h/lT0UuZzZqXON/rFrhs e32eT1Funswet3MP10rEhnBV37aK2qSqXubAMfGirdfVRyqH360rqHr160P/7rRIn51167X6 Lm7lc5N1SftswH7u5RJVsY/F+cc4bxvfV2Ipzkg01GIuKk4EAL3AYdiVAgAA Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 01:03:04 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B9136A6eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsIGV0LiBhbCwNCkkgdGhpbmsgdGhhdCBhdXRob3JzIGhhZCBub3QgY29uc2lkZXJl ZCBpbXBhY3Qgb2YgdGhlIHByb3Bvc2FsIG9uIGRlZmluZWQgaW4gUkZDIDY0MjggUkRJIGZ1bmN0 aW9uYWxpdHkuIFBlcmhhcHMgeW914oCZbGwgY2FsbCBzdXBwb3J0IG9mIHRoZSBSREkg4oCcYnJv a2VuIGltcGxlbWVudGF0aW9u4oCdLiBCdXQgdGhhdOKAmXMgT0suDQoNCiAgICAgICAgICAgICAg ICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnDQoNCkZyb206 IE1hbmF2IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEZlYnJ1YXJ5IDI0LCAyMDE1IDQ6MzUgUE0NClRvOiBHcmVnb3J5IE1pcnNreQ0KQ2M6IEpl ZmZyZXkgSGFhczsgcnRnLWJmZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IE5ldyBCRkQgQXV0aGVu dGljYXRpb24gT3B0aW1pemF0aW9uIGRyYWZ0IGRyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRp b24tMDANCg0KSGkgR3JlZywNCg0KSXQgcmVxdWlyZXMgbm8gY2hhbmdlcyBvbiB0aGUgUlggc2lk ZS4gSSBjb25jZWRlIHRoYXQgaXQgZG9lcyByZXF1aXJlIHNvbWUgY2hhbmdlcyBvbiB0aGUgVFgg c2lkZS4NCg0KSWYgc29tZWJvZHkgdGVsbHMgbWUgdGhhdCB0aGlzIHJlcXVpcmVzIGNoYW5nZXMg b24gdGhlIFJYIHNpZGUgYXMgd2VsbCwgdGhlbiB0aGF0IHZlbmRvcidzIGltcGxlbWVudGF0aW9u IGlzIGJyb2tlbiEgOi0pDQoNCkNoZWVycywgTWFuYXYNCg0KT24gV2VkLCBGZWIgMjUsIDIwMTUg YXQgNjowMiBBTSwgR3JlZ29yeSBNaXJza3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxt YWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBNYW5hdiwNCndo YXQgZXZpZGVuY2UgYXV0aG9ycyBoYXZlIHRvIHN0YXRlOg0K4oCcV2hhdCB3ZSBoYXZlIHByb3Bv c2VkIGhlcmUgcmVxdWlyZXMgbm8gY2hhbmdlIHRvIHRoZSBjdXJyZW50IGhhcmR3YXJlIGJhc2Vk IGltcGxlbWVudGF0aW9ucy7igJ0NCkhhZCB5b3UgcGVyZm9ybWVkIGEgcG9sbD8gV291bGQgeW91 IGtpbmRseSBzaGFyZSB0aGUgcmVzdWx0cz8NCg0KICAgICAgICAgICAgICAgIFJlZ2FyZHMsDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcNCg0KRnJvbTogUnRnLWJmZCBbbWFp bHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIE1hbmF2IEJoYXRpYQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkg MjQsIDIwMTUgMzowNSBQTQ0KVG86IEplZmZyZXkgSGFhcw0KQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogTmV3IEJGRCBBdXRoZW50aWNh dGlvbiBPcHRpbWl6YXRpb24gZHJhZnQgZHJhZnQtbWFoZXNoLWJmZC1hdXRoZW50aWNhdGlvbi0w MA0KDQpIaSBKZWZmLA0KDQpJIGFtIG5vdCBzdXJlIGhvdyBlYXN5IGlzIGl0IHRvIGRvIHRoaXMg Zm9yIEhXIGJhc2VkIGltcGxlbWVudGF0aW9ucyB3aGVyZSB5b3Ugd291bGQgYmUgcmVxdWlyZWQg dG8gY2FjaGUgdGhlIGxhc3QgZ29vZCBwYWNrZXQgaGVhcmQgZnJvbSBhbGwgc2Vzc2lvbnMuDQoN CldoYXQgd2UgaGF2ZSBwcm9wb3NlZCBoZXJlIHJlcXVpcmVzIG5vIGNoYW5nZSB0byB0aGUgY3Vy cmVudCBoYXJkd2FyZSBiYXNlZCBpbXBsZW1lbnRhdGlvbnMuDQoNCkNoZWVycywgTWFuYXYNCg0K T24gV2VkLCBGZWIgMjUsIDIwMTUgYXQgMjo0MyBBTSwgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJj Lm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiB3cm90ZToNCk9uIEZyaSwgRmViIDEzLCAyMDE1 IGF0IDEwOjMxOjQzQU0gLTA4MDAsIEFzaGVzaCBNaXNocmEgd3JvdGU6DQo+IEhpIEJGRCBFeHBl cnRzLA0KPiBUaGUgMDAgdmVyc2lvbiBvZiBCRkQgQXV0aGVudGljYXRpb24gT3B0aW1pemF0aW9u IGRyYWZ0IGlzIG5vdyBvbmxpbmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LW1haGVzaC1iZmQtYXV0aGVudGljYXRpb24vDQo+IFRoZSBkcmFmdCBkZXNjcmliZXMg bWV0aG9kIGZvciBzZWxlY3RpdmVseSBhdXRoZW50aWNhdGluZyBjZXJ0YWluIEJGRCBmcmFtZXMg dG8gYXZvaWQgY29tcHV0YXRpb25hbCBvdmVyaGVhZC4NCg0KSSBoYXZlIHBlcmhhcHMgYSByYXRo ZXIgYmFzaWMgcXVlc3Rpb24gd2hpY2ggSSdkIGJlZW4gdGhpbmtpbmcgb24gc2luY2UgaXQNCndh cyBzYWlkIHRoaXMgZHJhZnQgbWF5IGJlIGNvbWluZzoNCg0KSXMgdGhlcmUgYW55IHJlYXNvbiB3 ZSBjb3VsZG4ndCBzaW1wbHkgdXNlIHRoZSBub24tbWV0aWN1bG91cyB2ZXJzaW9ucyBvZg0KdGhl IGtleWVkIGF1dGhlbnRpY2F0aW9uIGFuZCByZWx5IG9uIGNhY2hpbmc/DQoNCkVzc2VudGlhbGx5 LCBpbiBzdGFibGUgc3RhdGUgQkZEIHBhY2tldHMgd2lsbCBiZSB0aGUgc2FtZSB0aGluZyBvdmVy IGFuZA0Kb3ZlciBhZ2Fpbi4gIEFzIGxvbmcgYXMgdGhlIHNlcXVlbmNlIG51bWJlciBpc24ndCBp bmNyZWFzZWQsIGtub3dpbmcgdGhhdCBhDQpnaXZlbiBwYWNrZXQgaGFzIHBhc3NlZCBhdXRoZW50 aWNhdGlvbiBwcmV2aW91c2x5IGlzIHN1ZmZpY2llbnQgaWYgaXQncyB0aGUNCnNhbWUgcGFja2V0 Lg0KDQpHaXZlbiBob3cgc21hbGwgQkZEIHBhY2tldHMgYXJlLCBjYWNoZSB0aGUgZW50aXJlIHBh Y2tldD8gIElzIHRoZSBtZW1vcnkgYXQNCnRoYXQgbGV2ZWwgb2YgcHJlY2lvdXNuZXNzIGluIHRo ZSBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbnM/DQoNCkJhc2ljYWxseSwgaW4gUkZDIDU4ODAsIHNl Y3Rpb24gNi44LjYsIGF0IHRoZSBwcm9jZWR1cmFsIGNvbXBvbmVudCB0aGF0IHNheXMNCiJNVVNU IGJlIGF1dGhlbnRpY2F0ZWQiLCBvbmNlIHRoaXMgc3RlcCBoYXMgY29tcGxldGVkIGZvciB0aGlz IHNlcXVlbmNlDQpudW1iZXIgYW5kIGNhY2hpbmcgaXMgZGV0ZXJtaW5lZCB0byBiZSBva2F5LCBz dG9yZSB0aGUgcGFja2V0LiAgV2hlbiB0aGUNCnNlcXVlbmNlIG51bWJlciBpcyBzZWVuIGEgc2Vj b25kIHRpbWUgYW5kIHRoZSBhdXRoZW50aWNhdGlvbiBjb250ZW50cyBhcmUNCnRoZSBzYW1lLCBz aW1wbHkgY29tcGFyZSB0aGUgYnl0ZXMgb2YgdGhlIHBhY2tldCB0byB0aGUgY2FjaGUuDQoNCkkg c3VzcGVjdCBJJ20gYWJvdXQgdG8gZ2V0IGEgdmVyeSBzdHJvbmcgcmVhbGl0eSBjaGVjayBoZXJl LiA6LSkNCg0KLS0gSmVmZg0KDQoNCg== --_000_7347100B5761DC41A166AC17F22DF1121B9136A6eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSBNYW5hdiwgZXQuIGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRo aW5rIHRoYXQgYXV0aG9ycyBoYWQgbm90IGNvbnNpZGVyZWQgaW1wYWN0IG9mIHRoZSBwcm9wb3Nh bCBvbiBkZWZpbmVkIGluIFJGQyA2NDI4IFJESSBmdW5jdGlvbmFsaXR5LiBQZXJoYXBzIHlvdeKA mWxsIGNhbGwgc3VwcG9ydCBvZiB0aGUgUkRJIOKAnGJyb2tlbiBpbXBsZW1lbnRhdGlvbuKAnS4N CiBCdXQgdGhhdOKAmXMgT0suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEdyZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hbmF2 IEJoYXRpYSBbbWFpbHRvOm1hbmF2YmhhdGlhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNSA0OjM1IFBNPGJyPg0KPGI+VG86PC9iPiBHcmVn b3J5IE1pcnNreTxicj4NCjxiPkNjOjwvYj4gSmVmZnJleSBIYWFzOyBydGctYmZkQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgQkZEIEF1dGhlbnRpY2F0aW9uIE9wdGltaXph dGlvbiBkcmFmdCBkcmFmdC1tYWhlc2gtYmZkLWF1dGhlbnRpY2F0aW9uLTAwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgR3JlZyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHJlcXVpcmVzIG5vIGNoYW5nZXMgb24gdGhlIFJY IHNpZGUuIEkgY29uY2VkZSB0aGF0IGl0IGRvZXMgcmVxdWlyZSBzb21lIGNoYW5nZXMgb24gdGhl IFRYIHNpZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklmIHNvbWVib2R5IHRlbGxzIG1lIHRoYXQgdGhpcyByZXF1aXJlcyBjaGFuZ2VzIG9u IHRoZSBSWCBzaWRlIGFzIHdlbGwsIHRoZW4gdGhhdCB2ZW5kb3IncyBpbXBsZW1lbnRhdGlvbiBp cyBicm9rZW4hIDotKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsIE1hbmF2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDI1LCAyMDE1IGF0IDY6MDIgQU0sIEdy ZWdvcnkgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hbmF2LDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndoYXQgZXZpZGVuY2UgYXV0aG9ycyBoYXZl IHRvIHN0YXRlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnFdoYXQgd2UgaGF2 ZSBwcm9wb3NlZCBoZXJlIHJlcXVpcmVzIG5vIGNoYW5nZSB0byB0aGUgY3VycmVudCBoYXJkd2Fy ZSBiYXNlZCBpbXBsZW1lbnRhdGlvbnMu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGFkIHlvdSBwZXJmb3JtZWQgYSBwb2xsPyBXb3VsZCB5b3Uga2luZGx5IHNoYXJlIHRoZSBy ZXN1bHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBH cmVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLWJm ZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5NYW5hdiBCaGF0aWE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkgMjQs IDIwMTUgMzowNSBQTTxicj4NCjxiPlRvOjwvYj4gSmVmZnJleSBIYWFzPGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86cnRnLWJmZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Zy1i ZmRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBOZXcgQkZEIEF1dGhlbnRp Y2F0aW9uIE9wdGltaXphdGlvbiBkcmFmdCBkcmFmdC1tYWhlc2gtYmZkLWF1dGhlbnRpY2F0aW9u LTAwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEplZmYsPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JIGFtIG5vdCBzdXJlIGhvdyBlYXN5IGlzIGl0IHRvIGRvIHRoaXMgZm9yIEhXIGJhc2Vk IGltcGxlbWVudGF0aW9ucyB3aGVyZSB5b3Ugd291bGQgYmUgcmVxdWlyZWQgdG8gY2FjaGUgdGhl IGxhc3QgZ29vZCBwYWNrZXQgaGVhcmQgZnJvbSBhbGwgc2Vzc2lvbnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IHdlIGhhdmUg cHJvcG9zZWQgaGVyZSByZXF1aXJlcyBubyBjaGFuZ2UgdG8gdGhlIGN1cnJlbnQgaGFyZHdhcmUg YmFzZWQgaW1wbGVtZW50YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLCBNYW5hdjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gV2VkLCBGZWIgMjUsIDIwMTUgYXQgMjo0MyBBTSwgSmVmZnJleSBIYWFz ICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIHRhcmdldD0iX2JsYW5rIj5qaGFh c0BwZnJjLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij5PbiBGcmksIEZlYiAxMywgMjAxNSBhdCAxMDozMTo0M0FNIC0wODAwLCBBc2hlc2ggTWlzaHJh IHdyb3RlOjxicj4NCiZndDsgSGkgQkZEIEV4cGVydHMsPGJyPg0KJmd0OyBUaGUgMDAgdmVyc2lv biBvZiBCRkQgQXV0aGVudGljYXRpb24gT3B0aW1pemF0aW9uIGRyYWZ0IGlzIG5vdyBvbmxpbmU6 PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1tYWhlc2gtYmZkLWF1dGhlbnRpY2F0aW9uLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWFoZXNoLWJmZC1hdXRoZW50aWNhdGlvbi88 L2E+PGJyPg0KJmd0OyBUaGUgZHJhZnQgZGVzY3JpYmVzIG1ldGhvZCBmb3Igc2VsZWN0aXZlbHkg YXV0aGVudGljYXRpbmcgY2VydGFpbiBCRkQgZnJhbWVzIHRvIGF2b2lkIGNvbXB1dGF0aW9uYWwg b3ZlcmhlYWQuPGJyPg0KPGJyPg0KSSBoYXZlIHBlcmhhcHMgYSByYXRoZXIgYmFzaWMgcXVlc3Rp b24gd2hpY2ggSSdkIGJlZW4gdGhpbmtpbmcgb24gc2luY2UgaXQ8YnI+DQp3YXMgc2FpZCB0aGlz IGRyYWZ0IG1heSBiZSBjb21pbmc6PGJyPg0KPGJyPg0KSXMgdGhlcmUgYW55IHJlYXNvbiB3ZSBj b3VsZG4ndCBzaW1wbHkgdXNlIHRoZSBub24tbWV0aWN1bG91cyB2ZXJzaW9ucyBvZjxicj4NCnRo ZSBrZXllZCBhdXRoZW50aWNhdGlvbiBhbmQgcmVseSBvbiBjYWNoaW5nPzxicj4NCjxicj4NCkVz c2VudGlhbGx5LCBpbiBzdGFibGUgc3RhdGUgQkZEIHBhY2tldHMgd2lsbCBiZSB0aGUgc2FtZSB0 aGluZyBvdmVyIGFuZDxicj4NCm92ZXIgYWdhaW4uJm5ic3A7IEFzIGxvbmcgYXMgdGhlIHNlcXVl bmNlIG51bWJlciBpc24ndCBpbmNyZWFzZWQsIGtub3dpbmcgdGhhdCBhPGJyPg0KZ2l2ZW4gcGFj a2V0IGhhcyBwYXNzZWQgYXV0aGVudGljYXRpb24gcHJldmlvdXNseSBpcyBzdWZmaWNpZW50IGlm IGl0J3MgdGhlPGJyPg0Kc2FtZSBwYWNrZXQuPGJyPg0KPGJyPg0KR2l2ZW4gaG93IHNtYWxsIEJG RCBwYWNrZXRzIGFyZSwgY2FjaGUgdGhlIGVudGlyZSBwYWNrZXQ/Jm5ic3A7IElzIHRoZSBtZW1v cnkgYXQ8YnI+DQp0aGF0IGxldmVsIG9mIHByZWNpb3VzbmVzcyBpbiB0aGUgaGFyZHdhcmUgaW1w bGVtZW50YXRpb25zPzxicj4NCjxicj4NCkJhc2ljYWxseSwgaW4gUkZDIDU4ODAsIHNlY3Rpb24g Ni44LjYsIGF0IHRoZSBwcm9jZWR1cmFsIGNvbXBvbmVudCB0aGF0IHNheXM8YnI+DQomcXVvdDtN VVNUIGJlIGF1dGhlbnRpY2F0ZWQmcXVvdDssIG9uY2UgdGhpcyBzdGVwIGhhcyBjb21wbGV0ZWQg Zm9yIHRoaXMgc2VxdWVuY2U8YnI+DQpudW1iZXIgYW5kIGNhY2hpbmcgaXMgZGV0ZXJtaW5lZCB0 byBiZSBva2F5LCBzdG9yZSB0aGUgcGFja2V0LiZuYnNwOyBXaGVuIHRoZTxicj4NCnNlcXVlbmNl IG51bWJlciBpcyBzZWVuIGEgc2Vjb25kIHRpbWUgYW5kIHRoZSBhdXRoZW50aWNhdGlvbiBjb250 ZW50cyBhcmU8YnI+DQp0aGUgc2FtZSwgc2ltcGx5IGNvbXBhcmUgdGhlIGJ5dGVzIG9mIHRoZSBw YWNrZXQgdG8gdGhlIGNhY2hlLjxicj4NCjxicj4NCkkgc3VzcGVjdCBJJ20gYWJvdXQgdG8gZ2V0 IGEgdmVyeSBzdHJvbmcgcmVhbGl0eSBjaGVjayBoZXJlLiA6LSk8YnI+DQo8YnI+DQotLSBKZWZm PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7347100B5761DC41A166AC17F22DF1121B9136A6eusaamb103erics_-- From nobody Wed Feb 25 08:24:45 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA961A90E6 for ; Wed, 25 Feb 2015 08:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 W-Mt4Frx767t for ; Wed, 25 Feb 2015 08:24:41 -0800 (PST) Received: from BAY004-OMC1S24.hotmail.com (bay004-omc1s24.hotmail.com [65.54.190.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022811A90E2 for ; Wed, 25 Feb 2015 08:23:27 -0800 (PST) Received: from BAY176-W10 ([65.54.190.59]) by BAY004-OMC1S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 25 Feb 2015 08:23:26 -0800 X-TMN: [pQK2QjA0RQNvIIXFcjBp/zo8UBNmcsAX] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_c3125d7f-c3fc-47fa-9d18-786d43146d9f_" From: Ashesh Mishra To: Gregory Mirsky , Manav Bhatia , "jhaas@pfrc.org" Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Date: Wed, 25 Feb 2015 08:23:26 -0800 Importance: Normal In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9136A6@eusaamb103.ericsson.se> References: , <20150224211328.GF25639@pfrc>, , <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se>, , <7347100B5761DC41A166AC17F22DF1121B9136A6@eusaamb103.ericsson.se> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Feb 2015 16:23:26.0714 (UTC) FILETIME=[622FC5A0:01D05117] Archived-At: Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 16:24:44 -0000 --_c3125d7f-c3fc-47fa-9d18-786d43146d9f_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greg=2C Jeff=2C et. al=2C There's three implementations to consider here: hardware-only=2C software-o= nly=2C and software state-machine with HW assist for Tx/Rx.=20 HARDWARE-ONLY:The proposed method may not be best suited to such implementa= tions (or rather=2C will not be easily accepted by engineers working on har= dware-only implementations). At least in the sense that there will need to = be major changes to the state-machine in HW (I have known this to not excit= e devs working on the HW programming). Non-meticulous auth with full frame = caching can work=2C but requires even more rework to the HW logic (while pr= oviding=2C more or less=2C the same security as the proposed method).=20 SOFTWARE-ONLY: The best scenario for this proposal. Getting any decent BFD = detection timeout with scale in a software implementation is challenging (I= must have lost at least five of years of my lifespan in the 12 months that= I spent worrying about BFD stability in software). Adding auth to the mix = is just plain cruel to the developers. Fewer frames to authenticate will go= a long way in convincing software BFD implementers to add auth support.=20 SOFTWARE-STATE-MACHINE-WITH-HW-TX-RX-ASSIST:This one is also a good candida= te for this proposal. Since the state machine is in SW=2C the authenticatio= n can be handled in software (auth frames in the proposal are not very time= sensitive). The only change needed in HW is to punt the auth frames to the= software engine.=20 Since there's been a lot of discussion=2C here's the summary of the idea an= d proposed changes so far:- Authenticate all frames that are meant to trigg= er a change in BFD state (the first few DOWN frames to support RDI=2C all I= NIT frames=2C P-F sequence frames)- To detect man-in-the-middle attacks whi= le the session state is UP=2C generate an auth UP frame once every X second= s (10 seconds?). This way=2C no MITM attack will go un-detected for longer = than n*X seconds (n is the detect multiplier for auth-UP frames ... it may/= may-not be same as the common BFD detect multiplier). BR=2CAshesh From: gregory.mirsky@ericsson.com To: manavbhatia@gmail.com Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00 Date: Wed=2C 25 Feb 2015 01:02:54 +0000 CC: rtg-bfd@ietf.org =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Hi Manav=2C et. al=2C=0A= I think that authors had not considered impact of the proposal on defined i= n RFC 6428 RDI functionality. Perhaps you=92ll call support of the RDI =93b= roken implementation=94.=0A= But that=92s OK.=0A= =0A= Regards=2C=0A= Greg=0A= =0A= From: Manav Bhatia [mailto:manavbhatia@gmail.com]=0A= =0A= Sent: Tuesday=2C February 24=2C 2015 4:35 PM =0A= To: Gregory Mirsky =0A= Cc: Jeffrey Haas=3B rtg-bfd@ietf.org =0A= Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00=0A= =0A= =0A= Hi Greg=2C=0A= =0A= =0A= =0A= =0A= It requires no changes on the RX side. I concede that it does require some = changes on the TX side.=0A= =0A= =0A= =0A= =0A= =0A= If somebody tells me that this requires changes on the RX side as well=2C t= hen that vendor's implementation is broken! :-)=0A= =0A= =0A= =0A= =0A= =0A= Cheers=2C Manav=0A= =0A= =0A= =0A= =0A= =0A= On Wed=2C Feb 25=2C 2015 at 6:02 AM=2C Gregory Mirsky wrote:=0A= =0A= =0A= Hi Manav=2C=0A= what evidence authors have to state:=0A= =93What we have proposed here requires no change to the current hardware ba= sed implementations.=94=0A= Had you performed a poll? Would you kindly share the results?=0A= =0A= Regards=2C=0A= Greg=0A= =0A= From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org]=0A= On Behalf Of Manav Bhatia =0A= Sent: Tuesday=2C February 24=2C 2015 3:05 PM =0A= To: Jeffrey Haas =0A= Cc: rtg-bfd@ietf.org =0A= Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-aut= hentication-00=0A= =0A= =0A= Hi Jeff=2C=0A= =0A= =0A= =0A= =0A= =0A= =0A= I am not sure how easy is it to do this for HW based implementations where = you would be required to cache the last good packet heard from all sessions= .=0A= =0A= =0A= =0A= =0A= =0A= What we have proposed here requires no change to the current hardware based= implementations.=0A= =0A= =0A= =0A= =0A= =0A= Cheers=2C Manav=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On Wed=2C Feb 25=2C 2015 at 2:43 AM=2C Jeffrey Haas wrote:= =0A= On Fri=2C Feb 13=2C 2015 at 10:31:43AM -0800=2C Ashesh Mishra wrote: =0A= > Hi BFD Experts=2C =0A= > The 00 version of BFD Authentication Optimization draft is now online: =0A= > =0A= https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/ =0A= > The draft describes method for selectively authenticating certain BFD fra= mes to avoid computational overhead. =0A= =0A= I have perhaps a rather basic question which I'd been thinking on since it =0A= was said this draft may be coming: =0A= =0A= Is there any reason we couldn't simply use the non-meticulous versions of =0A= the keyed authentication and rely on caching? =0A= =0A= Essentially=2C in stable state BFD packets will be the same thing over and =0A= over again. As long as the sequence number isn't increased=2C knowing that= a =0A= given packet has passed authentication previously is sufficient if it's the =0A= same packet. =0A= =0A= Given how small BFD packets are=2C cache the entire packet? Is the memory = at =0A= that level of preciousness in the hardware implementations? =0A= =0A= Basically=2C in RFC 5880=2C section 6.8.6=2C at the procedural component th= at says =0A= "MUST be authenticated"=2C once this step has completed for this sequence =0A= number and caching is determined to be okay=2C store the packet. When the =0A= sequence number is seen a second time and the authentication contents are =0A= the same=2C simply compare the bytes of the packet to the cache. =0A= =0A= I suspect I'm about to get a very strong reality check here. :-) =0A= =0A= -- Jeff=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= = --_c3125d7f-c3fc-47fa-9d18-786d43146d9f_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Greg=2C Jeff=2C et. al=2C
There's three implementations to consider here: hardware-only= =2C software-only=2C and software state-machine with HW assist for Tx/Rx.&n= bsp=3B

HARDWARE-ONLY:
The proposed metho= d may not be best suited to such implementations (or rather=2C will not be = easily accepted by engineers working on hardware-only implementations). At = least in the sense that there will need to be major changes to the state-ma= chine in HW (I have known this to not excite devs working on the HW program= ming). Non-meticulous auth with full frame caching can work=2C but requires= even more rework to the HW logic (while providing=2C more or less=2C the s= ame security as the proposed method). =3B

SOFT= WARE-ONLY: =3B
The best scenario for this proposal. Getting a= ny decent BFD detection timeout with scale in a software implementation is = challenging (I must have lost at least five of years of my lifespan in the = 12 months that I spent worrying about BFD stability in software). Adding au= th to the mix is just plain cruel to the developers. Fewer frames to authen= ticate will go a long way in convincing software BFD implementers to add au= th support. =3B

SOFTWARE-STATE-MACHINE-WITH-HW= -TX-RX-ASSIST:
This one is also a good candidate for this proposa= l. Since the state machine is in SW=2C the authentication can be handled in= software (auth frames in the proposal are not very time sensitive). The on= ly change needed in HW is to punt the auth frames to the software engine.&n= bsp=3B



Since there's= been a lot of discussion=2C here's the summary of the idea and proposed ch= anges so far:
- Authenticate all frames that are meant to trigger= a change in BFD state (the first few DOWN frames to support RDI=2C all INI= T frames=2C P-F sequence frames)
- To detect man-in-the-middle at= tacks while the session state is UP=2C generate an auth UP frame once every= X seconds (10 seconds?). This way=2C no MITM attack will go un-detected fo= r longer than n*X seconds (n is the detect multiplier for auth-UP frames ..= . it may/may-not be same as the common BFD detect multiplier).
BR=2C
Ashesh

From: gregory.mirsky@ericsson.com
To: manavbhatia@gmail.com
Subje= ct: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authenti= cation-00
Date: Wed=2C 25 Feb 2015 01:02:54 +0000
CC: rtg-bfd@ietf.or= g

=0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

Hi Ma= nav=2C et. al=2C

=0A=

I thi= nk that authors had not considered impact of the proposal on defined in RFC= 6428 RDI functionality. Perhaps you=92ll call support of the RDI =93broken= implementation=94.=0A= But that=92s OK.

=0A=

 = =3B

=0A=

 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B Regards=2C

=0A=

 = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B Greg

=0A=

 = =3B

=0A=

From: Manav Bhatia [mailto:manavbhatia@gmail.com]=0A=
=0A= Sent: Tuesday=2C February 24=2C 2015 4:35 PM
=0A= To: Gregory Mirsky
=0A= Cc: Jeffrey Haas=3B rtg-bfd@ietf.org
=0A= Subject: Re: New BFD Authentication Optimization draft draft-mahesh-= bfd-authentication-00

=0A=

 =3B

=0A=
=0A=

Hi Greg=2C

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

It requires no changes on the RX side. I concede = that it does require some changes on the TX side.

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

If somebody tells me that this requires changes o= n the RX side as well=2C then that vendor's implementation is broken! :-)=0A=

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

Cheers=2C Manav

=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=

On Wed=2C Feb 25=2C 2015 at 6:02 AM=2C Gregory Mi= rsky <=3Bgregory.mirsky@ericsson.com>=3B wrote:

=0A=
=0A=
=0A=

Hi Manav=2C

=0A=

what evidence authors have to state:

=0A=

=93What we have proposed here requires no change to the current hardw= are based implementations.=94

=0A=

Had you performed a poll? Would you kindly share the results?<= /p>=0A=

 =3B

=0A=

 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B Regards=2C

= =0A=

 =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B Greg

=0A=

 =3B

=0A=

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org]=0A= On Behalf Of Manav Bhatia
=0A= Sent: Tuesday=2C February 24=2C 2015 3:05 PM
=0A= To: Jeffrey Haas
=0A= Cc: rtg-bfd@ie= tf.org
=0A= Subject: Re: New BFD Authentication Optimization draft draft-mahesh-= bfd-authentication-00

=0A=

 =3B

=0A=
=0A=

Hi Jeff=2C

=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

I am not sure how easy is it to do thi= s for HW based implementations where you would be required to cache the las= t good packet heard from all sessions.

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

What we have proposed here requires no= change to the current hardware based implementations.

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

Cheers=2C Manav

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=

On Wed=2C Feb 25=2C 2015 at 2:43 AM=2C= Jeffrey Haas <=3Bjha= as@pfrc.org>=3B wrote:

=0A=

On Fri=2C Feb 13=2C 2015 at 10:31:43AM= -0800=2C Ashesh Mishra wrote:
=0A= >=3B Hi BFD Experts=2C
=0A= >=3B The 00 version of BFD Authentication Optimization draft is now onlin= e:
=0A= >=3B =0A= https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/
= =0A= >=3B The draft describes method for selectively authenticating certain BF= D frames to avoid computational overhead.
=0A=
=0A= I have perhaps a rather basic question which I'd been thinking on since it<= br>=0A= was said this draft may be coming:
=0A=
=0A= Is there any reason we couldn't simply use the non-meticulous versions of=0A= the keyed authentication and rely on caching?
=0A=
=0A= Essentially=2C in stable state BFD packets will be the same thing over and<= br>=0A= over again. =3B As long as the sequence number isn't increased=2C knowi= ng that a
=0A= given packet has passed authentication previously is sufficient if it's the=
=0A= same packet.
=0A=
=0A= Given how small BFD packets are=2C cache the entire packet? =3B Is the = memory at
=0A= that level of preciousness in the hardware implementations?
=0A=
=0A= Basically=2C in RFC 5880=2C section 6.8.6=2C at the procedural component th= at says
=0A= "MUST be authenticated"=2C once this step has completed for this sequence=0A= number and caching is determined to be okay=2C store the packet. =3B Wh= en the
=0A= sequence number is seen a second time and the authentication contents are=0A= the same=2C simply compare the bytes of the packet to the cache.
=0A=
=0A= I suspect I'm about to get a very strong reality check here. :-)
=0A=
=0A= -- Jeff

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
= --_c3125d7f-c3fc-47fa-9d18-786d43146d9f_--