From nobody Fri Oct 3 08:59:37 2014 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 49A351A0379; Fri, 3 Oct 2014 08:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 fz41QjBdAcCA; Fri, 3 Oct 2014 08:59:28 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB14F1A037F; Fri, 3 Oct 2014 08:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2460; q=dns/txt; s=iport; t=1412351966; x=1413561566; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vi43q8F8StGOOhejq1uUu24Dzq6+7cNJx79MNPkdeHI=; b=IXlY21qnS4MA3DZ4mtpSo5kNJ4wV5eVoSEOb7OBiL3eb0lHvBWzXileW bHtkYP8ZQ4CItWxi+X7z2mMc/qWQMAdt5f8XSJ/prFv875Jq7cmJgbRSo 1ThwAZmf9JLEhR1Wn8iWnb+VgT0P2hskxR/cBbcgoy7/GxSWxNLYxNbX6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFABnHLlStJV2b/2dsb2JhbABggw5TWASCfsgDh0sCGXQWAXuEAwEBAQQjEUMCDAQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEAQ0FCAGINQ2pSpVtAReBLI5RBisHBAKCcTaBHgWRdIQ8iDs7gweREYNjbAGBR4ECAQEB X-IronPort-AV: E=Sophos;i="5.04,647,1406592000"; d="scan'208";a="83821621" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 03 Oct 2014 15:59:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s93FxPTF030820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Oct 2014 15:59:25 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 3 Oct 2014 10:59:25 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "mpls@ietf.org" Subject: FW: New Version Notification for draft-grmas-bfd-rfc5884-clarifications-00.txt Thread-Topic: New Version Notification for draft-grmas-bfd-rfc5884-clarifications-00.txt Thread-Index: AQHP3xB2zMbNL6+ypkangFD1rnC1p5wehltw Date: Fri, 3 Oct 2014 15:59:25 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D346A9D9E@xmb-rcd-x15.cisco.com> References: <20141003134634.31923.87610.idtracker@ietfa.amsl.com> In-Reply-To: <20141003134634.31923.87610.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.216.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IwNrA_omSSb5PxCrC7VEG1BfPY8 Cc: "kalyani.rajaraman@ericsson.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: Fri, 03 Oct 2014 15:59:34 -0000 SGVsbG8gYWxsLA0KICBBIG5ldyBkcmFmdCAoZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtY2xhcmlm aWNhdGlvbnMpIGhhcyBiZWVuIHN1Ym1pdHRlZCBiYXNlZCBvbiBkaXNjdXNzaW9ucyBhdCBJRVRG LTkwIGZvciBkcmFmdC12Z292aW5kYW4tbXBscy1leHRlbmRlZC1iZmQtZGlzYy10bHYuIFBsZWFz ZSBub3RlIHRoYXQgdGhlIGxhdHRlciB3aWxsIGJlIGRpc2NvbnRpbnVlZC4gQ29tbWVudHMvIFJl dmlld3MgYXJlIHdlbGNvbWUgZm9yIGRyYWZ0LWdybWFzLWJmZC1yZmMtNTg4NC1jbGFyaWZpY2F0 aW9ucy4NCi0gQXV0aG9ycw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IEZyaWRheSwgT2N0b2JlciAwMywgMjAxNCA3OjE3IFBNDQpUbzogTm9ibyBBa2l5YSAo bm9ibyk7IFNhbSBBbGRyaW47IEdyZWcgTWlyc2t5OyBHcmVnb3J5IE1pcnNreTsgS2FseWFuaSBS YWphcmFtYW47IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IE5vYm8gQWtpeWEg KG5vYm8pOyBWZW5nYWRhIFByYXNhZCBHb3ZpbmRhbiAodmVuZ2dvdmkpOyBLYWx5YW5pIFJhamFy YW1hbjsgU2FtIEFsZHJpbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1ncm1hcy1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtY2xhcmlmaWNhdGlvbnMtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJhc2FkIEdv dmluZGFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0 LWdybWFzLWJmZC1yZmM1ODg0LWNsYXJpZmljYXRpb25zDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJ Q2xhcmlmaWNhdGlvbnMgdG8gUkZDIDU4ODQNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMDMNCkdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTYNClVSTDogICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ncm1hcy1iZmQtcmZjNTg4 NC1jbGFyaWZpY2F0aW9ucy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ncm1hcy1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncm1hcy1i ZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1 bWVudCBjbGFyaWZpZXMgdGhlIHByb2NlZHVyZXMgZm9yIGVzdGFibGlzaGluZywgbWFpbnRhaW5p bmcNCiAgIGFuZCByZW1vdmluZyBtdWx0aXBsZSwgY29uY3VycmVudCBCRkQgc2Vzc2lvbnMgZm9y IGEgZ2l2ZW4gPE1QTFMgTFNQLA0KICAgRkVDPiBkZXNjcmliZWQgaW4gUkZDNTg4NC4NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Oct 6 05:52:09 2014 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 C08BB1A6F13 for ; Mon, 6 Oct 2014 05:52:08 -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, 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 onM9Bv7QeLLS for ; Mon, 6 Oct 2014 05:52:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E310F1A6F12 for ; Mon, 6 Oct 2014 05:52:06 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 6 Oct 2014 12:51:43 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1024.012; Mon, 6 Oct 2014 12:51:43 +0000 From: Santosh P K To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThA= Date: Mon, 6 Oct 2014 12:51:42 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> In-Reply-To: <20140819140828.GJ30106@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(189002)(53754006)(199003)(377454003)(377424004)(97736003)(85852003)(66066001)(19580405001)(76576001)(20776003)(2656002)(15975445006)(15202345003)(86362001)(64706001)(4396001)(19580395003)(92566001)(33646002)(108616004)(107886001)(107046002)(95666004)(99286002)(10300001)(85306004)(46102003)(120916001)(40100001)(76482002)(74316001)(99396003)(101416001)(105586002)(80022003)(230783001)(87936001)(31966008)(21056001)(76176999)(50986999)(122556001)(106356001)(54356999)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JtSa5laqRfSDGj7OKnHpcGitUso 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, 06 Oct 2014 12:52:08 -0000 Hello All, I am seeking comments on active tale section of this document. I spoke t= o few implementers and found that no one really finds use case for active t= ale. Does anyone on this forum feel that we might need active tale? If ther= e are no uses cases then we can move active tale section to appendix? We wo= uld like to make all the changes before IETF 91 and push this for RFC. Any = suggestions? Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, August 19, 2014 7:38 PM To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Note that this consists mostly of a re-publish with Santosh as the new edit= or. (And moving from .nroff to .xml.) In the next few weeks, Santosh will be working with known implementors to e= dit the document to match implementation. Ideally these edits will be comp= lete prior to the next IETF session in Honolulu. This will put us a bit pa= st our original milestone for publication, but still much better on track t= han many of our previous documents. -- Jeff On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Work= ing Group of the IETF. >=20 > Title : BFD for Multipoint Networks > Authors : Dave Katz > Dave Ward > Santosh Pallagatti > Filename : draft-ietf-bfd-multipoint-04.txt > Pages : 27 > Date : 2014-08-12 >=20 > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol for its use in multipoint and multicast > networks. Comments on this draft should be directed to rtg- > bfd@ietf.org. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 06:27:07 2014 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 A62BD1A6F42 for ; Mon, 6 Oct 2014 06:27:05 -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, 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 HFRq7E3SOB3s for ; Mon, 6 Oct 2014 06:27:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631781A6F40 for ; Mon, 6 Oct 2014 06:27:03 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 6 Oct 2014 13:27:01 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1024.012; Mon, 6 Oct 2014 13:27:01 +0000 From: Santosh P K To: Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsA== Date: Mon, 6 Oct 2014 13:27:01 +0000 Message-ID: <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03569407CC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377424004)(189002)(13464003)(24454002)(51704005)(53754006)(199003)(377454003)(85306004)(40100001)(74316001)(76482002)(120916001)(46102003)(108616004)(99286002)(10300001)(95666004)(107886001)(107046002)(31966008)(106116001)(54356999)(106356001)(50986999)(21056001)(76176999)(122556001)(105586002)(80022003)(101416001)(99396003)(230783001)(87936001)(1941001)(15975445006)(20776003)(2656002)(85852003)(66066001)(97736003)(19580405001)(76576001)(64706001)(4396001)(92566001)(33646002)(19580395003)(15202345003)(86362001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8L9MQOYA3B8E6nT6Z9tFwXYk1tY 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, 06 Oct 2014 13:27:05 -0000 Sorry for typo in my precious mail "active tale" it is "active tail". Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, October 06, 2014 6:22 PM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello All, I am seeking comments on active tale section of this document. I spoke t= o few implementers and found that no one really finds use case for active t= ale. Does anyone on this forum feel that we might need active tale? If ther= e are no uses cases then we can move active tale section to appendix? We wo= uld like to make all the changes before IETF 91 and push this for RFC. Any = suggestions? Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, August 19, 2014 7:38 PM To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Note that this consists mostly of a re-publish with Santosh as the new edit= or. (And moving from .nroff to .xml.) In the next few weeks, Santosh will be working with known implementors to e= dit the document to match implementation. Ideally these edits will be comp= lete prior to the next IETF session in Honolulu. This will put us a bit pa= st our original milestone for publication, but still much better on track t= han many of our previous documents. -- Jeff On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Work= ing Group of the IETF. >=20 > Title : BFD for Multipoint Networks > Authors : Dave Katz > Dave Ward > Santosh Pallagatti > Filename : draft-ietf-bfd-multipoint-04.txt > Pages : 27 > Date : 2014-08-12 >=20 > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol for its use in multipoint and multicast > networks. Comments on this draft should be directed to rtg- > bfd@ietf.org. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 6 13:47:34 2014 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 58BD61A89C7 for ; Mon, 6 Oct 2014 13:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 dczURSUZh4Mi for ; Mon, 6 Oct 2014 13:47:31 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F8F1A89A3 for ; Mon, 6 Oct 2014 13:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=694; q=dns/txt; s=iport; t=1412628451; x=1413838051; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9Flsi5DspZ1jNApPa2zsDNQWtWB1iRXNVd4kB0eGg+M=; b=io3X6djsJK+l+kZcDKATwzC6I5WqlGqXIuU8NLWpwNWc3my+bkZ2ho7v 2kS0PCRFs5WlahZfp1mnfxT9zCzn38pmRmn6hJxAF+v7GRLNSL/sRgkqZ y8jjgiLfhRfJPE11KYSencQS2rno/0i4RrdgsXmjXd72UrmT1JRexC1v5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEGAFv/MlStJV2b/2dsb2JhbABfgmsjgS/TbQKBBhYBcgmEBQEEHR00HQEqFEImAQQbiDYBnRakHwEXj2MRAR+DZYEeBY9aghqMd4NCkRGDY4F7OYECAQEB X-IronPort-AV: E=Sophos;i="5.04,665,1406592000"; d="scan'208";a="84517786" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 06 Oct 2014 20:47:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s96KlVRm010129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Oct 2014 20:47:31 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 15:47:30 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Meeting in Honolulu for IETF 91 - Call for Presentations Thread-Topic: Meeting in Honolulu for IETF 91 - Call for Presentations Thread-Index: Ac/hpmP5Jycw+1mNQqCu/W4pCy/SRA== Date: Mon, 6 Oct 2014 20:47:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zH-B-sfxrztgqKEZ34MpOfYgT9M 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, 06 Oct 2014 20:47:33 -0000 Hi BFD WG, The WG chairs have determined we have enough items to warrant a meeting at = the upcoming IETF in Honolulu. If you have a topic you'd like to discuss at the meeting, please email the = chairs along with following information. 1) Draft title 2) Presenter name 3) Requested duration As always, we're looking to keep the sessions short and focused on discussi= on rather than reading from slides. New proposals should be backed by Inter= net-Drafts and discussion ideally should be initiated on the mailing list f= irst. Note: 2014-10-27 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59 Thanks! - Nobo and Jeff From nobody Thu Oct 9 08:38:16 2014 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 5B3661A6F0E for ; Thu, 9 Oct 2014 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 NRLNlmgf-g5Q for ; Thu, 9 Oct 2014 08:38:13 -0700 (PDT) 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 37D8B1A1B75 for ; Thu, 9 Oct 2014 08:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4316; q=dns/txt; s=iport; t=1412869093; x=1414078693; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=41jDz/u4nhTzoZe0UqKoJ6hiEZjQN1ZnUJbaJWwWw8M=; b=AghOnfgG930GZGKNWE/pOMBOggUCj47jc8JEDthH5Yzbry9nb5v1fJjN d93l+80HjphRBonZJQtFEisTTvLaAA9D2L+pQ9CowZ02QZN17GvQUxKcd 7AG+XOEl/ABeHS4iF7Z/EfpHKCtG2rIyA4/g8LPmMPi8ZIs3cCc2Z4iHa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAC6rNlStJV2T/2dsb2JhbABggmsjU1MFBMsWh00CgQcWAXuEAwEBAQQ6SwQCAQgRBAEBAQoUCQcyFAkIAgQBEggBiDUBBwXDCwEXj3MBAR44BoMngR4Fj1+CGoRCiD48gwqNH4N+g2NsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,685,1406592000"; d="scan'208";a="362071386" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 09 Oct 2014 15:38:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s99FcCGk015859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 15:38:12 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 10:38:12 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUPZOBPokD+keyL4hHqvmqqpvYS1kAgEtadQCAAAnegIAEgS9g Date: Thu, 9 Oct 2014 15:38:11 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_MAHwyqAia2NhaZKfOgtihnr8xU 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, 09 Oct 2014 15:38:15 -0000 [With Chair Hat On] Dear WG, The topic of keeping or removing the active tail from draft-ietf-bfd-multip= oint is one of the last couple of topics that we, as a WG, need to resolve = for this document. Whether or not we keep or remove the active tail, leaves will be able to de= tect the failure of the multicast tree, which allows protections such as li= ve-live. What is essentially different: Keeping the active tail - Allows ingress/root to keep track of leaves. Removing the active tail - Ingress/root will not be able to keep track of l= eaves. If there's any requirements for the ingress/root to trigger some protection= s, then active tail becomes a requirement. If there is no such requirements= , then the active tail is an unnecessary portion of this document. It'll be beneficial to hear your thoughts/comments to help gauge where we a= re on this matter as a WG. Comments/thoughts? Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, October 06, 2014 9:27 AM > To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Sorry for typo in my precious mail "active tale" it is "active tail". >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K > Sent: Monday, October 06, 2014 6:22 PM > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > I am seeking comments on active tale section of this document. I spoke= to > few implementers and found that no one really finds use case for active t= ale. > Does anyone on this forum feel that we might need active tale? If there a= re > no uses cases then we can move active tale section to appendix? We would > like to make all the changes before IETF 91 and push this for RFC. Any > suggestions? >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, August 19, 2014 7:38 PM > To: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Note that this consists mostly of a re-publish with Santosh as the new ed= itor. > (And moving from .nroff to .xml.) >=20 > In the next few weeks, Santosh will be working with known implementors to > edit the document to match implementation. Ideally these edits will be > complete prior to the next IETF session in Honolulu. This will put us a = bit > past our original milestone for publication, but still much better on tra= ck > than many of our previous documents. >=20 > -- Jeff >=20 >=20 >=20 > On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > > > Title : BFD for Multipoint Networks > > Authors : Dave Katz > > Dave Ward > > Santosh Pallagatti > > Filename : draft-ietf-bfd-multipoint-04.txt > > Pages : 27 > > Date : 2014-08-12 > > > > Abstract: > > This document describes extensions to the Bidirectional Forwarding > > Detection (BFD) protocol for its use in multipoint and multicast > > networks. Comments on this draft should be directed to rtg- > > bfd@ietf.org. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 11:58:44 2014 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 782301A1A83 for ; Thu, 9 Oct 2014 11:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 UhRoIDDrSZPm for ; Thu, 9 Oct 2014 11:58:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBC81A1A80 for ; Thu, 9 Oct 2014 11:58:40 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 1D0758306F6B7; Thu, 9 Oct 2014 18:58:35 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s99Iwb0N000425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 20:58:37 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 20:58:37 +0200 From: "Henderickx, Wim (Wim)" To: "Nobo Akiya (nobo)" , Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUPZOBPokD+keyL4hHqvmqqpvYS1kAgEtadQCAAAnegIAEgS9ggAA+kgA= Date: Thu, 9 Oct 2014 18:58:36 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ud2zXfGy9IeYhHr96J7EU9-Cak 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, 09 Oct 2014 18:58:42 -0000 In certain environment the tracking of the tails is happening by other means. Example is Multicast VPN using MP-BGP. On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: >[With Chair Hat On] > >Dear WG, > >The topic of keeping or removing the active tail from >draft-ietf-bfd-multipoint is one of the last couple of topics that we, as >a WG, need to resolve for this document. > >Whether or not we keep or remove the active tail, leaves will be able to >detect the failure of the multicast tree, which allows protections such >as live-live. > >What is essentially different: > >Keeping the active tail - Allows ingress/root to keep track of leaves. > >Removing the active tail - Ingress/root will not be able to keep track of >leaves. > >If there's any requirements for the ingress/root to trigger some >protections, then active tail becomes a requirement. If there is no such >requirements, then the active tail is an unnecessary portion of this >document. > >It'll be beneficial to hear your thoughts/comments to help gauge where we >are on this matter as a WG. > >Comments/thoughts? > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, October 06, 2014 9:27 AM >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Sorry for typo in my precious mail "active tale" it is "active tail". >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, October 06, 2014 6:22 PM >> To: Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Hello All, >> I am seeking comments on active tale section of this document. I >>spoke to >> few implementers and found that no one really finds use case for active >>tale. >> Does anyone on this forum feel that we might need active tale? If there >>are >> no uses cases then we can move active tale section to appendix? We would >> like to make all the changes before IETF 91 and push this for RFC. Any >> suggestions? >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>Haas >> Sent: Tuesday, August 19, 2014 7:38 PM >> To: rtg-bfd@ietf.org >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Note that this consists mostly of a re-publish with Santosh as the new >>editor. >> (And moving from .nroff to .xml.) >>=20 >> In the next few weeks, Santosh will be working with known implementors >>to >> edit the document to match implementation. Ideally these edits will be >> complete prior to the next IETF session in Honolulu. This will put us >>a bit >> past our original milestone for publication, but still much better on >>track >> than many of our previous documents. >>=20 >> -- Jeff >>=20 >>=20 >>=20 >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org >>wrote: >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Bidirectional Forwarding Detection >> Working Group of the IETF. >> > >> > Title : BFD for Multipoint Networks >> > Authors : Dave Katz >> > Dave Ward >> > Santosh Pallagatti >> > Filename : draft-ietf-bfd-multipoint-04.txt >> > Pages : 27 >> > Date : 2014-08-12 >> > >> > Abstract: >> > This document describes extensions to the Bidirectional Forwarding >> > Detection (BFD) protocol for its use in multipoint and multicast >> > networks. Comments on this draft should be directed to rtg- >> > bfd@ietf.org. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ > From nobody Thu Oct 9 18:32:12 2014 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 A51CD1A87E4 for ; Thu, 9 Oct 2014 18:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 qqn466ynw_nJ for ; Thu, 9 Oct 2014 18:32:07 -0700 (PDT) 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 1793D1AD045 for ; Thu, 9 Oct 2014 18:32:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNM28885; Fri, 10 Oct 2014 01:32:04 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Oct 2014 02:32:03 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 09:31:57 +0800 From: Mingui Zhang To: "Nobo Akiya (nobo)" , Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hWKEpQ2rtLyk+1UKjzaDPn65vXcWwAgEtadACAAAnegIAE26WAgAEl5ZA= Date: Fri, 10 Oct 2014 01:31:56 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AAC0A1C@nkgeml512-mbx.china.huawei.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ZiZZ9R2Ku_vROYO-e3_dZAY3h7U 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, 10 Oct 2014 01:32:09 -0000 I think the "keeping the active tail" choice can help the ingress/root to p= erform global protection. Additionally, it's possible to achieve a more bal= anced load distribution among multiple trees (there might be more than two = available trees) if the ingress/root has knowledge of the active tail.=20 Thanks, Mingui >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (n= obo) >Sent: Thursday, October 09, 2014 11:38 PM >To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >[With Chair Hat On] > >Dear WG, > >The topic of keeping or removing the active tail from draft-ietf-bfd-multi= point is >one of the last couple of topics that we, as a WG, need to resolve for thi= s >document. > >Whether or not we keep or remove the active tail, leaves will be able to d= etect >the failure of the multicast tree, which allows protections such as live-l= ive. > >What is essentially different: > >Keeping the active tail - Allows ingress/root to keep track of leaves. > >Removing the active tail - Ingress/root will not be able to keep track of = leaves. > >If there's any requirements for the ingress/root to trigger some protectio= ns, >then active tail becomes a requirement. If there is no such requirements, = then >the active tail is an unnecessary portion of this document. > >It'll be beneficial to hear your thoughts/comments to help gauge where we = are >on this matter as a WG. > >Comments/thoughts? > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, October 06, 2014 9:27 AM >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Sorry for typo in my precious mail "active tale" it is "active tail". >> >> Thanks >> Santosh P K >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K >> Sent: Monday, October 06, 2014 6:22 PM >> To: Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Hello All, >> I am seeking comments on active tale section of this document. I spok= e to >> few implementers and found that no one really finds use case for active = tale. >> Does anyone on this forum feel that we might need active tale? If there = are >> no uses cases then we can move active tale section to appendix? We would >> like to make all the changes before IETF 91 and push this for RFC. Any >> suggestions? >> >> Thanks >> Santosh P K >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haa= s >> Sent: Tuesday, August 19, 2014 7:38 PM >> To: rtg-bfd@ietf.org >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Note that this consists mostly of a re-publish with Santosh as the new e= ditor. >> (And moving from .nroff to .xml.) >> >> In the next few weeks, Santosh will be working with known implementors t= o >> edit the document to match implementation. Ideally these edits will be >> complete prior to the next IETF session in Honolulu. This will put us a= bit >> past our original milestone for publication, but still much better on tr= ack >> than many of our previous documents. >> >> -- Jeff >> >> >> >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote= : >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Bidirectional Forwarding Detection >> Working Group of the IETF. >> > >> > Title : BFD for Multipoint Networks >> > Authors : Dave Katz >> > Dave Ward >> > Santosh Pallagatti >> > Filename : draft-ietf-bfd-multipoint-04.txt >> > Pages : 27 >> > Date : 2014-08-12 >> > >> > Abstract: >> > This document describes extensions to the Bidirectional Forwarding >> > Detection (BFD) protocol for its use in multipoint and multicast >> > networks. Comments on this draft should be directed to rtg- >> > bfd@ietf.org. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 18:45:49 2014 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 AEE321AD051 for ; Thu, 9 Oct 2014 18:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OasXobZnASnY for ; Thu, 9 Oct 2014 18:45:46 -0700 (PDT) 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 9226E1AD050 for ; Thu, 9 Oct 2014 18:45:46 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-fc-5436e340f24a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 82.70.05330.043E6345; Thu, 9 Oct 2014 21:34:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 21:45:35 -0400 From: Gregory Mirsky To: Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUJnl0CAJJIkO/ChgaGBADZJvX94gAgEtaThCAAE0TgIAFQS9Q Date: Fri, 10 Oct 2014 01:45:35 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B859643@eusaamb103.ericsson.se> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.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: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B859643eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPuK7DY7MQg85z0hb7D75ltfj8Zxuj xbW7W5kdmD2WLPnJ5HG96Sq7x+XerawBzFFcNimpOZllqUX6dglcGb+bvjIW3Amt+PHrPlsD 41ePLkZODgkBE4np/88wQ9hiEhfurWfrYuTiEBI4yiixdedDKGcZo8TULw9ZQarYBIwkXmzs Ye9i5OAQEciXuH1VGiQsLGAp0f6sgQ3EFhGwktjyYj6U7SZx7c5dFhCbRUBVovHZSbAxvAK+ Ei8bljBDzP/BKPFpyzFGkJmcAmESjTfcQWoYgQ76fmoNE4jNLCAucevJfCaIQwUkluw5D3W0 qMTLx/9YIWwliUlLz7FC1OdLvN53lxlil6DEyZlPWCYwisxCMmoWkrJZSMog4joSC3Z/YoOw tSWWLXzNDGOfOfCYCVl8ASP7KkaO0uLUstx0I4NNjMCIOibBpruDcc9Ly0OMAhyMSjy8CmfN QoRYE8uKK3MPMUpzsCiJ886qnRcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGhRHZb3ox2 RjbBiKRJepM940R2lV8KDf9u3bs+vfbkPrW5d78d8i5YH1S2zYFN+VPEy4Be/qUlXTdmFt1u nRh7XZN9z/qLDkY9zic9rzawrw8TKuvrXvF45pqneocnMtzeuFuNfw0jp8mPtfNt4rby1XTy p5YdsvA0irabLNz29NMdI/U77EosxRmJhlrMRcWJANMdp8CJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5NAa5xrHKyTGF0NjnqlPkRhBbmY 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, 10 Oct 2014 01:45:48 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B859643eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Santosh, thank you for taking on this task. Perhaps just a technical question: * there many new protocol variables and states associated with the ta= il tracking functionality. Were you considering leaving them in the standar= d portion or moving into informational appendix along with the description = of tail monitoring machinery? Regards, Greg PS. I'll try to send my comments to the document by Monday. -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, October 06, 2014 6:27 AM To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Sorry for typo in my precious mail "active tale" it is "active tail". Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, October 06, 2014 6:22 PM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello All, I am seeking comments on active tale section of this document. I spoke t= o few implementers and found that no one really finds use case for active t= ale. Does anyone on this forum feel that we might need active tale? If ther= e are no uses cases then we can move active tale section to appendix? We wo= uld like to make all the changes before IETF 91 and push this for RFC. Any = suggestions? Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, August 19, 2014 7:38 PM To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Note that this consists mostly of a re-publish with Santosh as the new edit= or. (And moving from .nroff to .xml.) In the next few weeks, Santosh will be working with known implementors to e= dit the document to match implementation. Ideally these edits will be comp= lete prior to the next IETF session in Honolulu. This will put us a bit pa= st our original milestone for publication, but still much better on track t= han many of our previous documents. -- Jeff On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Work= ing Group of the IETF. > > Title : BFD for Multipoint Networks > Authors : Dave Katz > Dave Ward > Santosh Pallagatti > Filename : draft-ietf-bfd-multipoint-04.txt > Pages : 27 > Date : 2014-08-12 > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol for its use in multipoint and multicast > networks. Comments on this draft should be directed to rtg- > bfd@ietf.org. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > 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.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --_000_7347100B5761DC41A166AC17F22DF1121B859643eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Santosh,
thank you for taking on this task.
Perhaps just a technical question:
  • there many new protocol variables and states associated with the tail t= racking functionality. Were you considering leaving them in the standard po= rtion or moving into informational appendix along with the description of t= ail monitoring machinery?
 
        Regards,
           &nbs= p;    Greg
 
PS. I'll try to send my comments to the document by Monday.
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:27 AM
To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt
 
Sorry for typo in my precious mail  "active tale" it is= "active tail".
 
Thanks
Santosh P K
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:22 PM
To: Jeffrey Haas; rtg-bfd@ietf.org=
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt
 
Hello All,
   I am seeking comments on active tale section of this docu= ment. I spoke to few implementers and found that no one really finds use ca= se for active tale. Does anyone on this forum feel that we might need activ= e tale? If there are no uses cases then we can move active tale section to appendix? We would like to make all the cha= nges before IETF 91 and push this for RFC. Any suggestions?
 
Thanks
Santosh P K
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-= bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Tuesday, August 19, 2014 7:38 PM
Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt
 
Note that this consists mostly of a re-publish with Santosh as the new= editor.  (And moving from .nroff to .xml.)
 
In the next few weeks, Santosh will be working with known implementors= to edit the document to match implementation.  Ideally these edits wi= ll be complete prior to the next IETF session in Honolulu.  This will = put us a bit past our original milestone for publication, but still much better on track than many of our previous docum= ents.
 
-- Jeff
 
 
 
On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Draft= s directories.
>  This draft is a work item of the Bidirectional Forwarding D= etection Working Group of the IETF.
>
>         Title  =          : BFD for Multipoint Netwo= rks
>         Authors &nbs= p;       : Dave Katz
>           =             &nb= sp;   Dave Ward
>           =             &nb= sp;   Santosh Pallagatti
>        Filename  &nb= sp;     : draft-ietf-bfd-multipoint-04.txt
>        Pages   =         : 27
>        Date   &= nbsp;        : 2014-08-12
>
> Abstract:
>    This document describes extensions to the Bidir= ectional Forwarding
>    Detection (BFD) protocol for its use in multipo= int and multicast
>    networks.  Comments on this draft should b= e directed to rtg-
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
>
> There's also a htmlized version available at:
>
> A diff from the previous version is available at:
>
>
> Please note that it may take a couple of minutes from the time of=
> submission until the htmlized version and diff are available at t= ools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B859643eusaamb103erics_-- From nobody Thu Oct 9 19:39:56 2014 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 2FF1C1A0089 for ; Thu, 9 Oct 2014 19:39:52 -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, 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 CW8c1yml9b-g for ; Thu, 9 Oct 2014 19:39:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01961A0086 for ; Thu, 9 Oct 2014 19:39:49 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB754.namprd05.prod.outlook.com (10.141.208.142) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 10 Oct 2014 02:39:26 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1024.012; Fri, 10 Oct 2014 02:39:26 +0000 From: Santosh P K To: "Henderickx, Wim (Wim)" , "Nobo Akiya (nobo)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcA== Date: Fri, 10 Oct 2014 02:39:25 +0000 Message-ID: <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(41574002)(377424004)(189002)(199003)(53754006)(479174003)(51704005)(377454003)(105586002)(106116001)(107046002)(106356001)(46102003)(230783001)(80022003)(99396003)(74316001)(33646002)(108616004)(66066001)(95666004)(122556002)(76482002)(99286002)(40100002)(93886004)(107886001)(19580405001)(85306004)(120916001)(15975445006)(64706001)(2656002)(97736003)(19580395003)(54356999)(76576001)(92566001)(4396001)(20776003)(21056001)(101416001)(86362001)(15202345003)(50986999)(76176999)(31966008)(85852003)(87936001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB754; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/b573xZ5qNDHNDfqRc0Ibmvc_sIw 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, 10 Oct 2014 02:39:52 -0000 Thanks Hendreickx for your reply. -----Original Message----- From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]=20 Sent: Friday, October 10, 2014 12:29 AM To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt In certain environment the tracking of the tails is happening by other mean= s. Example is Multicast VPN using MP-BGP. On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: >[With Chair Hat On] > >Dear WG, > >The topic of keeping or removing the active tail from=20 >draft-ietf-bfd-multipoint is one of the last couple of topics that we,=20 >as a WG, need to resolve for this document. > >Whether or not we keep or remove the active tail, leaves will be able=20 >to detect the failure of the multicast tree, which allows protections=20 >such as live-live. > >What is essentially different: > >Keeping the active tail - Allows ingress/root to keep track of leaves. > >Removing the active tail - Ingress/root will not be able to keep track=20 >of leaves. > >If there's any requirements for the ingress/root to trigger some=20 >protections, then active tail becomes a requirement. If there is no=20 >such requirements, then the active tail is an unnecessary portion of=20 >this document. > >It'll be beneficial to hear your thoughts/comments to help gauge where=20 >we are on this matter as a WG. > >Comments/thoughts? > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >> P K >> Sent: Monday, October 06, 2014 9:27 AM >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Sorry for typo in my precious mail "active tale" it is "active tail". >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >> P K >> Sent: Monday, October 06, 2014 6:22 PM >> To: Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Hello All, >> I am seeking comments on active tale section of this document. I=20 >>spoke to few implementers and found that no one really finds use case=20 >>for active tale. >> Does anyone on this forum feel that we might need active tale? If=20 >>there are no uses cases then we can move active tale section to=20 >>appendix? We would like to make all the changes before IETF 91 and=20 >>push this for RFC. Any suggestions? >>=20 >> Thanks >> Santosh P K >>=20 >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 >>Haas >> Sent: Tuesday, August 19, 2014 7:38 PM >> To: rtg-bfd@ietf.org >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >>=20 >> Note that this consists mostly of a re-publish with Santosh as the=20 >>new editor. >> (And moving from .nroff to .xml.) >>=20 >> In the next few weeks, Santosh will be working with known=20 >>implementors to edit the document to match implementation. Ideally=20 >>these edits will be complete prior to the next IETF session in=20 >>Honolulu. This will put us a bit past our original milestone for=20 >>publication, but still much better on track than many of our previous=20 >>documents. >>=20 >> -- Jeff >>=20 >>=20 >>=20 >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org >>wrote: >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Bidirectional Forwarding=20 >> > Detection >> Working Group of the IETF. >> > >> > Title : BFD for Multipoint Networks >> > Authors : Dave Katz >> > Dave Ward >> > Santosh Pallagatti >> > Filename : draft-ietf-bfd-multipoint-04.txt >> > Pages : 27 >> > Date : 2014-08-12 >> > >> > Abstract: >> > This document describes extensions to the Bidirectional Forwarding >> > Detection (BFD) protocol for its use in multipoint and multicast >> > networks. Comments on this draft should be directed to rtg- >> > bfd@ietf.org. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >> > >> > >> > Please note that it may take a couple of minutes from the time of=20 >> > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ > From nobody Thu Oct 9 19:41:41 2014 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 1DBF71A0086 for ; Thu, 9 Oct 2014 19:41:41 -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, 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 33ORZzuuJygq for ; Thu, 9 Oct 2014 19:41:39 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201BC1A0081 for ; Thu, 9 Oct 2014 19:41:39 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 10 Oct 2014 02:41:37 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1024.012; Fri, 10 Oct 2014 02:41:37 +0000 From: Santosh P K To: Mingui Zhang , "Nobo Akiya (nobo)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgACl5ACAABLqQA== Date: Fri, 10 Oct 2014 02:41:37 +0000 Message-ID: <47fcdc98d547478fa963b18a891b87d2@BLUPR05MB755.namprd05.prod.outlook.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <4552F0907735844E9204A62BBDD325E76AAC0A1C@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AAC0A1C@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(13464003)(199003)(189002)(377424004)(377454003)(41574002)(164054003)(51704005)(24454002)(120916001)(230783001)(92566001)(97736003)(87936001)(40100002)(106356001)(31966008)(54356999)(106116001)(76176999)(21056001)(66066001)(105586002)(80022003)(50986999)(99396003)(93886004)(86362001)(46102003)(85852003)(74316001)(85306004)(76482002)(122556002)(33646002)(108616004)(101416001)(107886001)(4396001)(76576001)(15202345003)(107046002)(2656002)(19580405001)(64706001)(99286002)(95666004)(15975445006)(19580395003)(20776003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB755; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6j6eFDiufLo1XSRtTfMj-pM0C0E 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, 10 Oct 2014 02:41:41 -0000 Mingui, Thanks a lot for your comments. Can you please tell me if there any appl= ication which is already doing it? Is there any other way of doing it witho= ut BFD like in case of MVPN? Thanks Santosh P K=20 -----Original Message----- From: Mingui Zhang [mailto:zhangmingui@huawei.com]=20 Sent: Friday, October 10, 2014 7:02 AM To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt I think the "keeping the active tail" choice can help the ingress/root to p= erform global protection. Additionally, it's possible to achieve a more bal= anced load distribution among multiple trees (there might be more than two = available trees) if the ingress/root has knowledge of the active tail.=20 Thanks, Mingui >-----Original Message----- >From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya=20 >(nobo) >Sent: Thursday, October 09, 2014 11:38 PM >To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >[With Chair Hat On] > >Dear WG, > >The topic of keeping or removing the active tail from=20 >draft-ietf-bfd-multipoint is one of the last couple of topics that we,=20 >as a WG, need to resolve for this document. > >Whether or not we keep or remove the active tail, leaves will be able=20 >to detect the failure of the multicast tree, which allows protections such= as live-live. > >What is essentially different: > >Keeping the active tail - Allows ingress/root to keep track of leaves. > >Removing the active tail - Ingress/root will not be able to keep track of = leaves. > >If there's any requirements for the ingress/root to trigger some=20 >protections, then active tail becomes a requirement. If there is no=20 >such requirements, then the active tail is an unnecessary portion of this = document. > >It'll be beneficial to hear your thoughts/comments to help gauge where=20 >we are on this matter as a WG. > >Comments/thoughts? > >Thanks! > >-Nobo > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >> P K >> Sent: Monday, October 06, 2014 9:27 AM >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Sorry for typo in my precious mail "active tale" it is "active tail". >> >> Thanks >> Santosh P K >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh=20 >> P K >> Sent: Monday, October 06, 2014 6:22 PM >> To: Jeffrey Haas; rtg-bfd@ietf.org >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Hello All, >> I am seeking comments on active tale section of this document. I=20 >> spoke to few implementers and found that no one really finds use case fo= r active tale. >> Does anyone on this forum feel that we might need active tale? If=20 >> there are no uses cases then we can move active tale section to=20 >> appendix? We would like to make all the changes before IETF 91 and=20 >> push this for RFC. Any suggestions? >> >> Thanks >> Santosh P K >> >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 >> Haas >> Sent: Tuesday, August 19, 2014 7:38 PM >> To: rtg-bfd@ietf.org >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >> Note that this consists mostly of a re-publish with Santosh as the new e= ditor. >> (And moving from .nroff to .xml.) >> >> In the next few weeks, Santosh will be working with known=20 >> implementors to edit the document to match implementation. Ideally=20 >> these edits will be complete prior to the next IETF session in=20 >> Honolulu. This will put us a bit past our original milestone for=20 >> publication, but still much better on track than many of our previous do= cuments. >> >> -- Jeff >> >> >> >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote= : >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Bidirectional Forwarding=20 >> > Detection >> Working Group of the IETF. >> > >> > Title : BFD for Multipoint Networks >> > Authors : Dave Katz >> > Dave Ward >> > Santosh Pallagatti >> > Filename : draft-ietf-bfd-multipoint-04.txt >> > Pages : 27 >> > Date : 2014-08-12 >> > >> > Abstract: >> > This document describes extensions to the Bidirectional Forwarding >> > Detection (BFD) protocol for its use in multipoint and multicast >> > networks. Comments on this draft should be directed to rtg- >> > bfd@ietf.org. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >> > >> > >> > Please note that it may take a couple of minutes from the time of=20 >> > submission until the htmlized version and diff are available at >> tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 9 19:43:42 2014 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 F008D1A0081 for ; Thu, 9 Oct 2014 19:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qeffCvLWYNHf for ; Thu, 9 Oct 2014 19:43:38 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519921A00AB for ; Thu, 9 Oct 2014 19:43:37 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Fri, 10 Oct 2014 02:43:14 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1024.012; Fri, 10 Oct 2014 02:43:14 +0000 From: Santosh P K To: Gregory Mirsky , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAFhhyAgAAPqxA= Date: Fri, 10 Oct 2014 02:43:13 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B859643@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B859643@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(13464003)(199003)(24454002)(377454003)(189002)(377424004)(51704005)(19617315012)(4396001)(86362001)(66066001)(20776003)(19300405004)(19580405001)(92566001)(19625215002)(15202345003)(101416001)(85852003)(76576001)(33646002)(16236675004)(64706001)(2656002)(97736003)(107046002)(107886001)(54356999)(87936001)(230783001)(76176999)(50986999)(19609705001)(120916001)(99396003)(15975445006)(122556002)(40100002)(80022003)(19580395003)(95666004)(74316001)(105586002)(46102003)(108616004)(76482002)(21056001)(31966008)(85306004)(106356001)(106116001)(99286002)(93886004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d1872195479f4acbb74b0514d8a9d3deBLUPR05MB755namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/DWSt2OPmWGJDzTxWLgP_8AN2R4U 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, 10 Oct 2014 02:43:41 -0000 --_000_d1872195479f4acbb74b0514d8a9d3deBLUPR05MB755namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Greg, Thanks for your comments. Leaving or moving to appendix is the questio= n here. It depends on if we really find any use case scenario for active ta= il. Thanks Santosh P K From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Friday, October 10, 2014 7:16 AM To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hi Santosh, thank you for taking on this task. Perhaps just a technical question: * there many new protocol variables and states associated with the = tail tracking functionality. Were you considering leaving them in the stand= ard portion or moving into informational appendix along with the descriptio= n of tail monitoring machinery? Regards, Greg PS. I'll try to send my comments to the document by Monday. -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, October 06, 2014 6:27 AM To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Sorry for typo in my precious mail "active tale" it is "active tail". Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Monday, October 06, 2014 6:22 PM To: Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello All, I am seeking comments on active tale section of this document. I spoke t= o few implementers and found that no one really finds use case for active t= ale. Does anyone on this forum feel that we might need active tale? If ther= e are no uses cases then we can move active tale section to appendix? We wo= uld like to make all the changes before IETF 91 and push this for RFC. Any = suggestions? Thanks Santosh P K -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, August 19, 2014 7:38 PM To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Note that this consists mostly of a re-publish with Santosh as the new edit= or. (And moving from .nroff to .xml.) In the next few weeks, Santosh will be working with known implementors to e= dit the document to match implementation. Ideally these edits will be comp= lete prior to the next IETF session in Honolulu. This will put us a bit pa= st our original milestone for publication, but still much better on track t= han many of our previous documents. -- Jeff On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Bidirectional Forwarding Detection Work= ing Group of the IETF. > > Title : BFD for Multipoint Networks > Authors : Dave Katz > Dave Ward > Santosh Pallagatti > Filename : draft-ietf-bfd-multipoint-04.txt > Pages : 27 > Date : 2014-08-12 > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol for its use in multipoint and multicast > networks. Comments on this draft should be directed to rtg- > bfd@ietf.org. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > 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.iet= f.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ --_000_d1872195479f4acbb74b0514d8a9d3deBLUPR05MB755namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Greg,

     = Thanks for your comments. Leaving or moving to appendix is the question her= e. It depends on if we really find any use case scenario for active tail.

 <= /p>

Thanks<= /p>

Santosh P K

 <= /p>

From: Gregor= y Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Friday, October 10, 2014 7:16 AM
To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt=

 

Hi Santosh,

thank you for taking on this task.=

Perhaps just a technical question:=

·         there many new protocol variabl= es and states associated with the tail tracking functionality. Were you con= sidering leaving them in the standard portion or moving into informational appendix along with the description of tail monitoring = machinery?

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

PS. I'll try to send my comments to the= document by Monday.

 

-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Santosh P K
Sent: Monday, October 06, 2014 6:27 AM
To: Santosh P K; Jeffrey Haas; rtg-bfd@= ietf.org
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt=

 

Sorry for typo in my precious mail = ; "active tale" it is "active tail".<= /p>

 

Thanks

Santosh P K

 

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

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santo= sh P K

Sent: Monday, October 06, 2014 6:22 PM<= o:p>

To: Jeffrey Haas; rtg-bfd@ietf.org<= /p>

Subject: RE: I-D Action: draft-ietf-bfd= -multipoint-04.txt

 

Hello All,

   I am seeking comments on a= ctive tale section of this document. I spoke to few implementers and found = that no one really finds use case for active tale. Does anyone on this forum feel that we might need active tale? If there are no uses cases= then we can move active tale section to appendix? We would like to make al= l the changes before IETF 91 and push this for RFC. Any suggestions?

 

Thanks

Santosh P K

 

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

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffr= ey Haas

Sent: Tuesday, August 19, 2014 7:38 PM<= o:p>

To: rtg-bfd@ietf.org<= /p>

Subject: Re: I-D Action: draft-ietf-bfd= -multipoint-04.txt

 

Note that this consists mostly of a re-= publish with Santosh as the new editor.  (And moving from .nroff to .x= ml.)

 

In the next few weeks, Santosh will be = working with known implementors to edit the document to match implementatio= n.  Ideally these edits will be complete prior to the next IETF session in Honolulu.  This will put us a bit past our original m= ilestone for publication, but still much better on track than many of our p= revious documents.

 

-- Jeff

 

 

 

On Mon, Aug 18, 2014 at 05:55:37PM -070= 0, internet-drafts@ietf.org wr= ote:

>

> A New Internet-Draft is available = from the on-line Internet-Drafts directories.

>  This draft is a work item of= the Bidirectional Forwarding Detection Working Group of the IETF.

>

>      = ;   Title         &n= bsp; : BFD for Multipoint Networks

>      = ;   Authors         : Dav= e Katz

>      = ;            &n= bsp;        Dave Ward<= /p>

>      = ;            &n= bsp;        Santosh Pallagatti

>      = ;  Filename        : draft-ietf-bfd= -multipoint-04.txt

>      = ;  Pages           := 27

>      = ;  Date          &nb= sp; : 2014-08-12

>

> Abstract:

>    This document de= scribes extensions to the Bidirectional Forwarding

>    Detection (BFD) = protocol for its use in multipoint and multicast

>    networks.  = Comments on this draft should be directed to rtg-

>    bfd@ietf.org.

>

>

>

> The IETF datatracker status page f= or this draft is:

>

> There's also a htmlized version av= ailable at:

>

> A diff from the previous version i= s available at:

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> Internet-Drafts are also available= by anonymous FTP at:

 

 

--_000_d1872195479f4acbb74b0514d8a9d3deBLUPR05MB755namprd05pro_-- From nobody Thu Oct 9 20:21:35 2014 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 388471A00C6 for ; Thu, 9 Oct 2014 20:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 aXSN0jNvlQXV for ; Thu, 9 Oct 2014 20:21:30 -0700 (PDT) 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 561301A00C0 for ; Thu, 9 Oct 2014 20:21:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNM35402; Fri, 10 Oct 2014 03:21:28 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Oct 2014 04:21:27 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.22]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 11:21:24 +0800 From: Mingui Zhang To: Santosh P K , "Nobo Akiya (nobo)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hWKEpQ2rtLyk+1UKjzaDPn65vXcWwAgEtadACAAAnegIAE26WAgAEl5ZD//5N3gIAAi7CQ Date: Fri, 10 Oct 2014 03:21:24 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AAC0AC6@nkgeml512-mbx.china.huawei.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <4552F0907735844E9204A62BBDD325E76AAC0A1C@nkgeml512-mbx.china.huawei.com> <47fcdc98d547478fa963b18a891b87d2@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <47fcdc98d547478fa963b18a891b87d2@BLUPR05MB755.namprd05.prod.outlook.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.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WiG3VTcLHL7jCfFCX7hArfRYyrM 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, 10 Oct 2014 03:21:33 -0000 Hi Santosh, You are welcome.=20 We intend to do so for TRILL Resilient Distribution Trees.=20 Thanks, Mingui >-----Original Message----- >From: Santosh P K [mailto:santoshpk@juniper.net] >Sent: Friday, October 10, 2014 10:42 AM >To: Mingui Zhang; Nobo Akiya (nobo); Jeffrey Haas; rtg-bfd@ietf.org >Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >Mingui, > Thanks a lot for your comments. Can you please tell me if there any >application which is already doing it? Is there any other way of doing it = without >BFD like in case of MVPN? > >Thanks >Santosh P K > >-----Original Message----- >From: Mingui Zhang [mailto:zhangmingui@huawei.com] >Sent: Friday, October 10, 2014 7:02 AM >To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >I think the "keeping the active tail" choice can help the ingress/root to = perform >global protection. Additionally, it's possible to achieve a more balanced = load >distribution among multiple trees (there might be more than two available = trees) >if the ingress/root has knowledge of the active tail. > >Thanks, >Mingui > >>-----Original Message----- >>From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya >>(nobo) >>Sent: Thursday, October 09, 2014 11:38 PM >>To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >>Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >> >>[With Chair Hat On] >> >>Dear WG, >> >>The topic of keeping or removing the active tail from >>draft-ietf-bfd-multipoint is one of the last couple of topics that we, >>as a WG, need to resolve for this document. >> >>Whether or not we keep or remove the active tail, leaves will be able >>to detect the failure of the multicast tree, which allows protections suc= h as >live-live. >> >>What is essentially different: >> >>Keeping the active tail - Allows ingress/root to keep track of leaves. >> >>Removing the active tail - Ingress/root will not be able to keep track of= leaves. >> >>If there's any requirements for the ingress/root to trigger some >>protections, then active tail becomes a requirement. If there is no >>such requirements, then the active tail is an unnecessary portion of this >document. >> >>It'll be beneficial to hear your thoughts/comments to help gauge where >>we are on this matter as a WG. >> >>Comments/thoughts? >> >>Thanks! >> >>-Nobo >> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh >>> P K >>> Sent: Monday, October 06, 2014 9:27 AM >>> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org >>> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>> >>> Sorry for typo in my precious mail "active tale" it is "active tail". >>> >>> Thanks >>> Santosh P K >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh >>> P K >>> Sent: Monday, October 06, 2014 6:22 PM >>> To: Jeffrey Haas; rtg-bfd@ietf.org >>> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >>> >>> Hello All, >>> I am seeking comments on active tale section of this document. I >>> spoke to few implementers and found that no one really finds use case f= or >active tale. >>> Does anyone on this forum feel that we might need active tale? If >>> there are no uses cases then we can move active tale section to >>> appendix? We would like to make all the changes before IETF 91 and >>> push this for RFC. Any suggestions? >>> >>> Thanks >>> Santosh P K >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>> Haas >>> Sent: Tuesday, August 19, 2014 7:38 PM >>> To: rtg-bfd@ietf.org >>> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >>> >>> Note that this consists mostly of a re-publish with Santosh as the new = editor. >>> (And moving from .nroff to .xml.) >>> >>> In the next few weeks, Santosh will be working with known >>> implementors to edit the document to match implementation. Ideally >>> these edits will be complete prior to the next IETF session in >>> Honolulu. This will put us a bit past our original milestone for >>> publication, but still much better on track than many of our previous >documents. >>> >>> -- Jeff >>> >>> >>> >>> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrot= e: >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> > This draft is a work item of the Bidirectional Forwarding >>> > Detection >>> Working Group of the IETF. >>> > >>> > Title : BFD for Multipoint Networks >>> > Authors : Dave Katz >>> > Dave Ward >>> > Santosh Pallagatti >>> > Filename : draft-ietf-bfd-multipoint-04.txt >>> > Pages : 27 >>> > Date : 2014-08-12 >>> > >>> > Abstract: >>> > This document describes extensions to the Bidirectional Forwarding >>> > Detection (BFD) protocol for its use in multipoint and multicast >>> > networks. Comments on this draft should be directed to rtg- >>> > bfd@ietf.org. >>> > >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ >>> > >>> > There's also a htmlized version available at: >>> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 >>> > >>> > A diff from the previous version is available at: >>> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 >>> > >>> > >>> > Please note that it may take a couple of minutes from the time of >>> > submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 10 07:13:49 2014 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 1ED021A0383 for ; Fri, 10 Oct 2014 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 8LA8RAHY3lUC for ; Fri, 10 Oct 2014 07:13:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DD3C01A035E for ; Fri, 10 Oct 2014 07:13:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 912A2C260; Fri, 10 Oct 2014 10:13:44 -0400 (EDT) Date: Fri, 10 Oct 2014 10:13:44 -0400 From: Jeffrey Haas To: Santosh P K Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Message-ID: <20141010141344.GB7516@pfrc> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B859643@eusaamb103.ericsson.se> 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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OqEncGuR7LDace7e_SpDf95WEwA 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, 10 Oct 2014 14:13:46 -0000 On Fri, Oct 10, 2014 at 02:43:13AM +0000, Santosh P K wrote: > Hello Greg, > Thanks for your comments. Leaving or moving to appendix is the question here. It depends on if we really find any use case scenario for active tail. And one of the motivations for the solicication of comments is to figure out what we RFC: Shipping features vs. optional but specified components. For example, I don't think I've yet heard of a BFD implementation that supports demand mode. Echo mode is also incompletely supported across vendor platforms. While not a big deal - everyone supports async - such issues hinder advancement of the RFC to full standard. -- Jeff From nobody Fri Oct 10 07:48:33 2014 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 A512B1ACE22 for ; Fri, 10 Oct 2014 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 f_8kCubTPrb2 for ; Fri, 10 Oct 2014 07:48:30 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DA31A1A2C for ; Fri, 10 Oct 2014 07:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5847; q=dns/txt; s=iport; t=1412952509; x=1414162109; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UOekdZKrAgyFOcVrZCTLsEfPYl80blFkFNmQf735LHA=; b=fJv8rJ7AFAMiMek51v18zjT5tg+4MskH5cCyRo2MJIRkPnXN6ciGhDfT rcO2slvBPIeOHTW7Jod+dsqkAKiHgxAsMQZByVni7XhqBaZlCnb4cdhlT gZOD1trv00rXyaHhwIngvZ5OdcjvtjmB1JzxFPbRtOYfXDYh2f4qYL7GV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAHXxN1StJV2S/2dsb2JhbABggmsjU1MFBMtZh00CgQMWAXuEAwEBAQQ6SwQCAQgRBAEBAQoUCQcyFAkIAgQBEggBiDUBBwXCAgEBAQEBAQEBAQEBAQEBAQEBAQEBARePcwEBHjgGgyeBHgWPX4IahEKIPjyDCo0fg36CBhiBWWyBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,692,1406592000"; d="scan'208";a="85826075" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 10 Oct 2014 14:48:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9AEmS6C027338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 14:48:29 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 09:48:28 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUPZOBPokD+keyL4hHqvmqqpvYS1kAgEtadQCAAAnegIAEgS9ggAA+kgCAANSjgIAAY87w Date: Fri, 10 Oct 2014 14:48:28 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hCb2wrS-OoF9efzPZ1pfW42CLEY 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, 10 Oct 2014 14:48:32 -0000 Santosh, It will helpful to clarify exactly what you mean by "active tail". - Do you intend to keep tail reporting of the failure (bfd.ReportTailDown= =3D1)? - Is it just unicast poll from head that is being questioned for removal? Knowing exactly what aspect is being questioned for removal may provide a b= etter base for good discussions. Thanks! -Nobo > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Thursday, October 09, 2014 10:39 PM > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg- > bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Thanks Hendreickx for your reply. >=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > Sent: Friday, October 10, 2014 12:29 AM > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > In certain environment the tracking of the tails is happening by other me= ans. > Example is Multicast VPN using MP-BGP. >=20 > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: >=20 > >[With Chair Hat On] > > > >Dear WG, > > > >The topic of keeping or removing the active tail from > >draft-ietf-bfd-multipoint is one of the last couple of topics that we, > >as a WG, need to resolve for this document. > > > >Whether or not we keep or remove the active tail, leaves will be able > >to detect the failure of the multicast tree, which allows protections > >such as live-live. > > > >What is essentially different: > > > >Keeping the active tail - Allows ingress/root to keep track of leaves. > > > >Removing the active tail - Ingress/root will not be able to keep track > >of leaves. > > > >If there's any requirements for the ingress/root to trigger some > >protections, then active tail becomes a requirement. If there is no > >such requirements, then the active tail is an unnecessary portion of > >this document. > > > >It'll be beneficial to hear your thoughts/comments to help gauge where > >we are on this matter as a WG. > > > >Comments/thoughts? > > > >Thanks! > > > >-Nobo > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh > >> P K > >> Sent: Monday, October 06, 2014 9:27 AM > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Sorry for typo in my precious mail "active tale" it is "active tail". > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh > >> P K > >> Sent: Monday, October 06, 2014 6:22 PM > >> To: Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Hello All, > >> I am seeking comments on active tale section of this document. I > >>spoke to few implementers and found that no one really finds use case > >>for active tale. > >> Does anyone on this forum feel that we might need active tale? If > >>there are no uses cases then we can move active tale section to > >>appendix? We would like to make all the changes before IETF 91 and > >>push this for RFC. Any suggestions? > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey > >>Haas > >> Sent: Tuesday, August 19, 2014 7:38 PM > >> To: rtg-bfd@ietf.org > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Note that this consists mostly of a re-publish with Santosh as the > >>new editor. > >> (And moving from .nroff to .xml.) > >> > >> In the next few weeks, Santosh will be working with known > >>implementors to edit the document to match implementation. Ideally > >>these edits will be complete prior to the next IETF session in > >>Honolulu. This will put us a bit past our original milestone for > >>publication, but still much better on track than many of our previous > >>documents. > >> > >> -- Jeff > >> > >> > >> > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org > >>wrote: > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > This draft is a work item of the Bidirectional Forwarding > >> > Detection > >> Working Group of the IETF. > >> > > >> > Title : BFD for Multipoint Networks > >> > Authors : Dave Katz > >> > Dave Ward > >> > Santosh Pallagatti > >> > Filename : draft-ietf-bfd-multipoint-04.txt > >> > Pages : 27 > >> > Date : 2014-08-12 > >> > > >> > Abstract: > >> > This document describes extensions to the Bidirectional Forwardin= g > >> > Detection (BFD) protocol for its use in multipoint and multicast > >> > networks. Comments on this draft should be directed to rtg- > >> > bfd@ietf.org. > >> > > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > >> > > >> > > >> > Please note that it may take a couple of minutes from the time of > >> > submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Fri Oct 10 07:50:44 2014 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 AADB31ACE33 for ; Fri, 10 Oct 2014 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 lfb60Xhx2wK5 for ; Fri, 10 Oct 2014 07:50:36 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046761A90E3 for ; Fri, 10 Oct 2014 07:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6879; q=dns/txt; s=iport; t=1412952635; x=1414162235; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xVWP6zOVi6e1yjPFYuqq8+69XFsX0NqwwCNSYiJmKCA=; b=YSl60oaJlKqvA8cSWvh9hVBFEWgWU5ySyySjiq5HuFvpPQZkytv0eotq W4ctcBJ8ftgKXtEMOZpNVS1SVDixx5Gw0MEMLC3SMm7suNfUKoXG9BH+q 5wAQ86MPGP106Ua/zID+HlPRuV6WNoC4gyadRzUM0HGLC8Uk8rrVhylGV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFADDxN1StJA2K/2dsb2JhbABggw5TUwUEy1mHTQKBAxYBe4QDAQEBBDpLBAIBCBEEAQEBChQJBzIUCQgCBAESCAGINQgFwgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXj3MBAR44BoMngR4Fj1+CGoRCiD48gwqNH4N+g3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,692,1406592000"; d="scan'208";a="85827455" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 10 Oct 2014 14:50:34 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9AEoYlZ019307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Oct 2014 14:50:34 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 09:50:33 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "Nobo Akiya (nobo)" , Santosh P K , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hU1nryP7dQOU2cGGfuY/WCWpvYS1kAgEtadQCAAAnegIAE26WAgAEwFzA= Date: Fri, 10 Oct 2014 14:50:33 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D346AE69E@xmb-rcd-x15.cisco.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/S--WCpls1U9sEZmlbIZ3wdyOiXI 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, 10 Oct 2014 14:50:42 -0000 Hello Santosh, Since the usage of activeTail is currently optional, there may be benefit= in retaining the activeTail as part of the main specification. However we = could improve the specification of the activeTail, please find the followin= g observations in that context: Section 1: This document effectively modifies and adds to the base BFD specification. It is the intention of the authors to fold these extensions into the base specification at the appropriate time. GVP1> Should we consider removing the second sentence of the last paragraph= ? I assume that RFC 5880 would not change due to multi-point BFD gets stan= dardized. Section 2: A final goal is to integrate multipoint operation into the base specification in such a way as to make it relatively easy to support both multipoint and point-to-point operation in a single implementation. GVP1> Should we consider removing this goal? I assume that RFC 5880 would n= ot change due to multi-point BFD gets standardized. Section 3: In my understanding this section provides a lot of details in the way multi= pointTail sessions are bootstrapped and feedback on multipoint connectivity= is provided back to the head. However it may be better to consider splitti= ng this text into relevant sub-sections so important clauses needed for int= eroperability are not lost. In particular RFC 2119 verbs are not capitalize= d. I think it may be beneficial to explicitly capture the following aspects= : a/ Procedures for bootstrapping and maintaining multipointTail sessions (a= lready described in part in Sec 4.15.2) b/ Procedures for generating unicast BFD packets (reflecting the connectivi= ty state) from the tail nodes: It is my understanding that the tails do not= initiate unicast packets until the head initiates the poll sequence for al= l tail nodes. If this is the case, we could consider adding explicit text t= o this effect.=20 c/ Procedures for bootstrapping and maintaining multipointClient sessions: There may be additional clarifications needed for the demux of BFD sessions= at the tails especially when tracking P2MP MPLS LSPs. We could start a sep= arate thread for those considerations. =09 Regards Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Thursday, October 09, 2014 9:08 PM To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt [With Chair Hat On] Dear WG, The topic of keeping or removing the active tail from draft-ietf-bfd-multip= oint is one of the last couple of topics that we, as a WG, need to resolve = for this document. Whether or not we keep or remove the active tail, leaves will be able to de= tect the failure of the multicast tree, which allows protections such as li= ve-live. What is essentially different: Keeping the active tail - Allows ingress/root to keep track of leaves. Removing the active tail - Ingress/root will not be able to keep track of l= eaves. If there's any requirements for the ingress/root to trigger some protection= s, then active tail becomes a requirement. If there is no such requirements= , then the active tail is an unnecessary portion of this document. It'll be beneficial to hear your thoughts/comments to help gauge where we a= re on this matter as a WG. Comments/thoughts? Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Monday, October 06, 2014 9:27 AM > To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Sorry for typo in my precious mail "active tale" it is "active tail". >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Monday, October 06, 2014 6:22 PM > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > I am seeking comments on active tale section of this document. I=20 > spoke to few implementers and found that no one really finds use case for= active tale. > Does anyone on this forum feel that we might need active tale? If=20 > there are no uses cases then we can move active tale section to=20 > appendix? We would like to make all the changes before IETF 91 and=20 > push this for RFC. Any suggestions? >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 > Haas > Sent: Tuesday, August 19, 2014 7:38 PM > To: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Note that this consists mostly of a re-publish with Santosh as the new ed= itor. > (And moving from .nroff to .xml.) >=20 > In the next few weeks, Santosh will be working with known implementors=20 > to edit the document to match implementation. Ideally these edits=20 > will be complete prior to the next IETF session in Honolulu. This=20 > will put us a bit past our original milestone for publication, but=20 > still much better on track than many of our previous documents. >=20 > -- Jeff >=20 >=20 >=20 > On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > > > Title : BFD for Multipoint Networks > > Authors : Dave Katz > > Dave Ward > > Santosh Pallagatti > > Filename : draft-ietf-bfd-multipoint-04.txt > > Pages : 27 > > Date : 2014-08-12 > > > > Abstract: > > This document describes extensions to the Bidirectional Forwarding > > Detection (BFD) protocol for its use in multipoint and multicast > > networks. Comments on this draft should be directed to rtg- > > bfd@ietf.org. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 10 09:32:22 2014 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 6F4181A9045 for ; Fri, 10 Oct 2014 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7lARsMduoUii for ; Fri, 10 Oct 2014 09:32:17 -0700 (PDT) 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 4657E1A8A8C for ; Fri, 10 Oct 2014 09:28:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-da-5437b239d781 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 43.A5.05330.932B7345; Fri, 10 Oct 2014 12:17:30 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 12:28:49 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Santosh P K , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUJnl0CAJJIkO/ChgaGBADZJvX94gAgEtaThCAAE0TgIAE26SAgAA3/wCAAIDAgIAAy7IA///XVfA= Date: Fri, 10 Oct 2014 16:28:49 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B859B63@eusaamb103.ericsson.se> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> 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_7347100B5761DC41A166AC17F22DF1121B859B63eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonUNdqk3mIwZ7pwhb7D75ltZjdEW/x +c82Rotrd7cyW8x+/IPNgdWj9dleVo8pvzeyeixZ8pPJ43rTVXaPy71bWQNYo7hsUlJzMstS i/TtErgyfq6VKPg6m7Hi9sTXzA2Mm5oZuxg5OSQETCSOLbzHBmGLSVy4tx7I5uIQEjjKKNHT NZ8JwlnOKNHZOIcZpIpNwEjixcYedpCEiMAVRonm/nZ2kISwgKVE+7MGsFEiAlYSW17MB7I5 gOwkiT3zhEDCLAKqEu0tO8Dm8Ar4SiyevIMdYsF/ZonpO86xgCQ4gRKz99wGm8MIdNL3U2uY QGxmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaSxKSl51gh6vMlus89Z4FYJihxcuYTlgmM IrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipGjtDi1LDfdyGATIzD6 jkmw6e5g3PPS8hCjAAejEg+vwlmzECHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYEz7dGumUe6pMAWr9ENquvc7Eg92th+9aqMh+3fpQp/mjpoXek7Ta1fu mrpygcrSfLu6v9wtfv+2/1x2/sCjl5NLpvlyNIS07VklxNKpZLsz5ZaC6dNDt7We/r+izfTa P2jbpscnYnTcXdYcPinD/ig17ZlxXXPLAd2vu6aq+LGv4M/LEXKbOV2JpTgj0VCLuag4EQBN YLFqnwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4Q73933pyRwyj_FjHWeZN1whuSE 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, 10 Oct 2014 16:32:20 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B859B63eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, thank you for so precisely and eloquently formulating it: Knowing exactly what aspect is being questioned for removal may provi= de a better base for good discussions. I see several possible scenarios: * keep the scope of the document as-is; * extract and move to an appendix as informational/historical descrip= tion of tail monitoring but keep all new variables and states in standard p= art as currently defined (dormant but readily available); * rip off everything related to tail monitoring from the standard par= t (major, huge undertaking IMO). Have I missed any other option? Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Friday, October 10, 2014 7:48 AM To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Santosh, It will helpful to clarify exactly what you mean by "active tail". - Do you intend to keep tail reporting of the failure (bfd.ReportTailDown= =3D1)? - Is it just unicast poll from head that is being questioned for removal? Knowing exactly what aspect is being questioned for removal may provide a b= etter base for good discussions. Thanks! -Nobo > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Thursday, October 09, 2014 10:39 PM > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg- > bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > Thanks Hendreickx for your reply. > > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > Sent: Friday, October 10, 2014 12:29 AM > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > In certain environment the tracking of the tails is happening by other me= ans. > Example is Multicast VPN using MP-BGP. > > On 09/10/14 17:38, "Nobo Akiya (nobo)" > wrote: > > >[With Chair Hat On] > > > >Dear WG, > > > >The topic of keeping or removing the active tail from > >draft-ietf-bfd-multipoint is one of the last couple of topics that > >we, as a WG, need to resolve for this document. > > > >Whether or not we keep or remove the active tail, leaves will be able > >to detect the failure of the multicast tree, which allows protections > >such as live-live. > > > >What is essentially different: > > > >Keeping the active tail - Allows ingress/root to keep track of leaves. > > > >Removing the active tail - Ingress/root will not be able to keep > >track of leaves. > > > >If there's any requirements for the ingress/root to trigger some > >protections, then active tail becomes a requirement. If there is no > >such requirements, then the active tail is an unnecessary portion of > >this document. > > > >It'll be beneficial to hear your thoughts/comments to help gauge > >where we are on this matter as a WG. > > > >Comments/thoughts? > > > >Thanks! > > > >-Nobo > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >> Santosh P K > >> Sent: Monday, October 06, 2014 9:27 AM > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Sorry for typo in my precious mail "active tale" it is "active tail". > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >> Santosh P K > >> Sent: Monday, October 06, 2014 6:22 PM > >> To: Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Hello All, > >> I am seeking comments on active tale section of this document. I > >>spoke to few implementers and found that no one really finds use > >>case for active tale. > >> Does anyone on this forum feel that we might need active tale? If > >>there are no uses cases then we can move active tale section to > >>appendix? We would like to make all the changes before IETF 91 and > >>push this for RFC. Any suggestions? > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > >>Jeffrey Haas > >> Sent: Tuesday, August 19, 2014 7:38 PM > >> To: rtg-bfd@ietf.org > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Note that this consists mostly of a re-publish with Santosh as the > >>new editor. > >> (And moving from .nroff to .xml.) > >> > >> In the next few weeks, Santosh will be working with known > >>implementors to edit the document to match implementation. Ideally > >>these edits will be complete prior to the next IETF session in > >>Honolulu. This will put us a bit past our original milestone for > >>publication, but still much better on track than many of our > >>previous documents. > >> > >> -- Jeff > >> > >> > >> > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org > >>wrote: > >> > > >> > A New Internet-Draft is available from the on-line > >> > Internet-Drafts > >> directories. > >> > This draft is a work item of the Bidirectional Forwarding > >> > Detection > >> Working Group of the IETF. > >> > > >> > Title : BFD for Multipoint Networks > >> > Authors : Dave Katz > >> > Dave Ward > >> > Santosh Pallagatti > >> > Filename : draft-ietf-bfd-multipoint-04.txt > >> > Pages : 27 > >> > Date : 2014-08-12 > >> > > >> > Abstract: > >> > This document describes extensions to the Bidirectional Forwardin= g > >> > Detection (BFD) protocol for its use in multipoint and multicast > >> > networks. Comments on this draft should be directed to rtg- > >> > bfd@ietf.org. > >> > > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > >> > > >> > > >> > Please note that it may take a couple of minutes from the time of > >> > submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > > --_000_7347100B5761DC41A166AC17F22DF1121B859B63eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nobo,
thank you for so precisely and eloquently formulating it:
Knowing exactly what aspect is being ques= tioned for removal may provide a better base for good discussions.
I see several possible scenarios:
  • keep the scope of the document as-is;
  • extract and move to an ap= pendix as informational/historical description of tail monitoring but keep = all new variables and states in standard part as currently defined (dormant= but readily available);
  • rip off everything related to tail monitor= ing from the standard part (major, huge undertaking IMO).
 
Have I missed any other option?
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
Sent: Friday, October 10, 2014 7:48 AM
To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org
Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt
 
Santosh,
 
It will helpful to clarify exactly what you mean by "active tail&= quot;.
 
- Do you intend to keep tail reporting of the failure (bfd.ReportTailD= own=3D1)?
- Is it just unicast poll from head that is being questioned for remov= al?
 
Knowing exactly what aspect is being questioned for removal may provid= e a better base for good discussions.
 
Thanks!
 
-Nobo
 
> -----Original Message-----
> From: Santosh P K [mailt= o:santoshpk@juniper.net]
> Sent: Thursday, October 09, 2014 10:39 PM
> To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg- =
> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt
>
> Thanks Hendreickx for your reply.
>
> -----Original Message-----
> From: Henderickx, Wim (Wim) [mailto:wim.henderic= kx@alcatel-
> lucent.com]
> Sent: Friday, October 10, 2014 12:29 AM
> To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org
> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt
>
> In certain environment the tracking of the tails is happening by = other means.
> Example is Multicast VPN using MP-BGP.
>
> On 09/10/14 17:38, "Nobo Akiya (nobo)" <nobo@cisco.com> wrote:
>
> >[With Chair Hat On]
> >
> >Dear WG,
> >
> >The topic of keeping or removing the active tail from
> >draft-ietf-bfd-multipoint is one of the last couple of topics= that
> >we, as a WG, need to resolve for this document.
> >
> >Whether or not we keep or remove the active tail, leaves will= be able
> >to detect the failure of the multicast tree, which allows pro= tections
> >such as live-live.
> >
> >What is essentially different:
> >
> >Keeping the active tail - Allows ingress/root to keep track o= f leaves.
> >
> >Removing the active tail - Ingress/root will not be able to k= eep
> >track of leaves.
> >
> >If there's any requirements for the ingress/root to trigger s= ome
> >protections, then active tail becomes a requirement. If there= is no
> >such requirements, then the active tail is an unnecessary por= tion of
> >this document.
> >
> >It'll be beneficial to hear your thoughts/comments to help ga= uge
> >where we are on this matter as a WG.
> >
> >Comments/thoughts?
> >
> >Thanks!
> >
> >-Nobo
> >
> >> -----Original Message-----
> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> >> Santosh P K
> >> Sent: Monday, October 06, 2014 9:27 AM
> >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org
> >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.tx= t
> >>
> >> Sorry for typo in my precious mail  "active ta= le" it is "active tail".
> >>
> >> Thanks
> >> Santosh P K
> >>
> >> -----Original Message-----
> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> >> Santosh P K
> >> Sent: Monday, October 06, 2014 6:22 PM
> >> To: Jeffrey Haas; rt= g-bfd@ietf.org
> >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.tx= t
> >>
> >> Hello All,
> >>    I am seeking comments on active tale s= ection of this document. I
> >>spoke to  few implementers and found that no one rea= lly finds use
> >>case for active tale.
> >> Does anyone on this forum feel that we might need active= tale? If
> >>there are  no uses cases then we can move active tal= e section to
> >>appendix? We would  like to make all the changes bef= ore IETF 91 and
> >>push this for RFC. Any  suggestions?
> >>
> >> Thanks
> >> Santosh P K
> >>
> >> -----Original Message-----
> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
> >>Jeffrey Haas
> >> Sent: Tuesday, August 19, 2014 7:38 PM
> >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.tx= t
> >>
> >> Note that this consists mostly of a re-publish with Sant= osh as the
> >>new editor.
> >> (And moving from .nroff to .xml.)
> >>
> >> In the next few weeks, Santosh will be working with know= n
> >>implementors to  edit the document to match implemen= tation.  Ideally
> >>these edits will be  complete prior to the next IETF= session in
> >>Honolulu.  This will put us a bit  past our ori= ginal milestone for
> >>publication, but still much better on track  than ma= ny of our
> >>previous documents.
> >>
> >> -- Jeff
> >>
> >>
> >>
> >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org
> >>wrote:
> >> >
> >> > A New Internet-Draft is available from the on-line =
> >> > Internet-Drafts
> >> directories.
> >> >  This draft is a work item of the Bidirectiona= l Forwarding
> >> > Detection
> >> Working Group of the IETF.
> >> >
> >> >         Tit= le           : BFD for Mu= ltipoint Networks
> >> >         Aut= hors         : Dave Katz
> >> >        &nbs= p;            &= nbsp;     Dave Ward
> >> >        &nbs= p;            &= nbsp;     Santosh Pallagatti
> >> >   Filename     &= nbsp;  : draft-ietf-bfd-multipoint-04.txt
> >> >   Pages     &nbs= p;     : 27
> >> >   Date      = ;      : 2014-08-12
> >> >
> >> > Abstract:
> >> >    This document describes extension= s to the Bidirectional Forwarding
> >> >    Detection (BFD) protocol for its = use in multipoint and multicast
> >> >    networks.  Comments on this = draft should be directed to rtg-
> >> >    b= fd@ietf.org.
> >> >
> >> >
> >> >
> >> > The IETF datatracker status page for this draft is:=
> >> >
> >> > There's also a htmlized version available at:
> >> >
> >> > A diff from the previous version is available at:
> >> >
> >> >
> >> > Please note that it may take a couple of minutes fr= om the time of
> >> > submission until the htmlized version and diff are = available at
> >> tools.ietf.org.
> >> >
> >> > Internet-Drafts are also available by anonymous FTP= at:
> >
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B859B63eusaamb103erics_-- From nobody Fri Oct 10 09:52:45 2014 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 4187F1A8769 for ; Fri, 10 Oct 2014 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, 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 p15cqPUNU_fX for ; Fri, 10 Oct 2014 09:52:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id F02F11A913F for ; Fri, 10 Oct 2014 09:48:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A6740C06C; Fri, 10 Oct 2014 12:48:03 -0400 (EDT) Date: Fri, 10 Oct 2014 12:48:03 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Message-ID: <20141010164803.GB28239@pfrc> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B859B63@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B859B63@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tTsrIYmlTb8zI-dEsacKStsIvis 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, 10 Oct 2014 16:52:43 -0000 On Fri, Oct 10, 2014 at 04:28:49PM +0000, Gregory Mirsky wrote: > Hi Nobo, > thank you for so precisely and eloquently formulating it: > Knowing exactly what aspect is being questioned for removal may provide a better base for good discussions. > I see several possible scenarios: > * keep the scope of the document as-is; > * extract and move to an appendix as informational/historical description of tail monitoring but keep all new variables and states in standard part as currently defined (dormant but readily available); > * rip off everything related to tail monitoring from the standard part (major, huge undertaking IMO). > > Have I missed any other option? * Extract it to a new RFC extending the base multipoint draft; target it for experimental status. -- Jeff From nobody Tue Oct 14 04:21:42 2014 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 CFD1B1A86DE for ; Tue, 14 Oct 2014 04:21:39 -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, 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 CQ2m17WOTLhc for ; Tue, 14 Oct 2014 04:21:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0786.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:786]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1931A86E9 for ; Tue, 14 Oct 2014 04:21:36 -0700 (PDT) Received: from DM2PR05MB766.namprd05.prod.outlook.com (10.141.179.21) by DM2PR05MB766.namprd05.prod.outlook.com (10.141.179.21) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Tue, 14 Oct 2014 11:21:12 +0000 Received: from DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) by DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) with mapi id 15.00.1044.008; Tue, 14 Oct 2014 11:21:12 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyA= Date: Tue, 14 Oct 2014 11:21:12 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB766; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(51704005)(13464003)(24454002)(479174003)(377454003)(377424004)(53754006)(189002)(199003)(41574002)(107046002)(230783001)(101416001)(31966008)(19580395003)(4396001)(74316001)(106116001)(21056001)(87936001)(108616004)(40100003)(19580405001)(120916001)(85852003)(2656002)(15975445006)(86362001)(64706001)(85306004)(106356001)(66066001)(99396003)(50986999)(80022003)(33646002)(107886001)(97736003)(92566001)(76482002)(95666004)(93886004)(99286002)(15202345003)(105586002)(46102003)(76576001)(122556002)(20776003)(76176999)(54356999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB766; H:DM2PR05MB766.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SqNuX7fpzBNrUioNlIt1db8GAl4 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, 14 Oct 2014 11:21:40 -0000 Hello All, Sorry for delay. I am trying to elaborate what I meant by "active tail".= Please also comment on other two items that I have listed below which were= raised by Prasad and Nobo in earlier discussions.=20 Active tail: ------------ As per discussion with implementers it looks like we don't see any use case= scenario for head tracking tail. Currently there are multiple options give= n in draft for head to track tail.=20 1. Unreliable Head Notification as per section 6.2 When tail detect timer expires it sends DOWN BFD packet to head on revers= e unicast path.=20 2. Semi-reliable Head Notification and Tail Solicitation as per section 6.= 3 A multipoint POLL with a combination of reverse unicast path FINAL will h= elp head to know if tail has lost communication with head. 3. Reliable Head Notification as per section 6.4 A combination of multipoint POLL and unicast POLL will be used by head t= o detect tail going down. Tail will make use of reverse unicast path to sen= d FINAL packet to head.=20 We have below options: 1. Go with simple "No Head Notification" as per section 6.1 in base draft = and move rest of the sections to Appendix or move to separate draft? In th= is case On MultipointHead bfd.ReportTailDown=20 will be set to 0 and we might not even need MultipointClient as we ar= e not going to receive any packets from tail. bfd.SilentTail will be set to= 1 on MultipointTail 2. Another option is to just keep "Unreliable Head Notification" as per se= ction 6.2 and move/remove rest of mechanism through which Multipoint head c= an detect tail going down. Meaning we need to move/remove Multicast POLL and unicast POLL from M= ultipointHead.=20 3. Jeff suggested that we move these sections to new draft with experiment= al status.=20 4. Any other options? Please suggest. Along with this I am also seeking comments on below two points. Demux: --------- This was brought up by Prasad in context of EVPN BFD draft that as per sect= ion 4.7 of this draft say " The minimum amount of a priori information required both on the head=20 and tails is the binding to the multipoint path over which BFD is run= ning." Above text is brief and draft is AF agnostic. Do we need to make text of Se= c 4.7 and related sections more explicit? For example in case of EVPN tail = nodes may use the P2MP label as the session demux key. Do we want to elabor= ate demux in base draft or it should be outside the scope of this document?= =20 Security consideration: ---------------------------- As per Nobo's comment on this draft long back. We need to add some suggest= ion in security consideration. Mainly because MultipointTail session can be= created dynamically. Snippet from Nobo's mail.=20 "MultipointTail sessions are dynamically created. If I had a way of getting= around GTSM & Authentication (or lack of) and was aware of a source addres= s that will pass the "check", then I could DoS this system with range of My= Discriminator values to leaves, which will cause many instances of Multipo= intTail sessions to get created. Draft does say [create or discard] choice = is outside the scope (in 4.16.2). But given the dynamic nature of session c= reation, it would be beneficial to highlight this point and provide suggest= ions in the "Security Consideration"." Any suggestion on this? Jeff and Nobo have already raised some concerns here. We might have to see = how PIM is doing it today.=20 Thanks Santosh P K=20 -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Friday, October 10, 2014 8:18 PM To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Santosh, It will helpful to clarify exactly what you mean by "active tail". - Do you intend to keep tail reporting of the failure (bfd.ReportTailDown= =3D1)? - Is it just unicast poll from head that is being questioned for removal? Knowing exactly what aspect is being questioned for removal may provide a b= etter base for good discussions. Thanks! -Nobo > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Thursday, October 09, 2014 10:39 PM > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg-=20 > bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Thanks Hendreickx for your reply. >=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-=20 > lucent.com] > Sent: Friday, October 10, 2014 12:29 AM > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > In certain environment the tracking of the tails is happening by other me= ans. > Example is Multicast VPN using MP-BGP. >=20 > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: >=20 > >[With Chair Hat On] > > > >Dear WG, > > > >The topic of keeping or removing the active tail from=20 > >draft-ietf-bfd-multipoint is one of the last couple of topics that=20 > >we, as a WG, need to resolve for this document. > > > >Whether or not we keep or remove the active tail, leaves will be able=20 > >to detect the failure of the multicast tree, which allows protections=20 > >such as live-live. > > > >What is essentially different: > > > >Keeping the active tail - Allows ingress/root to keep track of leaves. > > > >Removing the active tail - Ingress/root will not be able to keep=20 > >track of leaves. > > > >If there's any requirements for the ingress/root to trigger some=20 > >protections, then active tail becomes a requirement. If there is no=20 > >such requirements, then the active tail is an unnecessary portion of=20 > >this document. > > > >It'll be beneficial to hear your thoughts/comments to help gauge=20 > >where we are on this matter as a WG. > > > >Comments/thoughts? > > > >Thanks! > > > >-Nobo > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > >> Santosh P K > >> Sent: Monday, October 06, 2014 9:27 AM > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Sorry for typo in my precious mail "active tale" it is "active tail". > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > >> Santosh P K > >> Sent: Monday, October 06, 2014 6:22 PM > >> To: Jeffrey Haas; rtg-bfd@ietf.org > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Hello All, > >> I am seeking comments on active tale section of this document. I=20 > >>spoke to few implementers and found that no one really finds use=20 > >>case for active tale. > >> Does anyone on this forum feel that we might need active tale? If=20 > >>there are no uses cases then we can move active tale section to=20 > >>appendix? We would like to make all the changes before IETF 91 and=20 > >>push this for RFC. Any suggestions? > >> > >> Thanks > >> Santosh P K > >> > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > >>Jeffrey Haas > >> Sent: Tuesday, August 19, 2014 7:38 PM > >> To: rtg-bfd@ietf.org > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > >> > >> Note that this consists mostly of a re-publish with Santosh as the=20 > >>new editor. > >> (And moving from .nroff to .xml.) > >> > >> In the next few weeks, Santosh will be working with known=20 > >>implementors to edit the document to match implementation. Ideally=20 > >>these edits will be complete prior to the next IETF session in=20 > >>Honolulu. This will put us a bit past our original milestone for=20 > >>publication, but still much better on track than many of our=20 > >>previous documents. > >> > >> -- Jeff > >> > >> > >> > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org > >>wrote: > >> > > >> > A New Internet-Draft is available from the on-line=20 > >> > Internet-Drafts > >> directories. > >> > This draft is a work item of the Bidirectional Forwarding=20 > >> > Detection > >> Working Group of the IETF. > >> > > >> > Title : BFD for Multipoint Networks > >> > Authors : Dave Katz > >> > Dave Ward > >> > Santosh Pallagatti > >> > Filename : draft-ietf-bfd-multipoint-04.txt > >> > Pages : 27 > >> > Date : 2014-08-12 > >> > > >> > Abstract: > >> > This document describes extensions to the Bidirectional Forwardin= g > >> > Detection (BFD) protocol for its use in multipoint and multicast > >> > networks. Comments on this draft should be directed to rtg- > >> > bfd@ietf.org. > >> > > >> > > >> > > >> > The IETF datatracker status page for this draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > >> > > >> > There's also a htmlized version available at: > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > >> > > >> > A diff from the previous version is available at: > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > >> > > >> > > >> > Please note that it may take a couple of minutes from the time of=20 > >> > submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Tue Oct 14 04:24:20 2014 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 4B7741A86EF for ; Tue, 14 Oct 2014 04:24:13 -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, 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 FcScUSypRq54 for ; Tue, 14 Oct 2014 04:24:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9471A86EA for ; Tue, 14 Oct 2014 04:24:05 -0700 (PDT) Received: from DM2PR05MB766.namprd05.prod.outlook.com (10.141.179.21) by DM2PR05MB768.namprd05.prod.outlook.com (10.141.179.27) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Tue, 14 Oct 2014 11:24:03 +0000 Received: from DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) by DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) with mapi id 15.00.1044.008; Tue, 14 Oct 2014 11:24:03 +0000 From: Santosh P K To: "Vengada Prasad Govindan (venggovi)" , "Nobo Akiya (nobo)" , Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAGFBoCABg9aQA== Date: Tue, 14 Oct 2014 11:24:03 +0000 Message-ID: <38e26337c1a94b8a8b113bfa89981b55@DM2PR05MB766.namprd05.prod.outlook.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <315041E4211CB84E86EF7C25A2AB583D346AE69E@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D346AE69E@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB768; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(199003)(41574002)(13464003)(24454002)(377454003)(377424004)(53754006)(64706001)(99396003)(46102003)(20776003)(95666004)(93886004)(40100003)(108616004)(101416001)(80022003)(74316001)(21056001)(54356999)(120916001)(230783001)(85306004)(97736003)(86362001)(19580395003)(76576001)(107046002)(76482002)(106116001)(105586002)(4396001)(85852003)(19580405001)(50986999)(76176999)(87936001)(33646002)(106356001)(107886001)(15975445006)(99286002)(66066001)(31966008)(92566001)(15202345003)(122556002)(2656002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB768; H:DM2PR05MB766.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/eDq9kZzn5tvAIZ0lxJnyvALJDUo 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, 14 Oct 2014 11:24:13 -0000 Prasad, Thanks for your comments. I have raised the below point in my new mail. I= have consolidated all three points of discussion in one mail.=20 > There may be additional clarifications needed for the demux of BFD sessi= ons at the tails especially when tracking P2MP MPLS LSPs. We could start a = separate thread for those considerations. Thanks Santosh P K =20 -----Original Message----- From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com]=20 Sent: Friday, October 10, 2014 8:21 PM To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello Santosh, Since the usage of activeTail is currently optional, there may be benefit= in retaining the activeTail as part of the main specification. However we = could improve the specification of the activeTail, please find the followin= g observations in that context: Section 1: This document effectively modifies and adds to the base BFD specification. It is the intention of the authors to fold these extensions into the base specification at the appropriate time. GVP1> Should we consider removing the second sentence of the last paragraph= ? I assume that RFC 5880 would not change due to multi-point BFD gets stan= dardized. Section 2: A final goal is to integrate multipoint operation into the base specification in such a way as to make it relatively easy to support both multipoint and point-to-point operation in a single implementation. GVP1> Should we consider removing this goal? I assume that RFC 5880 would n= ot change due to multi-point BFD gets standardized. Section 3: In my understanding this section provides a lot of details in the way multi= pointTail sessions are bootstrapped and feedback on multipoint connectivity= is provided back to the head. However it may be better to consider splitti= ng this text into relevant sub-sections so important clauses needed for int= eroperability are not lost. In particular RFC 2119 verbs are not capitalize= d. I think it may be beneficial to explicitly capture the following aspects= : a/ Procedures for bootstrapping and maintaining multipointTail sessions (a= lready described in part in Sec 4.15.2) b/ Procedures for generating unicas= t BFD packets (reflecting the connectivity state) from the tail nodes: It i= s my understanding that the tails do not initiate unicast packets until the= head initiates the poll sequence for all tail nodes. If this is the case, = we could consider adding explicit text to this effect.=20 c/ Procedures for bootstrapping and maintaining multipointClient sessions: There may be additional clarifications needed for the demux of BFD sessions= at the tails especially when tracking P2MP MPLS LSPs. We could start a sep= arate thread for those considerations. =09 Regards Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Thursday, October 09, 2014 9:08 PM To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt [With Chair Hat On] Dear WG, The topic of keeping or removing the active tail from draft-ietf-bfd-multip= oint is one of the last couple of topics that we, as a WG, need to resolve = for this document. Whether or not we keep or remove the active tail, leaves will be able to de= tect the failure of the multicast tree, which allows protections such as li= ve-live. What is essentially different: Keeping the active tail - Allows ingress/root to keep track of leaves. Removing the active tail - Ingress/root will not be able to keep track of l= eaves. If there's any requirements for the ingress/root to trigger some protection= s, then active tail becomes a requirement. If there is no such requirements= , then the active tail is an unnecessary portion of this document. It'll be beneficial to hear your thoughts/comments to help gauge where we a= re on this matter as a WG. Comments/thoughts? Thanks! -Nobo > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Monday, October 06, 2014 9:27 AM > To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Sorry for typo in my precious mail "active tale" it is "active tail". >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P=20 > K > Sent: Monday, October 06, 2014 6:22 PM > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > I am seeking comments on active tale section of this document. I=20 > spoke to few implementers and found that no one really finds use case for= active tale. > Does anyone on this forum feel that we might need active tale? If=20 > there are no uses cases then we can move active tale section to=20 > appendix? We would like to make all the changes before IETF 91 and=20 > push this for RFC. Any suggestions? >=20 > Thanks > Santosh P K >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey=20 > Haas > Sent: Tuesday, August 19, 2014 7:38 PM > To: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Note that this consists mostly of a re-publish with Santosh as the new ed= itor. > (And moving from .nroff to .xml.) >=20 > In the next few weeks, Santosh will be working with known implementors=20 > to edit the document to match implementation. Ideally these edits=20 > will be complete prior to the next IETF session in Honolulu. This=20 > will put us a bit past our original milestone for publication, but=20 > still much better on track than many of our previous documents. >=20 > -- Jeff >=20 >=20 >=20 > On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > > > Title : BFD for Multipoint Networks > > Authors : Dave Katz > > Dave Ward > > Santosh Pallagatti > > Filename : draft-ietf-bfd-multipoint-04.txt > > Pages : 27 > > Date : 2014-08-12 > > > > Abstract: > > This document describes extensions to the Bidirectional Forwarding > > Detection (BFD) protocol for its use in multipoint and multicast > > networks. Comments on this draft should be directed to rtg- > > bfd@ietf.org. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > > > > Please note that it may take a couple of minutes from the time of=20 > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 11:06:51 2014 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 B141D1A9138; Tue, 14 Oct 2014 11:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 N2OT62WXHweg; Tue, 14 Oct 2014 11:06:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4F91ACC91; Tue, 14 Oct 2014 11:06:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-intervals-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014180639.25129.60902.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 11:06:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lTbX32Y4jGf6U9LboQ3p-dl-rT8 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 18:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Common Interval Support in Bidirectional Forwarding Detection Authors : Nobo Akiya Marc Binderberger Greg Mirsky Filename : draft-ietf-bfd-intervals-05.txt Pages : 8 Date : 2014-10-14 Abstract: Bidirectional Forwarding Detection (BFD) requires that messages are transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions. This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 14 14:20:50 2014 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 4DF8E1ACD19; Tue, 14 Oct 2014 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vcRDOwBa1DE8; Tue, 14 Oct 2014 14:20:43 -0700 (PDT) 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 684DE1A005E; Tue, 14 Oct 2014 14:20:43 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-d7-543d3c624e53 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CE.AF.05330.36C3D345; Tue, 14 Oct 2014 17:08:19 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 17:20:08 -0400 From: Gregory Mirsky To: Ronald Bonica , "mpls@ietf.org" Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5+T1qcCg/R14/UmZV1nG50qHqZwv/D+wgAAbKtA= Date: Tue, 14 Oct 2014 21:20:07 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> In-Reply-To: <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> 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_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLonSjfZxjbE4MB3JYsL2++zWdxaupLV 4sB3B4vPf7YxOrB4LFnyk8njetNVdo8vlz+zBTBHcdmkpOZklqUW6dslcGU8PdrBVtDrUnFy 4zOmBsZu6y5GTg4JAROJW9OXsEDYYhIX7q1n62Lk4hASOMoocbl3IQuEs5xR4tzVzWBVbAJG Ei829rCD2CICHhJ965rAOpgFJjFKnN+8jhUkISwQKXHz40c2iKIoicmLjkDZVhIXzr0Da2YR UJU4+OUKWD2vgK9E/5kfUKt7GSW+tvcxgSQ4BcIknn17AlbECHTf91NrwOLMAuISt57MZ4K4 W0BiyZ7zzBC2qMTLx/9YIWxFiX3909kh6vMlTjx7ywSxTFDi5MwnLBMYRWchGTULSdksJGUQ cR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66kcEmRmDcHZNg093BuOel5SFG AQ5GJR5eBWGbECHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YFyjo/XT4+10p2PHeJOajZKlOYxPZlzXevR4fqRI9sXXnbLK9mcidofU/zbZLXbjVnz0giXT Zkbldj0UmybQVPnZxszze0jqzQO34tbXSy/8ek3PYtVaEcN7Ugu/1SSfObCVpaz+6FVOa4fQ XUsFZF8lzdByX8F6QtTv8cO6Kv+aNpbT1/I371JiKc5INNRiLipOBACtsVP8nAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LuTXIIyELrNfhquAG7Sl3V4jo38 Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.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, 14 Oct 2014 21:20:46 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ron,
thank you for bringing this work to discussion. I agree that lightweig= ht mechanism to verify LSP availability is useful and valuable tool in OAM = toolbox. Possible use of LSP Ping already been discussed in the document an= d thus I would like to reference another mechanism that authors of the Seamless Bid= irectional Forwarding Detection (BFD) Use Case document beli= eve addresses the problem stated in the Self-ping draft. Perhaps you can review and share your comments on S-BF= D Use Case document and Section 3.1 Unidirectional Forwarding Path Validati= on in particular.
 
Greatly appreciate your feedback.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt
 
Folks,
 
Please review and comment
 
           &nbs= p;             = Ron
 
 
> -----Original Message-----
> Sent: Tuesday, October 14, 2014 3:28 PM
> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi;
> Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT = -
> Conn; Dante Pacella; EXT - mark.wygant@verizon.com
> Subject: New Version Notification for
> draft-bonica-mpls-self-ping-00.txt
>
>
> A new version of I-D, draft-bonica-mpls-self-ping-00.txt
> has been successfully submitted by Ron Bonica and posted to the I= ETF
> repository.
>
> Name:         draft-bonic= a-mpls-self-ping
> Revision:     00
> Title:          = ;      LSP Self-Ping
> Document date:        2014-10-= 14
> Group:          = ;      Individual Submission
> Pages:          = ;      7
> 00.txt
>
>
> Abstract:
>    This memo describes LSP Self-ping.  An ing= ress LSR can use LSP Self-
>    ping to verify that an LSP is ready to carry tr= affic.
>
>
>
>
> Please note that it may take a couple of minutes from the time of=
> submission until the htmlized version and diff are available at t= ools.ietf.org.
>
> The IETF Secretariat
 
_______________________________________________
mpls mailing list
 
 --_000_7347100B5761DC41A166AC17F22DF1121B85CBD7eusaamb103erics_-- From nobody Tue Oct 14 14:32:59 2014 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 EEE481ACD2D; Tue, 14 Oct 2014 14:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.286 X-Spam-Level: X-Spam-Status: No, score=-115.286 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 f9MZpWAICcX1; Tue, 14 Oct 2014 14:32:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6981ACD19; Tue, 14 Oct 2014 14:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28622; q=dns/txt; s=iport; t=1413322372; x=1414531972; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eBnM3ecwP46UESUIqFa6z8e6bKidW39K5wmJgZBWBuY=; b=e9rSgyWKAgNjXG32w+mJXLrF4x4lPiavEBQbayPM3/0sbCKY7KlK6EjJ mXzyOoYr6ZmLSAsxnuLWAWGzZMN3NFjeRnscQA1y+M5TTIoQh8elLP0yb 85vfL0QdC3QhOWQ7ybFLswt3ga72UyFXrxDalJAKtqVLvP6fU4OE/RSUR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAC2VPVStJV2d/2dsb2JhbABbgkgjI1NYBMpJgWMBCYdNAoEXFgF9hAIBAQEDAQEBASpBCQIFBwQCAQgRBAEBCxYBBgcnCxQIAQgCBAENBQgBiCEDCQgBDMcpAQEBAQEBAQEBAQEBAQEBAQEBAQEBF44TggEtBAYBBgODJIEeBY9fghqEQog+PIMKjR+DfoIGGIFZbIEIJByBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208,217";a="363293779" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Oct 2014 21:32:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9ELWoaw022575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 21:32:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 16:32:50 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , Ronald Bonica , "mpls@ietf.org" Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/S+Gv5QLnD300KRpmKZHU+QY5wwGbuw Date: Tue, 14 Oct 2014 21:32:48 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CfCrT9B3ur6YauEYwpmWaJcAFWs Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.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, 14 Oct 2014 21:32:56 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, I agree with Greg that a light weight mechanism to verify LSP availability = is useful, and S-BFD may be a good fit for your needs. One comment in draft-bonica-mpls-self-ping-00. [snip from draft-bonica-mpls-self-ping-00, Section 2] If the protocol messages used to establish the LSP were delivered over IPv4 [RFC0791] the probe message is an ICMPv4 [RFC0792] Echo Reply. If the protocol messages used to establish the LSP were delivered over IPv6 [RFC2460] the probe message is an ICMPv6 [RFC4443] Echo Reply. In either case, the contents of the ICMP message are as follows: o Source Address equals the address of the egress LSR o Destination Address equals the address of the ingress LSR [snip] Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,=

 <= /p>

I agree with Greg that a = light weight mechanism to verify LSP availability is useful, and S-BFD may = be a good fit for your needs.

 <= /p>

One comment in draft-boni= ca-mpls-self-ping-00.

 <= /p>

[snip from draft-bonica-m= pls-self-ping-00, Section 2]

   If the proto= col messages used to establish the LSP were delivered

   over IPv4 [R= FC0791] the probe message is an ICMPv4 [RFC0792] Echo

   Reply. = If the protocol messages used to establish the LSP were<= /p>

   delivered ov= er IPv6 [RFC2460] the probe message is an ICMPv6

   [RFC4443] Ec= ho Reply.  In either case, the contents of the ICMP<= /p>

   message are = as follows:

 <= /p>

   o  Sour= ce Address equals the address of the egress LSR

 <= /p>

   o  Dest= ination Address equals the address of the ingress LSR

[snip]<= /p>

 <= /p>

Destination address havin= g a valid IP address (i.e. address of ingress LSR) means that this probe wi= ll come back to the ingress LSR when:

- transit LSR false pops = and forwards (due to incorrect label programming)

- transit LSR false forwa= rds elsewhere and happens to terminates at some other network nodes via dif= ferent LSP (due to incorrect label programming)

 <= /p>

Certain packets over such= LSP (ex: VPN) will likely get dropped even though proposed probe reports s= uccess, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.

 <= /p>

When applied to the LDP i= ndependent mode, proposed probe will have the same “false positive= 221; issue with “end-to-end LSP not ready” case as well.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

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

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943A44587Cxmbalnx01ciscoc_-- From nobody Tue Oct 14 15:23:12 2014 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 8AA9F1A0004; Tue, 14 Oct 2014 15:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TPoRs4pcILrd; Tue, 14 Oct 2014 15:23:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 053371A002F; Tue, 14 Oct 2014 15:22:57 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Document Action: 'Common Interval Support in Bidirectional Forwarding Detection' to Informational RFC (draft-ietf-bfd-intervals-05.txt) X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014222257.20153.82472.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 15:22:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lnTCiPlZBd9iTvkA1QQP02gMuUY Cc: bfd mailing list , bfd chair , RFC Editor X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 22:23:07 -0000 The IESG has approved the following document: - 'Common Interval Support in Bidirectional Forwarding Detection' (draft-ietf-bfd-intervals-05.txt) as Informational RFC This document is the product of the Bidirectional Forwarding Detection Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ Technical Summary Bidirectional Forwarding Detection (BFD) requires that messages are transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common Intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals. Working Group Summary: Discussion in the working group among known implementers of BFD was relatively quiet but supportive of this document. The only discussion that generated any significant amount of "noise" was the discussion of whether these well known common intervals should have an IANA registry to permit the maintenance of this document without requiring a RFC revision. The consensus of that discussion was that an IANA registry was not desired. Document Quality: Multiple implementations support the full range of documented values in either hardware or software, depending on the implementation. The only value that doesn't have very wide support is the 3.3ms value, but support for this value seems to be becoming more common. Personnel: Document Shepherd: Jeffrey Haas Responsible Area Director: Adrian Farrel From nobody Tue Oct 14 15:34:04 2014 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 61D111A0019 for ; Tue, 14 Oct 2014 15:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.287 X-Spam-Level: X-Spam-Status: No, score=-115.287 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, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 MNMIcFks5klZ for ; Tue, 14 Oct 2014 15:34:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75291A0056 for ; Tue, 14 Oct 2014 15:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12429; q=dns/txt; s=iport; t=1413326038; x=1414535638; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Qhe6PwrsM7wP27W/tJy4FitFr4bAEEDgwCSmvrNQchI=; b=AhyAxkdKRtXh/d8It5b0zhn/2as0eb1n6bH1B3q7Ei34y38hEvgWtqTI XeKYogTnfHZKc+uXt4rfLB3ZgQrKsapEKb265jI1eNHzhFrqK/XqeI0Zt wZNn6cjxAFwvA5cXKyy2dIYxhlk6Wdsn1NSA/S7vBvghdiWKjX/MRPOTl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKSkPVStJA2D/2dsb2JhbABbgmsjU1MFBMw2h00CgRIWAX2EAgEBAQMBOkQHBAIBCBEEAQEBChQJBzIUCQgCBAESCAGILQgBBwXHJQEBAQEBAQEBAQEBAQEBAQEBAQEBARePdAEBHjgGgyeBHgWGLYkyghqEQog+PIMKjR+DfoIGGIFZbIEGBQQXIoECAQEB X-IronPort-AV: E=Sophos;i="5.04,719,1406592000"; d="scan'208";a="86979711" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 14 Oct 2014 22:33:41 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9EMXgGa030590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Oct 2014 22:33:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 14 Oct 2014 17:33:41 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" , Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUPZOBPokD+keyL4hHqvmqqpvYS1kAgEtadQCAAAnegIAEgS9ggAA+kgCAANSjgIAAY87wgAZ3TgCAAFqOoA== Date: Tue, 14 Oct 2014 22:33:41 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> 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.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BIJ8jbAoem9dYePLUSi65WjzT7U 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, 14 Oct 2014 22:34:03 -0000 [With Chair Hat Off] Hi Santosh, Thank you for leading this effort! Hopefully others can provide their comments to help close of last remaining= points for the BFD multipoint document. Please see my comments in-line. > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, October 14, 2014 7:21 AM > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg- > bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > Sorry for delay. I am trying to elaborate what I meant by "active tail= ". > Please also comment on other two items that I have listed below which > were raised by Prasad and Nobo in earlier discussions. >=20 > Active tail: > ------------ > As per discussion with implementers it looks like we don't see any use ca= se > scenario for head tracking tail. Currently there are multiple options giv= en in > draft for head to track tail. > 1. Unreliable Head Notification as per section 6.2 > When tail detect timer expires it sends DOWN BFD packet to > head on reverse unicast path. > 2. Semi-reliable Head Notification and Tail Solicitation as per section > 6.3 > A multipoint POLL with a combination of reverse unicast > path FINAL will help head to know if tail has lost communication with hea= d. > 3. Reliable Head Notification as per section 6.4 > A combination of multipoint POLL and unicast POLL will be > used by head to detect tail going down. Tail will make use of reverse uni= cast > path to send FINAL packet to head. One important characteristics is that: (1) allows the head to be notified of _in-band_ failure by leaves. (2) allows the head to poll leaves through _in-band_ packets. (3) allows the head to poll leaves through _out-of-band_ unicast packets. Going back to what Wim wrote (thanks for the comment Wim!): [snip] > In certain environment the tracking of the tails is happening by other me= ans. > Example is Multicast VPN using MP-BGP. [snip] True, in the scenario described, (3) adds very minimal value beyond running= multi-hop BFD session between BGP peers. On the other hand (1) and (2) are in-band, and can detect failures that oth= er sessions like multi-hop BFD sessions cannot. It does look useful with te= chnologies such as P2MP-TE where: - leaves are constant - has path-protection mechanism =20 >=20 > We have below options: > 1. Go with simple "No Head Notification" as per section 6.1 in base > draft and move rest of the sections to Appendix or move to separate draft= ? > In this case On MultipointHead bfd.ReportTailDown > will be set to 0 and we might not even need MultipointClient as > we are not going to receive any packets from tail. bfd.SilentTail will be= set > to 1 on MultipointTail > 2. Another option is to just keep "Unreliable Head Notification" as > per section 6.2 and move/remove rest of mechanism through which > Multipoint head can detect tail going down. > Meaning we need to move/remove Multicast POLL and unicast > POLL from MultipointHead. Another way to look at this is that: (a) unicast DOWN notification from leaves. (b) multicast Poll of leaves. (c) unicast Poll of leaves. If we want to keep the in-band mechanism and remove out-of-band mechanism, = then preserve (a) and (b) but remove (c). And that would be my preference. Mingui, for your "TRILL Resilient Distribution Trees", do you see the need = for all [a-c] or just subsets? > 3. Jeff suggested that we move these sections to new draft with > experimental status. > 4. Any other options? Please suggest. >=20 >=20 > Along with this I am also seeking comments on below two points. > Demux: > --------- > This was brought up by Prasad in context of EVPN BFD draft that as per > section 4.7 of this draft say >=20 > " The minimum amount of a priori information required both on the > head > and tails is the binding to the multipoint path over which BFD is > running." >=20 > Above text is brief and draft is AF agnostic. Do we need to make text of = Sec > 4.7 and related sections more explicit? For example in case of EVPN tail > nodes may use the P2MP label as the session demux key. Do we want to > elaborate demux in base draft or it should be outside the scope of this > document? Demux procedures is one, UDP port is the other one (i.e. it is not specifie= d in this document). We need to either: - Add details in this document, or - Consider this document as multipoint base document, and roll out micro-do= cuments describing demux/UDP-port details for various data planes. Either will work, but the details are required somewhere to interoperate. >=20 > Security consideration: > ---------------------------- > As per Nobo's comment on this draft long back. We need to add some > suggestion in security consideration. Mainly because MultipointTail sessi= on > can be created dynamically. >=20 > Snippet from Nobo's mail. >=20 > "MultipointTail sessions are dynamically created. If I had a way of getti= ng > around GTSM & Authentication (or lack of) and was aware of a source > address that will pass the "check", then I could DoS this system with ran= ge > of My Discriminator values to leaves, which will cause many instances of > MultipointTail sessions to get created. Draft does say [create or discard= ] > choice is outside the scope (in 4.16.2). But given the dynamic nature of > session creation, it would be beneficial to highlight this point and prov= ide > suggestions in the "Security Consideration"." >=20 > Any suggestion on this? >=20 > Jeff and Nobo have already raised some concerns here. We might have to > see how PIM is doing it today. Right it would be a good idea how other multipoint/multicast protocols have= addressed this. Thanks! -Nobo >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Friday, October 10, 2014 8:18 PM > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Santosh, >=20 > It will helpful to clarify exactly what you mean by "active tail". >=20 > - Do you intend to keep tail reporting of the failure > (bfd.ReportTailDown=3D1)? > - Is it just unicast poll from head that is being questioned for removal? >=20 > Knowing exactly what aspect is being questioned for removal may provide a > better base for good discussions. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net] > > Sent: Thursday, October 09, 2014 10:39 PM > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg- > > bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Thanks Hendreickx for your reply. > > > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > lucent.com] > > Sent: Friday, October 10, 2014 12:29 AM > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > In certain environment the tracking of the tails is happening by other > means. > > Example is Multicast VPN using MP-BGP. > > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: > > > > >[With Chair Hat On] > > > > > >Dear WG, > > > > > >The topic of keeping or removing the active tail from > > >draft-ietf-bfd-multipoint is one of the last couple of topics that > > >we, as a WG, need to resolve for this document. > > > > > >Whether or not we keep or remove the active tail, leaves will be able > > >to detect the failure of the multicast tree, which allows protections > > >such as live-live. > > > > > >What is essentially different: > > > > > >Keeping the active tail - Allows ingress/root to keep track of leaves. > > > > > >Removing the active tail - Ingress/root will not be able to keep > > >track of leaves. > > > > > >If there's any requirements for the ingress/root to trigger some > > >protections, then active tail becomes a requirement. If there is no > > >such requirements, then the active tail is an unnecessary portion of > > >this document. > > > > > >It'll be beneficial to hear your thoughts/comments to help gauge > > >where we are on this matter as a WG. > > > > > >Comments/thoughts? > > > > > >Thanks! > > > > > >-Nobo > > > > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >> Santosh P K > > >> Sent: Monday, October 06, 2014 9:27 AM > > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Sorry for typo in my precious mail "active tale" it is "active tail= ". > > >> > > >> Thanks > > >> Santosh P K > > >> > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >> Santosh P K > > >> Sent: Monday, October 06, 2014 6:22 PM > > >> To: Jeffrey Haas; rtg-bfd@ietf.org > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Hello All, > > >> I am seeking comments on active tale section of this document. I > > >>spoke to few implementers and found that no one really finds use > > >>case for active tale. > > >> Does anyone on this forum feel that we might need active tale? If > > >>there are no uses cases then we can move active tale section to > > >>appendix? We would like to make all the changes before IETF 91 and > > >>push this for RFC. Any suggestions? > > >> > > >> Thanks > > >> Santosh P K > > >> > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >>Jeffrey Haas > > >> Sent: Tuesday, August 19, 2014 7:38 PM > > >> To: rtg-bfd@ietf.org > > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Note that this consists mostly of a re-publish with Santosh as the > > >>new editor. > > >> (And moving from .nroff to .xml.) > > >> > > >> In the next few weeks, Santosh will be working with known > > >>implementors to edit the document to match implementation. Ideally > > >>these edits will be complete prior to the next IETF session in > > >>Honolulu. This will put us a bit past our original milestone for > > >>publication, but still much better on track than many of our > > >>previous documents. > > >> > > >> -- Jeff > > >> > > >> > > >> > > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org > > >>wrote: > > >> > > > >> > A New Internet-Draft is available from the on-line > > >> > Internet-Drafts > > >> directories. > > >> > This draft is a work item of the Bidirectional Forwarding > > >> > Detection > > >> Working Group of the IETF. > > >> > > > >> > Title : BFD for Multipoint Networks > > >> > Authors : Dave Katz > > >> > Dave Ward > > >> > Santosh Pallagatti > > >> > Filename : draft-ietf-bfd-multipoint-04.txt > > >> > Pages : 27 > > >> > Date : 2014-08-12 > > >> > > > >> > Abstract: > > >> > This document describes extensions to the Bidirectional Forward= ing > > >> > Detection (BFD) protocol for its use in multipoint and multicas= t > > >> > networks. Comments on this draft should be directed to rtg- > > >> > bfd@ietf.org. > > >> > > > >> > > > >> > > > >> > The IETF datatracker status page for this draft is: > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > >> > > > >> > There's also a htmlized version available at: > > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > >> > > > >> > A diff from the previous version is available at: > > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > >> > > > >> > > > >> > Please note that it may take a couple of minutes from the time of > > >> > submission until the htmlized version and diff are available at > > >> tools.ietf.org. > > >> > > > >> > Internet-Drafts are also available by anonymous FTP at: > > >> > ftp://ftp.ietf.org/internet-drafts/ > > > From nobody Wed Oct 15 08:36:57 2014 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 C9D041A87ED; Wed, 15 Oct 2014 08:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 6mHZokuj7Una; Wed, 15 Oct 2014 08:36:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C615A1A8838; Wed, 15 Oct 2014 08:36:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 86D11C22C; Wed, 15 Oct 2014 11:36:54 -0400 (EDT) Date: Wed, 15 Oct 2014 11:36:54 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Message-ID: <20141015153654.GE18720@pfrc> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> 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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_UynUFRdfcPlnFJ_TwfqLvXGA8I Cc: Ronald Bonica , "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.ietf.org" , "mpls@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, 15 Oct 2014 15:36:55 -0000 On Tue, Oct 14, 2014 at 09:32:48PM +0000, Nobo Akiya (nobo) wrote: > Hi Ron, > > I agree with Greg that a light weight mechanism to verify LSP availability is useful, and S-BFD may be a good fit for your needs. FWIW, this discussion may also be relevant to be cc'd to lime@ietf. -- Jeff From nobody Thu Oct 16 11:16:59 2014 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 6546F1A011E; Thu, 16 Oct 2014 11:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, 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 z1VTgjwCD_RB; Thu, 16 Oct 2014 11:16:54 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BC51A011D; Thu, 16 Oct 2014 11:16:53 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 18:16:30 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 18:16:30 +0000 From: Ronald Bonica To: Gregory Mirsky , "mpls@ietf.org" Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/Sz532BBBssAEmtAXBon3Z/HZwzBFYw Date: Thu, 16 Oct 2014 18:16:29 +0000 Message-ID: <95c3da24b7e7438a9044c037b0920781@CO1PR05MB442.namprd05.prod.outlook.com> References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(199003)(377454003)(52604005)(377424004)(13464003)(189002)(86362001)(87936001)(77096002)(20776003)(99286002)(106116001)(76482002)(85306004)(19617315012)(33646002)(15975445006)(95666004)(54356999)(50986999)(76176999)(105586002)(85852003)(122556002)(74316001)(40100003)(31966008)(92566001)(19625215002)(108616004)(230783001)(120916001)(101416001)(19580395003)(66066001)(21056001)(19580405001)(80022003)(46102003)(4396001)(97736003)(76576001)(64706001)(19609705001)(15202345003)(2656002)(99396003)(107046002)(106356001)(2501002)(16236675004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ey6otracCC4f-o7JlNTYNoDfRDM Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.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, 16 Oct 2014 18:16:57 -0000 --_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for reviewing the document! One drawback of the approach outlined in draft-ietf-bfd-seamless-use-case i= s that it requires the egress LSR to implement new BFD procedures. By contr= ast, LSP Self-ping does not impose any new requirements upon the egress. Ron From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: draft-ietf-bfd-seamless-use-case@tools.ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 <= /p>

Thanks for reviewing the = document!

 <= /p>

One drawback of the appro= ach outlined in draft-ietf-bfd-seamless-use-case is that it requires the eg= ress LSR to implement new BFD procedures. By contrast, LSP Self-ping does not impose any new requirements upon the egress.=

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; Ron

 <= /p>

 <= /p>

From: Gregor= y Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: draft-ietf-bfd-seamless-use-case@tools.ietf.org; rtg-bfd@ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

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

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_95c3da24b7e7438a9044c037b0920781CO1PR05MB442namprd05pro_-- From nobody Thu Oct 16 11:44:33 2014 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 0A9D21A86ED; Thu, 16 Oct 2014 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 Q8uLRwENJTPi; Thu, 16 Oct 2014 11:44:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077B71A6FED; Thu, 16 Oct 2014 11:44:12 -0700 (PDT) Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 18:44:10 +0000 Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.91]) with mapi id 15.00.1049.012; Thu, 16 Oct 2014 18:44:10 +0000 From: Ronald Bonica To: "Nobo Akiya (nobo)" , Gregory Mirsky , "mpls@ietf.org" Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/Zqa6/0YZx/ZEumjY2jQZiJtJwzEBjA Date: Thu, 16 Oct 2014 18:44:10 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(41574002)(189002)(377454003)(52604005)(51704005)(377424004)(13464003)(85852003)(40100003)(20776003)(85306004)(93886004)(15202345003)(106356001)(50986999)(76576001)(86362001)(31966008)(19617315012)(2656002)(19625215002)(76176999)(19580395003)(15975445006)(16236675004)(19580405001)(19609705001)(2501002)(97736003)(33646002)(107046002)(99396003)(77096002)(64706001)(101416001)(120916001)(66066001)(21056001)(230783001)(80022003)(108616004)(46102003)(54356999)(4396001)(87936001)(92566001)(106116001)(105586002)(76482002)(122556002)(99286002)(74316001)(95666004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RHaBp1nQVenh7gqSmpmRT3MKWOs Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.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, 16 Oct 2014 18:44:18 -0000 --_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Thanks for reviewing this document. Comments inline..... Ron Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. [RPB] LSP Self-ping is an extremely lightweight mechanism that verifies the avail= ability of the data plane. It does not verify that the LSP follows the ERO,= or even that it terminates on the correct egress LSR. In the rare cases when the LSP has been programmed incorrectly, it is appro= priate to invoke heavier-weight diagnostic tools. When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. [RPB] True. LSP Self-ping is not applicable for LDP independent mode. Ron Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-= case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nobo,

 <= /p>

Thanks for reviewing this= document. Comments inline…..

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Ron

 <= /p>

 <= /p>

 = ;

Destinatio= n address having a valid IP address (i.e. address of ingress LSR) means tha= t this probe will come back to the ingress LSR when:

- transit = LSR false pops and forwards (due to incorrect label programming)=

- transit = LSR false forwards elsewhere and happens to terminates at some other networ= k nodes via different LSP (due to incorrect label programming)

 = ;

Certain pa= ckets over such LSP (ex: VPN) will likely get dropped even though proposed = probe reports success, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.=

 

[RPB= ]

LSP = Self-ping is an extremely lightweight mechanism that verifies the availabil= ity of the data plane. It does not verify that the LSP follows the ERO, or even that it terminates on the correct egress LSR.<= /span>

 

In t= he rare cases when the LSP has been programmed incorrectly, it is appropria= te to invoke heavier-weight diagnostic tools.

 = ;

 = ;

When appli= ed to the LDP independent mode, proposed probe will have the same “fa= lse positive” issue with “end-to-end LSP not ready” case = as well.

 

 

[RPB= ]

True= . LSP Self-ping is not applicable for LDP independent mode.

 

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            Ron

 = ;

 = ;

Thanks!

 = ;

-Nobo=

 = ;

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.or= g] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing t= his work to discussion. I agree that lightweight mechanism to verify LSP av= ailability is useful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would li= ke to reference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 =

Greatly appreciate your = feedback.

 =

    =     Regards,

    =             Greg

 =

-----Original Message---= --
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 =

Folks,=

 =

Please review and commen= t

 =

    =             &nb= sp;        Ron

 =

 =

> -----Original Messa= ge-----

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, Octo= ber 14, 2014 3:28 PM

> To: Ronald Bonica; = EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Ravee= ndra Torvi; Dante Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella= ; EXT - mark.wygant@verizon.com=

> Subject: New Versio= n Notification for

> draft-bonica-mpls-s= elf-ping-00.txt

>

>

> A new version of I-= D, draft-bonica-mpls-self-ping-00.txt

> has been successful= ly submitted by Ron Bonica and posted to the IETF

> repository.

>

> Name:  &n= bsp;      draft-bonica-mpls-self-ping

> Revision: &nbs= p;   00

> Title:  &= nbsp;           &nbs= p; LSP Self-Ping

> Document date: = ;       2014-10-14

> Group:  &= nbsp;           &nbs= p; Individual Submission

> Pages:  &= nbsp;           &nbs= p; 7

> 00.txt

>

>

> Abstract:

>    T= his memo describes LSP Self-ping.  An ingress LSR can use LSP Self-

>    p= ing to verify that an LSP is ready to carry traffic.

>

>

>

>

> Please note that it= may take a couple of minutes from the time of

> submission until th= e htmlized version and diff are available at tools.ietf.org.

>

> The IETF Secretaria= t

 =

________________________= _______________________

mpls mailing list

 =

--_000_a381d2c8be994cfab4e8741304e60496CO1PR05MB442namprd05pro_-- From nobody Thu Oct 16 15:43:33 2014 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 E765B1A87A4 for ; Thu, 16 Oct 2014 15:43:29 -0700 (PDT) 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 4UVu9CISH4WN for ; Thu, 16 Oct 2014 15:43:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611631A6EE6 for ; Thu, 16 Oct 2014 15:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=770; q=dns/txt; s=iport; t=1413499408; x=1414709008; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qo0Z4WdO65/MEMRLHwgLWO0dLtYrLVYeakq3awn0/Es=; b=N4WrJ584svwdDJ70TGZ5D3aywxuRiwwYfjwN1SxbxxaM25K8Jx4M/vAU brNY/C1woVJNcGvMUb8sNpBwsYFSXTRdvKyNOGHp9RXaW1FfSm3UarWSO 7vLSBmkiac4kt3S9R0OzsabQyrjnkr0V8iY9xFZCIrJX4surMq06Cx6i+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJlIQFStJA2D/2dsb2JhbABbgmsjgS/TbQKBFRYBcguEBAEEOlEBKhQxESYBBBMIiCIDEQGnRZ18DYZCAQEBBwEBAQEejhmBUhEBH4NlgR4Fj2OCHIlHkVeGVoN3bIEPOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,735,1406592000"; d="scan'208";a="364011022" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2014 22:43:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9GMhRTi029692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 16 Oct 2014 22:43:27 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 17:43:27 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Design Team for defining BFD Yang Models Thread-Topic: Design Team for defining BFD Yang Models Thread-Index: Ac/pkmoEX9Bwvz5jQiuPa/jIMBaxbQ== Date: Thu, 16 Oct 2014 22:43:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/I-UNCFni-JE5CBzaH8_zVCR2rsA 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, 16 Oct 2014 22:43:30 -0000 Dear BFD WG, Since IETF90 in Toronto, many have expressed interest in BFD Yang Models. I'd like to use this email to notify the BFD WG that Jeff and I have connec= ted interested members to form a design group for defining BFD Yang Models. Members are: Editors: Vero Zheng (vero.zheng@huawei.com) Reshad Rahman (rrahman@cisco.com) Co-authors: Mahesh Jethanandani (mjethanandani@gmail.com) Santosh P K (santoshpk@juniper.net) Contributors: Sam Aldrin (aldrin.ietf@gmail.com) Tissa Senevirathne (tsenevir@cisco.com) The members have been virtually meeting up bi-weekly and working through th= e designs at the moment. We expect a -00 document to be published by them o= nce they reach a certain point. Thanks! -Nobo & Jeff From nobody Thu Oct 16 15:56:57 2014 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 022731A8AFA; Thu, 16 Oct 2014 15:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 ZoDRnkMQjRQ9; Thu, 16 Oct 2014 15:56:51 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3101A8AFD; Thu, 16 Oct 2014 15:56:50 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 90ADF28C601B; Thu, 16 Oct 2014 18:56:49 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Design Team for defining BFD Yang Models From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 16 Oct 2014 18:56:40 -0400 Message-Id: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/SC1PnZ22v2fw04EToLzr3eKc1hQ Cc: rtg-yang-coord@ietf.org, "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, 16 Oct 2014 22:56:53 -0000 --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 Cross-posting to rtg-yang-coord list. --Tom On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) = wrote: > Dear BFD WG, >=20 > Since IETF90 in Toronto, many have expressed interest in BFD Yang = Models. >=20 > I'd like to use this email to notify the BFD WG that Jeff and I have = connected interested members to form a design group for defining BFD = Yang Models. >=20 > Members are: >=20 > Editors: > Vero Zheng (vero.zheng@huawei.com) > Reshad Rahman (rrahman@cisco.com) >=20 > Co-authors: > Mahesh Jethanandani (mjethanandani@gmail.com) > Santosh P K (santoshpk@juniper.net) >=20 > Contributors: > Sam Aldrin (aldrin.ietf@gmail.com) > Tissa Senevirathne (tsenevir@cisco.com) >=20 > The members have been virtually meeting up bi-weekly and working = through the designs at the moment. We expect a -00 document to be = published by them once they reach a certain point. >=20 > Thanks! >=20 > -Nobo & Jeff >=20 >=20 --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQE0oAAoJEPcO+I7eiUJZgiIQALiwdRG3lSDsVr71RWAb+W0c NAlSuJzbFe0kv+CGFtftT3yliynnIZaoODoDjD7h79iSr+s2EWT/QYwNtOgXWZXn fM4Z11s7v0gPLT0CAB4mG/vDV2Stb4+Lhwo1NmeXnqs/7tkaP/7GVj5+jWJShP7c XZa37PYfaMAyLMeSBKP3duoQtI5N9l53gbV0XCsyBqI5nT7hnkuOf7fSo0P3hqMs 1JnIcZfSU4r3VXASNChi1cnsAzECgYRslsCugzBfVNUFqLBUzOMwaxlpiurIDfCN klNM7nixG3vX0zok7NR3XcbpC/e6F1Cj34cmbBxO6EG/47MkY8eN0YPcMMYnZfo/ 1p5yc1/om+KmqaJ/XNhcO5zDJLlOMQBRqnrDCxGU8RITZVe6qIC9Sni+8xeJ77u8 kybEqhinDnJqKVULGAGdijrU9toFWIplXKhEoFwF5ZeLanB0qJNCjLHnklvWMxdu W0MSoF1JgmCIkX0svNmZi00hyQlDCJitktobewFJ94qyS+hku+z2gXfWWoSxhx6Q SrtJuUnN1CjYI4BaHTUH6NC2GclKf+aGbD0RHdeCMLT56Gqbh2oZvWmytNiUWXVW Rc0FpWhN0ei55QPdao985jCLTE1aSHcSBKt9yy3YfRWVF+1Bj8Gb+RMUysD/Ivxp HMpb+ODX6g4SEwnGJN8r =/Rwd -----END PGP SIGNATURE----- --Apple-Mail=_A36573FB-DA6F-4E58-B691-B502A4EA54FE-- From nobody Thu Oct 16 18:22:42 2014 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 A78F61A1BB5; Thu, 16 Oct 2014 18:22:39 -0700 (PDT) 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 cwS8vJvnu2I5; Thu, 16 Oct 2014 18:22:35 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69901A1BA4; Thu, 16 Oct 2014 18:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36798; q=dns/txt; s=iport; t=1413508954; x=1414718554; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UuyHF9kCyaHvMRiNw0Q940Y59FmqF0AbdBUUIJtsPyU=; b=WC93kCdhZ6hDhPA/EwkgehsQppNvnVacRyu2KDC6OT53cM8KT4+MOGLX hP5Wdc25YmQZOPzGSl+w3jF35Wqr0LcJjuG5Mr9b4+LiFgLq7YZfwzFfh AnpKk8IBS0mgaarNBUb/GyQzArtCUZbXZ8QDcAFDUBmAtltoHJ017VAQ/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABduQFStJA2D/2dsb2JhbABbgkgjI1NcyjKBZAEJh00CgRIWAX2EAgEBAQMBAQEBKkEJAgUHBAIBCA4DBAEBCxYBBgcnCxQIAQgCBAENBQgBiCEDCQgBDMtTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF44ZggMtBAYBBgODJIEeBY9jghyERohCPIMKjSiDfoIGGIFZbIEIJByBAgEBAQ X-IronPort-AV: E=Sophos; i="5.04,735,1406592000"; d="scan'208,217"; a="87735706" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 17 Oct 2014 01:22:33 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9H1MXMl031672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 01:22:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 20:22:32 -0500 From: "Nobo Akiya (nobo)" To: Ronald Bonica , Gregory Mirsky , "mpls@ietf.org" Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Topic: [mpls] FW: New Version Notification for draft-bonica-mpls-self-ping-00.txt Thread-Index: AQHP5/S+Gv5QLnD300KRpmKZHU+QY5wwGbuwgANMhQCAAA+ykA== Date: Fri, 17 Oct 2014 01:22:32 +0000 Message-ID: References: <20141014192743.28871.13693.idtracker@ietfa.amsl.com> <2be7dcabbf19453b8b9d4fbe69dcc65d@CO1PR05MB442.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B85CBD7@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: [10.86.253.22] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OLWRJPetCe82bpf-98Orw04n16Q Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-seamless-use-case@tools.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, 17 Oct 2014 01:22:39 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Thanks for your response. Please see in-line with [NOBO]. From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: Thursday, October 16, 2014 2:44 PM To: Nobo Akiya (nobo); Gregory Mirsky; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Nobo, Thanks for reviewing this document. Comments inline..... Ron Destination address having a valid IP address (i.e. address of ingress LSR)= means that this probe will come back to the ingress LSR when: - transit LSR false pops and forwards (due to incorrect label programming) - transit LSR false forwards elsewhere and happens to terminates at some ot= her network nodes via different LSP (due to incorrect label programming) Certain packets over such LSP (ex: VPN) will likely get dropped even though= proposed probe reports success, because destination IP address being the i= ngress LSR can cause the packet to come back to the ingress LSR. [RPB] LSP Self-ping is an extremely lightweight mechanism that verifies the avail= ability of the data plane. It does not verify that the LSP follows the ERO,= or even that it terminates on the correct egress LSR. [NOBO] "verifies the availability of the data plane" depends on which data = plane you are referring to. The proposed verifies the IP data plane from so= me nodes to self, which some node could the egress LSR. The proposed does n= ot verify the availability of the LSP (i.e. MPLS data plane), which I belie= ve is the verification that the proposal is trying to provide. In Section 3: [snip] By contrast, LSP Self-ping does not consume any control plane resources at the egress LSR, and relies solely on the data plane of the egress LSR, making it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs. [snip] It might be beneficial to clarify above text that the proposed attempts to = check the LSP readiness but has limitations as described previously. In the rare cases when the LSP has been programmed incorrectly, it is appro= priate to invoke heavier-weight diagnostic tools. [NOBO] It is also those "rare cases" that causes some of the biggest issue= s in networks. If something similar (i.e. light weight and quick) can be do= ne truly in-band to catch even those "rare cases", then I think that will b= e a good mechanism to [also] pursue. Thanks! -Nobo When applied to the LDP independent mode, proposed probe will have the same= "false positive" issue with "end-to-end LSP not ready" case as well. [RPB] True. LSP Self-ping is not applicable for LDP independent mode. Ron Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Tuesday, October 14, 2014 5:20 PM To: Ronald Bonica; mpls@ietf.org Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-= case@tools.ietf.org Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mpls-self= -ping-00.txt Hi Ron, thank you for bringing this work to discussion. I agree that lightweight me= chanism to verify LSP availability is useful and valuable tool in OAM toolb= ox. Possible use of LSP Ping already been discussed in the document and thu= s I would like to reference another mechanism that authors of the Seamless = Bidirectional Forwarding Detection (BFD) Use Case document believe addresses the prob= lem stated in the Self-ping draft. Perhaps you can review and share your co= mments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding= Path Validation in particular. Greatly appreciate your feedback. Regards, Greg -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Tuesday, October 14, 2014 12:36 PM To: mpls@ietf.org Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt Folks, Please review and comment Ron > -----Original Message----- > From: internet-drafts@ietf.org [mailto:i= nternet-drafts@ietf.org] > Sent: Tuesday, October 14, 2014 3:28 PM > To: Ronald Bonica; EXT - luis.tomotaki@verizon.com; Raveendra Torvi; > Michael Conn; Raveendra Torvi; Dante Pacella; Ronald Bonica; EXT - > mark.wygant@verizon.com; EXT - luis.tomot= aki@verizon.com; Michael > Conn; Dante Pacella; EXT - mark.wygant@verizon.com > Subject: New Version Notification for > draft-bonica-mpls-self-ping-00.txt > > > A new version of I-D, draft-bonica-mpls-self-ping-00.txt > has been successfully submitted by Ron Bonica and posted to the IETF > repository. > > Name: draft-bonica-mpls-self-ping > Revision: 00 > Title: LSP Self-Ping > Document date: 2014-10-14 > Group: Individual Submission > Pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-bonica-mpls-sel= f-ping- > 00.txt > Status: https://datatracker.ietf.org/doc/draft-bonica-mpls-self-p= ing/ > Htmlized: http://tools.ietf.org/html/draft-bonica-mpls-self-ping-00 > > > Abstract: > This memo describes LSP Self-ping. An ingress LSR can use LSP Self- > ping to verify that an LSP is ready to carry traffic. > > > > > 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.iet= f.org. > > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

Thanks for your response. Please see in-line with [NOBO]= .

 <= /p>

From: Ronald Bonica [mailto:rbonica@juniper.net]
Sent: Thursday, October 16, 2014 2:44 PM
To: Nobo Akiya (nobo); Gregory Mirsky; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.or= g
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Nobo,

 = ;

Thanks for= reviewing this document. Comments inline…..

 = ;

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Ron

 = ;

 = ;

 <= /p>

Destination address havin= g a valid IP address (i.e. address of ingress LSR) means that this probe wi= ll come back to the ingress LSR when:

- transit LSR false pops = and forwards (due to incorrect label programming)

- transit LSR false forwa= rds elsewhere and happens to terminates at some other network nodes via dif= ferent LSP (due to incorrect label programming)

 <= /p>

Certain packets over such= LSP (ex: VPN) will likely get dropped even though proposed probe reports s= uccess, because destination IP address being the ingress LSR can cause the packet to come back to the ingress LSR.

 

[RPB]

LSP Self-ping is an= extremely lightweight mechanism that verifies the availability of the data= plane. It does not verify that the LSP follows the ERO, or even that it terminates on the correct egress LSR.

 

[NOBO] “verifies the availability of the data plan= e” depends on which data plane you are referring to. The proposed ver= ifies the IP data plane from some nodes to self, which some node could the egress LSR. The proposed does not verify the availability of the LSP (= i.e. MPLS data plane), which I believe is the verification that the proposa= l is trying to provide.

 

In Section 3:

 

[snip]

   By contrast, LSP Self-ping does not consume a= ny control plane

   resources at the egress LSR, and relies solel= y on the data plane of

   the egress LSR, making it more suitable as a = tool for checking LSP

   readiness when dealing with a large number of= LSPs.

[snip]

 

It might be beneficial to clarify above text that the pr= oposed attempts to check the LSP readiness but has limitations as described= previously.

 

In the rare cases w= hen the LSP has been programmed incorrectly, it is appropriate to invoke he= avier-weight diagnostic tools.

 <= /p>

[NOBO]  It is also those “rare cases” t= hat causes some of the biggest issues in networks. If something similar (i.= e. light weight and quick) can be done truly in-band to catch even those “rare cases”, then I think that will be a good mechanism to [a= lso] pursue.

 

Thanks!

 

-Nobo

 <= /p>

When applied to the LDP i= ndependent mode, proposed probe will have the same “false positive= 221; issue with “end-to-end LSP not ready” case as well.

 

 

[RPB]

True. LSP Self-ping= is not applicable for LDP independent mode.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Ron=

 <= /p>

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Rtg-bfd [= mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Tuesday, October 14, 2014 5:20 PM
To: Ronald Bonica; mpls@ietf.org
Cc: rtg-bfd@ietf.org; draft-ietf-bfd-seamless-use-case@tools.ietf.org
Subject: RE: [mpls] FW: New Version Notification for draft-bonica-mp= ls-self-ping-00.txt

 

Hi Ron,

thank you for bringing this work to dis= cussion. I agree that lightweight mechanism to verify LSP availability is u= seful and valuable tool in OAM toolbox. Possible use of LSP Ping already been discussed in the document and thus I would like to r= eference another mechanism that authors of the Seamless Bidirectional Forwarding Detection (BFD) Use Case document be= lieve addresses the problem stated in the Self-ping draft. Perhaps you can = review and share your comments on S-BFD Use Case document and Section 3.1 Unidirectional Forwarding Path Val= idation in particular.

 

Greatly appreciate your feedback.<= /o:p>

 

      &nb= sp; Regards,

      &nb= sp;         Greg<= /p>

 

-----Original Message-----
From: mpls [mailto:mpls-bounces@ie= tf.org] On Behalf Of Ronald Bonica
Sent: Tuesday, October 14, 2014 12:36 PM
To: mpls@ietf.org
Subject: [mpls] FW: New Version Notification for draft-bonica-mpls-self-pin= g-00.txt

 

Folks,

 

Please review and comment

 

      &nb= sp;            =       Ron

 

 

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

> From: internet-drafts@ietf.org [<= a href=3D"mailto:internet-drafts@ietf.org">mailto:internet-drafts@ietf.org<= /a>]

> Sent: Tuesday, October 14, 2014 3:= 28 PM

> To: Ronald Bonica; EXT - luis.tomotaki@verizon.com;= Raveendra Torvi;

> Michael Conn; Raveendra Torvi; Dan= te Pacella; Ronald Bonica; EXT -

> Conn; Dante Pacella; EXT - mark.wygant@verizon.com=

> Subject: New Version Notification = for

> draft-bonica-mpls-self-ping-00.txt=

>

>

> A new version of I-D, draft-bonica= -mpls-self-ping-00.txt

> has been successfully submitted by= Ron Bonica and posted to the IETF

> repository.

>

> Name:     = ;    draft-bonica-mpls-self-ping

> Revision:     = 00

> Title:    &nbs= p;           LSP Self-Pin= g

> Document date:   &n= bsp;    2014-10-14

> Group:    &nbs= p;           Individual S= ubmission

> Pages:    &nbs= p;           7=

> 00.txt

>

>

> Abstract:

>    This memo descri= bes LSP Self-ping.  An ingress LSR can use LSP Self-=

>    ping to verify t= hat an LSP is ready to carry traffic.

>

>

>

>

> Please note that it may take a cou= ple of minutes from the time of

> submission until the htmlized vers= ion and diff are available at tools.ietf.org.

>

> The IETF Secretariat

 

_______________________________________= ________

mpls mailing list

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F4895B5xmbalnx01ciscoc_-- From nobody Fri Oct 17 05:33:58 2014 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 9AE7A1A9107; Fri, 17 Oct 2014 01:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 ecw306xNAbPG; Fri, 17 Oct 2014 01:09:22 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862971A9103; Fri, 17 Oct 2014 01:09:22 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rd18so263183iec.8 for ; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=afxhb0Q22/6RwxFDLIe+y0Pqfj9TsBVc5jggNFes6+0=; b=mRR6wa21tkZWE5Bwy6M6Gf5UiunYHOFYgwbXzKxPhTQpUH0VPTodMVD2b9VU7vHq1Q ov3qmNedSTj12tMkoZM6GGsCzbi3j+9t6dbxKmCkg0wvgqRtP/hmUUxbfXa77ZWf5EPt mpvi0XElCE8WdQescjJwm+N0QOS8LwC71Gr+Em0zGRJ0zglFfZFHUJJ2VTEJVZ2PZJGc c/G9rLsjPKn1ZIN0Vm2j9ZplgrsOI/71dr/FCjngvBFvGc0BWFbzN/OG/ZqGX9PrUzJp 1gr1sbWbnip9VOskbl7S34XxjqEiwjdqKKgTFjJB2nXprlI2OgR5qsufBr7sI+X7Sk6M dLBA== MIME-Version: 1.0 X-Received: by 10.42.20.195 with SMTP id h3mr851242icb.59.1413533361858; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.107.156.208 with HTTP; Fri, 17 Oct 2014 01:09:21 -0700 (PDT) In-Reply-To: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> Date: Fri, 17 Oct 2014 10:09:21 +0200 X-Google-Sender-Auth: weiNNL_fwdCqw9HA7xFx0jV6pvk Message-ID: Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models From: Robert Raszuk To: "Thomas D. Nadeau" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xnkaxCeEAct8JdMvxSeck9eoF9s X-Mailman-Approved-At: Fri, 17 Oct 2014 05:33:57 -0700 Cc: rtg-yang-coord@ietf.org, "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, 17 Oct 2014 08:09:24 -0000 Hi Tom, I assume this work will be under the general OAM YANG model correct ? http://tools.ietf.org/html/draft-tissa-netmod-oam-01 Thx, R. On Fri, Oct 17, 2014 at 12:56 AM, Thomas D. Nadeau wrote: > > Cross-posting to rtg-yang-coord list. > > --Tom > > > On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) wrote: > >> Dear BFD WG, >> >> Since IETF90 in Toronto, many have expressed interest in BFD Yang Models. >> >> I'd like to use this email to notify the BFD WG that Jeff and I have connected interested members to form a design group for defining BFD Yang Models. >> >> Members are: >> >> Editors: >> Vero Zheng (vero.zheng@huawei.com) >> Reshad Rahman (rrahman@cisco.com) >> >> Co-authors: >> Mahesh Jethanandani (mjethanandani@gmail.com) >> Santosh P K (santoshpk@juniper.net) >> >> Contributors: >> Sam Aldrin (aldrin.ietf@gmail.com) >> Tissa Senevirathne (tsenevir@cisco.com) >> >> The members have been virtually meeting up bi-weekly and working through the designs at the moment. We expect a -00 document to be published by them once they reach a certain point. >> >> Thanks! >> >> -Nobo & Jeff >> >> > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > From nobody Fri Oct 17 05:48:07 2014 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 769E31ACD48; Fri, 17 Oct 2014 05:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 wanssGdMnbNb; Fri, 17 Oct 2014 05:48:02 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A8AE21ACD4F; Fri, 17 Oct 2014 05:48:02 -0700 (PDT) Received: from [192.168.1.123] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 3385E28C6E72; Fri, 17 Oct 2014 08:48:02 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models From: "Thomas D. Nadeau" In-Reply-To: Date: Fri, 17 Oct 2014 08:47:50 -0400 Message-Id: References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VVYbDRB7LjnXht8PH2SV9kEVjTM Cc: rtg-yang-coord@ietf.org, "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, 17 Oct 2014 12:48:04 -0000 --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That depends on how this relates to real implementation. People = need to sit down and iterate on this, as well as implement these models = to ensure they actually work. --Tom > Hi Tom, >=20 > I assume this work will be under the general OAM YANG model correct ? >=20 > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 >=20 > Thx, > R. >=20 > On Fri, Oct 17, 2014 at 12:56 AM, Thomas D. Nadeau > wrote: >>=20 >> Cross-posting to rtg-yang-coord list. >>=20 >> --Tom >>=20 >>=20 >> On Oct 16, 2014:6:43 PM, at 6:43 PM, Nobo Akiya (nobo) = wrote: >>=20 >>> Dear BFD WG, >>>=20 >>> Since IETF90 in Toronto, many have expressed interest in BFD Yang = Models. >>>=20 >>> I'd like to use this email to notify the BFD WG that Jeff and I have = connected interested members to form a design group for defining BFD = Yang Models. >>>=20 >>> Members are: >>>=20 >>> Editors: >>> Vero Zheng (vero.zheng@huawei.com) >>> Reshad Rahman (rrahman@cisco.com) >>>=20 >>> Co-authors: >>> Mahesh Jethanandani (mjethanandani@gmail.com) >>> Santosh P K (santoshpk@juniper.net) >>>=20 >>> Contributors: >>> Sam Aldrin (aldrin.ietf@gmail.com) >>> Tissa Senevirathne (tsenevir@cisco.com) >>>=20 >>> The members have been virtually meeting up bi-weekly and working = through the designs at the moment. We expect a -00 document to be = published by them once they reach a certain point. >>>=20 >>> Thanks! >>>=20 >>> -Nobo & Jeff >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Rtg-yang-coord mailing list >> Rtg-yang-coord@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >=20 --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUQQ/2AAoJEPcO+I7eiUJZPEsP/1gflZ+pOSmD3IAkh8IvyK6B U6/w9NcUxZ69Bgpj6qhEz9tIGE/b0gkvhbj7PfTYrkyWiRxf6rBtzr30ipi8qRba 3duVz+FeBA7b+usD8EkKgFrFODyrEMD7b6Q2ex2poov0m7mszvUERfrkNA+s2xZb XnnaRZS0WaRQRHNikCi6hqdHiauz/M8LzmhP3zF+cvTkWgDpkkvgvgFdwQWZ28ld OUh8ZrpoByDXT8/YGeZYFLnVogAg/ju7zUh9POJftslDLfL18MzWsUchHpNgU/46 ICr3oPOz6Qx3WH5sj6oUKEYFY0DhhAyDVMGUNkOEWjTIaLM/3TWKaw5Vs4SOpm1w PFX0s3De8vTgoWQvw1XBeQVHYbCzSBmGhJI2dkFnaa4pIw7asNeBVc4R2EcomD3/ GN+PQhYkVJ/1/ME+nZGwGiYAURK1szaOS7FkQRQV9IFfA9SZ2MTfzo2DILyYedT1 eWKFg7V5prNcadGSulAoKa+immtKF8rGQQbaz3c+5LS5MpG2xYMIE3mketc7QIM+ zxJ2GUHMIvfu7KK5PIW9yEkZT0MwJiL2lpRoXp9cpaBB4zGbZ33eqDFhBTMvXAzR Er3FojwTXXvB8DBbuvrCt/qqp/D7pYsPhHvI5L9q9dKfaPZDFpD2FCDW1QtodOs1 b7RXuH4f1O4ZR4Aa8bY2 =ZsYR -----END PGP SIGNATURE----- --Apple-Mail=_C241697B-777F-4CA9-B057-3C52118505F3-- From nobody Sat Oct 18 06:33:57 2014 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 86C911A87A8 for ; Sat, 18 Oct 2014 06:33:54 -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, 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 Mx_YD52Rx20g for ; Sat, 18 Oct 2014 06:33:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAC91A87C3 for ; Sat, 18 Oct 2014 06:33:50 -0700 (PDT) Received: from DM2PR05MB766.namprd05.prod.outlook.com (10.141.179.21) by DM2PR05MB768.namprd05.prod.outlook.com (10.141.179.27) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Sat, 18 Oct 2014 13:33:49 +0000 Received: from DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) by DM2PR05MB766.namprd05.prod.outlook.com ([10.141.179.21]) with mapi id 15.00.1044.008; Sat, 18 Oct 2014 13:33:49 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" , Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHg Date: Sat, 18 Oct 2014 13:33:48 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.16] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB768; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(43784003)(57704003)(189002)(199003)(13464003)(51914003)(479174003)(24454002)(377454003)(377424004)(41574002)(53754006)(21056001)(120916001)(85306004)(80022003)(64706001)(99396003)(95666004)(230783001)(101416001)(93886004)(40100003)(108616004)(106116001)(20776003)(76482002)(107046002)(4396001)(19580395003)(105586002)(76576001)(31966008)(54356999)(19580405001)(50986999)(76176999)(87936001)(33646002)(106356001)(107886001)(15202345003)(46102003)(92566001)(66066001)(74316001)(85852003)(97736003)(15975445006)(86362001)(2656002)(122556002)(99286002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB768; H:DM2PR05MB766.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/rn7jy2mBKm2X4Yjf9-ZaPytF2u0 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: Sat, 18 Oct 2014 13:33:54 -0000 Hello Nobo, Thanks again for your comments on this. Please see my comments.=20 > (a) unicast DOWN notification from leaves. > (b) multicast Poll of leaves. > (c) unicast Poll of leaves. > If we want to keep the in-band mechanism and remove out-of-band mechanism= , then preserve (a) and (b) but remove (c). And that would be my preference= . > Mingui, for your "TRILL Resilient Distribution Trees", do you see the nee= d for all [a-c] or just subsets? Does (a) alone not enough? Want to know if there are any application which= wants to track tail proactively? If so we can keep both (a) and (b).=20 > Demux procedures is one, UDP port is the other one (i.e. it is not specif= ied in this document). Yes, UDP port is not specified in the document. We can add this info in bas= e document itself? Every on ok with this? Any suggestions? =20 Thanks Santosh P K =20 -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Wednesday, October 15, 2014 4:04 AM To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org; Min= gui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt [With Chair Hat Off] Hi Santosh, Thank you for leading this effort! Hopefully others can provide their comments to help close of last remaining= points for the BFD multipoint document. Please see my comments in-line. > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Tuesday, October 14, 2014 7:21 AM > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-=20 > bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > Sorry for delay. I am trying to elaborate what I meant by "active tail= ". > Please also comment on other two items that I have listed below which=20 > were raised by Prasad and Nobo in earlier discussions. >=20 > Active tail: > ------------ > As per discussion with implementers it looks like we don't see any use=20 > case scenario for head tracking tail. Currently there are multiple=20 > options given in draft for head to track tail. > 1. Unreliable Head Notification as per section 6.2 > When tail detect timer expires it sends DOWN BFD packet to head on=20 > reverse unicast path. > 2. Semi-reliable Head Notification and Tail Solicitation as per=20 > section > 6.3 > A multipoint POLL with a combination of reverse unicast path FINAL=20 > will help head to know if tail has lost communication with head. > 3. Reliable Head Notification as per section 6.4 > A combination of multipoint POLL and unicast POLL will be used by=20 > head to detect tail going down. Tail will make use of reverse unicast=20 > path to send FINAL packet to head. One important characteristics is that: (1) allows the head to be notified of _in-band_ failure by leaves. (2) allows the head to poll leaves through _in-band_ packets. (3) allows the head to poll leaves through _out-of-band_ unicast packets. Going back to what Wim wrote (thanks for the comment Wim!): [snip] > In certain environment the tracking of the tails is happening by other me= ans. > Example is Multicast VPN using MP-BGP. [snip] True, in the scenario described, (3) adds very minimal value beyond running= multi-hop BFD session between BGP peers. On the other hand (1) and (2) are in-band, and can detect failures that oth= er sessions like multi-hop BFD sessions cannot. It does look useful with te= chnologies such as P2MP-TE where: - leaves are constant - has path-protection mechanism =20 >=20 > We have below options: > 1. Go with simple "No Head Notification" as per section 6.1 in base=20 > draft and move rest of the sections to Appendix or move to separate draft= ? > In this case On MultipointHead bfd.ReportTailDown > will be set to 0 and we might not even need MultipointClient as=20 > we are not going to receive any packets from tail. bfd.SilentTail will=20 > be set to 1 on MultipointTail > 2. Another option is to just keep "Unreliable Head Notification" as=20 > per section 6.2 and move/remove rest of mechanism through which=20 > Multipoint head can detect tail going down. > Meaning we need to move/remove Multicast POLL and unicast POLL=20 > from MultipointHead. Another way to look at this is that: (a) unicast DOWN notification from leaves. (b) multicast Poll of leaves. (c) unicast Poll of leaves. If we want to keep the in-band mechanism and remove out-of-band mechanism, = then preserve (a) and (b) but remove (c). And that would be my preference. Mingui, for your "TRILL Resilient Distribution Trees", do you see the need = for all [a-c] or just subsets? > 3. Jeff suggested that we move these sections to new draft with=20 > experimental status. > 4. Any other options? Please suggest. >=20 >=20 > Along with this I am also seeking comments on below two points. > Demux: > --------- > This was brought up by Prasad in context of EVPN BFD draft that as per=20 > section 4.7 of this draft say >=20 > " The minimum amount of a priori information required both on the=20 > head > and tails is the binding to the multipoint path over which BFD is=20 > running." >=20 > Above text is brief and draft is AF agnostic. Do we need to make text=20 > of Sec > 4.7 and related sections more explicit? For example in case of EVPN=20 > tail nodes may use the P2MP label as the session demux key. Do we want=20 > to elaborate demux in base draft or it should be outside the scope of=20 > this document? Demux procedures is one, UDP port is the other one (i.e. it is not specifie= d in this document). We need to either: - Add details in this document, or - Consider this document as multipoint base document, and roll out micro-do= cuments describing demux/UDP-port details for various data planes. Either will work, but the details are required somewhere to interoperate. >=20 > Security consideration: > ---------------------------- > As per Nobo's comment on this draft long back. We need to add some=20 > suggestion in security consideration. Mainly because MultipointTail=20 > session can be created dynamically. >=20 > Snippet from Nobo's mail. >=20 > "MultipointTail sessions are dynamically created. If I had a way of=20 > getting around GTSM & Authentication (or lack of) and was aware of a=20 > source address that will pass the "check", then I could DoS this=20 > system with range of My Discriminator values to leaves, which will=20 > cause many instances of MultipointTail sessions to get created. Draft=20 > does say [create or discard] choice is outside the scope (in 4.16.2).=20 > But given the dynamic nature of session creation, it would be=20 > beneficial to highlight this point and provide suggestions in the "Securi= ty Consideration"." >=20 > Any suggestion on this? >=20 > Jeff and Nobo have already raised some concerns here. We might have to=20 > see how PIM is doing it today. Right it would be a good idea how other multipoint/multicast protocols have= addressed this. Thanks! -Nobo >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Friday, October 10, 2014 8:18 PM > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Santosh, >=20 > It will helpful to clarify exactly what you mean by "active tail". >=20 > - Do you intend to keep tail reporting of the failure=20 > (bfd.ReportTailDown=3D1)? > - Is it just unicast poll from head that is being questioned for removal? >=20 > Knowing exactly what aspect is being questioned for removal may=20 > provide a better base for good discussions. >=20 > Thanks! >=20 > -Nobo >=20 > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net] > > Sent: Thursday, October 09, 2014 10:39 PM > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg-=20 > > bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Thanks Hendreickx for your reply. > > > > -----Original Message----- > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-=20 > > lucent.com] > > Sent: Friday, October 10, 2014 12:29 AM > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > In certain environment the tracking of the tails is happening by=20 > > other > means. > > Example is Multicast VPN using MP-BGP. > > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: > > > > >[With Chair Hat On] > > > > > >Dear WG, > > > > > >The topic of keeping or removing the active tail from=20 > > >draft-ietf-bfd-multipoint is one of the last couple of topics that=20 > > >we, as a WG, need to resolve for this document. > > > > > >Whether or not we keep or remove the active tail, leaves will be=20 > > >able to detect the failure of the multicast tree, which allows=20 > > >protections such as live-live. > > > > > >What is essentially different: > > > > > >Keeping the active tail - Allows ingress/root to keep track of leaves. > > > > > >Removing the active tail - Ingress/root will not be able to keep=20 > > >track of leaves. > > > > > >If there's any requirements for the ingress/root to trigger some=20 > > >protections, then active tail becomes a requirement. If there is no=20 > > >such requirements, then the active tail is an unnecessary portion=20 > > >of this document. > > > > > >It'll be beneficial to hear your thoughts/comments to help gauge=20 > > >where we are on this matter as a WG. > > > > > >Comments/thoughts? > > > > > >Thanks! > > > > > >-Nobo > > > > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >> Santosh P K > > >> Sent: Monday, October 06, 2014 9:27 AM > > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Sorry for typo in my precious mail "active tale" it is "active tail= ". > > >> > > >> Thanks > > >> Santosh P K > > >> > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >> Santosh P K > > >> Sent: Monday, October 06, 2014 6:22 PM > > >> To: Jeffrey Haas; rtg-bfd@ietf.org > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Hello All, > > >> I am seeking comments on active tale section of this document.=20 > > >>I spoke to few implementers and found that no one really finds=20 > > >>use case for active tale. > > >> Does anyone on this forum feel that we might need active tale? If=20 > > >>there are no uses cases then we can move active tale section to=20 > > >>appendix? We would like to make all the changes before IETF 91=20 > > >>and push this for RFC. Any suggestions? > > >> > > >> Thanks > > >> Santosh P K > > >> > > >> -----Original Message----- > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > >>Jeffrey Haas > > >> Sent: Tuesday, August 19, 2014 7:38 PM > > >> To: rtg-bfd@ietf.org > > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > >> > > >> Note that this consists mostly of a re-publish with Santosh as=20 > > >>the new editor. > > >> (And moving from .nroff to .xml.) > > >> > > >> In the next few weeks, Santosh will be working with known=20 > > >>implementors to edit the document to match implementation. =20 > > >>Ideally these edits will be complete prior to the next IETF=20 > > >>session in Honolulu. This will put us a bit past our original=20 > > >>milestone for publication, but still much better on track than=20 > > >>many of our previous documents. > > >> > > >> -- Jeff > > >> > > >> > > >> > > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700,=20 > > >>internet-drafts@ietf.org > > >>wrote: > > >> > > > >> > A New Internet-Draft is available from the on-line=20 > > >> > Internet-Drafts > > >> directories. > > >> > This draft is a work item of the Bidirectional Forwarding=20 > > >> > Detection > > >> Working Group of the IETF. > > >> > > > >> > Title : BFD for Multipoint Networks > > >> > Authors : Dave Katz > > >> > Dave Ward > > >> > Santosh Pallagatti > > >> > Filename : draft-ietf-bfd-multipoint-04.txt > > >> > Pages : 27 > > >> > Date : 2014-08-12 > > >> > > > >> > Abstract: > > >> > This document describes extensions to the Bidirectional Forward= ing > > >> > Detection (BFD) protocol for its use in multipoint and multicas= t > > >> > networks. Comments on this draft should be directed to rtg- > > >> > bfd@ietf.org. > > >> > > > >> > > > >> > > > >> > The IETF datatracker status page for this draft is: > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > >> > > > >> > There's also a htmlized version available at: > > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > >> > > > >> > A diff from the previous version is available at: > > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > >> > > > >> > > > >> > Please note that it may take a couple of minutes from the time=20 > > >> > of submission until the htmlized version and diff are available=20 > > >> > at > > >> tools.ietf.org. > > >> > > > >> > Internet-Drafts are also available by anonymous FTP at: > > >> > ftp://ftp.ietf.org/internet-drafts/ > > > From nobody Tue Oct 21 14:39:00 2014 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 C03AF1A87A3 for ; Tue, 21 Oct 2014 14:38:57 -0700 (PDT) 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 WCiUc6XCcqdm for ; Tue, 21 Oct 2014 14:38:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8991C1A8791 for ; Tue, 21 Oct 2014 14:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15600; q=dns/txt; s=iport; t=1413927530; x=1415137130; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=M+1bvpCXPtkVcLgK5J2vYxCXHNGx8wfrXOKrT3Qh6o0=; b=Xl8CanFqTIq2ny6chEyyBAuBNrDDZ8VkdBYy27qR95eUjx2IhIwwU8K3 fyLX9oPcZOuj+lyfy1qH5zgC9smux3TrlTizZFV9iDT0LF4e2ZFhnFmXH jHwJdUf05iUGYnRE3YdA/Nlwzi2Z+dcGNtCry4MmE7wHk/6+JhMTTMvhe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAJDRRlStJV2Z/2dsb2JhbABcgmsjU1MFBMx8h00CgRYWAX2EAgEBAQMBOkQHBAIBCBEEAQEBChQJBzIUCQgCBAESCAGILggBBwXGZwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQBgEBHjgGgyeBHgWGLYk4ghyERohDPIMMjSyEAYIGGIFabIEGBQEDFyKBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,764,1406592000"; d="scan'208";a="365307570" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2014 21:38:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9LLcmnu012192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 21:38:48 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:38:47 -0500 From: "Nobo Akiya (nobo)" To: Santosh P K , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" , Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hUPZOBPokD+keyL4hHqvmqqpvYS1kAgEtadQCAAAnegIAEgS9ggAA+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmA= Date: Tue, 21 Oct 2014 21:38:47 +0000 Message-ID: References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iUVbX78Ts8a9FPcrWc_3q-dCd-Y 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, 21 Oct 2014 21:38:57 -0000 [With Chair Hat On] WG, I'd imagine many are busy ... being the last week before the cut-off and al= l ... But it'll be very helpful if you can chime in to help Santosh to take BFD m= ultipoint further. [With Chair Hat Off] Hi Santosh, > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Saturday, October 18, 2014 9:34 AM > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg- > bfd@ietf.org; Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello Nobo, > Thanks again for your comments on this. Please see my comments. >=20 > > (a) unicast DOWN notification from leaves. > > (b) multicast Poll of leaves. > > (c) unicast Poll of leaves. > > If we want to keep the in-band mechanism and remove out-of-band > mechanism, then preserve (a) and (b) but remove (c). And that would be my > preference. > > Mingui, for your "TRILL Resilient Distribution Trees", do you see the n= eed > for all [a-c] or just subsets? >=20 > Does (a) alone not enough?=20 Personally I think there's a value in leaving the option for the head to do= in-band polling of leaves. In other words, if down notification from a lea= f to the head, then there is no way for the head to find out that leaf is n= o longer receiving. > Want to know if there are any application > which wants to track tail proactively? If so we can keep both (a) and (b)= . More comments from the WG will be very helpful. So far ... - Mingui brought up "TRILL Resilient Distribution Trees". - I brought up P2MP-TE Path Protection, which I think both (a) and (b) will= be useful. >=20 > > Demux procedures is one, UDP port is the other one (i.e. it is not spec= ified > in this document). >=20 > Yes, UDP port is not specified in the document. We can add this info in b= ase > document itself? Every on ok with this? Any suggestions? Demux procedures and UDP ports should go into the same document. So it's either: (a) put everything in draft-ietf-bfd-multipoint. Or (b) spin off draft-ietf-bfd-multipoint- document per data plane. Thanks! -Nobo >=20 >=20 > Thanks > Santosh P K >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 15, 2014 4:04 AM > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org; > Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > [With Chair Hat Off] >=20 > Hi Santosh, >=20 > Thank you for leading this effort! >=20 > Hopefully others can provide their comments to help close of last remaini= ng > points for the BFD multipoint document. >=20 > Please see my comments in-line. >=20 > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net] > > Sent: Tuesday, October 14, 2014 7:21 AM > > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg- > > bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Hello All, > > Sorry for delay. I am trying to elaborate what I meant by "active ta= il". > > Please also comment on other two items that I have listed below which > > were raised by Prasad and Nobo in earlier discussions. > > > > Active tail: > > ------------ > > As per discussion with implementers it looks like we don't see any use > > case scenario for head tracking tail. Currently there are multiple > > options given in draft for head to track tail. > > 1. Unreliable Head Notification as per section 6.2 > > When tail detect timer expires it sends DOWN BFD packet to > head on > > reverse unicast path. > > 2. Semi-reliable Head Notification and Tail Solicitation as per > > section > > 6.3 > > A multipoint POLL with a combination of reverse unicast > path FINAL > > will help head to know if tail has lost communication with head. > > 3. Reliable Head Notification as per section 6.4 > > A combination of multipoint POLL and unicast POLL will be > used by > > head to detect tail going down. Tail will make use of reverse unicast > > path to send FINAL packet to head. >=20 > One important characteristics is that: > (1) allows the head to be notified of _in-band_ failure by leaves. > (2) allows the head to poll leaves through _in-band_ packets. > (3) allows the head to poll leaves through _out-of-band_ unicast packets. >=20 > Going back to what Wim wrote (thanks for the comment Wim!): > [snip] > > In certain environment the tracking of the tails is happening by other > means. > > Example is Multicast VPN using MP-BGP. > [snip] >=20 > True, in the scenario described, (3) adds very minimal value beyond runni= ng > multi-hop BFD session between BGP peers. >=20 > On the other hand (1) and (2) are in-band, and can detect failures that o= ther > sessions like multi-hop BFD sessions cannot. It does look useful with > technologies such as P2MP-TE where: >=20 > - leaves are constant > - has path-protection mechanism >=20 > > > > We have below options: > > 1. Go with simple "No Head Notification" as per section 6.1 in base > > draft and move rest of the sections to Appendix or move to separate > draft? > > In this case On MultipointHead bfd.ReportTailDown > > will be set to 0 and we might not even need MultipointClient as > > we are not going to receive any packets from tail. bfd.SilentTail will > > be set to 1 on MultipointTail > > 2. Another option is to just keep "Unreliable Head Notification" as > > per section 6.2 and move/remove rest of mechanism through which > > Multipoint head can detect tail going down. > > Meaning we need to move/remove Multicast POLL and unicast > POLL > > from MultipointHead. >=20 > Another way to look at this is that: >=20 > (a) unicast DOWN notification from leaves. > (b) multicast Poll of leaves. > (c) unicast Poll of leaves. >=20 > If we want to keep the in-band mechanism and remove out-of-band > mechanism, then preserve (a) and (b) but remove (c). And that would be my > preference. >=20 > Mingui, for your "TRILL Resilient Distribution Trees", do you see the nee= d > for all [a-c] or just subsets? >=20 > > 3. Jeff suggested that we move these sections to new draft with > > experimental status. > > 4. Any other options? Please suggest. > > > > > > Along with this I am also seeking comments on below two points. > > Demux: > > --------- > > This was brought up by Prasad in context of EVPN BFD draft that as per > > section 4.7 of this draft say > > > > " The minimum amount of a priori information required both on the > > head > > and tails is the binding to the multipoint path over which BFD is > > running." > > > > Above text is brief and draft is AF agnostic. Do we need to make text > > of Sec > > 4.7 and related sections more explicit? For example in case of EVPN > > tail nodes may use the P2MP label as the session demux key. Do we want > > to elaborate demux in base draft or it should be outside the scope of > > this document? >=20 > Demux procedures is one, UDP port is the other one (i.e. it is not specif= ied > in this document). >=20 > We need to either: > - Add details in this document, or > - Consider this document as multipoint base document, and roll out micro- > documents describing demux/UDP-port details for various data planes. >=20 > Either will work, but the details are required somewhere to interoperate. >=20 > > > > Security consideration: > > ---------------------------- > > As per Nobo's comment on this draft long back. We need to add some > > suggestion in security consideration. Mainly because MultipointTail > > session can be created dynamically. > > > > Snippet from Nobo's mail. > > > > "MultipointTail sessions are dynamically created. If I had a way of > > getting around GTSM & Authentication (or lack of) and was aware of a > > source address that will pass the "check", then I could DoS this > > system with range of My Discriminator values to leaves, which will > > cause many instances of MultipointTail sessions to get created. Draft > > does say [create or discard] choice is outside the scope (in 4.16.2). > > But given the dynamic nature of session creation, it would be > > beneficial to highlight this point and provide suggestions in the "Secu= rity > Consideration"." > > > > Any suggestion on this? > > > > Jeff and Nobo have already raised some concerns here. We might have to > > see how PIM is doing it today. >=20 > Right it would be a good idea how other multipoint/multicast protocols > have addressed this. >=20 > Thanks! >=20 > -Nobo >=20 > > > > > > Thanks > > Santosh P K > > > > > > > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Friday, October 10, 2014 8:18 PM > > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Santosh, > > > > It will helpful to clarify exactly what you mean by "active tail". > > > > - Do you intend to keep tail reporting of the failure > > (bfd.ReportTailDown=3D1)? > > - Is it just unicast poll from head that is being questioned for remova= l? > > > > Knowing exactly what aspect is being questioned for removal may > > provide a better base for good discussions. > > > > Thanks! > > > > -Nobo > > > > > -----Original Message----- > > > From: Santosh P K [mailto:santoshpk@juniper.net] > > > Sent: Thursday, October 09, 2014 10:39 PM > > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg- > > > bfd@ietf.org > > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > Thanks Hendreickx for your reply. > > > > > > -----Original Message----- > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > > > lucent.com] > > > Sent: Friday, October 10, 2014 12:29 AM > > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > In certain environment the tracking of the tails is happening by > > > other > > means. > > > Example is Multicast VPN using MP-BGP. > > > > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: > > > > > > >[With Chair Hat On] > > > > > > > >Dear WG, > > > > > > > >The topic of keeping or removing the active tail from > > > >draft-ietf-bfd-multipoint is one of the last couple of topics that > > > >we, as a WG, need to resolve for this document. > > > > > > > >Whether or not we keep or remove the active tail, leaves will be > > > >able to detect the failure of the multicast tree, which allows > > > >protections such as live-live. > > > > > > > >What is essentially different: > > > > > > > >Keeping the active tail - Allows ingress/root to keep track of leave= s. > > > > > > > >Removing the active tail - Ingress/root will not be able to keep > > > >track of leaves. > > > > > > > >If there's any requirements for the ingress/root to trigger some > > > >protections, then active tail becomes a requirement. If there is no > > > >such requirements, then the active tail is an unnecessary portion > > > >of this document. > > > > > > > >It'll be beneficial to hear your thoughts/comments to help gauge > > > >where we are on this matter as a WG. > > > > > > > >Comments/thoughts? > > > > > > > >Thanks! > > > > > > > >-Nobo > > > > > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >> Santosh P K > > > >> Sent: Monday, October 06, 2014 9:27 AM > > > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Sorry for typo in my precious mail "active tale" it is "active ta= il". > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >> Santosh P K > > > >> Sent: Monday, October 06, 2014 6:22 PM > > > >> To: Jeffrey Haas; rtg-bfd@ietf.org > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Hello All, > > > >> I am seeking comments on active tale section of this document. > > > >>I spoke to few implementers and found that no one really finds > > > >>use case for active tale. > > > >> Does anyone on this forum feel that we might need active tale? If > > > >>there are no uses cases then we can move active tale section to > > > >>appendix? We would like to make all the changes before IETF 91 > > > >>and push this for RFC. Any suggestions? > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > > >>Jeffrey Haas > > > >> Sent: Tuesday, August 19, 2014 7:38 PM > > > >> To: rtg-bfd@ietf.org > > > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Note that this consists mostly of a re-publish with Santosh as > > > >>the new editor. > > > >> (And moving from .nroff to .xml.) > > > >> > > > >> In the next few weeks, Santosh will be working with known > > > >>implementors to edit the document to match implementation. > > > >>Ideally these edits will be complete prior to the next IETF > > > >>session in Honolulu. This will put us a bit past our original > > > >>milestone for publication, but still much better on track than > > > >>many of our previous documents. > > > >> > > > >> -- Jeff > > > >> > > > >> > > > >> > > > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700, > > > >>internet-drafts@ietf.org > > > >>wrote: > > > >> > > > > >> > A New Internet-Draft is available from the on-line > > > >> > Internet-Drafts > > > >> directories. > > > >> > This draft is a work item of the Bidirectional Forwarding > > > >> > Detection > > > >> Working Group of the IETF. > > > >> > > > > >> > Title : BFD for Multipoint Networks > > > >> > Authors : Dave Katz > > > >> > Dave Ward > > > >> > Santosh Pallagatti > > > >> > Filename : draft-ietf-bfd-multipoint-04.txt > > > >> > Pages : 27 > > > >> > Date : 2014-08-12 > > > >> > > > > >> > Abstract: > > > >> > This document describes extensions to the Bidirectional > Forwarding > > > >> > Detection (BFD) protocol for its use in multipoint and multic= ast > > > >> > networks. Comments on this draft should be directed to rtg- > > > >> > bfd@ietf.org. > > > >> > > > > >> > > > > >> > > > > >> > The IETF datatracker status page for this draft is: > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > >> > > > > >> > There's also a htmlized version available at: > > > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > > >> > > > > >> > A diff from the previous version is available at: > > > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > >> > > > > >> > > > > >> > Please note that it may take a couple of minutes from the time > > > >> > of submission until the htmlized version and diff are available > > > >> > at > > > >> tools.ietf.org. > > > >> > > > > >> > Internet-Drafts are also available by anonymous FTP at: > > > >> > ftp://ftp.ietf.org/internet-drafts/ > > > > From nobody Tue Oct 21 14:48:26 2014 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 232211A87AD for ; Tue, 21 Oct 2014 14:48:25 -0700 (PDT) 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 hje2eDO19EQP for ; Tue, 21 Oct 2014 14:48:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74671A6FD1 for ; Tue, 21 Oct 2014 14:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1285; q=dns/txt; s=iport; t=1413928104; x=1415137704; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EzvdpUYuEHsxL01mWle2T+8C9zFPaja6AUwQqF21CXk=; b=Td48A2Kd/iCYQ7/Xz0pwJuY21Q6k2D5GGHmB4PotRmlRCQvQ8qVzXRTr 4dCWY2cJHKZ5g21Qt8Ro6f3WZdAh2LKuCqi5lYblvSqB/8TEhnziILrxT oG9f0nt80kZW/sNz/So+AJjnCoOVDoyqioAFE8QW+6LxRyzBXWWoKd4S0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAF3URlStJV2U/2dsb2JhbABcgmsjU1MFBMx+h0sCgRYWAXILhAQBBDo9FAEqFEIgBgEEGwGINgEHBaI2pCgBAQEBBgEBAQEBARyQJoNlgR4Fj2WCHIRGiH+UOYN4bAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.04,764,1406592000"; d="scan'208";a="365232592" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 21 Oct 2014 21:48:24 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9LLmNkP020847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Oct 2014 21:48:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 16:48:22 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Index: Ac/td9CpsR8YPbouQ+azq8UBG9W92A== Date: Tue, 21 Oct 2014 21:48:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6JFvfDy4Sed21cCwUdUBWsmZNVs 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, 21 Oct 2014 21:48:25 -0000 Dear BFD WG, The last of the S-BFD documents, and likely the most controversial one, has= been updated and published. In summary, let's reserve S-BFD discriminator zero(0) as the alert discrimi= nator. We'd appreciate comments. Thanks! -Nobo, ducking for cover [snip] A new version of I-D, draft-akiya-bfd-seamless-alert-discrim-03.txt has been successfully submitted by Nobo Akiya and posted to the IETF reposi= tory. Name: draft-akiya-bfd-seamless-alert-discrim Revision: 03 Title: Seamless Bidirectional Forwarding Detection (S-BFD) Alert Discrimin= ator Document date: 2014-10-21 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamles= s-alert-discrim-03.txt Status: https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-a= lert-discrim/ Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-alert-d= iscrim-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless= -alert-discrim-03 Abstract: This document defines the Alert Discriminator which operates on the Seamless Bidirectional Forwarding Detection (S-BFD), and Alert Discriminator Diagnostic Codes which operates on the Alert Discriminator. [snip] From nobody Tue Oct 21 19:13:12 2014 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 6518F1A8A3E for ; Tue, 21 Oct 2014 19:13:07 -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, 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 QDDvl-K72M5Q for ; Tue, 21 Oct 2014 19:13:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AC91A89E0 for ; Tue, 21 Oct 2014 19:13:00 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 02:12:57 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 02:12:57 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Henderickx, Wim (Wim)" , Jeffrey Haas , "rtg-bfd@ietf.org" , Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Topic: I-D Action: draft-ietf-bfd-multipoint-04.txt Thread-Index: AQHPu0hR7sGQaOWUeUOP01liBtKTfJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCAAExXoA== Date: Wed, 22 Oct 2014 02:12:57 +0000 Message-ID: <24f653025a5b4f16a74bde29b6669a7f@BLUPR05MB755.namprd05.prod.outlook.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB756; x-forefront-prvs: 037291602B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(479174003)(43784003)(41574002)(13464003)(51914003)(51704005)(189002)(57704003)(24454002)(53754006)(377424004)(21056001)(101416001)(19580395003)(105586002)(106356001)(106116001)(66066001)(87936001)(2656002)(20776003)(85852003)(4396001)(92566001)(107886001)(107046002)(50986999)(19580405001)(64706001)(76176999)(76576001)(54356999)(97736003)(86362001)(80022003)(46102003)(15202345003)(33646002)(99396003)(122556002)(230783001)(108616004)(40100003)(99286002)(31966008)(74316001)(93886004)(76482002)(95666004)(120916001)(15975445006)(85306004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BiPupCAqMjeEJMMJDw3ldxqQ_7w 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, 22 Oct 2014 02:13:07 -0000 Nobo, Thanks for your comments. It is more clear now. I will wait for other to = comment on these points as well.=20 Thanks Santosh P K=20 -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Wednesday, October 22, 2014 3:09 AM To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org; Min= gui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt [With Chair Hat On] WG, I'd imagine many are busy ... being the last week before the cut-off and al= l ... But it'll be very helpful if you can chime in to help Santosh to take BFD m= ultipoint further. [With Chair Hat Off] Hi Santosh, > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Saturday, October 18, 2014 9:34 AM > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-=20 > bfd@ietf.org; Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello Nobo, > Thanks again for your comments on this. Please see my comments. >=20 > > (a) unicast DOWN notification from leaves. > > (b) multicast Poll of leaves. > > (c) unicast Poll of leaves. > > If we want to keep the in-band mechanism and remove out-of-band > mechanism, then preserve (a) and (b) but remove (c). And that would be=20 > my preference. > > Mingui, for your "TRILL Resilient Distribution Trees", do you see=20 > > the need > for all [a-c] or just subsets? >=20 > Does (a) alone not enough?=20 Personally I think there's a value in leaving the option for the head to do= in-band polling of leaves. In other words, if down notification from a lea= f to the head, then there is no way for the head to find out that leaf is n= o longer receiving. > Want to know if there are any application which wants to track tail=20 > proactively? If so we can keep both (a) and (b). More comments from the WG will be very helpful. So far ... - Mingui brought up "TRILL Resilient Distribution Trees". - I brought up P2MP-TE Path Protection, which I think both (a) and (b) will= be useful. >=20 > > Demux procedures is one, UDP port is the other one (i.e. it is not=20 > > specified > in this document). >=20 > Yes, UDP port is not specified in the document. We can add this info=20 > in base document itself? Every on ok with this? Any suggestions? Demux procedures and UDP ports should go into the same document. So it's either: (a) put everything in draft-ietf-bfd-multipoint. Or (b) spin off draft-ietf-bfd-multipoint- document per data plane. Thanks! -Nobo >=20 >=20 > Thanks > Santosh P K >=20 >=20 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 15, 2014 4:04 AM > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas;=20 > rtg-bfd@ietf.org; Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > [With Chair Hat Off] >=20 > Hi Santosh, >=20 > Thank you for leading this effort! >=20 > Hopefully others can provide their comments to help close of last=20 > remaining points for the BFD multipoint document. >=20 > Please see my comments in-line. >=20 > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net] > > Sent: Tuesday, October 14, 2014 7:21 AM > > To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-=20 > > bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Hello All, > > Sorry for delay. I am trying to elaborate what I meant by "active ta= il". > > Please also comment on other two items that I have listed below=20 > > which were raised by Prasad and Nobo in earlier discussions. > > > > Active tail: > > ------------ > > As per discussion with implementers it looks like we don't see any=20 > > use case scenario for head tracking tail. Currently there are=20 > > multiple options given in draft for head to track tail. > > 1. Unreliable Head Notification as per section 6.2 > > When tail detect timer expires it sends DOWN BFD packet to > head on > > reverse unicast path. > > 2. Semi-reliable Head Notification and Tail Solicitation as per=20 > > section > > 6.3 > > A multipoint POLL with a combination of reverse unicast > path FINAL > > will help head to know if tail has lost communication with head. > > 3. Reliable Head Notification as per section 6.4 > > A combination of multipoint POLL and unicast POLL will be > used by > > head to detect tail going down. Tail will make use of reverse=20 > > unicast path to send FINAL packet to head. >=20 > One important characteristics is that: > (1) allows the head to be notified of _in-band_ failure by leaves. > (2) allows the head to poll leaves through _in-band_ packets. > (3) allows the head to poll leaves through _out-of-band_ unicast packets. >=20 > Going back to what Wim wrote (thanks for the comment Wim!): > [snip] > > In certain environment the tracking of the tails is happening by=20 > > other > means. > > Example is Multicast VPN using MP-BGP. > [snip] >=20 > True, in the scenario described, (3) adds very minimal value beyond=20 > running multi-hop BFD session between BGP peers. >=20 > On the other hand (1) and (2) are in-band, and can detect failures=20 > that other sessions like multi-hop BFD sessions cannot. It does look=20 > useful with technologies such as P2MP-TE where: >=20 > - leaves are constant > - has path-protection mechanism >=20 > > > > We have below options: > > 1. Go with simple "No Head Notification" as per section 6.1 in base=20 > > draft and move rest of the sections to Appendix or move to separate > draft? > > In this case On MultipointHead bfd.ReportTailDown > > will be set to 0 and we might not even need MultipointClient=20 > > as we are not going to receive any packets from tail. bfd.SilentTail=20 > > will be set to 1 on MultipointTail > > 2. Another option is to just keep "Unreliable Head Notification" as=20 > > per section 6.2 and move/remove rest of mechanism through which=20 > > Multipoint head can detect tail going down. > > Meaning we need to move/remove Multicast POLL and unicast > POLL > > from MultipointHead. >=20 > Another way to look at this is that: >=20 > (a) unicast DOWN notification from leaves. > (b) multicast Poll of leaves. > (c) unicast Poll of leaves. >=20 > If we want to keep the in-band mechanism and remove out-of-band=20 > mechanism, then preserve (a) and (b) but remove (c). And that would be=20 > my preference. >=20 > Mingui, for your "TRILL Resilient Distribution Trees", do you see the=20 > need for all [a-c] or just subsets? >=20 > > 3. Jeff suggested that we move these sections to new draft with=20 > > experimental status. > > 4. Any other options? Please suggest. > > > > > > Along with this I am also seeking comments on below two points. > > Demux: > > --------- > > This was brought up by Prasad in context of EVPN BFD draft that as=20 > > per section 4.7 of this draft say > > > > " The minimum amount of a priori information required both on the=20 > > head > > and tails is the binding to the multipoint path over which BFD=20 > > is running." > > > > Above text is brief and draft is AF agnostic. Do we need to make=20 > > text of Sec > > 4.7 and related sections more explicit? For example in case of EVPN=20 > > tail nodes may use the P2MP label as the session demux key. Do we=20 > > want to elaborate demux in base draft or it should be outside the=20 > > scope of this document? >=20 > Demux procedures is one, UDP port is the other one (i.e. it is not=20 > specified in this document). >=20 > We need to either: > - Add details in this document, or > - Consider this document as multipoint base document, and roll out=20 > micro- documents describing demux/UDP-port details for various data plane= s. >=20 > Either will work, but the details are required somewhere to interoperate. >=20 > > > > Security consideration: > > ---------------------------- > > As per Nobo's comment on this draft long back. We need to add some=20 > > suggestion in security consideration. Mainly because MultipointTail=20 > > session can be created dynamically. > > > > Snippet from Nobo's mail. > > > > "MultipointTail sessions are dynamically created. If I had a way of=20 > > getting around GTSM & Authentication (or lack of) and was aware of a=20 > > source address that will pass the "check", then I could DoS this=20 > > system with range of My Discriminator values to leaves, which will=20 > > cause many instances of MultipointTail sessions to get created.=20 > > Draft does say [create or discard] choice is outside the scope (in 4.16= .2). > > But given the dynamic nature of session creation, it would be=20 > > beneficial to highlight this point and provide suggestions in the=20 > > "Security > Consideration"." > > > > Any suggestion on this? > > > > Jeff and Nobo have already raised some concerns here. We might have=20 > > to see how PIM is doing it today. >=20 > Right it would be a good idea how other multipoint/multicast protocols=20 > have addressed this. >=20 > Thanks! >=20 > -Nobo >=20 > > > > > > Thanks > > Santosh P K > > > > > > > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Friday, October 10, 2014 8:18 PM > > To: Santosh P K; Henderickx, Wim (Wim); Jeffrey Haas;=20 > > rtg-bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Santosh, > > > > It will helpful to clarify exactly what you mean by "active tail". > > > > - Do you intend to keep tail reporting of the failure=20 > > (bfd.ReportTailDown=3D1)? > > - Is it just unicast poll from head that is being questioned for remova= l? > > > > Knowing exactly what aspect is being questioned for removal may=20 > > provide a better base for good discussions. > > > > Thanks! > > > > -Nobo > > > > > -----Original Message----- > > > From: Santosh P K [mailto:santoshpk@juniper.net] > > > Sent: Thursday, October 09, 2014 10:39 PM > > > To: Henderickx, Wim (Wim); Nobo Akiya (nobo); Jeffrey Haas; rtg-=20 > > > bfd@ietf.org > > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > Thanks Hendreickx for your reply. > > > > > > -----Original Message----- > > > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-=20 > > > lucent.com] > > > Sent: Friday, October 10, 2014 12:29 AM > > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > In certain environment the tracking of the tails is happening by=20 > > > other > > means. > > > Example is Multicast VPN using MP-BGP. > > > > > > On 09/10/14 17:38, "Nobo Akiya (nobo)" wrote: > > > > > > >[With Chair Hat On] > > > > > > > >Dear WG, > > > > > > > >The topic of keeping or removing the active tail from=20 > > > >draft-ietf-bfd-multipoint is one of the last couple of topics=20 > > > >that we, as a WG, need to resolve for this document. > > > > > > > >Whether or not we keep or remove the active tail, leaves will be=20 > > > >able to detect the failure of the multicast tree, which allows=20 > > > >protections such as live-live. > > > > > > > >What is essentially different: > > > > > > > >Keeping the active tail - Allows ingress/root to keep track of leave= s. > > > > > > > >Removing the active tail - Ingress/root will not be able to keep=20 > > > >track of leaves. > > > > > > > >If there's any requirements for the ingress/root to trigger some=20 > > > >protections, then active tail becomes a requirement. If there is=20 > > > >no such requirements, then the active tail is an unnecessary=20 > > > >portion of this document. > > > > > > > >It'll be beneficial to hear your thoughts/comments to help gauge=20 > > > >where we are on this matter as a WG. > > > > > > > >Comments/thoughts? > > > > > > > >Thanks! > > > > > > > >-Nobo > > > > > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > > >> Santosh P K > > > >> Sent: Monday, October 06, 2014 9:27 AM > > > >> To: Santosh P K; Jeffrey Haas; rtg-bfd@ietf.org > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Sorry for typo in my precious mail "active tale" it is "active ta= il". > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > > >> Santosh P K > > > >> Sent: Monday, October 06, 2014 6:22 PM > > > >> To: Jeffrey Haas; rtg-bfd@ietf.org > > > >> Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Hello All, > > > >> I am seeking comments on active tale section of this document. > > > >>I spoke to few implementers and found that no one really finds=20 > > > >>use case for active tale. > > > >> Does anyone on this forum feel that we might need active tale?=20 > > > >>If there are no uses cases then we can move active tale section=20 > > > >>to appendix? We would like to make all the changes before IETF=20 > > > >>91 and push this for RFC. Any suggestions? > > > >> > > > >> Thanks > > > >> Santosh P K > > > >> > > > >> -----Original Message----- > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of=20 > > > >>Jeffrey Haas > > > >> Sent: Tuesday, August 19, 2014 7:38 PM > > > >> To: rtg-bfd@ietf.org > > > >> Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > >> > > > >> Note that this consists mostly of a re-publish with Santosh as=20 > > > >>the new editor. > > > >> (And moving from .nroff to .xml.) > > > >> > > > >> In the next few weeks, Santosh will be working with known=20 > > > >>implementors to edit the document to match implementation. > > > >>Ideally these edits will be complete prior to the next IETF=20 > > > >>session in Honolulu. This will put us a bit past our original=20 > > > >>milestone for publication, but still much better on track than=20 > > > >>many of our previous documents. > > > >> > > > >> -- Jeff > > > >> > > > >> > > > >> > > > >> On Mon, Aug 18, 2014 at 05:55:37PM -0700,=20 > > > >>internet-drafts@ietf.org > > > >>wrote: > > > >> > > > > >> > A New Internet-Draft is available from the on-line=20 > > > >> > Internet-Drafts > > > >> directories. > > > >> > This draft is a work item of the Bidirectional Forwarding=20 > > > >> > Detection > > > >> Working Group of the IETF. > > > >> > > > > >> > Title : BFD for Multipoint Networks > > > >> > Authors : Dave Katz > > > >> > Dave Ward > > > >> > Santosh Pallagatti > > > >> > Filename : draft-ietf-bfd-multipoint-04.txt > > > >> > Pages : 27 > > > >> > Date : 2014-08-12 > > > >> > > > > >> > Abstract: > > > >> > This document describes extensions to the Bidirectional > Forwarding > > > >> > Detection (BFD) protocol for its use in multipoint and multic= ast > > > >> > networks. Comments on this draft should be directed to rtg- > > > >> > bfd@ietf.org. > > > >> > > > > >> > > > > >> > > > > >> > The IETF datatracker status page for this draft is: > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > >> > > > > >> > There's also a htmlized version available at: > > > >> > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > > >> > > > > >> > A diff from the previous version is available at: > > > >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-04 > > > >> > > > > >> > > > > >> > Please note that it may take a couple of minutes from the=20 > > > >> > time of submission until the htmlized version and diff are=20 > > > >> > available at > > > >> tools.ietf.org. > > > >> > > > > >> > Internet-Drafts are also available by anonymous FTP at: > > > >> > ftp://ftp.ietf.org/internet-drafts/ > > > > From nobody Wed Oct 22 08:35:02 2014 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 AB3FE1ACD27 for ; Wed, 22 Oct 2014 08:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 URT0H1mNXzg7 for ; Wed, 22 Oct 2014 08:34:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBD31ACD6B for ; Wed, 22 Oct 2014 08:34:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022153455.21460.81320.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 08:34:55 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lVEWT0JJJ1JQOW5j1ZMoxlRaoss X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:35:00 -0000 URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Wed Oct 22 08:36:25 2014 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 8CF361ACD5C for ; Wed, 22 Oct 2014 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KwLxgZyFv1sn for ; Wed, 22 Oct 2014 08:36:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8737C1ACD65 for ; Wed, 22 Oct 2014 08:36:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022153621.14120.94563.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 08:36:21 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QyEYJyhZRIeuyssAFgPEnKIZ5uk X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:36:23 -0000 Changed milestone "Submit a BFD Yang module to the IESG to be considered as a Proposed Standard", set due date to December 2016 from December 2015. URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Wed Oct 22 08:41:09 2014 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 17AA61ACD5C for ; Wed, 22 Oct 2014 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 cnVLzjn-_V1u for ; Wed, 22 Oct 2014 08:41:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CB81ACD6D for ; Wed, 22 Oct 2014 08:41:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141022154105.24916.94637.idtracker@ietfa.amsl.com> Date: Wed, 22 Oct 2014 08:41:05 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iTuRFS6Yoa6sktviuc0odzRvLTQ X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 15:41:08 -0000 Changed milestone "Submit a BFD Yang module to the IESG to be considered as a Proposed Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/bfd/charter/ From mishra.ashesh@gmail.com Wed Oct 22 10:01:57 2014 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 459631ACE3C for ; Wed, 22 Oct 2014 10:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 DHllHbCv1DgG for ; Wed, 22 Oct 2014 10:01:55 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFCC1ACE4B for ; Wed, 22 Oct 2014 10:01:55 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id n15so3210865lbi.11 for ; Wed, 22 Oct 2014 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=MR/9jZ8aLNLeGGcrNKqQlg5BABGUJu2ZTUMjJhX+EmM=; b=CL/2aBtADsLWAiF5CvNUhemHinHMhifKEJEJTMajluGuF1jsIWivviRzMX/QV0KnZk ciRazxRfORc+1uo4y0alBsjedLsIuyI/Ita5hrkuLH01UcFs99TKROT8eV5+agBncv6a 5zi2HrffOsqSYmr9dmDMr27ANrREQFbxtfMLdl6yD+0oikvUUlyVrrZXt+SfEfa9maUi NBh+/w/heIgP2TTaWA2bie07Tlz5407M/CnLudl1cEJaMVUSu8vfWZ1yOt/nurw5071V 3T6IUSn6UciioW8tdT2bn4YtDj1SHqjdW8/7XcZ4+bW18BVu/uDHrqNU4GH09rSjcPQh ArlA== X-Received: by 10.152.8.12 with SMTP id n12mr42743423laa.51.1413997313373; Wed, 22 Oct 2014 10:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.83.202 with HTTP; Wed, 22 Oct 2014 10:01:33 -0700 (PDT) From: Ashesh Mishra Date: Wed, 22 Oct 2014 10:01:33 -0700 Message-ID: Subject: New version for draft-ashesh-bfd-stability now available To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=001a11c365b693bc13050605e729 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/1-oZ_SKYtVASWeW60Dp4WlqykYA X-Mailman-Approved-At: Wed, 22 Oct 2014 10:21:56 -0700 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, 22 Oct 2014 17:09:05 -0000 --001a11c365b693bc13050605e729 Content-Type: text/plain; charset=UTF-8 Dear BFD WG, The 01 version of the BFD Stability draft is now published and available. https://tools.ietf.org/html/draft-ashesh-bfd-stability-01 Summary of changes from version 00: 1. The draft now only addresses BFD frame loss detection. There has been growing demand from the industry on having such capability and the consensus of the design team for this draft is to use a NULL-Auth TLV with sequence numbers. 2. All references to timestamps are now removed, but the space in the TLV is now set to "Reserved for Future". This will allow flexibility for this idea to grow in the future, while allowing existing and future implementations to be interoperable. As a result, the draft is now tiny and shouldn't take long for the forum to review :) We'd appreciate comments from the WG. BR, Ashesh --001a11c365b693bc13050605e729 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear BFD WG,

The 01 version of the BFD = Stability draft is now published and available.=C2=A0

<= div>h= ttps://tools.ietf.org/html/draft-ashesh-bfd-stability-01

=
Summary of changes from version 00:

1. = The draft now only addresses BFD frame loss detection. There has been growi= ng demand from the industry on having such capability and the consensus of = the design team for this draft is to use a NULL-Auth TLV with sequence numb= ers.=C2=A0

2. All references to timestamps are now= removed, but the space in the TLV is now set to "Reserved for Future&= quot;. This will allow flexibility for this idea to grow in the future, whi= le allowing existing and future implementations to be interoperable.=C2=A0<= /div>

As a result, the draft is now tiny and shouldn'= ;t take long for the forum to review :)

We'd a= ppreciate comments from the WG.=C2=A0

BR,
Ashesh
--001a11c365b693bc13050605e729-- From nobody Wed Oct 22 16:49:51 2014 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 6CC921A8820; Wed, 22 Oct 2014 16:49:47 -0700 (PDT) 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 Rs3emynBjpJl; Wed, 22 Oct 2014 16:49:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 894CC1A87E8; Wed, 22 Oct 2014 16:49:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 28B5FC20E; Wed, 22 Oct 2014 19:49:46 -0400 (EDT) Date: Wed, 22 Oct 2014 19:49:45 -0400 From: Jeffrey Haas To: Robert Raszuk Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models Message-ID: <20141022234945.GF18782@pfrc> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uc8Uw2VAKo6ck6HfQJ8V801HrKY Cc: rtg-yang-coord@ietf.org, "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, 22 Oct 2014 23:49:47 -0000 Robert, On Fri, Oct 17, 2014 at 10:09:21AM +0200, Robert Raszuk wrote: > Hi Tom, > > I assume this work will be under the general OAM YANG model correct ? > > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 I'm interested to see opinions on this topic as well. One interesting input is that a strong motivator for people asking for BFD rather than CFM-like mechanisms is the complete lack of the IEEE management domain model. Many operators seem to strongly dislike it. Seeing how BFD would fit into this draft given the above will be interesting. -- Jeff From nobody Wed Oct 22 21:07:36 2014 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 140951A8892 for ; Wed, 22 Oct 2014 21:07:34 -0700 (PDT) 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 YOWi6EM0qg-X for ; Wed, 22 Oct 2014 21:07:32 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C44EC1A8899 for ; Wed, 22 Oct 2014 21:07:31 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B54782AA0F; Thu, 23 Oct 2014 04:07:24 +0000 (GMT) Date: Wed, 22 Oct 2014 21:08:18 -0700 From: Marc Binderberger To: Ashesh Mishra Message-ID: <20141022210818265344.d1fc1992@sniff.de> In-Reply-To: References: Subject: Re: New version for draft-ashesh-bfd-stability now available MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/k4QNaWzitEzMjecfWMr2C57w_a0 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, 23 Oct 2014 04:07:34 -0000 Hello Ashesh & authors, starting with a nitpick The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Something went wrong with all the "<" and ">" in the xref ;-) What I wonder is this: what happens when the sequence number wraps? With the ever faster BFD intervals we have 2^32 * 3.3msec = 164 days 2^32 * 10msec = 497 days at least I wouldn't rule out such stable networks and routers. Theoretically wrapping back to 0 could - according to the draft - reset the logic even if there is a packet loss, e.g. lets say the packet with sequence 2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrapping back to 1 after reaching 2^32 - 1 ? For the auth TLV you write: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Auth Key ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for Future | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for Future | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Auth Type: The Authentication Type, which in this case is (Null Authentication). Auth Len: The length of the Authentication Section, in bytes. Set to 12. Auth Key ID: The Authentication Key ID in use for this packet. This MUST be set to zero on transmit, and ignored on receipt. Reserved: This byte MUST be set to zero on transmit, and ignored on receipt. RFC5880 has this generic form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Len The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields. Your definition of "Auth Len" does not seem to match RFC5880? Should the value be 16 in your case? And why do you define the "Auth Key ID"? Will there be potential future plans for it? Otherwise you could just extend the "Reserved" field to 16 bit. If you have future plans, I think it would be useful to mention this fact, so implementors are prepared. Best regards, Marc On Wed, 22 Oct 2014 10:01:33 -0700, Ashesh Mishra wrote: > Dear BFD WG, > > The 01 version of the BFD Stability draft is now published and available. > > https://tools.ietf.org/html/draft-ashesh-bfd-stability-01 > > Summary of changes from version 00: > > 1. The draft now only addresses BFD frame loss detection. There has been > growing demand from the industry on having such capability and the > consensus of the design team for this draft is to use a NULL-Auth TLV with > sequence numbers. > > 2. All references to timestamps are now removed, but the space in the TLV > is now set to "Reserved for Future". This will allow flexibility for this > idea to grow in the future, while allowing existing and future > implementations to be interoperable. > > As a result, the draft is now tiny and shouldn't take long for the forum to > review :) > > We'd appreciate comments from the WG. > > BR, > Ashesh From nobody Thu Oct 23 02:18:37 2014 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 66DFF1A896C for ; Thu, 23 Oct 2014 02:18:36 -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, 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 tNlVR8apgGRH for ; Thu, 23 Oct 2014 02:18:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8451A8968 for ; Thu, 23 Oct 2014 02:18:33 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB753.namprd05.prod.outlook.com (10.141.208.140) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 23 Oct 2014 09:18:10 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 09:18:10 +0000 From: Santosh P K To: Marc Binderberger , Ashesh Mishra Subject: RE: New version for draft-ashesh-bfd-stability now available Thread-Topic: New version for draft-ashesh-bfd-stability now available Thread-Index: AQHP7hy0tQq/WcSti0q/rG+8cmDFP5w9EboAgABNWmA= Date: Thu, 23 Oct 2014 09:18:10 +0000 Message-ID: <5b0a2a609835440f87240e089c553e7f@BLUPR05MB755.namprd05.prod.outlook.com> References: <20141022210818265344.d1fc1992@sniff.de> In-Reply-To: <20141022210818265344.d1fc1992@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.16] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB753; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(24454002)(108616004)(33646002)(21056001)(76176999)(76576001)(86362001)(54356999)(92566001)(20776003)(230783001)(50986999)(99286002)(66066001)(64706001)(95666004)(107046002)(106356001)(105586002)(106116001)(76482002)(80022003)(97736003)(120916001)(99396003)(122556002)(87936001)(4396001)(31966008)(15975445006)(2656002)(85852003)(46102003)(19580395003)(74316001)(40100003)(101416001)(85306004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB753; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QCPbRDnnHBbnEZAfOWQhL8odKM8 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, 23 Oct 2014 09:18:36 -0000 Hello Marc, Thanks for your comments. Please see inline comments.=20 >What I wonder is this: what happens when the sequence number wraps? With t= he ever faster BFD intervals we have >2^32 * 3.3msec =3D 164 days >2^32 * 10msec =3D 497 days >at least I wouldn't rule out such stable networks and routers. >Theoretically wrapping back to 0 could - according to the draft - reset th= e logic even if there is a packet loss, e.g. lets say the packet with seque= nce >2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrappin= g back to 1 after reaching 2^32 - 1 ? This is good point. I agree that we should add more details on sequence num= ber wrapping. I see few options to address this.=20 1. Use of two reserve bits (Just like P/F) to indicate/negotiate that seque= nce number has wrapped, so that other end still keeps account of Lost packe= t. Keeping sequence number unsigned integer.=20 2. Lollipop sequence number. This means we need to use signed integer for = sequence number and start with 0 or -1.=20 3. Any other suggestions?=20 > And why do you define the "Auth Key ID"? Will there be potential future = plans for it? Otherwise you could just extend the "Reserved" field to 16 b= it. If you have future plans, I think it would be useful to mention this fa= ct, so implementors are prepared. Auth Key id might not be required as this is NULL auth.=20 Thanks Santosh P K=20 What I wonder is this: what happens when the sequence number wraps? With th= e ever faster BFD intervals we have 2^32 * 3.3msec =3D 164 days 2^32 * 10msec =3D 497 days at least I wouldn't rule out such stable networks and routers. Theoretically wrapping back to 0 could - according to the draft - reset the= logic even if there is a packet loss, e.g. lets say the packet with sequen= ce 2^32 - 1 is missing. Maybe you want a "lollipop" sequence instead, wrapping= back to 1 after reaching 2^32 - 1 ? For the auth TLV you write: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Auth Key ID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for Future | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved for Future | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Auth Type: The Authentication Type, which in this case is (Null Authentication). Auth Len: The length of the Authentication Section, in bytes. Set to 12. Auth Key ID: The Authentication Key ID in use for this packet. This MUST be set to zero on transmit, and ignored on receipt. Reserved: This byte MUST be set to zero on transmit, and ignored on receipt. RFC5880 has this generic form: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth Len The length, in bytes, of the authentication section, including the Auth Type and Auth Len fields. Your definition of "Auth Len" does not seem to match RFC5880? Should the va= lue be 16 in your case? And why do you define the "Auth Key ID"? Will there be potential future pl= ans for it? Otherwise you could just extend the "Reserved" field to 16 bit= . If you have future plans, I think it would be useful to mention this fact= , so implementors are prepared. Best regards, Marc On Wed, 22 Oct 2014 10:01:33 -0700, Ashesh Mishra wrote: > Dear BFD WG, >=20 > The 01 version of the BFD Stability draft is now published and available.= =20 >=20 > https://tools.ietf.org/html/draft-ashesh-bfd-stability-01 >=20 > Summary of changes from version 00: >=20 > 1. The draft now only addresses BFD frame loss detection. There has=20 > been growing demand from the industry on having such capability and=20 > the consensus of the design team for this draft is to use a NULL-Auth=20 > TLV with sequence numbers. >=20 > 2. All references to timestamps are now removed, but the space in the=20 > TLV is now set to "Reserved for Future". This will allow flexibility=20 > for this idea to grow in the future, while allowing existing and=20 > future implementations to be interoperable. >=20 > As a result, the draft is now tiny and shouldn't take long for the=20 > forum to review :) >=20 > We'd appreciate comments from the WG.=20 >=20 > BR, > Ashesh From nobody Thu Oct 23 07:29:41 2014 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 548151AC39D for ; Thu, 23 Oct 2014 07:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HgqWLSDZZrrb for ; Thu, 23 Oct 2014 07:29:36 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id DBB491AC3C0 for ; Thu, 23 Oct 2014 07:29:32 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 4ADE63D0B3; Thu, 23 Oct 2014 16:29:30 +0200 (CEST) Date: Thu, 23 Oct 2014 16:29:30 +0200 (CEST) Message-Id: <20141023.162930.237954217.he@uninett.no> To: santoshpk@juniper.net Subject: Re: New version for draft-ashesh-bfd-stability now available From: Havard Eidnes In-Reply-To: <5b0a2a609835440f87240e089c553e7f@BLUPR05MB755.namprd05.prod.outlook.com> References: <20141022210818265344.d1fc1992@sniff.de> <5b0a2a609835440f87240e089c553e7f@BLUPR05MB755.namprd05.prod.outlook.com> X-Mailer: Mew version 6.5 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/iqvQVVvAiHIZ0xskMNM6j72mDjw Cc: rtg-bfd@ietf.org, mishra.ashesh@gmail.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: Thu, 23 Oct 2014 14:29:38 -0000 >> Theoretically wrapping back to 0 could - according to the >> draft - reset the logic even if there is a packet loss, >> e.g. lets say the packet with sequence 2^32 - 1 is >> missing. Maybe you want a "lollipop" sequence instead, >> wrapping back to 1 after reaching 2^32 - 1 ? > = > This is good point. I agree that we should add more details on > sequence number wrapping. I see few options to address this. > = > 1. Use of two reserve bits (Just like P/F) to > indicate/negotiate that sequence number has wrapped, so > that other end still keeps account of Lost packet. Keeping > sequence number unsigned integer. = > 2. Lollipop sequence number. This means we need to use signed > integer for sequence number and start with 0 or -1. > 3. Any other suggestions? Without having delved into the specifics of this case, may I suggest "Serial number arithmetic" or "Seqeuence Number Arithmetic", ref. RFC 1982? Regards, - H=E5vard From nobody Thu Oct 23 07:57:48 2014 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 CE23E1A9241 for ; Thu, 23 Oct 2014 07:57:44 -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, 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 YMnMbxN1NuxM for ; Thu, 23 Oct 2014 07:57:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:704]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9501A9239 for ; Thu, 23 Oct 2014 07:57:41 -0700 (PDT) Received: from BLUPR05MB755.namprd05.prod.outlook.com (10.141.208.145) by BLUPR05MB756.namprd05.prod.outlook.com (10.141.208.151) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 14:57:18 +0000 Received: from BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) by BLUPR05MB755.namprd05.prod.outlook.com ([10.141.208.145]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 14:57:18 +0000 From: Santosh P K To: Havard Eidnes Subject: RE: New version for draft-ashesh-bfd-stability now available Thread-Topic: New version for draft-ashesh-bfd-stability now available Thread-Index: AQHP7hy0tQq/WcSti0q/rG+8cmDFP5w9EboAgABNWmCAAGA1AIAAB42A Date: Thu, 23 Oct 2014 14:57:18 +0000 Message-ID: References: <20141022210818265344.d1fc1992@sniff.de> <5b0a2a609835440f87240e089c553e7f@BLUPR05MB755.namprd05.prod.outlook.com> <20141023.162930.237954217.he@uninett.no> In-Reply-To: <20141023.162930.237954217.he@uninett.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [116.197.184.16] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB756; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0373D94D15 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(13464003)(40224003)(199003)(377454003)(40100003)(99286002)(33646002)(122556002)(230783001)(108616004)(99396003)(110136001)(76482002)(120916001)(85306004)(93886004)(95666004)(74316001)(4396001)(31966008)(92566001)(107046002)(105586002)(106356001)(106116001)(21056001)(101416001)(19580395003)(66066001)(87936001)(20776003)(2656002)(85852003)(86362001)(46102003)(80022003)(97736003)(76176999)(64706001)(54356999)(76576001)(19580405001)(50986999)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/v0ooT3BZFArW0TCk97pbLrnyb94 Cc: "rtg-bfd@ietf.org" , "mishra.ashesh@gmail.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: Thu, 23 Oct 2014 14:57:45 -0000 Havard, Thanks a lot. We will take a look at RFC 1982. Thanks Santosh P K=20 -----Original Message----- From: Havard Eidnes [mailto:he@uninett.no]=20 Sent: Thursday, October 23, 2014 8:00 PM To: Santosh P K Cc: marc@sniff.de; mishra.ashesh@gmail.com; rtg-bfd@ietf.org Subject: Re: New version for draft-ashesh-bfd-stability now available >> Theoretically wrapping back to 0 could - according to the draft -=20 >> reset the logic even if there is a packet loss, e.g. lets say the=20 >> packet with sequence 2^32 - 1 is missing. Maybe you want a "lollipop"=20 >> sequence instead, wrapping back to 1 after reaching 2^32 - 1 ? >=20 > This is good point. I agree that we should add more details on=20 > sequence number wrapping. I see few options to address this. >=20 > 1. Use of two reserve bits (Just like P/F) to > indicate/negotiate that sequence number has wrapped, so > that other end still keeps account of Lost packet. Keeping > sequence number unsigned integer.=20 > 2. Lollipop sequence number. This means we need to use signed > integer for sequence number and start with 0 or -1. > 3. Any other suggestions? Without having delved into the specifics of this case, may I suggest "Seria= l number arithmetic" or "Seqeuence Number Arithmetic", ref. RFC 1982? Regards, - H=E5vard From nobody Thu Oct 23 11:45:49 2014 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 C1A6C1A90E0; Thu, 23 Oct 2014 11:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UfXOcBDHAbxG; Thu, 23 Oct 2014 11:45:45 -0700 (PDT) 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 42A621A8ACC; Thu, 23 Oct 2014 11:45:45 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-c1-5448f2bbd328 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.FB.25146.BB2F8445; Thu, 23 Oct 2014 14:21:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 14:45:43 -0400 From: Gregory Mirsky To: Jeffrey Haas , Robert Raszuk Subject: RE: [Rtg-yang-coord] Design Team for defining BFD Yang Models Thread-Topic: [Rtg-yang-coord] Design Team for defining BFD Yang Models Thread-Index: Ac/pkmoEX9Bwvz5jQiuPa/jIMBaxbQAI49oAABNNX4ABHEzZgAAfD1Vg Date: Thu, 23 Oct 2014 18:45:43 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B865166@eusaamb103.ericsson.se> References: <277F136F-A86C-4AFE-BC51-4CC27A661AB5@lucidvision.com> <20141022234945.GF18782@pfrc> In-Reply-To: <20141022234945.GF18782@pfrc> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQXf3J48Qg293BC32H3zLajG7I96i aWETs8XnP9sYLX4/v81s8XDyJXYHNo8pvzeyeixZ8pPJY+uTJewel3u3snrs3riAKYA1issm JTUnsyy1SN8ugSvjzL8mtoIzXBXr9vaxNzA+5+hi5OSQEDCR6Om5xQphi0lcuLeerYuRi0NI 4CijxMcF7ewQznJGiQWfJ7KAVLEJGEm82NjDDmKLCLhI/Nq+CyzOLLCNUeLo8zwQW1jATWLO mmlANRxANe4SP5tkIMrdJC5v3M8IYrMIqEqcbd0LNoZXwFfiRNNpZohdbxglFs95ywSS4BTQ krj1ZjobiM0IdN33U2uYIHaJS9x6Mp8J4moBiSV7zjND2KISLx//g/pGUWJf/3R2iHodiQW7 P7FB2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYuQoLU4ty003MtzECIy1 YxJsjjsYF3yyPMQowMGoxMP7QMMjRIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjKxtEX/jdfKL4nq4q/LSLNetrlt7YGokc45h8tw9SvuX13Bs2qxg9vj/ 4uNbtC3OXDibaaLJ73rh7c6OgE+Pdx/gMjXgiFus+O7tmY6y9qwDzTymPw5fLFEXTUi79mCe F8exDtv987OUudWaGxoWGF04e/bf+yd51jMdX1ytvs3C/dn4aH0GlxJLcUaioRZzUXEiADdc QwqWAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/RAf_-1UrGQ4Bg1cPadcHqAW_mL0 Cc: "rtg-yang-coord@ietf.org" , "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, 23 Oct 2014 18:45:47 -0000 Hi Robert, et. al, I've commented on the draft you've referenced http://www.ietf.org/mail-arch= ive/web/netmod/current/msg10528.html. The document been just updated and I'm looking forward to continue discussi= on with authors. Regards, Greg -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Jeffrey Haas Sent: Wednesday, October 22, 2014 4:50 PM To: Robert Raszuk Cc: rtg-yang-coord@ietf.org; Thomas D. Nadeau; Nobo Akiya (nobo); rtg-bfd@i= etf.org Subject: Re: [Rtg-yang-coord] Design Team for defining BFD Yang Models Robert, On Fri, Oct 17, 2014 at 10:09:21AM +0200, Robert Raszuk wrote: > Hi Tom, >=20 > I assume this work will be under the general OAM YANG model correct ? >=20 > http://tools.ietf.org/html/draft-tissa-netmod-oam-01 I'm interested to see opinions on this topic as well. One interesting input is that a strong motivator for people asking for BFD = rather than CFM-like mechanisms is the complete lack of the IEEE management= domain model. Many operators seem to strongly dislike it. Seeing how BFD would fit into this draft given the above will be interestin= g. -- Jeff _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Thu Oct 23 13:01:58 2014 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 2DEA31AD058; Thu, 23 Oct 2014 13:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 HToSl2QLWXxg; Thu, 23 Oct 2014 13:01:41 -0700 (PDT) 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 1903B1AD057; Thu, 23 Oct 2014 13:01:40 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-7a-544906ee6751 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.7A.05330.EE609445; Thu, 23 Oct 2014 15:47:26 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 16:01:39 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Subject: FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP7vuLnXrxVtGdr0an+IEI1vxrJpw+GV8Q Date: Thu, 23 Oct 2014 20:01:38 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> In-Reply-To: <20141023195707.10809.79077.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.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyuXRPiO47Ns8Qg++brS1uLV3JavH5zzZG i+MXfjM6MHssWfKTKYAxissmJTUnsyy1SN8ugSuj6XdBwTvhipdTprM1MK4R7mLk5JAQMJG4 fOIVC4QtJnHh3nq2LkYuDiGBo4wS86/+hXKWM0pc/f2QCaSKTcBI4sXGHnYQW0SgUGLh9AY2 EFtYIFCibd9eZoh4kETju/WMELaRxOU3DaxdjBwcLAKqEgdO1oOEeQV8JbZc+glWLiTgKHGn 9RaYzSngJDFzwncwmxHooO+n1oCtZRYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0rs65/O DrKKWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMHKXFqWW5 6UYGmxiBcXBMgk13B+Oel5aHGAU4GJV4eB9oeIQIsSaWFVfmHmKU5mBREuedVTsvWEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVANjeOvH7a9svS6wfJeueXP/wsNFDYuM/kzfGxSVrBI1m0+1 VNBaoq3mqX1fuvn757sc3nEeOfbbOObu6WNfEzMXqLBVLRGfWhtxfJXUptZv8svDCzSzbHhm ftSqvDKx2mbpc/N9s2cZhl67t2mt5ee1PRxLPu0VK2newbyo5OC6XWb277+aWu14qsRSnJFo qMVcVJwIALnV26ZkAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jNLsvg_YN9zbn2ukeONGFXJ18Qo 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, 23 Oct 2014 20:01:49 -0000 RGVhciBBbGwsDQphIG5ldyBzZWN0aW9uIDMuMyBCb290c3RyYXBwaW5nIEJGRCBzZXNzaW9uIHdp dGggQkZEIFJldmVyc2UgUGF0aCBvdmVyIFNlZ21lbnQgUm91dGVkIHR1bm5lbCBiZWVuIGFkZGVk LiBBdXRob3JzIGFsd2F5cyB3ZWxjb21lIHlvdXIgY29tbWVudHMgYW5kIGdyZWF0bHkgYXBwcmVj aWF0ZSBzdWdnZXN0aW9ucy4gV2UncmUgbG9va2luZyBmb3J3YXJkIHRvIGNvbnRpbnVlIGRpc2N1 c3Npb24gYXQgV0cgbWVldGluZ3MgYXQgSUVURi05MS4NCg0KCVJlZ2FyZHMsDQoJCUdyZWcNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAyMywgMjAxNCAxMjo1NyBQTQ0KVG86IEdyZWdvcnkgTWlyc2t5OyBKZWZmIFRhbnRzdXJh OyBHcmVnb3J5IE1pcnNreTsgSmVmZiBUYW50c3VyYTsgSWx5YSBWYXJsYXNoa2luOyBJbHlhIFZh cmxhc2hraW4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWly c2t5LW1wbHMtYmZkLWRpcmVjdGVkLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEdyZWcgTWlyc2t5IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZA0KUmV2aXNpb246 CTAxDQpUaXRsZToJCUJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgRGly ZWN0ZWQgUmV0dXJuIFBhdGgNCkRvY3VtZW50IGRhdGU6CTIwMTQtMTAtMjMNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTkNClVSTDogICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQt MDEudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMQ0KRGlm ZjogICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pcnNr eS1tcGxzLWJmZC1kaXJlY3RlZC0wMQ0KDQpBYnN0cmFjdDoNCiAgIEJpZGlyZWN0aW9uYWwgRm9y d2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgaXMgZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCiAgIGRp cmVjdGlvbmFsIHBhdGhzLiAgV2hlbiBhIEJGRCBzZXNzaW9uIG1vbml0b3JzIGluIGl0cyBmb3J3 YXJkDQogICBkaXJlY3Rpb24gYW4gZXhwbGljaXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpcyBhIG5l ZWQgdG8gYmUgYWJsZSB0bw0KICAgZGlyZWN0IGZhci1lbmQgQkZEIHBlZXIgdG8gdXNlIHNwZWNp ZmljIHBhdGggYXMgcmV2ZXJzZSBkaXJlY3Rpb24gb2YNCiAgIHRoZSBCRkQgc2Vzc2lvbi4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Fri Oct 24 07:29:56 2014 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 840311A0070 for ; Fri, 24 Oct 2014 07:29:54 -0700 (PDT) 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 ig3b3J2c47Hu for ; Fri, 24 Oct 2014 07:29:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD101A0006 for ; Fri, 24 Oct 2014 07:29:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4676BC2A0; Fri, 24 Oct 2014 10:29:53 -0400 (EDT) Date: Fri, 24 Oct 2014 10:29:53 -0400 From: Jeffrey Haas To: Ashesh Mishra Subject: Re: New version for draft-ashesh-bfd-stability now available Message-ID: <20141024142953.GG30433@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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BpXxXr7cKYL2lO8j9Q5loiDr15s 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, 24 Oct 2014 14:29:54 -0000 Ashesh, Thanks for the update. On Wed, Oct 22, 2014 at 10:01:33AM -0700, Ashesh Mishra wrote: > Dear BFD WG, > > The 01 version of the BFD Stability draft is now published and available. > > https://tools.ietf.org/html/draft-ashesh-bfd-stability-01 > > Summary of changes from version 00: > > 1. The draft now only addresses BFD frame loss detection. There has been > growing demand from the industry on having such capability and the > consensus of the design team for this draft is to use a NULL-Auth TLV with > sequence numbers. > > 2. All references to timestamps are now removed, but the space in the TLV > is now set to "Reserved for Future". This will allow flexibility for this > idea to grow in the future, while allowing existing and future > implementations to be interoperable. > > As a result, the draft is now tiny and shouldn't take long for the forum to > review :) A question I have for the working group is the management considerations for this mechanism. The mechanism is appropriate for determining if there's observable loss of BFD packets, but not recommendations as to what information should be gathered for such loss. Would the WG benefit from a management framework for this mechanism? These days that probably means a yang module, but this is also potentially amenable to an extension of the BFD MIB. Secondary note: This mechanism theoretically could work on any meticulous authentication scheme. The major considerations against that are: - The reserved space kept against further statistics. - The overhead of meticulous authentication when actual cryptographic checks are performed. (There was supposed to be a proposal for making those checks more reasonable coming soon. :-) -- Jeff From nobody Fri Oct 24 09:21:12 2014 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 AF5601A1B56 for ; Fri, 24 Oct 2014 09:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KOb90Fs5WjdW for ; Fri, 24 Oct 2014 09:21:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 169571A1B87 for ; Fri, 24 Oct 2014 09:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: rtg-bfd@ietf.org Subject: Milestones changed for bfd WG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024162102.29216.96597.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 09:21:02 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2felTjJKOrkytEmxjee91Y9yAbI X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:21:09 -0000 Changed milestone "Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard", set due date to March 2015 from June 2014. URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Fri Oct 24 09:31:17 2014 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 B02F61A1B91 for ; Fri, 24 Oct 2014 09:31:15 -0700 (PDT) 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 RYlQfIn5yKzD for ; Fri, 24 Oct 2014 09:31:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E75981A1B98 for ; Fri, 24 Oct 2014 09:31:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 73013C2A0; Fri, 24 Oct 2014 12:31:13 -0400 (EDT) Date: Fri, 24 Oct 2014 12:31:13 -0400 From: Jeffrey Haas To: "Nobo Akiya (nobo)" Subject: Re: Call for adoption for draft-akiya-bfd-seamless-ip Message-ID: <20141024163113.GT30433@pfrc> References: <20140903015109.GK7736@pfrc> <20140913142317.GA10965@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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0LWk2EqVmsE1afN9lXgYwpQkLUg 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, 24 Oct 2014 16:31:15 -0000 Nobo and other S-BFD contributors: On Sun, Sep 14, 2014 at 01:57:02PM +0000, Nobo Akiya (nobo) wrote: > Hi Jeff and WG, > > Thank you for allowing the document to become a WG document. The document has been published as draft-ietf-bfd-seamless-ip. > > URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-seamless-ip-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ip/ > Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-00 > > Jeff, authors feel that this is a good trigger to initiate port allocation of the S-BFD ports via Expert Review process. Section 8 of draft-ietf-bfd-seamless-ip-00 has all necessary values. Can you help initiating this process? A request has been forwarded to our area director to re-start the early allocation process for the S-BFD port. -- Jeff From nobody Fri Oct 24 17:10:34 2014 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 74FCE1A1BE3 for ; Fri, 24 Oct 2014 17:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1773ATbR6-_Y for ; Fri, 24 Oct 2014 17:10:24 -0700 (PDT) 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 63ED11A1B65 for ; Fri, 24 Oct 2014 17:10:22 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-e0-544a92a89e2f Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.F8.05330.8A29A445; Fri, 24 Oct 2014 19:55:52 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 24 Oct 2014 20:10:21 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Index: Ac/td9CpsR8YPbouQ+azq8UBG9W92ACaiTmA Date: Sat, 25 Oct 2014 00:10:20 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B866592@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.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B866592eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXSPt+6KSV4hBv/vW1jM7oi3+PxnG6MD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHk9jGWgmXuFZcWfmBsYJxu28XIySEhYCJx qfU0E4QtJnHh3nq2LkYuDiGBo4wSL/52s0M4yxkltuw6yAxSxSZgJPFiYw9QgoNDRCBQ4vc5 TpCwsECkxMaNN6DCURKXX4ZBmEYS6z6ygVSwCKhKXPmyAmwVr4CvxOfNf8DiQgI+EpMPPQIb zgkUf7W1ByzOCHTO91NrwOqZBcQlbj2ZD3WmgMSSPeeZIWxRiZeP/7FC2EoSk5aeY4Woz5dY u+8PM8QuQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZV jBylxalluelGBpsYgXFzTIJNdwfjnpeWhxgFOBiVeHgVnDxDhFgTy4orcw8xSnOwKInzzqqd FywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcZpDT23X+iNOPZWSvfc/iFQJyx16sott12Kf L6nb2NPYqoseOwrEmahtMjbruLSn5rfV9XO65xtEPqZtrRQVPPqo8tgZqRqBvn2HC9JaVx41 f2f0L4dp7ptqoV8H3rFNUDn0X/FLUNvCXv2nx4QW/WPgWnR/4jqZiRfFvfv+n3U7eDv/bIrq byWW4oxEQy3mouJEAG82QFp8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/atKVF3rQwKkDV4442CQiioDG9Uw 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: Sat, 25 Oct 2014 00:10:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B866592eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Authors, et. al, please kindly consider my comments: * Section 2. Why not to add these to draft-ietf-bfd-seamless-use-case= document? * Section 2.1 o use of S-BFD as inter-AS OAM. Perhaps this use case suggest need fo= r BGP extension to advertise S-BFD discriminator(s). o Lack of control plane. MPLS-TP without control plane assumes centra= lized provisioning and I think it would be reasonable to expect that S-BFD = can be administered in the same manner. o "To accommodate the two scenarios described ..." you've listed thre= e - which one can be ignored? :) * Section 2.2 o I don't think that IP OAM should be concerned with disjointness of = paths taken by different OAM packets over ECMP if network is properly desig= ned and IGP convergence time is not much bigger than OAM defect detection t= ime. (Otherwise there's no reason to report and investigate what well could= be false negative defect.) o I think that this section talks more about need of defect correlati= on. * Section 3 o Have you considered Alert Discriminator as update to draft-ietf-bfd= -seamless-base? Otherwise, if Alert Discriminator is not part of S-BFD base= , not mandatory but optional, capability, then, I think, it must be adverti= sed. * Section 5 o I think that requirement to protect ones NEs from potential DDoS us= ing Alert Discriminator is very serious operational limitation. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Tuesday, October 21, 2014 2:48 PM To: rtg-bfd@ietf.org Subject: New Version Notification for draft-akiya-bfd-seamless-alert-discri= m-03.txt Dear BFD WG, The last of the S-BFD documents, and likely the most controversial one, has= been updated and published. In summary, let's reserve S-BFD discriminator zero(0) as the alert discrimi= nator. We'd appreciate comments. Thanks! -Nobo, ducking for cover [snip] A new version of I-D, draft-akiya-bfd-seamless-alert-discrim-03.txt has been successfully submitted by Nobo Akiya and posted to the IETF reposi= tory. Name: draft-akiya-bfd-seamless-alert-discrim Revision: 03 Title: Seamless Bidirectional Forwarding Detection (S-BFD) Alert D= iscriminator Document date: 2014-10-21 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamles= s-alert-discrim-03.txt Status: https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-a= lert-discrim/ Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-alert-d= iscrim-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless= -alert-discrim-03 Abstract: This document defines the Alert Discriminator which operates on the Seamless Bidirectional Forwarding Detection (S-BFD), and Alert Discriminator Diagnostic Codes which operates on the Alert Discriminator. [snip] --_000_7347100B5761DC41A166AC17F22DF1121B866592eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Nobo, Authors, et. al,
please kindly consider my comments:
  • Section 2. Why not to add these to draft-ietf-bfd-seamless-use-case doc= ument?
  • Section 2.1
  • use of S-BFD as inter-AS OAM. Perhaps this use case suggest need for BG= P extension to advertise S-BFD discriminator(s).
  • Lack of control pl= ane. MPLS-TP without control plane assumes centralized provisioning and I t= hink it would be reasonable to expect that S-BFD can be administered in the= same manner.
  • “To accommodate the two scenarios described = 230;” you’ve listed three – which one can be ignored? J
  • Section 2.2
  • I don’t think that IP OAM should be concerned with disjointness o= f paths taken by different OAM packets over ECMP if network is properly des= igned and IGP convergence time is not much bigger than OAM defect detection= time. (Otherwise there’s no reason to report and investigate what well could be false negative defect.)
  • I= think that this section talks more about need of defect correlation.
    • <= /ul>
    • Section 3
    • Have you considered Alert Discriminator as update to draft-ietf-bfd-sea= mless-base? Otherwise, if Alert Discriminator is not part of S-BFD base, no= t mandatory but optional, capability, then, I think, it must be advertised.=
    • Section 5
    • I think that requirement to protect ones NEs from potential DDoS using = Alert Discriminator is very serious operational limitation.
     
    Regards,
           = ;         Greg
     
    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
    Sent: Tuesday, October 21, 2014 2:48 PM
    To: rtg-bfd@ietf.org
    Subject: New Version Notification for draft-akiya-bfd-seamless-alert-discri= m-03.txt
     
    Dear BFD WG,
     
    The last of the S-BFD documents, and likely the most controversial one= , has been updated and published.
     
    In summary, let's reserve S-BFD discriminator zero(0) as the alert dis= criminator.
     
    We'd appreciate comments.
     
    Thanks!
     
    -Nobo, ducking for cover
     
     
    [snip]
    A new version of I-D, draft-akiya-bfd-seamless-alert-discrim-03.txt
    has been successfully submitted by Nobo Akiya and posted to the IETF r= epository.
     
    Name:           draf= t-akiya-bfd-seamless-alert-discrim
    Revision:       03
    Title:          Seamless = Bidirectional Forwarding Detection (S-BFD) Alert Discriminator
    Document date:  2014-10-21
    Group:          Individua= l Submission
    Pages:          9
    Status:         http= s://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-alert-discrim/
     
    Abstract:
       This document defines the Alert Discriminator which opera= tes on the
       Seamless Bidirectional Forwarding Detection (S-BFD), and = Alert
       Discriminator Diagnostic Codes which operates on the Aler= t
       Discriminator.
    [snip]
     
     
    --_000_7347100B5761DC41A166AC17F22DF1121B866592eusaamb103erics_-- From nobody Sat Oct 25 14:29:10 2014 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 2163B1A1AD5 for ; Sat, 25 Oct 2014 14:29:08 -0700 (PDT) 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 HCs_cGeD5uhJ for ; Sat, 25 Oct 2014 14:29:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95C511A1A2D for ; Sat, 25 Oct 2014 14:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9578; q=dns/txt; s=iport; t=1414272545; x=1415482145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YI2CeVgvhgmjwEIYGrJiXz+PotI1zbT42Gj7FSddufg=; b=lgg2xMnhlDEAK7CU2LwnTjYzB5FF/bozvWg61TWxPt6EXN8V8HcRjRrx CBPyFg7tBiDYBXt+U+MA5OTtpT2G/q+pn3nd6r3KFCWMdwcOwVOqQeXOh vvzkkjzBv5LDGSpUT14/JoZ2vYO5WRuDolrs4knxpEc0pZbeHUk7fxYlC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGALUVTFStJV2c/2dsb2JhbABcgmsjVFMFBIMCylCHTQIbaxYBfYQCAQEBAwEjEUMCDAQCAQYCEQQBAQMCBh0DAgICMBQBCAMFAQEEAQ0FCAESiB0JAQcFlxWcX4VQjm8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyPKzEHBoJxNoEeAQSPaYIehEiIQzyDDYoVgx+EAIN4bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,788,1406592000"; d="scan'208";a="366433165" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 25 Oct 2014 21:29:04 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9PLT4tV006046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 21:29:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 16:29:04 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Topic: New Version Notification for draft-akiya-bfd-seamless-alert-discrim-03.txt Thread-Index: Ac/td9CpsR8YPbouQ+azq8UBG9W92ACaiTmAACxl3vA= Date: Sat, 25 Oct 2014 21:29:03 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B866592@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B866592@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LS8xpXYcuBuiAV9UlB9WaNYd9nw Cc: "draft-ietf-bfd-seamless-use-case@tools.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: Sat, 25 Oct 2014 21:29:08 -0000 KyBkcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy11c2UtY2FzZSBhdXRob3JzDQoNCkhpIEdyZWcsDQoN Ck1hbnkgdGhhbmtzIGZvciBjb21tZW50cy4gSG9uZXN0bHkgSSB3YXMgZXhwZWN0ZWQgYmlnZ2Vy IHRvbWF0b2VzIHRvIGJlIHRocm93biBieSB5b3UsIGJ1dCB5b3Ugd2VyZSB2ZXJ5IGtpbmQgd2l0 aCB5b3VyIGNvbW1lbnRzLiBJIGhvcGUgeW91IHdlcmVuJ3QganVzdCB3YXJtaW5nIHVwIDpQDQoN ClBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGluLWxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogR3JlZ29yeSBNaXJza3kgW21haWx0bzpncmVnb3J5Lm1pcnNreUBl cmljc3Nvbi5jb21dDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAyNCwgMjAxNCA4OjEwIFBNDQo+ IFRvOiBOb2JvIEFraXlhIChub2JvKTsgcnRnLWJmZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3MtYWxl cnQtDQo+IGRpc2NyaW0tMDMudHh0DQo+IA0KPiBIaSBOb2JvLCBBdXRob3JzLCBldC4gYWwsDQo+ IHBsZWFzZSBraW5kbHkgY29uc2lkZXIgbXkgY29tbWVudHM6DQo+IOKAoiBTZWN0aW9uIDIuIFdo eSBub3QgdG8gYWRkIHRoZXNlIHRvIGRyYWZ0LWlldGYtYmZkLXNlYW1sZXNzLXVzZS1jYXNlDQo+ IGRvY3VtZW50Pw0KDQpJIHRoaW5rIGl0IHdhcyBhIGdvb2QgaWRlYSB0byBrZWVwIHRoZXNlICJl eHRlbmRlZCB1c2UgY2FzZXMiIG91dCBmcm9tIHRoZSBkcmFmdC1pZXRmLWJmZC1zZWFtbGVzcy11 c2UtY2FzZSBkb2N1bWVudCBpbml0aWFsbHkuIFRoZXkgbWF5IGhhdmUgc291bmRlZCB0b28gZXh0 cmVtZSBhbmQgY291bGQgaGF2ZSBwcmV2ZW50ZWQgUy1CRkQgY29yZSBmdW5jdGlvbmFsaXRpZXMg dG8gcHJvZ3Jlc3MuIEhvd2V2ZXIsIGdpdmVuIHdoZXJlIHdlIGFyZSwgSSBhZ3JlZS4gSSB0aGlu ayBpdCdzIHJlYXNvbmFibGUgZm9yIHRoZW0gdG8gYmUgbWlncmF0ZWQgb3ZlciB0byBkcmFmdC1p ZXRmLWJmZC1zZWFtbGVzcy11c2UtY2FzZSBkb2N1bWVudC4NCg0KPiDigKIgU2VjdGlvbiAyLjEN Cj4g4oCiIHVzZSBvZiBTLUJGRCBhcyBpbnRlci1BUyBPQU0uIFBlcmhhcHMgdGhpcyB1c2UgY2Fz ZSBzdWdnZXN0IG5lZWQgZm9yIEJHUA0KPiBleHRlbnNpb24gdG8gYWR2ZXJ0aXNlIFMtQkZEIGRp c2NyaW1pbmF0b3IocykuDQoNCkkgYWdyZWUgdGhhdCB1c2Ugb2YgQkdQIGV4dGVuc2lvbiB0byBh ZHZlcnRpc2UgUy1CRkQgZGlzY3JpbWluYXRvcihzKSBpcyBvbmUgc29sdXRpb24gdG8gYWRkcmVz cyBpbnRlci1BUyBzY2VuYXJpby4gVGhlIHVzYWdlIG9mIGFsZXJ0IGRpc2NyaW1pbmF0b3Igd2l0 aCAiZGlzY292ZXJ5IiBkaWFnIGlzIGFub3RoZXIgd2F5LiBJR1AgZXh0ZW5zaW9ucyB0byBhZHZl cnRpc2UgUy1CRkQgZGlzY3JpbWluYXRvcihzKSBpcyBhIG5lY2Vzc2FyeSBmdW5jdGlvbi4gTm90 IG9ubHkgZG9lcyB0aGF0IGFsbG93IFMtQkZEIGRpc2NyaW1pbmF0b3IocykgdG8gYmUgYWR2ZXJ0 aXNlZCB3aXRoaW4gdGhlIElHUCBkb21haW4sIGl0IGFsc28gYWxsb3dzIFMtQkZEIGRpc2NyaW1p bmF0b3IgY29uZmxpY3RzIHdpdGhpbiB0aGUgSUdQIGRvbWFpbi4gRm9yIG90aGVyIHByb3RvY29s IGV4dGVuc2lvbnMgdG8gYWR2ZXJ0aXNlIFMtQkZEIGRpc2NyaW1pbmF0b3IocyksIEkgdGhpbmsg c29tZSB3aWxsIHN0aWxsIG1ha2Ugc2Vuc2UuIEhvd2V2ZXIsIGhhdmluZyBhIHNpbXBsZXIgY29t bW9uIHdheSBmb3IgZGlzY292ZXJpbmcgdGhlIHRhcmdldCBTLUJGRCBkaXNjcmltaW5hdG9yIHdp bGwgYWxzbyBhbGxvdyBmb3IgZmFzdGVyIGRlcGxveW1lbnQgb2YgUy1CRkRzLiBTbywgYWx0aG91 Z2ggQkdQIGV4dGVuc2lvbiBpcyBhIHZhbGlkIHNvbHV0aW9uLCBJIHRoaW5rIHRoZXJlJ3MgYSBi ZW5lZml0IGluIGNvbnNpZGVyaW5nIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQuDQoNCj4g4oCiIExhY2sgb2YgY29udHJvbCBwbGFuZS4gTVBMUy1UUCB3aXRob3V0IGNv bnRyb2wgcGxhbmUgYXNzdW1lcyBjZW50cmFsaXplZA0KPiBwcm92aXNpb25pbmcgYW5kIEkgdGhp bmsgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCBTLUJGRCBjYW4gYmUNCj4g YWRtaW5pc3RlcmVkIGluIHRoZSBzYW1lIG1hbm5lci4NCg0KVHJ1ZSwgdGhpcyBjYW4gYmUgYWNo aWV2ZWQgd2l0aCBjZW50cmFsaXplZCBwcm92aXNpb25pbmcgZGV2aWNlcy4gV2l0aCB0aGUgImRp c2NvdmVyeSIgbWVjaGFuaXNtIGRlc2NyaWJlZCwgaXQgZG9lcyBzaW1wbGlmeSB0aGUgY2VudHJh bGl6ZWQgcHJvdmlzaW9uaW5nIGRldmljZXMgaW4gdGVybXMgb2YgaW5zdHJ1Y3Rpb25zIGl0IG5l ZWRzIHRvIHBlcmZvcm0gdG8gc3RhcnQgdXAgUy1CRkQuIEFkZGl0aW9uYWxseSB3aXRoIHRoZSAi ZGlzY292ZXJ5IiBtZWNoYW5pc20gZGVzY3JpYmVkLCBpdCB3aWxsIHNpbXBsaWZ5IHNjZW5hcmlv cyB3aGVyZSB0aGVyZSBpcyBubyBvciB0aGVyZSBpcyBubyAic21hcnQiIGNlbnRyYWxpemVkIHBy b3Zpc2lvbmluZyBkZXZpY2VzLg0KDQo+IOKAoiDigJxUbyBhY2NvbW1vZGF0ZSB0aGUgdHdvIHNj ZW5hcmlvcyBkZXNjcmliZWQg4oCm4oCdIHlvdeKAmXZlIGxpc3RlZCB0aHJlZSDigJMNCj4gd2hp Y2ggb25lIGNhbiBiZSBpZ25vcmVkPyDimLoNCg0KT29wcywgdGhhbmtzIGZvciBjYXRjaGluZyB0 aGF0IGxvbC4gQWx0aG91Z2ggeW91IHByb3ZpZGVkIHNvbWUgYWx0ZXJuYXRlIHNvbHV0aW9ucywg SSBzdGlsbCBkbyBzZWUgdGhyZWUgdXNlIGNhc2VzIDopDQoNCj4g4oCiIFNlY3Rpb24gMi4yDQo+ IOKAoiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBJUCBPQU0gc2hvdWxkIGJlIGNvbmNlcm5lZCB3aXRo IGRpc2pvaW50bmVzcyBvZiBwYXRocw0KPiB0YWtlbiBieSBkaWZmZXJlbnQgT0FNIHBhY2tldHMg b3ZlciBFQ01QIGlmIG5ldHdvcmsgaXMgcHJvcGVybHkgZGVzaWduZWQNCj4gYW5kIElHUCBjb252 ZXJnZW5jZSB0aW1lIGlzIG5vdCBtdWNoIGJpZ2dlciB0aGFuIE9BTSBkZWZlY3QgZGV0ZWN0aW9u DQo+IHRpbWUuIChPdGhlcndpc2UgdGhlcmXigJlzIG5vIHJlYXNvbiB0byByZXBvcnQgYW5kIGlu dmVzdGlnYXRlIHdoYXQgd2VsbA0KPiBjb3VsZCBiZSBmYWxzZSBuZWdhdGl2ZSBkZWZlY3QuKQ0K DQpGb3IgaGFsZiBvZiB3aGF0IHlvdSBzYWlkLCBJIGFncmVlLiBGb3IgdGhlIG90aGVyIGhhbGYs IEkgZG9uJ3QgYWdyZWUgOikgSVAgZGF0YSBwbGFuZSBpcyBmYWlybHkgZ29vZDogcnVuIHNpbmds ZS1ob3AgQkZEIG9uIGV2ZXJ5IGxpbmssIHJ1biBCRkQgb24gTEFHIG9uIGV2ZXJ5IExBRywgYW5k IG1ha2Ugc3VyZSBJR1AgY29udmVyZ2VzIGJhc2VkIG9uIHRoZXNlLCBldGMuIEhvd2V2ZXIsIHRo ZXJlJ3MgYSBiaWcgZ2FwIHdoZW4gaXQgY29tZXMgdG8gRUNNUCBvbiBNUExTIGRhdGEgcGxhbmUg KHdoZXRoZXIgaXQncyBMRFAgb3IgUlNWUCBvciBTZWdtZW50IFJvdXRpbmcpLiBPbmUgb2YgdGhl IG1ham9yIGNvbnRyaWJ1dG9yIG9mIHRyYWZmaWMgYmxhY2sgaG9saW5nIG9uIHRoZSBNUExTIGRh dGEgcGxhbmUgaXMgdGhlIGRpc2Nvbm5lY3QgYmV0d2VlbiBjb250cm9sIHBsYW5lIGFuZCBkYXRh IHBsYW5lIChpLmUuIG1pc3NpbmcgZXhwZWN0ZWQgaW4vb3V0IGxhYmVscyBmcm9tIGRhdGEgcGxh bmUpLiBTaW5nbGUtaG9wIEJGRCBjYW5ub3QgZGV0ZWN0IHRoaXMgc2luY2UgSVAgY29ubmVjdGl2 aXR5IGlzIGZpbmUuIEJGRCBvbiBMQUcgY2Fubm90IGRldGVjdCB0aGlzIHNpbmNlIExBRyAoYW5k IHRoZSBJUCBvbiB0aGUgTEFHKSBpcyBmaW5lLiBTaW5nbGUgQkZEIG92ZXIgTVBMUyBzZXNzaW9u IGVuZC10by1lbmQgY2FuIHZlcmlmeSBvbmUgYXJiaXRyYXJ5IHBhdGggb2YgdGhlIEVDTVAsIGJ1 dCBub3QgYWxsIC4uLiBtZWFuaW5nIGl0J3MgYmxpbmQgdG8gcHJvYmxlbXMuDQoNCj4g4oCiIEkg dGhpbmsgdGhhdCB0aGlzIHNlY3Rpb24gdGFsa3MgbW9yZSBhYm91dCBuZWVkIG9mIGRlZmVjdCBj b3JyZWxhdGlvbi4NCg0KSSBjb3VsZG4ndCB1bmRlcnN0YW5kIHRoaXMgb25lLiBDYW4geW91IGVs YWJvcmF0ZT8NCg0KPiDigKIgU2VjdGlvbiAzDQo+IOKAoiBIYXZlIHlvdSBjb25zaWRlcmVkIEFs ZXJ0IERpc2NyaW1pbmF0b3IgYXMgdXBkYXRlIHRvIGRyYWZ0LWlldGYtYmZkLQ0KPiBzZWFtbGVz cy1iYXNlPyBPdGhlcndpc2UsIGlmIEFsZXJ0IERpc2NyaW1pbmF0b3IgaXMgbm90IHBhcnQgb2Yg Uy1CRkQgYmFzZSwNCj4gbm90IG1hbmRhdG9yeSBidXQgb3B0aW9uYWwsIGNhcGFiaWxpdHksIHRo ZW4sIEkgdGhpbmssIGl0IG11c3QgYmUgYWR2ZXJ0aXNlZC4NCg0KVGhhdCdzIGEgZ29vZCBwb2lu dCwgSSBkaWRuJ3QgdGhpbmsgYWJvdXQgcHV0dGluZyB0aGlzIGluIHRoZSBkcmFmdC1pZXRmLWJm ZC1zZWFtbGVzcy1iYXNlLiBJIHRoaW5rIHRoaXMgaXMgYSByZWFzb25hYmxlIG9wdGlvbiBpZiB0 aGUgV0cgdGhpbmtzIHRoZXNlIGZ1bmN0aW9ucyBhcmUgdXNlZnVsLg0KDQo+IOKAoiBTZWN0aW9u IDUNCj4g4oCiIEkgdGhpbmsgdGhhdCByZXF1aXJlbWVudCB0byBwcm90ZWN0IG9uZXMgTkVzIGZy b20gcG90ZW50aWFsIEREb1MgdXNpbmcNCj4gQWxlcnQgRGlzY3JpbWluYXRvciBpcyB2ZXJ5IHNl cmlvdXMgb3BlcmF0aW9uYWwgbGltaXRhdGlvbi4NCg0KSSBmdWxseSBhZ3JlZSB0aGF0IHRoZSBh bGVydCBkaXNjcmltaW5hdG9yIG11c3QgYmUgdXNlZCB3aXRoIGNhcmUsIHN1Y2ggYXMgZ29vZCBm aWx0ZXJpbmcgb2Ygd2hvIHlvdSBhY2NlcHQgYWxlcnQgZGlzY3JpbWluYXRvciBmcm9tLiBJIHRo aW5rIG1vcmUgY29udGVudHMgb24gdGhpcyBzZWN0aW9uIHdpbGwgYmUgZ29vZC4NCg0KSSBwbGFu IHRvIHByZXNlbnQgUy1CRkQgdXBkYXRlIGF0IElFVEY5MSwgSSdsbCBicmluZyB1cCAyIHRoaW5n cy4NCjEuIEZlZWwgb2YgdGhlIGF1ZGllbmNlIG9uIG1pZ3JhdGluZyB0aGUgMiB1c2UgY2FzZXMg dG8gZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtdXNlLWNhc2UuDQoyLiBGZWVsIG9mIHRoZSBhdWRp ZW5jZSBvbiBtaWdyYXRpbmcgdGhlIGFsZXJ0IGRpc2NyaW1pbmF0b3IgdG8gZHJhZnQtaWV0Zi1i ZmQtc2VhbWxlc3MtYmFzZS4NCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQo+IA0KPiBSZWdhcmRzLA0K PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgR3JlZw0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5vYm8gQWtpeWENCj4gKG5vYm8pDQo+IFNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMjEsIDIwMTQgMjo0OCBQTQ0KPiBUbzogcnRnLWJmZEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy1hbGVydC0NCj4gZGlzY3JpbS0wMy50eHQNCj4gDQo+IERlYXIgQkZEIFdHLA0KPiANCj4g VGhlIGxhc3Qgb2YgdGhlIFMtQkZEIGRvY3VtZW50cywgYW5kIGxpa2VseSB0aGUgbW9zdCBjb250 cm92ZXJzaWFsIG9uZSwgaGFzDQo+IGJlZW4gdXBkYXRlZCBhbmQgcHVibGlzaGVkLg0KPiANCj4g SW4gc3VtbWFyeSwgbGV0J3MgcmVzZXJ2ZSBTLUJGRCBkaXNjcmltaW5hdG9yIHplcm8oMCkgYXMg dGhlIGFsZXJ0DQo+IGRpc2NyaW1pbmF0b3IuDQo+IA0KPiBXZSdkIGFwcHJlY2lhdGUgY29tbWVu dHMuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiAtTm9ibywgZHVja2luZyBmb3IgY292ZXINCj4gDQo+ IA0KPiBbc25pcF0NCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy1hbGVydC1kaXNjcmltLTAzLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IE5vYm8gQWtpeWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0K PiANCj4gTmFtZTrCoMKgwqDCoMKgwqDCoMKgwqDCoCBkcmFmdC1ha2l5YS1iZmQtc2VhbWxlc3Mt YWxlcnQtZGlzY3JpbQ0KPiBSZXZpc2lvbjrCoMKgwqDCoMKgwqAgMDMNCj4gVGl0bGU6wqDCoMKg wqDCoMKgwqDCoMKgIFNlYW1sZXNzIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24g KFMtQkZEKSBBbGVydA0KPiBEaXNjcmltaW5hdG9yDQo+IERvY3VtZW50IGRhdGU6wqAgMjAxNC0x MC0yMQ0KPiBHcm91cDrCoMKgwqDCoMKgwqDCoMKgwqAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOsKgwqDCoMKgwqDCoMKgwqDCoCA5DQo+IFVSTDrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFraXlhLWJmZC1zZWFt bGVzcy0NCj4gYWxlcnQtZGlzY3JpbS0wMy50eHQNCj4gU3RhdHVzOsKgwqDCoMKgwqDCoMKgwqAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNz LWFsZXJ0LQ0KPiBkaXNjcmltLw0KPiBIdG1saXplZDrCoMKgwqDCoMKgwqAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWFsZXJ0LQ0KPiBkaXNjcmlt LTAzDQo+IERpZmY6wqDCoMKgwqDCoMKgwqDCoMKgwqAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtYWtpeWEtYmZkLXNlYW1sZXNzLWFsZXJ0LQ0KPiBkaXNjcmltLTAzDQo+ IA0KPiBBYnN0cmFjdDoNCj4gwqDCoCBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIEFsZXJ0IERp c2NyaW1pbmF0b3Igd2hpY2ggb3BlcmF0ZXMgb24gdGhlDQo+IMKgwqAgU2VhbWxlc3MgQmlkaXJl Y3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoUy1CRkQpLCBhbmQgQWxlcnQNCj4gwqDCoCBE aXNjcmltaW5hdG9yIERpYWdub3N0aWMgQ29kZXMgd2hpY2ggb3BlcmF0ZXMgb24gdGhlIEFsZXJ0 DQo+IMKgwqAgRGlzY3JpbWluYXRvci4NCj4gW3NuaXBdDQo+IA0KPiANCg== From nobody Sat Oct 25 14:55:36 2014 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 8B66C1A1A66 for ; Sat, 25 Oct 2014 14:55:35 -0700 (PDT) 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 JIpqMWy0pcg9 for ; Sat, 25 Oct 2014 14:55:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D471A1A45 for ; Sat, 25 Oct 2014 14:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=441; q=dns/txt; s=iport; t=1414274134; x=1415483734; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xaN4EVgoFGMydZakRszRjZxa+oO4zMVdiNp+sQGplcg=; b=dX4ip6LFnHlK1iPFh8Mgy3cecXAVGTAUAfYT6L7On8zG08wiWbjllkGX 8XNUVuO6fj7lRNZF0QltLkKJMdzXsw615nmppsc/ym5jaz74ogzgszLpb RG+IJnxXEJiXeVLu6SpipKddjoOsCdaNNzpI2x6lkhusM/uuRt258N4Ml k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FAP8bTFStJV2S/2dsb2JhbABcgmsjVFkDzVKHTQKBBRYBcguEBAEEOlEBKhRCJgEEGwGIOAEMpDCjegELIJBXg2WBHgWPaYIejQuDSY00hACDeII0gQMBAQE X-IronPort-AV: E=Sophos;i="5.04,788,1406592000"; d="scan'208";a="366396087" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2014 21:55:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9PLtXLj030949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 25 Oct 2014 21:55:33 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 16:55:33 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF91 BFD WG Agenda (Tentative) Thread-Topic: IETF91 BFD WG Agenda (Tentative) Thread-Index: Ac/wnYZzGbbdpvVpR7CQjZatyVomGA== Date: Sat, 25 Oct 2014 21:55:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NGb3QXMQhhi4sOdTv55hAwrh53I 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: Sat, 25 Oct 2014 21:55:35 -0000 Hello BFD WG, Tentative IETF91 BFD WG agenda has been posted. http://www.ietf.org/proceedings/91/agenda/agenda-91-bfd Please look over and let Jeff and I know if we have missed anything. If you are presenting, please send Jeff and I your slides by no longer than= November 7th. Reminder: 2014-10-27 (Monday): Internet Draft submission cut-off (for all drafts, inc= luding -00) by UTC 23:59 Thanks! -Nobo and Jeff From nobody Sun Oct 26 14:31:12 2014 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 EBF971A1AAF; Sun, 26 Oct 2014 14:31:10 -0700 (PDT) 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 JBA9P_x3SL5W; Sun, 26 Oct 2014 14:31:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18801A1A9E; Sun, 26 Oct 2014 14:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6506; q=dns/txt; s=iport; t=1414359068; x=1415568668; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XJHnI14gfJa91YgF43dYfk9D4moFpMIZNN8PkUaqB3E=; b=KlCPaR3Uz4yUfxMzcnkzxiB+C7zCgm5JzExH+aaiw/TrbrgMRiV2zOXf le+4WxGYX5x2d6mX3T3kKGKvLxTJ5A7kcmFm10gFllAJvtIgsEa50d/DS z3WduVATm5EgakKDAcT2dFZTuYPe8pgrr+X8Ko4yUIkqh/4MCH2FqwCwY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKdnTVStJV2Q/2dsb2JhbABcgmsjVFMFBMxsCoZ5VAKBCRYBfYQCAQEBBAEBATc0CQ4EAgEIEQQBAQsUCQcnCxQIAQgCBAESCAGIOAEHBcdGAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXOAaDJ4EeBY9pgh6ESIhDPIMNgy2GaIMfhACCNIFEbIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,791,1406592000"; d="scan'208";a="366655403" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 26 Oct 2014 21:31:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9QLV7au029321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 21:31:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 16:31:07 -0500 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Subject: RE: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Topic: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP7vuLnXrxVtGdr0an+IEI1vxrJpw+GV8QgATDqGA= Date: Sun, 26 Oct 2014 21:31:07 +0000 Message-ID: References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8656DB@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VZ28QnuoXW83nGx2whhQj8A6nXY 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, 26 Oct 2014 21:31:11 -0000 Hi Greg, Jeff, et al, Please find below my comments on draft-mirsky-mpls-bfd-directed. 1) General - clarification I realize that there's no explicit code point overlap between draft-mirsky-= mpls-bfd-directed and draft-chen-mpls-bfd-enhancement: draft-mirsky-mpls-bf= d-directed is focused on Segment Routing whilst draft-chen-mpls-bfd-enhance= ment is focused on existing MPLS technologies. However, both documents are = describing how to program the reverse BFD path on the egress LSR via LSP Pi= ng. It would be nice to have one way of doing this, whether the technology = is Segment Routing or something else. Can authors of draft-mirsky-mpls-bfd-= directed and draft-chen-mpls-bfd-enhancement sync up to come up with a sing= le approach? 2) Section 1 - clarification The [RFC5880], [RFC5881], and the [RFC5883] established BFD protocol for IP networks and the [RFC5884] set rules of using BFD Asynchronous mode over IP/MPLS LSPs. The described problem is valid, but: - I don't think the same problem applies to RFC5881 (aka single-hop BFD), a= s sessions are bound to the interface being monitored. - The same problem is definitely not applicable to RFC5880 which is the bas= e protocol spec (i.e. does not define any data plane procedures). Perhaps you can list only RFC5883/RFC5884 or add some clarifications on why= RFC5880/RFC5881 are also listed. 3) Section 1 - clarification And because BFD control packets are not guaranteed to cross the same links and nodes in both directions detection of Loss of Continuity (LoC) defect in forward direction is not guaranteed or is free of positive negatives. I tripped over the words "... free of positive negatives" and had to read t= his multiple times. This is purely a nit comment, but I think what you want= to say here is "... free of false negatives"? 4) Section 2 s/BF D/BFD/ [NOTE] Remove space between 'F' and 'D'. 5) Section 2 - some text suggestion [OLD] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. [NEW] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. The head-end node in this case will detect a problem due to lack of expected BFD control packets (i.e. detection timer expiry) instead of immediately receiving BFD control packets with explicit Down messages from the far-end peer. 6) Section 3.3 - clarification [snip] Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed. " When LSP ping is used to bootstrap BFD session this document updates this and defines that LSP Ping MUST include the FEC corresponding to the destination segment and SHOULD NOT include FECs corresponding to some or all of segment imposed by the initiator. Operationally such restriction would not cause any problem or uncertainty as LSP ping with FECs corresponding to some or all segments or traceroute may preceed the LSP ping that bootstraps the BFD session. [snip] Right now draft-kumarkini-mpls-spring-lsp-ping states, "MAY include other F= ECs". draft-mirsky-mpls-bfd-directed updates this by stating, "SHOULD NOT include= other FECs". It seems to me that the both aren't very different and the proposed mechani= sm will work whether this change is made or not. Can you clarify why this d= ocument makes above update? 7) General - additional reference With Segment Routing, there can be multiple SR-TE paths between the same so= urce/destination pairs, with subset of SR-TE paths ending with same SID. Th= us, there's a strong dependency from this mechanism described to draft-grma= s-bfd-rfc5884-clarifications. It might be a good idea that implementation o= f draft-mirsky-mpls-bfd-directed will require draft-grmas-bfd-rfc5884-clari= fications. Thanks! -Nobo > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gregory Mirsky > Sent: Thursday, October 23, 2014 4:02 PM > To: rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org > Subject: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd- > directed-01.txt >=20 > Dear All, > a new section 3.3 Bootstrapping BFD session with BFD Reverse Path over > Segment Routed tunnel been added. Authors always welcome your > comments and greatly appreciate suggestions. We're looking forward to > continue discussion at WG meetings at IETF-91. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 23, 2014 12:57 PM > To: Gregory Mirsky; Jeff Tantsura; Gregory Mirsky; Jeff Tantsura; Ilya > Varlashkin; Ilya Varlashkin > Subject: New Version Notification for draft-mirsky-mpls-bfd-directed-01.t= xt >=20 >=20 > A new version of I-D, draft-mirsky-mpls-bfd-directed-01.txt > has been successfully submitted by Greg Mirsky and posted to the IETF > repository. >=20 > Name: draft-mirsky-mpls-bfd-directed > Revision: 01 > Title: Bidirectional Forwarding Detection (BFD) Directed Return > Path > Document date: 2014-10-23 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd= - > directed-01.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd- > directed/ > Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed= -01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-bfd-= directed- > 01 >=20 > Abstract: > Bidirectional Forwarding Detection (BFD) is expected to monitor bi- > directional paths. When a BFD session monitors in its forward > direction an explicitly routed path there is a need to be able to > direct far-end BFD peer to use specific path as reverse direction of > the BFD session. >=20 >=20 >=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.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sun Oct 26 15:14:51 2014 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 DA47A1A1AB3 for ; Sun, 26 Oct 2014 15:14:48 -0700 (PDT) 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 dwq7WnlTb1UE for ; Sun, 26 Oct 2014 15:14:47 -0700 (PDT) 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 F07531A1AB0 for ; Sun, 26 Oct 2014 15:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1214; q=dns/txt; s=iport; t=1414361688; x=1415571288; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ks8rLkZqxhBA1rf5Db0GPe5ZiTPItKWacYz6ybhkn8k=; b=U4k6HDKHQShOmvY5YnSHxoaz4I+lODYe1vbLdGeKfcdJKMuQ1XO/sjkt ZHWqisd2kGj+dUuCiPTnwkckLYPuqECX7sV3QqdBKiSVBDKD3CGb/kZAG ign11Krxj+IlQ/GgqP1S3Jn9SpPb/G1h2RiW6YQ/wDcNKHEoaLn+UXgTu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFANJwTVStJA2L/2dsb2JhbABcgmsjVFgEzHaHTQKBChYBfYQCAQEBBB0dMQ4MBAIBCA4DBAEBAQoUCQcyFAkIAgQOBQgBiDgBDMdUAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXMQcGgyeBHgWPaYIehEiIf5RBg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,791,1406592000"; d="scan'208";a="366837416" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP; 26 Oct 2014 22:14:47 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9QMEk2i012124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Oct 2014 22:14:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Sun, 26 Oct 2014 17:14:45 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas Subject: RE: Call for adoption for draft-akiya-bfd-seamless-ip Thread-Topic: Call for adoption for draft-akiya-bfd-seamless-ip Thread-Index: AQHPxxmOoUonnCaoS0iL2q7HJxPquJv/giOAgAE0dbCAP17ggIADMMvA Date: Sun, 26 Oct 2014 22:14:45 +0000 Message-ID: References: <20140903015109.GK7736@pfrc> <20140913142317.GA10965@pfrc> <20141024163113.GT30433@pfrc> In-Reply-To: <20141024163113.GT30433@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/D-Z1jTlnPVmwdKKte1M42lbcX7A 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, 26 Oct 2014 22:14:49 -0000 Thank you Jeff! -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Friday, October 24, 2014 12:31 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: Call for adoption for draft-akiya-bfd-seamless-ip >=20 > Nobo and other S-BFD contributors: >=20 > On Sun, Sep 14, 2014 at 01:57:02PM +0000, Nobo Akiya (nobo) wrote: > > Hi Jeff and WG, > > > > Thank you for allowing the document to become a WG document. The > document has been published as draft-ietf-bfd-seamless-ip. > > > > URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-seam= less-ip- > 00.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamles= s-ip/ > > Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-seamless-ip-0= 0 > > > > Jeff, authors feel that this is a good trigger to initiate port allocat= ion of the > S-BFD ports via Expert Review process. Section 8 of draft-ietf-bfd-seamle= ss- > ip-00 has all necessary values. Can you help initiating this process? >=20 > A request has been forwarded to our area director to re-start the early > allocation process for the S-BFD port. >=20 > -- Jeff From nobody Sun Oct 26 19:58:43 2014 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 C77481A6F30 for ; Sun, 26 Oct 2014 19:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 mxswYFAkpDBF for ; Sun, 26 Oct 2014 19:58:38 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56091A1B5B for ; Sun, 26 Oct 2014 19:58:38 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i17so1662245qcy.31 for ; Sun, 26 Oct 2014 19:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:content-transfer-encoding:subject:references:from :mime-version:in-reply-to:message-id:date:cc:to; bh=lLVqAn2nY1C89tvYV2QuSyBVEuuwNmzIaEXjH7QCY2o=; b=lIWFFoLO3vtch2LYV7LnWgjFnSylJAOFXJ4Jw5BeGNoJtfFQz/KDw+9F3wA3PSf2FB 0z/x5LL9sKyrL/M3Cb2cIeNG9tJcvy67n6VzfwtyzUE4uolTCpC+Q/ZrRq38j5rMik28 qNrkSDSbMKlmJhYd9KjDcuBAJ90qShHOM5ocsBIc+rysiUyDDFdbZ66PQmmj8OeJXcuH p0rDWtbKgf/sdtznMOFDnksWnPKDhvH3XdAP+kyxftcxq03Iloa+49gYlm9yvezJjRSl SyDiRMQWq6Ky8IZPcDjKhzA1YDLITOlDFOWKxABKf9680MArHeJP9PrcPGZdhyHvMPfj 6U3A== X-Received: by 10.224.80.193 with SMTP id u1mr27830572qak.86.1414378717963; Sun, 26 Oct 2014 19:58:37 -0700 (PDT) Received: from [172.20.14.216] ([12.133.161.2]) by mx.google.com with ESMTPSA id s3sm10248664qat.4.2014.10.26.19.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 19:58:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9CB5C9D7-03FE-431A-A34A-F51650BFAE94 Content-Transfer-Encoding: 7bit Subject: Re: New version for draft-ashesh-bfd-stability now available References: <20141024142953.GG30433@pfrc> From: Mahesh Jethanandani Mime-Version: 1.0 (1.0) In-Reply-To: <20141024142953.GG30433@pfrc> Message-Id: <101E9102-777D-48F5-A9B0-BD7A496E724A@gmail.com> Date: Sun, 26 Oct 2014 13:05:20 -0700 To: Jeffrey Haas X-Mailer: iPad Mail (11D257) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/U1OX7BIlYHHmXsUZvdx-EydXqQo Cc: "rtg-bfd@ietf.org" , Ashesh Mishra 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, 27 Oct 2014 02:58:40 -0000 --Apple-Mail-9CB5C9D7-03FE-431A-A34A-F51650BFAE94 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mahesh Jethanandani mjethanandani@gmail.com > On Oct 24, 2014, at 7:29 AM, Jeffrey Haas wrote: >=20 > Would the WG benefit from a management framework for this mechanism? Thes= e > days that probably means a yang module, but this is also potentially > amenable to an extension of the BFD MIB. [With BFD YANG design group hat on] Yes, the design group can include this in their management framework. [With BFD YANG design group hat off] >=20 > Secondary note: This mechanism theoretically could work on any meticulous > authentication scheme. The major considerations against that are: > - The reserved space kept against further statistics. > - The overhead of meticulous authentication when actual cryptographic chec= ks > are performed. (There was supposed to be a proposal for making those > checks more reasonable coming soon. :-) The loss of BFD frames by itself would not cause an overhead per the propose= d changes (yes the proposal is pending) because there would be no state chan= ge.= --Apple-Mail-9CB5C9D7-03FE-431A-A34A-F51650BFAE94 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


    Mahesh Jethanandani

    On Oct 24, 2014, at 7:29 AM, Jeffrey Haa= s <jhaas@pfrc.org> wrote:
    Would the WG benefit from a managemen= t framework for this mechanism?  These
    days that probab= ly means a yang module, but this is also potentially
    amenabl= e to an extension of the BFD MIB.

    [Wit= h BFD YANG design group hat on]

    Yes, the design group can= include this in their management framework.

    [With B= FD YANG design group hat off]

    =
    Secondary note: This mechanism theoretically could work on a= ny meticulous
    authentication scheme.  The major conside= rations against that are:
    - The reserved space kept against f= urther statistics.
    - The overhead of meticulous authenticati= on when actual cryptographic checks
     are performed. &n= bsp;(There was supposed to be a proposal for making those
    &= nbsp;checks more reasonable coming soon. :-)

    The loss of BFD frames by itself would not cause an overhead per the prop= osed changes (yes the proposal is pending) because there would be no state c= hange.
    = --Apple-Mail-9CB5C9D7-03FE-431A-A34A-F51650BFAE94-- From nobody Mon Oct 27 05:44:55 2014 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 B83481A9072 for ; Mon, 27 Oct 2014 05:44:36 -0700 (PDT) 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 X7R4UZ38x1SR for ; Mon, 27 Oct 2014 05:44:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BD21A9046 for ; Mon, 27 Oct 2014 05:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=953; q=dns/txt; s=iport; t=1414413875; x=1415623475; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=bibyJPyuS9Fg7eVSipGN+rwrrXahyyxVe30aho/eZCI=; b=kDc+qHWqDuaBRVA/jNvywTjwPzdwu8sjMYQBg/WdIZOb8vKlxJ/MI87Q d/joNv5AddSIiryodtDllhxOjYbjBEw/1eNJ9KSG4JcY4ZvzYQZyWeTv0 fyyV1lsU5nKVVlurmSfS6a0/YQpFoJkr1L8d6D1ltCPegBC5p+c9ZhlIa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAGU9TlStJV2P/2dsb2JhbABcgmsjVFgBA808h00CgRgWAXILhAQBBDo/EgEqFEImAQQODYg5AQzKPAEBAQEBBQEBAQEBARyQNwEBHjGDNIEeBY9pgh6ESIhDPJBBhACDeG2BDjmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,795,1406592000"; d="scan'208";a="366707387" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 27 Oct 2014 12:44:34 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s9RCiYRb003174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Oct 2014 12:44:34 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 27 Oct 2014 07:44:34 -0500 From: "Nobo Akiya (nobo)" To: "draft-wang-yang-bfd-oam@tools.ietf.org" Subject: Mail regarding draft-wang-yang-bfd-oam Thread-Topic: Mail regarding draft-wang-yang-bfd-oam Thread-Index: Ac/x4VJNTSl5wYKTR0SfmT9yU1MSpA== Date: Mon, 27 Oct 2014 12:44:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PKZPhrRQcor5EC_IvBxM79vyAcE 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, 27 Oct 2014 12:44:36 -0000 Authors, I see that you have just published draft-wang-yang-bfd-oam-00. The BFD WG has formed a design team to define the yang models for the BFD t= echnologies. http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord Ensuring that multiple vendors are collaborating from the initial design, a= lthough will require more time, will help significantly to come up with the= definition that accommodates large set of existing implementations. I'm sure the authors of draft-wang-yang-bfd-oam have spent time/effort to d= efining your version of the BFD yang models, and I do appreciate that. What= will be helpful, instead of attempting to push draft-wang-yang-bfd-oam any= further, is for you to provide your input and focus to helping the BFD yan= g design team. The BFD yang design team: - will be presenting at IETF91. - will have -00 posted, hopefully shortly after IETF91. Thanks! -Nobo, as the BFD WG co-chair From nobody Mon Oct 27 07:10:16 2014 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 6ECC91ACD3A for ; Mon, 27 Oct 2014 07:09:24 -0700 (PDT) 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 5Iee0Mh1659a for ; Mon, 27 Oct 2014 07:09:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 581C81ACD3C for ; Mon, 27 Oct 2014 07:09:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F19FEC221; Mon, 27 Oct 2014 10:09:13 -0400 (EDT) Date: Mon, 27 Oct 2014 10:09:13 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org, draft-wang-yang-bfd-oam@tools.ietf.org Subject: Re: Mail regarding draft-wang-yang-bfd-oam Message-ID: <20141027140913.GB8111@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: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oF7UJXDp_Rzic8KQi1ytz9KQUgw Cc: "rtg-bfd@ietf.org" , "draft-wang-yang-bfd-oam@tools.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, 27 Oct 2014 14:09:24 -0000 X-List-Received-Date: Mon, 27 Oct 2014 14:09:24 -0000 On Mon, Oct 27, 2014 at 12:44:33PM +0000, Nobo Akiya (nobo) wrote: > I see that you have just published draft-wang-yang-bfd-oam-00. > > The BFD WG has formed a design team to define the yang models for the BFD technologies. > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord > > Ensuring that multiple vendors are collaborating from the initial design, although will require more time, will help significantly to come up with the definition that accommodates large set of existing implementations. > > I'm sure the authors of draft-wang-yang-bfd-oam have spent time/effort to defining your version of the BFD yang models, and I do appreciate that. What will be helpful, instead of attempting to push draft-wang-yang-bfd-oam any further, is for you to provide your input and focus to helping the BFD yang design team. I will be taking an action item to get the design team mailing list setup. They're still working using mail cc: chains. This will also provide more openness to the work. We'd also invite the authors of this draft to review the current git repository of materials to see what other vendors have contributed as materials toward modeling BFD and would invite them to contribute the draft contents as another input to that repository. > The BFD yang design team: > - will be presenting at IETF91. > - will have -00 posted, hopefully shortly after IETF91. We'd like to encourage the design team to review Wang and Wu's proposal, specifically the BFD modeling constructs. One of the more interesting aspects, not yet decided at a larger IETF level, is integration with the generic OAM framework that is starting to get attention in the LIME working group. In particular, the idea of "management domains". While we see that in this model there isn't a strong resemblance to the IEEE MEP model used for Ethernet, there had been some prior concern about this. Operators in the past have strongly indicated a beneficial aspect of BFD is is didn't require configuration integration in such a model. While the deadline for IETF is approaching, if it's possible to include some analysis of the proposal, that'd be helpful. However, the chairs are very aware that the weeks just prior to a session are usually very busy. -- Jeff & Nobo From nobody Mon Oct 27 07:47:22 2014 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 BEB071ACDDA for ; Mon, 27 Oct 2014 07:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 WlsPcaVpKQT1 for ; Mon, 27 Oct 2014 07:46:47 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B97A1ACDD6 for ; Mon, 27 Oct 2014 07:46:46 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id e89so3941356qgf.8 for ; Mon, 27 Oct 2014 07:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=EO/6ThuMMafUm8JoiYJhELRPupKITju3Idw8EraWp7o=; b=EG21664obW7w5TbglyoCpCo//K0sW+8LHW7SBZyqsh0D75vizp3rrTs/02Zc8DqUaT 0Ss+2LUWlvcmSVt+5MTFlo+4I5fPVGqa670uLXDl0hhAXSmj+bnHkbcRVv7T3HMXXJxn zbgbEW4Q0cr/Fjf+MTN7xXhic/7VQCbpdAS9oLzYyGNZXnfjAjWAx02j4innqpNyRbfT 9Us5HwhjwRj3DUOl30fMxvAjFN2GJpmOKWWrffmagdlYW/TCR4XusTTxVud7663e8ujo 2SUcRGLz1fEBDbv1u4/W5QDNN4b6qp4xtCki0R1Qf6yDU1HXmMhCiIhsQqOZWN3hbXeP RB4Q== X-Received: by 10.140.21.199 with SMTP id 65mr31513795qgl.86.1414421206192; Mon, 27 Oct 2014 07:46:46 -0700 (PDT) Received: from [10.0.0.18] ([50.251.156.113]) by mx.google.com with ESMTPSA id w8sm11397820qay.5.2014.10.27.07.46.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 07:46:45 -0700 (PDT) References: <20141027140913.GB8111@pfrc> Mime-Version: 1.0 (1.0) In-Reply-To: <20141027140913.GB8111@pfrc> Content-Type: multipart/alternative; boundary=Apple-Mail-737230BC-90BD-4BB9-9B6D-577BAE4D7DBC Content-Transfer-Encoding: 7bit Message-Id: <7D6ACD14-6E81-4F7D-99D7-B5A96FB50D18@gmail.com> X-Mailer: iPad Mail (11D257) From: Mahesh Jethanandani Subject: Re: Mail regarding draft-wang-yang-bfd-oam Date: Mon, 27 Oct 2014 10:46:44 -0400 To: Jeffrey Haas Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/pwgU0fCoNHtUVN4IYJWPJ3FRYOo Cc: "rtg-bfd@ietf.org" , "draft-wang-yang-bfd-oam@tools.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, 27 Oct 2014 14:46:57 -0000 --Apple-Mail-737230BC-90BD-4BB9-9B6D-577BAE4D7DBC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Jeff, The design team will *try* to take a look at this new draft before the meeti= ng. But as you note, the weeks before the meeting tend to be the busiest and= not the best time to take on new work. So thank you for that understanding.= Mahesh Jethanandani mjethanandani@gmail.com > On Oct 27, 2014, at 10:09 AM, Jeffrey Haas wrote: >=20 >> On Mon, Oct 27, 2014 at 12:44:33PM +0000, Nobo Akiya (nobo) wrote: >> I see that you have just published draft-wang-yang-bfd-oam-00. >>=20 >> The BFD WG has formed a design team to define the yang models for the BFD= technologies. >>=20 >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCoord >>=20 >> Ensuring that multiple vendors are collaborating from the initial design,= although will require more time, will help significantly to come up with th= e definition that accommodates large set of existing implementations. >>=20 >> I'm sure the authors of draft-wang-yang-bfd-oam have spent time/effort to= defining your version of the BFD yang models, and I do appreciate that. Wha= t will be helpful, instead of attempting to push draft-wang-yang-bfd-oam any= further, is for you to provide your input and focus to helping the BFD yang= design team. >=20 > I will be taking an action item to get the design team mailing list=20 > setup. They're still working using mail cc: chains. This will also provi= de > more openness to the work. >=20 > We'd also invite the authors of this draft to review the current git > repository of materials to see what other vendors have contributed as > materials toward modeling BFD and would invite them to contribute the draf= t > contents as another input to that repository. >=20 >> The BFD yang design team: >> - will be presenting at IETF91. >> - will have -00 posted, hopefully shortly after IETF91. >=20 > We'd like to encourage the design team to review Wang and Wu's proposal, > specifically the BFD modeling constructs. One of the more interesting > aspects, not yet decided at a larger IETF level, is integration with the > generic OAM framework that is starting to get attention in the LIME workin= g > group. In particular, the idea of "management domains". While we see tha= t > in this model there isn't a strong resemblance to the IEEE MEP model used > for Ethernet, there had been some prior concern about this. Operators in > the past have strongly indicated a beneficial aspect of BFD is is didn't > require configuration integration in such a model. >=20 > While the deadline for IETF is approaching, if it's possible to include so= me > analysis of the proposal, that'd be helpful. However, the chairs are very= > aware that the weeks just prior to a session are usually very busy. >=20 > -- Jeff & Nobo >=20 --Apple-Mail-737230BC-90BD-4BB9-9B6D-577BAE4D7DBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Jeff,

    The des= ign team will *try* to take a look at this new draft before the meeting. But= as you note, the weeks before the meeting tend to be the busiest and not th= e best time to take on new work. So thank you for that understanding.
    Mahesh Jethanandani

    On Oct 27= , 2014, at 10:09 AM, Jeffrey Haas <jhaa= s@pfrc.org> wrote:

    = On Mon, Oct 27, 2014 at 12:44:33PM +0000, Nobo Akiya (nobo) wrote:
    I see that you have just published draft-wa= ng-yang-bfd-oam-00.
    <= /span>
    The BFD WG has formed= a design team to define the yang models for the BFD technologies.

    http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgYangCo= ord

    Ensuring that multiple vendors ar= e collaborating from the initial design, although will require more time, wi= ll help significantly to come up with the definition that accommodates large= set of existing implementations.

    I'm sur= e the authors of draft-wang-yang-bfd-oam have spent time/effort to defining y= our version of the BFD yang models, and I do appreciate that. What will be h= elpful, instead of attempting to push draft-wang-yang-bfd-oam any further, i= s for you to provide your input and focus to helping the BFD yang design tea= m.

    I will be taking an action i= tem to get the design team mailing list
    setup.  They'r= e still working using mail cc: chains.  This will also providemore openness to the work.

    We'd als= o invite the authors of this draft to review the current git
    repository of materials to see what other vendors have contributed as
    materials toward modeling BFD and would invite them to contribute= the draft
    contents as another input to that repository.

    The BFD yang design t= eam:
    - will be presen= ting at IETF91.
    - wil= l have -00 posted, hopefully shortly after IETF91.

    We'd like to encourage the design team to review Wang a= nd Wu's proposal,
    specifically the BFD modeling constructs. &= nbsp;One of the more interesting
    aspects, not yet decided at= a larger IETF level, is integration with the
    generic OAM fr= amework that is starting to get attention in the LIME working
    group.  In particular, the idea of "management domains".  While w= e see that
    in this model there isn't a strong resemblance to= the IEEE MEP model used
    for Ethernet, there had been some p= rior concern about this.  Operators in
    the past have st= rongly indicated a beneficial aspect of BFD is is didn't
    req= uire configuration integration in such a model.

    <= span>While the deadline for IETF is approaching, if it's possible to include= some
    analysis of the proposal, that'd be helpful.  How= ever, the chairs are very
    aware that the weeks just prior to= a session are usually very busy.

    -- Jeff &= amp; Nobo

    = --Apple-Mail-737230BC-90BD-4BB9-9B6D-577BAE4D7DBC-- From nobody Mon Oct 27 13:30:15 2014 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 AD2B01AD472; Mon, 27 Oct 2014 13:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 w-SksqrSuf1G; Mon, 27 Oct 2014 13:29:56 -0700 (PDT) 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 473671AD477; Mon, 27 Oct 2014 13:29:56 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-cc-544e5354a488 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.89.05330.4535E445; Mon, 27 Oct 2014 15:14:45 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 16:29:49 -0400 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" Subject: RE: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Topic: [spring] FW: New Version Notification for draft-mirsky-mpls-bfd-directed-01.txt Thread-Index: AQHP8WQqkhU0lIa9iUGgsm0LPdqTnJxEZfrA Date: Mon, 27 Oct 2014 20:29:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B873677@eusaamb103.ericsson.se> References: <20141023195707.10809.79077.idtracker@ietfa.amsl.com> <7347100B5761DC41A166AC17F22DF1121B8656DB@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPoG5osF+IwdJTjBa3lq5ktZjdEW/x +c82RovjF34zOrB4TPm9kdVjyZKfTAFMUVw2Kak5mWWpRfp2CVwZf9pmsBScM684ubadsYHx p04XIweHhICJxP4dMV2MnECmmMSFe+vZQGwhgSOMErN/M3UxcgHZyxklfh7dwQySYBMwknix sYcdJCEiMJNR4uLEK2AJYYE4iflnnzKB2CIC8RI/Tq2Eso0kJtzvYAdZxiKgKnH0vThImFfA V+Luju+sEMtOMEpsnxYAYnMCxWcdXQY2khHooO+n1oCNYRYQl7j1ZD4TxKECEkv2nGeGsEUl Xj7+xwphK0lMWnqOFaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKW BYwsqxg5SotTy3LTjQw2MQKj45gEm+4Oxj0vLQ8xCnAwKvHwbnDxDRFiTSwrrsw9xCjNwaIk zjurdl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYa26RlXx4q1xQ3MRaWzkyaF5nk4C6/ kHPPwZCM2qip39++U7T7Gf4s2+PwbZFZV5jLdjadlHh276OZ7W4WIcFLnjeV/Lj99O55bPpk dO+bgteEy2u5lHJ26rr7xd84ZfSDUV6u7ODDq409mkHebJN3Se5ynf+Lt2LBR630uv2HT7jv lVTs+KLEUpyRaKjFXFScCABqg+55bwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UOB_TjZuaJO1uuiZmLln5ddSM2E 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, 27 Oct 2014 20:29:59 -0000 Hi Nobo, your time and thoughtful comments much appreciated. We'll work with draft-chen-mpls-bfd-enhancement authors closely after the m= eeting. I'll prepare update to the most straightforward changes and then will addre= ss those that need more discussion. Kind regards, Greg -----Original Message----- From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]=20 Sent: Sunday, October 26, 2014 2:31 PM To: Gregory Mirsky; rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org Subject: RE: [spring] FW: New Version Notification for draft-mirsky-mpls-bf= d-directed-01.txt Hi Greg, Jeff, et al, Please find below my comments on draft-mirsky-mpls-bfd-directed. 1) General - clarification I realize that there's no explicit code point overlap between draft-mirsky-= mpls-bfd-directed and draft-chen-mpls-bfd-enhancement: draft-mirsky-mpls-bf= d-directed is focused on Segment Routing whilst draft-chen-mpls-bfd-enhance= ment is focused on existing MPLS technologies. However, both documents are = describing how to program the reverse BFD path on the egress LSR via LSP Pi= ng. It would be nice to have one way of doing this, whether the technology = is Segment Routing or something else. Can authors of draft-mirsky-mpls-bfd-= directed and draft-chen-mpls-bfd-enhancement sync up to come up with a sing= le approach? 2) Section 1 - clarification The [RFC5880], [RFC5881], and the [RFC5883] established BFD protocol for IP networks and the [RFC5884] set rules of using BFD Asynchronous mode over IP/MPLS LSPs. The described problem is valid, but: - I don't think the same problem applies to RFC5881 (aka single-hop BFD), a= s sessions are bound to the interface being monitored. - The same problem is definitely not applicable to RFC5880 which is the bas= e protocol spec (i.e. does not define any data plane procedures). Perhaps you can list only RFC5883/RFC5884 or add some clarifications on why= RFC5880/RFC5881 are also listed. 3) Section 1 - clarification And because BFD control packets are not guaranteed to cross the same links and nodes in both directions detection of Loss of Continuity (LoC) defect in forward direction is not guaranteed or is free of positive negatives. I tripped over the words "... free of positive negatives" and had to read t= his multiple times. This is purely a nit comment, but I think what you want= to say here is "... free of false negatives"? 4) Section 2 s/BF D/BFD/ [NOTE] Remove space between 'F' and 'D'. 5) Section 2 - some text suggestion [OLD] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. [NEW] o if reverse direction is in Down state, the head-end node would not receive indication of forward direction failure from its far-end peer. The head-end node in this case will detect a problem due to lack of expected BFD control packets (i.e. detection timer expiry) instead of immediately receiving BFD control packets with explicit Down messages from the far-end peer. 6) Section 3.3 - clarification [snip] Initiator MAY include FECs corresponding to some or all of segments imposed in the label stack by the initiator to communicate the segments traversed. " When LSP ping is used to bootstrap BFD session this document updates this and defines that LSP Ping MUST include the FEC corresponding to the destination segment and SHOULD NOT include FECs corresponding to some or all of segment imposed by the initiator. Operationally such restriction would not cause any problem or uncertainty as LSP ping with FECs corresponding to some or all segments or traceroute may preceed the LSP ping that bootstraps the BFD session. [snip] Right now draft-kumarkini-mpls-spring-lsp-ping states, "MAY include other F= ECs". draft-mirsky-mpls-bfd-directed updates this by stating, "SHOULD NOT include= other FECs". It seems to me that the both aren't very different and the proposed mechani= sm will work whether this change is made or not. Can you clarify why this d= ocument makes above update? 7) General - additional reference With Segment Routing, there can be multiple SR-TE paths between the same so= urce/destination pairs, with subset of SR-TE paths ending with same SID. Th= us, there's a strong dependency from this mechanism described to draft-grma= s-bfd-rfc5884-clarifications. It might be a good idea that implementation o= f draft-mirsky-mpls-bfd-directed will require draft-grmas-bfd-rfc5884-clari= fications. Thanks! -Nobo > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Gregory=20 > Mirsky > Sent: Thursday, October 23, 2014 4:02 PM > To: rtg-bfd@ietf.org; mpls@ietf.org; spring@ietf.org > Subject: [spring] FW: New Version Notification for=20 > draft-mirsky-mpls-bfd- directed-01.txt >=20 > Dear All, > a new section 3.3 Bootstrapping BFD session with BFD Reverse Path over=20 > Segment Routed tunnel been added. Authors always welcome your comments=20 > and greatly appreciate suggestions. We're looking forward to continue=20 > discussion at WG meetings at IETF-91. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 23, 2014 12:57 PM > To: Gregory Mirsky; Jeff Tantsura; Gregory Mirsky; Jeff Tantsura; Ilya=20 > Varlashkin; Ilya Varlashkin > Subject: New Version Notification for=20 > draft-mirsky-mpls-bfd-directed-01.txt >=20 >=20 > A new version of I-D, draft-mirsky-mpls-bfd-directed-01.txt > has been successfully submitted by Greg Mirsky and posted to the IETF=20 > repository. >=20 > Name: draft-mirsky-mpls-bfd-directed > Revision: 01 > Title: Bidirectional Forwarding Detection (BFD) Directed Return > Path > Document date: 2014-10-23 > Group: Individual Submission > Pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-bfd= - > directed-01.txt > Status: https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd- > directed/ > Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-bfd-directed= -01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-bfd-= directed- > 01 >=20 > Abstract: > Bidirectional Forwarding Detection (BFD) is expected to monitor bi- > directional paths. When a BFD session monitors in its forward > direction an explicitly routed path there is a need to be able to > direct far-end BFD peer to use specific path as reverse direction of > the BFD session. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Mon Oct 27 18:26:44 2014 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 489081A8839 for ; Mon, 27 Oct 2014 18:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 ID-RnqyUeybn for ; Mon, 27 Oct 2014 18:26:39 -0700 (PDT) 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 47E5B1A19E5 for ; Mon, 27 Oct 2014 18:26:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ70697; Tue, 28 Oct 2014 01:26:37 +0000 (GMT) Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 01:26:37 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.231]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 09:26:30 +0800 From: wangzitao To: "Nobo Akiya (nobo)" , "draft-wang-yang-bfd-oam@tools.ietf.org" Subject: RE: Mail regarding draft-wang-yang-bfd-oam Thread-Topic: Mail regarding draft-wang-yang-bfd-oam Thread-Index: Ac/x4VJNTSl5wYKTR0SfmT9yU1MSpAAa4kUw Date: Tue, 28 Oct 2014 01:26:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2KeWoCvbKmba0p95ZSsGuNuM18Q 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, 28 Oct 2014 01:26:41 -0000 SGksIE5vYm86DQpBcG9sb2dpemUgZm9yIG15IHF1aWNrIHBvc3RpbmcuDQpJIGRpZG4ndCByZWFs aXplIHRoZXJlIHdhcyBkZXNpZ24gdGVhbSB0YXJnZXRpbmcgdG8gZG8gdGhpcyBqb2Igd2hlbiBJ IGNhbWUgdXAgdGhpcyBpZGVhIGFuZCB3cm90ZSB0aGlzIGRyYWZ0IHVubGVzcyBRaW4gcmVtaW5k ZWQgbWUgYXQgdGhlIGxhc3QgbWludXRlIGluIHRoZSBydGcteWFuZy1kaXNjdXNzaW9uIGxpc3Qu DQpJIGFtIGhhcHB5IHRvIGNvb3BlcmF0ZSB3aXRoIEJGRCBZQU5HIGRlc2lnbiB0ZWFtIGFuZCBw cm92aWRlIG91ciBpbnB1dC4NCkxldCBtZSBrbm93IHdobyB3aWxsIGJlIHRoZSBjb250YWN0IHBl cnNvbiBhbmQgSSBjYW4gZGlzY3VzcyB3aXRoIGhpbS4NCg0KUmVnYXJkcyENCi1NaWNoYWVsDQot LS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTm9ibyBBa2l5YSAobm9ibykgW21haWx0bzpub2Jv QGNpc2NvLmNvbV0gDQq3osvNyrG85DogMjAxNMTqMTDUwjI3yNUgMjA6NDUNCsrVvP7IyzogZHJh ZnQtd2FuZy15YW5nLWJmZC1vYW1AdG9vbHMuaWV0Zi5vcmcNCrOty806IHJ0Zy1iZmRAaWV0Zi5v cmcNCtb3zOI6IE1haWwgcmVnYXJkaW5nIGRyYWZ0LXdhbmcteWFuZy1iZmQtb2FtDQoNCkF1dGhv cnMsDQoNCkkgc2VlIHRoYXQgeW91IGhhdmUganVzdCBwdWJsaXNoZWQgZHJhZnQtd2FuZy15YW5n LWJmZC1vYW0tMDAuDQoNClRoZSBCRkQgV0cgaGFzIGZvcm1lZCBhIGRlc2lnbiB0ZWFtIHRvIGRl ZmluZSB0aGUgeWFuZyBtb2RlbHMgZm9yIHRoZSBCRkQgdGVjaG5vbG9naWVzLg0KDQpodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnWWFuZ0Nvb3JkDQoNCkVu c3VyaW5nIHRoYXQgbXVsdGlwbGUgdmVuZG9ycyBhcmUgY29sbGFib3JhdGluZyBmcm9tIHRoZSBp bml0aWFsIGRlc2lnbiwgYWx0aG91Z2ggd2lsbCByZXF1aXJlIG1vcmUgdGltZSwgd2lsbCBoZWxw IHNpZ25pZmljYW50bHkgdG8gY29tZSB1cCB3aXRoIHRoZSBkZWZpbml0aW9uIHRoYXQgYWNjb21t b2RhdGVzIGxhcmdlIHNldCBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuDQoNCkknbSBzdXJl IHRoZSBhdXRob3JzIG9mIGRyYWZ0LXdhbmcteWFuZy1iZmQtb2FtIGhhdmUgc3BlbnQgdGltZS9l ZmZvcnQgdG8gZGVmaW5pbmcgeW91ciB2ZXJzaW9uIG9mIHRoZSBCRkQgeWFuZyBtb2RlbHMsIGFu ZCBJIGRvIGFwcHJlY2lhdGUgdGhhdC4gV2hhdCB3aWxsIGJlIGhlbHBmdWwsIGluc3RlYWQgb2Yg YXR0ZW1wdGluZyB0byBwdXNoIGRyYWZ0LXdhbmcteWFuZy1iZmQtb2FtIGFueSBmdXJ0aGVyLCBp cyBmb3IgeW91IHRvIHByb3ZpZGUgeW91ciBpbnB1dCBhbmQgZm9jdXMgdG8gaGVscGluZyB0aGUg QkZEIHlhbmcgZGVzaWduIHRlYW0uDQoNClRoZSBCRkQgeWFuZyBkZXNpZ24gdGVhbToNCi0gd2ls bCBiZSBwcmVzZW50aW5nIGF0IElFVEY5MS4NCi0gd2lsbCBoYXZlIC0wMCBwb3N0ZWQsIGhvcGVm dWxseSBzaG9ydGx5IGFmdGVyIElFVEY5MS4NCg0KVGhhbmtzIQ0KDQotTm9ibywgYXMgdGhlIEJG RCBXRyBjby1jaGFpcg0KDQo= From nobody Mon Oct 27 20:59:31 2014 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 32C441A03A7 for ; Mon, 27 Oct 2014 20:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 2_PYUQz_GPAq for ; Mon, 27 Oct 2014 20:59:27 -0700 (PDT) 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 DF7FE1A039A for ; Mon, 27 Oct 2014 20:59:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ80026; Tue, 28 Oct 2014 03:59:25 +0000 (GMT) Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 03:59:24 +0000 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.231]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 11:59:15 +0800 From: wangzitao To: Jeffrey Haas Subject: RE: Mail regarding draft-wang-yang-bfd-oam Thread-Topic: Mail regarding draft-wang-yang-bfd-oam Thread-Index: Ac/x4VJNTSl5wYKTR0SfmT9yU1MSpP//lmqA//6TTHA= Date: Tue, 28 Oct 2014 03:59:15 +0000 Message-ID: References: <20141027140913.GB8111@pfrc> In-Reply-To: <20141027140913.GB8111@pfrc> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.131] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NwVEp4dJPihynGLcMuyvzGEol2I 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, 28 Oct 2014 03:59:29 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IEplZmZyZXkgSGFhcyBbbWFpbHRvOmpoYWFzQHBm cmMub3JnXSANCreiy83KsbzkOiAyMDE0xOoxMNTCMjfI1SAyMjowOQ0KytW8/sjLOiBydGctYmZk QGlldGYub3JnOyBkcmFmdC13YW5nLXlhbmctYmZkLW9hbUB0b29scy5pZXRmLm9yZw0Ks63LzTog ZHJhZnQtd2FuZy15YW5nLWJmZC1vYW1AdG9vbHMuaWV0Zi5vcmc7IHJ0Zy1iZmRAaWV0Zi5vcmcN Ctb3zOI6IFJlOiBNYWlsIHJlZ2FyZGluZyBkcmFmdC13YW5nLXlhbmctYmZkLW9hbQ0KDQpPbiBN b24sIE9jdCAyNywgMjAxNCBhdCAxMjo0NDozM1BNICswMDAwLCBOb2JvIEFraXlhIChub2JvKSB3 cm90ZToNCj4gSSBzZWUgdGhhdCB5b3UgaGF2ZSBqdXN0IHB1Ymxpc2hlZCBkcmFmdC13YW5nLXlh bmctYmZkLW9hbS0wMC4NCj4gDQo+IFRoZSBCRkQgV0cgaGFzIGZvcm1lZCBhIGRlc2lnbiB0ZWFt IHRvIGRlZmluZSB0aGUgeWFuZyBtb2RlbHMgZm9yIHRoZSBCRkQgdGVjaG5vbG9naWVzLg0KPiAN Cj4gaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z1lhbmdD b29yZA0KPiANCj4gRW5zdXJpbmcgdGhhdCBtdWx0aXBsZSB2ZW5kb3JzIGFyZSBjb2xsYWJvcmF0 aW5nIGZyb20gdGhlIGluaXRpYWwgZGVzaWduLCBhbHRob3VnaCB3aWxsIHJlcXVpcmUgbW9yZSB0 aW1lLCB3aWxsIGhlbHAgc2lnbmlmaWNhbnRseSB0byBjb21lIHVwIHdpdGggdGhlIGRlZmluaXRp b24gdGhhdCBhY2NvbW1vZGF0ZXMgbGFyZ2Ugc2V0IG9mIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cy4NCj4gDQo+IEknbSBzdXJlIHRoZSBhdXRob3JzIG9mIGRyYWZ0LXdhbmcteWFuZy1iZmQtb2Ft IGhhdmUgc3BlbnQgdGltZS9lZmZvcnQgdG8gZGVmaW5pbmcgeW91ciB2ZXJzaW9uIG9mIHRoZSBC RkQgeWFuZyBtb2RlbHMsIGFuZCBJIGRvIGFwcHJlY2lhdGUgdGhhdC4gV2hhdCB3aWxsIGJlIGhl bHBmdWwsIGluc3RlYWQgb2YgYXR0ZW1wdGluZyB0byBwdXNoIGRyYWZ0LXdhbmcteWFuZy1iZmQt b2FtIGFueSBmdXJ0aGVyLCBpcyBmb3IgeW91IHRvIHByb3ZpZGUgeW91ciBpbnB1dCBhbmQgZm9j dXMgdG8gaGVscGluZyB0aGUgQkZEIHlhbmcgZGVzaWduIHRlYW0uDQoNCkkgd2lsbCBiZSB0YWtp bmcgYW4gYWN0aW9uIGl0ZW0gdG8gZ2V0IHRoZSBkZXNpZ24gdGVhbSBtYWlsaW5nIGxpc3Qgc2V0 dXAuICBUaGV5J3JlIHN0aWxsIHdvcmtpbmcgdXNpbmcgbWFpbCBjYzogY2hhaW5zLiAgVGhpcyB3 aWxsIGFsc28gcHJvdmlkZSBtb3JlIG9wZW5uZXNzIHRvIHRoZSB3b3JrLg0KDQpXZSdkIGFsc28g aW52aXRlIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgdG8gcmV2aWV3IHRoZSBjdXJyZW50IGdp dCByZXBvc2l0b3J5IG9mIG1hdGVyaWFscyB0byBzZWUgd2hhdCBvdGhlciB2ZW5kb3JzIGhhdmUg Y29udHJpYnV0ZWQgYXMgbWF0ZXJpYWxzIHRvd2FyZCBtb2RlbGluZyBCRkQgYW5kIHdvdWxkIGlu dml0ZSB0aGVtIHRvIGNvbnRyaWJ1dGUgdGhlIGRyYWZ0IGNvbnRlbnRzIGFzIGFub3RoZXIgaW5w dXQgdG8gdGhhdCByZXBvc2l0b3J5Lg0KDQpbTWljaGFlbF06IFRoYW5rcyBmb3IgeW91ciBwb2lu dGluZy4NClllcywgd2Ugd2lsbCByZXZpZXcgdGhlIGxhdGVzdCBvdXRwdXQgbWF0ZXJpYWwgaW4g dGhlIGdpdCByZXBvc2l0b3J5IGFuZCB3b3VsZCBiZSBoYXBweSB0byBjb250cmlidXRlIGRyYWZ0 IGNvbnRlbnRzIGFzIGlucHV0IGlmIHlvdSB0aGluayBpdCB1c2VmdWwuDQo=