From nobody Tue Sep 20 01:36:46 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C44F12B6CD for ; Tue, 20 Sep 2016 01:36:45 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eci365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VcRUtyPmxhD for ; Tue, 20 Sep 2016 01:36:42 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0123.outbound.protection.outlook.com [104.47.1.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761ED12B70E for ; Tue, 20 Sep 2016 01:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rRp1orTjiguUDe01S7iHh8yyo5CXzi9VKwG8Zw8eJOI=; b=e8+SmL9tFRO3f6g1g8EYEVhpVK6gaBygILhy/RNGMuEdWccn4reZT5J7d3GQKxIGIdJXK78RzUpwigjHR1f0w/AASAhfziKrCg9I/QOyj/m/eYhT9rr2mHpep44Ykn/7MgKYfObTw1De0CaLrKVSkSWAoG2oxGTitQG8fB22wrs= Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) by HE1PR0301MB2266.eurprd03.prod.outlook.com (10.168.31.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Tue, 20 Sep 2016 08:27:14 +0000 Received: from HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) by HE1PR0301MB2266.eurprd03.prod.outlook.com ([10.168.31.153]) with mapi id 15.01.0629.006; Tue, 20 Sep 2016 08:27:14 +0000 From: Alexander Vainshtein To: BFD WG Subject: Problematic text in RFC 5882 Thread-Topic: Problematic text in RFC 5882 Thread-Index: AdITGMkBxeS81riJTc2Fv6ed3vCMzQ== Date: Tue, 20 Sep 2016 08:27:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Vainshtein@ecitele.com; x-originating-ip: [147.234.241.1] x-ms-office365-filtering-correlation-id: 89edb97b-7cf9-4a63-226d-08d3e12fece2 x-microsoft-exchange-diagnostics: 1; HE1PR0301MB2266; 6:qjUwiRLKiC7fQb4aAXBiK5g8348itQ0lU/HPMZj/74NkzxO0UG1UzHlq0/xFShMsGIAhlnCfBfeXf4NLSDmy4AXg5v9mk79WSyUDjG8uUBRtBS9/xxSVGc7xlOnM2rXFRRGLe9nJl2+Ig5tSJP31gJpL+7HX/iTn6nyVMdF+P0VPp0V+YVV3Wx2zrKA5xK0IJjfnitwKWWzdzaggifjoyJ/TZDjfF6GCLz+BL6gcyz49DxD2FfDvBSp9wnk+xtIiBLPk9JH8YgJU+DxeU2vyvA3jl9f9JfPL+i4CeCLgNmS6PHmEpp5uQ3fMrl9W5C+QC5SBaYyEeb3kVh7HKHJe6w==; 5:gqsgJ1Bceuk2I0ahzN/vHcfBRTekY0E7fX6eMEAVc/lWEXMtq+CvBXnQ1MRNgBXtFx0rA8GMKWOobZG59KwfcAeg+oyo7GQg5Qg9p2rpPksEHjcP38aEBAQecxMNUcRasggOhMqHb01PBo6FgTBXlg==; 24:T5snPQGaVbXjQY5QODgH0QJ2iehSuvNJXLTmascf838CPaiH0M7gEXor/NgzChXjLw72msKduit0+SxOt25PCK090prA0xbmEdO4lUURrzw=; 7:7E3DqVSXLQrz6hmgL1GeGFl1IKE2qDEdFaAzajKPMgiU6r6cUdwfYcav4rFD9H0H4AlDxcBwCPWz3zsgusNmsaZj4F978iJ+UvYDrBxb04Anj+prXHY/TibMEt715wsep15J3aGDM3IwTGaCcA5V1RZHGGXr9OyF9Sm1lmptO3+nnKZxISQ4/+pkVkV4gncgd1/GRwxwnuDh02YtnWBjuT320T+gFUITzeSn6d/Ls1IBMcCLI2RMNVuM9iP2nULRcgpVf16gg9zZMX/WU0ISMVksSyLM0j2Qe4T5O0ayWf30pLr2E4k/yF95z04l2oOo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0301MB2266; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(279101305709854); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:HE1PR0301MB2266; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0301MB2266; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(53754006)(189002)(252514010)(199003)(5002640100001)(19580395003)(229853001)(16236675004)(105586002)(19580405001)(106356001)(101416001)(54356999)(50986999)(76576001)(86362001)(189998001)(19300405004)(33656002)(92566002)(19625215002)(11100500001)(8936002)(586003)(97736004)(3280700002)(3660700001)(74316002)(2906002)(10400500002)(7736002)(9686002)(81166006)(7696004)(68736007)(7846002)(107886002)(8676002)(6116002)(102836003)(790700001)(5660300001)(3846002)(15975445007)(77096005)(87936001)(66066001)(2900100001)(122556002)(110136003)(81156014)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0301MB2266; H:HE1PR0301MB2266.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0301MB22660CCAD20D2E3604C251089DF70HE1PR0301MB2266_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2016 08:27:14.1705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0301MB2266 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 08:36:45 -0000 --_000_HE1PR0301MB22660CCAD20D2E3604C251089DF70HE1PR0301MB2266_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have found the following problematic text in Section 10.1.2 of RFC 5882: If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology- specific path associated with a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) in order to signal a lack of connectivity. I suspect that LSP in this context stands for Link State Packet and not for= Label Switched Path. If my understanding is correct, is this observation worth an Editorial Erra= ta? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com --_000_HE1PR0301MB22660CCAD20D2E3604C251089DF70HE1PR0301MB2266_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have found the following problematic text in Section 10.1.2 of RFC 5882:

<quote>

   If multiple topologies are used t= o support multiple data protocols (or

   multiple classes of service of th= e same data protocol), the topology-

   specific path associated with a f= ailing BFD session should no longer

   be advertised in IS-IS Label Switched Paths= (LSPs) in order to signal

   a lack of connectivity.

<end quote>

 

I suspect that LSP in this context stands for Link State Packet and not for Label Switched Path.

 

If my understanding is correct, is this observation = worth an Editorial Errata?

 

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-5492663= 02

Email:   Alexander.Vainshtein@ecitele.com<= o:p>

 

--_000_HE1PR0301MB22660CCAD20D2E3604C251089DF70HE1PR0301MB2266_-- From nobody Tue Sep 20 05:17:45 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC9712B2DD for ; Tue, 20 Sep 2016 05:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.826 X-Spam-Level: X-Spam-Status: No, score=-16.826 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQZnKEJTsxg7 for ; Tue, 20 Sep 2016 05:17:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4037A12B2D8 for ; Tue, 20 Sep 2016 05:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10270; q=dns/txt; s=iport; t=1474373862; x=1475583462; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cDTH36HBo2OMWtwxhVJE6ni4YhroD8hFA6yK8BMpgKs=; b=lcsRC8g3Ya7fpJ8mgV+nXEun6R/CkBv4FmhM9Bn9stCFbuVkZGdTZEuN mS9PvgSwReLfDLWG1hks+H/vO1SeeMtS0HOz4wPsDg1zO1fgVNwpOaGFF nCzSqAppomOxKoAkrT944vHHvX91Uppik107cCn2ql0nqvFelL+LtxCsV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAgBTKOFX/4kNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgwc0AQEBAQEegVMHjSymM4UPggSGHgIcgUU4FAECAQEBAQEBAV4nhGI?= =?us-ascii?q?BAQQjVg4CAgEIPwMCAgIUHBQRAQEEDgWISrAqjEYBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEcBYYygXyCWIE8gloRATOCayuCLwWUGoVXAYknhjaPa4xkg3oBHjaDJYF?= =?us-ascii?q?ecoUDgSB/AQEB?= X-IronPort-AV: E=Sophos;i="5.30,367,1470700800"; d="scan'208,217";a="150961825" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2016 12:17:41 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8KCHfIg007223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Sep 2016 12:17:41 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 20 Sep 2016 08:17:40 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 20 Sep 2016 08:17:40 -0400 From: "Carlos Pignataro (cpignata)" To: Alexander Vainshtein Subject: Re: Problematic text in RFC 5882 Thread-Topic: Problematic text in RFC 5882 Thread-Index: AdITGMkBxeS81riJTc2Fv6ed3vCMzQAQbk4A Date: Tue, 20 Sep 2016 12:17:40 +0000 Message-ID: <8B0480FC-ABD9-4A12-9A9E-43597B82DB45@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.185] Content-Type: multipart/alternative; boundary="_000_8B0480FCABD94A129A9E43597B82DB45ciscocom_" MIME-Version: 1.0 Archived-At: Cc: BFD WG X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 12:17:43 -0000 --_000_8B0480FCABD94A129A9E43597B82DB45ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FzaGEsDQoNClRoYXTigJlzIGNvcnJlY3QsIGFuIGVkaXRvcmlhbCBtaXMtZXhwYW5zaW9u IG9mIHRoZSBhY3JvbnltIExTUC4gSXQgc2hvdWxkIGJlIOKAnExpbmsgU3RhdGUgUGFja2V04oCd Lg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCk9uIFNlcCAyMCwgMjAxNiwgYXQgNDoyNyBB TSwgQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t PG1haWx0bzpBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+IHdyb3RlOg0KDQpIaSBh bGwsDQpJIGhhdmUgZm91bmQgdGhlIGZvbGxvd2luZyBwcm9ibGVtYXRpYyB0ZXh0IGluIFNlY3Rp b24gMTAuMS4yIG9mIFJGQyA1ODgyOg0KPHF1b3RlPg0KICAgSWYgbXVsdGlwbGUgdG9wb2xvZ2ll cyBhcmUgdXNlZCB0byBzdXBwb3J0IG11bHRpcGxlIGRhdGEgcHJvdG9jb2xzIChvcg0KICAgbXVs dGlwbGUgY2xhc3NlcyBvZiBzZXJ2aWNlIG9mIHRoZSBzYW1lIGRhdGEgcHJvdG9jb2wpLCB0aGUg dG9wb2xvZ3ktDQogICBzcGVjaWZpYyBwYXRoIGFzc29jaWF0ZWQgd2l0aCBhIGZhaWxpbmcgQkZE IHNlc3Npb24gc2hvdWxkIG5vIGxvbmdlcg0KICAgYmUgYWR2ZXJ0aXNlZCBpbiBJUy1JUyBMYWJl bCBTd2l0Y2hlZCBQYXRocyAoTFNQcykgaW4gb3JkZXIgdG8gc2lnbmFsDQogICBhIGxhY2sgb2Yg Y29ubmVjdGl2aXR5Lg0KPGVuZCBxdW90ZT4NCg0KSSBzdXNwZWN0IHRoYXQgTFNQIGluIHRoaXMg Y29udGV4dCBzdGFuZHMgZm9yIExpbmsgU3RhdGUgUGFja2V0IGFuZCBub3QgZm9yIExhYmVsIFN3 aXRjaGVkIFBhdGguDQoNCklmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgaXMgdGhpcyBv YnNlcnZhdGlvbiB3b3J0aCBhbiBFZGl0b3JpYWwgRXJyYXRhPw0KDQoNClJlZ2FyZHMsDQpTYXNo YQ0KDQpPZmZpY2U6ICs5NzItMzkyNjYzMDINCkNlbGw6ICAgICAgKzk3Mi01NDkyNjYzMDINCkVt YWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4YW5kZXIu VmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4NCg0K --_000_8B0480FCABD94A129A9E43597B82DB45ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <91F5840743985241B878E4B5AFAF5D44@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgU2FzaGEsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGF04oCZcyBjb3JyZWN0 LCBhbiBlZGl0b3JpYWwgbWlzLWV4cGFuc2lvbiBvZiB0aGUgYWNyb255bSBMU1AuIEl0IHNob3Vs ZCBiZSDigJxMaW5rIFN0YXRlIFBhY2tldOKAnS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDIwLCAyMDE2LCBhdCA0OjI3IEFN LCBBbGV4YW5kZXIgVmFpbnNodGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFsZXhhbmRlci5WYWlu c2h0ZWluQGVjaXRlbGUuY29tIiBjbGFzcz0iIj5BbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxl PSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQpIaSBhbGwsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSSBoYXZlIGZvdW5kIHRo ZSBmb2xsb3dpbmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHllbGxvdzsgYmFja2dyb3VuZC1wb3Np dGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFs OyIgY2xhc3M9IiI+cHJvYmxlbWF0aWMgdGV4dDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+aW4NCiBTZWN0aW9uIDEwLjEuMiBvZiBSRkMgNTg4 Mjo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQombHQ7cXVvdGUmZ3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0iIj4m bmJzcDsmbmJzcDsgSWYgbXVsdGlwbGUgdG9wb2xvZ2llcyBhcmUgdXNlZCB0byBzdXBwb3J0IG11 bHRpcGxlIGRhdGEgcHJvdG9jb2xzIChvcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiIGNsYXNzPSIi PiZuYnNwOyZuYnNwOyBtdWx0aXBsZSBjbGFzc2VzIG9mIHNlcnZpY2Ugb2YgdGhlIHNhbWUgZGF0 YSBwcm90b2NvbCksIHRoZSB0b3BvbG9neS08bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0i Ij4mbmJzcDsmbmJzcDsgc3BlY2lmaWMgcGF0aCBhc3NvY2lhdGVkIHdpdGggYSBmYWlsaW5nIEJG RCBzZXNzaW9uIHNob3VsZCBubyBsb25nZXI8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IiBjbGFzcz0i Ij4mbmJzcDsmbmJzcDsgYmUgYWR2ZXJ0aXNlZCBpbiBJUy1JUzxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogeWVsbG93OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91 bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj5MYWJlbA0KIFN3aXRjaGVkIFBh dGhzPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4oTFNQcykgaW4gb3JkZXIgdG8gc2lnbmFsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9 IiI+Jm5ic3A7Jm5ic3A7IGEgbGFjayBvZiBjb25uZWN0aXZpdHkuPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZsdDtlbmQgcXVvdGUmZ3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K SSBzdXNwZWN0IHRoYXQgTFNQIGluIHRoaXMgY29udGV4dCBzdGFuZHMgZm9yPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kLWNvbG9yOiBsaW1lOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJh Y2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj5MaW5rIFN0YXRlIFBh Y2tldDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+YW5kDQogbm90IGZvcjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogeWVsbG93OyBiYWNrZ3JvdW5k LXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGlu aXRpYWw7IiBjbGFzcz0iIj5MYWJlbCBTd2l0Y2hlZCBQYXRoPC9zcGFuPi48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIGlz IHRoaXMgb2JzZXJ2YXRpb24gd29ydGggYW4gRWRpdG9yaWFsIEVycmF0YT88bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpSZWdhcmRzLDxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NClNhc2hhPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KT2ZmaWNl OiAmIzQzOzk3Mi0zOTI2NjMwMjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkNlbGw6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7OTcyLTU0OTI2NjMwMjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkVtYWlsOiZuYnNw OyZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20iIHN0eWxlPSJj b2xvcjogcmdiKDE0OSwgNzksIDExNCk7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208L2E+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_8B0480FCABD94A129A9E43597B82DB45ciscocom_-- From nobody Wed Sep 21 00:10:07 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F3112B0CF; Wed, 21 Sep 2016 00:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKFsVzj6qBXX; Wed, 21 Sep 2016 00:10:00 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C333212B0A8; Wed, 21 Sep 2016 00:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9060; q=dns/txt; s=iport; t=1474441799; x=1475651399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WUJVWvldcMU5DslKGIbeVUR7oNHQvh1PWhlf0HbJJ5M=; b=dOHAqJLay8iiMw3RohYcEnlu+dS1tyt2XA8zTZTedaY6gWWQ46BnM3pD vWpLF4FEJwZ/VSV7bJDt1HEdS15I2Ni0MHUa/Psh5ESVuO9ZgXpysX/Jv eWNLO+/6wJwtlD6wMm5N9S6euDEGTN3/khulWv//GGlBeI7fMHl9KqItA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAQCnMeJX/4wNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAR5XfAeNLKtFggQZC4V6AoFaOBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?hAQEBBAEBATc0CQIMBAIBCA4DBAEBAR4JBycLFAkIAgQBDQWISw66YQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARyGN4NPgQWEDQkRARyFXgWOM4tBAYYmiTqBbk6EFoM?= =?us-ascii?q?3hWOHBIVig3sBHjaDGBuBUHIBhE2BIH8BAQE?= X-IronPort-AV: E=Sophos;i="5.30,372,1470700800"; d="scan'208";a="326045798" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2016 07:09:58 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u8L79wK4024597 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Sep 2016 07:09:58 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 03:09:57 -0400 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1210.000; Wed, 21 Sep 2016 03:09:51 -0400 From: "Nitish Gupta (nitisgup)" To: Chris Bowers , "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Topic: New Version Notification for draft-nitish-vrrp-bfd-02.txt Thread-Index: AQHRBjYiTS9LHO0Rck2198aSpBcKKZ5+EmUAgHxbjACACWswAIABbJEAgYD7aIA= Date: Wed, 21 Sep 2016 07:09:51 +0000 Message-ID: References: <20151014040939.28122.79925.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.8.160830 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.232.12.98] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C8AE941FBC8304DBB16E17A77479926@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jeff Haas , "colin@doch.org.uk" , "Aditya Dogra \(addogra\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 07:10:02 -0000 Hi Chris, We have taken care of all the comments that WG had given on this draft and the below version of the draft has all the updates: URL: https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-04.txt Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-0= 4 Major updates that we have done in this version: 1. Added few Variables for VRRP Protocol for P2P mode of operation. 2. Included State Machine for VRRP in the case of P2P BFD mode of operation. Which outlines the details of how to form the Peer table and when to start and stop the BFD sessions. 3. We have also updated the p2mp Section with the comments that you had given, for the source ip to use in the P2mp BFD packets. We have also mentioned the state machine of VRRP in the mode of operation, Just to outline the interactions VRRP will have with Multipoint BFD. This is for making it explicit in the state machine. Although there is no update to the Protocol state machine in this case, we have mentioned this in the document. 4. IANA considerations updated in the document to allocate the namespace for VRRP Packet types. If there are no further comments on the draft we would like to ask the WG for Adoption. Looking forward to hearing from you. Thanks, Nitish On 20/01/16, 12:36 PM, "Nitish Gupta (nitisgup)" wrote: >Hi Chris, > >Thanks for your comments. We would like to take care of the comments you >have given before we ask the WG for adoption. > >Thanks, >Nitish > >On 20/01/16 1:23 am, "Chris Bowers" wrote: > >>Nitish and co-authors, >> >>I have read this draft and have several comments below. In general, I >>prefer that authors address outstanding comments in a new revision before >>we conduct a poll for adoption in RTGWG. Since an adoption poll usually >>triggers quite a few people read a draft in detail, it makes better use >>of the working groups time to have them reading the most up-to-date >>version. However, an argument could also be made for filling in some of >>the additional detail that I am asking for below after WG adoption >>(assuming it is adopted), when the WG has more direct control of the >>document. So I am open to either approach. >> >>So please respond to the feedback below and tell me if you would like to >>address some of it in a new revision before I conduct a poll for WG >>adoption, or if you would prefer to do the WG adoption poll using the >>current revision. There has also been feedback from others on this draft >>in response to your email, so you should respond to that as well. >> >>In general, I think the draft would benefit from specifying the VRRP >>state machine for this BFD mode of operation at the same level of detail >>that RFC5798 specifies the existing VRRP state machine. There are >>several places where it is probably possible to infer the correct >>behavior, but making it very explicit will make for a better document. >> >>1) Section 3.5 of this draft defines the Critical BFD session which is >>the BFD session between the VRRP Master and the next best VRRP backup. >>In the existing VRRP state machine, a VRRP router in the backup state is >>not able to determine if it is the next best VRRP backup. Presumably, in >>the VRRP state machine for the BFD mode of operation, a VRRP router in >>the backup state will look at the peer table populated by the Backup >>Advertisements and figure out which router is the next best VRRP router >>based on highest priority value with highest IPvX address as tie breaker. >> However, it would be better to be as explicit as RFC5798 about how this >>new state machine operates. >> >>2) Section 5 says that "To reduce the number of packets generated at a >>regular interval, Backup Advert packets may be sent at a reduced rate as >>compared to Advert packets sent by the VRRP Master." It seems that the >>state machine for VRRP BFD mode will have to be enhanced in some way to >>support this. One way to do this would be for each router to have a >>Backup_Advertisement_Interval which it uses to populate the Maximum >>Advertisement Interval in the BACKUP ADVERTISEMENT, and have each >>receiving router maintain a Peer_Advert_Interval(P) for each peer(P), and >>remove a peer entry when a BACKUP ADVERTISEMENT is not received from P >>for 3* Peer_Advert_Interval(P). But this is just one possible approach. >>In any case, it would be good to choose a mechanism and describe the >>corresponding state machine. >> >>3) The text should clarify how the VRRP state machine interacts with the >>BFD state machine. One can imagine scenarios where a BFD session stays >>up but the VRRP advertisements stop being received, or vice versa. This >>scenario is not very far-fetched because BFD may use unicast and VRRP >>uses multicast. Behavior can probably be inferred from existing text, >>but I think more precision is better here. >> >>4) I don't understand Section 4 which describes how to use p2mp BFD. >> >>A) The text says that "The Master router starts transmitting BFD control >>packets with VRID as source IP address." According to RFC5798, the VRID >>is an integer in the range from 1-255. Is the idea to encode the integer >>VRID as an IP address? Or should the BFD control packets be sent with >>the source IP address set to an IPvX address associated with the virtual >>router? Or are both used? In any case, it seems like this needs >>clarification. >> >>B) What is the destination IP address of the p2mp BFD control packet? Is >>it 224.0.0.18 or FF02:0:0:0:0:0:0:12, then IPv4 and IPv6 multicast >>addresses for VRRP? If so, this should be made explicit. >> >>C) Again, a state machine description would help readers and future >>implementers understand exactly what is intended. >> >>Thanks, >>Chris >> >>-----Original Message----- >>From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Nitish Gupta >>(nitisgup) >>Sent: Wednesday, January 13, 2016 3:31 AM >>To: rtgwg@ietf.org; rtg-bfd@ietf.org >>Cc: Gregory Mirsky ; Jeff Haas >>; colin@doch.org.uk; Aditya Dogra (addogra) >> >>Subject: Re: New Version Notification for draft-nitish-vrrp-bfd-02.txt >> >>Hi, >> >>We had presented the Draft for VRRP BFD integration in IETF 93 and we had >>taken care of all the comments that came as part of the WG meeting. >>We had also merged the two drafts as per the comments in IETF 93: >>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >> >>We had presented the merged draft in IETF 94 and there were no specific >>comments on the draft. >>We would like to ask the RTGWG to adopt the Draft as a WG document. >> >>Thanks, >>Nitish >> >> >>On 26/10/15 11:57 am, "Nitish Gupta (nitisgup)" >>wrote: >> >>>Hi, >>> >>>We have submitted a new version of the draft. As discussed in IETF 93 >>>at prague. >>> >>>We have merged the following drafts: >>>http://tools.ietf.org/html/draft-nitish-vrrp-bfd-01 >>> >>>https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-00 >>> >>> >>> >>>We have also taken care of all the comments that were discussed in the >>>RTGWG meeting. >>>We welcome any comments and suggestions on the draft. >>> >>>Thanks, >>>Nitish >>> >>>On 13/10/15 9:09 pm, "internet-drafts@ietf.org" >>> >>>wrote: >>> >>>> >>>>A new version of I-D, draft-nitish-vrrp-bfd-02.txt has been >>>>successfully submitted by Nitish Gupta and posted to the IETF >>>>repository. >>>> >>>>Name: draft-nitish-vrrp-bfd >>>>Revision: 02 >>>>Title: Fast failure detection in VRRP with BFD >>>>Document date: 2015-10-13 >>>>Group: Individual Submission >>>>Pages: 10 >>>>URL: =20 >>>>https://www.ietf.org/internet-drafts/draft-nitish-vrrp-bfd-02.txt >>>>Status: https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd/ >>>>Htmlized: https://tools.ietf.org/html/draft-nitish-vrrp-bfd-02 >>>>Diff: =20 >>>>https://www.ietf.org/rfcdiff?url2=3Ddraft-nitish-vrrp-bfd-02 >>>> >>>>Abstract: >>>> This document describes how Bidirectional Forwarding Detection (BFD) >>>> can be used to support sub-second detection of a Master Router >>>> failure in the Virtual Router Redundancy Protocol (VRRP). >>>> >>>> =20 >>>> =20 >>>> >>>> >>>>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 >>>> >>> >> >>_______________________________________________ >>rtgwg mailing list >>rtgwg@ietf.org >>https://www.ietf.org/mailman/listinfo/rtgwg > From nobody Tue Sep 27 08:12:34 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB55B12B379 for ; Tue, 27 Sep 2016 00:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qMv9EMZhNVq for ; Tue, 27 Sep 2016 00:33:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F42012B2BD for ; Tue, 27 Sep 2016 00:33:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 43556B80A7C; Tue, 27 Sep 2016 00:33:38 -0700 (PDT) To: dkatz@juniper.net, dward@juniper.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, jhaas@pfrc.org, rrahman@cisco.com Subject: [Editorial Errata Reported] RFC5882 (4812) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160927073338.43556B80A7C@rfc-editor.org> Date: Tue, 27 Sep 2016 00:33:38 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Tue, 27 Sep 2016 08:12:32 -0700 Cc: rtg-bfd@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 07:33:40 -0000 The following errata report has been submitted for RFC5882, "Generic Application of Bidirectional Forwarding Detection (BFD)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5882&eid=4812 -------------------------------------- Type: Editorial Reported by: Alexander ("Sasha") Vainshtein Section: 10.1.2 Original Text ------------- IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology- specific path associated with a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) in order to signal a lack of connectivity. Corrected Text -------------- IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology- specific path associated with a failing BFD session should no longer be advertised in IS-IS Link State Packets (LSPs) in order to signal a lack of connectivity. Notes ----- In the context of this section (that discusses usage of BFD sessions for detection of failure of an IS-IS adjacency) the abbreviation "LSP" should be expanded as "Link State Packet" and not as "Label Switched Path". >From my POV this is an editorial erratum since I believe the readers of the RFC understand what the authors wanted to say. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5882 (draft-ietf-bfd-generic-05) -------------------------------------- Title : Generic Application of Bidirectional Forwarding Detection (BFD) Publication Date : June 2010 Author(s) : D. Katz, D. Ward Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Sep 27 09:22:09 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA64F12B2AD; Tue, 27 Sep 2016 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8meeiyeHsn3; Tue, 27 Sep 2016 09:22:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6268C12B2A9; Tue, 27 Sep 2016 09:22:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5B615B8168A; Tue, 27 Sep 2016 09:22:06 -0700 (PDT) To: Alexander.Vainshtein@ecitele.com, dkatz@juniper.net, dward@juniper.net Subject: [Errata Held for Document Update] RFC5882 (4812) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160927162206.5B615B8168A@rfc-editor.org> Date: Tue, 27 Sep 2016 09:22:06 -0700 (PDT) Archived-At: Cc: rtg-bfd@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 27 Sep 2016 16:22:08 -0000 The following errata report has been held for document update for RFC5882, "Generic Application of Bidirectional Forwarding Detection (BFD)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5882&eid=4812 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Alexander ("Sasha") Vainshtein Date Reported: 2016-09-27 Held by: Alvaro Retana (IESG) Section: 10.1.2 Original Text ------------- IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology- specific path associated with a failing BFD session should no longer be advertised in IS-IS Label Switched Paths (LSPs) in order to signal a lack of connectivity. Corrected Text -------------- IS-IS may be used to support only one data protocol, or multiple data protocols. [ISIS] specifies a common topology for multiple data protocols, but work is under way to support multiple topologies. If multiple topologies are used to support multiple data protocols (or multiple classes of service of the same data protocol), the topology- specific path associated with a failing BFD session should no longer be advertised in IS-IS Link State Packets (LSPs) in order to signal a lack of connectivity. Notes ----- In the context of this section (that discusses usage of BFD sessions for detection of failure of an IS-IS adjacency) the abbreviation "LSP" should be expanded as "Link State Packet" and not as "Label Switched Path". >From my POV this is an editorial erratum since I believe the readers of the RFC understand what the authors wanted to say. -------------------------------------- RFC5882 (draft-ietf-bfd-generic-05) -------------------------------------- Title : Generic Application of Bidirectional Forwarding Detection (BFD) Publication Date : June 2010 Author(s) : D. Katz, D. Ward Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Sep 29 08:44:16 2016 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B136912B18C; Thu, 29 Sep 2016 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6SsNxvdfDWZ; Thu, 29 Sep 2016 08:44:09 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0127.outbound.protection.outlook.com [104.47.37.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A0012B134; Thu, 29 Sep 2016 08:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SgPTnlrpnXnwAKlW/ubxebpfbE1CHJii8B2dBDIOkd8=; b=fOlGD4oPr4xcKXxOcnj1v5mNtqHLifIEVAIMAT1iZajWKoAb+l52R05o2+DCInJw1CWGa9v1hZ1vLsj7LDin4x55Nkm7LQXMlw5XfSUnA/rbNBmcmJb16FO4jwk1U/+YegcMQEpvyz1kyhmz9DId4ELy9RSd+hHWFriAxB3k2y4= Received: from MWHPR05MB2829.namprd05.prod.outlook.com (10.168.245.11) by MWHPR05MB2831.namprd05.prod.outlook.com (10.168.245.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6; Thu, 29 Sep 2016 15:44:06 +0000 Received: from MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) by MWHPR05MB2829.namprd05.prod.outlook.com ([10.168.245.11]) with mapi id 15.01.0649.016; Thu, 29 Sep 2016 15:44:06 +0000 From: Chris Bowers To: "rtgwg@ietf.org" , "rtg-bfd@ietf.org" Subject: WG adoption poll on draft-nitish-vrrp-bfd-04 Thread-Topic: WG adoption poll on draft-nitish-vrrp-bfd-04 Thread-Index: AdIaZGPlJxb+ITrzQuavzBeZL6nhIQ== Date: Thu, 29 Sep 2016 15:44:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=cbowers@juniper.net; x-originating-ip: [66.129.239.12] x-ms-office365-filtering-correlation-id: 845f446b-2cad-4546-b09e-08d3e87f7280 x-microsoft-exchange-diagnostics: 1; MWHPR05MB2831; 7:mFrdpnHP3XPoeIkzK2Yn99izChgmTl4z/uRyW58/QabR6p6xHrebYy/76+ODR7tTTqwo485exMfVLVgcsYFiH5Q/ZYWccLJfyqOPyqNRmFFH2iy6lfTsKit06h950epurnLG24YW6MJLdstr5L96TmhHhArPmMrsFA2VNVdRxetZ+PIj+sr3xnMzqJrb3OZgE+aFbOlUxlL+rQetWhAix59aShxe1IPfycGsIptGw9cjgVv9sS337y7NAYQp1f4rHgmBMfYQyRl65pe/N5rZ1Gl5R71RYUR5tFb3lK+qJS9LUlINc9t3BOAlakyzJZCSbiysYmjDnUo3rDUv7/pHNw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR05MB2831; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:MWHPR05MB2831; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2831; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(11100500001)(9686002)(107886002)(77096005)(189998001)(92566002)(8936002)(15975445007)(122556002)(6116002)(76576001)(450100001)(2501003)(102836003)(3846002)(586003)(97736004)(2906002)(5001770100001)(81156014)(8676002)(7736002)(81166006)(5660300001)(7696004)(10400500002)(305945005)(7846002)(86362001)(74316002)(66066001)(19580395003)(54356999)(19580405001)(33656002)(50986999)(101416001)(68736007)(5002640100001)(229853001)(105586002)(99286002)(3280700002)(3660700001)(2900100001)(230783001)(87936001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2831; H:MWHPR05MB2829.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR05MB282912503287BCA31D5B5E46A9CE0MWHPR05MB2829namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2016 15:44:06.7037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2831 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 15:44:12 -0000 --_000_MWHPR05MB282912503287BCA31D5B5E46A9CE0MWHPR05MB2829namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RTGWG, This email starts a two week poll to gauge consensus on adopting draft-niti= sh-vrrp-bfd-04 as an RTGWG working group document. The BFD working group is also copied on this adoption poll. We encourage p= articipants in BFD working group to provide their input on the adoption poll. And should = this document be adopted as an RTGWG document, we would plan to copy the BFD WG on emails related to this document to benefit from the BFD expertise in that WG in th= e development of this document. Please send your comments to the RTGWG mailing list (rtgwg@ietf.org) indicating support or opposition to the adoption of this document, along with the reasoning fo= r that support or opposition. If you are listed as a document author or contributor, please respond to th= is email stating whether or not you are aware of any relevant IPR. The response needs to b= e sent to the RTGWG mailing list. The document will not advance to the next stage until a= response has been received from each author and each individual that has contributed to = the document. At this point, the document has the following IPR disclosure associated wit= h it. https://datatracker.ietf.org/ipr/2739/ This adoption poll will end on Friday October 14th. Thanks, Chris and Jeff --_000_MWHPR05MB282912503287BCA31D5B5E46A9CE0MWHPR05MB2829namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
RTGWG,
 
This email starts a two week poll to gauge consensus on adopting draft= -nitish-vrrp-bfd-04
as an RTGWG working group document.
 
The BFD working group is also copied on this adoption poll.  We e= ncourage participants in
BFD working group to provide their input on the adoption poll.  A= nd should this document
be adopted as an RTGWG document, we would plan to copy the BFD WG on e= mails
related to this document to benefit from the BFD expertise in that WG = in the development
of this document.
 
Please send your comments to the RTGWG mailing list (rtgwg@ietf.org) = indicating support
or opposition to the adoption of this document, along with the reasoni= ng for that support
or opposition. 
 
If you are listed as a document author or contributor, please respond = to this email stating
whether or not you are aware of any relevant IPR.   The resp= onse needs to be sent to the
RTGWG mailing list. The document will not advance to the next stage un= til a response has
been received from each author and each individual that has contribute= d to the document.
 
At this point, the document has the following IPR disclosure associate= d with it.
 
This adoption poll will end on Friday October 14th.
 
Thanks,
Chris and Jeff
 
 
 --_000_MWHPR05MB282912503287BCA31D5B5E46A9CE0MWHPR05MB2829namp_-- From nobody Thu Sep 29 10:36:51 2016 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08F12B1F4; Thu, 29 Sep 2016 10:36:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: bfd - Not having a session at IETF 97 X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147517060944.18467.18058747413149793235.idtracker@ietfa.amsl.com> Date: Thu, 29 Sep 2016 10:36:49 -0700 Archived-At: Cc: rtg-bfd@ietf.org, bfd-chairs@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 17:36:49 -0000 Jeffrey Haas, a chair of the bfd working group, indicated that the bfd working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool.