From nobody Sat Nov 1 07:26:53 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 794081A8868 for ; Sat, 1 Nov 2014 07:26:52 -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 uFkUnuq45b35 for ; Sat, 1 Nov 2014 07:26:50 -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 9B3901A002A for ; Sat, 1 Nov 2014 07:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1317; q=dns/txt; s=iport; t=1414852010; x=1416061610; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wliKCfaLpIdWxGcTnLltQm8ngTVNJpiwajfJrV89oPw=; b=A+uSmuOCMmvbXCeMBX3/c/oSFo+1wDtS3ly3BZm76RrGjDPUh6KNef3x Khrd8gPVbRPyP7BH0u8vs5a37WhLy5y0iFJuc745kvWWECgiWmrSZKWQz /XeE+idBrtKkUymCVm+kQV22ss8l8sTttpFhGmdGUF08ZNgOsOzBFDhrh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAETtVFStJA2K/2dsb2JhbABcgmsjVFgEzT6HTQKBFRYBAQEBAXILhAIBAQEEOksEAgEIEQQBAQsUCQcyFAkIAQEEEwgBiDgBDMlHAQEBAQEBAQECAQEBAQEBAQEakF84BoMngR4Fj3uCH40Yg02NSYQJg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,295,1413244800"; d="scan'208";a="368421328" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 01 Nov 2014 14:26:49 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sA1EQnh5002024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Nov 2014 14:26:49 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 1 Nov 2014 09:26:49 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: IETF91 BFD WG Agenda (Tentative) Thread-Topic: IETF91 BFD WG Agenda (Tentative) Thread-Index: Ac/wnYZzGbbdpvVpR7CQjZatyVomGAFQQIYg Date: Sat, 1 Nov 2014 14:26:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.113] 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/w7ZVDbUetGkGJYPDg-V0loRK0i0 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, 01 Nov 2014 14:26:52 -0000 Hello BFD WG, There has been no changes from the tentative BFD agenda. http://www.ietf.org/proceedings/91/agenda/agenda-91-bfd There is some buffer towards the end of the session, which we'll encourage = its usage for further BFD yang modeling discussions, unless there are other= topics raised/suggested. Question: Would any brave souls willing to server as: (1) note/minute taker (2) jabber scribe ?? Reminder: If you are presenting at IETF91 BFD WG, please send Jeff and I your slides = by no later than November 7th. Thanks! -Nobo and Jeff > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Saturday, October 25, 2014 5:56 PM > To: rtg-bfd@ietf.org > Subject: IETF91 BFD WG Agenda (Tentative) >=20 > Hello BFD WG, >=20 > Tentative IETF91 BFD WG agenda has been posted. >=20 > http://www.ietf.org/proceedings/91/agenda/agenda-91-bfd >=20 > Please look over and let Jeff and I know if we have missed anything. >=20 > If you are presenting, please send Jeff and I your slides by no longer th= an > November 7th. >=20 > Reminder: >=20 > 2014-10-27 (Monday): Internet Draft submission cut-off (for all drafts, > including -00) by UTC 23:59 >=20 > Thanks! >=20 > -Nobo and Jeff From nobody Thu Nov 6 14:31:11 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 7C9141AC3E7 for ; Thu, 6 Nov 2014 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 1Vo7xNoDaP4E for ; Thu, 6 Nov 2014 14:31:08 -0800 (PST) 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 30D6A1AC3E3 for ; Thu, 6 Nov 2014 14:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2138; q=dns/txt; s=iport; t=1415313069; x=1416522669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TlmW90c3+6etNLIyFtpokG4oLdHQe/VhiCVlljXNd6k=; b=QjR2jAd9DkLHzvY7cqlciGrPYijzDrT0LC5Wk4W8X/ABw9EQs2jEvKzM KH/ND4mY3NtJXBT0H2OFuct2b3xap6ilhglTFTrkNhc29DaJnsesZ/34k Kx8+7NNjYZi69OQxQcQWyLcrYYs04F9/3Y9GN9MBu9dyxcAGjHWp3yc9s 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFADj2W1StJA2D/2dsb2JhbABbgmsjgTHSfQKBIRYBAQEBAX2EAgEBAQMBOj8FCwIBCBYMFBAyJQEBBA4NiDAJAc81AQEBAQEBAQEBAQEBAQEBAQEBAQEYkGAxB4MtgR4BBJADgiGiTYN4gjSBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,328,1413244800"; d="scan'208";a="370078101" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2014 22:31:08 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA6MV6kM004065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Nov 2014 22:31:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 16:31:06 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K Subject: RE: draft-ietf-bfd-seamless-base-03 Thread-Topic: draft-ietf-bfd-seamless-base-03 Thread-Index: Ac/5y47ipSOBcrC9QU2LWlafKJUuuAAQ8T0A Date: Thu, 6 Nov 2014 22:31:05 +0000 Message-ID: References: <7457d0b951ce4be588f10303cce057ec@BLUPR05MB755.namprd05.prod.outlook.com> In-Reply-To: <7457d0b951ce4be588f10303cce057ec@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.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/hMYRPZWqdvuQXDoBU8kDoDyMOoc 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, 06 Nov 2014 22:31:09 -0000 Hi Santosh, Good question. > Sent: Thursday, November 06, 2014 9:16 AM > > In SBFD base draft we say >=20 > " The usage of the "Required Min Echo RX Interval" field is described > in Section 7.2.2 and Section 7.3.2. Because of the stateless nature > of SBFDReflector sessions, a value specified the "Required Min Echo > RX Interval" field in both directions is not very meaningful. Thus > it is RECOMMENDED that the "Required Min Echo RX Interval" field > simply be set to zero in both directions." >=20 >=20 > I understand that SBFD initiator sending echo Min RX interval as zero mak= es > sense as reflector will never send echo packet. But SBFD initiator may se= nd > echo packet and if SBFD reflector has a policy that it can't loop back th= e > packet on the same interface where it received or a global config says it= can > only entertain x rate of packets then do we need to communicate that to > Initiator? I am ask this because in BFD for SR it is using echo and contr= ol to > detect path going down. Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from. However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control packets i= t replies. Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packets it repli= es. In summary, I think we should clarify this by updating above texts to somet= hing along the line of: If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) { MUST set non-zero value in the "Required Min Echo RX Interval" field of= reply packets. } else { MUST set zero in the "Required Min Echo RX Interval" field of reply pac= kets. } What do you think? Thanks! -Nobo From nobody Thu Nov 6 19:27: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 5B3FA1A0074 for ; Thu, 6 Nov 2014 19:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 WHoeo1d8kgsz for ; Thu, 6 Nov 2014 19:27:12 -0800 (PST) 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 335471A0073 for ; Thu, 6 Nov 2014 19:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5810; q=dns/txt; s=iport; t=1415330833; x=1416540433; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4tX36ka1verAnBSNM8X3xX0jU7Ag4cWwOOjbNDR9yIw=; b=f1Jjy3+hWgbKBDcqQAp7uhXEamSlsCXSwZyuFyC+qE9mraQ8mkw/j/P2 CJbgtQ9GgtBWq+/5jXEU1oEayp7rmARjGgryWsnRcioIXU+6DRS3fHblg 3DBgjDxNVrvYRNhoHTEF+62XdFEQjlYeyLQABkVmnViZw9Trbz18cVtEh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAIAOQ6XFStJV2S/2dsb2JhbABbgw5UWQSDAsg2h00CHH8WAQEBAQF9hAIBAQEEIxE6CQIMBAIBCBEEAQEDAgYdAwICAjAUAQgIAgQOBQgBiDgNuROVewEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLY8zBisHBAKCcTaBHgWSJIRTiFE9gxGNUoQJg3hsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,329,1413244800"; d="scan'208";a="94311768" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 07 Nov 2014 03:27:12 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sA73RBvK028850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Nov 2014 03:27:11 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.48]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 21:27:11 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Santosh P K Subject: RE: 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+ypkangFD1rnC1p5wehltwgDVEENCAAOuYcA== Date: Fri, 7 Nov 2014 03:27:10 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3471EE32@xmb-rcd-x15.cisco.com> References: <20141003134634.31923.87610.idtracker@ietfa.amsl.com> <315041E4211CB84E86EF7C25A2AB583D346A9D9E@xmb-rcd-x15.cisco.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.70.183] 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/aoW-atB2e3Y6ZNq4rbfI32hFMk0 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, 07 Nov 2014 03:27:14 -0000 SGVsbG8gU2FudG9zaCwNCiAgUGxlYXNlIGZpbmQgcmVzcG9uc2VzIGlubGluZS4gUGVybWl0IG1l IHRvIGNvcHkgdGhlIEJGRCBXRyBtYWlsaW5nIGxpc3QuIEkgbG9vayBmb3J3YXJkIHRvIGhlYXJp bmcgeW91ciBjb21tZW50cyBvbiB0aGUgcmVzcG9uc2VzLg0KVGhhbmtzDQpQcmFzYWQgDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTYW50b3NoIFAgSyBbbWFpbHRvOnNhbnRv c2hwa0BqdW5pcGVyLm5ldF0gDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDYsIDIwMTQgNjo1 MiBQTQ0KVG86IFZlbmdhZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSkNClN1YmplY3Q6IFJF OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWdybWFzLWJmZC1yZmM1ODg0LWNs YXJpZmljYXRpb25zLTAwLnR4dA0KDQpQcmFzYWQsDQogICBJIHdhbnRlZCBmZXcgY2xhcmlmaWNh dGlvbiBpbiB0aGlzIGRyYWZ0LiANCg0KSW4gc2VjdGlvbiAyLjMgaXQgc2F5cw0KDQoiICAgICAg VGhlIEJGRCBzZXNzaW9uIG9uIHRoZSBlZ3Jlc3MgTFNSIE1BWSBiZSBncmFjZWZ1bGx5IHJlbW92 ZWQgYnkgdGhlDQogICAgICBpbmdyZXNzIExTUiBieSB1c2luZyB0aGUgQkZEIGRpYWdub3N0aWMg Y29kZSBBZG1pbkRvd24oNykNCiAgICAgIHNwZWNpZmllZCBpbiBbUkZDNTg4MF0uICBXaGVuIHRo ZSBpbmdyZXNzIExTUiB3YW50cyB0byBncmFjZWZ1bGx5DQogICAgICByZW1vdmUgYSBzZXNzaW9u LCBpdCBNQVkgdHJhbnNtaXQgQkZEIHBhY2tldHMgY29udGFpbmluZyB0aGUNCiAgICAgIGRpYWdu b3N0aWMgY29kZSBBZG1pbkRvd24oNykgZGV0ZWN0TXVsdGlwbGllciBudW1iZXIgb2YgdGltZXMu DQogICAgICBVcG9uIHJlY2VpdmluZyBzdWNoIGEgcGFja2V0LCB0aGUgZWdyZXNzIExTUiBNQVkg cmVtb3ZlIHRoZSBCRkQNCiAgICAgIHNlc3Npb24gZ3JhY2VmdWxseSwgd2l0aG91dCB0cmlnZ2Vy aW5nIGEgY2hhbmdlIG9mIHN0YXRlLg0KDQogICBFZCBOb3RlOiBUaGUgcHJvY2VkdXJlcyB0byBi ZSBmb2xsb3dlZCBhdCB0aGUgZWdyZXNzIExTUiB3aGVuIHRoZSBCRkQNCiAgIHNlc3Npb24gbmV2 ZXIgdHJhbnNpdGlvbnMgdG8gVVAgZnJvbSBET1dOIHN0YXRlIGFyZSB5ZXQgdG8gYmUNCiAgIGNs YXJpZmllZCAiDQoNCg0KV2hlbiBBRE1JTkRPV04gcGFja2V0IGlzIHJlY2VpdmVkIHdoeSBpcyBp dCBtZW50aW9uZWQgdGhhdCBlZ3Jlc3MgbWF5IG5vdCBnbyBkb3duIGFuZCBjYW4gcmVtb3ZlIHRo ZSBCRkQgc2Vzc2lvbj8gSXQgY2FuIGdvIGRvd24gYW5kIGNhbiByZW1vdmUgdGhlIHNlc3Npb24g cmlnaHQ/IEJGRCBzZXNzaW9uIG9uIGVncmVzcyBjYW4gc2VuZCBBRE1JTkRPV04gcmVjZWl2ZWQg c3RhdGUgdG8gaXRzIGNsaWVudD8NCkdWUDE+IFdoZW4gdGhlIExTUiBlZ3Jlc3MgcmVjZWl2ZXMg YSBCRkQgcGFja2V0IHdpdGggQWRtaW5Eb3duIGRpYWdub3N0aWMgY29kZSwgaXQgZG9lcyBub3Qg dGFrZSB0aGUgYWRqYWNlbmN5IGRvd24uIEluIG90aGVyIHdvcmRzLCB0aGlzIGlzIHRoZSBlcXVp dmFsZW50IG9mIHRoZSBhZGphY2VuY3kgYmVpbmcgbm8gbG9uZ2VyIHRyYWNrZWQgYnkgQkZELiBI ZW5jZSB0aGUgYWJvdmUgdGV4dC4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBhcmUgc3RpbGwg bm90IGNvbnZpbmNlZCBhYm91dCB0aGUgY2xhcml0eS4NCkFuZCBJIGRpZCBub3QgdW5kZXJzdGFu ZCB0aGF0IEVkIG5vdGU6KSBDYW4geW91IHBsZWFzZSBjYWxyaWZ5Pw0KR1ZQMT4gVGhlIGNhc2Ug d2hlcmUgYSBwb3NzaWJsZSBzdGFydmF0aW9uIG9mIHJlc291cmNlcyBjYW4gaGFwcGVuIGF0IHRo ZSBMU1IgZWdyZXNzIGR1ZSB0byBtYW55IHBlbmRpbmcgQkZEIGJvb3RzdHJhcCByZXF1ZXN0cyAo d2hlcmUgdGhlIEJGRCBzZXNzaW9uIG5ldmVyIHRyYW5zaXRpb25zIHRvIFVQIHN0YXRlIGNhdXNp bmcgc29tZSByZXNvdXJjZXMgbGlrZSBtZW1vcnksIHBwcyBidWRnZXQgZXRjIHRvIGxpZSB1bnVz ZWQpIG1heSBuZWVkIGRpc2N1c3Npb24uIA0KDQpUaGFua3MNClNhbnRvc2ggUCBLICANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdGctYmZkIFttYWlsdG86cnRnLWJm ZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmVuZ2FkYSANCj4gUHJhc2FkIEdvdmlu ZGFuICh2ZW5nZ292aSkNCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDAzLCAyMDE0IDk6MjkgUE0N Cj4gVG86IHJ0Zy1iZmRAaWV0Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IGthbHlhbmkucmFq YXJhbWFuQGVyaWNzc29uLmNvbQ0KPiBTdWJqZWN0OiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1ncm1hcy1iZmQtcmZjNTg4NC0gDQo+IGNsYXJpZmljYXRpb25zLTAwLnR4 dA0KPiANCj4gSGVsbG8gYWxsLA0KPiAgIEEgbmV3IGRyYWZ0IChkcmFmdC1ncm1hcy1iZmQtcmZj NTg4NC1jbGFyaWZpY2F0aW9ucykgaGFzIGJlZW4gDQo+IHN1Ym1pdHRlZCBiYXNlZCBvbiBkaXNj dXNzaW9ucyBhdCBJRVRGLTkwIGZvciANCj4gZHJhZnQtdmdvdmluZGFuLW1wbHMtZXh0ZW5kZWQt YmZkLWRpc2MtDQo+IHRsdi4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgbGF0dGVyIHdpbGwgYmUgZGlz Y29udGludWVkLiBDb21tZW50cy8gDQo+IFJldmlld3MgYXJlIHdlbGNvbWUgZm9yIGRyYWZ0LWdy bWFzLWJmZC1yZmMtNTg4NC1jbGFyaWZpY2F0aW9ucy4NCj4gLSBBdXRob3JzDQo+IA0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2Jl ciAwMywgMjAxNCA3OjE3IFBNDQo+IFRvOiBOb2JvIEFraXlhIChub2JvKTsgU2FtIEFsZHJpbjsg R3JlZyBNaXJza3k7IEdyZWdvcnkgTWlyc2t5OyANCj4gS2FseWFuaSBSYWphcmFtYW47IFZlbmdh ZGEgUHJhc2FkIEdvdmluZGFuICh2ZW5nZ292aSk7IE5vYm8gQWtpeWEgDQo+IChub2JvKTsgVmVu Z2FkYSBQcmFzYWQgR292aW5kYW4gKHZlbmdnb3ZpKTsgS2FseWFuaSBSYWphcmFtYW47IFNhbSAN Cj4gQWxkcmluDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRy YWZ0LWdybWFzLWJmZC1yZmM1ODg0LWNsYXJpZmljYXRpb25zLQ0KPiAwMC50eHQNCj4gDQo+IA0K PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtY2xhcmlmaWNh dGlvbnMtMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVmVuZ2Fk YSBQcmFzYWQgR292aW5kYW4gYW5kIHBvc3RlZCANCj4gdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IE5hbWU6CQlkcmFmdC1ncm1hcy1iZmQtcmZjNTg4NC1jbGFyaWZpY2F0aW9ucw0KPiBS ZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlDbGFyaWZpY2F0aW9ucyB0byBSRkMgNTg4NA0KPiBEb2N1 bWVudCBkYXRlOgkyMDE0LTEwLTAzDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ IFBhZ2VzOgkJNg0KPiBVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtDQo+IGNsYXJpZmljYXRpb25zLTAwLnR4 dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZ3JtYXMtYmZkLXJmYzU4ODQtDQo+IGNsYXJpZmljYXRpb25zLw0KPiBIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3JtYXMtYmZkLXJmYzU4ODQtDQo+ IGNsYXJpZmljYXRpb25zLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1l bnQgY2xhcmlmaWVzIHRoZSBwcm9jZWR1cmVzIGZvciBlc3RhYmxpc2hpbmcsIG1haW50YWluaW5n DQo+ICAgIGFuZCByZW1vdmluZyBtdWx0aXBsZSwgY29uY3VycmVudCBCRkQgc2Vzc2lvbnMgZm9y IGEgZ2l2ZW4gPE1QTFMgTFNQLA0KPiAgICBGRUM+IGRlc2NyaWJlZCBpbiBSRkM1ODg0Lg0KPiAN Cj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Nov 6 21:47:52 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 986F31ACEEB for ; Thu, 6 Nov 2014 21:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 OwFeS58zIdEK for ; Thu, 6 Nov 2014 21:47:48 -0800 (PST) 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 5E8EB1A1A15 for ; Thu, 6 Nov 2014 21:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7453; q=dns/txt; s=iport; t=1415339268; x=1416548868; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=399l5amp9sMet1b0HeoikNVGRC2okXedrUQ5v9mw5PI=; b=iqGjt1z1kemSP3/zPs/bfhCyGzIytjSs1xDk+yTdGD7cl7a0ZMqJCqf1 mGCv/fb8DSSQ1dAwh+zJ1c2Q/IiD0k265CdBShwG3lsM5l7YPRafQHza/ xCOEp/GHnpt0Ya4wnk0zniKrcdW5mlQ0zIJYXE+CvwO5ac1sVk2oQvVJP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFALBbXFStJV2Y/2dsb2JhbABbgkhGgS0E0w0CgR0WAQEBAQF9hAIBAQEEeRIBCBEDAQEBKCYTFAkIAQEEAQ0FiEHPCwEBAQEBAQEBAQEBAQEBAQEBAQEBAReRABEHhEsFkAOCIQOLb5Zbg3lsgUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,329,1413244800"; d="scan'208,217"; a="94330523" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 07 Nov 2014 05:47:47 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA75llsw003952 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Nov 2014 05:47:47 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.74]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 23:47:47 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Santosh P K Subject: Re: draft-ietf-bfd-seamless-base-03 Thread-Topic: draft-ietf-bfd-seamless-base-03 Thread-Index: Ac/5y47ipSOBcrC9QU2LWlafKJUuuAAQ8T0AACfamQA= Date: Fri, 7 Nov 2014 05:47:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.238] Content-Type: multipart/alternative; boundary="_000_D0825ACD27367mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gbKUbNqUJ22iiiEHxOH8grloJ18 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, 07 Nov 2014 05:47:50 -0000 --_000_D0825ACD27367mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Sounds perfect. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Friday 7 November 2014 4:01 AM To: Santosh P K > Cc: "rtg-bfd@ietf.org" > Subject: RE: draft-ietf-bfd-seamless-base-03 Hi Santosh, Good question. Sent: Thursday, November 06, 2014 9:16 AM In SBFD base draft we say " The usage of the "Required Min Echo RX Interval" field is described in Section 7.2.2 and Section 7.3.2. Because of the stateless nature of SBFDReflector sessions, a value specified the "Required Min Echo RX Interval" field in both directions is not very meaningful. Thus it is RECOMMENDED that the "Required Min Echo RX Interval" field simply be set to zero in both directions." I understand that SBFD initiator sending echo Min RX interval as zero makes sense as reflector will never send echo packet. But SBFD initiator may send echo packet and if SBFD reflector has a policy that it can't loop back the packet on the same interface where it received or a global config says it c= an only entertain x rate of packets then do we need to communicate that to Initiator? I am ask this because in BFD for SR it is using echo and control= to detect path going down. Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from. However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control packets i= t replies. Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packets it repli= es. In summary, I think we should clarify this by updating above texts to somet= hing along the line of: If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) { MUST set non-zero value in the "Required Min Echo RX Interval" field of= reply packets. } else { MUST set zero in the "Required Min Echo RX Interval" field of reply pac= kets. } What do you think? Thanks! -Nobo --_000_D0825ACD27367mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9932E03E767F7C4F81081C75B7441B81@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Sounds perfect.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Friday 7 November 2014 4:01 A= M
To: Santosh P K <santoshpk@juniper.net>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: draft-ietf-bfd-seamles= s-base-03

Hi Santosh,

Good question.

Sent: Thursday, November 06, 2014 9:16 AM

In SBFD base draft we say
" The usage of the "Required Min Echo RX Interval" fiel= d is described
    in Section 7.2.2 and Section 7.3.2.  = ;Because of the stateless nature
    of SBFDReflector sessions, a value specified t= he "Required Min Echo
    RX Interval" field in both directions is = not very meaningful.  Thus
    it is RECOMMENDED that the "Required Min = Echo RX Interval" field
    simply be set to zero in both directions."= ;
I understand that SBFD initiator sending echo Min RX interval as zero = makes
sense as reflector will never send echo packet. But SBFD initiator may= send
echo packet and if SBFD reflector has a policy that it can't loop back= the
packet on the same interface where it received or a global config says= it can
only entertain x rate of packets then do we need to communicate that t= o
Initiator? I am ask this because in BFD for SR it is using echo and co= ntrol to
detect path going down.

Just to clarify, there is no requirement that that SBFDReflector must = loop back S-BFD echo packets on the same interface which it received from.<= /div>

However, I do agree that it would be beneficial for SBFDReflector to i= ndicate that it is capable of looping backing S-BFD echo packets or not via= the use of "Required Min Echo RX Interval" field in the S-BFD co= ntrol packets it replies.

Although I do not think SBFDReflector should keep track of how much/ma= ny S-BFD echo packets it's looping back and reflect some suggested value in= the "Required Min Echo RX Interval" field in the S-BFD control p= ackets it replies.

In summary, I think we should clarify this by updating above texts to = something along the line of:

If (SBFDReflector is hosted on a device that supports looping back of = S-BFD echo packets) {
    MUST set non-zero value in the "Required = Min Echo RX Interval" field of reply packets.
} else {
    MUST set zero in the "Required Min Echo R= X Interval" field of reply packets.
}

What do you think?

Thanks!

-Nobo


--_000_D0825ACD27367mmudigonciscocom_-- From nobody Fri Nov 7 13:53: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 CB5051A1B56 for ; Fri, 7 Nov 2014 13:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qKzVMsd3YMq for ; Fri, 7 Nov 2014 13:53:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:736]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A543E1A0006 for ; Fri, 7 Nov 2014 13:53:32 -0800 (PST) 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.1.11.14; Fri, 7 Nov 2014 21:53:09 +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.01.0011.000; Fri, 7 Nov 2014 21:53:09 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" Subject: RE: draft-ietf-bfd-seamless-base-03 Thread-Topic: draft-ietf-bfd-seamless-base-03 Thread-Index: Ac/5y47ipSOBcrC9QU2LWlafKJUuuAAQ8T0AADF5CdM= Date: Fri, 7 Nov 2014 21:53:09 +0000 Message-ID: References: <7457d0b951ce4be588f10303cce057ec@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: [::] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB756; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(41574002)(189002)(76104003)(24454002)(57704003)(51704005)(377454003)(77156002)(122556002)(62966003)(110136001)(64706001)(46102003)(54356999)(76176999)(50986999)(20776003)(101416001)(21056001)(4396001)(31966008)(33646002)(92726001)(92566001)(40100003)(99396003)(120916001)(107046002)(95246002)(105586002)(87936001)(86362001)(19580405001)(95666004)(99286002)(19580395003)(97736003)(230783001)(19625215002)(106356001)(63666004)(2656002)(16236675004); 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_n7j2oqi6tp6llfaieadojpqh1415396741477emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Oto9q_R3hx2O4fo0VHEGR8ppsc0 Cc: rtg-bfd 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, 07 Nov 2014 21:53:35 -0000 --_000_n7j2oqi6tp6llfaieadojpqh1415396741477emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Nobo, This looks perfect. Thanks a lot. Thanks Santosh P K Sent from my Xiaomi On Nov 7, 2014 4:01 AM, "Nobo Akiya (nobo)" wrote: Hi Santosh, Good question. > Sent: Thursday, November 06, 2014 9:16 AM > > In SBFD base draft we say > > " The usage of the "Required Min Echo RX Interval" field is described > in Section 7.2.2 and Section 7.3.2. Because of the stateless nature > of SBFDReflector sessions, a value specified the "Required Min Echo > RX Interval" field in both directions is not very meaningful. Thus > it is RECOMMENDED that the "Required Min Echo RX Interval" field > simply be set to zero in both directions." > > > I understand that SBFD initiator sending echo Min RX interval as zero mak= es > sense as reflector will never send echo packet. But SBFD initiator may se= nd > echo packet and if SBFD reflector has a policy that it can't loop back th= e > packet on the same interface where it received or a global config says it= can > only entertain x rate of packets then do we need to communicate that to > Initiator? I am ask this because in BFD for SR it is using echo and contr= ol to > detect path going down. Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from. However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control packets i= t replies. Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packets it repli= es. In summary, I think we should clarify this by updating above texts to somet= hing along the line of: If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) { MUST set non-zero value in the "Required Min Echo RX Interval" field of= reply packets. } else { MUST set zero in the "Required Min Echo RX Interval" field of reply pac= kets. } What do you think? Thanks! -Nobo --_000_n7j2oqi6tp6llfaieadojpqh1415396741477emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Nobo,
    This looks perfect. Thanks a lot.

Thanks
Santosh P K

Sent from my Xiaomi

On Nov 7, 2014 4:01 AM, "Nobo Akiya (nobo)"= ; <nobo@cisco.com> wrote:
Hi Santosh,

Good question.

> Sent: Thursday, November 06, 2014 9:16 AM
>
> In SBFD base draft we say
>
> " The usage of the "Required Min Echo RX Interval" fiel= d is described
>    in Section 7.2.2 and Section 7.3.2.  Because of= the stateless nature
>    of SBFDReflector sessions, a value specified the &qu= ot;Required Min Echo
>    RX Interval" field in both directions is not ve= ry meaningful.  Thus
>    it is RECOMMENDED that the "Required Min Echo R= X Interval" field
>    simply be set to zero in both directions."
>
>
> I understand that SBFD initiator sending echo Min RX interval as zero = makes
> sense as reflector will never send echo packet. But SBFD initiator may= send
> echo packet and if SBFD reflector has a policy that it can't loop back= the
> packet on the same interface where it received or a global config says= it can
> only entertain x rate of packets then do we need to communicate that t= o
> Initiator? I am ask this because in BFD for SR it is using echo and co= ntrol to
> detect path going down.

Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from.

However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control= packets it replies.

Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packet= s it replies.

In summary, I think we should clarify this by updating above texts to somet= hing along the line of:

If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) {
    MUST set non-zero value in the "Required Min Echo R= X Interval" field of reply packets.
} else {
    MUST set zero in the "Required Min Echo RX Interval= " field of reply packets.
}

What do you think?

Thanks!

-Nobo
 --_000_n7j2oqi6tp6llfaieadojpqh1415396741477emailandroidcom_-- From nobody Fri Nov 7 16:15: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 64F0B1A0035 for ; Fri, 7 Nov 2014 16:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -113.58 X-Spam-Level: X-Spam-Status: No, score=-113.58 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.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 4Brcs7rLBWmL for ; Fri, 7 Nov 2014 16:15:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4A01A000E for ; Fri, 7 Nov 2014 16:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10521; q=dns/txt; s=iport; t=1415405748; x=1416615348; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ErToL13S0mFJvlZzDW0e+PpSWzd58hCwH0eu/InX7Pg=; b=mg3Hu8QioPxQYMRUpwuhD8HRVevjJapOG/JgKm5N0Gb3VMoRvjEBTQcG jRl6DFZI38I4NZYst8Vhc17tH9dTe8FMwxWmBw8+CUAC0xegR7yp7tBAP CJufm6tWdoXgxJHBD19SC1WAqvh9FxXLIKejoRMVmkMHcLueRo3E+6h3e s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFABZgXVStJA2E/2dsb2JhbABbgkgjI1RZBNMpAoEaFgEBAQEBfYQCAQEBAwEtTAULAgEIEQQBAQsdBzIUCQgBAQQOBQiIMAkBzzQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkGAxBgGDLYEeBZAEgiONJZEhhAmDeWyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208,217";a="367307131" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2014 00:15:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sA80FkQ9019216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 00:15:46 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; Fri, 7 Nov 2014 18:15:46 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K Subject: RE: draft-ietf-bfd-seamless-base-03 Thread-Topic: draft-ietf-bfd-seamless-base-03 Thread-Index: Ac/5y47ipSOBcrC9QU2LWlafKJUuuAAQ8T0AADF5CdMABPY8IA== Date: Sat, 8 Nov 2014 00:15:45 +0000 Message-ID: References: <7457d0b951ce4be588f10303cce057ec@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.254.83] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F51D42Bxmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Rza8oYBw1se9tV-F8mgDDVz8NOI Cc: rtg-bfd 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, 08 Nov 2014 00:15:49 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F51D42Bxmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, Santosh, Many thanks for your input. Will cook up a proper text and put it in the ne= xt revision. Thanks! -Nobo From: Santosh P K [mailto:santoshpk@juniper.net] Sent: Friday, November 07, 2014 4:53 PM To: Nobo Akiya (nobo) Cc: rtg-bfd Subject: RE: draft-ietf-bfd-seamless-base-03 Hello Nobo, This looks perfect. Thanks a lot. Thanks Santosh P K Sent from my Xiaomi On Nov 7, 2014 4:01 AM, "Nobo Akiya (nobo)" > wrote: Hi Santosh, Good question. > Sent: Thursday, November 06, 2014 9:16 AM > > In SBFD base draft we say > > " The usage of the "Required Min Echo RX Interval" field is described > in Section 7.2.2 and Section 7.3.2. Because of the stateless nature > of SBFDReflector sessions, a value specified the "Required Min Echo > RX Interval" field in both directions is not very meaningful. Thus > it is RECOMMENDED that the "Required Min Echo RX Interval" field > simply be set to zero in both directions." > > > I understand that SBFD initiator sending echo Min RX interval as zero mak= es > sense as reflector will never send echo packet. But SBFD initiator may se= nd > echo packet and if SBFD reflector has a policy that it can't loop back th= e > packet on the same interface where it received or a global config says it= can > only entertain x rate of packets then do we need to communicate that to > Initiator? I am ask this because in BFD for SR it is using echo and contr= ol to > detect path going down. Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from. However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control packets i= t replies. Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packets it repli= es. In summary, I think we should clarify this by updating above texts to somet= hing along the line of: If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) { MUST set non-zero value in the "Required Min Echo RX Interval" field of= reply packets. } else { MUST set zero in the "Required Min Echo RX Interval" field of reply pac= kets. } What do you think? Thanks! -Nobo --_000_CECE764681BE964CBE1DFF78F3CDD3943F51D42Bxmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik, Santosh,<= /o:p>

 <= /p>

Many thanks for your inpu= t. Will cook up a proper text and put it in the next revision.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

From: Santosh P K [mailto:santoshpk@juniper.net]
Sent: Friday, November 07, 2014 4:53 PM
To: Nobo Akiya (nobo)
Cc: rtg-bfd
Subject: RE: draft-ietf-bfd-seamless-base-03

 

Hello Nobo,
    This looks perfect. Thanks a lot.

Thanks
Santosh P K

Sent from my Xiaomi

On Nov 7, 2014 4:01 AM, "Nobo Akiya (nobo)"= ; <nobo@cisco.com> wrote:<= /o:p>

Hi Santosh,

Good question.

> Sent: Thursday, November 06, 2014 9:16 AM
>
> In SBFD base draft we say
>
> " The usage of the "Required Min Echo RX Interval" fiel= d is described
>    in Section 7.2.2 and Section 7.3.2.  Because of= the stateless nature
>    of SBFDReflector sessions, a value specified the &qu= ot;Required Min Echo
>    RX Interval" field in both directions is not ve= ry meaningful.  Thus
>    it is RECOMMENDED that the "Required Min Echo R= X Interval" field
>    simply be set to zero in both directions."
>
>
> I understand that SBFD initiator sending echo Min RX interval as zero = makes
> sense as reflector will never send echo packet. But SBFD initiator may= send
> echo packet and if SBFD reflector has a policy that it can't loop back= the
> packet on the same interface where it received or a global config says= it can
> only entertain x rate of packets then do we need to communicate that t= o
> Initiator? I am ask this because in BFD for SR it is using echo and co= ntrol to
> detect path going down.

Just to clarify, there is no requirement that that SBFDReflector must loop = back S-BFD echo packets on the same interface which it received from.

However, I do agree that it would be beneficial for SBFDReflector to indica= te that it is capable of looping backing S-BFD echo packets or not via the = use of "Required Min Echo RX Interval" field in the S-BFD control= packets it replies.

Although I do not think SBFDReflector should keep track of how much/many S-= BFD echo packets it's looping back and reflect some suggested value in the = "Required Min Echo RX Interval" field in the S-BFD control packet= s it replies.

In summary, I think we should clarify this by updating above texts to somet= hing along the line of:

If (SBFDReflector is hosted on a device that supports looping back of S-BFD= echo packets) {
    MUST set non-zero value in the "Required Min Echo R= X Interval" field of reply packets.
} else {
    MUST set zero in the "Required Min Echo RX Interval= " field of reply packets.
}

What do you think?

Thanks!

-Nobo

--_000_CECE764681BE964CBE1DFF78F3CDD3943F51D42Bxmbalnx01ciscoc_-- From nobody Thu Nov 13 20:04:13 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 0CF131A00EB for ; Thu, 13 Nov 2014 20:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 UXaZNoS9vdkr for ; Thu, 13 Nov 2014 20:04:09 -0800 (PST) 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 601DB1A00BD for ; Thu, 13 Nov 2014 20:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1276; q=dns/txt; s=iport; t=1415937851; x=1417147451; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=LG7A5lmikUIKPph28bb9x96QGRW2KvOjWF6jeNQHO6k=; b=j07+Ai2+sySN2WCmhxkxOTcUEbiY9R4Rig1DfXixbV2+MT85CHkCmdkZ JLmJlUXRnMfSi3v+mnUXbdJ6mv7fxtuR01bag0VnrmCi0aVDYGPVuvOHC 9YwhZpaAgU+CDH3zBOMm9SFZnaEo1u5NvBEPtG0ScNAatLeF1uR6iHDB8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAMN+ZVStJV2T/2dsb2JhbABbgmsjgTLUTwKBIhYBAQEBAXILhAQBBDpRASoUQiAGAQQbiDkBqnimDQEBAQEGAQEBAQEdkHGDZYEeBZAfgiiNOZE8hAqDfII1gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,383,1413244800"; d="scan'208";a="372094718" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2014 04:04:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAE448Y2031616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Nov 2014 04:04:08 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; Thu, 13 Nov 2014 22:04:08 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRA== Date: Fri, 14 Nov 2014 04:04:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.85] 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/RlKU2SBAP4hI3zY4Apac6E0F6Pg 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, 14 Nov 2014 04:04:11 -0000 [Speaking as an individual S-BFD contributor] Hi BFD WG, There were couple of questions I need your input on draft-akiya-bfd-seamles= s-alert-discrim. (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless-u= se-case? My opinion is yes. Once the "extended" S-BFD use cases have been incorporat= ed into draft-ietf-bfd-seamless-use-case, then we should try to move draft-= ietf-bfd-seamless-use-case forward. How does the WG feel about this? (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamless= -base? My opinion is no . Instead we should position this as an optional feature o= f S-BFD (hence separate document than the base), especially considering we = likely need to think through additional security concerns raised by this. A question was raised by Greg on how does a node find out if the target sup= ports the optional alert discriminator or not. We can define a mandatory di= agnostic value that must be implemented when the alert discriminator is imp= lemented. One can send an S-BFD control packet with the alert discriminator= with this diagnostic value to check if the target supports the alert discr= iminator mechanism. How does the WG feel about this? Thanks! -Nobo From nobody Fri Nov 14 14:06: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 D06671A1A56 for ; Fri, 14 Nov 2014 14:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrESPpeuPfDu for ; Fri, 14 Nov 2014 14:06:38 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715B41A1A5B for ; Fri, 14 Nov 2014 14:06:38 -0800 (PST) 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.1.16.15; Fri, 14 Nov 2014 22:06:34 +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.01.0016.006; Fri, 14 Nov 2014 22:06:34 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRAAlrrkA Date: Fri, 14 Nov 2014 22:06:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB756; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB756; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(120916001)(99396003)(101416001)(99286002)(31966008)(87936001)(33646002)(230783001)(561944003)(106356001)(62966003)(77156002)(86362001)(40100003)(21056001)(95666004)(105586002)(107046002)(2656002)(107886001)(76576001)(46102003)(92566001)(122556002)(97736003)(66066001)(74316001)(4396001)(76176999)(50986999)(54356999)(20776003)(64706001)(108616004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB756; H:BLUPR05MB755.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:3; 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/a9jAaMeKbdjZ8k0rwv6l4DrKZ-M 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, 14 Nov 2014 22:06:45 -0000 Nobo, =20 > (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless= - > use-case? >=20 > My opinion is yes. Once the "extended" S-BFD use cases have been > incorporated into draft-ietf-bfd-seamless-use-case, then we should try to > move draft-ietf-bfd-seamless-use-case forward. >=20 > How does the WG feel about this? >=20 I agree.=20 >=20 > (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamle= ss- > base? >=20 > My opinion is no . Instead we should position this as an optional feature= of S- > BFD (hence separate document than the base), especially considering we > likely need to think through additional security concerns raised by this. >=20 > A question was raised by Greg on how does a node find out if the target > supports the optional alert discriminator or not. We can define a mandato= ry > diagnostic value that must be implemented when the alert discriminator is > implemented. One can send an S-BFD control packet with the alert > discriminator with this diagnostic value to check if the target supports = the > alert discriminator mechanism. >=20 > How does the WG feel about this? >=20 I agree with making this as optional feature and not merging with use case = document. This also assumes that all the nodes on the path MUST have S-BFD = implemented. What even if we mandate diag bit and intermediate router does = not understand that diag bit as that box is with old BFD implementation? Th= ere should be something suggested in this document that ingress should try = for only finite time or retries? Thanks Santosh P K=20 From nobody Fri Nov 14 14:23: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 5DD991ACFAF for ; Fri, 14 Nov 2014 14:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 4Xn2ctRMzh_Q for ; Fri, 14 Nov 2014 14:22:52 -0800 (PST) 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 E0B6F1ACFD5 for ; Fri, 14 Nov 2014 14:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2594; q=dns/txt; s=iport; t=1416003772; x=1417213372; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WTMXBiCYRMoJoKtaNDxLjb5ClzXWjEDHisTYNULCmPk=; b=f7pLFsmSA2M8cwkAhFICaCCxkLcd3rqbaYsXjFglr+Kb5RQXeP7uErlG xuhbeqKWv3FyGwY7DWa6y7MTBVFWzBz9lgg9Y4ILhlyyR9Wg6Qjbv/qdx jlzzD7H18iYVTriu6MCp6wl5+M//CLNjlo+jHm5rqLEaYZipinJXScAT9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAFuAZlStJV2a/2dsb2JhbABbgmsjgS4E1E8CgRwWAQEBAQF9hAIBAQEDATpLBAIBCBEEAQELFAkHMhQJAwUBAQQBEgiIMAkB0hcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkHE4BoMngR4FkB+CKI05g1SRcoN8bYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="scan'208";a="96793241" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 14 Nov 2014 22:22:51 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAEMMpUG012300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 22:22:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 16:22:50 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "rtg-bfd@ietf.org" Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRAAlrrkAAACJhKA= Date: Fri, 14 Nov 2014 22:22:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.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/Ex2nyHHy8cL0NI1lv7q1WDgJJfY 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, 14 Nov 2014 22:22:54 -0000 Hi Santosh, Many thanks for comments. Speaking with couple of folks at IETF91, they were in agreement on the sugg= ested approach for (1) and (2). Hoping to hear further comments in response to this thread, so that we can = close this off and move forward. Please see in-line. > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Friday, November 14, 2014 12:07 PM > To: Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Nobo, >=20 > > (1) Should the "extended" S-BFD use cases move to > > draft-ietf-bfd-seamless- use-case? > > > > My opinion is yes. Once the "extended" S-BFD use cases have been > > incorporated into draft-ietf-bfd-seamless-use-case, then we should try > > to move draft-ietf-bfd-seamless-use-case forward. > > > > How does the WG feel about this? > > >=20 > I agree. :) >=20 >=20 > > > > (2) Should the alert discriminator proposal move to > > draft-ietf-bfd-seamless- base? > > > > My opinion is no . Instead we should position this as an optional > > feature of S- BFD (hence separate document than the base), especially > > considering we likely need to think through additional security concern= s > raised by this. > > > > A question was raised by Greg on how does a node find out if the > > target supports the optional alert discriminator or not. We can define > > a mandatory diagnostic value that must be implemented when the alert > > discriminator is implemented. One can send an S-BFD control packet > > with the alert discriminator with this diagnostic value to check if > > the target supports the alert discriminator mechanism. > > > > How does the WG feel about this? > > >=20 > I agree with making this as optional feature and not merging with use cas= e > document. This also assumes that all the nodes on the path MUST have S- > BFD implemented. What even if we mandate diag bit and intermediate > router does not understand that diag bit as that box is with old BFD > implementation? There should be something suggested in this document > that ingress should try for only finite time or retries? Classical BFD vs. S-BFD will be differentiated with the UDP port. With that= said, having some texts about how an initiator unambiguously determines wh= ether or not a target node support S-BFD alert discriminator (and recommend= ed sequences) is a good idea. I'll place this text in the next revision. Thanks! -Nobo >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 From nobody Fri Nov 14 23:57: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 79A461A1B58 for ; Fri, 14 Nov 2014 23:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNMjWYcxAv8H for ; Fri, 14 Nov 2014 23:57:09 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CD91A1B80 for ; Fri, 14 Nov 2014 23:57:09 -0800 (PST) X-AuditID: c618062d-f79206d0000014d2-3f-5466ae7575bc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 72.93.05330.57EA6645; Sat, 15 Nov 2014 02:37:58 +0100 (CET) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Sat, 15 Nov 2014 02:57:06 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRAA6JQPg Date: Sat, 15 Nov 2014 07:57:05 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B88381A@eusaamb106.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.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXSPn27ZurQQg29nWS1md8RbfP6zjdGB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgynh0dyt7wXf+imf7OtkaGP/ydDFyckgImEhs ud/ICGGLSVy4t56ti5GLQ0jgCKNEb/daRghnOaPE2aPLWUCq2ASMJF5s7GHvYuTgEBEIlPh9 jhMkLCzgLrFr/X02EFtEwEPi29uzzBC2kUTvntVgNouAqsT1PyvAxvAK+Ers3NLMDmILCfhI rJm6G6yGEyg+v3MFWJwR6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWwliTmv rzFD1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcWpZ brqRwSZGYCwck2DT3cG456XlIUYBDkYlHl6DwLQQIdbEsuLK3EOM0hwsSuK8s2rnBQsJpCeW pGanphakFsUXleakFh9iZOLglGpgZDV2LLqr0zeDTfdxw67LzdKHb7QVcXj82PnyRLJj0iId BQPVQ8wiCxO8eb2jGVqT819t+KetNP3oIZPfS4/Ovnxj1qFn1VqS3+9nxsfuvearrclW8Xid a5Ahd8c1JWbvjZ0Vuv+V/99saQ6/9tNE4rProeMzhLR6Jv9qn3J2s9/0vfr/N5SFKbEUZyQa ajEXFScCAOq7xS1mAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FhgkIPBEPdwX_cWcRLhn2OI2a4U 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, 15 Nov 2014 07:57:11 -0000 Hi Nobo, et. al, please find my notes in-line and tagged GIM>>. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Thursday, November 13, 2014 8:04 PM To: rtg-bfd@ietf.org Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim [Speaking as an individual S-BFD contributor] Hi BFD WG, There were couple of questions I need your input on draft-akiya-bfd-seamles= s-alert-discrim. (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless-u= se-case? My opinion is yes. Once the "extended" S-BFD use cases have been incorporat= ed into draft-ietf-bfd-seamless-use-case, then we should try to move draft-= ietf-bfd-seamless-use-case forward. How does the WG feel about this? GIM>> I think it makes sense to have use cases related to S-BFD in one docu= ment. Support. (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamless= -base? My opinion is no . Instead we should position this as an optional feature o= f S-BFD (hence separate document than the base), especially considering we = likely need to think through additional security concerns raised by this. A question was raised by Greg on how does a node find out if the target sup= ports the optional alert discriminator or not. We can define a mandatory di= agnostic value that must be implemented when the alert discriminator is imp= lemented. One can send an S-BFD control packet with the alert discriminator= with this diagnostic value to check if the target supports the alert discr= iminator mechanism. How does the WG feel about this? GIM>> After discussing structure of BFD for multi-point networks document I= realized that keeping protocol extensions in separate documents has its va= lue, especially if an extension is optional. Hence I change my previously s= tated position and support progress alert discriminator document separately= from S-BFD base. Thanks! -Nobo From nobody Sat Nov 15 04:33: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 334421A8767 for ; Sat, 15 Nov 2014 04:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 OwcsM3SZ0x2y for ; Sat, 15 Nov 2014 04:33:21 -0800 (PST) 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 B590E1A875B for ; Sat, 15 Nov 2014 04:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5708; q=dns/txt; s=iport; t=1416054802; x=1417264402; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=ZaP2wnnrYxfP3874/ZoB/+am5Jf+VldYqPjSwcyVfcY=; b=lVTnz/49723OC/p1iV9btsdn1afDsu2vR0Oza4oCD6aFNkyVbdIgyAxS 8tEJN7lE92s15WLI0qggoxTv5hlrGyhCfwEpX4VyBAcEDJsk/aWmwfs7b 0aqTjzzOUqTaB96kJ8lZqEuygkpd8K+UlIUp7Uzamw2+irDKPU/ln8PBI 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FABpHZ1StJV2P/2dsb2JhbABbgkhGgS4E1GECgRMWAQEBAQF9hAIBAgSBCwEIEQMBAigmExQJAwUBAQQBEohB0RYBAQEBAQEEAQEBAQEBAQEakREYhEsFkB+CKAWMAIE0kTyECoN8bYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,391,1413244800"; d="scan'208,217";a="372468741" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 15 Nov 2014 12:33:21 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAFCXKok000391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Nov 2014 12:33:20 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.74]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 06:33:20 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , "rtg-bfd@ietf.org" Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRABcLHWA Date: Sat, 15 Nov 2014 12:33:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.42.197] Content-Type: multipart/alternative; boundary="_000_D08D458627631mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/941BPLm42OYEkq8zKh9Fk8-GRUQ 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, 15 Nov 2014 12:33:24 -0000 --_000_D08D458627631mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, Replies inline Regards Mallik From: "Nobo Akiya (nobo)" > Date: Friday, 14 November 2014 9:34 am To: "rtg-bfd@ietf.org" > Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim [Speaking as an individual S-BFD contributor] Hi BFD WG, There were couple of questions I need your input on draft-akiya-bfd-seamles= s-alert-discrim. (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless-u= se-case? My opinion is yes. Once the "extended" S-BFD use cases have been incorporat= ed into draft-ietf-bfd-seamless-use-case, then we should try to move draft-= ietf-bfd-seamless-use-case forward. How does the WG feel about this? Mallik>> Agree. Since this is another use case of SBFD it makes sense to ha= ve all in one place. (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamless= -base? My opinion is no . Instead we should position this as an optional feature o= f S-BFD (hence separate document than the base), especially considering we = likely need to think through additional security concerns raised by this. A question was raised by Greg on how does a node find out if the target sup= ports the optional alert discriminator or not. We can define a mandatory di= agnostic value that must be implemented when the alert discriminator is imp= lemented. One can send an S-BFD control packet with the alert discriminator= with this diagnostic value to check if the target supports the alert discr= iminator mechanism. How does the WG feel about this? Mallik>> Agree. Since this is an optional feature using the base proposal o= f SBFD, we can have it as a separate document. Thanks! -Nobo --_000_D08D458627631mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Replies inline

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Friday, 14 November 2014 9:34= am
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Seeking opinions on draft-= akiya-bfd-seamless-alert-discrim

[Speaking as an individual S-BFD contributor]

Hi BFD WG,

There were couple of questions I need your input on draft-akiya-bfd-se= amless-alert-discrim.


(1) Should the "extended" S-BFD use cases move to draft-ietf= -bfd-seamless-use-case?

My opinion is yes. Once the "extended" S-BFD use cases have = been incorporated into draft-ietf-bfd-seamless-use-case, then we should try= to move draft-ietf-bfd-seamless-use-case forward.

How does the WG feel about this?

Mallik>> Agree. Since this is another use case of SBFD it makes = sense to have all in one place.


(2) Should the alert discriminator proposal move to draft-ietf-bfd-sea= mless-base?

My opinion is no . Instead we should position this as an optional feat= ure of S-BFD (hence separate document than the base), especially considerin= g we likely need to think through additional security concerns raised by th= is.

A question was raised by Greg on how does a node find out if the targe= t supports the optional alert discriminator or not. We can define a mandato= ry diagnostic value that must be implemented when the alert discriminator i= s implemented. One can send an S-BFD control packet with the alert discriminator with this diagnostic value to = check if the target supports the alert discriminator mechanism.

How does the WG feel about this?
Mallik>> Agree. Since this is an optional feature using the base= proposal of SBFD, we can have it as a separate document.

Thanks!

-Nobo


 --_000_D08D458627631mmudigonciscocom_-- From nobody Sat Nov 15 11:34:47 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 BE2811A1BBC for ; Sat, 15 Nov 2014 11:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 Zh9qL-GTGuOW for ; Sat, 15 Nov 2014 11:34:44 -0800 (PST) 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 E587A1A1B8D for ; Sat, 15 Nov 2014 11:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2519; q=dns/txt; s=iport; t=1416080083; x=1417289683; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GH15eJ++Z+gcwcQXUM7mRIWdHyeH5EDAVX7mHDedc0s=; b=HlH1IobKYcMNQE0ogODo/oixnoYj7mohbbYvIjw0Xao5g8Q4ttrGP0eM 41ZZvGoVNNk0xe9JN84EilXT/EMlHSa2kVERxsIeky7YMnv3b4JHEivGx ETTPddadrKkLADzbB+W5p9s1eUpNvj9Opph8TePvyQlcEyIH6RIBZpHGN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAD6qZ1StJA2M/2dsb2JhbABbgmsjgS4E1GICgRIWAQEBAQF9hAIBAQEEOksEAgEIEQQBAQsUCQcyFAkDBQEBBAESCIg5AdB4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BxOAaDJ4EeAQSQH4IojTmDVI1ohAqDfG2BSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="96986736" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 15 Nov 2014 19:34:43 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAFJYhi4008625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Nov 2014 19:34:43 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; Sat, 15 Nov 2014 13:34:42 -0600 From: "Nobo Akiya (nobo)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRAA6JQPgABibFWA= Date: Sat, 15 Nov 2014 19:34:42 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B88381A@eusaamb106.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B88381A@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.98.48] 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/7s5q2yKxBN8nGPXw9zRQ9Xd6Qbo 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, 15 Nov 2014 19:34:46 -0000 Hi Greg, Many thanks for taking time to provide your comments. Thanks! -Nobo > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, November 14, 2014 9:57 PM > To: Nobo Akiya (nobo); rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hi Nobo, et. al, > please find my notes in-line and tagged GIM>>. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Thursday, November 13, 2014 8:04 PM > To: rtg-bfd@ietf.org > Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > [Speaking as an individual S-BFD contributor] >=20 > Hi BFD WG, >=20 > There were couple of questions I need your input on draft-akiya-bfd- > seamless-alert-discrim. >=20 >=20 > (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless= - > use-case? >=20 > My opinion is yes. Once the "extended" S-BFD use cases have been > incorporated into draft-ietf-bfd-seamless-use-case, then we should try to > move draft-ietf-bfd-seamless-use-case forward. >=20 > How does the WG feel about this? >=20 > GIM>> I think it makes sense to have use cases related to S-BFD in one > document. Support. >=20 > (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamle= ss- > base? >=20 > My opinion is no . Instead we should position this as an optional feature= of > S-BFD (hence separate document than the base), especially considering we > likely need to think through additional security concerns raised by this. >=20 > A question was raised by Greg on how does a node find out if the target > supports the optional alert discriminator or not. We can define a mandato= ry > diagnostic value that must be implemented when the alert discriminator is > implemented. One can send an S-BFD control packet with the alert > discriminator with this diagnostic value to check if the target supports = the > alert discriminator mechanism. >=20 > How does the WG feel about this? >=20 > GIM>> After discussing structure of BFD for multi-point networks document > I realized that keeping protocol extensions in separate documents has its > value, especially if an extension is optional. Hence I change my previous= ly > stated position and support progress alert discriminator document > separately from S-BFD base. >=20 > Thanks! >=20 > -Nobo From nobody Sat Nov 15 11:36: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 155BB1A1B5C for ; Sat, 15 Nov 2014 11:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.094 X-Spam-Level: X-Spam-Status: No, score=-115.094 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.594, 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 z67ZuD4HUoo5 for ; Sat, 15 Nov 2014 11:36:07 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB2B1A0089 for ; Sat, 15 Nov 2014 11:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15830; q=dns/txt; s=iport; t=1416080166; x=1417289766; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MZt6w43315yyDAznNQHvBg9qFoIF0i4nGZVP2xT2pgE=; b=Zz0fafegWlGXUNBi/WwWYSelkAM3rWqSKS8ucKA0IA9N3gnYqWNxxebo GCShXhHjyc4o4UWIhzCyYjuEL4pW/SJEFWeRZvXs5vKJx/jv1+EXtSBFO Y8bZ6HdCQYoIUOxmckBRt30JvQ2pHJxuhkVz8Hl9AI529XkZTb8bV9/Q/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPypZ1StJA2H/2dsb2JhbABbgkgjI1VZBNRiAoESFgEBAQEBfYQCAQEBBC1cAgEIEQMBAQELHQcyFAkDBQEBBAESCIg5AdB3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BxIBcBgy2BHgWQH4IojTmRPIQKg3xtgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208,217";a="372850901" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP; 15 Nov 2014 19:36:05 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAFJa5E4001724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Nov 2014 19:36:05 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; Sat, 15 Nov 2014 13:36:05 -0600 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , "rtg-bfd@ietf.org" Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRABcLHWAAAlemEA= Date: Sat, 15 Nov 2014 19:36:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.98.48] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F528E9Axmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/euO-ZfcHupc60bU74zjIVyUoo0k 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, 15 Nov 2014 19:36:09 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F528E9Axmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mallik, Many thanks for providing your comments. Thanks! -Nobo From: MALLIK MUDIGONDA (mmudigon) Sent: Saturday, November 15, 2014 2:33 AM To: Nobo Akiya (nobo); rtg-bfd@ietf.org Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hi Nobo, Replies inline Regards Mallik From: "Nobo Akiya (nobo)" > Date: Friday, 14 November 2014 9:34 am To: "rtg-bfd@ietf.org" > Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim [Speaking as an individual S-BFD contributor] Hi BFD WG, There were couple of questions I need your input on draft-akiya-bfd-seamles= s-alert-discrim. (1) Should the "extended" S-BFD use cases move to draft-ietf-bfd-seamless-u= se-case? My opinion is yes. Once the "extended" S-BFD use cases have been incorporat= ed into draft-ietf-bfd-seamless-use-case, then we should try to move draft-= ietf-bfd-seamless-use-case forward. How does the WG feel about this? Mallik>> Agree. Since this is another use case of SBFD it makes sense to ha= ve all in one place. (2) Should the alert discriminator proposal move to draft-ietf-bfd-seamless= -base? My opinion is no . Instead we should position this as an optional feature o= f S-BFD (hence separate document than the base), especially considering we = likely need to think through additional security concerns raised by this. A question was raised by Greg on how does a node find out if the target sup= ports the optional alert discriminator or not. We can define a mandatory di= agnostic value that must be implemented when the alert discriminator is imp= lemented. One can send an S-BFD control packet with the alert discriminator= with this diagnostic value to check if the target supports the alert discr= iminator mechanism. How does the WG feel about this? Mallik>> Agree. Since this is an optional feature using the base proposal o= f SBFD, we can have it as a separate document. Thanks! -Nobo --_000_CECE764681BE964CBE1DFF78F3CDD3943F528E9Axmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mallik,

 <= /p>

Many thanks for providing= your comments.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

 <= /p>

From: MALLIK MUDIGONDA (mmudigon)
Sent: Saturday, November 15, 2014 2:33 AM
To: Nobo Akiya (nobo); rtg-bfd@ietf.org
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-disc= rim

 

Hi Nobo,

 

Replies inline

 

Regards

Mallik

 

From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Friday, 14 November 2014 9:34 am
To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim<= o:p>

 

[Speaking as an individual S-= BFD contributor]

 

Hi BFD WG,<= /p>

 

There were couple of question= s I need your input on draft-akiya-bfd-seamless-alert-discrim.

 

 

(1) Should the "extended= " S-BFD use cases move to draft-ietf-bfd-seamless-use-case?=

 

My opinion is yes. Once the &= quot;extended" S-BFD use cases have been incorporated into draft-ietf-= bfd-seamless-use-case, then we should try to move draft-ietf-bfd-seamless-u= se-case forward.

 

How does the WG feel about th= is?

 

Mallik>> Agree. Since t= his is another use case of SBFD it makes sense to have all in one place.

 

 

(2) Should the alert discrimi= nator proposal move to draft-ietf-bfd-seamless-base?

 

My opinion is no . Instead we= should position this as an optional feature of S-BFD (hence separate docum= ent than the base), especially considering we likely need to think through additional security concerns raised by this.

 

A question was raised by Greg= on how does a node find out if the target supports the optional alert disc= riminator or not. We can define a mandatory diagnostic value that must be implemented when the alert discriminator is implemented. One = can send an S-BFD control packet with the alert discriminator with this dia= gnostic value to check if the target supports the alert discriminator mecha= nism.

 

How does the WG feel about th= is?

 

Mallik>> Agree. Since t= his is an optional feature using the base proposal of SBFD, we can have it = as a separate document.

 

Thanks!

 

-Nobo

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F528E9Axmbalnx01ciscoc_-- From nobody Sat Nov 15 11:45: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 2EC671A1BDD for ; Sat, 15 Nov 2014 11:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 1LE-3y2eUvDX for ; Sat, 15 Nov 2014 11:45:54 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D851A1BCE for ; Sat, 15 Nov 2014 11:45:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=916; q=dns/txt; s=iport; t=1416080755; x=1417290355; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=AdOeTa9VCojlV12AGTsJUcWQicgPtaXFrkPAeV1S6+A=; b=eJuHf+PM2WLxUhpow+MkuMqF7tcPrifXkrZ2/g9NICarHSqSOgdz86ib qeS9Qc3pl4URguwweLwOr96MPxelVweJAuPzfMgkVRwi2xVB49oYKXA1H Ny5TCboX4kVumVVmfi4sOkmTO9iX2zOT04XXH9yvc9MLbjIRYsp30xxkB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAFqsZ1StJV2P/2dsb2JhbABbgw5VWQTNFIdOAoESFgEBAQEBcguEBAEEOj8SASoUQiYBBA4NAYg4DdBvAQEBAQEBBAEBAQEBHZBAEAIBHjECgzKBHgWBXY5Cgiiif4N8bQGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="96933576" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 15 Nov 2014 19:45:55 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAFJjrnW017339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Nov 2014 19:45:53 GMT Received: from xmb-rcd-x01.cisco.com ([173.37.183.16]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 13:45:53 -0600 From: "Nobo Akiya (nobo)" To: "draft-ietf-bfd-seamless-use-case@tools.ietf.org" Subject: S-BFD Use Cases Document Request Thread-Topic: S-BFD Use Cases Document Request Thread-Index: AdABDKwmAAW81djsR+aAuGldE074UA== Date: Sat, 15 Nov 2014 19:45:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.98.48] 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/9j2nSUWuFlIPGNoJgpZsL3WwV2U 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: Sat, 15 Nov 2014 19:45:56 -0000 Hi draft-ietf-bfd-seamless-use-case Authors, Number of WG members feel that it is appropriate to take following action. 1) Take Section 2 from draft-akiya-bfd-seamless-alert-discrim-03, and incor= porate into draft-ietf-bfd-seamless-use-case. 2) Once (1) is done, remove Section 2 in draft-akiya-bfd-seamless-alert-dis= crim and reference draft-ietf-bfd-seamless-use-case. 3) Once (1) is done, attempt to progress draft-ietf-bfd-seamless-use-case d= ocument forward. See http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02407.html for = email which initially stemmed this discussion. See http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02425.html for = email which converged the direction. If Authors of draft-ietf-bfd-seamless-use-case have no objections, I'd like= to ask the Authors of draft-ietf-bfd-seamless-use-case to initiate the cha= nges for (1). Thanks! -Nobo From nobody Sun Nov 16 22:01: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 1C68D1A0113 for ; Sun, 16 Nov 2014 22:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594] 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 xHBxTlsrkqrO for ; Sun, 16 Nov 2014 22:01:08 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE4F1A010C for ; Sun, 16 Nov 2014 22:01:08 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C17DA2AA0F; Mon, 17 Nov 2014 06:01:05 +0000 (GMT) Date: Sun, 16 Nov 2014 22:03:32 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20141116220332392193.5ed69d25@sniff.de> In-Reply-To: References: Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim 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/bYF9vj25Bq1kPSDwhXc9IjY9DBc 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, 17 Nov 2014 06:01:11 -0000 Hello Nobo and BFD experts, giving this document a closer look for the first time (ahem ;-) I have a slightly different view. Having S-BFD use cases for the general S-BFD in an extra document does improve the overall discussion and documentation, simply because the base S-BFD is already complex enough, as are the use cases. But for such a relatively small document splitting off the reason why the document exists is not improving the reading/understanding of this draft. Unless you decide to integrate the alert-discriminator document into the base document, then obviously you use the use-case document. For the integration of the technical aspect into the base document, I think this is an idea worth to discuss. At the end what you need is to add the rule for the zero discriminator to the reflector behaviour; we managed this for standard BFD, we should be able to do this for the reflector BFD as well :-) For the diagnostic codes I'm not sure; it will complicate hardware implementations (probably not a no-go problem though) and seems otherwise not add a real value IMHO. So if there are already at this stage of S-BFD use case(s) for zero-discriminator to bring up (some) sessions then I would propose to consider the integration into the base document. This will also guarantee that the zero-discriminator handling is as fast as the "normal" reflection and is not on a slower exception path. I have a question: so far S-BFD packets would be received, not "picked out of the data stream". Receiving could be because the destination IP would match or would be 127/8, the TTL would be zero and so on. In the security section you say ... Conceptually the Alert Discriminator is similar to an IP Router Alert Option or an MPLS Router Alert Label. ... and I wonder if you expect a node to "pick" S-BFD traffic (to the reflector) with an alert-discriminator out of the data stream that otherwise would just pass this node? I guess you don't want but I want to make sure I understand it correctly. Regards, Marc On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > [Speaking as an individual S-BFD contributor] > > Hi BFD WG, > > There were couple of questions I need your input on > draft-akiya-bfd-seamless-alert-discrim. > > > (1) Should the "extended" S-BFD use cases move to > draft-ietf-bfd-seamless-use-case? > > My opinion is yes. Once the "extended" S-BFD use cases have been > incorporated into draft-ietf-bfd-seamless-use-case, then we should try to > move draft-ietf-bfd-seamless-use-case forward. > > How does the WG feel about this? > > > (2) Should the alert discriminator proposal move to > draft-ietf-bfd-seamless-base? > > My opinion is no . Instead we should position this as an optional feature > of S-BFD (hence separate document than the base), especially considering we > likely need to think through additional security concerns raised by this. > > A question was raised by Greg on how does a node find out if the target > supports the optional alert discriminator or not. We can define a mandatory > diagnostic value that must be implemented when the alert discriminator is > implemented. One can send an S-BFD control packet with the alert > discriminator with this diagnostic value to check if the target supports > the alert discriminator mechanism. > > How does the WG feel about this? > > > Thanks! > > -Nobo > From nobody Sun Nov 16 22:15: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 40E971A0120 for ; Sun, 16 Nov 2014 22:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594] 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 cM4rPtodStbM for ; Sun, 16 Nov 2014 22:15:02 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 764B91A011F for ; Sun, 16 Nov 2014 22:15:02 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id BEF262AA0F; Mon, 17 Nov 2014 06:15:00 +0000 (GMT) Date: Sun, 16 Nov 2014 22:17:27 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20141116221727294771.761f1aac@sniff.de> In-Reply-To: References: Subject: Re: S-BFD Use Cases Document Request 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/tyaMPIgrYjPWlhukqFr6pymQnzY 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: Mon, 17 Nov 2014 06:15:05 -0000 Hello Nobo et al., erm ... it's great to see so much energy and "drive" but can we discuss this a little bit further? As I said in my reply, moving section 2 into the use-case document does make the alert-discrim draft less readable in my opinion. Thanks & Regards, Marc On Sat, 15 Nov 2014 19:45:53 +0000, Nobo Akiya (nobo) wrote: > Hi draft-ietf-bfd-seamless-use-case Authors, > > Number of WG members feel that it is appropriate to take following action. > > 1) Take Section 2 from draft-akiya-bfd-seamless-alert-discrim-03, and > incorporate into draft-ietf-bfd-seamless-use-case. > 2) Once (1) is done, remove Section 2 in > draft-akiya-bfd-seamless-alert-discrim and reference > draft-ietf-bfd-seamless-use-case. > 3) Once (1) is done, attempt to progress draft-ietf-bfd-seamless-use-case > document forward. > > See http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02407.html for > email which initially stemmed this discussion. > See http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg02425.html for > email which converged the direction. > > If Authors of draft-ietf-bfd-seamless-use-case have no objections, I'd like > to ask the Authors of draft-ietf-bfd-seamless-use-case to initiate the > changes for (1). > > Thanks! > > -Nobo > From nobody Thu Nov 20 05:46: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 522DD1A01D8 for ; Thu, 20 Nov 2014 03:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8YAHCiEAzft for ; Thu, 20 Nov 2014 03:33:47 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::709]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EF31A01A9 for ; Thu, 20 Nov 2014 03:33:46 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 20 Nov 2014 11:33:22 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0016.006; Thu, 20 Nov 2014 11:33:22 +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/gIAFryHggAVB2oCALmknIA== Date: Thu, 20 Nov 2014 11:33:22 +0000 Message-ID: <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.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-originating-ip: [116.197.184.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(57704003)(13464003)(24454002)(479174003)(41574002)(189002)(199003)(51914003)(35774003)(53754006)(377424004)(51704005)(19300405004)(64706001)(76176999)(108616004)(19580395003)(101416001)(33646002)(87936001)(77156002)(66066001)(107046002)(16236675004)(230783001)(19617315012)(93886004)(20776003)(40100003)(92566001)(15975445006)(99396003)(50986999)(106356001)(120916001)(19625215002)(2656002)(105586002)(31966008)(4396001)(76576001)(86362001)(106116001)(99286002)(107886001)(19580405001)(74316001)(15202345003)(21056001)(54356999)(62966003)(95666004)(122556002)(46102003)(97736003)(24736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_48e22f9306f64bb29df1883372665a78CO2PR0501MB823namprd05p_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aanWZ6TXrxLT8HooH80dFGOvGG8 X-Mailman-Approved-At: Thu, 20 Nov 2014 05:46:31 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 11:33:58 -0000 --_000_48e22f9306f64bb29df1883372665a78CO2PR0501MB823namprd05p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, In IETF-91 I have presented open items. Below are the last few things w= e need to close on. 1. Active tail. As discussed earlier, is this required in base draft? I spoke to all implem= enters and no one has active tail implemented yet. To push it for RFC we n= eed implementation so can we go ahead and move it to appendix or may be new= document? 2. Demultiplexing and UDP port number. It makes more sense to have a separate draft for this. Please let me know i= f that is ok? If it benefits to have it in base draft itself then we can ha= ve more sections for demux and port number to be used. 3. Echo mode supported? Echo mode does not fit in P2MP BFD. We can say it is not supported. Does an= yone see use of echo BFD in P2MP BFD? 4. Increase interval? Draft suggest not to use POLL sequence and suggests to increase multiplier = first and then interval. If we have hardware implementation and don't want = to check complete packet every time received then change in packet may be i= ndicated with POLL bit set. Since this is one to many mapping we can't have a complete PO= LL sequence and hence we need to suppress FINAL. Should we be going with PO= LL and suppress FINAL by setting desired RX interval set to 0? Please sugge= st any better idea. 5. bfd.ReportTailDown Draft suggests that head direct tails to send down notification. How will h= ead direct tail about failure notification to be sent or not? Is this drive= n by configuration? At least the section 4.4.1 says so. It could also be c= ommunicated to received out of band? This should be out of scope of this document as we can't direct tails with = in BFD packet. Any comments? 6. How packets get absorbed on tails? Few implementers use UDP port number to absorb BFD packet on tails. It woul= d be good to clarify about this in draft. Do we see any other way of absorb= ing packet on tail? 7. Security consideration? No suggestions yet. Thanks Santosh P K > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 22, 2014 3:09 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 > > [With Chair Hat On] > > WG, > > I'd imagine many are busy ... being the last week before the cut-off and = all ... > > But it'll be very helpful if you can chime in to help Santosh to take BFD > multipoint 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 > > > > Hello Nobo, > > Thanks again for your comments on this. Please see my comments. > > > > > (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? > > > > Does (a) alone not enough? > > 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 leaf = to the > head, then there is no way for the head to find out that leaf is no longe= r > 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) wi= ll be > useful. > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > specified > > in this document). > > > > Yes, UDP port is not specified in the document. We can add this info > > 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 plan= e. > > Thanks! > > -Nobo > > > > > > > Thanks > > Santosh P K > > > > > > -----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 > > > > [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 > > > > > > 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. > > > > > > 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 POL= L will be > > used by > > > head to detect tail going down. Tail will make use of reverse > > > unicast 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 packet= s. > > > > 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] > > > > 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 other sessions like multi-hop BFD sessions cannot. It does look > > useful with technologies such as P2MP-TE where: > > > > - leaves are constant > > - has path-protection mechanism > > > > > > > > We have below options: > > > 1. Go with simple "No Head Notification" as per section 6.1 in b= ase > > > 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 MultipointClien= t > > > 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. > > > > > > > > > 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 th= e > > > head > > > and tails is the binding to the multipoint path over which B= FD > > > 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? > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > specified in this document). > > > > 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. > > > > Either will work, but the details are required somewhere to interoperat= e. > > > > > > > > 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 > > > "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. > > > > Right it would be a good idea how other multipoint/multicast protocols > > have addressed this. > > > > Thanks! > > > > -Nobo > > > > > > > > > > > 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 remo= val? > > > > > > 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<= mailto: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 lea= ves. > > > > > > > > > >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 > > Forwarding > > > > >> > Detection (BFD) protocol for its use in multipoint and mult= icast > > > > >> > 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-0= 4 > > > > >> > > > > > >> > > > > > >> > 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_48e22f9306f64bb29df1883372665a78CO2PR0501MB823namprd05p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

    In IETF-91 I have presented op= en items. Below are the last few things we need to close on.

 

1.       Active tail.

As discussed earlier, = is this required in base draft? I spoke to all implementers  and no on= e has active tail implemented yet. To push it for RFC we need implementatio= n so can we go ahead and move it to appendix or may be new document?

 

2.       Demultiplexing and UDP port number.

It makes more sense to= have a separate draft for this. Please let me know if that is ok? If it be= nefits to have it in base draft itself then we can have more sections for d= emux and port number to be used.

 

3.       Echo mode supported?

Echo mode does not fit= in P2MP BFD. We can say it is not supported. Does anyone see use of echo B= FD in P2MP BFD?

 

4.       Increase interval?

Draft suggest not to u= se POLL sequence and suggests to increase multiplier first and then interva= l. If we have hardware implementation and don’t want to check complet= e packet every time received then change in packet may be indicated with

POLL bit set. Since th= is is one to many mapping we can't have a complete POLL sequence and hence = we need to suppress FINAL. Should we be going with POLL and suppress FINAL = by setting desired RX interval set to 0? Please suggest any better idea.

 

5.       bfd.ReportTailDown

Draf= t suggests that head direct tails to send down notification. How will head = direct tail about failure notification to be sent or not? Is this driven by= configuration? At least the  section 4.4.1 says so. It could also be communicated to

rece= ived out of band?

 

This= should be out of scope of this document as we can't direct tails with in B= FD packet. Any comments?

 

6.       How packets get absorbed on tails?

Few implementers use U= DP port number to absorb BFD packet on tails. It would be good to clarify a= bout this in draft. Do we see any other way of absorbing packet on tail? &n= bsp;

 

7.       Security consideration?

No suggestions yet.

 

 

Thanks

Santosh P K

 

 

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

> From: Nobo Akiya (nobo) [mailto:nobo@cisco.c= om]

> Sent: Wednesday, October 22, 2014 3:09 AM

> To: Santosh P K; Henderickx, Wim (Wim); Jeff= rey Haas; rtg-bfd@ietf.org;

> Mingui Zhang

> Subject: RE: I-D Action: draft-ietf-bfd-mult= ipoint-04.txt

>

> [With Chair Hat On]

>

> WG,

>

> I'd imagine many are busy ... being the last= week before the cut-off and all ...

>

> But it'll be very helpful if you can chime i= n to help Santosh to take BFD

> multipoint further.

>

> [With Chair Hat Off]

>

> Hi Santosh,

>

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

> > From: Santosh P K [= mailto:santoshpk@juniper.net]

> > Sent: Saturday, October 18, 2014 9:34 A= M

> > To: Nobo Akiya (nobo); Henderickx, Wim = (Wim); Jeffrey Haas; rtg-

> > bfd@ietf.org; Min= gui Zhang

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

> >

> > Hello Nobo,

> >    Thanks again for your= comments on this. Please see my comments.

> >

> > > (a) unicast DOWN notification from= leaves.

> > > (b) multicast Poll of leaves.

> > > (c) unicast Poll of leaves.

> > > If we want to keep the in-band mec= hanism and remove out-of-band

> > mechanism, then preserve (a) and (b) bu= t remove (c). And that would be

> > my preference.

> > > Mingui, for your "TRILL Resil= ient Distribution Trees", do you see

> > > the need

> > for all [a-c] or just subsets?

> >

> > Does (a) alone not enough?

>

> Personally I think there's a value in leavin= g the option for the head to do in-

> band polling of leaves. In other words, if d= own notification from a leaf to the

> head, then there is no way for the head to f= ind out that leaf is no longer

> receiving.

>

> > Want to know if there are any applicati= on which wants to track tail

> > proactively? If so we can keep both (a)= and (b).

>

> More comments from the WG will be very helpf= ul. So far ...

>

> - Mingui brought up "TRILL Resilient Di= stribution Trees".

> - I brought up P2MP-TE Path Protection, whic= h I think both (a) and (b) will be

> useful.

>

> >

> > > Demux procedures is one, UDP port = is the other one (i.e. it is not

> > > specified

> > in this document).

> >

> > Yes, UDP port is not specified in the d= ocument. We can add this info

> > in base document itself? Every on ok wi= th this? Any suggestions?

>

> Demux procedures and UDP ports should go int= o the same document.

>

> So it's either:

>

> (a) put everything in draft-ietf-bfd-multipo= int.

>

> Or

>

> (b) spin off draft-ietf-bfd-multipoint-<d= ataplane> document per data plane.

>

> Thanks!

>

> -Nobo

>

> >

> >

> > Thanks

> > Santosh P K

> >

> >

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

> > From: Nobo Akiya (nobo) [m= ailto:nobo@cisco.com]

> > Sent: Wednesday, October 15, 2014 4:04 = AM

> > To: Santosh P K; Henderickx, Wim (Wim);= Jeffrey Haas;

> > rtg-bfd@ietf.org<= /a>; Mingui 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 comm= ents 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-iet= f-bfd-multipoint-04.txt

> > >

> > > Hello All,

> > >    Sorry for delay.= I am trying to elaborate what I meant by "active tail".

> > > Please also comment on other two i= tems that I have listed below

> > > which were raised by Prasad and No= bo in earlier discussions.

> > >

> > > Active tail:

> > > ------------

> > > As per discussion with implementer= s it looks like we don't see any

> > > use case scenario for head trackin= g tail. Currently there are

> > > multiple options given in draft fo= r head to track tail.

> > >      1.  = Unreliable Head Notification as per section 6.2

> > >      &nbs= p;            &= nbsp;  When tail detect timer expires it sends DOWN BFD packet to

> > head on

> > > reverse unicast path.

> > >      2. Semi-r= eliable Head Notification and Tail Solicitation as per

> > > section

> > > 6.3

> > >      &nbs= p;            &= nbsp;  A multipoint POLL with a combination of reverse unicast

> > path FINAL

> > > will help head to know if tail has= lost communication with head.

> > >      3. Reliab= le Head Notification as per section 6.4

> > >       &nb= sp;            =   A combination of multipoint POLL and unicast POLL will be

> > used by

> > > head to detect tail going down. Ta= il will make use of reverse

> > > unicast path to send FINAL packet = to head.

> >

> > One important characteristics is that:<= /p>

> > (1) allows the head to be notified of _= in-band_ failure by leaves.

> > (2) allows the head to poll leaves thro= ugh _in-band_ packets.

> > (3) allows the head to poll leaves thro= ugh _out-of-band_ unicast packets.

> >

> > Going back to what Wim wrote (thanks fo= r the comment Wim!):

> > [snip]

> > > In certain environment the trackin= g of the tails is happening by

> > > other

> > means.

> > > Example is Multicast VPN using MP-= BGP.

> > [snip]

> >

> > True, in the scenario described, (3) ad= ds very minimal value beyond

> > running multi-hop BFD session between B= GP peers.

> >

> > On the other hand (1) and (2) are in-ba= nd, and can detect failures

> > that other sessions like multi-hop BFD = sessions cannot. It does look

> > useful with technologies such as P2MP-T= E where:

> >

> > - leaves are constant

> > - has path-protection mechanism

> >

> > >

> > > We have below options:

> > >      1. Go wit= h simple "No Head Notification" as per section 6.1 in base

> > > draft and move rest of the section= s to Appendix or move to separate

> > draft?

> > > In this case On MultipointHead bfd= .ReportTailDown

> > >       &nb= sp;   will be set to 0 and we might not even need Multipoint= Client

> > > as we are not going to receive any= packets from tail. bfd.SilentTail

> > > will be set to 1 on MultipointTail=

> > >      2. Anothe= r option is to just keep "Unreliable Head Notification" as

> > > per section 6.2 and move/remove re= st of mechanism through which

> > > Multipoint head can detect tail go= ing down.

> > >       &nb= sp;   Meaning we need to move/remove Multicast POLL and unic= ast

> > POLL

> > > from MultipointHead.

> >

> > Another way to look at this is that:

> >

> > (a) unicast DOWN notification from leav= es.

> > (b) multicast Poll of leaves.

> > (c) unicast Poll of leaves.

> >

> > If we want to keep the in-band mechanis= m and remove out-of-band

> > mechanism, then preserve (a) and (b) bu= t 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 s= uggested 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 c= ontext of EVPN BFD draft that as

> > > per section 4.7 of this draft say<= /p>

> > >

> > >      " Th= e minimum amount of a priori information required both on the

> > > head

> > >       &nb= sp;  and tails is the binding to the multipoint path over which B= FD

> > > is running."

> > >

> > > Above text is brief and draft is A= F agnostic. Do we need to make

> > > text of Sec

> > > 4.7 and related sections more expl= icit? 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 dr= aft or it should be outside the

> > > scope of this document?

> >

> > Demux procedures is one, UDP port is th= e other one (i.e. it is not

> > specified in this document).

> >

> > 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-p= ort details for various data

> planes.

> >

> > Either will work, but the details are r= equired somewhere to interoperate.

> >

> > >

> > > Security consideration:

> > > ----------------------------

> > > As per Nobo's comment on this draf= t long back.  We need to add some

> > > suggestion in security considerati= on. 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 & Authenti= cation (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 Discrimina= tor values to leaves, which will

> > > cause many instances of Multipoint= Tail 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 se= ssion creation, it would be

> > > beneficial to highlight this point= and provide suggestions 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.<= /p>

> >

> > Right it would be a good idea how other= multipoint/multicast protocols

> > have addressed this.

> >

> > Thanks!

> >

> > -Nobo

> >

> > >

> > >

> > > Thanks

> > > Santosh P K

> > >

> > >

> > >

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

> > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]

> > > Sent: Friday, October 10, 2014 8:1= 8 PM

> > > To: Santosh P K; Henderickx, Wim (= Wim); Jeffrey Haas;

> > > rtg-bfd@ietf.org

> > > Subject: RE: I-D Action: draft-iet= f-bfd-multipoint-04.txt

> > >

> > > Santosh,

> > >

> > > It will helpful to clarify exactly= what you mean by "active tail".

> > >

> > > - Do you intend to keep tail repor= ting of the failure

> > > (bfd.ReportTailDown=3D1)?

> > > - Is it just unicast poll from hea= d that is being questioned for removal?

> > >

> > > Knowing exactly what aspect is bei= ng questioned for removal may

> > > provide a better base for good dis= cussions.

> > >

> > > Thanks!

> > >

> > > -Nobo

> > >

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

> > > > From: Santosh P K [mailto:santoshpk@juniper.net]

> > > > Sent: Thursday, October 09, 2= 014 10:39 PM

> > > > To: Henderickx, Wim (Wim); No= bo Akiya (nobo); Jeffrey Haas; rtg-

> > > > bfd@ietf.org

> > > > Subject: RE: I-D Action: draf= t-ietf-bfd-multipoint-04.txt

> > > >

> > > > Thanks Hendreickx for your re= ply.

> > > >

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

> > > > From: Henderickx, Wim (Wim) [= mailto:wim.henderickx@alcatel-

> > > > lucent.com]

> > > > Sent: Friday, October 10, 201= 4 12:29 AM

> > > > To: Nobo Akiya (nobo); Santos= h P K; Jeffrey Haas; rtg-bfd@ietf.org

> > > > Subject: Re: I-D Action: draf= t-ietf-bfd-multipoint-04.txt

> > > >

> > > > In certain environment the tr= acking of the tails is happening by

> > > > other

> > > means.

> > > > Example is Multicast VPN usin= g 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 r= emoving 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 failur= e of the multicast tree, which allows

> > > > >protections such as live-= live.

> > > > >

> > > > >What is essentially diffe= rent:

> > > > >

> > > > >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 requiremen= ts for the ingress/root to trigger some

> > > > >protections, then active = tail becomes a requirement. If there is

> > > > >no such requirements, the= n the active tail is an unnecessary

> > > > >portion of this document.=

> > > > >

> > > > >It'll be beneficial to he= ar your thoughts/comments to help gauge

> > > > >where we are on this matt= er as a WG.

> > > > >

> > > > >Comments/thoughts?

> > > > >

> > > > >Thanks!

> > > > >

> > > > >-Nobo

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >> Santosh P K

> > > > >> Sent: Monday, Octobe= r 06, 2014 9:27 AM

> > > > >> To: Santosh P K; Jef= frey Haas; rtg-bfd@ietf.org

> > > > >> Subject: RE: I-D Act= ion: draft-ietf-bfd-multipoint-04.txt

> > > > >>

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

> > > > >>

> > > > >> Thanks

> > > > >> Santosh P K

> > > > >>

> > > > >> -----Original Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >> Santosh P K

> > > > >> Sent: Monday, Octobe= r 06, 2014 6:22 PM

> > > > >> To: Jeffrey Haas; rtg-bfd@ietf.org

> > > > >> Subject: RE: I-D Act= ion: 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 t= ale.

> > > > >> 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 Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >>Jeffrey Haas

> > > > >> Sent: Tuesday, Augus= t 19, 2014 7:38 PM

> > > > >> To: r= tg-bfd@ietf.org

> > > > >> Subject: Re: I-D Act= ion: draft-ietf-bfd-multipoint-04.txt

> > > > >>

> > > > >> Note that this consi= sts mostly of a re-publish with Santosh as

> > > > >>the new editor.

> > > > >> (And moving from .nr= off to .xml.)

> > > > >>

> > > > >> In the next few week= s, Santosh will be working with known

> > > > >>implementors to = edit the document to match implementation.

> > > > >>Ideally these edits w= ill be  complete prior to the next IETF

> > > > >>session in Honolulu.&= nbsp; This will put us a bit  past our original

> > > > >>milestone for publica= tion, 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 draf= t is a work item of the Bidirectional Forwarding

> > > > >> > Detection

> > > > >> Working Group of the= IETF.

> > > > >> >

> > > > >> >  &nbs= p;      Title      &= nbsp;    : BFD for Multipoint Networks

> > > > >> >  &nbs= p;      Authors      = ;   : Dave Katz

> > > > >> >  &nbs= p;            &= nbsp;           Dave Ward=

> > > > >> >  &nbs= p;            &= nbsp;           Santosh P= allagatti

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

> > > > >> >   &nb= sp;    Pages        =    : 27

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

> > > > >> >

> > > > >> > Abstract:

> > > > >> >  &nbs= p; This document describes extensions to the Bidirectional

> > Forwarding

> > > > >> >  &nbs= p; Detection (BFD) protocol for its use in multipoint and multicast

> > > > >> >  &nbs= p; networks.  Comments on this draft should be directed to rtg-

> > > > >> >  &nbs= p; bfd@ietf.org.

> > > > >> >

> > > > >> >

> > > > >> >

> > > > >> > The IETF datatr= acker status page for this draft is:

> > > > >> > https://datatracker.i= etf.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/r= fcdiff?url2=3Ddraft-ietf-bfd-multipoint-04

> > > > >> >

> > > > >> >

> > > > >> > Please note tha= t it may take a couple of minutes from the

> > > > >> > time of submiss= ion 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/in= ternet-drafts/

> > > > >

 

--_000_48e22f9306f64bb29df1883372665a78CO2PR0501MB823namprd05p_-- From nobody Thu Nov 20 07:16:47 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 8B08A1A1A7E for ; Thu, 20 Nov 2014 07:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 GbVBsx4_dpLK for ; Thu, 20 Nov 2014 07:16:45 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8721A1A7B for ; Thu, 20 Nov 2014 07:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=250; q=dns/txt; s=iport; t=1416496590; x=1417706190; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ctSK4TAYlwyvdANuNKf3/yJG8N5oxnToYnnxTCnWM8E=; b=XwN4bhWlqFW1SqqJqaKNHKkJ/assjhVzpgqUXjaO9sme+KsuW1TgYcVo ce1fJlHQZ5vA1jLnItxP60e6WY78FBNTfSH3LC0/W5T6GMpmCOby8UhJp wvP+j8J60jL6HI8n6L+DZf4sZgsb2+n5fxCGIeTqtusFKCm8kjmKAAOiK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMHAAMFblStJA2M/2dsb2JhbABagmsjVVoDy1SHSQKBBhYBAQEBAXILhAQBBDpRASoUQiYBBBsBiDgBDK4tpjsskFeDZYEeBZAtgiqjBYN7gjWBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,424,1413244800"; d="scan'208";a="98535431" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 20 Nov 2014 15:16:30 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAKFGUGm012342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Nov 2014 15:16:30 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 09:16:30 -0600 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: IETF91 BFD WG Session Minutes Thread-Topic: IETF91 BFD WG Session Minutes Thread-Index: AdAE1LVOhPN9c40nSJCtSQqCZrjtwQ== Date: Thu, 20 Nov 2014 15:16:29 +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.76] 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/T4nko2roPbNkhb02SwOwIjrBEbQ 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, 20 Nov 2014 15:16:46 -0000 Hi Folks, IETF91 BFD WG Session Minutes has been posted. http://www.ietf.org/proceedings/91/minutes/minutes-91-bfd Special thanks for Santosh P K for taking the minutes. And do respond if we missed anything. Thanks! -Nobo and Jeff From nobody Thu Nov 20 17:59: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 3475F1A8A62 for ; Thu, 20 Nov 2014 17:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 5Dk29LjWva0Y for ; Thu, 20 Nov 2014 17:59:00 -0800 (PST) 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 6B0401A8A56 for ; Thu, 20 Nov 2014 17:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5988; q=dns/txt; s=iport; t=1416535140; x=1417744740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LbkFC6MzJFoObeFT1xlcjpLjp6sObzy6QBHT4tBqjQQ=; b=gB+Q2fXKm+AoXQ8LZFFCSJCJn1NsNA+NNal6CxDZYnw1YFcmLWuQOrWq eU/Xg8zDHpt9JNPMhVL9LE4IhButjqYQ+sXJHPuXjoOkcTg3gJNofTblj j6FmWIOuCAltL2uN5HGsCfVoA+gsBxHUnQ+ClkodkNZXU0V+9i5p1q+Kd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAEmbblStJA2E/2dsb2JhbABagmsjgS4E0ykCgQkWAQEBAQF9hAIBAQEDAToxCQUFBwQCAQgRBAEBAQoUCQcyFAkDBQEBBA4FCIgwCQHUXAEBAQEBAQEBAQEBAQEBAQEBAQEBAReQVzEHBoMngR4FkC2CKo09g1WNaoQJg3ttgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,427,1413244800"; d="scan'208";a="374065205" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 21 Nov 2014 01:58:59 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAL1wx9s011667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 01:58:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 19:58:59 -0600 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiA= Date: Fri, 21 Nov 2014 01:58:59 +0000 Message-ID: References: <20141116220332392193.5ed69d25@sniff.de> In-Reply-To: <20141116220332392193.5ed69d25@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.39] 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/un3eG5z2CryYRpAPzBWYK3XOo8g 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, 21 Nov 2014 01:59:04 -0000 Hi Marc, Thanks for providing your view. Please see in-line. > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, November 17, 2014 1:04 AM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hello Nobo and BFD experts, >=20 > giving this document a closer look for the first time (ahem ;-) I have a > slightly different view. >=20 > Having S-BFD use cases for the general S-BFD in an extra document does > improve the overall discussion and documentation, simply because the > base S-BFD is already complex enough, as are the use cases. >=20 > But for such a relatively small document splitting off the reason why the > document exists is not improving the reading/understanding of this draft. > Unless you decide to integrate the alert-discriminator document into the > base document, then obviously you use the use-case document. Your view is then: Instead of: (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and keep th= e alert discriminator mechanism in the draft-akiya-bfd-seamless-alert-discr= im. Do: (2) Keep the extended use-cases and alert discriminator mechanism in the dr= aft-akiya-bfd-seamless-alert-discrim. Or (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case and mov= e the alert discriminator mechanism to draft-ietf-bfd-seamless-base. My thought was that (1) makes sense, but your view that (1) makes all the S= -BFD documents set more complex to understand is a valid concern (it's alwa= ys good to get fresh eyes on documents!). >=20 >=20 > For the integration of the technical aspect into the base document, I thi= nk > this is an idea worth to discuss. At the end what you need is to add the = rule > for the zero discriminator to the reflector behaviour; we managed this fo= r > standard BFD, we should be able to do this for the reflector BFD as well = :-) Whether the S-BFD packets with alert discriminator are handled in HW or SW = is an implementation choice. Similar to how IP router alert option & router= alert label are handled, I do see handling of S-BFD packets with alert dis= criminator in the SW to be a reasonable approach, in which case the HW inst= ruction for S-BFD packets with alert discriminator is to punt to SW for pro= cessing. > For the diagnostic codes I'm not sure; it will complicate hardware > implementations (probably not a no-go problem though) and seems > otherwise not add a real value IMHO. If one really wants to handle them in the HW, that's a possibility. Althoug= h as you stated, it does complicate HW implementations and this is another = reason for SW based implementations. >=20 > So if there are already at this stage of S-BFD use case(s) for zero- > discriminator to bring up (some) sessions then I would propose to conside= r > the integration into the base document. This will also guarantee that the > zero-discriminator handling is as fast as the "normal" reflection and is = not > on a slower exception path. Personally, I tend to recommend that alert discriminators are handled in th= e SW. Let's assume that you agree on this (hypothetically). In that case, w= ould you still recommend the alert discriminator mechanism to be moved to t= he draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draft= -akiya-bfd-seamless-alert-discrim? >=20 >=20 >=20 > I have a question: so far S-BFD packets would be received, not "picked ou= t > of the data stream". Receiving could be because the destination IP would > match or would be 127/8, the TTL would be zero and so on. In the security > section you say ... >=20 > Conceptually the Alert Discriminator is similar to an IP Router Alert > Option or an MPLS Router Alert Label. >=20 > ... and I wonder if you expect a node to "pick" S-BFD traffic (to the > reflector) with an alert-discriminator out of the data stream that otherw= ise > would just pass this node? > I guess you don't want but I want to make sure I understand it correctly. Ah, great catch. Yes we do not want "intermediate nodes" to pick up S-BFD p= ackets with alert discriminator. So the statement regarding "Conceptually t= he Alert Discriminator is similar to an IP Router Alert Option or an MPLS R= outer Alert Label" should be re-stated and clarified. Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > > [Speaking as an individual S-BFD contributor] > > > > Hi BFD WG, > > > > There were couple of questions I need your input on > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > (1) Should the "extended" S-BFD use cases move to > > draft-ietf-bfd-seamless-use-case? > > > > My opinion is yes. Once the "extended" S-BFD use cases have been > > incorporated into draft-ietf-bfd-seamless-use-case, then we should try > > to move draft-ietf-bfd-seamless-use-case forward. > > > > How does the WG feel about this? > > > > > > (2) Should the alert discriminator proposal move to > > draft-ietf-bfd-seamless-base? > > > > My opinion is no . Instead we should position this as an optional > > feature of S-BFD (hence separate document than the base), especially > > considering we likely need to think through additional security concern= s > raised by this. > > > > A question was raised by Greg on how does a node find out if the > > target supports the optional alert discriminator or not. We can define > > a mandatory diagnostic value that must be implemented when the alert > > discriminator is implemented. One can send an S-BFD control packet > > with the alert discriminator with this diagnostic value to check if > > the target supports the alert discriminator mechanism. > > > > How does the WG feel about this? > > > > > > Thanks! > > > > -Nobo > > From nobody Fri Nov 21 00: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 AAB701AD2EC for ; Fri, 21 Nov 2014 00:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.594] 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 L2YL9qMlM7Z9 for ; Fri, 21 Nov 2014 00:22:35 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F051AD324 for ; Fri, 21 Nov 2014 00:22:34 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7CE852AA0F; Fri, 21 Nov 2014 08:22:31 +0000 (GMT) Date: Fri, 21 Nov 2014 00:25:12 -0800 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20141121002512713064.799b449a@sniff.de> In-Reply-To: References: <20141116220332392193.5ed69d25@sniff.de> Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim 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/3ek7BbseUz3ap7dBI3OK6nbkUFc 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, 21 Nov 2014 08:22:39 -0000 Hello Nobo, (back from Hawaii or writing emails at the beach? ;-) > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and keep > the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case and > move the alert discriminator mechanism to draft-ietf-bfd-seamless-base. yes, exactly. > Whether the S-BFD packets with alert discriminator are handled in HW or SW > is an implementation choice. Similar to how IP router alert option & router > alert label are handled, I do see handling of S-BFD packets with alert > discriminator in the SW to be a reasonable approach, in which case the HW > instruction for S-BFD packets with alert discriminator is to punt to SW for > processing. > Personally, I tend to recommend that alert discriminators are handled in > the SW. Let's assume that you agree on this (hypothetically). In that case, > would you still recommend the alert discriminator mechanism to be moved to > the draft-ietf-bfd-seamless-base or is it reasonable to keep it in the > draft-akiya-bfd-seamless-alert-discrim? That's probably where our different views come from :-) I would aim to simplify the main idea of the draft so it _can_ easily be implemented even in hardware. For the traceroute - my guess is TTL punts (if that mechanism to "deliver" is used) happen in software as many mechanism use this "trick" but if a hardware can handle TTL punts, it can handle the diag code as well. I don't see the document needs to adjust for the traceroute case. For a basic reflector task, having a zero discriminator as a default reflector discriminator would allow for very simple implementations (we discussed a while ago a fixed discriminator value for simple broadband modems, remember?). For more complex equipment and scenarios, keeping it in hardware instead of a software punt would maintain the ability of S-BFD to go up very quickly. I tend to not see the zero discriminator as such a big exception, which may explain my idea to integrate it into the base document. And to keep it compatible to hardware implementations. Assuming you want to add more "special effects" in the future I can see why you have an extra document. I would propose to keep the zero-reflector mentally aligned :-) with the base document and accordingly designed to allow implementations to cover the zero-reflector together with "normal" S-BFD (read: may be in hardware). > Ah, great catch. Yes we do not want "intermediate nodes" to pick up S-BFD > packets with alert discriminator. Good - makes life simpler :-) Regards, Marc On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, > > Thanks for providing your view. > > Please see in-line. > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, November 17, 2014 1:04 AM >> To: Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >> >> Hello Nobo and BFD experts, >> >> giving this document a closer look for the first time (ahem ;-) I have a >> slightly different view. >> >> Having S-BFD use cases for the general S-BFD in an extra document does >> improve the overall discussion and documentation, simply because the >> base S-BFD is already complex enough, as are the use cases. >> >> But for such a relatively small document splitting off the reason why the >> document exists is not improving the reading/understanding of this draft. >> Unless you decide to integrate the alert-discriminator document into the >> base document, then obviously you use the use-case document. > > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and keep > the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case and > move the alert discriminator mechanism to draft-ietf-bfd-seamless-base. > > My thought was that (1) makes sense, but your view that (1) makes all the > S-BFD documents set more complex to understand is a valid concern (it's > always good to get fresh eyes on documents!). > >> >> >> For the integration of the technical aspect into the base document, I think >> this is an idea worth to discuss. At the end what you need is to add the >> rule >> for the zero discriminator to the reflector behaviour; we managed this for >> standard BFD, we should be able to do this for the reflector BFD as well >> :-) > > Whether the S-BFD packets with alert discriminator are handled in HW or SW > is an implementation choice. Similar to how IP router alert option & router > alert label are handled, I do see handling of S-BFD packets with alert > discriminator in the SW to be a reasonable approach, in which case the HW > instruction for S-BFD packets with alert discriminator is to punt to SW for > processing. > >> For the diagnostic codes I'm not sure; it will complicate hardware >> implementations (probably not a no-go problem though) and seems >> otherwise not add a real value IMHO. > > If one really wants to handle them in the HW, that's a possibility. > Although as you stated, it does complicate HW implementations and this is > another reason for SW based implementations. > >> >> So if there are already at this stage of S-BFD use case(s) for zero- >> discriminator to bring up (some) sessions then I would propose to consider >> the integration into the base document. This will also guarantee that the >> zero-discriminator handling is as fast as the "normal" reflection and is >> not >> on a slower exception path. > > Personally, I tend to recommend that alert discriminators are handled in > the SW. Let's assume that you agree on this (hypothetically). In that case, > would you still recommend the alert discriminator mechanism to be moved to > the draft-ietf-bfd-seamless-base or is it reasonable to keep it in the > draft-akiya-bfd-seamless-alert-discrim? > >> >> >> >> I have a question: so far S-BFD packets would be received, not "picked out >> of the data stream". Receiving could be because the destination IP would >> match or would be 127/8, the TTL would be zero and so on. In the security >> section you say ... >> >> Conceptually the Alert Discriminator is similar to an IP Router Alert >> Option or an MPLS Router Alert Label. >> >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the >> reflector) with an alert-discriminator out of the data stream that >> otherwise >> would just pass this node? >> I guess you don't want but I want to make sure I understand it correctly. > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up S-BFD > packets with alert discriminator. So the statement regarding "Conceptually > the Alert Discriminator is similar to an IP Router Alert Option or an MPLS > Router Alert Label" should be re-stated and clarified. > > Thanks! > > -Nobo > >> >> >> Regards, Marc >> >> >> >> >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: >>> [Speaking as an individual S-BFD contributor] >>> >>> Hi BFD WG, >>> >>> There were couple of questions I need your input on >>> draft-akiya-bfd-seamless-alert-discrim. >>> >>> >>> (1) Should the "extended" S-BFD use cases move to >>> draft-ietf-bfd-seamless-use-case? >>> >>> My opinion is yes. Once the "extended" S-BFD use cases have been >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should try >>> to move draft-ietf-bfd-seamless-use-case forward. >>> >>> How does the WG feel about this? >>> >>> >>> (2) Should the alert discriminator proposal move to >>> draft-ietf-bfd-seamless-base? >>> >>> My opinion is no . Instead we should position this as an optional >>> feature of S-BFD (hence separate document than the base), especially >>> considering we likely need to think through additional security concerns >> raised by this. >>> >>> A question was raised by Greg on how does a node find out if the >>> target supports the optional alert discriminator or not. We can define >>> a mandatory diagnostic value that must be implemented when the alert >>> discriminator is implemented. One can send an S-BFD control packet >>> with the alert discriminator with this diagnostic value to check if >>> the target supports the alert discriminator mechanism. >>> >>> How does the WG feel about this? >>> >>> >>> Thanks! >>> >>> -Nobo >>> > From nobody Fri Nov 21 07:05:40 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 C38661AD5B7 for ; Fri, 21 Nov 2014 04:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 j2gbWpfckOcc for ; Fri, 21 Nov 2014 04:24:31 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6BE1B1AD436 for ; Fri, 21 Nov 2014 04:14:11 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1E5AEA4AB9B40; Fri, 21 Nov 2014 12:14:06 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sALCDWBk025186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 13:13:56 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.219]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 21 Nov 2014 13:12:09 +0100 From: "Henderickx, Wim (Wim)" To: Santosh P K , "Nobo Akiya (nobo)" , 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+keyL4hHqvmqqpvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABGZGA Date: Fri, 21 Nov 2014 12:12:08 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> In-Reply-To: <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_D093325C10B94Ewimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/eOtaWwd_jznur1jJO6WqUzIwRso X-Mailman-Approved-At: Fri, 21 Nov 2014 07:05:36 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 12:24:42 -0000 --_000_D093325C10B94Ewimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In-line From: Santosh P K > Date: Thursday 20 November 2014 03:33 To: "Nobo Akiya (nobo)" >, Wim Hender= ickx >, Jeffrey Haas >, "rtg-bfd@iet= f.org" >= , Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello All, In IETF-91 I have presented open items. Below are the last few things w= e need to close on. 1. Active tail. As discussed earlier, is this required in base draft? I spoke to all implem= enters and no one has active tail implemented yet. To push it for RFC we n= eed implementation so can we go ahead and move it to appendix or may be new= document? WH> I would propose we do the active tail in appendix or a separate draft 2. Demultiplexing and UDP port number. It makes more sense to have a separate draft for this. Please let me know i= f that is ok? If it benefits to have it in base draft itself then we can ha= ve more sections for demux and port number to be used. WH> it should be in the draft I believe 3. Echo mode supported? Echo mode does not fit in P2MP BFD. We can say it is not supported. Does an= yone see use of echo BFD in P2MP BFD? WH> I don=92t see a use case for this so far 4. Increase interval? Draft suggest not to use POLL sequence and suggests to increase multiplier = first and then interval. If we have hardware implementation and don=92t wan= t to check complete packet every time received then change in packet may be= indicated with POLL bit set. Since this is one to many mapping we can't have a complete PO= LL sequence and hence we need to suppress FINAL. Should we be going with PO= LL and suppress FINAL by setting desired RX interval set to 0? Please sugge= st any better idea. 5. bfd.ReportTailDown Draft suggests that head direct tails to send down notification. How will h= ead direct tail about failure notification to be sent or not? Is this drive= n by configuration? At least the section 4.4.1 says so. It could also be c= ommunicated to received out of band? This should be out of scope of this document as we can't direct tails with = in BFD packet. Any comments? 6. How packets get absorbed on tails? Few implementers use UDP port number to absorb BFD packet on tails. It woul= d be good to clarify about this in draft. Do we see any other way of absorb= ing packet on tail? 7. Security consideration? No suggestions yet. Thanks Santosh P K > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 22, 2014 3:09 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 > > [With Chair Hat On] > > WG, > > I'd imagine many are busy ... being the last week before the cut-off and = all ... > > But it'll be very helpful if you can chime in to help Santosh to take BFD > multipoint 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 > > > > Hello Nobo, > > Thanks again for your comments on this. Please see my comments. > > > > > (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? > > > > Does (a) alone not enough? > > 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 leaf = to the > head, then there is no way for the head to find out that leaf is no longe= r > 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) wi= ll be > useful. > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > specified > > in this document). > > > > Yes, UDP port is not specified in the document. We can add this info > > 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 plan= e. > > Thanks! > > -Nobo > > > > > > > Thanks > > Santosh P K > > > > > > -----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 > > > > [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 > > > > > > 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. > > > > > > 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 POL= L will be > > used by > > > head to detect tail going down. Tail will make use of reverse > > > unicast 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 packet= s. > > > > 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] > > > > 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 other sessions like multi-hop BFD sessions cannot. It does look > > useful with technologies such as P2MP-TE where: > > > > - leaves are constant > > - has path-protection mechanism > > > > > > > > We have below options: > > > 1. Go with simple "No Head Notification" as per section 6.1 in b= ase > > > 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 MultipointClien= t > > > 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. > > > > > > > > > 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 th= e > > > head > > > and tails is the binding to the multipoint path over which B= FD > > > 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? > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > specified in this document). > > > > 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. > > > > Either will work, but the details are required somewhere to interoperat= e. > > > > > > > > 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 > > > "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. > > > > Right it would be a good idea how other multipoint/multicast protocols > > have addressed this. > > > > Thanks! > > > > -Nobo > > > > > > > > > > > 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 remo= val? > > > > > > 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<= mailto: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 lea= ves. > > > > > > > > > >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 > > Forwarding > > > > >> > Detection (BFD) protocol for its use in multipoint and mult= icast > > > > >> > 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-0= 4 > > > > >> > > > > > >> > > > > > >> > 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_D093325C10B94Ewimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0E458FBC3B70F84AA4C48925A92B140C@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
In-line

From: Santosh P K <santoshpk@juniper.net>
Date: Thursday 20 November 2014 03:= 33
To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>, Wim Henderickx= <wim.henderickx@al= catel-lucent.com>, Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org">rtg-bfd@ietf.org>, Mingui Zhang &= lt;zhangmingui@huawei.com>=
Subject: RE: I-D Action: draft-ietf= -bfd-multipoint-04.txt

Hello All,

    In IETF-91 I have presented op= en items. Below are the last few things we need to close on.

 

1.   =     Active tail.

As discussed earlier, = is this required in base draft? I spoke to all implementers  and no on= e has active tail implemented yet. To push it for RFC we need implementatio= n so can we go ahead and move it to appendix or may be new document?

WH> I would propose we do the active tail in appendix or a separate= draft

 

2.   =     Demultiplexing and UDP port number.<= /p>

It makes more sense to= have a separate draft for this. Please let me know if that is ok? If it be= nefits to have it in base draft itself then we can have more sections for d= emux and port number to be used.

WH> it should be in the draft I believe

 

3.   =     Echo mode supported?

Echo mode does not fit= in P2MP BFD. We can say it is not supported. Does anyone see use of echo B= FD in P2MP BFD?

WH> I don=92t see a use case for this so far

 

4.   =     Increase interval?

Draft suggest not to u= se POLL sequence and suggests to increase multiplier first and then interva= l. If we have hardware implementation and don=92t want to check complete pa= cket every time received then change in packet may be indicated with

POLL bit set. Since th= is is one to many mapping we can't have a complete POLL sequence and hence = we need to suppress FINAL. Should we be going with POLL and suppress FINAL = by setting desired RX interval set to 0? Please suggest any better idea.

 

5.   =     bfd.ReportTailDown

Draf= t suggests that head direct tails to send down notification. How will head = direct tail about failure notification to be sent or not? Is this driven by= configuration? At least the  section 4.4.1 says so. It could also be communicated to

rece= ived out of band?

 

This= should be out of scope of this document as we can't direct tails with in B= FD packet. Any comments?

 

6.   =     How packets get absorbed on tails?

Few implementers use U= DP port number to absorb BFD packet on tails. It would be good to clarify a= bout this in draft. Do we see any other way of absorbing packet on tail? &n= bsp;

 

7.   =     Security consideration?

No suggestions yet.

 

 

Thanks

Santosh P K

 

 

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

> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]

> Sent: Wednesday, October 22, 2014 3:09 AM

> To: Santosh P K; Henderickx, Wim (Wim); Jeff= rey Haas; rtg-bfd@ietf.org;

> Mingui Zhang

> Subject: RE: I-D Action: draft-ietf-bfd-mult= ipoint-04.txt

>

> [With Chair Hat On]

>

> WG,

>

> I'd imagine many are busy ... being the last= week before the cut-off and all ...

>

> But it'll be very helpful if you can chime i= n to help Santosh to take BFD

> multipoint further.

>

> [With Chair Hat Off]

>

> Hi Santosh,

>

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

> > From: Santosh P K [= mailto:santoshpk@juniper.net]

> > Sent: Saturday, October 18, 2014 9:34 A= M

> > To: Nobo Akiya (nobo); Henderickx, Wim = (Wim); Jeffrey Haas; rtg-

> > bfd@ietf.org; Min= gui Zhang

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

> >

> > Hello Nobo,

> >    Thanks again for your= comments on this. Please see my comments.

> >

> > > (a) unicast DOWN notification from= leaves.

> > > (b) multicast Poll of leaves.

> > > (c) unicast Poll of leaves.

> > > If we want to keep the in-band mec= hanism and remove out-of-band

> > mechanism, then preserve (a) and (b) bu= t remove (c). And that would be

> > my preference.

> > > Mingui, for your "TRILL Resil= ient Distribution Trees", do you see

> > > the need

> > for all [a-c] or just subsets?

> >

> > Does (a) alone not enough?

>

> Personally I think there's a value in leavin= g the option for the head to do in-

> band polling of leaves. In other words, if d= own notification from a leaf to the

> head, then there is no way for the head to f= ind out that leaf is no longer

> receiving.

>

> > Want to know if there are any applicati= on which wants to track tail

> > proactively? If so we can keep both (a)= and (b).

>

> More comments from the WG will be very helpf= ul. So far ...

>

> - Mingui brought up "TRILL Resilient Di= stribution Trees".

> - I brought up P2MP-TE Path Protection, whic= h I think both (a) and (b) will be

> useful.

>

> >

> > > Demux procedures is one, UDP port = is the other one (i.e. it is not

> > > specified

> > in this document).

> >

> > Yes, UDP port is not specified in the d= ocument. We can add this info

> > in base document itself? Every on ok wi= th this? Any suggestions?

>

> Demux procedures and UDP ports should go int= o the same document.

>

> So it's either:

>

> (a) put everything in draft-ietf-bfd-multipo= int.

>

> Or

>

> (b) spin off draft-ietf-bfd-multipoint-<d= ataplane> document per data plane.

>

> Thanks!

>

> -Nobo

>

> >

> >

> > Thanks

> > Santosh P K

> >

> >

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

> > From: Nobo Akiya (nobo) [m= ailto:nobo@cisco.com]

> > Sent: Wednesday, October 15, 2014 4:04 = AM

> > To: Santosh P K; Henderickx, Wim (Wim);= Jeffrey Haas;

> > rtg-bfd@ietf.org<= /a>; Mingui 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 comm= ents 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-iet= f-bfd-multipoint-04.txt

> > >

> > > Hello All,

> > >    Sorry for delay.= I am trying to elaborate what I meant by "active tail".

> > > Please also comment on other two i= tems that I have listed below

> > > which were raised by Prasad and No= bo in earlier discussions.

> > >

> > > Active tail:

> > > ------------

> > > As per discussion with implementer= s it looks like we don't see any

> > > use case scenario for head trackin= g tail. Currently there are

> > > multiple options given in draft fo= r head to track tail.

> > >      1.  = Unreliable Head Notification as per section 6.2

> > >      &nbs= p;            &= nbsp;  When tail detect timer expires it sends DOWN BFD packet to

> > head on

> > > reverse unicast path.

> > >      2. Semi-r= eliable Head Notification and Tail Solicitation as per

> > > section

> > > 6.3

> > >      &nbs= p;            &= nbsp;  A multipoint POLL with a combination of reverse unicast

> > path FINAL

> > > will help head to know if tail has= lost communication with head.

> > >      3. Reliab= le Head Notification as per section 6.4

> > >       &nb= sp;            =   A combination of multipoint POLL and unicast POLL will be

> > used by

> > > head to detect tail going down. Ta= il will make use of reverse

> > > unicast path to send FINAL packet = to head.

> >

> > One important characteristics is that:<= /p>

> > (1) allows the head to be notified of _= in-band_ failure by leaves.

> > (2) allows the head to poll leaves thro= ugh _in-band_ packets.

> > (3) allows the head to poll leaves thro= ugh _out-of-band_ unicast packets.

> >

> > Going back to what Wim wrote (thanks fo= r the comment Wim!):

> > [snip]

> > > In certain environment the trackin= g of the tails is happening by

> > > other

> > means.

> > > Example is Multicast VPN using MP-= BGP.

> > [snip]

> >

> > True, in the scenario described, (3) ad= ds very minimal value beyond

> > running multi-hop BFD session between B= GP peers.

> >

> > On the other hand (1) and (2) are in-ba= nd, and can detect failures

> > that other sessions like multi-hop BFD = sessions cannot. It does look

> > useful with technologies such as P2MP-T= E where:

> >

> > - leaves are constant

> > - has path-protection mechanism

> >

> > >

> > > We have below options:

> > >      1. Go wit= h simple "No Head Notification" as per section 6.1 in base

> > > draft and move rest of the section= s to Appendix or move to separate

> > draft?

> > > In this case On MultipointHead bfd= .ReportTailDown

> > >       &nb= sp;   will be set to 0 and we might not even need Multipoint= Client

> > > as we are not going to receive any= packets from tail. bfd.SilentTail

> > > will be set to 1 on MultipointTail=

> > >      2. Anothe= r option is to just keep "Unreliable Head Notification" as

> > > per section 6.2 and move/remove re= st of mechanism through which

> > > Multipoint head can detect tail go= ing down.

> > >       &nb= sp;   Meaning we need to move/remove Multicast POLL and unic= ast

> > POLL

> > > from MultipointHead.

> >

> > Another way to look at this is that:

> >

> > (a) unicast DOWN notification from leav= es.

> > (b) multicast Poll of leaves.

> > (c) unicast Poll of leaves.

> >

> > If we want to keep the in-band mechanis= m and remove out-of-band

> > mechanism, then preserve (a) and (b) bu= t 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 s= uggested 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 c= ontext of EVPN BFD draft that as

> > > per section 4.7 of this draft say<= /p>

> > >

> > >      " Th= e minimum amount of a priori information required both on the

> > > head

> > >       &nb= sp;  and tails is the binding to the multipoint path over which B= FD

> > > is running."

> > >

> > > Above text is brief and draft is A= F agnostic. Do we need to make

> > > text of Sec

> > > 4.7 and related sections more expl= icit? 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 dr= aft or it should be outside the

> > > scope of this document?

> >

> > Demux procedures is one, UDP port is th= e other one (i.e. it is not

> > specified in this document).

> >

> > 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-p= ort details for various data

> planes.

> >

> > Either will work, but the details are r= equired somewhere to interoperate.

> >

> > >

> > > Security consideration:

> > > ----------------------------

> > > As per Nobo's comment on this draf= t long back.  We need to add some

> > > suggestion in security considerati= on. 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 & Authenti= cation (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 Discrimina= tor values to leaves, which will

> > > cause many instances of Multipoint= Tail 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 se= ssion creation, it would be

> > > beneficial to highlight this point= and provide suggestions 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.<= /p>

> >

> > Right it would be a good idea how other= multipoint/multicast protocols

> > have addressed this.

> >

> > Thanks!

> >

> > -Nobo

> >

> > >

> > >

> > > Thanks

> > > Santosh P K

> > >

> > >

> > >

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

> > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]

> > > Sent: Friday, October 10, 2014 8:1= 8 PM

> > > To: Santosh P K; Henderickx, Wim (= Wim); Jeffrey Haas;

> > > rtg-bfd@ietf.org

> > > Subject: RE: I-D Action: draft-iet= f-bfd-multipoint-04.txt

> > >

> > > Santosh,

> > >

> > > It will helpful to clarify exactly= what you mean by "active tail".

> > >

> > > - Do you intend to keep tail repor= ting of the failure

> > > (bfd.ReportTailDown=3D1)?

> > > - Is it just unicast poll from hea= d that is being questioned for removal?

> > >

> > > Knowing exactly what aspect is bei= ng questioned for removal may

> > > provide a better base for good dis= cussions.

> > >

> > > Thanks!

> > >

> > > -Nobo

> > >

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

> > > > From: Santosh P K [mailto:santoshpk@juniper.net]

> > > > Sent: Thursday, October 09, 2= 014 10:39 PM

> > > > To: Henderickx, Wim (Wim); No= bo Akiya (nobo); Jeffrey Haas; rtg-

> > > > bfd@ietf.org

> > > > Subject: RE: I-D Action: draf= t-ietf-bfd-multipoint-04.txt

> > > >

> > > > Thanks Hendreickx for your re= ply.

> > > >

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

> > > > From: Henderickx, Wim (Wim) [= mailto:wim.henderickx@alcatel-

> > > > lucent.com]

> > > > Sent: Friday, October 10, 201= 4 12:29 AM

> > > > To: Nobo Akiya (nobo); Santos= h P K; Jeffrey Haas; rtg-bfd@ietf.org

> > > > Subject: Re: I-D Action: draf= t-ietf-bfd-multipoint-04.txt

> > > >

> > > > In certain environment the tr= acking of the tails is happening by

> > > > other

> > > means.

> > > > Example is Multicast VPN usin= g 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 r= emoving 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 failur= e of the multicast tree, which allows

> > > > >protections such as live-= live.

> > > > >

> > > > >What is essentially diffe= rent:

> > > > >

> > > > >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 requiremen= ts for the ingress/root to trigger some

> > > > >protections, then active = tail becomes a requirement. If there is

> > > > >no such requirements, the= n the active tail is an unnecessary

> > > > >portion of this document.=

> > > > >

> > > > >It'll be beneficial to he= ar your thoughts/comments to help gauge

> > > > >where we are on this matt= er as a WG.

> > > > >

> > > > >Comments/thoughts?

> > > > >

> > > > >Thanks!

> > > > >

> > > > >-Nobo

> > > > >

> > > > >> -----Original Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >> Santosh P K

> > > > >> Sent: Monday, Octobe= r 06, 2014 9:27 AM

> > > > >> To: Santosh P K; Jef= frey Haas; rtg-bfd@ietf.org

> > > > >> Subject: RE: I-D Act= ion: draft-ietf-bfd-multipoint-04.txt

> > > > >>

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

> > > > >>

> > > > >> Thanks

> > > > >> Santosh P K

> > > > >>

> > > > >> -----Original Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >> Santosh P K

> > > > >> Sent: Monday, Octobe= r 06, 2014 6:22 PM

> > > > >> To: Jeffrey Haas; rtg-bfd@ietf.org

> > > > >> Subject: RE: I-D Act= ion: 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 t= ale.

> > > > >> 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 Messag= e-----

> > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of<= /p>

> > > > >>Jeffrey Haas

> > > > >> Sent: Tuesday, Augus= t 19, 2014 7:38 PM

> > > > >> To: r= tg-bfd@ietf.org

> > > > >> Subject: Re: I-D Act= ion: draft-ietf-bfd-multipoint-04.txt

> > > > >>

> > > > >> Note that this consi= sts mostly of a re-publish with Santosh as

> > > > >>the new editor.

> > > > >> (And moving from .nr= off to .xml.)

> > > > >>

> > > > >> In the next few week= s, Santosh will be working with known

> > > > >>implementors to = edit the document to match implementation.

> > > > >>Ideally these edits w= ill be  complete prior to the next IETF

> > > > >>session in Honolulu.&= nbsp; This will put us a bit  past our original

> > > > >>milestone for publica= tion, 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 draf= t is a work item of the Bidirectional Forwarding

> > > > >> > Detection

> > > > >> Working Group of the= IETF.

> > > > >> >

> > > > >> >  &nbs= p;      Title      &= nbsp;    : BFD for Multipoint Networks

> > > > >> >  &nbs= p;      Authors      = ;   : Dave Katz

> > > > >> >  &nbs= p;            &= nbsp;           Dave Ward=

> > > > >> >  &nbs= p;            &= nbsp;           Santosh P= allagatti

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

> > > > >> >   &nb= sp;    Pages        =    : 27

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

> > > > >> >

> > > > >> > Abstract:

> > > > >> >  &nbs= p; This document describes extensions to the Bidirectional

> > Forwarding

> > > > >> >  &nbs= p; Detection (BFD) protocol for its use in multipoint and multicast

> > > > >> >  &nbs= p; networks.  Comments on this draft should be directed to rtg-

> > > > >> >  &nbs= p; bfd@ietf.org.

> > > > >> >

> > > > >> >

> > > > >> >

> > > > >> > The IETF datatr= acker status page for this draft is:

> > > > >> > https://datatracker.i= etf.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/r= fcdiff?url2=3Ddraft-ietf-bfd-multipoint-04

> > > > >> >

> > > > >> >

> > > > >> > Please note tha= t it may take a couple of minutes from the

> > > > >> > time of submiss= ion 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/in= ternet-drafts/

> > > > >

 

 --_000_D093325C10B94Ewimhenderickxalcatellucentcom_-- From nobody Sat Nov 22 01:04:23 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 37D1F1A00CF for ; Sat, 22 Nov 2014 01:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dun0Y7ItVEr for ; Sat, 22 Nov 2014 01:04:16 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B6D1A00C3 for ; Sat, 22 Nov 2014 01:04:16 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sat, 22 Nov 2014 09:04:13 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sat, 22 Nov 2014 09:04:13 +0000 From: Santosh P K To: "Henderickx, Wim (Wim)" , "Nobo Akiya (nobo)" , 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/gIAFryHggAVB2oCALmknIIABsM0AgAFbmqA= Date: Sat, 22 Nov 2014 09:04:12 +0000 Message-ID: <81ee5fcd79b84400a9dbac3c5543e946@CO2PR0501MB823.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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.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: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 040359335D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51914003)(377424004)(35774003)(24454002)(57704003)(51704005)(377454003)(199003)(479174003)(41574002)(53754006)(189002)(13464003)(46102003)(31966008)(92566001)(15975445006)(86362001)(74316001)(54356999)(4396001)(120916001)(62966003)(122556002)(99396003)(40100003)(76176999)(19580405001)(50986999)(77156002)(2656002)(107886001)(108616004)(19580395003)(33646002)(93886004)(106356001)(230783001)(64706001)(15202345003)(21056001)(107046002)(99286002)(101416001)(106116001)(87936001)(76576001)(20776003)(66066001)(95666004)(97736003)(105586002)(24736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/TMSuCoMWcW7fQeG2gQdzK0L-12A 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, 22 Nov 2014 09:04:21 -0000 Hello Wim, Thanks a lot for your inputs on this. This really helps to take this dra= ft forward.=20 >>1. Demultiplexing and UDP port number. >>It makes more sense to have a separate draft for this. Please let me know= if that is ok? If it benefits to have it in base draft itself then we can = have more sections for demux and port number to be used. >WH> it should be in the draft I believe Looks like TRILL will not have UDP and hence it will need different mechani= sm for demux. I had chat with Mingui and below is mail from him which expla= in how they absorb packet on tails.=20 [Snip] Since TRILL does not use UDP, no port number will be used. Instead, TRILL c= reates a data plane channel for BFD.=20 A new RBridge-Channel Ethertype 0x8946 has been assigned for this kind of c= hannel (http://tools.ietf.org/html/rfc7178#section-7.2). And RBridge Channe= l protocol numbers 0x002 and 0x003 are created for BFD Control and BFD Echo= respectively (http://tools.ietf.org/html/rfc7175#section-8). [Snip] Now for P2MP LSP's we can still UDP to absorb packet on tails (already ther= e are implementations doing this) and for TRILLs we can use RBridge channel= . I somehow feel too much of info will go in to base draft if we add demux = in to base draft. I am still open for others opinion :).=20 Thanks Santosh P K From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]=20 Sent: Friday, November 21, 2014 5:42 PM To: Santosh P K; Nobo Akiya (nobo); Jeffrey Haas; rtg-bfd@ietf.org; Mingui = Zhang Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt In-line From: Santosh P K Date: Thursday 20 November 2014 03:33 To: "Nobo Akiya (nobo)" , Wim Henderickx , Jeffrey Haas , "rtg-bfd@ietf.org" , Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello All, =A0=A0=A0 In IETF-91 I have presented open items. Below are the last few th= ings we need to close on.=20 =A0 1. Active tail. As discussed earlier, is this required in base draft? I spoke to all= implementers =A0and no one has active tail implemented yet. To push it for= RFC we need implementation so can we go ahead and move it to appendix or m= ay be new document? WH> I would propose we do the active tail in appendix or a separate draft =A0 2. Demultiplexing and UDP port number. It makes more sense to have a separate draft for this. Please let me= know if that is ok? If it benefits to have it in base draft itself then we= can have more sections for demux and port number to be used. WH> it should be in the draft I believe =A0 3. Echo mode supported? Echo mode does not fit in P2MP BFD. We can say it is not supported. = Does anyone see use of echo BFD in P2MP BFD? WH> I don't see a use case for this so far =A0 4. Increase interval? Draft suggest not to use POLL sequence and suggests to increase multiplier = first and then interval. If we have hardware implementation and don't want = to check complete packet every time received then change in packet may be i= ndicated with=20 POLL bit set. Since this is one to many mapping we can't have a complete PO= LL sequence and hence we need to suppress FINAL. Should we be going with PO= LL and suppress FINAL by setting desired RX interval set to 0? Please sugge= st any better idea.=20 =A0 5. bfd.ReportTailDown Draft suggests that head direct tails to send down notification. How= will head direct tail about failure notification to be sent or not? Is thi= s driven by configuration? At least the=A0 section 4.4.1 says so. It could = also be communicated to=20 received out of band? =A0 This should be out of scope of this document as we can't direct tail= s with in BFD packet. Any comments?=20 =A0 6. How packets get absorbed on tails? Few implementers use UDP port number to absorb BFD packet on tails. It woul= d be good to clarify about this in draft. Do we see any other way of absorb= ing packet on tail? =A0 =A0 7. Security consideration? No suggestions yet. =A0 =A0 Thanks Santosh P K=20 =A0 =A0 > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Wednesday, October 22, 2014 3:09 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 On] >=20 > WG, >=20 > I'd imagine many are busy ... being the last week before the cut-off and = all ... >=20 > But it'll be very helpful if you can chime in to help Santosh to take BFD > multipoint further. >=20 > [With Chair Hat Off] >=20 > Hi Santosh, >=20 > > -----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 > > > > Hello Nobo, > >=A0=A0=A0 Thanks again for your comments on this. Please see my comments= . > > > > > (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? > > > > 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 leaf = to the > head, then there is no way for the head to find out that leaf is no longe= r > receiving. >=20 > > Want to know if there are any application which wants to track tail > > proactively? If so we can keep both (a) and (b). >=20 > More comments from the WG will be very helpful. So far ... >=20 > - Mingui brought up "TRILL Resilient Distribution Trees". > - I brought up P2MP-TE Path Protection, which I think both (a) and (b) wi= ll be > useful. >=20 > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > specified > > in this document). > > > > Yes, UDP port is not specified in the document. We can add this info > > in base document itself? Every on ok with this? Any suggestions? >=20 > Demux procedures and UDP ports should go into the same document. >=20 > So it's either: >=20 > (a) put everything in draft-ietf-bfd-multipoint. >=20 > Or >=20 > (b) spin off draft-ietf-bfd-multipoint- document per data plan= e. >=20 > Thanks! >=20 > -Nobo >=20 > > > > > > Thanks > > Santosh P K > > > > > > -----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 > > > > [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 > > > > > > Hello All, > > >=A0=A0=A0 Sorry for delay. I am trying to elaborate what I meant by "a= ctive tail". > > > 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. > > > =A0=A0=A0=A0 1.=A0 Unreliable Head Notification as per section 6.2 > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When tai= l detect timer expires it sends DOWN BFD packet to > > head on > > > reverse unicast path. > > > =A0=A0=A0=A0 2. Semi-reliable Head Notification and Tail Solicitation= as per > > > section > > > 6.3 > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A multip= oint POLL with a combination of reverse unicast > > path FINAL > > > will help head to know if tail has lost communication with head. > > > =A0=A0=A0=A0 3. Reliable Head Notification as per section 6.4 > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A combinat= ion 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. > > > > 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 packet= s. > > > > 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] > > > > 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 other sessions like multi-hop BFD sessions cannot. It does look > > useful with technologies such as P2MP-TE where: > > > > - leaves are constant > > - has path-protection mechanism > > > > > > > > We have below options: > > > =A0=A0=A0=A0 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 > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0will be set to 0 and we might not even ne= ed MultipointClient > > > as we are not going to receive any packets from tail. bfd.SilentTail > > > will be set to 1 on MultipointTail > > > =A0=A0=A0=A0 2. Another option is to just keep "Unreliable Head Notif= ication" as > > > per section 6.2 and move/remove rest of mechanism through which > > > Multipoint head can detect tail going down. > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0Meaning 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? > > > > > =A0=A0=A0=A0 3. Jeff suggested that we move these sections to new dra= ft with > > > experimental status. > > > =A0=A0=A0=A0 4.=A0 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 > > > > > > =A0=A0=A0=A0 " The minimum amount of a priori information required bo= th on the > > > head > > > =A0=A0=A0=A0 =A0=A0=A0=A0and tails is the binding to the multipoint p= ath 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? > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > specified in this document). > > > > 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. > > > > Either will work, but the details are required somewhere to interoperat= e. > > > > > > > > Security consideration: > > > ---------------------------- > > > As per Nobo's comment on this draft long back.=A0 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 > > > "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. > > > > Right it would be a good idea how other multipoint/multicast protocols > > have addressed this. > > > > Thanks! > > > > -Nobo > > > > > > > > > > > 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 remo= val? > > > > > > 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 lea= ves. > > > > > > > > > >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=A0 "active tale" it is "activ= e 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, > > > > >>=A0=A0=A0 I am seeking comments on active tale section of this do= cument. > > > > >>I spoke to=A0 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=A0 no uses cases then we can move active tale sectio= n > > > > >>to appendix? We would=A0 like to make all the changes before IETF > > > > >>91 and push this for RFC. Any=A0 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=A0 edit the document to match implementation. > > > > >>Ideally these edits will be=A0 complete prior to the next IETF > > > > >>session in Honolulu.=A0 This will put us a bit=A0 past our origin= al > > > > >>milestone for publication, but still much better on track=A0 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. > > > > >> >=A0 This draft is a work item of the Bidirectional Forwarding > > > > >> > Detection > > > > >> Working Group of the IETF. > > > > >> > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = BFD for Multipoint Networks > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Dave= Katz > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Dave Ward > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Santosh Pallagatti > > > > >> > =A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-= bfd-multipoint-04.txt > > > > >> > =A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 27 > > > > >> > =A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 201= 4-08-12 > > > > >> > > > > > >> > Abstract: > > > > >> >=A0=A0=A0 This document describes extensions to the Bidirection= al > > Forwarding > > > > >> >=A0=A0=A0 Detection (BFD) protocol for its use in multipoint an= d multicast > > > > >> >=A0=A0=A0 networks.=A0 Comments on this draft should be directe= d to rtg- > > > > >> >=A0=A0=A0 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-0= 4 > > > > >> > > > > > >> > > > > > >> > 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/ > > > > > =A0 From nobody Sat Nov 22 17:16: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 ADCDA1A1A06 for ; Sat, 22 Nov 2014 17:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 1LSqh_0bpq-2 for ; Sat, 22 Nov 2014 17:15:51 -0800 (PST) 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 E3E1B1A1A27 for ; Sat, 22 Nov 2014 17:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10772; q=dns/txt; s=iport; t=1416705351; x=1417914951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6dO8cOPnXcG/tpM34QHn7RMkLvTsz+wZT0KhI4w+a2I=; b=fSckhRzQrwIyykghIRuTYjJ8LfaQZtQHLwoUt6GuGP+G2q/6RO7fgIpi Lrzbfmr3+u205Mc3ywhIoA39Zwof22WBPHLEI3pxbxKFDxjbnXx8JoIpT 5kxDQgBEqNSBOGoU6/xBtaL0YdjUaeiAN0GzGShVoQOcCACFIhLQ64DIE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAHQ0cVStJA2I/2dsb2JhbABcgmsjgS4E0wYCgQAWAQEBAQF9hAIBAQEEOjEJBQwEAgEIEQQBAQEKFAkHMhQJAwUBAQQOBQgRAogmAc01AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BaMQcGgymBHwWQOoIujU2DWYM4ikuECoN9eIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,440,1413244800"; d="scan'208";a="374483952" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP; 23 Nov 2014 01:15:50 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAN1FnAr000902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Nov 2014 01:15:49 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; Sat, 22 Nov 2014 19:15:49 -0600 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4Q Date: Sun, 23 Nov 2014 01:15:48 +0000 Message-ID: References: <20141116220332392193.5ed69d25@sniff.de> <20141121002512713064.799b449a@sniff.de> In-Reply-To: <20141121002512713064.799b449a@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.4] 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/QL2QQvkP_uwh-7n9bqH0_DBumUo 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, 23 Nov 2014 01:16:00 -0000 Hello BFD WG, Marc and I had some conversation on the topic of S-BFD alert discriminator = document structure, and converged on a direction. - We think that it is useful to describe both the problems and the solution= for the S-BFD alert discrimintor in a single document. - We also think the S-BFD alert discriminator is more like an exception mec= hanism, thus the mechanism should remain outside of the S-BFD base document= . Therefore, our converged recommendation to the WG is to keep the extended u= se-cases and the alert discriminator mechanism in the draft-akiya-bfd-seaml= ess-alert-discrim. This also means that no further changes are needed in draft-ietf-bfd-seamle= ss-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forwar= d if authors feel that it is ready. We would appreciate it if folks can chime in and state whether or not this = is an acceptable way forward. Thanks! -Nobo & Marc =09 > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, November 21, 2014 3:25 AM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hello Nobo, >=20 > (back from Hawaii or writing emails at the beach? ;-) >=20 >=20 > > Your view is then: > > > > Instead of: > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > keep the alert discriminator mechanism in the > > draft-akiya-bfd-seamless-alert-discrim. > > > > Do: > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > the draft-akiya-bfd-seamless-alert-discrim. > > > > Or > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- > base. >=20 > yes, exactly. >=20 >=20 > > Whether the S-BFD packets with alert discriminator are handled in HW > > or SW is an implementation choice. Similar to how IP router alert > > option & router alert label are handled, I do see handling of S-BFD > > packets with alert discriminator in the SW to be a reasonable > > approach, in which case the HW instruction for S-BFD packets with > > alert discriminator is to punt to SW for processing. >=20 > > Personally, I tend to recommend that alert discriminators are handled > > in the SW. Let's assume that you agree on this (hypothetically). In > > that case, would you still recommend the alert discriminator mechanism > > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > > keep it in the draft-akiya-bfd-seamless-alert-discrim? >=20 >=20 > That's probably where our different views come from :-) I would aim to > simplify the main idea of the draft so it _can_ easily be implemented eve= n > in hardware. >=20 > For the traceroute - my guess is TTL punts (if that mechanism to "deliver= " is > used) happen in software as many mechanism use this "trick" but if a > hardware can handle TTL punts, it can handle the diag code as well. I don= 't > see the document needs to adjust for the traceroute case. >=20 > For a basic reflector task, having a zero discriminator as a default refl= ector > discriminator would allow for very simple implementations (we discussed a > while ago a fixed discriminator value for simple broadband modems, > remember?). > For more complex equipment and scenarios, keeping it in hardware instead > of a software punt would maintain the ability of S-BFD to go up very quic= kly. >=20 >=20 > I tend to not see the zero discriminator as such a big exception, which m= ay > explain my idea to integrate it into the base document. And to keep it > compatible to hardware implementations. > Assuming you want to add more "special effects" in the future I can see w= hy > you have an extra document. I would propose to keep the zero-reflector > mentally aligned :-) with the base document and accordingly designed to > allow implementations to cover the zero-reflector together with "normal" > S-BFD > (read: may be in hardware). >=20 >=20 > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > S-BFD packets with alert discriminator. >=20 > Good - makes life simpler :-) >=20 >=20 > Regards, Marc >=20 >=20 > On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > > Thanks for providing your view. > > > > Please see in-line. > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, November 17, 2014 1:04 AM > >> To: Nobo Akiya (nobo) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: Seeking opinions on > >> draft-akiya-bfd-seamless-alert-discrim > >> > >> Hello Nobo and BFD experts, > >> > >> giving this document a closer look for the first time (ahem ;-) I > >> have a slightly different view. > >> > >> Having S-BFD use cases for the general S-BFD in an extra document > >> does improve the overall discussion and documentation, simply because > >> the base S-BFD is already complex enough, as are the use cases. > >> > >> But for such a relatively small document splitting off the reason why > >> the document exists is not improving the reading/understanding of this > draft. > >> Unless you decide to integrate the alert-discriminator document into > >> the base document, then obviously you use the use-case document. > > > > Your view is then: > > > > Instead of: > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > keep the alert discriminator mechanism in the > > draft-akiya-bfd-seamless-alert-discrim. > > > > Do: > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > the draft-akiya-bfd-seamless-alert-discrim. > > > > Or > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- > base. > > > > My thought was that (1) makes sense, but your view that (1) makes all > > the S-BFD documents set more complex to understand is a valid concern > > (it's always good to get fresh eyes on documents!). > > > >> > >> > >> For the integration of the technical aspect into the base document, I > >> think this is an idea worth to discuss. At the end what you need is > >> to add the rule for the zero discriminator to the reflector > >> behaviour; we managed this for standard BFD, we should be able to do > >> this for the reflector BFD as well > >> :-) > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > or SW is an implementation choice. Similar to how IP router alert > > option & router alert label are handled, I do see handling of S-BFD > > packets with alert discriminator in the SW to be a reasonable > > approach, in which case the HW instruction for S-BFD packets with > > alert discriminator is to punt to SW for processing. > > > >> For the diagnostic codes I'm not sure; it will complicate hardware > >> implementations (probably not a no-go problem though) and seems > >> otherwise not add a real value IMHO. > > > > If one really wants to handle them in the HW, that's a possibility. > > Although as you stated, it does complicate HW implementations and this > > is another reason for SW based implementations. > > > >> > >> So if there are already at this stage of S-BFD use case(s) for zero- > >> discriminator to bring up (some) sessions then I would propose to > >> consider the integration into the base document. This will also > >> guarantee that the zero-discriminator handling is as fast as the > >> "normal" reflection and is not on a slower exception path. > > > > Personally, I tend to recommend that alert discriminators are handled > > in the SW. Let's assume that you agree on this (hypothetically). In > > that case, would you still recommend the alert discriminator mechanism > > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > > keep it in the draft-akiya-bfd-seamless-alert-discrim? > > > >> > >> > >> > >> I have a question: so far S-BFD packets would be received, not > >> "picked out of the data stream". Receiving could be because the > >> destination IP would match or would be 127/8, the TTL would be zero > >> and so on. In the security section you say ... > >> > >> Conceptually the Alert Discriminator is similar to an IP Router Ale= rt > >> Option or an MPLS Router Alert Label. > >> > >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the > >> reflector) with an alert-discriminator out of the data stream that > >> otherwise would just pass this node? > >> I guess you don't want but I want to make sure I understand it correct= ly. > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > S-BFD packets with alert discriminator. So the statement regarding > > "Conceptually the Alert Discriminator is similar to an IP Router Alert > > Option or an MPLS Router Alert Label" should be re-stated and clarified= . > > > > Thanks! > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > >>> [Speaking as an individual S-BFD contributor] > >>> > >>> Hi BFD WG, > >>> > >>> There were couple of questions I need your input on > >>> draft-akiya-bfd-seamless-alert-discrim. > >>> > >>> > >>> (1) Should the "extended" S-BFD use cases move to > >>> draft-ietf-bfd-seamless-use-case? > >>> > >>> My opinion is yes. Once the "extended" S-BFD use cases have been > >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should > >>> try to move draft-ietf-bfd-seamless-use-case forward. > >>> > >>> How does the WG feel about this? > >>> > >>> > >>> (2) Should the alert discriminator proposal move to > >>> draft-ietf-bfd-seamless-base? > >>> > >>> My opinion is no . Instead we should position this as an optional > >>> feature of S-BFD (hence separate document than the base), especially > >>> considering we likely need to think through additional security > >>> concerns > >> raised by this. > >>> > >>> A question was raised by Greg on how does a node find out if the > >>> target supports the optional alert discriminator or not. We can > >>> define a mandatory diagnostic value that must be implemented when > >>> the alert discriminator is implemented. One can send an S-BFD > >>> control packet with the alert discriminator with this diagnostic > >>> value to check if the target supports the alert discriminator mechani= sm. > >>> > >>> How does the WG feel about this? > >>> > >>> > >>> Thanks! > >>> > >>> -Nobo > >>> > > From nobody Sat Nov 22 17:57: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 131181A1A4F for ; Sat, 22 Nov 2014 17:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 btlshdIi6Fwz for ; Sat, 22 Nov 2014 17:57:49 -0800 (PST) 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 2D2401A1A4E for ; Sat, 22 Nov 2014 17:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23440; q=dns/txt; s=iport; t=1416707870; x=1417917470; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Uy50bLZplr371U7KUWf986L8fue+Ap9HRBZR9WXa0Jg=; b=ktOs8XiAPPdApGuZ3fQo/LXNoFEhB3qIlCOVk13uASF2GJxnkyRKEfBY nkgyLwezoLnlsHYVitteMNwORQipf9eWn3BkKDcTcf/MiPscpsohQDqc4 5nUl7pOYXyHYR7/PwB5YyYMctps3Nw0ZZeF8Xv+oUOLWPiEElkA1ulfiJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAMs9cVStJV2U/2dsb2JhbABcgmsjVVQFBMwbhmoCgQAWAQEBAQF9hAIBAQEDARprBAIBCBEDAQEBAQodBzIUCQgCBAESCAGILwkBBwXNLwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQOgEBHjgGgymBHwWGToUbhFGCLoRliGg/gxqKR4M8hAqCChiBW3gBgQUFAQMXIoEDAQEB X-IronPort-AV: E=Sophos;i="5.07,440,1413244800"; d="scan'208";a="374522009" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 23 Nov 2014 01:57:46 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAN1vjNx017098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Nov 2014 01:57:45 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sat, 22 Nov 2014 19:57:45 -0600 From: "Nobo Akiya (nobo)" To: "Henderickx, Wim (Wim)" , Santosh P K , 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+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmCALuR+AIABnSoAgAINGWA= Date: Sun, 23 Nov 2014 01:57:45 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.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.21.112.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/o_WRYCNp2VwIt9Bb8-SwdAjCv0I 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, 23 Nov 2014 01:57:54 -0000 Hi Santosh, Wim, > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel- > lucent.com] > Sent: Friday, November 21, 2014 7:12 AM > To: Santosh P K; Nobo Akiya (nobo); Jeffrey Haas; rtg-bfd@ietf.org; Mingu= i > Zhang > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > In-line >=20 > From: Santosh P K > Date: Thursday 20 November 2014 03:33 > To: "Nobo Akiya (nobo)" , Wim Henderickx > , Jeffrey Haas , "rtg- > bfd@ietf.org" , Mingui Zhang > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hello All, > =A0=A0=A0 In IETF-91 I have presented open items. Below are the last few = things we > need to close on. >=20 > 1.=A0=A0=A0=A0=A0=A0 Active tail. > As discussed earlier, is this required in base draft? I spoke to a= ll > implementers =A0and no one has active tail implemented yet. To push it fo= r > RFC we need implementation so can we go ahead and move it to appendix > or may be new document? >=20 > WH> I would propose we do the active tail in appendix or a separate draft [NOBO] Wim, can you clarify which you mean? A) You propose reliable head notification to be moved. B) You propose semi-reliable and reliable head notifications to be moved. C) You propose unreliable, semi-reliable and reliable head notifications to= be moved. You can find the description of each notifications in page 4 of http://www.= ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. My preference will be (A). >=20 > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > It makes more sense to have a separate draft for this. Please let = me > know if that is ok? If it benefits to have it in base draft itself then w= e can > have more sections for demux and port number to be used. >=20 > WH> it should be in the draft I believe [NOBO] So ... Option 1 is to describe the demux codepoint & procedures in the bfd-multipo= int document. Option 2 is to describe the demux codepoint & procedures in separate data p= lane document(s). It sounds like Santosh is preferring Option 2 while Wim is preferring optio= n 1. Perhaps there's an Option 3. The bfd-multipoint document to describe one or two basic data plane demux c= odepoint & procedures cleanly in a separate section (ex: IP and MPLS). Othe= r data planes documents (ex: TRILL) can update the demux section of the bfd= -multipoint document. Just thinking out loud ... >=20 > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > Echo mode does not fit in P2MP BFD. We can say it is not supported= . > Does anyone see use of echo BFD in P2MP BFD? >=20 > WH> I don't see a use case for this so far [NOBO] Agree, I see no value in the multipoint document considering the ech= o inside the scope. >=20 > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > Draft suggest not to use POLL sequence and suggests to increase multiplie= r > first and then interval. If we have hardware implementation and don't wan= t > to check complete packet every time received then change in packet may be > indicated with > POLL bit set. Since this is one to many mapping we can't have a complete > POLL sequence and hence we need to suppress FINAL. Should we be going > with POLL and suppress FINAL by setting desired RX interval set to 0? Ple= ase > suggest any better idea. [NOBO] If we keep the semi-reliable head notification, then I would have ex= pected P/F (from head to tails) to just work? >=20 > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > Draft suggests that head direct tails to send down notification. H= ow will > head direct tail about failure notification to be sent or not? Is this dr= iven by > configuration? At least the=A0 section 4.4.1 says so. It could also be > communicated to > received out of band? >=20 > This should be out of scope of this document as we can't direct ta= ils with > in BFD packet. Any comments? [NOBO] This is something which can be configured, thus out of scope [for no= w] should be fine. One reason that I have been pushing to keep semi-reliabl= e head notification is that it can catch instances of odd cases like tails = not having consistent configurations ... i.e, only some tails notify and so= me don't. Head doing the in-band polling can discover the available tails, = becomes more of a fail-safe mechanism. >=20 > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > Few implementers use UDP port number to absorb BFD packet on tails. It > would be good to clarify about this in draft. Do we see any other way of > absorbing packet on tail? [NOBO] For IP: - UDP port. For MPLS: - 127/8 and UDP port. - UHP does not require bootstrapping but PHP will require bootstrapping. Thanks! -Nobo, as individual contributor >=20 > 7.=A0=A0=A0=A0=A0=A0 Security consideration? > No suggestions yet. >=20 >=20 > Thanks > Santosh P K >=20 >=20 > > -----Original Message----- > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > Sent: Wednesday, October 22, 2014 3:09 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 > > > > [With Chair Hat On] > > > > WG, > > > > I'd imagine many are busy ... being the last week before the cut-off an= d > all ... > > > > But it'll be very helpful if you can chime in to help Santosh to take B= FD > > multipoint 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 > > > > > > Hello Nobo, > > >=A0=A0=A0 Thanks again for your comments on this. Please see my commen= ts. > > > > > > > (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 b= e > > > my preference. > > > > Mingui, for your "TRILL Resilient Distribution Trees", do you see > > > > the need > > > for all [a-c] or just subsets? > > > > > > Does (a) alone not enough? > > > > Personally I think there's a value in leaving the option for the head t= o 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 no lon= ger > > 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. > > > > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > > specified > > > in this document). > > > > > > Yes, UDP port is not specified in the document. We can add this info > > > 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 > > > > > > > > > > > Thanks > > > Santosh P K > > > > > > > > > -----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 > > > > > > [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 > > > > > > > > Hello All, > > > >=A0=A0=A0 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. > > > > > > > > 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. > > > > =A0=A0=A0=A0 1.=A0 Unreliable Head Notification as per section 6.2 > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When t= ail detect timer expires it sends DOWN BFD packet to > > > head on > > > > reverse unicast path. > > > > =A0=A0=A0=A0 2. Semi-reliable Head Notification and Tail Solicitati= on as per > > > > section > > > > 6.3 > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A mult= ipoint POLL with a combination of reverse unicast > > > path FINAL > > > > will help head to know if tail has lost communication with head. > > > > =A0=A0=A0=A0 3. Reliable Head Notification as per section 6.4 > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A combin= ation 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. > > > > > > 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 pack= ets. > > > > > > 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] > > > > > > 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 other sessions like multi-hop BFD sessions cannot. It does look > > > useful with technologies such as P2MP-TE where: > > > > > > - leaves are constant > > > - has path-protection mechanism > > > > > > > > > > > We have below options: > > > > =A0=A0=A0=A0 1. Go with simple "No Head Notification" as per sectio= n 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 > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0will be set to 0 and we might not even = need MultipointClient > > > > as we are not going to receive any packets from tail. bfd.SilentTai= l > > > > will be set to 1 on MultipointTail > > > > =A0=A0=A0=A0 2. Another option is to just keep "Unreliable Head Not= ification" as > > > > per section 6.2 and move/remove rest of mechanism through which > > > > Multipoint head can detect tail going down. > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0Meaning we need to move/remove Multicas= t 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 b= e > > > my preference. > > > > > > Mingui, for your "TRILL Resilient Distribution Trees", do you see the > > > need for all [a-c] or just subsets? > > > > > > > =A0=A0=A0=A0 3. Jeff suggested that we move these sections to new d= raft with > > > > experimental status. > > > > =A0=A0=A0=A0 4.=A0 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 > > > > > > > > =A0=A0=A0=A0 " The minimum amount of a priori information required = both on the > > > > head > > > > =A0=A0=A0=A0 =A0=A0=A0=A0and 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? > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > specified in this document). > > > > > > 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. > > > > > > Either will work, but the details are required somewhere to interoper= ate. > > > > > > > > > > > Security consideration: > > > > ---------------------------- > > > > As per Nobo's comment on this draft long back.=A0 We need to add so= me > > > > 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 > > > > "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. > > > > > > Right it would be a good idea how other multipoint/multicast protocol= s > > > have addressed this. > > > > > > Thanks! > > > > > > -Nobo > > > > > > > > > > > > > > > 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 re= moval? > > > > > > > > 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.or= g > > > > > 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 l= eaves. > > > > > > > > > > > >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=A0 "active tale" it is "act= ive 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, > > > > > >>=A0=A0=A0 I am seeking comments on active tale section of this = document. > > > > > >>I spoke to=A0 few implementers and found that no one really fin= ds > > > > > >>use case for active tale. > > > > > >> Does anyone on this forum feel that we might need active tale? > > > > > >>If there are=A0 no uses cases then we can move active tale sect= ion > > > > > >>to appendix? We would=A0 like to make all the changes before IE= TF > > > > > >>91 and push this for RFC. Any=A0 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=A0 edit the document to match implementation. > > > > > >>Ideally these edits will be=A0 complete prior to the next IETF > > > > > >>session in Honolulu.=A0 This will put us a bit=A0 past our orig= inal > > > > > >>milestone for publication, but still much better on track=A0 th= an > > > > > >>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. > > > > > >> >=A0 This draft is a work item of the Bidirectional Forwarding > > > > > >> > Detection > > > > > >> Working Group of the IETF. > > > > > >> > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = : BFD for Multipoint Networks > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Da= ve Katz > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Dave Ward > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Santosh Pallagatti > > > > > >> > =A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-iet= f-bfd-multipoint-04.txt > > > > > >> > =A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 27 > > > > > >> > =A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2= 014-08-12 > > > > > >> > > > > > > >> > Abstract: > > > > > >> >=A0=A0=A0 This document describes extensions to the Bidirecti= onal > > > Forwarding > > > > > >> >=A0=A0=A0 Detection (BFD) protocol for its use in multipoint = and multicast > > > > > >> >=A0=A0=A0 networks.=A0 Comments on this draft should be direc= ted to rtg- > > > > > >> >=A0=A0=A0 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/ > > > > > > >=20 From nobody Sat Nov 22 18:35: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 A96691A1A66 for ; Sat, 22 Nov 2014 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUpyWsqkYGwZ for ; Sat, 22 Nov 2014 18:35:30 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA631A1A63 for ; Sat, 22 Nov 2014 18:35:29 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 23 Nov 2014 02:35:26 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sun, 23 Nov 2014 02:35:26 +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/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEA== Date: Sun, 23 Nov 2014 02:35:25 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.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: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 04041A2886 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377424004)(53754006)(199003)(377454003)(13464003)(41574002)(51704005)(24454002)(51914003)(35774003)(479174003)(57704003)(86362001)(2656002)(106356001)(64706001)(40100003)(107046002)(99286002)(107886001)(93886004)(95666004)(105586002)(21056001)(33646002)(106116001)(66066001)(76576001)(20776003)(230783001)(76176999)(77156002)(15202345003)(108616004)(74316001)(120916001)(15975445006)(97736003)(99396003)(101416001)(92566001)(50986999)(54356999)(4396001)(31966008)(87936001)(62966003)(122556002)(19580405001)(46102003)(19580395003)(24736002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/GX6Jni5vr0Ah7QTfmkgiJPnYPYk 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, 23 Nov 2014 02:35:36 -0000 Hello Nobo, Thanks for your reply. Please see inline. =09 > > 1.=A0=A0=A0=A0=A0=A0 Active tail. > > As discussed earlier, is this required in base draft? I spoke > > to all implementers =A0and no one has active tail implemented yet. To > > push it for RFC we need implementation so can we go ahead and move it > > to appendix or may be new document? > > > > WH> I would propose we do the active tail in appendix or a separate > > WH> draft >=20 > [NOBO] Wim, can you clarify which you mean? >=20 > A) You propose reliable head notification to be moved. > B) You propose semi-reliable and reliable head notifications to be moved. > C) You propose unreliable, semi-reliable and reliable head notifications = to be > moved. >=20 > You can find the description of each notifications in page 4 of > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. >=20 > My preference will be (A). >=20 Moving reliable head notification to appendix or new document you mean :) ?= =20 > > > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > > It makes more sense to have a separate draft for this. Please > > let me know if that is ok? If it benefits to have it in base draft > > itself then we can have more sections for demux and port number to be > used. > > > > WH> it should be in the draft I believe >=20 > [NOBO] So ... >=20 > Option 1 is to describe the demux codepoint & procedures in the bfd- > multipoint document. > Option 2 is to describe the demux codepoint & procedures in separate data > plane document(s). >=20 > It sounds like Santosh is preferring Option 2 while Wim is preferring opt= ion 1. >=20 > Perhaps there's an Option 3. >=20 > The bfd-multipoint document to describe one or two basic data plane demux > codepoint & procedures cleanly in a separate section (ex: IP and MPLS). > Other data planes documents (ex: TRILL) can update the demux section of > the bfd-multipoint document. Just thinking out loud ... >=20 Currently in document it tries to explain how to demux for IP only in secti= on 4.8. We can add more text for clarity.=20 I am ok with option 1 where all procedure dumped in single document but I a= m worried that in future some other data plane wants a new way of demultipl= exing then we may need to change the base document again?=20 > > > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > > Echo mode does not fit in P2MP BFD. We can say it is not support= ed. > > Does anyone see use of echo BFD in P2MP BFD? > > > > WH> I don't see a use case for this so far >=20 > [NOBO] Agree, I see no value in the multipoint document considering the > echo inside the scope. Thanks. > > > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > > Draft suggest not to use POLL sequence and suggests to increase > > multiplier first and then interval. If we have hardware implementation > > and don't want to check complete packet every time received then > > change in packet may be indicated with POLL bit set. Since this is one > > to many mapping we can't have a complete POLL sequence and hence we > > need to suppress FINAL. Should we be going with POLL and suppress > > FINAL by setting desired RX interval set to 0? Please suggest any > > better idea. >=20 > [NOBO] If we keep the semi-reliable head notification, then I would have > expected P/F (from head to tails) to just work? With semi-reliable head notification you want to have complete POLL sequenc= e for interval negotiation? One to many mapping will have issues with comp= lete POLL sequence. Can you elaborate how this will help?=20 > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > > Draft suggests that head direct tails to send down > > notification. How will head direct tail about failure notification to > > be sent or not? Is this driven by configuration? At least the=A0 sectio= n > > 4.4.1 says so. It could also be communicated to > > received out of band? > > > > This should be out of scope of this document as we can't direct > > tails with in BFD packet. Any comments? >=20 > [NOBO] This is something which can be configured, thus out of scope [for > now] should be fine. One reason that I have been pushing to keep semi- > reliable head notification is that it can catch instances of odd cases li= ke tails > not having consistent configurations ... i.e, only some tails notify and = some > don't. Head doing the in-band polling can discover the available tails, > becomes more of a fail-safe mechanism. Agreed. It makes sense to have semi-reliable here.=20 >=20 > > > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > > Few implementers use UDP port number to absorb BFD packet on tails. It > > would be good to clarify about this in draft. Do we see any other way > > of absorbing packet on tail? >=20 > [NOBO] >=20 > For IP: > - UDP port. >=20 > For MPLS: > - 127/8 and UDP port. > - UHP does not require bootstrapping but PHP will require bootstrapping. For TILLS: A new data channel.=20 Thanks Santosh P K=20 > > > > > -----Original Message----- > > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > > Sent: Wednesday, October 22, 2014 3:09 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 > > > > > > [With Chair Hat On] > > > > > > WG, > > > > > > I'd imagine many are busy ... being the last week before the cut-off > > > and > > all ... > > > > > > But it'll be very helpful if you can chime in to help Santosh to > > > take BFD multipoint 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 > > > > > > > > Hello Nobo, > > > >=A0=A0=A0 Thanks again for your comments on this. Please see my comm= ents. > > > > > > > > > (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? > > > > > > > > Does (a) alone not enough? > > > > > > 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 > > > leaf to > > the > > > head, then there is no way for the head to find out that leaf is no > > > 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. > > > > > > > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is > > > > > not specified > > > > in this document). > > > > > > > > Yes, UDP port is not specified in the document. We can add this > > > > info in base document itself? Every on ok with this? Any suggestion= s? > > > > > > 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 > > > > > > > > > > > > > > > Thanks > > > > Santosh P K > > > > > > > > > > > > -----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 > > > > > > > > [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 > > > > > > > > > > Hello All, > > > > >=A0=A0=A0 Sorry for delay. I am trying to elaborate what I meant b= y "active tail". > > > > > 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. > > > > > =A0=A0=A0=A0 1.=A0 Unreliable Head Notification as per section 6.= 2 > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When= tail detect timer expires it sends > > > > > DOWN BFD packet to > > > > head on > > > > > reverse unicast path. > > > > > =A0=A0=A0=A0 2. Semi-reliable Head Notification and Tail Solicita= tion as > > > > > per section > > > > > 6.3 > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A mu= ltipoint POLL with a combination of > > > > > reverse unicast > > > > path FINAL > > > > > will help head to know if tail has lost communication with head. > > > > > =A0=A0=A0=A0 3. Reliable Head Notification as per section 6.4 > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A comb= ination 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. > > > > > > > > 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 > > > > means. > > > > > 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 other sessions like multi-hop BFD sessions cannot. It does > > > > look useful with technologies such as P2MP-TE where: > > > > > > > > - leaves are constant > > > > - has path-protection mechanism > > > > > > > > > > > > > > We have below options: > > > > > =A0=A0=A0=A0 1. Go with simple "No Head Notification" as per sect= ion 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 > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0will be set to 0 and we might not eve= n need > > > > > MultipointClient as we are not going to receive any packets from > > > > > tail. bfd.SilentTail will be set to 1 on MultipointTail > > > > > =A0=A0=A0=A0 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. > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0Meaning we need to move/remove Multic= ast 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? > > > > > > > > > =A0=A0=A0=A0 3. Jeff suggested that we move these sections to new= draft > > > > > with experimental status. > > > > > =A0=A0=A0=A0 4.=A0 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 > > > > > > > > > > =A0=A0=A0=A0 " The minimum amount of a priori information require= d both > > > > > on the head > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0and tails is the binding to the multipoi= nt 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? > > > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is not > > > > specified in this document). > > > > > > > > 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. > > > > > > > > Either will work, but the details are required somewhere to > interoperate. > > > > > > > > > > > > > > Security consideration: > > > > > ---------------------------- > > > > > As per Nobo's comment on this draft long back.=A0 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 session= s to > get created. > > > > > Draft does say [create or discard] choice is outside the scope (i= n > 4.16.2). > > > > > But given the dynamic nature of session creation, it would be > > > > > beneficial to highlight this point and provide suggestions 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. > > > > > > > > Right it would be a good idea how other multipoint/multicast > > > > protocols have addressed this. > > > > > > > > Thanks! > > > > > > > > -Nobo > > > > > > > > > > > > > > > > > > > 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 = removal? > > > > > > > > > > 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 > 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=A0 "active tale" it is "a= ctive 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, > > > > > > >>=A0=A0=A0 I am seeking comments on active tale section of thi= s document. > > > > > > >>I spoke to=A0 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 tal= e? > > > > > > >>If there are=A0 no uses cases then we can move active tale > > > > > > >>section to appendix? We would=A0 like to make all the changes > > > > > > >>before IETF > > > > > > >>91 and push this for RFC. Any=A0 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=A0 edit the document to match implementation. > > > > > > >>Ideally these edits will be=A0 complete prior to the next IET= F > > > > > > >>session in Honolulu.=A0 This will put us a bit=A0 past our > > > > > > >>original milestone for publication, but still much better on > > > > > > >>track=A0 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. > > > > > > >> >=A0 This draft is a work item of the Bidirectional > > > > > > >> >Forwarding Detection > > > > > > >> Working Group of the IETF. > > > > > > >> > > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 : BFD for Multipoint Networks > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : = Dave Katz > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Dave Ward > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Santosh Pallagatti > > > > > > >> > =A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-i= etf-bfd-multipoint-04.txt > > > > > > >> > =A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2= 7 > > > > > > >> > =A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 := 2014-08-12 > > > > > > >> > > > > > > > >> > Abstract: > > > > > > >> >=A0=A0=A0 This document describes extensions to the > > > > > > >> >Bidirectional > > > > Forwarding > > > > > > >> >=A0=A0=A0 Detection (BFD) protocol for its use in multipoin= t and > > > > > > >> >multicast > > > > > > >> >=A0=A0=A0 networks.=A0 Comments on this draft should be dir= ected > > > > > > >> >to rtg- > > > > > > >> >=A0=A0=A0 bfd@ietf.org. > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > The IETF datatracker status page for this draft is: > > > > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoin > > > > > > >> > t/ > > > > > > >> > > > > > > > >> > 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-multipoi= n > > > > > > >> > t-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 Sat Nov 22 18:39: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 6F9E51A1A6A for ; Sat, 22 Nov 2014 18:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIrh5HBfp8Dl for ; Sat, 22 Nov 2014 18:39:10 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0118.outbound.protection.outlook.com [207.46.100.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455E21A1A66 for ; Sat, 22 Nov 2014 18:39:10 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 23 Nov 2014 02:39:08 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sun, 23 Nov 2014 02:39:08 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACbC/IAAMCf94AADX0MAABVlhIAAALQ2tA= Date: Sun, 23 Nov 2014 02:39:07 +0000 Message-ID: <4ecc79f51fdf4a59b8871dd8eed9d25d@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141116220332392193.5ed69d25@sniff.de> <20141121002512713064.799b449a@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 04041A2886 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(54094003)(24454002)(52544003)(13464003)(52604005)(199003)(51704005)(377454003)(41574002)(105586002)(106356001)(76576001)(99286002)(95666004)(21056001)(107046002)(230783001)(64706001)(561944003)(108616004)(40100003)(101416001)(93886004)(66066001)(33646002)(31966008)(120916001)(97736003)(46102003)(92566001)(20776003)(99396003)(122556002)(2656002)(86362001)(19580395003)(19580405001)(87936001)(74316001)(62966003)(77156002)(50986999)(54356999)(76176999)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/_N5GDWA3gAHjV0LHjQsRVJ8sYcw 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, 23 Nov 2014 02:39:13 -0000 Nobo and Marc, I completely agree with having a separate document for alert discriminat= or and progress with use-case document. Thanks Santosh P K=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya > (nobo) > Sent: Sunday, November 23, 2014 6:46 AM > To: Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hello BFD WG, >=20 > Marc and I had some conversation on the topic of S-BFD alert discriminato= r > document structure, and converged on a direction. >=20 > - We think that it is useful to describe both the problems and the soluti= on for > the S-BFD alert discrimintor in a single document. > - We also think the S-BFD alert discriminator is more like an exception > mechanism, thus the mechanism should remain outside of the S-BFD base > document. >=20 > Therefore, our converged recommendation to the WG is to keep the > extended use-cases and the alert discriminator mechanism in the draft- > akiya-bfd-seamless-alert-discrim. >=20 > This also means that no further changes are needed in draft-ietf-bfd- > seamless-use-case, and the draft-ietf-bfd-seamless-use-case can progresse= d > forward if authors feel that it is ready. >=20 > We would appreciate it if folks can chime in and state whether or not thi= s is > an acceptable way forward. >=20 > Thanks! >=20 > -Nobo & Marc >=20 > > -----Original Message----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, November 21, 2014 3:25 AM > > To: Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: RE: Seeking opinions on > > draft-akiya-bfd-seamless-alert-discrim > > > > Hello Nobo, > > > > (back from Hawaii or writing emails at the beach? ;-) > > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > yes, exactly. > > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the dr= aft- > akiya-bfd-seamless-alert-discrim? > > > > > > That's probably where our different views come from :-) I would aim to > > simplify the main idea of the draft so it _can_ easily be implemented > > even in hardware. > > > > For the traceroute - my guess is TTL punts (if that mechanism to > > "deliver" is > > used) happen in software as many mechanism use this "trick" but if a > > hardware can handle TTL punts, it can handle the diag code as well. I > > don't see the document needs to adjust for the traceroute case. > > > > For a basic reflector task, having a zero discriminator as a default > > reflector discriminator would allow for very simple implementations > > (we discussed a while ago a fixed discriminator value for simple > > broadband modems, remember?). > > For more complex equipment and scenarios, keeping it in hardware > > instead of a software punt would maintain the ability of S-BFD to go up= very > quickly. > > > > > > I tend to not see the zero discriminator as such a big exception, > > which may explain my idea to integrate it into the base document. And > > to keep it compatible to hardware implementations. > > Assuming you want to add more "special effects" in the future I can > > see why you have an extra document. I would propose to keep the > > zero-reflector mentally aligned :-) with the base document and > > accordingly designed to allow implementations to cover the zero-reflect= or > together with "normal" > > S-BFD > > (read: may be in hardware). > > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. > > > > Good - makes life simpler :-) > > > > > > Regards, Marc > > > > > > On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > > > Hi Marc, > > > > > > Thanks for providing your view. > > > > > > Please see in-line. > > > > > >> -----Original Message----- > > >> From: Marc Binderberger [mailto:marc@sniff.de] > > >> Sent: Monday, November 17, 2014 1:04 AM > > >> To: Nobo Akiya (nobo) > > >> Cc: rtg-bfd@ietf.org > > >> Subject: Re: Seeking opinions on > > >> draft-akiya-bfd-seamless-alert-discrim > > >> > > >> Hello Nobo and BFD experts, > > >> > > >> giving this document a closer look for the first time (ahem ;-) I > > >> have a slightly different view. > > >> > > >> Having S-BFD use cases for the general S-BFD in an extra document > > >> does improve the overall discussion and documentation, simply > > >> because the base S-BFD is already complex enough, as are the use > cases. > > >> > > >> But for such a relatively small document splitting off the reason > > >> why the document exists is not improving the reading/understanding > > >> of this > > draft. > > >> Unless you decide to integrate the alert-discriminator document > > >> into the base document, then obviously you use the use-case > document. > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > > > My thought was that (1) makes sense, but your view that (1) makes > > > all the S-BFD documents set more complex to understand is a valid > > > concern (it's always good to get fresh eyes on documents!). > > > > > >> > > >> > > >> For the integration of the technical aspect into the base document, > > >> I think this is an idea worth to discuss. At the end what you need > > >> is to add the rule for the zero discriminator to the reflector > > >> behaviour; we managed this for standard BFD, we should be able to > > >> do this for the reflector BFD as well > > >> :-) > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > >> For the diagnostic codes I'm not sure; it will complicate hardware > > >> implementations (probably not a no-go problem though) and seems > > >> otherwise not add a real value IMHO. > > > > > > If one really wants to handle them in the HW, that's a possibility. > > > Although as you stated, it does complicate HW implementations and > > > this is another reason for SW based implementations. > > > > > >> > > >> So if there are already at this stage of S-BFD use case(s) for > > >> zero- discriminator to bring up (some) sessions then I would > > >> propose to consider the integration into the base document. This > > >> will also guarantee that the zero-discriminator handling is as fast > > >> as the "normal" reflection and is not on a slower exception path. > > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the dr= aft- > akiya-bfd-seamless-alert-discrim? > > > > > >> > > >> > > >> > > >> I have a question: so far S-BFD packets would be received, not > > >> "picked out of the data stream". Receiving could be because the > > >> destination IP would match or would be 127/8, the TTL would be zero > > >> and so on. In the security section you say ... > > >> > > >> Conceptually the Alert Discriminator is similar to an IP Router A= lert > > >> Option or an MPLS Router Alert Label. > > >> > > >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to > > >> the > > >> reflector) with an alert-discriminator out of the data stream that > > >> otherwise would just pass this node? > > >> I guess you don't want but I want to make sure I understand it corre= ctly. > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. So the statement regarding > > > "Conceptually the Alert Discriminator is similar to an IP Router > > > Alert Option or an MPLS Router Alert Label" should be re-stated and > clarified. > > > > > > Thanks! > > > > > > -Nobo > > > > > >> > > >> > > >> Regards, Marc > > >> > > >> > > >> > > >> > > >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > > >>> [Speaking as an individual S-BFD contributor] > > >>> > > >>> Hi BFD WG, > > >>> > > >>> There were couple of questions I need your input on > > >>> draft-akiya-bfd-seamless-alert-discrim. > > >>> > > >>> > > >>> (1) Should the "extended" S-BFD use cases move to > > >>> draft-ietf-bfd-seamless-use-case? > > >>> > > >>> My opinion is yes. Once the "extended" S-BFD use cases have been > > >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should > > >>> try to move draft-ietf-bfd-seamless-use-case forward. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> (2) Should the alert discriminator proposal move to > > >>> draft-ietf-bfd-seamless-base? > > >>> > > >>> My opinion is no . Instead we should position this as an optional > > >>> feature of S-BFD (hence separate document than the base), > > >>> especially considering we likely need to think through additional > > >>> security concerns > > >> raised by this. > > >>> > > >>> A question was raised by Greg on how does a node find out if the > > >>> target supports the optional alert discriminator or not. We can > > >>> define a mandatory diagnostic value that must be implemented when > > >>> the alert discriminator is implemented. One can send an S-BFD > > >>> control packet with the alert discriminator with this diagnostic > > >>> value to check if the target supports the alert discriminator > mechanism. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> Thanks! > > >>> > > >>> -Nobo > > >>> > > > From nobody Sat Nov 22 20:30:18 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 195F01A1A98 for ; Sat, 22 Nov 2014 20:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.601 X-Spam-Level: X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlqL-bBIpqfO for ; Sat, 22 Nov 2014 20:30:12 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573D11A1A8C for ; Sat, 22 Nov 2014 20:30:11 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-54-54710398512c Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4F.CC.25146.89301745; Sat, 22 Nov 2014 22:43:53 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Sat, 22 Nov 2014 23:15:00 -0500 From: Gregory Mirsky To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRAClhicAAMCf+IAADX0LAABVlhMAAARMXoA= Date: Sun, 23 Nov 2014 04:14:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B896402@eusaamb103.ericsson.se> References: <20141116220332392193.5ed69d25@sniff.de> <20141121002512713064.799b449a@sniff.de> 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.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyuXRPoO5M5sIQg6bnEhazr/xntpjdEW/x +c82Rgdmjym/N7J6LFnyk8mjdXU3SwBzFJdNSmpOZllqkb5dAlfG7XNFBSciK1Y/XcrWwLjb vYuRk0NCwETiw5QpjBC2mMSFe+vZuhi5OIQEjjBKTH3QAOUsZ5RYdbqZHaSKTcBI4sXGHjBb RMBb4srM+WA2s4CmRNOJz2C2sIC7xK7199kgajwkvr09ywxh+0mcfLKBFcRmEVCVuPPoCEsX IwcHr4CvROMDG4hdK5gkpm3uBOvlBIpv/7kU7DpGoOu+n1rDBLFLXOLWk/lMEFcLSCzZc54Z whaVePn4HyuErSQx5/U1Zoh6HYkFuz+xQdjaEssWvgaL8woISpyc+YRlAqPYLCRjZyFpmYWk ZRaSlgWMLKsYOUqLU8ty040MNzEC4+aYBJvjDsYFnywPMQpwMCrx8G7ozg8RYk0sK67MPcQo zcGiJM6rWT0vWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjCItA3fyKcM9nR4551X8zva31 OmXXyu1y2+ZNVUta9z5ETSxw5iOFaaafVSrZ5U9sDQrdIcq7qGTljztK0pXzDj7yvfDt4GGF zrX22vM298y74p79f0fwfZl8m5+znRW0/d4/ZLnm3frP9y7fXOeldrtyLCJjt4TH33b9NXP/ 9K1KNT2zHtpGKLEUZyQaajEXFScCADS1IhV8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BeZmeTdtLoN2HwM2bnqcMcyL6kM 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, 23 Nov 2014 04:30:16 -0000 Hi Nobo, Marc, Santosh, et. al, there're many ways to slice the bread. I agree with the proposed course of actions. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (no= bo) Sent: Saturday, November 22, 2014 5:16 PM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hello BFD WG, Marc and I had some conversation on the topic of S-BFD alert discriminator = document structure, and converged on a direction. - We think that it is useful to describe both the problems and the solution= for the S-BFD alert discrimintor in a single document. - We also think the S-BFD alert discriminator is more like an exception mec= hanism, thus the mechanism should remain outside of the S-BFD base document= . Therefore, our converged recommendation to the WG is to keep the extended u= se-cases and the alert discriminator mechanism in the draft-akiya-bfd-seaml= ess-alert-discrim. This also means that no further changes are needed in draft-ietf-bfd-seamle= ss-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forwar= d if authors feel that it is ready. We would appreciate it if folks can chime in and state whether or not this = is an acceptable way forward. Thanks! -Nobo & Marc =09 > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Friday, November 21, 2014 3:25 AM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: Seeking opinions on=20 > draft-akiya-bfd-seamless-alert-discrim >=20 > Hello Nobo, >=20 > (back from Hawaii or writing emails at the beach? ;-) >=20 >=20 > > Your view is then: > > > > Instead of: > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and=20 > > keep the alert discriminator mechanism in the=20 > > draft-akiya-bfd-seamless-alert-discrim. > > > > Do: > > > > (2) Keep the extended use-cases and alert discriminator mechanism in=20 > > the draft-akiya-bfd-seamless-alert-discrim. > > > > Or > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case=20 > > and move the alert discriminator mechanism to=20 > > draft-ietf-bfd-seamless- > base. >=20 > yes, exactly. >=20 >=20 > > Whether the S-BFD packets with alert discriminator are handled in HW=20 > > or SW is an implementation choice. Similar to how IP router alert=20 > > option & router alert label are handled, I do see handling of S-BFD=20 > > packets with alert discriminator in the SW to be a reasonable=20 > > approach, in which case the HW instruction for S-BFD packets with=20 > > alert discriminator is to punt to SW for processing. >=20 > > Personally, I tend to recommend that alert discriminators are=20 > > handled in the SW. Let's assume that you agree on this=20 > > (hypothetically). In that case, would you still recommend the alert=20 > > discriminator mechanism to be moved to the=20 > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draf= t-akiya-bfd-seamless-alert-discrim? >=20 >=20 > That's probably where our different views come from :-) I would aim to=20 > simplify the main idea of the draft so it _can_ easily be implemented=20 > even in hardware. >=20 > For the traceroute - my guess is TTL punts (if that mechanism to=20 > "deliver" is > used) happen in software as many mechanism use this "trick" but if a=20 > hardware can handle TTL punts, it can handle the diag code as well. I=20 > don't see the document needs to adjust for the traceroute case. >=20 > For a basic reflector task, having a zero discriminator as a default=20 > reflector discriminator would allow for very simple implementations=20 > (we discussed a while ago a fixed discriminator value for simple=20 > broadband modems, remember?). > For more complex equipment and scenarios, keeping it in hardware=20 > instead of a software punt would maintain the ability of S-BFD to go up v= ery quickly. >=20 >=20 > I tend to not see the zero discriminator as such a big exception,=20 > which may explain my idea to integrate it into the base document. And=20 > to keep it compatible to hardware implementations. > Assuming you want to add more "special effects" in the future I can=20 > see why you have an extra document. I would propose to keep the=20 > zero-reflector mentally aligned :-) with the base document and=20 > accordingly designed to allow implementations to cover the zero-reflector= together with "normal" > S-BFD > (read: may be in hardware). >=20 >=20 > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up=20 > > S-BFD packets with alert discriminator. >=20 > Good - makes life simpler :-) >=20 >=20 > Regards, Marc >=20 >=20 > On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > > Hi Marc, > > > > Thanks for providing your view. > > > > Please see in-line. > > > >> -----Original Message----- > >> From: Marc Binderberger [mailto:marc@sniff.de] > >> Sent: Monday, November 17, 2014 1:04 AM > >> To: Nobo Akiya (nobo) > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: Seeking opinions on > >> draft-akiya-bfd-seamless-alert-discrim > >> > >> Hello Nobo and BFD experts, > >> > >> giving this document a closer look for the first time (ahem ;-) I=20 > >> have a slightly different view. > >> > >> Having S-BFD use cases for the general S-BFD in an extra document=20 > >> does improve the overall discussion and documentation, simply=20 > >> because the base S-BFD is already complex enough, as are the use cases= . > >> > >> But for such a relatively small document splitting off the reason=20 > >> why the document exists is not improving the reading/understanding=20 > >> of this > draft. > >> Unless you decide to integrate the alert-discriminator document=20 > >> into the base document, then obviously you use the use-case document. > > > > Your view is then: > > > > Instead of: > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and=20 > > keep the alert discriminator mechanism in the=20 > > draft-akiya-bfd-seamless-alert-discrim. > > > > Do: > > > > (2) Keep the extended use-cases and alert discriminator mechanism in=20 > > the draft-akiya-bfd-seamless-alert-discrim. > > > > Or > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case=20 > > and move the alert discriminator mechanism to=20 > > draft-ietf-bfd-seamless- > base. > > > > My thought was that (1) makes sense, but your view that (1) makes=20 > > all the S-BFD documents set more complex to understand is a valid=20 > > concern (it's always good to get fresh eyes on documents!). > > > >> > >> > >> For the integration of the technical aspect into the base document,=20 > >> I think this is an idea worth to discuss. At the end what you need=20 > >> is to add the rule for the zero discriminator to the reflector=20 > >> behaviour; we managed this for standard BFD, we should be able to=20 > >> do this for the reflector BFD as well > >> :-) > > > > Whether the S-BFD packets with alert discriminator are handled in HW=20 > > or SW is an implementation choice. Similar to how IP router alert=20 > > option & router alert label are handled, I do see handling of S-BFD=20 > > packets with alert discriminator in the SW to be a reasonable=20 > > approach, in which case the HW instruction for S-BFD packets with=20 > > alert discriminator is to punt to SW for processing. > > > >> For the diagnostic codes I'm not sure; it will complicate hardware=20 > >> implementations (probably not a no-go problem though) and seems=20 > >> otherwise not add a real value IMHO. > > > > If one really wants to handle them in the HW, that's a possibility. > > Although as you stated, it does complicate HW implementations and=20 > > this is another reason for SW based implementations. > > > >> > >> So if there are already at this stage of S-BFD use case(s) for=20 > >> zero- discriminator to bring up (some) sessions then I would=20 > >> propose to consider the integration into the base document. This=20 > >> will also guarantee that the zero-discriminator handling is as fast=20 > >> as the "normal" reflection and is not on a slower exception path. > > > > Personally, I tend to recommend that alert discriminators are=20 > > handled in the SW. Let's assume that you agree on this=20 > > (hypothetically). In that case, would you still recommend the alert=20 > > discriminator mechanism to be moved to the=20 > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the draf= t-akiya-bfd-seamless-alert-discrim? > > > >> > >> > >> > >> I have a question: so far S-BFD packets would be received, not=20 > >> "picked out of the data stream". Receiving could be because the=20 > >> destination IP would match or would be 127/8, the TTL would be zero=20 > >> and so on. In the security section you say ... > >> > >> Conceptually the Alert Discriminator is similar to an IP Router Ale= rt > >> Option or an MPLS Router Alert Label. > >> > >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to=20 > >> the > >> reflector) with an alert-discriminator out of the data stream that=20 > >> otherwise would just pass this node? > >> I guess you don't want but I want to make sure I understand it correct= ly. > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up=20 > > S-BFD packets with alert discriminator. So the statement regarding=20 > > "Conceptually the Alert Discriminator is similar to an IP Router=20 > > Alert Option or an MPLS Router Alert Label" should be re-stated and cla= rified. > > > > Thanks! > > > > -Nobo > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > >>> [Speaking as an individual S-BFD contributor] > >>> > >>> Hi BFD WG, > >>> > >>> There were couple of questions I need your input on=20 > >>> draft-akiya-bfd-seamless-alert-discrim. > >>> > >>> > >>> (1) Should the "extended" S-BFD use cases move to=20 > >>> draft-ietf-bfd-seamless-use-case? > >>> > >>> My opinion is yes. Once the "extended" S-BFD use cases have been=20 > >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should=20 > >>> try to move draft-ietf-bfd-seamless-use-case forward. > >>> > >>> How does the WG feel about this? > >>> > >>> > >>> (2) Should the alert discriminator proposal move to=20 > >>> draft-ietf-bfd-seamless-base? > >>> > >>> My opinion is no . Instead we should position this as an optional=20 > >>> feature of S-BFD (hence separate document than the base),=20 > >>> especially considering we likely need to think through additional=20 > >>> security concerns > >> raised by this. > >>> > >>> A question was raised by Greg on how does a node find out if the=20 > >>> target supports the optional alert discriminator or not. We can=20 > >>> define a mandatory diagnostic value that must be implemented when=20 > >>> the alert discriminator is implemented. One can send an S-BFD=20 > >>> control packet with the alert discriminator with this diagnostic=20 > >>> value to check if the target supports the alert discriminator mechani= sm. > >>> > >>> How does the WG feel about this? > >>> > >>> > >>> Thanks! > >>> > >>> -Nobo > >>> > > From nobody Sat Nov 22 20:49:30 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 29A741A1AA3 for ; Sat, 22 Nov 2014 20:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvZjz64kSn_m for ; Sat, 22 Nov 2014 20:49:23 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E851A1AA0 for ; Sat, 22 Nov 2014 20:49:22 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-d7-54710b9b6341 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9A.FC.25146.C9B01745; Sat, 22 Nov 2014 23:18:04 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Sat, 22 Nov 2014 23:49:11 -0500 From: Gregory Mirsky To: Santosh P K , "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: AQHPu0hUJnl0CAJJIkO/ChgaGBADZJvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAQGNgIAFsnwAgAU+f4CALo2OAIABnSkAgAJ5AoCAAAqGgP//yhDA Date: Sun, 23 Nov 2014 04:49:11 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B896423@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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.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.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonRHcOd2GIwfbpqhb7D75ltZjdEW/x +c82Rotrd7cyW8x+/IPN4srcRjYHNo/WZ3tZPab83sjq0XLkLavHkiU/mTyuN11l97jcu5U1 gC2KyyYlNSezLLVI3y6BK+PHhB2MBQvPMFbc+DORpYFx7SzGLkZODgkBE4nTsw6xQdhiEhfu rQeyuTiEBI4wSqyYuIgZwlnOKPFk4URWkCo2ASOJFxt72EESIgJ/GSUWP/rCDJIQFrCUaH/W ADZKRMBKYsuL+WwQRdMYJaZvngtWxCKgKjF7+0uwSbwCvhIfrsxnh1ixiUPi2purYEdxCkRI /H54jh3EZgQ66vupNUwgNrOAuMStJ/OZII4VkFiy5zwzhC0q8fLxP1YIW0lizutrzBD1ehI3 pk5hg7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREY Z8ck2Bx3MC74ZHmIUYCDUYmHd0N3fogQa2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhj3tfZ0ejOuqvE6GK04cV7z6X7W76ZMPgZT9F7V6v04eeif7EnHjzYH o1/EWa3uFrRoWnu8Zt9n3VvMv3SfXnedc1ft3L35ys51J2I/Gz+oSa3+MUn/fxezrerH43JL l3Py9uSY7Trnxvcy7+DN94JJ21r3bYz/obVO9xar4LtDn/yytnJnKz5XYinOSDTUYi4qTgQA u161XZQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/M1MHvCHg29EHpyvd1vVXmnFAgNs 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, 23 Nov 2014 04:49:28 -0000 Hi Santosh, et. al, I'm adding more in-line to the level of making the discussion untraceable. = Look for GIM>> tags. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Santosh P K Sent: Saturday, November 22, 2014 6:35 PM To: Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.or= g; Mingui Zhang Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hello Nobo, Thanks for your reply. Please see inline. =09 > > 1.=A0=A0=A0=A0=A0=A0 Active tail. > > As discussed earlier, is this required in base draft? I spoke=20 > > to all implementers =A0and no one has active tail implemented yet. To=20 > > push it for RFC we need implementation so can we go ahead and move=20 > > it to appendix or may be new document? > > > > WH> I would propose we do the active tail in appendix or a separate=20 > > WH> draft >=20 > [NOBO] Wim, can you clarify which you mean? >=20 > A) You propose reliable head notification to be moved. > B) You propose semi-reliable and reliable head notifications to be moved. > C) You propose unreliable, semi-reliable and reliable head=20 > notifications to be moved. >=20 > You can find the description of each notifications in page 4 of=20 > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. >=20 > My preference will be (A). >=20 Moving reliable head notification to appendix or new document you mean :) ?= =20 GIM>> My preference - C into the separate draft. And all related updates of= state machine and new variables - go with it. > > > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > > It makes more sense to have a separate draft for this. Please=20 > > let me know if that is ok? If it benefits to have it in base draft=20 > > itself then we can have more sections for demux and port number to=20 > > be > used. > > > > WH> it should be in the draft I believe >=20 > [NOBO] So ... >=20 > Option 1 is to describe the demux codepoint & procedures in the bfd-=20 > multipoint document. > Option 2 is to describe the demux codepoint & procedures in separate=20 > data plane document(s). >=20 > It sounds like Santosh is preferring Option 2 while Wim is preferring opt= ion 1. >=20 > Perhaps there's an Option 3. >=20 > The bfd-multipoint document to describe one or two basic data plane=20 > demux codepoint & procedures cleanly in a separate section (ex: IP and MP= LS). > Other data planes documents (ex: TRILL) can update the demux section=20 > of the bfd-multipoint document. Just thinking out loud ... >=20 Currently in document it tries to explain how to demux for IP only in secti= on 4.8. We can add more text for clarity.=20 I am ok with option 1 where all procedure dumped in single document but I a= m worried that in future some other data plane wants a new way of demultipl= exing then we may need to change the base document again?=20 GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS ACH, = would have to write documents of their own. > > > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > > Echo mode does not fit in P2MP BFD. We can say it is not support= ed. > > Does anyone see use of echo BFD in P2MP BFD? > > > > WH> I don't see a use case for this so far >=20 > [NOBO] Agree, I see no value in the multipoint document considering=20 > the echo inside the scope. Thanks. GIM>> Agree, no echo mode. > > > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > > Draft suggest not to use POLL sequence and suggests to increase=20 > > multiplier first and then interval. If we have hardware=20 > > implementation and don't want to check complete packet every time=20 > > received then change in packet may be indicated with POLL bit set.=20 > > Since this is one to many mapping we can't have a complete POLL=20 > > sequence and hence we need to suppress FINAL. Should we be going=20 > > with POLL and suppress FINAL by setting desired RX interval set to=20 > > 0? Please suggest any better idea. >=20 > [NOBO] If we keep the semi-reliable head notification, then I would=20 > have expected P/F (from head to tails) to just work? With semi-reliable head notification you want to have complete POLL sequenc= e for interval negotiation? One to many mapping will have issues with comp= lete POLL sequence. Can you elaborate how this will help?=20 > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > > Draft suggests that head direct tails to send down=20 > > notification. How will head direct tail about failure notification=20 > > to be sent or not? Is this driven by configuration? At least the=A0=20 > > section > > 4.4.1 says so. It could also be communicated to > > received out of band? > > > > This should be out of scope of this document as we can't=20 > > direct tails with in BFD packet. Any comments? >=20 > [NOBO] This is something which can be configured, thus out of scope=20 > [for now] should be fine. One reason that I have been pushing to keep=20 > semi- reliable head notification is that it can catch instances of odd=20 > cases like tails not having consistent configurations ... i.e, only=20 > some tails notify and some don't. Head doing the in-band polling can=20 > discover the available tails, becomes more of a fail-safe mechanism. Agreed. It makes sense to have semi-reliable here.=20 GIM>> I think that I disagree on this. Configuration can be verified by oth= er means. I consider the base of multi-point BFD as mechanism suitable for = 1+1 protection switchover. Any type of tail monitoring, IMO, is optional an= d can be document of its own. >=20 > > > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > > Few implementers use UDP port number to absorb BFD packet on tails.=20 > > It would be good to clarify about this in draft. Do we see any other=20 > > way of absorbing packet on tail? >=20 > [NOBO] >=20 > For IP: > - UDP port. >=20 > For MPLS: > - 127/8 and UDP port. > - UHP does not require bootstrapping but PHP will require bootstrapping. GIM>> Why would bootstrapping be required for multi-point BFD session in MP= LS data plane with PHP if tail monitoring is not required?=20 =20 For TILLS: A new data channel.=20 Thanks Santosh P K=20 > > > > > -----Original Message----- > > > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > > > Sent: Wednesday, October 22, 2014 3:09 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 > > > > > > [With Chair Hat On] > > > > > > WG, > > > > > > I'd imagine many are busy ... being the last week before the=20 > > > cut-off and > > all ... > > > > > > But it'll be very helpful if you can chime in to help Santosh to=20 > > > take BFD multipoint 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 > > > > > > > > Hello Nobo, > > > >=A0=A0=A0 Thanks again for your comments on this. Please see my comm= ents. > > > > > > > > > (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=20 > > > > > out-of-band > > > > mechanism, then preserve (a) and (b) but remove (c). And that=20 > > > > would be my preference. > > > > > Mingui, for your "TRILL Resilient Distribution Trees", do you=20 > > > > > see the need > > > > for all [a-c] or just subsets? > > > > > > > > Does (a) alone not enough? > > > > > > Personally I think there's a value in leaving the option for the=20 > > > head to do > > in- > > > band polling of leaves. In other words, if down notification from=20 > > > a leaf to > > the > > > head, then there is no way for the head to find out that leaf is=20 > > > no longer receiving. > > > > > > > Want to know if there are any application which wants to track=20 > > > > 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. > > > > > > > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is=20 > > > > > not specified > > > > in this document). > > > > > > > > Yes, UDP port is not specified in the document. We can add this=20 > > > > info in base document itself? Every on ok with this? Any suggestion= s? > > > > > > 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=20 > > > data > > plane. > > > > > > Thanks! > > > > > > -Nobo > > > > > > > > > > > > > > > Thanks > > > > Santosh P K > > > > > > > > > > > > -----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 > > > > > > > > [With Chair Hat Off] > > > > > > > > Hi Santosh, > > > > > > > > Thank you for leading this effort! > > > > > > > > Hopefully others can provide their comments to help close of=20 > > > > 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;=20 > > > > > rtg- bfd@ietf.org > > > > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > > > > > Hello All, > > > > >=A0=A0=A0 Sorry for delay. I am trying to elaborate what I meant b= y "active tail". > > > > > Please also comment on other two items that I have listed=20 > > > > >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=20 > > > > > any use case scenario for head tracking tail. Currently there=20 > > > > > are multiple options given in draft for head to track tail. > > > > > =A0=A0=A0=A0 1.=A0 Unreliable Head Notification as per section 6.= 2 > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When= tail detect timer expires it sends=20 > > > > > DOWN BFD packet to > > > > head on > > > > > reverse unicast path. > > > > > =A0=A0=A0=A0 2. Semi-reliable Head Notification and Tail Solicita= tion=20 > > > > > as per section > > > > > 6.3 > > > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A mu= ltipoint POLL with a combination of=20 > > > > > reverse unicast > > > > path FINAL > > > > > will help head to know if tail has lost communication with head. > > > > > =A0=A0=A0=A0 3. Reliable Head Notification as per section 6.4 > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A comb= ination of multipoint POLL and=20 > > > > > 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. > > > > > > > > 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=20 > > > > > by other > > > > means. > > > > > Example is Multicast VPN using MP-BGP. > > > > [snip] > > > > > > > > True, in the scenario described, (3) adds very minimal value=20 > > > > beyond running multi-hop BFD session between BGP peers. > > > > > > > > On the other hand (1) and (2) are in-band, and can detect=20 > > > > failures that other sessions like multi-hop BFD sessions cannot.=20 > > > > It does look useful with technologies such as P2MP-TE where: > > > > > > > > - leaves are constant > > > > - has path-protection mechanism > > > > > > > > > > > > > > We have below options: > > > > > =A0=A0=A0=A0 1. Go with simple "No Head Notification" as per sect= ion=20 > > > > > 6.1 in base draft and move rest of the sections to Appendix or=20 > > > > > move to separate > > > > draft? > > > > > In this case On MultipointHead bfd.ReportTailDown > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0will be set to 0 and we might not eve= n need=20 > > > > > MultipointClient as we are not going to receive any packets=20 > > > > > from tail. bfd.SilentTail will be set to 1 on MultipointTail > > > > > =A0=A0=A0=A0 2. Another option is to just keep "Unreliable Head=20 > > > > > Notification" as per section 6.2 and move/remove rest of=20 > > > > > mechanism through which Multipoint head can detect tail going > down. > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0=A0Meaning we need to move/remove Multic= ast POLL and=20 > > > > > 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=20 > > > > mechanism, then preserve (a) and (b) but remove (c). And that=20 > > > > would be my preference. > > > > > > > > Mingui, for your "TRILL Resilient Distribution Trees", do you=20 > > > > see the need for all [a-c] or just subsets? > > > > > > > > > =A0=A0=A0=A0 3. Jeff suggested that we move these sections to new= =20 > > > > > draft with experimental status. > > > > > =A0=A0=A0=A0 4.=A0 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=20 > > > > > that as per section 4.7 of this draft say > > > > > > > > > > =A0=A0=A0=A0 " The minimum amount of a priori information require= d=20 > > > > > both on the head > > > > > =A0=A0=A0=A0 =A0=A0=A0=A0and tails is the binding to the multipoi= nt path over=20 > > > > > which BFD is running." > > > > > > > > > > Above text is brief and draft is AF agnostic. Do we need to=20 > > > > > make text of Sec > > > > > 4.7 and related sections more explicit? For example in case of=20 > > > > > 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=20 > > > > > outside the scope of this document? > > > > > > > > Demux procedures is one, UDP port is the other one (i.e. it is=20 > > > > not specified in this document). > > > > > > > > We need to either: > > > > - Add details in this document, or > > > > - Consider this document as multipoint base document, and roll=20 > > > > out > > > > micro- documents describing demux/UDP-port details for various=20 > > > > data > > > planes. > > > > > > > > Either will work, but the details are required somewhere to > interoperate. > > > > > > > > > > > > > > Security consideration: > > > > > ---------------------------- > > > > > As per Nobo's comment on this draft long back.=A0 We need to add= =20 > > > > > some suggestion in security consideration. Mainly because=20 > > > > > MultipointTail session can be created dynamically. > > > > > > > > > > Snippet from Nobo's mail. > > > > > > > > > > "MultipointTail sessions are dynamically created. If I had a=20 > > > > > way of getting around GTSM & Authentication (or lack of) and=20 > > > > > was aware of a source address that will pass the "check", then=20 > > > > > I could DoS this system with range of My Discriminator values=20 > > > > > to leaves, which will cause many instances of MultipointTail=20 > > > > > sessions to > get created. > > > > > Draft does say [create or discard] choice is outside the scope=20 > > > > > (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=20 > > > > > the "Security > > > > Consideration"." > > > > > > > > > > Any suggestion on this? > > > > > > > > > > Jeff and Nobo have already raised some concerns here. We might=20 > > > > > have to see how PIM is doing it today. > > > > > > > > Right it would be a good idea how other multipoint/multicast=20 > > > > protocols have addressed this. > > > > > > > > Thanks! > > > > > > > > -Nobo > > > > > > > > > > > > > > > > > > > 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 = removal? > > > > > > > > > > Knowing exactly what aspect is being questioned for removal=20 > > > > > 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-=20 > > > > > > lucent.com] > > > > > > Sent: Friday, October 10, 2014 12:29 AM > > > > > > To: Nobo Akiya (nobo); Santosh P K; Jeffrey Haas;=20 > > > > > > rtg-bfd@ietf.org > > > > > > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > > > > > > > > > In certain environment the tracking of the tails is=20 > > > > > > 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=20 > > > > > > >draft-ietf-bfd-multipoint is one of the last couple of=20 > > > > > > >topics that we, as a WG, need to resolve for this document. > > > > > > > > > > > > > >Whether or not we keep or remove the active tail, leaves=20 > > > > > > >will be able to detect the failure of the multicast tree,=20 > > > > > > >which allows protections such as live-live. > > > > > > > > > > > > > >What is essentially different: > > > > > > > > > > > > > >Keeping the active tail - Allows ingress/root to keep track=20 > > > > > > >of > leaves. > > > > > > > > > > > > > >Removing the active tail - Ingress/root will not be able to=20 > > > > > > >keep track of leaves. > > > > > > > > > > > > > >If there's any requirements for the ingress/root to trigger=20 > > > > > > >some protections, then active tail becomes a requirement.=20 > > > > > > >If there is no such requirements, then the active tail is=20 > > > > > > >an unnecessary portion of this document. > > > > > > > > > > > > > >It'll be beneficial to hear your thoughts/comments to help=20 > > > > > > >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=20 > > > > > > >> 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=A0 "active tale" it is "a= ctive tail". > > > > > > >> > > > > > > >> Thanks > > > > > > >> Santosh P K > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf=20 > > > > > > >> 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, > > > > > > >>=A0=A0=A0 I am seeking comments on active tale section of thi= s document. > > > > > > >>I spoke to=A0 few implementers and found that no one really=20 > > > > > > >>finds use case for active tale. > > > > > > >> Does anyone on this forum feel that we might need active tal= e? > > > > > > >>If there are=A0 no uses cases then we can move active tale=20 > > > > > > >>section to appendix? We would=A0 like to make all the=20 > > > > > > >>changes before IETF > > > > > > >>91 and push this for RFC. Any=A0 suggestions? > > > > > > >> > > > > > > >> Thanks > > > > > > >> Santosh P K > > > > > > >> > > > > > > >> -----Original Message----- > > > > > > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf=20 > > > > > > >>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=20 > > > > > > >>Santosh as the new editor. > > > > > > >> (And moving from .nroff to .xml.) > > > > > > >> > > > > > > >> In the next few weeks, Santosh will be working with known=20 > > > > > > >>implementors to=A0 edit the document to match implementation. > > > > > > >>Ideally these edits will be=A0 complete prior to the next=20 > > > > > > >>IETF session in Honolulu.=A0 This will put us a bit=A0 past=20 > > > > > > >>our original milestone for publication, but still much=20 > > > > > > >>better on track=A0 than 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. > > > > > > >> >=A0 This draft is a work item of the Bidirectional=20 > > > > > > >> >Forwarding Detection > > > > > > >> Working Group of the IETF. > > > > > > >> > > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 : BFD for Multipoint Networks > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : = Dave Katz > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Dave Ward > > > > > > >> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Santosh Pallagatti > > > > > > >> > =A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 :=20 > > > > > > >> >draft-ietf-bfd-multipoint-04.txt > > > > > > >> > =A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2= 7 > > > > > > >> > =A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 := 2014-08-12 > > > > > > >> > > > > > > > >> > Abstract: > > > > > > >> >=A0=A0=A0 This document describes extensions to the=20 > > > > > > >> >Bidirectional > > > > Forwarding > > > > > > >> >=A0=A0=A0 Detection (BFD) protocol for its use in multipoin= t=20 > > > > > > >> >and multicast > > > > > > >> >=A0=A0=A0 networks.=A0 Comments on this draft should be dir= ected=20 > > > > > > >> >to rtg- > > > > > > >> >=A0=A0=A0 bfd@ietf.org. > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > The IETF datatracker status page for this draft is: > > > > > > >> > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipo > > > > > > >> > in > > > > > > >> > t/ > > > > > > >> > > > > > > > >> > 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-multipo > > > > > > >> > in > > > > > > >> > t-04 > > > > > > >> > > > > > > > >> > > > > > > > >> > Please note that it may take a couple of minutes from=20 > > > > > > >> > the time of submission until the htmlized version and=20 > > > > > > >> > diff are available at > > > > > > >> tools.ietf.org. > > > > > > >> > > > > > > > >> > Internet-Drafts are also available by anonymous FTP at: > > > > > > >> > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > From nobody Sat Nov 22 21:29:40 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 D68BF1A1ABC for ; Sat, 22 Nov 2014 21:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bXZGs5f9Xnu for ; Sat, 22 Nov 2014 21:29:34 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C32E1A1ABB for ; Sat, 22 Nov 2014 21:29:34 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 23 Nov 2014 05:29:31 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sun, 23 Nov 2014 05:29:31 +0000 From: Santosh P K To: Gregory Mirsky , "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/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbA= Date: Sun, 23 Nov 2014 05:29:30 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 04041A2886 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(35774003)(51444003)(50986999)(107046002)(106116001)(230783001)(62966003)(77156002)(120916001)(95666004)(105586002)(107886001)(93886004)(101416001)(99286002)(122556002)(108616004)(74316001)(64706001)(20776003)(92566001)(76576001)(66066001)(21056001)(86362001)(54356999)(106356001)(15975445006)(40100003)(4396001)(33646002)(46102003)(31966008)(19580395003)(76176999)(15202345003)(87936001)(97736003)(2656002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/g_-YvoDxbYx344ENA6BkLWbIofI 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, 23 Nov 2014 05:29:38 -0000 Hello Greg, Thanks a lot of your comments. Please see inline.=20 > > > 1.=A0=A0=A0=A0=A0=A0 Active tail. > > > As discussed earlier, is this required in base draft? I spoke > > > to all implementers =A0and no one has active tail implemented yet. To > > > push it for RFC we need implementation so can we go ahead and move > > > it to appendix or may be new document? > > > > > > WH> I would propose we do the active tail in appendix or a separate > > > WH> draft > > > > [NOBO] Wim, can you clarify which you mean? > > > > A) You propose reliable head notification to be moved. > > B) You propose semi-reliable and reliable head notifications to be move= d. > > C) You propose unreliable, semi-reliable and reliable head > > notifications to be moved. > > > > You can find the description of each notifications in page 4 of > > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > > > > My preference will be (A). > > > Moving reliable head notification to appendix or new document you mean :) > ? > GIM>> My preference - C into the separate draft. And all related updates = of > state machine and new variables - go with it. Ok so we have 1. Moving reliable notification option (A) moving to separate document/appe= ndix. (Nobo's preference) 2. Moving unreliable, semi-reliable and reliable (C) to separate document/a= ppendix. (Greg's preference)=20 Wim you have any preference on this?=20 >=20 > > > > > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > > > It makes more sense to have a separate draft for this. Please > > > let me know if that is ok? If it benefits to have it in base draft > > > itself then we can have more sections for demux and port number to > > > be > > used. > > > > > > WH> it should be in the draft I believe > > > > [NOBO] So ... > > > > Option 1 is to describe the demux codepoint & procedures in the bfd- > > multipoint document. > > Option 2 is to describe the demux codepoint & procedures in separate > > data plane document(s). > > > > It sounds like Santosh is preferring Option 2 while Wim is preferring o= ption > 1. > > > > Perhaps there's an Option 3. > > > > The bfd-multipoint document to describe one or two basic data plane > > demux codepoint & procedures cleanly in a separate section (ex: IP and > MPLS). > > Other data planes documents (ex: TRILL) can update the demux section > > of the bfd-multipoint document. Just thinking out loud ... > > >=20 > Currently in document it tries to explain how to demux for IP only in sec= tion > 4.8. We can add more text for clarity. > I am ok with option 1 where all procedure dumped in single document but I > am worried that in future some other data plane wants a new way of > demultiplexing then we may need to change the base document again? > GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS > ACH, would have to write documents of their own. Ok so I think we are making progress on this. I understand that we need to = do below.=20 Keep base document with IP demux and MPLS demux. For any other (TRILLS, MPL= S ACH) demux required come up with a new draft.=20 > > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > > > Echo mode does not fit in P2MP BFD. We can say it is not suppo= rted. > > > Does anyone see use of echo BFD in P2MP BFD? > > > > > > WH> I don't see a use case for this so far > > > > [NOBO] Agree, I see no value in the multipoint document considering > > the echo inside the scope. >=20 > Thanks. > GIM>> Agree, no echo mode. Thanks. We are converging on this point.=20 >=20 > > > > > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > > > Draft suggest not to use POLL sequence and suggests to increase > > > multiplier first and then interval. If we have hardware > > > implementation and don't want to check complete packet every time > > > received then change in packet may be indicated with POLL bit set. > > > Since this is one to many mapping we can't have a complete POLL > > > sequence and hence we need to suppress FINAL. Should we be going > > > with POLL and suppress FINAL by setting desired RX interval set to > > > 0? Please suggest any better idea. > > > > [NOBO] If we keep the semi-reliable head notification, then I would > > have expected P/F (from head to tails) to just work? >=20 > With semi-reliable head notification you want to have complete POLL > sequence for interval negotiation? One to many mapping will have issues > with complete POLL sequence. Can you elaborate how this will help? >=20 >=20 > > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > > > Draft suggests that head direct tails to send down > > > notification. How will head direct tail about failure notification > > > to be sent or not? Is this driven by configuration? At least the > > > section > > > 4.4.1 says so. It could also be communicated to > > > received out of band? > > > > > > This should be out of scope of this document as we can't > > > direct tails with in BFD packet. Any comments? > > > > [NOBO] This is something which can be configured, thus out of scope > > [for now] should be fine. One reason that I have been pushing to keep > > semi- reliable head notification is that it can catch instances of odd > > cases like tails not having consistent configurations ... i.e, only > > some tails notify and some don't. Head doing the in-band polling can > > discover the available tails, becomes more of a fail-safe mechanism. >=20 > Agreed. It makes sense to have semi-reliable here. >=20 > GIM>> I think that I disagree on this. Configuration can be verified by o= ther > means. I consider the base of multi-point BFD as mechanism suitable for 1= +1 > protection switchover. Any type of tail monitoring, IMO, is optional and = can > be document of its own. Hmmm so this means we need converge on below options for tail monitoring. 1. Moving reliable notification option (A) moving to separate document/appe= ndix. (Nobo's preference) 2. Moving unreliable, semi-reliable and reliable (C) to separate document/a= ppendix. (Greg's preference) > > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > > > Few implementers use UDP port number to absorb BFD packet on tails. > > > It would be good to clarify about this in draft. Do we see any other > > > way of absorbing packet on tail? > > > > [NOBO] > > > > For IP: > > - UDP port. > > > > For MPLS: > > - 127/8 and UDP port. > > - UHP does not require bootstrapping but PHP will require bootstrapping= . >=20 > GIM>> Why would bootstrapping be required for multi-point BFD session in > MPLS data plane with PHP if tail monitoring is not required? In case of PHP tail will not know which how to associate BFD received packe= t to an LSP as all BFD packets will come with 127/8 address. This is why we= need boot strapping with MPLS LSP ping. There was a draft for the same lon= g time ago. http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 Thanks Santosh P K=20 From nobody Sun Nov 23 02:15: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 575A81A1B26 for ; Sun, 23 Nov 2014 02:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.494 X-Spam-Level: X-Spam-Status: No, score=-7.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] 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 GL25w-oFxqiG for ; Sun, 23 Nov 2014 02:15:32 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3B7FE1A0151 for ; Sun, 23 Nov 2014 02:15:31 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id F34C4E6BA96CE; Sun, 23 Nov 2014 10:15:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sANAFS2g030057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Nov 2014 11:15:28 +0100 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; Sun, 23 Nov 2014 11:15:28 +0100 From: "Henderickx, Wim (Wim)" To: Santosh P K , Gregory Mirsky , "Nobo Akiya (nobo)" , "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+keyL4hHqvmqqpvX94gAgEtaThCAAAlCsIAE3GeAgAA3/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABGZGAgAL/eoCAAAqGgIAAJWCAgAALQwCAAGCBAA== Date: Sun, 23 Nov 2014 10:15:26 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> 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.6.141106 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <061FBDB7A484B749A403E534E16826FF@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KJ9JBv1Ds2NLA2kWEAcmJheTees 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, 23 Nov 2014 10:15:35 -0000 In-line with WH> On 23/11/14 06:29, "Santosh P K" wrote: >Hello Greg, > Thanks a lot of your comments. Please see inline. > >> > > 1. Active tail. >> > > As discussed earlier, is this required in base draft? I spoke >> > > to all implementers and no one has active tail implemented yet. To >> > > push it for RFC we need implementation so can we go ahead and move >> > > it to appendix or may be new document? >> > > >> > > WH> I would propose we do the active tail in appendix or a separate >> > > WH> draft >> > >> > [NOBO] Wim, can you clarify which you mean? >> > >> > A) You propose reliable head notification to be moved. >> > B) You propose semi-reliable and reliable head notifications to be >>moved. >> > C) You propose unreliable, semi-reliable and reliable head >> > notifications to be moved. >> > >> > You can find the description of each notifications in page 4 of >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. >> > >> > My preference will be (A). >> > >> Moving reliable head notification to appendix or new document you mean >>:) >> ? >> GIM>> My preference - C into the separate draft. And all related >>updates of >> state machine and new variables - go with it. > >Ok so we have > >1. Moving reliable notification option (A) moving to separate >document/appendix. (Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate >document/appendix. (Greg's preference) > >Wim you have any preference on this? WH> I would prefer C a per Greg=B9s suggestion >=20 > > > >>=20 >> > > >> > > 2. Demultiplexing and UDP port number. >> > > It makes more sense to have a separate draft for this. Please >> > > let me know if that is ok? If it benefits to have it in base draft >> > > itself then we can have more sections for demux and port number to >> > > be >> > used. >> > > >> > > WH> it should be in the draft I believe >> > >> > [NOBO] So ... >> > >> > Option 1 is to describe the demux codepoint & procedures in the bfd- >> > multipoint document. >> > Option 2 is to describe the demux codepoint & procedures in separate >> > data plane document(s). >> > >> > It sounds like Santosh is preferring Option 2 while Wim is preferring >>option >> 1. >> > >> > Perhaps there's an Option 3. >> > >> > The bfd-multipoint document to describe one or two basic data plane >> > demux codepoint & procedures cleanly in a separate section (ex: IP and >> MPLS). >> > Other data planes documents (ex: TRILL) can update the demux section >> > of the bfd-multipoint document. Just thinking out loud ... >> > >>=20 >> Currently in document it tries to explain how to demux for IP only in >>section >> 4.8. We can add more text for clarity. >> I am ok with option 1 where all procedure dumped in single document but >>I >> am worried that in future some other data plane wants a new way of >> demultiplexing then we may need to change the base document again? >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS >> ACH, would have to write documents of their own. > >Ok so I think we are making progress on this. I understand that we need >to do below.=20 > >Keep base document with IP demux and MPLS demux. For any other (TRILLS, >MPLS ACH) demux required come up with a new draft. WH> I agree to make a separate doc on other demux schemes other than IP and MPLS >=20 > > >> > > 3. Echo mode supported? >> > > Echo mode does not fit in P2MP BFD. We can say it is not >>supported. >> > > Does anyone see use of echo BFD in P2MP BFD? >> > > >> > > WH> I don't see a use case for this so far >> > >> > [NOBO] Agree, I see no value in the multipoint document considering >> > the echo inside the scope. >>=20 >> Thanks. >> GIM>> Agree, no echo mode. > >Thanks. We are converging on this point. > >>=20 >> > > >> > > 4. Increase interval? >> > > Draft suggest not to use POLL sequence and suggests to increase >> > > multiplier first and then interval. If we have hardware >> > > implementation and don't want to check complete packet every time >> > > received then change in packet may be indicated with POLL bit set. >> > > Since this is one to many mapping we can't have a complete POLL >> > > sequence and hence we need to suppress FINAL. Should we be going >> > > with POLL and suppress FINAL by setting desired RX interval set to >> > > 0? Please suggest any better idea. >> > >> > [NOBO] If we keep the semi-reliable head notification, then I would >> > have expected P/F (from head to tails) to just work? >>=20 >> With semi-reliable head notification you want to have complete POLL >> sequence for interval negotiation? One to many mapping will have issues >> with complete POLL sequence. Can you elaborate how this will help? >>=20 >>=20 >> > > 5. bfd.ReportTailDown >> > > Draft suggests that head direct tails to send down >> > > notification. How will head direct tail about failure notification >> > > to be sent or not? Is this driven by configuration? At least the >> > > section >> > > 4.4.1 says so. It could also be communicated to >> > > received out of band? >> > > >> > > This should be out of scope of this document as we can't >> > > direct tails with in BFD packet. Any comments? >> > >> > [NOBO] This is something which can be configured, thus out of scope >> > [for now] should be fine. One reason that I have been pushing to keep >> > semi- reliable head notification is that it can catch instances of odd >> > cases like tails not having consistent configurations ... i.e, only >> > some tails notify and some don't. Head doing the in-band polling can >> > discover the available tails, becomes more of a fail-safe mechanism. >>=20 >> Agreed. It makes sense to have semi-reliable here. >>=20 >> GIM>> I think that I disagree on this. Configuration can be verified by >>other >> means. I consider the base of multi-point BFD as mechanism suitable for >>1+1 >> protection switchover. Any type of tail monitoring, IMO, is optional >>and can >> be document of its own. > >Hmmm so this means we need converge on below options for tail monitoring. > >1. Moving reliable notification option (A) moving to separate >document/appendix. (Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate >document/appendix. (Greg's preference) > > >> > > 6. How packets get absorbed on tails? >> > > Few implementers use UDP port number to absorb BFD packet on tails. >> > > It would be good to clarify about this in draft. Do we see any other >> > > way of absorbing packet on tail? >> > >> > [NOBO] >> > >> > For IP: >> > - UDP port. >> > >> > For MPLS: >> > - 127/8 and UDP port. >> > - UHP does not require bootstrapping but PHP will require >>bootstrapping. >>=20 >> GIM>> Why would bootstrapping be required for multi-point BFD session in >> MPLS data plane with PHP if tail monitoring is not required? > >In case of PHP tail will not know which how to associate BFD received >packet to an LSP as all BFD packets will come with 127/8 address. This is >why we need boot strapping with MPLS LSP ping. There was a draft for the >same long time ago. > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > >Thanks >Santosh P K=20 From nobody Sun Nov 23 17:31:08 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 09B0E1A1B76 for ; Sun, 23 Nov 2014 17:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2WZHIUpnV7q for ; Sun, 23 Nov 2014 17:30:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012A41A1B78 for ; Sun, 23 Nov 2014 17:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1799; q=dns/txt; s=iport; t=1416792659; x=1418002259; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ACs65DxIdpjyK6SOwm5IOAsAKz0SxuTMvBb5E166CoQ=; b=U9kujbM3xcmw4A1FA3uC/6gt//j1cZ9SWa7U6gvwBsurxWFX+A4NO1Wu emWek0fXSCZxWuAQnUhgikJK3A3I/OVYamQEE0t7ZgwTcLEWrqGrAOqLX w5bpqyIxVtmNBhLjlgsON0+n25Bxpk6xv3to9xyO6sTa30vmUnDeNz7Ml 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAPqIclStJV2T/2dsb2JhbABbgmsjVVkEy3eGagKBDxYBAQEBAX2EAwEBBIEJAgEIIiQyJQIEARoBiDgBDM0wAQEBAQEBAQMBAQEBAQEckFo4gy+BHwWLaYRRgi6jM4N9eAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,445,1413244800"; d="scan'208";a="99420974" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 24 Nov 2014 01:30:58 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id sAO1UvAW013516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 01:30:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Sun, 23 Nov 2014 19:30:57 -0600 From: "Nobo Akiya (nobo)" To: "Henderickx, Wim (Wim)" , Santosh P K , Gregory Mirsky , 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+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmCALuR+AIABnSoAgAINGWCAAHZvgIAAJV+AgAALRACAAE/kAIAAkabw Date: Mon, 24 Nov 2014 01:30:56 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@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.21.79.78] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/gans7_lPxzAspU99l-cg_FBejFk 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, 24 Nov 2014 01:31:05 -0000 Hi Santosh, > >> > > 1. Active tail. > >> > > As discussed earlier, is this required in base draft? I > >> > > spoke to all implementers and no one has active tail implemented > >> > > yet. To push it for RFC we need implementation so can we go ahead > >> > > and move it to appendix or may be new document? > >> > > > >> > > WH> I would propose we do the active tail in appendix or a > >> > > WH> separate draft > >> > > >> > [NOBO] Wim, can you clarify which you mean? > >> > > >> > A) You propose reliable head notification to be moved. > >> > B) You propose semi-reliable and reliable head notifications to be > >>moved. > >> > C) You propose unreliable, semi-reliable and reliable head > >> > notifications to be moved. > >> > > >> > You can find the description of each notifications in page 4 of > >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > >> > > >> > My preference will be (A). > >> > > >> Moving reliable head notification to appendix or new document you > >>mean > >>:) > >> ? > >> GIM>> My preference - C into the separate draft. And all related > >>updates of > >> state machine and new variables - go with it. > > > >Ok so we have > > > >1. Moving reliable notification option (A) moving to separate > >document/appendix. (Nobo's preference) 2. Moving unreliable, > >semi-reliable and reliable (C) to separate document/appendix. (Greg's > >preference) > > > >Wim you have any preference on this? > WH> I would prefer C a per Greg=B9s suggestion If the majority of the WG thinks we should go with (C), then I wouldn't opp= ose. There is a benefit in progressing the portion that we all agree on, and rev= isit those questionable parts when there are stronger requirements. Thanks! -Nobo From nobody Sun Nov 23 18:54: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 17F251A1B3C for ; Sun, 23 Nov 2014 18:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 GicooZvRtBP9 for ; Sun, 23 Nov 2014 18:54:21 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301471A1A43 for ; Sun, 23 Nov 2014 18:54:21 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id m8so6491975obr.13 for ; Sun, 23 Nov 2014 18:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JPaeyWKp3LiZM90nFUrD+4T7fHtG9tCKBv/PA6Zx280=; b=ZWeIzpLKxN6Scag/ACDqIuQy9GP/7tJLRfF/6eYE8YdVIoRRk1UX/gVEGnmpqTdAGU 2i6Gwk9N5899BeXCLrWWk9TQ5wow06ZNKAuzTd29ZCuJPlTP1mjXVeb7JrRAnQV0JJdb LhpA63zPTpOK/Geq7F82gJtIVzwJY2KjKshSnVGsixfOdpTFlAbmJyyt+bp5v1yqHmV6 BI+Ggkvgm+lSL16GKQMCAyHaCr0PIBd/6wYLC1TB3x9v842YS9u3KVXjVZtxqlRri+Ld 2O5bkRPj7aubfBiTW7UyX/JzrSFmYEto7KfFALf6GCiTKOnb5Ivf2pzrW6qs/w2TzOYK 3n7A== MIME-Version: 1.0 X-Received: by 10.60.133.141 with SMTP id pc13mr9988497oeb.68.1416797660538; Sun, 23 Nov 2014 18:54:20 -0800 (PST) Received: by 10.76.178.197 with HTTP; Sun, 23 Nov 2014 18:54:20 -0800 (PST) In-Reply-To: References: <20141116220332392193.5ed69d25@sniff.de> <20141121002512713064.799b449a@sniff.de> Date: Mon, 24 Nov 2014 08:24:20 +0530 Message-ID: Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim From: Manav Bhatia To: "Nobo Akiya (nobo)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/UBeMK2ljJdUVw-P9YjOOkoHfWmo 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, 24 Nov 2014 02:54:24 -0000 I agree that alert-discrim use case and mechanism should go in a separate draft and must not be combined with the base s-bfd drafts. Cheers, Manav On Sun, Nov 23, 2014 at 6:45 AM, Nobo Akiya (nobo) wrote: > Hello BFD WG, > > Marc and I had some conversation on the topic of S-BFD alert discriminator document structure, and converged on a direction. > > - We think that it is useful to describe both the problems and the solution for the S-BFD alert discrimintor in a single document. > - We also think the S-BFD alert discriminator is more like an exception mechanism, thus the mechanism should remain outside of the S-BFD base document. > > Therefore, our converged recommendation to the WG is to keep the extended use-cases and the alert discriminator mechanism in the draft-akiya-bfd-seamless-alert-discrim. > > This also means that no further changes are needed in draft-ietf-bfd-seamless-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forward if authors feel that it is ready. > > We would appreciate it if folks can chime in and state whether or not this is an acceptable way forward. > > Thanks! > > -Nobo & Marc > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Friday, November 21, 2014 3:25 AM >> To: Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >> >> Hello Nobo, >> >> (back from Hawaii or writing emails at the beach? ;-) >> >> >> > Your view is then: >> > >> > Instead of: >> > >> > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and >> > keep the alert discriminator mechanism in the >> > draft-akiya-bfd-seamless-alert-discrim. >> > >> > Do: >> > >> > (2) Keep the extended use-cases and alert discriminator mechanism in >> > the draft-akiya-bfd-seamless-alert-discrim. >> > >> > Or >> > >> > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case >> > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- >> base. >> >> yes, exactly. >> >> >> > Whether the S-BFD packets with alert discriminator are handled in HW >> > or SW is an implementation choice. Similar to how IP router alert >> > option & router alert label are handled, I do see handling of S-BFD >> > packets with alert discriminator in the SW to be a reasonable >> > approach, in which case the HW instruction for S-BFD packets with >> > alert discriminator is to punt to SW for processing. >> >> > Personally, I tend to recommend that alert discriminators are handled >> > in the SW. Let's assume that you agree on this (hypothetically). In >> > that case, would you still recommend the alert discriminator mechanism >> > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to >> > keep it in the draft-akiya-bfd-seamless-alert-discrim? >> >> >> That's probably where our different views come from :-) I would aim to >> simplify the main idea of the draft so it _can_ easily be implemented even >> in hardware. >> >> For the traceroute - my guess is TTL punts (if that mechanism to "deliver" is >> used) happen in software as many mechanism use this "trick" but if a >> hardware can handle TTL punts, it can handle the diag code as well. I don't >> see the document needs to adjust for the traceroute case. >> >> For a basic reflector task, having a zero discriminator as a default reflector >> discriminator would allow for very simple implementations (we discussed a >> while ago a fixed discriminator value for simple broadband modems, >> remember?). >> For more complex equipment and scenarios, keeping it in hardware instead >> of a software punt would maintain the ability of S-BFD to go up very quickly. >> >> >> I tend to not see the zero discriminator as such a big exception, which may >> explain my idea to integrate it into the base document. And to keep it >> compatible to hardware implementations. >> Assuming you want to add more "special effects" in the future I can see why >> you have an extra document. I would propose to keep the zero-reflector >> mentally aligned :-) with the base document and accordingly designed to >> allow implementations to cover the zero-reflector together with "normal" >> S-BFD >> (read: may be in hardware). >> >> >> > Ah, great catch. Yes we do not want "intermediate nodes" to pick up >> > S-BFD packets with alert discriminator. >> >> Good - makes life simpler :-) >> >> >> Regards, Marc >> >> >> On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: >> > Hi Marc, >> > >> > Thanks for providing your view. >> > >> > Please see in-line. >> > >> >> -----Original Message----- >> >> From: Marc Binderberger [mailto:marc@sniff.de] >> >> Sent: Monday, November 17, 2014 1:04 AM >> >> To: Nobo Akiya (nobo) >> >> Cc: rtg-bfd@ietf.org >> >> Subject: Re: Seeking opinions on >> >> draft-akiya-bfd-seamless-alert-discrim >> >> >> >> Hello Nobo and BFD experts, >> >> >> >> giving this document a closer look for the first time (ahem ;-) I >> >> have a slightly different view. >> >> >> >> Having S-BFD use cases for the general S-BFD in an extra document >> >> does improve the overall discussion and documentation, simply because >> >> the base S-BFD is already complex enough, as are the use cases. >> >> >> >> But for such a relatively small document splitting off the reason why >> >> the document exists is not improving the reading/understanding of this >> draft. >> >> Unless you decide to integrate the alert-discriminator document into >> >> the base document, then obviously you use the use-case document. >> > >> > Your view is then: >> > >> > Instead of: >> > >> > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and >> > keep the alert discriminator mechanism in the >> > draft-akiya-bfd-seamless-alert-discrim. >> > >> > Do: >> > >> > (2) Keep the extended use-cases and alert discriminator mechanism in >> > the draft-akiya-bfd-seamless-alert-discrim. >> > >> > Or >> > >> > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case >> > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- >> base. >> > >> > My thought was that (1) makes sense, but your view that (1) makes all >> > the S-BFD documents set more complex to understand is a valid concern >> > (it's always good to get fresh eyes on documents!). >> > >> >> >> >> >> >> For the integration of the technical aspect into the base document, I >> >> think this is an idea worth to discuss. At the end what you need is >> >> to add the rule for the zero discriminator to the reflector >> >> behaviour; we managed this for standard BFD, we should be able to do >> >> this for the reflector BFD as well >> >> :-) >> > >> > Whether the S-BFD packets with alert discriminator are handled in HW >> > or SW is an implementation choice. Similar to how IP router alert >> > option & router alert label are handled, I do see handling of S-BFD >> > packets with alert discriminator in the SW to be a reasonable >> > approach, in which case the HW instruction for S-BFD packets with >> > alert discriminator is to punt to SW for processing. >> > >> >> For the diagnostic codes I'm not sure; it will complicate hardware >> >> implementations (probably not a no-go problem though) and seems >> >> otherwise not add a real value IMHO. >> > >> > If one really wants to handle them in the HW, that's a possibility. >> > Although as you stated, it does complicate HW implementations and this >> > is another reason for SW based implementations. >> > >> >> >> >> So if there are already at this stage of S-BFD use case(s) for zero- >> >> discriminator to bring up (some) sessions then I would propose to >> >> consider the integration into the base document. This will also >> >> guarantee that the zero-discriminator handling is as fast as the >> >> "normal" reflection and is not on a slower exception path. >> > >> > Personally, I tend to recommend that alert discriminators are handled >> > in the SW. Let's assume that you agree on this (hypothetically). In >> > that case, would you still recommend the alert discriminator mechanism >> > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to >> > keep it in the draft-akiya-bfd-seamless-alert-discrim? >> > >> >> >> >> >> >> >> >> I have a question: so far S-BFD packets would be received, not >> >> "picked out of the data stream". Receiving could be because the >> >> destination IP would match or would be 127/8, the TTL would be zero >> >> and so on. In the security section you say ... >> >> >> >> Conceptually the Alert Discriminator is similar to an IP Router Alert >> >> Option or an MPLS Router Alert Label. >> >> >> >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the >> >> reflector) with an alert-discriminator out of the data stream that >> >> otherwise would just pass this node? >> >> I guess you don't want but I want to make sure I understand it correctly. >> > >> > Ah, great catch. Yes we do not want "intermediate nodes" to pick up >> > S-BFD packets with alert discriminator. So the statement regarding >> > "Conceptually the Alert Discriminator is similar to an IP Router Alert >> > Option or an MPLS Router Alert Label" should be re-stated and clarified. >> > >> > Thanks! >> > >> > -Nobo >> > >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: >> >>> [Speaking as an individual S-BFD contributor] >> >>> >> >>> Hi BFD WG, >> >>> >> >>> There were couple of questions I need your input on >> >>> draft-akiya-bfd-seamless-alert-discrim. >> >>> >> >>> >> >>> (1) Should the "extended" S-BFD use cases move to >> >>> draft-ietf-bfd-seamless-use-case? >> >>> >> >>> My opinion is yes. Once the "extended" S-BFD use cases have been >> >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should >> >>> try to move draft-ietf-bfd-seamless-use-case forward. >> >>> >> >>> How does the WG feel about this? >> >>> >> >>> >> >>> (2) Should the alert discriminator proposal move to >> >>> draft-ietf-bfd-seamless-base? >> >>> >> >>> My opinion is no . Instead we should position this as an optional >> >>> feature of S-BFD (hence separate document than the base), especially >> >>> considering we likely need to think through additional security >> >>> concerns >> >> raised by this. >> >>> >> >>> A question was raised by Greg on how does a node find out if the >> >>> target supports the optional alert discriminator or not. We can >> >>> define a mandatory diagnostic value that must be implemented when >> >>> the alert discriminator is implemented. One can send an S-BFD >> >>> control packet with the alert discriminator with this diagnostic >> >>> value to check if the target supports the alert discriminator mechanism. >> >>> >> >>> How does the WG feel about this? >> >>> >> >>> >> >>> Thanks! >> >>> >> >>> -Nobo >> >>> >> > > From nobody Sun Nov 23 19:37: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 8AA351A1BB7 for ; Sun, 23 Nov 2014 19:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7DYQzd1Vi_0 for ; Sun, 23 Nov 2014 19:37:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919EF1A1BB5 for ; Sun, 23 Nov 2014 19:37:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLY57542; Mon, 24 Nov 2014 03:37:02 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Nov 2014 03:37:01 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.72]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 24 Nov 2014 11:36:58 +0800 From: Mingui Zhang To: Santosh P K , Gregory Mirsky , "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: AQHPu0hWKEpQ2rtLyk+1UKjzaDPn65vXcWwAgEtadACAAAnegIAE26WAgAA3/wCAAIDAgIAAy7IAgAYPagCAALvkgIAFsnwAgAU+f4CALnzKAIABnSkAgAJ5AoCAAAqGgIAAJWCAgAALQwCAAeG20A== Date: Mon, 24 Nov 2014 03:36:57 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bUtsbbmRGBoiJW4gFgeikBQcjMI 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, 24 Nov 2014 03:37:06 -0000 Hi Santosh, >Ok so I think we are making progress on this. I understand that we need to= do >below. > >Keep base document with IP demux and MPLS demux. For any other (TRILLS, >MPLS ACH) demux required come up with a new draft. I think this is reasonable. Thanks, Mingui >-----Original Message----- >From: Santosh P K [mailto:santoshpk@juniper.net] >Sent: Sunday, November 23, 2014 1:30 PM >To: Gregory Mirsky; 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 > >Hello Greg, > Thanks a lot of your comments. Please see inline. > >> > > 1.=A0=A0=A0=A0=A0=A0 Active tail. >> > > As discussed earlier, is this required in base draft? I spoke >> > > to all implementers =A0and no one has active tail implemented yet. T= o >> > > push it for RFC we need implementation so can we go ahead and move >> > > it to appendix or may be new document? >> > > >> > > WH> I would propose we do the active tail in appendix or a separate >> > > WH> draft >> > >> > [NOBO] Wim, can you clarify which you mean? >> > >> > A) You propose reliable head notification to be moved. >> > B) You propose semi-reliable and reliable head notifications to be mov= ed. >> > C) You propose unreliable, semi-reliable and reliable head >> > notifications to be moved. >> > >> > You can find the description of each notifications in page 4 of >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. >> > >> > My preference will be (A). >> > >> Moving reliable head notification to appendix or new document you mean := ) >> ? >> GIM>> My preference - C into the separate draft. And all related updates= of >> state machine and new variables - go with it. > >Ok so we have > >1. Moving reliable notification option (A) moving to separate document/app= endix. >(Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate >document/appendix. (Greg's preference) > >Wim you have any preference on this? > > > >> >> > > >> > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. >> > > It makes more sense to have a separate draft for this. Please >> > > let me know if that is ok? If it benefits to have it in base draft >> > > itself then we can have more sections for demux and port number to >> > > be >> > used. >> > > >> > > WH> it should be in the draft I believe >> > >> > [NOBO] So ... >> > >> > Option 1 is to describe the demux codepoint & procedures in the bfd- >> > multipoint document. >> > Option 2 is to describe the demux codepoint & procedures in separate >> > data plane document(s). >> > >> > It sounds like Santosh is preferring Option 2 while Wim is preferring = option >> 1. >> > >> > Perhaps there's an Option 3. >> > >> > The bfd-multipoint document to describe one or two basic data plane >> > demux codepoint & procedures cleanly in a separate section (ex: IP and >> MPLS). >> > Other data planes documents (ex: TRILL) can update the demux section >> > of the bfd-multipoint document. Just thinking out loud ... >> > >> >> Currently in document it tries to explain how to demux for IP only in se= ction >> 4.8. We can add more text for clarity. >> I am ok with option 1 where all procedure dumped in single document but = I >> am worried that in future some other data plane wants a new way of >> demultiplexing then we may need to change the base document again? >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS >> ACH, would have to write documents of their own. > >Ok so I think we are making progress on this. I understand that we need to= do >below. > >Keep base document with IP demux and MPLS demux. For any other (TRILLS, >MPLS ACH) demux required come up with a new draft. > > >> > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? >> > > Echo mode does not fit in P2MP BFD. We can say it is not >supported. >> > > Does anyone see use of echo BFD in P2MP BFD? >> > > >> > > WH> I don't see a use case for this so far >> > >> > [NOBO] Agree, I see no value in the multipoint document considering >> > the echo inside the scope. >> >> Thanks. >> GIM>> Agree, no echo mode. > >Thanks. We are converging on this point. > >> >> > > >> > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? >> > > Draft suggest not to use POLL sequence and suggests to increase >> > > multiplier first and then interval. If we have hardware >> > > implementation and don't want to check complete packet every time >> > > received then change in packet may be indicated with POLL bit set. >> > > Since this is one to many mapping we can't have a complete POLL >> > > sequence and hence we need to suppress FINAL. Should we be going >> > > with POLL and suppress FINAL by setting desired RX interval set to >> > > 0? Please suggest any better idea. >> > >> > [NOBO] If we keep the semi-reliable head notification, then I would >> > have expected P/F (from head to tails) to just work? >> >> With semi-reliable head notification you want to have complete POLL >> sequence for interval negotiation? One to many mapping will have issues >> with complete POLL sequence. Can you elaborate how this will help? >> >> >> > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown >> > > Draft suggests that head direct tails to send down >> > > notification. How will head direct tail about failure notification >> > > to be sent or not? Is this driven by configuration? At least the >> > > section >> > > 4.4.1 says so. It could also be communicated to >> > > received out of band? >> > > >> > > This should be out of scope of this document as we can't >> > > direct tails with in BFD packet. Any comments? >> > >> > [NOBO] This is something which can be configured, thus out of scope >> > [for now] should be fine. One reason that I have been pushing to keep >> > semi- reliable head notification is that it can catch instances of odd >> > cases like tails not having consistent configurations ... i.e, only >> > some tails notify and some don't. Head doing the in-band polling can >> > discover the available tails, becomes more of a fail-safe mechanism. >> >> Agreed. It makes sense to have semi-reliable here. >> >> GIM>> I think that I disagree on this. Configuration can be verified by = other >> means. I consider the base of multi-point BFD as mechanism suitable for = 1+1 >> protection switchover. Any type of tail monitoring, IMO, is optional and= can >> be document of its own. > >Hmmm so this means we need converge on below options for tail monitoring. > >1. Moving reliable notification option (A) moving to separate document/app= endix. >(Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate >document/appendix. (Greg's preference) > > >> > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? >> > > Few implementers use UDP port number to absorb BFD packet on tails. >> > > It would be good to clarify about this in draft. Do we see any other >> > > way of absorbing packet on tail? >> > >> > [NOBO] >> > >> > For IP: >> > - UDP port. >> > >> > For MPLS: >> > - 127/8 and UDP port. >> > - UHP does not require bootstrapping but PHP will require bootstrappin= g. >> >> GIM>> Why would bootstrapping be required for multi-point BFD session in >> MPLS data plane with PHP if tail monitoring is not required? > >In case of PHP tail will not know which how to associate BFD received pack= et to >an LSP as all BFD packets will come with 127/8 address. This is why we nee= d >boot strapping with MPLS LSP ping. There was a draft for the same long tim= e >ago. > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > >Thanks >Santosh P K From nobody Sun Nov 23 21:49: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 C9FDF1A1BE6 for ; Sun, 23 Nov 2014 21:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCJ08xL6P_j1 for ; Sun, 23 Nov 2014 21:49:17 -0800 (PST) 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 4896F1A1BDE for ; Sun, 23 Nov 2014 21:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28247; q=dns/txt; s=iport; t=1416808157; x=1418017757; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Ed0GROBY3wVDfC0Tjp2VT0jxqVPTMG9Ix0WjX3KnCgk=; b=K8EdlFG1/UCqVULlf/tBR7gPMlr1rHevX4jYtHreG7OzEaBTT73ZfIu4 Ovx0tuAimEJg8Kuw6KScpUzdXXe4pX5TWjQJPmITi8NusQwYORxVJN1TW biZpRq1N+oCuYE1/gBX67kFcYcUQAv+eAviKVzGnzqdPndBqw2fJLyfzL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFACPGclStJV2U/2dsb2JhbABbgkhGgS4EyUCJIwKBFRYBAQEBAX2EAgEBAQMBGlEJBQUHBgEIEQMBAQEBIAcmExQJAwUBAQQBDQUZAogdCc16AQEBAQEBAQEBAQEBAQEBAQEBAQEBF5B6EQcGhEgFkDqCLgWMFIE0g1mDOIpLhAqDfXiBSIEDAQEB X-IronPort-AV: E=Sophos; i="5.07,447,1413244800"; d="scan'208,217"; a="99466626" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP; 24 Nov 2014 05:49:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAO5nF8p014385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 05:49:16 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sun, 23 Nov 2014 23:49:15 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAA= Date: Mon, 24 Nov 2014 05:49:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.20] Content-Type: multipart/alternative; boundary="_000_D098C403279A9mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/JxPa973xwRr2PNtb9hfKA5Dctfk 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, 24 Nov 2014 05:49:22 -0000 --_000_D098C403279A9mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nobo, Agree that the Alert Discriminator must be described in a separate document= . Since the SBFD use case document is listing out all the use cases of SBFD= don=92t you think we should at least mention the alert discriminator func= tion as on of the use cases and place a reference to the alert discriminato= r document in the use cases. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Sunday, 23 November 2014 6:45 am To: Marc Binderberger > Cc: "rtg-bfd@ietf.org" > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hello BFD WG, Marc and I had some conversation on the topic of S-BFD alert discriminator = document structure, and converged on a direction. - We think that it is useful to describe both the problems and the solution= for the S-BFD alert discrimintor in a single document. - We also think the S-BFD alert discriminator is more like an exception mec= hanism, thus the mechanism should remain outside of the S-BFD base document= . Therefore, our converged recommendation to the WG is to keep the extended u= se-cases and the alert discriminator mechanism in the draft-akiya-bfd-seaml= ess-alert-discrim. This also means that no further changes are needed in draft-ietf-bfd-seamle= ss-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forwar= d if authors feel that it is ready. We would appreciate it if folks can chime in and state whether or not this = is an acceptable way forward. Thanks! -Nobo & Marc -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Friday, November 21, 2014 3:25 AM To: Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hello Nobo, (back from Hawaii or writing emails at the beach? ;-) > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > keep the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in > the draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- base. yes, exactly. > Whether the S-BFD packets with alert discriminator are handled in HW > or SW is an implementation choice. Similar to how IP router alert > option & router alert label are handled, I do see handling of S-BFD > packets with alert discriminator in the SW to be a reasonable > approach, in which case the HW instruction for S-BFD packets with > alert discriminator is to punt to SW for processing. > Personally, I tend to recommend that alert discriminators are handled > in the SW. Let's assume that you agree on this (hypothetically). In > that case, would you still recommend the alert discriminator mechanism > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > keep it in the draft-akiya-bfd-seamless-alert-discrim? That's probably where our different views come from :-) I would aim to simplify the main idea of the draft so it _can_ easily be implemented even in hardware. For the traceroute - my guess is TTL punts (if that mechanism to "deliver" = is used) happen in software as many mechanism use this "trick" but if a hardware can handle TTL punts, it can handle the diag code as well. I don't see the document needs to adjust for the traceroute case. For a basic reflector task, having a zero discriminator as a default reflec= tor discriminator would allow for very simple implementations (we discussed a while ago a fixed discriminator value for simple broadband modems, remember?). For more complex equipment and scenarios, keeping it in hardware instead of a software punt would maintain the ability of S-BFD to go up very quickl= y. I tend to not see the zero discriminator as such a big exception, which may explain my idea to integrate it into the base document. And to keep it compatible to hardware implementations. Assuming you want to add more "special effects" in the future I can see why you have an extra document. I would propose to keep the zero-reflector mentally aligned :-) with the base document and accordingly designed to allow implementations to cover the zero-reflector together with "normal" S-BFD (read: may be in hardware). > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > S-BFD packets with alert discriminator. Good - makes life simpler :-) Regards, Marc On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, > > Thanks for providing your view. > > Please see in-line. > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, November 17, 2014 1:04 AM >> To: Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Seeking opinions on >> draft-akiya-bfd-seamless-alert-discrim >> >> Hello Nobo and BFD experts, >> >> giving this document a closer look for the first time (ahem ;-) I >> have a slightly different view. >> >> Having S-BFD use cases for the general S-BFD in an extra document >> does improve the overall discussion and documentation, simply because >> the base S-BFD is already complex enough, as are the use cases. >> >> But for such a relatively small document splitting off the reason why >> the document exists is not improving the reading/understanding of this draft. >> Unless you decide to integrate the alert-discriminator document into >> the base document, then obviously you use the use-case document. > > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > keep the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in > the draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- base. > > My thought was that (1) makes sense, but your view that (1) makes all > the S-BFD documents set more complex to understand is a valid concern > (it's always good to get fresh eyes on documents!). > >> >> >> For the integration of the technical aspect into the base document, I >> think this is an idea worth to discuss. At the end what you need is >> to add the rule for the zero discriminator to the reflector >> behaviour; we managed this for standard BFD, we should be able to do >> this for the reflector BFD as well >> :-) > > Whether the S-BFD packets with alert discriminator are handled in HW > or SW is an implementation choice. Similar to how IP router alert > option & router alert label are handled, I do see handling of S-BFD > packets with alert discriminator in the SW to be a reasonable > approach, in which case the HW instruction for S-BFD packets with > alert discriminator is to punt to SW for processing. > >> For the diagnostic codes I'm not sure; it will complicate hardware >> implementations (probably not a no-go problem though) and seems >> otherwise not add a real value IMHO. > > If one really wants to handle them in the HW, that's a possibility. > Although as you stated, it does complicate HW implementations and this > is another reason for SW based implementations. > >> >> So if there are already at this stage of S-BFD use case(s) for zero- >> discriminator to bring up (some) sessions then I would propose to >> consider the integration into the base document. This will also >> guarantee that the zero-discriminator handling is as fast as the >> "normal" reflection and is not on a slower exception path. > > Personally, I tend to recommend that alert discriminators are handled > in the SW. Let's assume that you agree on this (hypothetically). In > that case, would you still recommend the alert discriminator mechanism > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > keep it in the draft-akiya-bfd-seamless-alert-discrim? > >> >> >> >> I have a question: so far S-BFD packets would be received, not >> "picked out of the data stream". Receiving could be because the >> destination IP would match or would be 127/8, the TTL would be zero >> and so on. In the security section you say ... >> >> Conceptually the Alert Discriminator is similar to an IP Router Alert >> Option or an MPLS Router Alert Label. >> >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the >> reflector) with an alert-discriminator out of the data stream that >> otherwise would just pass this node? >> I guess you don't want but I want to make sure I understand it correctly= . > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > S-BFD packets with alert discriminator. So the statement regarding > "Conceptually the Alert Discriminator is similar to an IP Router Alert > Option or an MPLS Router Alert Label" should be re-stated and clarified. > > Thanks! > > -Nobo > >> >> >> Regards, Marc >> >> >> >> >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: >>> [Speaking as an individual S-BFD contributor] >>> >>> Hi BFD WG, >>> >>> There were couple of questions I need your input on >>> draft-akiya-bfd-seamless-alert-discrim. >>> >>> >>> (1) Should the "extended" S-BFD use cases move to >>> draft-ietf-bfd-seamless-use-case? >>> >>> My opinion is yes. Once the "extended" S-BFD use cases have been >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should >>> try to move draft-ietf-bfd-seamless-use-case forward. >>> >>> How does the WG feel about this? >>> >>> >>> (2) Should the alert discriminator proposal move to >>> draft-ietf-bfd-seamless-base? >>> >>> My opinion is no . Instead we should position this as an optional >>> feature of S-BFD (hence separate document than the base), especially >>> considering we likely need to think through additional security >>> concerns >> raised by this. >>> >>> A question was raised by Greg on how does a node find out if the >>> target supports the optional alert discriminator or not. We can >>> define a mandatory diagnostic value that must be implemented when >>> the alert discriminator is implemented. One can send an S-BFD >>> control packet with the alert discriminator with this diagnostic >>> value to check if the target supports the alert discriminator mechanism= . >>> >>> How does the WG feel about this? >>> >>> >>> Thanks! >>> >>> -Nobo >>> > --_000_D098C403279A9mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Nobo,

Agree that the Alert Discriminator must be described in a separate doc= ument. Since the SBFD use case document is listing out all the use cases of= SBFD don=92t you think we should at least mention  the alert discrimi= nator function as on of the use cases and place a reference to the alert discriminator document in the use cases.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Sunday, 23 November 2014 6:45= am
To: Marc Binderberger <marc@sniff.de>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: RE: Seeking opinions on dr= aft-akiya-bfd-seamless-alert-discrim

Hello BFD WG,

Marc and I had some conversation on the topic of S-BFD alert discrimin= ator document structure, and converged on a direction.

- We think that it is useful to describe both the problems and the sol= ution for the S-BFD alert discrimintor in a single document.
- We also think the S-BFD alert discriminator is more like an exceptio= n mechanism, thus the mechanism should remain outside of the S-BFD base doc= ument.

Therefore, our converged recommendation to the WG is to keep the exten= ded use-cases and the alert discriminator mechanism in the draft-akiya-bfd-= seamless-alert-discrim.

This also means that no further changes are needed in draft-ietf-bfd-s= eamless-use-case, and the draft-ietf-bfd-seamless-use-case can progressed f= orward if authors feel that it is ready.

We would appreciate it if folks can chime in and state whether or not = this is an acceptable way forward.

Thanks!

-Nobo & Marc
-----Original Message-----
From: Marc Binderberger [mailto:marc@= sniff.de]
Sent: Friday, November 21, 2014 3:25 AM
To: Nobo Akiya (nobo)
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discri= m
Hello Nobo,
(back from Hawaii or writing emails at the beach? ;-)
> Your view is then:
>
> Instead of:
>
> (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case a= nd
> keep the alert discriminator mechanism in the
> draft-akiya-bfd-seamless-alert-discrim.
>
> Do:
>
> (2) Keep the extended use-cases and alert discriminator mechanism= in
> the draft-akiya-bfd-seamless-alert-discrim.
>
> Or
>
> (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-ca= se
> and move the alert discriminator mechanism to draft-ietf-bfd-seam= less-
base.
yes, exactly.
> Whether the S-BFD packets with alert discriminator are handled in= HW
> or SW is an implementation choice. Similar to how IP router alert=
> option & router alert label are handled, I do see handling of= S-BFD
> packets with alert discriminator in the SW to be a reasonable
> approach, in which case the HW instruction for S-BFD packets with=
> alert discriminator is to punt to SW for processing.
> Personally, I tend to recommend that alert discriminators are han= dled
> in the SW. Let's assume that you agree on this (hypothetically). = In
> that case, would you still recommend the alert discriminator mech= anism
> to be moved to the draft-ietf-bfd-seamless-base or is it reasonab= le to
> keep it in the draft-akiya-bfd-seamless-alert-discrim?
That's probably where our different views come from :-) I would aim to=
simplify the main idea of the draft so it _can_ easily be implemented = even
in hardware.
For the traceroute - my guess is TTL punts (if that mechanism to "= ;deliver" is
used) happen in software as many mechanism use this "trick" = but if a
hardware can handle TTL punts, it can handle the diag code as well. I = don't
see the document needs to adjust for the traceroute case.
For a basic reflector task, having a zero discriminator as a default r= eflector
discriminator would allow for very simple implementations (we discusse= d a
while ago a fixed discriminator value for simple broadband modems,
remember?).
For more complex equipment and scenarios, keeping it in hardware inste= ad
of a software punt would maintain the ability of S-BFD to go up very q= uickly.
I tend to not see the zero discriminator as such a big exception, whic= h may
explain my idea to integrate it into the base document. And to keep it=
compatible to hardware implementations.
Assuming you want to add more "special effects" in the futur= e I can see why
you have an extra document. I would propose to keep the zero-reflector=
mentally aligned :-) with the base document and accordingly designed t= o
allow implementations to cover the zero-reflector together with "= normal"
S-BFD
(read: may be in hardware).
> Ah, great catch. Yes we do not want "intermediate nodes"= ; to pick up
> S-BFD packets with alert discriminator.
Good - makes life simpler :-)
Regards, Marc
On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote:
> Hi Marc,
>
> Thanks for providing your view.
>
> Please see in-line.
>
>> -----Original Message-----
>> From: Marc Binderberger [mai= lto:marc@sniff.de]
>> Sent: Monday, November 17, 2014 1:04 AM
>> To: Nobo Akiya (nobo)
>> Cc: rtg-bfd@ietf.org<= /div>
>> Subject: Re: Seeking opinions on
>> draft-akiya-bfd-seamless-alert-discrim
>>
>> Hello Nobo and BFD experts,
>>
>> giving this document a closer look for the first time (ahem ;= -) I
>> have a slightly different view.
>>
>> Having S-BFD use cases for the general S-BFD in an extra docu= ment
>> does improve the overall discussion and documentation, simply= because
>> the base S-BFD is already complex enough, as are the use case= s.
>>
>> But for such a relatively small document splitting off the re= ason why
>> the document exists is not improving the reading/understandin= g of this
draft.
>> Unless you decide to integrate the alert-discriminator docume= nt into
>> the base document, then obviously you use the use-case docume= nt.
>
> Your view is then:
>
> Instead of:
>
> (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case a= nd
> keep the alert discriminator mechanism in the
> draft-akiya-bfd-seamless-alert-discrim.
>
> Do:
>
> (2) Keep the extended use-cases and alert discriminator mechanism= in
> the draft-akiya-bfd-seamless-alert-discrim.
>
> Or
>
> (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-ca= se
> and move the alert discriminator mechanism to draft-ietf-bfd-seam= less-
base.
>
> My thought was that (1) makes sense, but your view that (1) makes= all
> the S-BFD documents set more complex to understand is a valid con= cern
> (it's always good to get fresh eyes on documents!).
>
>>
>>
>> For the integration of the technical aspect into the base doc= ument, I
>> think this is an idea worth to discuss. At the end what you n= eed is
>> to add the rule for the zero discriminator to the reflector
>> behaviour; we managed this for standard BFD, we should be abl= e to do
>> this for the reflector BFD as well
>> :-)
>
> Whether the S-BFD packets with alert discriminator are handled in= HW
> or SW is an implementation choice. Similar to how IP router alert=
> option & router alert label are handled, I do see handling of= S-BFD
> packets with alert discriminator in the SW to be a reasonable
> approach, in which case the HW instruction for S-BFD packets with=
> alert discriminator is to punt to SW for processing.
>
>> For the diagnostic codes I'm not sure; it will complicate har= dware
>> implementations (probably not a no-go problem though) and see= ms
>> otherwise not add a real value IMHO.
>
> If one really wants to handle them in the HW, that's a possibilit= y.
> Although as you stated, it does complicate HW implementations and= this
> is another reason for SW based implementations.
>
>>
>> So if there are already at this stage of S-BFD use case(s) fo= r zero-
>> discriminator to bring up (some) sessions then I would propos= e to
>> consider the integration into the base document. This will al= so
>> guarantee that the zero-discriminator handling is as fast as = the
>> "normal" reflection and is not on a slower exceptio= n path.
>
> Personally, I tend to recommend that alert discriminators are han= dled
> in the SW. Let's assume that you agree on this (hypothetically). = In
> that case, would you still recommend the alert discriminator mech= anism
> to be moved to the draft-ietf-bfd-seamless-base or is it reasonab= le to
> keep it in the draft-akiya-bfd-seamless-alert-discrim?
>
>>
>>
>>
>> I have a question: so far S-BFD packets would be received, no= t
>> "picked out of the data stream". Receiving could be= because the
>> destination IP would match or would be 127/8, the TTL would b= e zero
>> and so on. In the security section you say ...
>>
>>    Conceptually the Alert Discriminator i= s similar to an IP Router Alert
>>    Option or an MPLS Router Alert Label.<= /div>
>>
>> ... and I wonder if you expect a node to "pick" S-B= FD traffic (to the
>> reflector) with an alert-discriminator out of the data stream= that
>> otherwise would just pass this node?
>> I guess you don't want but I want to make sure I understand i= t correctly.
>
> Ah, great catch. Yes we do not want "intermediate nodes"= ; to pick up
> S-BFD packets with alert discriminator. So the statement regardin= g
> "Conceptually the Alert Discriminator is similar to an IP Ro= uter Alert
> Option or an MPLS Router Alert Label" should be re-stated an= d clarified.
>
> Thanks!
>
> -Nobo
>
>>
>>
>> Regards, Marc
>>
>>
>>
>>
>> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wro= te:
>>> [Speaking as an individual S-BFD contributor]
>>>
>>> Hi BFD WG,
>>>
>>> There were couple of questions I need your input on
>>> draft-akiya-bfd-seamless-alert-discrim.
>>>
>>>
>>> (1) Should the "extended" S-BFD use cases move = to
>>> draft-ietf-bfd-seamless-use-case?
>>>
>>> My opinion is yes. Once the "extended" S-BFD us= e cases have been
>>> incorporated into draft-ietf-bfd-seamless-use-case, then = we should
>>> try to move draft-ietf-bfd-seamless-use-case forward.
>>>
>>> How does the WG feel about this?
>>>
>>>
>>> (2) Should the alert discriminator proposal move to
>>> draft-ietf-bfd-seamless-base?
>>>
>>> My opinion is no . Instead we should position this as an = optional
>>> feature of S-BFD (hence separate document than the base),= especially
>>> considering we likely need to think through additional se= curity
>>> concerns
>> raised by this.
>>>
>>> A question was raised by Greg on how does a node find out= if the
>>> target supports the optional alert discriminator or not. = We can
>>> define a mandatory diagnostic value that must be implemen= ted when
>>> the alert discriminator is implemented. One can send an S= -BFD
>>> control packet with the alert discriminator with this dia= gnostic
>>> value to check if the target supports the alert discrimin= ator mechanism.
>>>
>>> How does the WG feel about this?
>>>
>>>
>>> Thanks!
>>>
>>> -Nobo
>>>
>


 --_000_D098C403279A9mmudigonciscocom_-- From nobody Sun Nov 23 22:03:52 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 02E171A1BC6 for ; Sun, 23 Nov 2014 22:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNJFB9609yCY for ; Sun, 23 Nov 2014 22:03:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03DB1A1B2D for ; Sun, 23 Nov 2014 22:03:48 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 24 Nov 2014 06:03:46 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Mon, 24 Nov 2014 06:03:45 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Henderickx, Wim (Wim)" , Gregory Mirsky , 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/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAFRiAIAA/8oAgABMM5A= Date: Mon, 24 Nov 2014 06:03:45 +0000 Message-ID: <4a9951b86b234f74b379624d5f1fe6bb@CO2PR0501MB823.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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@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: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 040513D301 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(41574002)(51704005)(377454003)(13464003)(99396003)(120916001)(95666004)(105586002)(230783001)(107046002)(50986999)(77156002)(62966003)(106116001)(93886004)(107886001)(99286002)(101416001)(108616004)(122556002)(74316001)(64706001)(20776003)(92566001)(76576001)(66066001)(21056001)(86362001)(54356999)(106356001)(15975445006)(40100003)(4396001)(33646002)(46102003)(31966008)(19580395003)(19580405001)(76176999)(97736003)(15202345003)(2656002)(87936001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/mg83fQ3-e0Mrte-02bkH8RxMrMQ 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, 24 Nov 2014 06:03:51 -0000 Thanks Nobo. > -----Original Message----- > From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > Sent: Monday, November 24, 2014 7:01 AM > To: Henderickx, Wim (Wim); Santosh P K; Gregory Mirsky; Jeffrey Haas; rtg= - > bfd@ietf.org; Mingui Zhang > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hi Santosh, >=20 > > >> > > 1. Active tail. > > >> > > As discussed earlier, is this required in base draft? I > > >> > > spoke to all implementers and no one has active tail > > >> > > implemented yet. To push it for RFC we need implementation so > > >> > > can we go ahead and move it to appendix or may be new > document? > > >> > > > > >> > > WH> I would propose we do the active tail in appendix or a > > >> > > WH> separate draft > > >> > > > >> > [NOBO] Wim, can you clarify which you mean? > > >> > > > >> > A) You propose reliable head notification to be moved. > > >> > B) You propose semi-reliable and reliable head notifications to > > >> > be > > >>moved. > > >> > C) You propose unreliable, semi-reliable and reliable head > > >> > notifications to be moved. > > >> > > > >> > You can find the description of each notifications in page 4 of > > >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > > >> > > > >> > My preference will be (A). > > >> > > > >> Moving reliable head notification to appendix or new document you > > >>mean > > >>:) > > >> ? > > >> GIM>> My preference - C into the separate draft. And all related > > >>updates of > > >> state machine and new variables - go with it. > > > > > >Ok so we have > > > > > >1. Moving reliable notification option (A) moving to separate > > >document/appendix. (Nobo's preference) 2. Moving unreliable, > > >semi-reliable and reliable (C) to separate document/appendix. (Greg's > > >preference) > > > > > >Wim you have any preference on this? > > WH> I would prefer C a per Greg=B9s suggestion >=20 > If the majority of the WG thinks we should go with (C), then I wouldn't > oppose. >=20 > There is a benefit in progressing the portion that we all agree on, and r= evisit > those questionable parts when there are stronger requirements. >=20 > Thanks! >=20 > -Nobo From nobody Sun Nov 23 22:04: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 442B91A1BDD for ; Sun, 23 Nov 2014 22:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO4UMwbupYWs for ; Sun, 23 Nov 2014 22:04:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:791]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF941A1BC6 for ; Sun, 23 Nov 2014 22:04:32 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 24 Nov 2014 06:04:08 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Mon, 24 Nov 2014 06:04:08 +0000 From: Santosh P K To: "Henderickx, Wim (Wim)" , "Gregory Mirsky" , "Nobo Akiya (nobo)" , 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/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAFRiAIABTAkg Date: Mon, 24 Nov 2014 06:04:08 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@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: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 040513D301 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51444003)(479174003)(189002)(24454002)(35774003)(13464003)(199003)(51704005)(377454003)(105586002)(106116001)(93886004)(31966008)(33646002)(15975445006)(101416001)(76576001)(107046002)(107886001)(106356001)(99286002)(95666004)(21056001)(64706001)(230783001)(40100003)(108616004)(120916001)(66066001)(97736003)(46102003)(92566001)(20776003)(99396003)(122556002)(2656002)(86362001)(19580395003)(19580405001)(87936001)(74316001)(77156002)(62966003)(76176999)(50986999)(54356999)(4396001)(15202345003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/n_hpSNnKd6teh9xxNggn-slLA_Q 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, 24 Nov 2014 06:04:35 -0000 Thanks Wim for clarifying.=20 Thanks Santosh P K=20 > -----Original Message----- > From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] > Sent: Sunday, November 23, 2014 3:45 PM > To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Jeffrey Haas; rtg- > bfd@ietf.org; Mingui Zhang > Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > In-line with WH> >=20 > On 23/11/14 06:29, "Santosh P K" wrote: >=20 > >Hello Greg, > > Thanks a lot of your comments. Please see inline. > > > >> > > 1. Active tail. > >> > > As discussed earlier, is this required in base draft? I > >> > > spoke to all implementers and no one has active tail implemented > >> > > yet. To push it for RFC we need implementation so can we go ahead > >> > > and move it to appendix or may be new document? > >> > > > >> > > WH> I would propose we do the active tail in appendix or a > >> > > WH> separate draft > >> > > >> > [NOBO] Wim, can you clarify which you mean? > >> > > >> > A) You propose reliable head notification to be moved. > >> > B) You propose semi-reliable and reliable head notifications to be > >>moved. > >> > C) You propose unreliable, semi-reliable and reliable head > >> > notifications to be moved. > >> > > >> > You can find the description of each notifications in page 4 of > >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > >> > > >> > My preference will be (A). > >> > > >> Moving reliable head notification to appendix or new document you > >>mean > >>:) > >> ? > >> GIM>> My preference - C into the separate draft. And all related > >>updates of > >> state machine and new variables - go with it. > > > >Ok so we have > > > >1. Moving reliable notification option (A) moving to separate > >document/appendix. (Nobo's preference) 2. Moving unreliable, > >semi-reliable and reliable (C) to separate document/appendix. (Greg's > >preference) > > > >Wim you have any preference on this? > WH> I would prefer C a per Greg=B9s suggestion > > > > > > > > > >> > >> > > > >> > > 2. Demultiplexing and UDP port number. > >> > > It makes more sense to have a separate draft for this. > >> > > Please let me know if that is ok? If it benefits to have it in > >> > > base draft itself then we can have more sections for demux and > >> > > port number to be > >> > used. > >> > > > >> > > WH> it should be in the draft I believe > >> > > >> > [NOBO] So ... > >> > > >> > Option 1 is to describe the demux codepoint & procedures in the > >> > bfd- multipoint document. > >> > Option 2 is to describe the demux codepoint & procedures in > >> > separate data plane document(s). > >> > > >> > It sounds like Santosh is preferring Option 2 while Wim is > >> > preferring > >>option > >> 1. > >> > > >> > Perhaps there's an Option 3. > >> > > >> > The bfd-multipoint document to describe one or two basic data plane > >> > demux codepoint & procedures cleanly in a separate section (ex: IP > >> > and > >> MPLS). > >> > Other data planes documents (ex: TRILL) can update the demux > >> > section of the bfd-multipoint document. Just thinking out loud ... > >> > > >> > >> Currently in document it tries to explain how to demux for IP only in > >>section 4.8. We can add more text for clarity. > >> I am ok with option 1 where all procedure dumped in single document > >>but I am worried that in future some other data plane wants a new way > >>of demultiplexing then we may need to change the base document > again? > >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS > >> ACH, would have to write documents of their own. > > > >Ok so I think we are making progress on this. I understand that we need > >to do below. > > > >Keep base document with IP demux and MPLS demux. For any other > (TRILLS, > >MPLS ACH) demux required come up with a new draft. > WH> I agree to make a separate doc on other demux schemes other than IP > and MPLS > > > > > > > >> > > 3. Echo mode supported? > >> > > Echo mode does not fit in P2MP BFD. We can say it is not > >>supported. > >> > > Does anyone see use of echo BFD in P2MP BFD? > >> > > > >> > > WH> I don't see a use case for this so far > >> > > >> > [NOBO] Agree, I see no value in the multipoint document considering > >> > the echo inside the scope. > >> > >> Thanks. > >> GIM>> Agree, no echo mode. > > > >Thanks. We are converging on this point. > > > >> > >> > > > >> > > 4. Increase interval? > >> > > Draft suggest not to use POLL sequence and suggests to increase > >> > > multiplier first and then interval. If we have hardware > >> > > implementation and don't want to check complete packet every time > >> > > received then change in packet may be indicated with POLL bit set. > >> > > Since this is one to many mapping we can't have a complete POLL > >> > > sequence and hence we need to suppress FINAL. Should we be going > >> > > with POLL and suppress FINAL by setting desired RX interval set > >> > > to 0? Please suggest any better idea. > >> > > >> > [NOBO] If we keep the semi-reliable head notification, then I would > >> > have expected P/F (from head to tails) to just work? > >> > >> With semi-reliable head notification you want to have complete POLL > >> sequence for interval negotiation? One to many mapping will have > >> issues with complete POLL sequence. Can you elaborate how this will > help? > >> > >> > >> > > 5. bfd.ReportTailDown > >> > > Draft suggests that head direct tails to send down > >> > > notification. How will head direct tail about failure > >> > > notification to be sent or not? Is this driven by configuration? > >> > > At least the section > >> > > 4.4.1 says so. It could also be communicated to > >> > > received out of band? > >> > > > >> > > This should be out of scope of this document as we can't > >> > > direct tails with in BFD packet. Any comments? > >> > > >> > [NOBO] This is something which can be configured, thus out of scope > >> > [for now] should be fine. One reason that I have been pushing to > >> > keep > >> > semi- reliable head notification is that it can catch instances of > >> > odd cases like tails not having consistent configurations ... i.e, > >> > only some tails notify and some don't. Head doing the in-band > >> > polling can discover the available tails, becomes more of a fail-saf= e > mechanism. > >> > >> Agreed. It makes sense to have semi-reliable here. > >> > >> GIM>> I think that I disagree on this. Configuration can be verified > >> GIM>> by > >>other > >> means. I consider the base of multi-point BFD as mechanism suitable > >>for > >>1+1 > >> protection switchover. Any type of tail monitoring, IMO, is optional > >>and can be document of its own. > > > >Hmmm so this means we need converge on below options for tail > monitoring. > > > >1. Moving reliable notification option (A) moving to separate > >document/appendix. (Nobo's preference) 2. Moving unreliable, > >semi-reliable and reliable (C) to separate document/appendix. (Greg's > >preference) > > > > > >> > > 6. How packets get absorbed on tails? > >> > > Few implementers use UDP port number to absorb BFD packet on > tails. > >> > > It would be good to clarify about this in draft. Do we see any > >> > > other way of absorbing packet on tail? > >> > > >> > [NOBO] > >> > > >> > For IP: > >> > - UDP port. > >> > > >> > For MPLS: > >> > - 127/8 and UDP port. > >> > - UHP does not require bootstrapping but PHP will require > >>bootstrapping. > >> > >> GIM>> Why would bootstrapping be required for multi-point BFD session > >> GIM>> in > >> MPLS data plane with PHP if tail monitoring is not required? > > > >In case of PHP tail will not know which how to associate BFD received > >packet to an LSP as all BFD packets will come with 127/8 address. This > >is why we need boot strapping with MPLS LSP ping. There was a draft for > >the same long time ago. > > > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > > > >Thanks > >Santosh P K From nobody Sun Nov 23 22:31: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 5DD0F1A1BDE for ; Sun, 23 Nov 2014 22:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwxEVZ8xshLf for ; Sun, 23 Nov 2014 22:31:02 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7106F1A1BDD for ; Sun, 23 Nov 2014 22:31:02 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 24 Nov 2014 06:31:00 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Mon, 24 Nov 2014 06:31:00 +0000 From: Santosh P K To: Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAMINQ Date: Mon, 24 Nov 2014 06:31:00 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 040513D301 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(13464003)(35774003)(377454003)(189002)(51444003)(164054003)(99286002)(62966003)(95666004)(86362001)(105586002)(106116001)(120916001)(99396003)(21056001)(40100003)(87936001)(77156002)(2656002)(107046002)(107886001)(122556002)(106356001)(101416001)(4396001)(92566001)(230783001)(66066001)(76176999)(54356999)(33646002)(50986999)(76576001)(19580395003)(19580405001)(93886004)(15975445006)(46102003)(74316001)(108616004)(97736003)(20776003)(15202345003)(31966008)(64706001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/P-JiaF3rkTn7uPD6yGv_yh7ezCA 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, 24 Nov 2014 06:31:05 -0000 Mingui, Thanks for your comments. Thanks Santosh P K=20 > -----Original Message----- > From: Mingui Zhang [mailto:zhangmingui@huawei.com] > Sent: Monday, November 24, 2014 9:07 AM > To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim > (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hi Santosh, >=20 > > >Ok so I think we are making progress on this. I understand that we need > >to do below. > > > >Keep base document with IP demux and MPLS demux. For any other > (TRILLS, > >MPLS ACH) demux required come up with a new draft. > >=20 > I think this is reasonable. >=20 > Thanks, > Mingui >=20 > >-----Original Message----- > >From: Santosh P K [mailto:santoshpk@juniper.net] > >Sent: Sunday, November 23, 2014 1:30 PM > >To: Gregory Mirsky; 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 > > > >Hello Greg, > > Thanks a lot of your comments. Please see inline. > > > >> > > 1.=A0=A0=A0=A0=A0=A0 Active tail. > >> > > As discussed earlier, is this required in base draft? I > >> > > spoke to all implementers =A0and no one has active tail implemente= d > >> > > yet. To push it for RFC we need implementation so can we go ahead > >> > > and move it to appendix or may be new document? > >> > > > >> > > WH> I would propose we do the active tail in appendix or a > >> > > WH> separate draft > >> > > >> > [NOBO] Wim, can you clarify which you mean? > >> > > >> > A) You propose reliable head notification to be moved. > >> > B) You propose semi-reliable and reliable head notifications to be > moved. > >> > C) You propose unreliable, semi-reliable and reliable head > >> > notifications to be moved. > >> > > >> > You can find the description of each notifications in page 4 of > >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > >> > > >> > My preference will be (A). > >> > > >> Moving reliable head notification to appendix or new document you > >> mean :) ? > >> GIM>> My preference - C into the separate draft. And all related > >> GIM>> updates of > >> state machine and new variables - go with it. > > > >Ok so we have > > > >1. Moving reliable notification option (A) moving to separate > document/appendix. > >(Nobo's preference) > >2. Moving unreliable, semi-reliable and reliable (C) to separate > >document/appendix. (Greg's preference) > > > >Wim you have any preference on this? > > > > > > > >> > >> > > > >> > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > >> > > It makes more sense to have a separate draft for this. > >> > > Please let me know if that is ok? If it benefits to have it in > >> > > base draft itself then we can have more sections for demux and > >> > > port number to be > >> > used. > >> > > > >> > > WH> it should be in the draft I believe > >> > > >> > [NOBO] So ... > >> > > >> > Option 1 is to describe the demux codepoint & procedures in the > >> > bfd- multipoint document. > >> > Option 2 is to describe the demux codepoint & procedures in > >> > separate data plane document(s). > >> > > >> > It sounds like Santosh is preferring Option 2 while Wim is > >> > preferring option > >> 1. > >> > > >> > Perhaps there's an Option 3. > >> > > >> > The bfd-multipoint document to describe one or two basic data plane > >> > demux codepoint & procedures cleanly in a separate section (ex: IP > >> > and > >> MPLS). > >> > Other data planes documents (ex: TRILL) can update the demux > >> > section of the bfd-multipoint document. Just thinking out loud ... > >> > > >> > >> Currently in document it tries to explain how to demux for IP only in > >> section 4.8. We can add more text for clarity. > >> I am ok with option 1 where all procedure dumped in single document > >> but I am worried that in future some other data plane wants a new way > >> of demultiplexing then we may need to change the base document > again? > >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS > >> ACH, would have to write documents of their own. > > > >Ok so I think we are making progress on this. I understand that we need > >to do below. > > > >Keep base document with IP demux and MPLS demux. For any other > (TRILLS, > >MPLS ACH) demux required come up with a new draft. > > > > > >> > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > >> > > Echo mode does not fit in P2MP BFD. We can say it is not > >supported. > >> > > Does anyone see use of echo BFD in P2MP BFD? > >> > > > >> > > WH> I don't see a use case for this so far > >> > > >> > [NOBO] Agree, I see no value in the multipoint document considering > >> > the echo inside the scope. > >> > >> Thanks. > >> GIM>> Agree, no echo mode. > > > >Thanks. We are converging on this point. > > > >> > >> > > > >> > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > >> > > Draft suggest not to use POLL sequence and suggests to increase > >> > > multiplier first and then interval. If we have hardware > >> > > implementation and don't want to check complete packet every time > >> > > received then change in packet may be indicated with POLL bit set. > >> > > Since this is one to many mapping we can't have a complete POLL > >> > > sequence and hence we need to suppress FINAL. Should we be going > >> > > with POLL and suppress FINAL by setting desired RX interval set > >> > > to 0? Please suggest any better idea. > >> > > >> > [NOBO] If we keep the semi-reliable head notification, then I would > >> > have expected P/F (from head to tails) to just work? > >> > >> With semi-reliable head notification you want to have complete POLL > >> sequence for interval negotiation? One to many mapping will have > >> issues with complete POLL sequence. Can you elaborate how this will > help? > >> > >> > >> > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > >> > > Draft suggests that head direct tails to send down > >> > > notification. How will head direct tail about failure > >> > > notification to be sent or not? Is this driven by configuration? > >> > > At least the section > >> > > 4.4.1 says so. It could also be communicated to > >> > > received out of band? > >> > > > >> > > This should be out of scope of this document as we can't > >> > > direct tails with in BFD packet. Any comments? > >> > > >> > [NOBO] This is something which can be configured, thus out of scope > >> > [for now] should be fine. One reason that I have been pushing to > >> > keep > >> > semi- reliable head notification is that it can catch instances of > >> > odd cases like tails not having consistent configurations ... i.e, > >> > only some tails notify and some don't. Head doing the in-band > >> > polling can discover the available tails, becomes more of a fail-saf= e > mechanism. > >> > >> Agreed. It makes sense to have semi-reliable here. > >> > >> GIM>> I think that I disagree on this. Configuration can be verified > >> GIM>> by other > >> means. I consider the base of multi-point BFD as mechanism suitable > >> for 1+1 protection switchover. Any type of tail monitoring, IMO, is > >> optional and can be document of its own. > > > >Hmmm so this means we need converge on below options for tail > monitoring. > > > >1. Moving reliable notification option (A) moving to separate > document/appendix. > >(Nobo's preference) > >2. Moving unreliable, semi-reliable and reliable (C) to separate > >document/appendix. (Greg's preference) > > > > > >> > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > >> > > Few implementers use UDP port number to absorb BFD packet on > tails. > >> > > It would be good to clarify about this in draft. Do we see any > >> > > other way of absorbing packet on tail? > >> > > >> > [NOBO] > >> > > >> > For IP: > >> > - UDP port. > >> > > >> > For MPLS: > >> > - 127/8 and UDP port. > >> > - UHP does not require bootstrapping but PHP will require > bootstrapping. > >> > >> GIM>> Why would bootstrapping be required for multi-point BFD session > >> GIM>> in > >> MPLS data plane with PHP if tail monitoring is not required? > > > >In case of PHP tail will not know which how to associate BFD received > >packet to an LSP as all BFD packets will come with 127/8 address. This > >is why we need boot strapping with MPLS LSP ping. There was a draft for > >the same long time ago. > > > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > > > >Thanks > >Santosh P K From nobody Mon Nov 24 02:05: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 BD4791A1F02 for ; Mon, 24 Nov 2014 02:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw9zWwueI8tR for ; Mon, 24 Nov 2014 02:04:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD03A1A1F01 for ; Mon, 24 Nov 2014 02:04:58 -0800 (PST) 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 BLY93799; Mon, 24 Nov 2014 10:04:56 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Nov 2014 10:04:55 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Mon, 24 Nov 2014 18:03:16 +0800 From: Mach Chen To: "Nobo Akiya (nobo)" , Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACKSGkAAMCf94AADX0MAABVlhIAAFUnQHA= Date: Mon, 24 Nov 2014 10:03:15 +0000 Message-ID: References: <20141116220332392193.5ed69d25@sniff.de> <20141121002512713064.799b449a@sniff.de> 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.97.72] 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/g6aaVOUHNknXwDXiTpWfZWXCkWE 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, 24 Nov 2014 10:05:04 -0000 Hi Nobo and Marc, I totally agree with the proposal to keep the extended use-cases and the al= ert discriminator mechanism in draft-akiya-bfd-seamless-alert-discrim. Best regards, Mach > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya (= nobo) > Sent: Sunday, November 23, 2014 9:16 AM > To: Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hello BFD WG, >=20 > Marc and I had some conversation on the topic of S-BFD alert discriminato= r > document structure, and converged on a direction. >=20 > - We think that it is useful to describe both the problems and the soluti= on for the > S-BFD alert discrimintor in a single document. > - We also think the S-BFD alert discriminator is more like an exception m= echanism, > thus the mechanism should remain outside of the S-BFD base document. >=20 > Therefore, our converged recommendation to the WG is to keep the extended > use-cases and the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. >=20 > This also means that no further changes are needed in > draft-ietf-bfd-seamless-use-case, and the draft-ietf-bfd-seamless-use-cas= e can > progressed forward if authors feel that it is ready. >=20 > We would appreciate it if folks can chime in and state whether or not thi= s is an > acceptable way forward. >=20 > Thanks! >=20 > -Nobo & Marc >=20 > > -----Original Message----- > > From: Marc Binderberger [mailto:marc@sniff.de] > > Sent: Friday, November 21, 2014 3:25 AM > > To: Nobo Akiya (nobo) > > Cc: rtg-bfd@ietf.org > > Subject: RE: Seeking opinions on > > draft-akiya-bfd-seamless-alert-discrim > > > > Hello Nobo, > > > > (back from Hawaii or writing emails at the beach? ;-) > > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > yes, exactly. > > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the > draft-akiya-bfd-seamless-alert-discrim? > > > > > > That's probably where our different views come from :-) I would aim to > > simplify the main idea of the draft so it _can_ easily be implemented > > even in hardware. > > > > For the traceroute - my guess is TTL punts (if that mechanism to > > "deliver" is > > used) happen in software as many mechanism use this "trick" but if a > > hardware can handle TTL punts, it can handle the diag code as well. I > > don't see the document needs to adjust for the traceroute case. > > > > For a basic reflector task, having a zero discriminator as a default > > reflector discriminator would allow for very simple implementations > > (we discussed a while ago a fixed discriminator value for simple > > broadband modems, remember?). > > For more complex equipment and scenarios, keeping it in hardware > > instead of a software punt would maintain the ability of S-BFD to go up= very > quickly. > > > > > > I tend to not see the zero discriminator as such a big exception, > > which may explain my idea to integrate it into the base document. And > > to keep it compatible to hardware implementations. > > Assuming you want to add more "special effects" in the future I can > > see why you have an extra document. I would propose to keep the > > zero-reflector mentally aligned :-) with the base document and > > accordingly designed to allow implementations to cover the zero-reflect= or > together with "normal" > > S-BFD > > (read: may be in hardware). > > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. > > > > Good - makes life simpler :-) > > > > > > Regards, Marc > > > > > > On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > > > Hi Marc, > > > > > > Thanks for providing your view. > > > > > > Please see in-line. > > > > > >> -----Original Message----- > > >> From: Marc Binderberger [mailto:marc@sniff.de] > > >> Sent: Monday, November 17, 2014 1:04 AM > > >> To: Nobo Akiya (nobo) > > >> Cc: rtg-bfd@ietf.org > > >> Subject: Re: Seeking opinions on > > >> draft-akiya-bfd-seamless-alert-discrim > > >> > > >> Hello Nobo and BFD experts, > > >> > > >> giving this document a closer look for the first time (ahem ;-) I > > >> have a slightly different view. > > >> > > >> Having S-BFD use cases for the general S-BFD in an extra document > > >> does improve the overall discussion and documentation, simply > > >> because the base S-BFD is already complex enough, as are the use cas= es. > > >> > > >> But for such a relatively small document splitting off the reason > > >> why the document exists is not improving the reading/understanding > > >> of this > > draft. > > >> Unless you decide to integrate the alert-discriminator document > > >> into the base document, then obviously you use the use-case document= . > > > > > > Your view is then: > > > > > > Instead of: > > > > > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > > > keep the alert discriminator mechanism in the > > > draft-akiya-bfd-seamless-alert-discrim. > > > > > > Do: > > > > > > (2) Keep the extended use-cases and alert discriminator mechanism in > > > the draft-akiya-bfd-seamless-alert-discrim. > > > > > > Or > > > > > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > > > and move the alert discriminator mechanism to > > > draft-ietf-bfd-seamless- > > base. > > > > > > My thought was that (1) makes sense, but your view that (1) makes > > > all the S-BFD documents set more complex to understand is a valid > > > concern (it's always good to get fresh eyes on documents!). > > > > > >> > > >> > > >> For the integration of the technical aspect into the base document, > > >> I think this is an idea worth to discuss. At the end what you need > > >> is to add the rule for the zero discriminator to the reflector > > >> behaviour; we managed this for standard BFD, we should be able to > > >> do this for the reflector BFD as well > > >> :-) > > > > > > Whether the S-BFD packets with alert discriminator are handled in HW > > > or SW is an implementation choice. Similar to how IP router alert > > > option & router alert label are handled, I do see handling of S-BFD > > > packets with alert discriminator in the SW to be a reasonable > > > approach, in which case the HW instruction for S-BFD packets with > > > alert discriminator is to punt to SW for processing. > > > > > >> For the diagnostic codes I'm not sure; it will complicate hardware > > >> implementations (probably not a no-go problem though) and seems > > >> otherwise not add a real value IMHO. > > > > > > If one really wants to handle them in the HW, that's a possibility. > > > Although as you stated, it does complicate HW implementations and > > > this is another reason for SW based implementations. > > > > > >> > > >> So if there are already at this stage of S-BFD use case(s) for > > >> zero- discriminator to bring up (some) sessions then I would > > >> propose to consider the integration into the base document. This > > >> will also guarantee that the zero-discriminator handling is as fast > > >> as the "normal" reflection and is not on a slower exception path. > > > > > > Personally, I tend to recommend that alert discriminators are > > > handled in the SW. Let's assume that you agree on this > > > (hypothetically). In that case, would you still recommend the alert > > > discriminator mechanism to be moved to the > > > draft-ietf-bfd-seamless-base or is it reasonable to keep it in the > draft-akiya-bfd-seamless-alert-discrim? > > > > > >> > > >> > > >> > > >> I have a question: so far S-BFD packets would be received, not > > >> "picked out of the data stream". Receiving could be because the > > >> destination IP would match or would be 127/8, the TTL would be zero > > >> and so on. In the security section you say ... > > >> > > >> Conceptually the Alert Discriminator is similar to an IP Router A= lert > > >> Option or an MPLS Router Alert Label. > > >> > > >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to > > >> the > > >> reflector) with an alert-discriminator out of the data stream that > > >> otherwise would just pass this node? > > >> I guess you don't want but I want to make sure I understand it corre= ctly. > > > > > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > > > S-BFD packets with alert discriminator. So the statement regarding > > > "Conceptually the Alert Discriminator is similar to an IP Router > > > Alert Option or an MPLS Router Alert Label" should be re-stated and c= larified. > > > > > > Thanks! > > > > > > -Nobo > > > > > >> > > >> > > >> Regards, Marc > > >> > > >> > > >> > > >> > > >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: > > >>> [Speaking as an individual S-BFD contributor] > > >>> > > >>> Hi BFD WG, > > >>> > > >>> There were couple of questions I need your input on > > >>> draft-akiya-bfd-seamless-alert-discrim. > > >>> > > >>> > > >>> (1) Should the "extended" S-BFD use cases move to > > >>> draft-ietf-bfd-seamless-use-case? > > >>> > > >>> My opinion is yes. Once the "extended" S-BFD use cases have been > > >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should > > >>> try to move draft-ietf-bfd-seamless-use-case forward. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> (2) Should the alert discriminator proposal move to > > >>> draft-ietf-bfd-seamless-base? > > >>> > > >>> My opinion is no . Instead we should position this as an optional > > >>> feature of S-BFD (hence separate document than the base), > > >>> especially considering we likely need to think through additional > > >>> security concerns > > >> raised by this. > > >>> > > >>> A question was raised by Greg on how does a node find out if the > > >>> target supports the optional alert discriminator or not. We can > > >>> define a mandatory diagnostic value that must be implemented when > > >>> the alert discriminator is implemented. One can send an S-BFD > > >>> control packet with the alert discriminator with this diagnostic > > >>> value to check if the target supports the alert discriminator mecha= nism. > > >>> > > >>> How does the WG feel about this? > > >>> > > >>> > > >>> Thanks! > > >>> > > >>> -Nobo > > >>> > > > From nobody Mon Nov 24 02:18: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 295001A1EFC for ; Mon, 24 Nov 2014 02:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbL7zrJ6vBXG for ; Mon, 24 Nov 2014 02:18:54 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958141A1E0C for ; Mon, 24 Nov 2014 02:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8501; q=dns/txt; s=iport; t=1416824334; x=1418033934; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=vYooFwDyUmSfdJ0dzsi6woJYiMVQP8H7P028lihEdBE=; b=nIhHakwYQMOqSgke4MD13s7YZfcVyt+wEY7IPH4epG8u4V+MVhha/Kay 8yLEHfg3FqfCPfJEHmJLd2s7JZ/kD/jxO/2ejn+MbhIg2hsGVWKOETd7R Om20Q2Te7QXuDltiE3ffCG3U4NvwMvaOLDBO4WPYLmMjo4Q1hAvdfiV7g 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFADQFc1StJA2K/2dsb2JhbABbgw5VWQTIXYI5hmoCgSAWAQEBAQF9hAIBAQEEgQUEAgEIEQQBAQsdBzIUCQgCBAESCAGIOA3OKAEBAQEBAQEBAQEBAQEBAQEBAQEZkFo4BoMpgR8Fi2mEUYIuhGWIaD+DGopHgzyECoN9eAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,448,1413244800"; d="scan'208";a="99515837" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 24 Nov 2014 10:18:53 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAOAIrkA012561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 10:18:53 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 04:18:53 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Mingui Zhang , Santosh P K , Gregory Mirsky , "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: AQHPu0hU1nryP7dQOU2cGGfuY/WCWpvYS1kAgEtadQCAAAnegIAE26WAgAA3/wCAAIDAgIAAy7EAgAYPawCAALvkgIAFsnwAgAU+f4CALo2NAIABnSoAgAJ5AYCAAAqHgIAAJV+AgAALRACAAXLjgIAAC2AQ Date: Mon, 24 Nov 2014 10:18:52 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.50] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/tMiEHpo_vGluYYjC7u7f2YKHw7I 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, 24 Nov 2014 10:18:57 -0000 Hello Santosh, I agree that option (C) is a reasonable approach to carry forward the P2= MP document. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mingui Zhang Sent: Monday, November 24, 2014 9:07 AM To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim (Wim); = Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hi Santosh, >Ok so I think we are making progress on this. I understand that we need=20 >to do below. > >Keep base document with IP demux and MPLS demux. For any other (TRILLS,=20 >MPLS ACH) demux required come up with a new draft. I think this is reasonable. Thanks, Mingui >-----Original Message----- >From: Santosh P K [mailto:santoshpk@juniper.net] >Sent: Sunday, November 23, 2014 1:30 PM >To: Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim (Wim); Jeffrey=20 >Haas; rtg-bfd@ietf.org; Mingui Zhang >Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > >Hello Greg, > Thanks a lot of your comments. Please see inline. > >> > > 1.=A0=A0=A0=A0=A0=A0 Active tail. >> > > As discussed earlier, is this required in base draft? I=20 >> > > spoke to all implementers =A0and no one has active tail implemented= =20 >> > > yet. To push it for RFC we need implementation so can we go ahead=20 >> > > and move it to appendix or may be new document? >> > > >> > > WH> I would propose we do the active tail in appendix or a=20 >> > > WH> separate draft >> > >> > [NOBO] Wim, can you clarify which you mean? >> > >> > A) You propose reliable head notification to be moved. >> > B) You propose semi-reliable and reliable head notifications to be mov= ed. >> > C) You propose unreliable, semi-reliable and reliable head=20 >> > notifications to be moved. >> > >> > You can find the description of each notifications in page 4 of=20 >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. >> > >> > My preference will be (A). >> > >> Moving reliable head notification to appendix or new document you=20 >> mean :) ? >> GIM>> My preference - C into the separate draft. And all related=20 >> GIM>> updates of >> state machine and new variables - go with it. > >Ok so we have > >1. Moving reliable notification option (A) moving to separate document/app= endix. >(Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate=20 >document/appendix. (Greg's preference) > >Wim you have any preference on this? > > > >> >> > > >> > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. >> > > It makes more sense to have a separate draft for this.=20 >> > > Please let me know if that is ok? If it benefits to have it in=20 >> > > base draft itself then we can have more sections for demux and=20 >> > > port number to be >> > used. >> > > >> > > WH> it should be in the draft I believe >> > >> > [NOBO] So ... >> > >> > Option 1 is to describe the demux codepoint & procedures in the=20 >> > bfd- multipoint document. >> > Option 2 is to describe the demux codepoint & procedures in=20 >> > separate data plane document(s). >> > >> > It sounds like Santosh is preferring Option 2 while Wim is=20 >> > preferring option >> 1. >> > >> > Perhaps there's an Option 3. >> > >> > The bfd-multipoint document to describe one or two basic data plane=20 >> > demux codepoint & procedures cleanly in a separate section (ex: IP=20 >> > and >> MPLS). >> > Other data planes documents (ex: TRILL) can update the demux=20 >> > section of the bfd-multipoint document. Just thinking out loud ... >> > >> >> Currently in document it tries to explain how to demux for IP only in=20 >> section 4.8. We can add more text for clarity. >> I am ok with option 1 where all procedure dumped in single document=20 >> but I am worried that in future some other data plane wants a new way=20 >> of demultiplexing then we may need to change the base document again? >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS >> ACH, would have to write documents of their own. > >Ok so I think we are making progress on this. I understand that we need=20 >to do below. > >Keep base document with IP demux and MPLS demux. For any other (TRILLS,=20 >MPLS ACH) demux required come up with a new draft. > > >> > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? >> > > Echo mode does not fit in P2MP BFD. We can say it is not >supported. >> > > Does anyone see use of echo BFD in P2MP BFD? >> > > >> > > WH> I don't see a use case for this so far >> > >> > [NOBO] Agree, I see no value in the multipoint document considering=20 >> > the echo inside the scope. >> >> Thanks. >> GIM>> Agree, no echo mode. > >Thanks. We are converging on this point. > >> >> > > >> > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? >> > > Draft suggest not to use POLL sequence and suggests to increase=20 >> > > multiplier first and then interval. If we have hardware=20 >> > > implementation and don't want to check complete packet every time=20 >> > > received then change in packet may be indicated with POLL bit set. >> > > Since this is one to many mapping we can't have a complete POLL=20 >> > > sequence and hence we need to suppress FINAL. Should we be going=20 >> > > with POLL and suppress FINAL by setting desired RX interval set=20 >> > > to 0? Please suggest any better idea. >> > >> > [NOBO] If we keep the semi-reliable head notification, then I would=20 >> > have expected P/F (from head to tails) to just work? >> >> With semi-reliable head notification you want to have complete POLL=20 >> sequence for interval negotiation? One to many mapping will have=20 >> issues with complete POLL sequence. Can you elaborate how this will help= ? >> >> >> > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown >> > > Draft suggests that head direct tails to send down=20 >> > > notification. How will head direct tail about failure=20 >> > > notification to be sent or not? Is this driven by configuration?=20 >> > > At least the section >> > > 4.4.1 says so. It could also be communicated to >> > > received out of band? >> > > >> > > This should be out of scope of this document as we can't=20 >> > > direct tails with in BFD packet. Any comments? >> > >> > [NOBO] This is something which can be configured, thus out of scope=20 >> > [for now] should be fine. One reason that I have been pushing to=20 >> > keep >> > semi- reliable head notification is that it can catch instances of=20 >> > odd cases like tails not having consistent configurations ... i.e,=20 >> > only some tails notify and some don't. Head doing the in-band=20 >> > polling can discover the available tails, becomes more of a fail-safe = mechanism. >> >> Agreed. It makes sense to have semi-reliable here. >> >> GIM>> I think that I disagree on this. Configuration can be verified=20 >> GIM>> by other >> means. I consider the base of multi-point BFD as mechanism suitable=20 >> for 1+1 protection switchover. Any type of tail monitoring, IMO, is=20 >> optional and can be document of its own. > >Hmmm so this means we need converge on below options for tail monitoring. > >1. Moving reliable notification option (A) moving to separate document/app= endix. >(Nobo's preference) >2. Moving unreliable, semi-reliable and reliable (C) to separate=20 >document/appendix. (Greg's preference) > > >> > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? >> > > Few implementers use UDP port number to absorb BFD packet on tails. >> > > It would be good to clarify about this in draft. Do we see any=20 >> > > other way of absorbing packet on tail? >> > >> > [NOBO] >> > >> > For IP: >> > - UDP port. >> > >> > For MPLS: >> > - 127/8 and UDP port. >> > - UHP does not require bootstrapping but PHP will require bootstrappin= g. >> >> GIM>> Why would bootstrapping be required for multi-point BFD session=20 >> GIM>> in >> MPLS data plane with PHP if tail monitoring is not required? > >In case of PHP tail will not know which how to associate BFD received=20 >packet to an LSP as all BFD packets will come with 127/8 address. This=20 >is why we need boot strapping with MPLS LSP ping. There was a draft for=20 >the same long time ago. > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > >Thanks >Santosh P K From nobody Mon Nov 24 03:37:38 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 B72A21A1F02 for ; Mon, 24 Nov 2014 03:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt0gnr2o_gSM for ; Mon, 24 Nov 2014 03:37:33 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F7B1A3BA2 for ; Mon, 24 Nov 2014 03:37:32 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Mon, 24 Nov 2014 11:37:08 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Mon, 24 Nov 2014 11:37:08 +0000 From: Santosh P K To: "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUA= Date: Mon, 24 Nov 2014 11:37:08 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 040513D301 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(35774003)(164054003)(377454003)(13464003)(120916001)(95666004)(105586002)(99396003)(50986999)(107046002)(108616004)(62966003)(77156002)(93886004)(106116001)(230783001)(107886001)(99286002)(101416001)(74316001)(122556002)(64706001)(20776003)(92566001)(76576001)(66066001)(21056001)(86362001)(54356999)(106356001)(15975445006)(40100003)(4396001)(33646002)(46102003)(19580395003)(19580405001)(76176999)(31966008)(97736003)(15202345003)(87936001)(2656002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/hy0a_O7kklKadNeDxRL1Evk93DU 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, 24 Nov 2014 11:37:36 -0000 Thanks Prasad.=20 > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) [mailto:venggovi@cisco.com] > Sent: Monday, November 24, 2014 3:49 PM > To: Mingui Zhang; Santosh P K; Gregory Mirsky; 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 Santosh, > I agree that option (C) is a reasonable approach to carry forward the = P2MP > document. > Thanks > Prasad >=20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mingui Zhang > Sent: Monday, November 24, 2014 9:07 AM > To: Santosh P K; Gregory Mirsky; Nobo Akiya (nobo); Henderickx, Wim > (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hi Santosh, >=20 > > >Ok so I think we are making progress on this. I understand that we need > >to do below. > > > >Keep base document with IP demux and MPLS demux. For any other > (TRILLS, > >MPLS ACH) demux required come up with a new draft. > >=20 > I think this is reasonable. >=20 > Thanks, > Mingui >=20 > >-----Original Message----- > >From: Santosh P K [mailto:santoshpk@juniper.net] > >Sent: Sunday, November 23, 2014 1:30 PM > >To: Gregory Mirsky; 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 > > > >Hello Greg, > > Thanks a lot of your comments. Please see inline. > > > >> > > 1.=A0=A0=A0=A0=A0=A0 Active tail. > >> > > As discussed earlier, is this required in base draft? I > >> > > spoke to all implementers =A0and no one has active tail implemente= d > >> > > yet. To push it for RFC we need implementation so can we go ahead > >> > > and move it to appendix or may be new document? > >> > > > >> > > WH> I would propose we do the active tail in appendix or a > >> > > WH> separate draft > >> > > >> > [NOBO] Wim, can you clarify which you mean? > >> > > >> > A) You propose reliable head notification to be moved. > >> > B) You propose semi-reliable and reliable head notifications to be > moved. > >> > C) You propose unreliable, semi-reliable and reliable head > >> > notifications to be moved. > >> > > >> > You can find the description of each notifications in page 4 of > >> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-0.pptx. > >> > > >> > My preference will be (A). > >> > > >> Moving reliable head notification to appendix or new document you > >> mean :) ? > >> GIM>> My preference - C into the separate draft. And all related > >> GIM>> updates of > >> state machine and new variables - go with it. > > > >Ok so we have > > > >1. Moving reliable notification option (A) moving to separate > document/appendix. > >(Nobo's preference) > >2. Moving unreliable, semi-reliable and reliable (C) to separate > >document/appendix. (Greg's preference) > > > >Wim you have any preference on this? > > > > > > > >> > >> > > > >> > > 2.=A0=A0=A0=A0=A0=A0 Demultiplexing and UDP port number. > >> > > It makes more sense to have a separate draft for this. > >> > > Please let me know if that is ok? If it benefits to have it in > >> > > base draft itself then we can have more sections for demux and > >> > > port number to be > >> > used. > >> > > > >> > > WH> it should be in the draft I believe > >> > > >> > [NOBO] So ... > >> > > >> > Option 1 is to describe the demux codepoint & procedures in the > >> > bfd- multipoint document. > >> > Option 2 is to describe the demux codepoint & procedures in > >> > separate data plane document(s). > >> > > >> > It sounds like Santosh is preferring Option 2 while Wim is > >> > preferring option > >> 1. > >> > > >> > Perhaps there's an Option 3. > >> > > >> > The bfd-multipoint document to describe one or two basic data plane > >> > demux codepoint & procedures cleanly in a separate section (ex: IP > >> > and > >> MPLS). > >> > Other data planes documents (ex: TRILL) can update the demux > >> > section of the bfd-multipoint document. Just thinking out loud ... > >> > > >> > >> Currently in document it tries to explain how to demux for IP only in > >> section 4.8. We can add more text for clarity. > >> I am ok with option 1 where all procedure dumped in single document > >> but I am worried that in future some other data plane wants a new way > >> of demultiplexing then we may need to change the base document > again? > >> GIM>> Option 1 does make sense to me. Other encapsulations, e.g. MPLS > >> ACH, would have to write documents of their own. > > > >Ok so I think we are making progress on this. I understand that we need > >to do below. > > > >Keep base document with IP demux and MPLS demux. For any other > (TRILLS, > >MPLS ACH) demux required come up with a new draft. > > > > > >> > > 3.=A0=A0=A0=A0=A0=A0 Echo mode supported? > >> > > Echo mode does not fit in P2MP BFD. We can say it is not > >supported. > >> > > Does anyone see use of echo BFD in P2MP BFD? > >> > > > >> > > WH> I don't see a use case for this so far > >> > > >> > [NOBO] Agree, I see no value in the multipoint document considering > >> > the echo inside the scope. > >> > >> Thanks. > >> GIM>> Agree, no echo mode. > > > >Thanks. We are converging on this point. > > > >> > >> > > > >> > > 4.=A0=A0=A0=A0=A0=A0 Increase interval? > >> > > Draft suggest not to use POLL sequence and suggests to increase > >> > > multiplier first and then interval. If we have hardware > >> > > implementation and don't want to check complete packet every time > >> > > received then change in packet may be indicated with POLL bit set. > >> > > Since this is one to many mapping we can't have a complete POLL > >> > > sequence and hence we need to suppress FINAL. Should we be going > >> > > with POLL and suppress FINAL by setting desired RX interval set > >> > > to 0? Please suggest any better idea. > >> > > >> > [NOBO] If we keep the semi-reliable head notification, then I would > >> > have expected P/F (from head to tails) to just work? > >> > >> With semi-reliable head notification you want to have complete POLL > >> sequence for interval negotiation? One to many mapping will have > >> issues with complete POLL sequence. Can you elaborate how this will > help? > >> > >> > >> > > 5.=A0=A0=A0=A0=A0=A0 bfd.ReportTailDown > >> > > Draft suggests that head direct tails to send down > >> > > notification. How will head direct tail about failure > >> > > notification to be sent or not? Is this driven by configuration? > >> > > At least the section > >> > > 4.4.1 says so. It could also be communicated to > >> > > received out of band? > >> > > > >> > > This should be out of scope of this document as we can't > >> > > direct tails with in BFD packet. Any comments? > >> > > >> > [NOBO] This is something which can be configured, thus out of scope > >> > [for now] should be fine. One reason that I have been pushing to > >> > keep > >> > semi- reliable head notification is that it can catch instances of > >> > odd cases like tails not having consistent configurations ... i.e, > >> > only some tails notify and some don't. Head doing the in-band > >> > polling can discover the available tails, becomes more of a fail-saf= e > mechanism. > >> > >> Agreed. It makes sense to have semi-reliable here. > >> > >> GIM>> I think that I disagree on this. Configuration can be verified > >> GIM>> by other > >> means. I consider the base of multi-point BFD as mechanism suitable > >> for 1+1 protection switchover. Any type of tail monitoring, IMO, is > >> optional and can be document of its own. > > > >Hmmm so this means we need converge on below options for tail > monitoring. > > > >1. Moving reliable notification option (A) moving to separate > document/appendix. > >(Nobo's preference) > >2. Moving unreliable, semi-reliable and reliable (C) to separate > >document/appendix. (Greg's preference) > > > > > >> > > 6.=A0=A0=A0=A0=A0=A0 How packets get absorbed on tails? > >> > > Few implementers use UDP port number to absorb BFD packet on > tails. > >> > > It would be good to clarify about this in draft. Do we see any > >> > > other way of absorbing packet on tail? > >> > > >> > [NOBO] > >> > > >> > For IP: > >> > - UDP port. > >> > > >> > For MPLS: > >> > - 127/8 and UDP port. > >> > - UHP does not require bootstrapping but PHP will require > bootstrapping. > >> > >> GIM>> Why would bootstrapping be required for multi-point BFD session > >> GIM>> in > >> MPLS data plane with PHP if tail monitoring is not required? > > > >In case of PHP tail will not know which how to associate BFD received > >packet to an LSP as all BFD packets will come with 127/8 address. This > >is why we need boot strapping with MPLS LSP ping. There was a draft for > >the same long time ago. > > > >http://tools.ietf.org/html/draft-hc-mpls-mpoint-bfd-for-mpls-00 > > > >Thanks > >Santosh P K From nobody Mon Nov 24 05:57: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 9B2171A6F7F for ; Mon, 24 Nov 2014 05:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.51 X-Spam-Level: X-Spam-Status: No, score=-114.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0BgA8L-KuC3 for ; Mon, 24 Nov 2014 05:55:59 -0800 (PST) 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 811141A6F7D for ; Mon, 24 Nov 2014 05:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76708; q=dns/txt; s=iport; t=1416837359; x=1418046959; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rzjszRgqsW3m2u1WS9YF6ewBWxdFszeBzvDo5qGgq8U=; b=dwbsoZS8WJWPfOwH/8wIQNvKLLc4nFW8rq3Upt4W8VUtBKiHZH5ycmnR BFKTL1ikHBgSlsCevljk0401/AlPeqMFmmPXhZqVKsJWvuTrH8Uhh8PSy s63O5rAc4txTe5qXLrwR2mGpHlJXNQQGVm0PydXtWh+P8igx0xjumKbqs Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFANc3c1StJA2G/2dsb2JhbABbgkgjI1VZBNF/AoEdFgEBAQEBfYQCAQEBAwEaEz4JBQUHBAIBCBEDAQEBAQoWAQYHMhQJAwUCBAENBQgRAogdCQHPCwEBAQEBAQEBAQEBAQEBAQEBAQEBAReQWiARBgEGgymBHwWQOoIujU2DWYM4ikuECoN9eIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,449,1413244800"; d="scan'208,217";a="374812766" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 24 Nov 2014 13:55:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAODtpVP016694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 13:55:52 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; Mon, 24 Nov 2014 07:55:51 -0600 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , Marc Binderberger Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAAAB0lM4A== Date: Mon, 24 Nov 2014 13:55:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.228] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3943F5A1776xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/cDMhF3bBhTLtefDsTd9VZuhg59E X-Mailman-Approved-At: Mon, 24 Nov 2014 05:57:42 -0800 Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 13:56:06 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3943F5A1776xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for chiming in Manav, Mallik, Mach! Mallik, please see one comment in-line. From: MALLIK MUDIGONDA (mmudigon) Sent: Monday, November 24, 2014 12:49 AM To: Nobo Akiya (nobo); Marc Binderberger Cc: rtg-bfd@ietf.org Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hi Nobo, Agree that the Alert Discriminator must be described in a separate document= . Since the SBFD use case document is listing out all the use cases of SBFD= don't you think we should at least mention the alert discriminator functi= on as on of the use cases and place a reference to the alert discriminator = document in the use cases. [NOBO] Normally: 1. Use case document exists. 2. Solution document exists and references the use case documents. 3. Extension document exists and references the solution document (and= possibly the use case document). So the S-BFD use case document referencing the alert discriminator document= will be backwards IMO. I think it is reasonable to not make any updates to= the S-BFD use case document, wrt mentioning of the alert discriminator use= -cases/problems since those will be described in the alert discriminator do= cument. Thanks! -Nobo Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Sunday, 23 November 2014 6:45 am To: Marc Binderberger > Cc: "rtg-bfd@ietf.org" > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hello BFD WG, Marc and I had some conversation on the topic of S-BFD alert discriminator = document structure, and converged on a direction. - We think that it is useful to describe both the problems and the solution= for the S-BFD alert discrimintor in a single document. - We also think the S-BFD alert discriminator is more like an exception mec= hanism, thus the mechanism should remain outside of the S-BFD base document= . Therefore, our converged recommendation to the WG is to keep the extended u= se-cases and the alert discriminator mechanism in the draft-akiya-bfd-seaml= ess-alert-discrim. This also means that no further changes are needed in draft-ietf-bfd-seamle= ss-use-case, and the draft-ietf-bfd-seamless-use-case can progressed forwar= d if authors feel that it is ready. We would appreciate it if folks can chime in and state whether or not this = is an acceptable way forward. Thanks! -Nobo & Marc -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de] Sent: Friday, November 21, 2014 3:25 AM To: Nobo Akiya (nobo) Cc: rtg-bfd@ietf.org Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hello Nobo, (back from Hawaii or writing emails at the beach? ;-) > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > keep the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in > the draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- base. yes, exactly. > Whether the S-BFD packets with alert discriminator are handled in HW > or SW is an implementation choice. Similar to how IP router alert > option & router alert label are handled, I do see handling of S-BFD > packets with alert discriminator in the SW to be a reasonable > approach, in which case the HW instruction for S-BFD packets with > alert discriminator is to punt to SW for processing. > Personally, I tend to recommend that alert discriminators are handled > in the SW. Let's assume that you agree on this (hypothetically). In > that case, would you still recommend the alert discriminator mechanism > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > keep it in the draft-akiya-bfd-seamless-alert-discrim? That's probably where our different views come from :-) I would aim to simplify the main idea of the draft so it _can_ easily be implemented even in hardware. For the traceroute - my guess is TTL punts (if that mechanism to "deliver" = is used) happen in software as many mechanism use this "trick" but if a hardware can handle TTL punts, it can handle the diag code as well. I don't see the document needs to adjust for the traceroute case. For a basic reflector task, having a zero discriminator as a default reflec= tor discriminator would allow for very simple implementations (we discussed a while ago a fixed discriminator value for simple broadband modems, remember?). For more complex equipment and scenarios, keeping it in hardware instead of a software punt would maintain the ability of S-BFD to go up very quickl= y. I tend to not see the zero discriminator as such a big exception, which may explain my idea to integrate it into the base document. And to keep it compatible to hardware implementations. Assuming you want to add more "special effects" in the future I can see why you have an extra document. I would propose to keep the zero-reflector mentally aligned :-) with the base document and accordingly designed to allow implementations to cover the zero-reflector together with "normal" S-BFD (read: may be in hardware). > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > S-BFD packets with alert discriminator. Good - makes life simpler :-) Regards, Marc On Fri, 21 Nov 2014 01:58:59 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, > > Thanks for providing your view. > > Please see in-line. > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, November 17, 2014 1:04 AM >> To: Nobo Akiya (nobo) >> Cc: rtg-bfd@ietf.org >> Subject: Re: Seeking opinions on >> draft-akiya-bfd-seamless-alert-discrim >> >> Hello Nobo and BFD experts, >> >> giving this document a closer look for the first time (ahem ;-) I >> have a slightly different view. >> >> Having S-BFD use cases for the general S-BFD in an extra document >> does improve the overall discussion and documentation, simply because >> the base S-BFD is already complex enough, as are the use cases. >> >> But for such a relatively small document splitting off the reason why >> the document exists is not improving the reading/understanding of this draft. >> Unless you decide to integrate the alert-discriminator document into >> the base document, then obviously you use the use-case document. > > Your view is then: > > Instead of: > > (1) Move extended use-cases to draft-ietf-bfd-seamless-use-case and > keep the alert discriminator mechanism in the > draft-akiya-bfd-seamless-alert-discrim. > > Do: > > (2) Keep the extended use-cases and alert discriminator mechanism in > the draft-akiya-bfd-seamless-alert-discrim. > > Or > > (3) Move the extended use-cases to draft-ietf-bfd-seamless-use-case > and move the alert discriminator mechanism to draft-ietf-bfd-seamless- base. > > My thought was that (1) makes sense, but your view that (1) makes all > the S-BFD documents set more complex to understand is a valid concern > (it's always good to get fresh eyes on documents!). > >> >> >> For the integration of the technical aspect into the base document, I >> think this is an idea worth to discuss. At the end what you need is >> to add the rule for the zero discriminator to the reflector >> behaviour; we managed this for standard BFD, we should be able to do >> this for the reflector BFD as well >> :-) > > Whether the S-BFD packets with alert discriminator are handled in HW > or SW is an implementation choice. Similar to how IP router alert > option & router alert label are handled, I do see handling of S-BFD > packets with alert discriminator in the SW to be a reasonable > approach, in which case the HW instruction for S-BFD packets with > alert discriminator is to punt to SW for processing. > >> For the diagnostic codes I'm not sure; it will complicate hardware >> implementations (probably not a no-go problem though) and seems >> otherwise not add a real value IMHO. > > If one really wants to handle them in the HW, that's a possibility. > Although as you stated, it does complicate HW implementations and this > is another reason for SW based implementations. > >> >> So if there are already at this stage of S-BFD use case(s) for zero- >> discriminator to bring up (some) sessions then I would propose to >> consider the integration into the base document. This will also >> guarantee that the zero-discriminator handling is as fast as the >> "normal" reflection and is not on a slower exception path. > > Personally, I tend to recommend that alert discriminators are handled > in the SW. Let's assume that you agree on this (hypothetically). In > that case, would you still recommend the alert discriminator mechanism > to be moved to the draft-ietf-bfd-seamless-base or is it reasonable to > keep it in the draft-akiya-bfd-seamless-alert-discrim? > >> >> >> >> I have a question: so far S-BFD packets would be received, not >> "picked out of the data stream". Receiving could be because the >> destination IP would match or would be 127/8, the TTL would be zero >> and so on. In the security section you say ... >> >> Conceptually the Alert Discriminator is similar to an IP Router Alert >> Option or an MPLS Router Alert Label. >> >> ... and I wonder if you expect a node to "pick" S-BFD traffic (to the >> reflector) with an alert-discriminator out of the data stream that >> otherwise would just pass this node? >> I guess you don't want but I want to make sure I understand it correctly= . > > Ah, great catch. Yes we do not want "intermediate nodes" to pick up > S-BFD packets with alert discriminator. So the statement regarding > "Conceptually the Alert Discriminator is similar to an IP Router Alert > Option or an MPLS Router Alert Label" should be re-stated and clarified. > > Thanks! > > -Nobo > >> >> >> Regards, Marc >> >> >> >> >> On Fri, 14 Nov 2014 04:04:08 +0000, Nobo Akiya (nobo) wrote: >>> [Speaking as an individual S-BFD contributor] >>> >>> Hi BFD WG, >>> >>> There were couple of questions I need your input on >>> draft-akiya-bfd-seamless-alert-discrim. >>> >>> >>> (1) Should the "extended" S-BFD use cases move to >>> draft-ietf-bfd-seamless-use-case? >>> >>> My opinion is yes. Once the "extended" S-BFD use cases have been >>> incorporated into draft-ietf-bfd-seamless-use-case, then we should >>> try to move draft-ietf-bfd-seamless-use-case forward. >>> >>> How does the WG feel about this? >>> >>> >>> (2) Should the alert discriminator proposal move to >>> draft-ietf-bfd-seamless-base? >>> >>> My opinion is no . Instead we should position this as an optional >>> feature of S-BFD (hence separate document than the base), especially >>> considering we likely need to think through additional security >>> concerns >> raised by this. >>> >>> A question was raised by Greg on how does a node find out if the >>> target supports the optional alert discriminator or not. We can >>> define a mandatory diagnostic value that must be implemented when >>> the alert discriminator is implemented. One can send an S-BFD >>> control packet with the alert discriminator with this diagnostic >>> value to check if the target supports the alert discriminator mechanism= . >>> >>> How does the WG feel about this? >>> >>> >>> Thanks! >>> >>> -Nobo >>> > --_000_CECE764681BE964CBE1DFF78F3CDD3943F5A1776xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for chiming in Man= av, Mallik, Mach!

 <= /p>

Mallik, please see one co= mment in-line.

 <= /p>

From: MALLIK MUDIGONDA (mmudigon)
Sent: Monday, November 24, 2014 12:49 AM
To: Nobo Akiya (nobo); Marc Binderberger
Cc: rtg-bfd@ietf.org
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-disc= rim

 

Hi Nobo,

 

Agree that the Alert Discrimi= nator must be described in a separate document. Since the SBFD use case doc= ument is listing out all the use cases of SBFD don’t you think we should at least mention  the alert discriminator function as= on of the use cases and place a reference to the alert discriminator docum= ent in the use cases.

 

[NOBO] Normally:

1. = ;     Use case document= exists.

2. = ;     Solution document= exists and references the use case documents.

3. = ;     Extension documen= t exists and references the solution document (and possibly the use case do= cument).

So the S-BFD use case doc= ument referencing the alert discriminator document will be backwards IMO. I= think it is reasonable to not make any updates to the S-BFD use case document, wrt mentioning of the alert discriminator use-cases/pro= blems since those will be described in the alert discriminator document.

 <= /p>

Thanks!=

 <= /p>

-Nobo

 <= /p>

Thanks

 

Regards

Mallik

 

From: "Nobo Akiya (nobo)" <nobo@cisco.com>
Date: Sunday, 23 November 2014 6:45 am
To: Marc Binderberger <marc@snif= f.de>
Cc: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-disc= rim

 

Hello BFD WG,

 

Marc and I had some conversat= ion on the topic of S-BFD alert discriminator document structure, and conve= rged on a direction.

 

- We think that it is useful = to describe both the problems and the solution for the S-BFD alert discrimi= ntor in a single document.

- We also think the S-BFD ale= rt discriminator is more like an exception mechanism, thus the mechanism sh= ould remain outside of the S-BFD base document.

 

Therefore, our converged reco= mmendation to the WG is to keep the extended use-cases and the alert discri= minator mechanism in the draft-akiya-bfd-seamless-alert-discrim.=

 

This also means that no furth= er changes are needed in draft-ietf-bfd-seamless-use-case, and the draft-ie= tf-bfd-seamless-use-case can progressed forward if authors feel that it is ready.

 

We would appreciate it if fol= ks can chime in and state whether or not this is an acceptable way forward.=

 

Thanks!

 

-Nobo & Marc

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

From: Marc Binderberger [mailto:marc@sniff.de]

Sent: Friday, November 21, 20= 14 3:25 AM

To: Nobo Akiya (nobo)

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

Subject: RE: Seeking opinions= on draft-akiya-bfd-seamless-alert-discrim

Hello Nobo,=

(back from Hawaii or writing = emails at the beach? ;-)

> Your view is then:<= /o:p>

> <= /p>

> Instead of:

> <= /p>

> (1) Move extended use-ca= ses to draft-ietf-bfd-seamless-use-case and

> keep the alert discrimin= ator mechanism in the

> draft-akiya-bfd-seamless= -alert-discrim.

> <= /p>

> Do:

> <= /p>

> (2) Keep the extended us= e-cases and alert discriminator mechanism in

> the draft-akiya-bfd-seam= less-alert-discrim.

> <= /p>

> Or

> <= /p>

> (3) Move the extended us= e-cases to draft-ietf-bfd-seamless-use-case

> and move the alert discr= iminator mechanism to draft-ietf-bfd-seamless-

base.

yes, exactly.

> Whether the S-BFD packet= s with alert discriminator are handled in HW

> or SW is an implementati= on choice. Similar to how IP router alert

> option & router aler= t label are handled, I do see handling of S-BFD

> packets with alert discr= iminator in the SW to be a reasonable

> approach, in which case = the HW instruction for S-BFD packets with

> alert discriminator is t= o punt to SW for processing.

> Personally, I tend to re= commend that alert discriminators are handled

> in the SW. Let's assume = that you agree on this (hypothetically). In

> that case, would you sti= ll recommend the alert discriminator mechanism

> to be moved to the draft= -ietf-bfd-seamless-base or is it reasonable to

> keep it in the draft-aki= ya-bfd-seamless-alert-discrim?

That's probably where our dif= ferent views come from :-) I would aim to

simplify the main idea of the= draft so it _can_ easily be implemented even

in hardware.

For the traceroute - my guess= is TTL punts (if that mechanism to "deliver" is

used) happen in software as m= any mechanism use this "trick" but if a

hardware can handle TTL punts= , it can handle the diag code as well. I don't

see the document needs to adj= ust for the traceroute case.

For a basic reflector task, h= aving a zero discriminator as a default reflector

discriminator would allow for= very simple implementations (we discussed a

while ago a fixed discriminat= or value for simple broadband modems,

remember?).=

For more complex equipment an= d scenarios, keeping it in hardware instead

of a software punt would main= tain the ability of S-BFD to go up very quickly.

I tend to not see the zero di= scriminator as such a big exception, which may

explain my idea to integrate = it into the base document. And to keep it

compatible to hardware implem= entations.

Assuming you want to add more= "special effects" in the future I can see why<= /p>

you have an extra document. I= would propose to keep the zero-reflector

mentally aligned :-) with the= base document and accordingly designed to

allow implementations to cove= r the zero-reflector together with "normal"

S-BFD

(read: may be in hardware).

> Ah, great catch. Yes we = do not want "intermediate nodes" to pick up

> S-BFD packets with alert= discriminator.

Good - makes life simpler :-)=

Regards, Marc

On Fri, 21 Nov 2014 01:58:59 = +0000, Nobo Akiya (nobo) wrote:

> Hi Marc,

> <= /p>

> Thanks for providing you= r view.

> <= /p>

> Please see in-line.=

> <= /p>

>> -----Original Messag= e-----

>> From: Marc Binderber= ger [mailto:marc@sniff.de]<= /span>

>> Sent: Monday, Novemb= er 17, 2014 1:04 AM

>> To: Nobo Akiya (nobo= )

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

>> Subject: Re: Seeking= opinions on

>> draft-akiya-bfd-seam= less-alert-discrim

>> 

>> Hello Nobo and BFD e= xperts,

>> 

>> giving this document= a closer look for the first time (ahem ;-) I

>> have a slightly diff= erent view.

>> 

>> Having S-BFD use cas= es for the general S-BFD in an extra document

>> does improve the ove= rall discussion and documentation, simply because

>> the base S-BFD is al= ready complex enough, as are the use cases.

>> 

>> But for such a relat= ively small document splitting off the reason why

>> the document exists = is not improving the reading/understanding of this

draft.

>> Unless you decide to= integrate the alert-discriminator document into

>> the base document, t= hen obviously you use the use-case document.

> <= /p>

> Your view is then:<= /o:p>

> <= /p>

> Instead of:

> <= /p>

> (1) Move extended use-ca= ses to draft-ietf-bfd-seamless-use-case and

> keep the alert discrimin= ator mechanism in the

> draft-akiya-bfd-seamless= -alert-discrim.

> <= /p>

> Do:

> <= /p>

> (2) Keep the extended us= e-cases and alert discriminator mechanism in

> the draft-akiya-bfd-seam= less-alert-discrim.

> <= /p>

> Or

> <= /p>

> (3) Move the extended us= e-cases to draft-ietf-bfd-seamless-use-case

> and move the alert discr= iminator mechanism to draft-ietf-bfd-seamless-

base.

> <= /p>

> My thought was that (1) = makes sense, but your view that (1) makes all

> the S-BFD documents set = more complex to understand is a valid concern

> (it's always good to get= fresh eyes on documents!).

> <= /p>

>> 

>> 

>> For the integration = of the technical aspect into the base document, I

>> think this is an ide= a worth to discuss. At the end what you need is

>> to add the rule for = the zero discriminator to the reflector

>> behaviour; we manage= d this for standard BFD, we should be able to do

>> this for the reflect= or BFD as well

>> :-)

> <= /p>

> Whether the S-BFD packet= s with alert discriminator are handled in HW

> or SW is an implementati= on choice. Similar to how IP router alert

> option & router aler= t label are handled, I do see handling of S-BFD

> packets with alert discr= iminator in the SW to be a reasonable

> approach, in which case = the HW instruction for S-BFD packets with

> alert discriminator is t= o punt to SW for processing.

> <= /p>

>> For the diagnostic c= odes I'm not sure; it will complicate hardware

>> implementations (pro= bably not a no-go problem though) and seems

>> otherwise not add a = real value IMHO.

> <= /p>

> If one really wants to h= andle them in the HW, that's a possibility.

> Although as you stated, = it does complicate HW implementations and this

> is another reason for SW= based implementations.

> <= /p>

>> 

>> So if there are alre= ady at this stage of S-BFD use case(s) for zero-

>> discriminator to bri= ng up (some) sessions then I would propose to

>> consider the integra= tion into the base document. This will also

>> guarantee that the z= ero-discriminator handling is as fast as the

>> "normal" r= eflection and is not on a slower exception path.

> <= /p>

> Personally, I tend to re= commend that alert discriminators are handled

> in the SW. Let's assume = that you agree on this (hypothetically). In

> that case, would you sti= ll recommend the alert discriminator mechanism

> to be moved to the draft= -ietf-bfd-seamless-base or is it reasonable to

> keep it in the draft-aki= ya-bfd-seamless-alert-discrim?

> <= /p>

>> 

>> 

>> 

>> I have a question: s= o far S-BFD packets would be received, not

>> "picked out of = the data stream". Receiving could be because the

>> destination IP would= match or would be 127/8, the TTL would be zero

>> and so on. In the se= curity section you say ...

>> 

>>   &nb= sp;Conceptually the Alert Discriminator is similar to an IP Router Alert

>>   &nb= sp;Option or an MPLS Router Alert Label.

>> 

>> ... and I wonder if = you expect a node to "pick" S-BFD traffic (to the

>> reflector) with an a= lert-discriminator out of the data stream that

>> otherwise would just= pass this node?

>> I guess you don't wa= nt but I want to make sure I understand it correctly.

> <= /p>

> Ah, great catch. Yes we = do not want "intermediate nodes" to pick up

> S-BFD packets with alert= discriminator. So the statement regarding

> "Conceptually the A= lert Discriminator is similar to an IP Router Alert

> Option or an MPLS Router= Alert Label" should be re-stated and clarified.

> <= /p>

> Thanks!

> <= /p>

> -Nobo<= /p>

> <= /p>

>> 

>> 

>> Regards, Marc

>> 

>> 

>> 

>> 

>> On Fri, 14 Nov 2014 = 04:04:08 +0000, Nobo Akiya (nobo) wrote:

>>> [Speaking as an = individual S-BFD contributor]

>>> =

>>> Hi BFD WG,<= /o:p>

>>> =

>>> There were coupl= e of questions I need your input on

>>> draft-akiya-bfd-= seamless-alert-discrim.

>>> =

>>> =

>>> (1) Should the &= quot;extended" S-BFD use cases move to

>>> draft-ietf-bfd-s= eamless-use-case?

>>> =

>>> My opinion is ye= s. Once the "extended" S-BFD use cases have been

>>> incorporated int= o draft-ietf-bfd-seamless-use-case, then we should

>>> try to move draf= t-ietf-bfd-seamless-use-case forward.

>>> =

>>> How does the WG = feel about this?

>>> =

>>> =

>>> (2) Should the a= lert discriminator proposal move to

>>> draft-ietf-bfd-s= eamless-base?

>>> =

>>> My opinion is no= . Instead we should position this as an optional

>>> feature of S-BFD= (hence separate document than the base), especially

>>> considering we l= ikely need to think through additional security

>>> concerns

>> raised by this.=

>>> =

>>> A question was r= aised by Greg on how does a node find out if the

>>> target supports = the optional alert discriminator or not. We can

>>> define a mandato= ry diagnostic value that must be implemented when

>>> the alert discri= minator is implemented. One can send an S-BFD

>>> control packet w= ith the alert discriminator with this diagnostic

>>> value to check i= f the target supports the alert discriminator mechanism.<= /p>

>>> =

>>> How does the WG = feel about this?

>>> =

>>> =

>>> Thanks!

>>> =

>>> -Nobo=

>>> =

> <= /p>

 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3943F5A1776xmbalnx01ciscoc_-- From nobody Mon Nov 24 11:47:54 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 0C0EB1A8A03 for ; Mon, 24 Nov 2014 11:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f79983yXrtTR for ; Mon, 24 Nov 2014 11:47:52 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E643C1A89FB for ; Mon, 24 Nov 2014 11:47:51 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3AFDCC260; Mon, 24 Nov 2014 14:47:51 -0500 (EST) Date: Mon, 24 Nov 2014 14:47:51 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD statistics for BFD-MPLS sessions (fate of MIB) Message-ID: <20141124194751.GD28464@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/ufUVI_zp-hTWgEw0k1Jlf4kMWYg 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, 24 Nov 2014 19:47:53 -0000 Working Group, One of the topics broached during our status update at IETF-91 was the fate of the BFD MPLS MIB. (https://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-04) MIBs often don't get a lot of attention within IETF and there is often a cyclic dependency issue for customer demand based on the publication of an RFC, but no demand because there's no RFC. There is also the issue that while BFD for MPLS is obviously a popular protocol and supported across multiple vendors, MIBs are being generally supplanted by Yang. However, existing operational infrastructure still heavily depends on SNMP polling. ------8<---- cut here ---->8------ I would like to thus turn this into a different question: Does your implementation provide statistics for connectivity issues in your UI for BFD over MPLS sessions? If so, please compare them to the performance counters in the MIB. ------8<---- cut here ---->8------ The MIB obviously covers additional information, but performance counters are usually the primary motivator for the MIB. Let's use these data points to discuss whether the WG will continue to spend effort on the MIB. -- Jeff From nobody Mon Nov 24 11: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 93A0D1A895A for ; Mon, 24 Nov 2014 11:52:44 -0800 (PST) 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 pIC0yY24HgEg for ; Mon, 24 Nov 2014 11:52:41 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 437A61A8868 for ; Mon, 24 Nov 2014 11:52:41 -0800 (PST) Received: from [192.168.1.136] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 84574296CB01; Mon, 24 Nov 2014 14:52:40 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: BFD statistics for BFD-MPLS sessions (fate of MIB) From: "Thomas D. Nadeau" In-Reply-To: <20141124194751.GD28464@pfrc> Date: Mon, 24 Nov 2014 14:52:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6A4D8981-FD42-4C0D-AB99-D9BBCD0952D7@lucidvision.com> References: <20141124194751.GD28464@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PGvaY-_UDPMhqhSc3wQZ-yZLf7A 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, 24 Nov 2014 19:52:44 -0000 Also, just to add to this discussion, there is a way to = translate SMI/MIBs -> Yang. This is fairly straight-forward, especially = for simple statistics.=20 --Tom > On Nov 24, 2014:2:47 PM, at 2:47 PM, Jeffrey Haas = wrote: >=20 > Working Group, >=20 > One of the topics broached during our status update at IETF-91 was the = fate > of the BFD MPLS MIB. = (https://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-04) >=20 > MIBs often don't get a lot of attention within IETF and there is often = a > cyclic dependency issue for customer demand based on the publication = of an > RFC, but no demand because there's no RFC. =20 >=20 > There is also the issue that while BFD for MPLS is obviously a popular > protocol and supported across multiple vendors, MIBs are being = generally > supplanted by Yang. However, existing operational infrastructure = still > heavily depends on SNMP polling. >=20 > ------8<---- cut here ---->8------ >=20 > I would like to thus turn this into a different question: >=20 > Does your implementation provide statistics for connectivity issues in = your > UI for BFD over MPLS sessions? >=20 > If so, please compare them to the performance counters in the MIB. >=20 > ------8<---- cut here ---->8------ >=20 > The MIB obviously covers additional information, but performance = counters > are usually the primary motivator for the MIB. >=20 > Let's use these data points to discuss whether the WG will continue to = spend > effort on the MIB. >=20 > -- Jeff >=20 >=20 From nobody Mon Nov 24 17:29:21 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 1C8591A6F45 for ; Mon, 24 Nov 2014 17:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO_FZLyy-5W9 for ; Mon, 24 Nov 2014 17:29:17 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178D11A6F1D for ; Mon, 24 Nov 2014 17:29:17 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so7828671qcv.1 for ; Mon, 24 Nov 2014 17:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h4sj30CkoA/U0KSmDj/hiw5db1jv3jM4X71GGENkt+E=; b=VHU9e7AYwNsXyl2ST60gWk4gffA2lGeqeJEoIrAVlRwZrw28BSH0lQ2U5d64Wk85q2 X2uUnSlVGNu0XJQAGbpfEHN9noRsv5x1EfedTkIJMCWLLHG1Qz61zGnwttpSG0ZgIswJ POD/JPhZ8s2U2bR3wUTfrPtwpULuRa+g2oPdENDcKZfyP4A0mDGknHajBVnjKksotAzf uwt56uPviiN7JbPYbozFM13RjoKukCa3Muz6xOke9/3c2d22Qra9s5wOr0o2+G+1d3/M 7OXSeWTUjKrHw0/IHX+b9L2CvBcq3nOrLJ4Rs379fSM1akh09A9mA+R952T2T5M0IHRq UQUQ== MIME-Version: 1.0 X-Received: by 10.140.51.99 with SMTP id t90mr32994016qga.72.1416878956377; Mon, 24 Nov 2014 17:29:16 -0800 (PST) Received: by 10.96.65.42 with HTTP; Mon, 24 Nov 2014 17:29:16 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Nov 2014 17:29:16 -0800 Message-ID: Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim From: Sam Aldrin To: "Nobo Akiya (nobo)" Content-Type: multipart/alternative; boundary=001a11351efae27d6c0508a4d6f1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/oep8S319BC_0Dw4OxSSwTZwyBVE Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 01:29:19 -0000 --001a11351efae27d6c0508a4d6f1 Content-Type: text/plain; charset=UTF-8 [resending as mailer complained, mail is too long; removed earlier content as well) Hi Nobo et al, I have finally read the 'alert discriminator' document. Keeping the solution aside, what makes it special that the use case cannot be documented in 'use case' ID? Irrespectively, while explaining the solution, the problem has to be explained anyway. But, when there is use case document, like other use cases, adding the use case will be good, doesn't it? I know it will only delay the use-case document, which I am an editor of it. Want to understand the rationale behind it. (Read emails, but don't think I am convinced). Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2). I am not sure if it is indeed needed as BFD was not used so far like this. Just a simple extension or not is different matter. Whether we should be doing it with BFD (not just S-BFD) is more important and needs to be discussed. And I do not think that it should be part of S-BFD use case at this point. cheers sam --001a11351efae27d6c0508a4d6f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[resending as mailer complained, mail is too l= ong; removed earlier content as well)
Hi Nobo et al= ,

I have finally= read the 'alert discriminator' document.

Keeping the solution aside, what makes it = special that the use case cannot be documented in 'use case' ID?
Irrespectivel= y, while explaining the solution, the problem has to be explained anyway.
But, when th= ere is use case document, like other use cases, adding the use case will be= good, doesn't it?

I know it will only delay the use-case document, which I am an editor= of it.=C2=A0
Want to understand the rationale behind it. (Read emails, but don't = think I am convinced).

Secondly, the alert-discriminator ID specifies the 'trace' op= tion (sec 2.2).
I am not sure if it is indeed needed as BFD was not used so far like t= his.
Just a= simple extension or not is different matter. Whether we should be doing it= with BFD (not just S-BFD) is more important and needs to be discussed.
And I do not t= hink that it should be part of S-BFD use case at this point.

cheers
sam
--001a11351efae27d6c0508a4d6f1-- From nobody Tue Nov 25 16:19: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 3547D1A89A8 for ; Tue, 25 Nov 2014 16:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6u7LmlHyo0C for ; Tue, 25 Nov 2014 16:19:32 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A41A89A6 for ; Tue, 25 Nov 2014 16:19:32 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 00556C15F; Tue, 25 Nov 2014 19:19:31 -0500 (EST) Date: Tue, 25 Nov 2014 19:19:31 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD stability follow-up from IETF-91 Message-ID: <20141126001931.GJ20330@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aFaUKpa4l-uxdBvI9b2E7xdwo4c 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, 26 Nov 2014 00:19:33 -0000 draft-ashesh-bfd-stability-01 was presented again during IETF-91 in Honolulu. The slides can be viewed here: http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx To attempt to simplify the presentation, the contentious portion of the timers were removed from the proposal, leaving only the sequence numbering for detecting loss of BFD async packets. When the room was polled to see whether the draft should be adopted as a WG item, the sense of the room was very quiet. As promised, this is to inquire for support for this draft on the WG mailing list to make sure the whole group has a voice. It should be noted that post-meeting discussion on the fate of this draft noted that BFD authentication code points are plentiful and are available with expert review. Should the draft authors wish to continue this work as Experimental, that is an option. -- Jeff From nobody Tue Nov 25 16:50:06 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 0A4791A8759 for ; Tue, 25 Nov 2014 16:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3twacgXcL8PP for ; Tue, 25 Nov 2014 16:50:02 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7611A874B for ; Tue, 25 Nov 2014 16:50:02 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 31ABFC15F; Tue, 25 Nov 2014 19:50:02 -0500 (EST) Date: Tue, 25 Nov 2014 19:50:02 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Message-ID: <20141126005002.GL20330@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4hBvErm22BgsqaelKIxg7Q4MEwQ 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, 26 Nov 2014 00:50:03 -0000 Working Group, Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was presented at IETF-91 in Honolulu and was positively received. We'd like to ask the Working Group whether we should formally adopt this draft as a Working Group item. Please indicate your support or lack thereof to the mail list by December 12, 2014. Also, please supply feedback to the authors. I believe the perception of this document is that it's very nearly complete and thus should have a short lifetime prior to publication as an RFC. -- Jeff & Nobo. From nobody Tue Nov 25 16:57: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 442631A8759 for ; Tue, 25 Nov 2014 16:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDkTTbEiwhWu for ; Tue, 25 Nov 2014 16:57:38 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0DB1A874B for ; Tue, 25 Nov 2014 16:57:38 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id z107so1380741qgd.1 for ; Tue, 25 Nov 2014 16:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KJ3eP2CsgKLbyUSKe/lixlspryzNvTNCtD/7wF9DiSQ=; b=S7FMHJa/6MwuHxMBDXbz+3VpmdzCwKWJL/d//R5veJT49F+CYX6yWbvMLCTXUrrQGP WJCtIyQJwq1ZCYb35Zg7Sy4hGXe9K7+FxSS195yTwDZ68Ds+ESlp8LpY8q9K/kgCMFGf 6hNBaz/2CHm8s4H4jcRlMYAVFfB75HWDKXuPIfUBLwqwW4Q0sp+n/nn1p7x8+fYckXNz Sced6CJrFD6RSNKwcFRuxwKZnzq6Up79xuKaiGlcZ0Bp2owCOWxWoXLxCxbeldXb2Di+ YgYyISnRdxCXkc6X0WLarUgQBzQNil4irdWJ5IGQ6oSxfia/+57YXh874zr6N6dqViqW g2AA== MIME-Version: 1.0 X-Received: by 10.140.107.163 with SMTP id h32mr41185074qgf.34.1416963457998; Tue, 25 Nov 2014 16:57:37 -0800 (PST) Received: by 10.96.65.42 with HTTP; Tue, 25 Nov 2014 16:57:37 -0800 (PST) In-Reply-To: <20141126005002.GL20330@pfrc> References: <20141126005002.GL20330@pfrc> Date: Tue, 25 Nov 2014 16:57:37 -0800 Message-ID: Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) From: Sam Aldrin To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a113a64b292e77f0508b883db Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KpcUnSBcNTItj83Pl9r-hKaqgvU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 00:57:40 -0000 --001a113a64b292e77f0508b883db Content-Type: text/plain; charset=UTF-8 Support the adoption. Important piece of work and very much needed. -sam On Tue, Nov 25, 2014 at 4:50 PM, Jeffrey Haas wrote: > Working Group, > > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. > > Please indicate your support or lack thereof to the mail list by > December 12, 2014. > > Also, please supply feedback to the authors. I believe the perception of > this document is that it's very nearly complete and thus should have a > short > lifetime prior to publication as an RFC. > > -- Jeff & Nobo. > > --001a113a64b292e77f0508b883db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support the adoption.
Important piece of work and very= much needed.

-sam

On Tue, Nov 25, 2014 at 4:50 PM, Jeff= rey Haas <jhaas@pfrc.org> wrote:
Working Group,

Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was
presented at IETF-91 in Honolulu and was positively received.=C2=A0 We'= d like to
ask the Working Group whether we should formally adopt this draft as a
Working Group item.

Please indicate your support or lack thereof to the mail list by
December 12, 2014.

Also, please supply feedback to the authors.=C2=A0 I believe the perception= of
this document is that it's very nearly complete and thus should have a = short
lifetime prior to publication as an RFC.

-- Jeff & Nobo.


--001a113a64b292e77f0508b883db-- From nobody Tue Nov 25 17:28: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 6359B1A89AD; Tue, 25 Nov 2014 17:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ca3S9ND9TtAi; Tue, 25 Nov 2014 17:28:51 -0800 (PST) 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 E09ED1A89AC; Tue, 25 Nov 2014 17:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1416965331; x=1418174931; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oY4+Khnv+1do1pQSOmLBifBkI2+ra0ADptIy+eniRkI=; b=W6a1B3BAw7wRNXLzekDzZ3BFFmxw3b5zY/eyVDnpQNCIKjrwGSiMJn+m yO4QbDSwkTMV5J40Ut+U8q1o7ekfcF0f5+3ZLe8m1aBK8GxU9tbewCY07 1ZqHhYXUyPa2ltej08MeIMzi8dvptSdub6EauEM5er/j/zxM8CFqskFWy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAL0rdVStJV2b/2dsb2JhbABbgmMjgSkEzxkCgQ8WAQEBAQF9hAIBAQEEOksEAgEIEQQBAQsUCQcyFAkIAgQBEgiIOAHROwEBAQEBAQEBAQEBAQEBAQEBAQEBAReNL4J7AQEeOAaDKIEfAQSQN4IsjU6DWYM5hFc+hTaECoI3gUV3gQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="100156210" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 26 Nov 2014 01:28:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAQ1SoeU022433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 01:28:50 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 19:28:49 -0600 From: "Nobo Akiya (nobo)" To: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwD0kN+7aWAUmXdJExNJzzJ5xyHHug Date: Wed, 26 Nov 2014 01:28:49 +0000 Message-ID: References: <20141126005002.GL20330@pfrc> In-Reply-To: <20141126005002.GL20330@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.99.53] 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/31-OU0TFIQThYAbd2zOT9LVZals 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, 26 Nov 2014 01:28:52 -0000 Dear MPLS WG, As agreed at IETF91, we would like to keep the MPLS WG involved with draft-= grmas-bfd-rfc5884-clarifications. The document clarifies the procedures of BFD on MPLS. If this topic is of y= our interest, please do read and provide comments. Note, the WG adoption poll for draft-grmas-bfd-rfc5884-clarifications was j= ust kicked off today (and ends on Dec. 12, 2014). Thanks! -Nobo and Jeff > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, November 25, 2014 7:50 PM > To: rtg-bfd@ietf.org > Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends > December 12, 2014) >=20 > Working Group, >=20 > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like = to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. >=20 > Please indicate your support or lack thereof to the mail list by December= 12, > 2014. >=20 > Also, please supply feedback to the authors. I believe the perception of= this > document is that it's very nearly complete and thus should have a short > lifetime prior to publication as an RFC. >=20 > -- Jeff & Nobo. From nobody Tue Nov 25 17:55: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 0D9DA1A1E0F for ; Tue, 25 Nov 2014 17:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAG9sRml3Ia6 for ; Tue, 25 Nov 2014 17:55:30 -0800 (PST) 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 1949B1A1BF4 for ; Tue, 25 Nov 2014 17:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4052; q=dns/txt; s=iport; t=1416966929; x=1418176529; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RfwJYjQ0lx+X5EAoDQsOQOV8svaAymREtHEcjuh+hws=; b=GNgD8IjB+2rsPHliyyEXw6ZU4O/l3qhss0s30fckAoQnFdaT0SVRCYpH c464I3FDT78bPgZWejOUboZrnbjv/NGLOjMSfiR96KAbV4dnA/8zz7kls vpRyLzRyiTUN2HdG94EUf6CFl1BjTPkzXxpBJTwZu2qtreLz/ryaA+pxz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4IANMxdVStJV2S/2dsb2JhbABbgmMjgSkEgwHMGAIcdBYBAQEBAX2EAgEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgDBQIEDgUIE4gQAwkJAbsQj38NhhwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgS6NFYFnAQEeMQcGgnI2gR8BBJA3giyKBYNJg1mDOYdYhn2DfHeBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,459,1413244800"; d="scan'208";a="100148547" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP; 26 Nov 2014 01:55:29 +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 sAQ1tTVm026981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 01:55:29 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; Tue, 25 Nov 2014 19:55:29 -0600 From: "Nobo Akiya (nobo)" To: Sam Aldrin Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAAAB0lM4AAWZpcAACXg7LA= Date: Wed, 26 Nov 2014 01:55:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.99.53] 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/hFMnfLBoF_nNgYrxDw5RiM6MXt8 Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:55:32 -0000 SGkgU2FtLA0KDQpHb29kIHBvaW50cywgcGxlYXNlIHNlZSBpbi1saW5lIHdpdGggW05PQk9dLg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNhbSBBbGRyaW4gW21haWx0 bzphbGRyaW4uaWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjQsIDIw MTQgODoyOSBQTQ0KPiBUbzogTm9ibyBBa2l5YSAobm9ibykNCj4gQ2M6IE1BTExJSyBNVURJR09O REEgKG1tdWRpZ29uKTsgTWFyYyBCaW5kZXJiZXJnZXI7IHJ0Zy1iZmRAaWV0Zi5vcmc7DQo+IG1h bmF2QGlvbm9zbmV0d29ya3MuY29tDQo+IFN1YmplY3Q6IFJlOiBTZWVraW5nIG9waW5pb25zIG9u IGRyYWZ0LWFraXlhLWJmZC1zZWFtbGVzcy1hbGVydC1kaXNjcmltDQo+IA0KPiBbcmVzZW5kaW5n IGFzIG1haWxlciBjb21wbGFpbmVkLCBtYWlsIGlzIHRvbyBsb25nOyByZW1vdmVkIGVhcmxpZXIg Y29udGVudA0KPiBhcyB3ZWxsKQ0KPiBIaSBOb2JvIGV0IGFsLA0KPiANCj4gSSBoYXZlIGZpbmFs bHkgcmVhZCB0aGUgJ2FsZXJ0IGRpc2NyaW1pbmF0b3InIGRvY3VtZW50Lg0KDQpbTk9CT10gVGhh bmtzIQ0KDQo+IA0KPiBLZWVwaW5nIHRoZSBzb2x1dGlvbiBhc2lkZSwgd2hhdCBtYWtlcyBpdCBz cGVjaWFsIHRoYXQgdGhlIHVzZSBjYXNlIGNhbm5vdA0KPiBiZSBkb2N1bWVudGVkIGluICd1c2Ug Y2FzZScgSUQ/DQoNCltOT0JPXSBJIGhhdmUgZmxpcC1mbG9wcGVkIG9uIHRoZSBkb2N1bWVudCBz dHJ1Y3R1cmUgYnV0IGhlcmUncyBteSBjdXJyZW50IHRob3VnaHRzLg0KDQpDdXJyZW50bHkgdGhl IFMtQkZEIHVzZSBjYXNlIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgdXNlIGNhc2VzIGZvciB0aGUg Y29yZSBTLUJGRCBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBpbiB0aGUgUy1CRkQgYmFzZSBkb2N1 bWVudC4gDQoNCkFzIHlvdSBkZXNjcmliZWQgYmVsb3csIHdlIGRvIG5vdCB5ZXQgaGF2ZSB0aGUg V0cgY29uc2Vuc3VzIG9uIHRoZSBhbGVydCBkaXNjcmltaW5hdG9yIHVzZSBjYXNlcyBub3IgdGhl IG1lY2hhbmlzbSwgYW5kIHRoaXMgaXMgc29tZXRoaW5nIHdoaWNoIG5lZWRzIHRvIGdldCBkaXNj dXNzZWQgbW9yZS4NCg0KSG93ZXZlciwgdGhlcmUgaXMgbm8gcmVhc29uIHRvIGhhbHQgdGhlIHBy b2dyZXNzIG9mIFMtQkZEIHVzZS1jYXNlL2Jhc2UvaXAgZG9jdW1lbnRzIGFzIHRoZXJlIGlzIG5v IGRlcGVuZGVuY3kgZnJvbSB0aGVtIHRvIHRoZSBhbGVydCBkaXNjcmltaW5hdG9yLg0KDQpUaGVy ZWZvcmUgYXQgdGhpcyBwb2ludCBpdCBtYWtlcyBzZW5zZSBbdG8gbWVdIHRoYXQgd2U6DQoxKSBQ cm9ncmVzcyBTLUJGRCB1c2UtY2FzZSBkb2N1bWVudC4NCjIpIFByb2dyZXNzIFMtQkZEIGJhc2Uv aXAgZG9jdW1lbnRzLg0KMykgRGlzY3VzcyB0aGUgdXNlLWNhc2VzL21lY2hhbmlzbSBvZiB0aGUg YWxlcnQgZGlzY3JpbWluYXRvciwgd2l0aG91dCBjcmVhdGluZyBhIGRlcGVuZGVuY3kgZnJvbSAo MSwgMikgdG8gdGhlIGFsZXJ0IGRpc2NyaW1pbmF0b3IuDQoNCj4gSXJyZXNwZWN0aXZlbHksIHdo aWxlIGV4cGxhaW5pbmcgdGhlIHNvbHV0aW9uLCB0aGUgcHJvYmxlbSBoYXMgdG8gYmUNCj4gZXhw bGFpbmVkIGFueXdheS4NCg0KW05PQk9dIEFncmVlLg0KDQo+IEJ1dCwgd2hlbiB0aGVyZSBpcyB1 c2UgY2FzZSBkb2N1bWVudCwgbGlrZSBvdGhlciB1c2UgY2FzZXMsIGFkZGluZyB0aGUgdXNlDQo+ IGNhc2Ugd2lsbCBiZSBnb29kLCBkb2Vzbid0IGl0Pw0KDQpbTk9CT10gSWYgdGhleSBhcmUgdXNl IGNhc2VzIGZvciB0aGUgYmFzZSBmdW5jdGlvbmFsaXR5LCB0aGVuIGRlZmluaXRlbHkgeWVzLiBJ ZiB0aGVyZSBhcmUgdXNlIGNhc2VzIHRoYXQgcmVxdWlyZSBmdXJ0aGVyIGV4dGVuc2lvbnMgdG8g dGhlIGJhc2UgZnVuY3Rpb25hbGl0eSwgdGhlbiBJIHRoaW5rIHRoZSBhbnN3ZXIgcmVhbGx5IGRl cGVuZHMgKGxpa2Ugd2hlcmUgd2UgYXJlKS4NCg0KPiANCj4gSSBrbm93IGl0IHdpbGwgb25seSBk ZWxheSB0aGUgdXNlLWNhc2UgZG9jdW1lbnQsIHdoaWNoIEkgYW0gYW4gZWRpdG9yIG9mIGl0Lg0K PiBXYW50IHRvIHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBiZWhpbmQgaXQuIChSZWFkIGVtYWls cywgYnV0IGRvbid0IHRoaW5rIEkNCj4gYW0gY29udmluY2VkKS4NCg0KW05PQk9dIEkgaG9wZSBh Ym92ZSBwcm92aWRlcyBtb3JlIGNvbnRleHQgb24gd2hlcmUgd2UgYXJlPw0KDQo+IA0KPiBTZWNv bmRseSwgdGhlIGFsZXJ0LWRpc2NyaW1pbmF0b3IgSUQgc3BlY2lmaWVzIHRoZSAndHJhY2UnIG9w dGlvbiAoc2VjIDIuMikuDQo+IEkgYW0gbm90IHN1cmUgaWYgaXQgaXMgaW5kZWVkIG5lZWRlZCBh cyBCRkQgd2FzIG5vdCB1c2VkIHNvIGZhciBsaWtlIHRoaXMuDQo+IEp1c3QgYSBzaW1wbGUgZXh0 ZW5zaW9uIG9yIG5vdCBpcyBkaWZmZXJlbnQgbWF0dGVyLiBXaGV0aGVyIHdlIHNob3VsZCBiZQ0K PiBkb2luZyBpdCB3aXRoIEJGRCAobm90IGp1c3QgUy1CRkQpIGlzIG1vcmUgaW1wb3J0YW50IGFu ZCBuZWVkcyB0byBiZQ0KPiBkaXNjdXNzZWQuDQoNCltOT0JPXSBGdWxseSBhZ3JlZSB0aGF0IHdl IG5lZWQgdG8gZGlzY3VzcyBhYm92ZSBmdXJ0aGVyLg0KDQo+IEFuZCBJIGRvIG5vdCB0aGluayB0 aGF0IGl0IHNob3VsZCBiZSBwYXJ0IG9mIFMtQkZEIHVzZSBjYXNlIGF0IHRoaXMgcG9pbnQuDQoN CltOT0JPXSBFeGNlbGxlbnQhIFNvIHdlIGFyZSBpbiBzeW5jIGFib3V0IHRoZSBkb2N1bWVudCBz dHJ1Y3R1cmUgdGhlbi4gTGV0IHB1c2ggcHJvY2VlZCB3aXRoIHRoaXMgcGF0aCwgYW5kIHNwYXdu IG9mZiBhIHNlcGFyYXRlIHRocmVhZCB0byBkaXNjdXNzIHRoZSB2YWxpZGl0eSBvZiB0aGUgYWxl cnQgZGlzY3JpbWluYXRvciB1c2UtY2FzZXMgYW5kIHRoZSBtZWNoYW5pc20uIFNvdW5kcyBsaWtl IGEgcGxhbj8NCg0KVGhhbmtzIQ0KDQotTm9ibw0KDQo+IA0KPiBjaGVlcnMNCj4gc2FtDQo= From nobody Tue Nov 25 19:59:19 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 932811A87E1 for ; Tue, 25 Nov 2014 19:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiP8iCKjuXch for ; Tue, 25 Nov 2014 19:59:12 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB371A8795 for ; Tue, 25 Nov 2014 19:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11314; q=dns/txt; s=iport; t=1416974352; x=1418183952; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=L07mvzgxsCtPEndlKlOpuPvM2jyzHqDTUevmz9CIuAE=; b=gt4Wpq8OXMLcoTRxIbNUX0SSgRnhUyqEfQ0rX7mqmGK0zATGHknNcaqN lSYw08CcpcXDNwCL5wrwkozJugy/waR6Yb6Z6grQMDuFAG/krH35DPfyD TPkKDIeom9ULspZsH9+NfeAvun0djxOf2/uGLOxL4iAQj7i241RNg3qXw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAGFPdVStJA2N/2dsb2JhbABbgkJEgSkExXyJBAKBEBYBAQEBAX2EAgEBAQR5DAYBCBEDAQEBKCYCERQJAwUCBAENBRuIEAMSyncNhhwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjkOBZwEBPhEHBoRHBZA3giwFigCCFIE1g1mDOYdYhn2DfHeBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208,217";a="100114925" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 26 Nov 2014 03:59:11 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sAQ3xBov017401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 03:59:11 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 21:59:10 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Nobo Akiya (nobo)" , Sam Aldrin Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAAAB0lM4AAWZpcAACXg7LAAHSwHAA== Date: Wed, 26 Nov 2014 03:59:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.110.45] Content-Type: multipart/alternative; boundary="_000_D09B4DB527AB7mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dCxvrnf4-DH2qD9LCg1Wu3Qj5tw Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 03:59:16 -0000 --_000_D09B4DB527AB7mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nobo, I am convinced. If Sam doesn=92t have any further comments I think we are g= ood to go. Thanks Regards Mallik From: "Nobo Akiya (nobo)" > Date: Wednesday, 26 November 2014 7:25 am To: Sam Aldrin > Cc: Cisco Employee >, Marc Bi= nderberger >, "rtg-bfd@ietf.org" >, "manav@iono= snetworks.com" > Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Hi Sam, Good points, please see in-line with [NOBO]. -----Original Message----- From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Monday, November 24, 2014 8:29 PM To: Nobo Akiya (nobo) Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; rtg-bfd@ietf.org; manav@ionosnetworks.com Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim [resending as mailer complained, mail is too long; removed earlier content as well) Hi Nobo et al, I have finally read the 'alert discriminator' document. [NOBO] Thanks! Keeping the solution aside, what makes it special that the use case cannot be documented in 'use case' ID? [NOBO] I have flip-flopped on the document structure but here's my current = thoughts. Currently the S-BFD use case document describes the use cases for the core = S-BFD functionality described in the S-BFD base document. As you described below, we do not yet have the WG consensus on the alert di= scriminator use cases nor the mechanism, and this is something which needs = to get discussed more. However, there is no reason to halt the progress of S-BFD use-case/base/ip = documents as there is no dependency from them to the alert discriminator. Therefore at this point it makes sense [to me] that we: 1) Progress S-BFD use-case document. 2) Progress S-BFD base/ip documents. 3) Discuss the use-cases/mechanism of the alert discriminator, without crea= ting a dependency from (1, 2) to the alert discriminator. Irrespectively, while explaining the solution, the problem has to be explained anyway. [NOBO] Agree. But, when there is use case document, like other use cases, adding the use case will be good, doesn't it? [NOBO] If they are use cases for the base functionality, then definitely ye= s. If there are use cases that require further extensions to the base funct= ionality, then I think the answer really depends (like where we are). I know it will only delay the use-case document, which I am an editor of it= . Want to understand the rationale behind it. (Read emails, but don't think I am convinced). [NOBO] I hope above provides more context on where we are? Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2)= . I am not sure if it is indeed needed as BFD was not used so far like this. Just a simple extension or not is different matter. Whether we should be doing it with BFD (not just S-BFD) is more important and needs to be discussed. [NOBO] Fully agree that we need to discuss above further. And I do not think that it should be part of S-BFD use case at this point. [NOBO] Excellent! So we are in sync about the document structure then. Let = push proceed with this path, and spawn off a separate thread to discuss the= validity of the alert discriminator use-cases and the mechanism. Sounds li= ke a plan? Thanks! -Nobo cheers sam --_000_D09B4DB527AB7mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3E301279C080F2429712391BC0F9ACF3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Nobo,

I am convinced. If Sam doesn=92t have any further comments I think we = are good to go.

Thanks

Regards
Mallik

From: "Nobo Akiya (nobo)"= <nobo@cisco.com>
Date: Wednesday, 26 November 2014 7= :25 am
To: Sam Aldrin <aldrin.ietf@gmail.com>
Cc: Cisco Employee <mmudigon@cisco.com>, Marc Binderberger <= ;marc@sniff.de>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "manav@ionosnetworks.com" <manav@ionosnetworks= .com>
Subject: RE: Seeking opinions on dr= aft-akiya-bfd-seamless-alert-discrim

Hi Sam,

Good points, please see in-line with [NOBO].

-----Original Message-----
Sent: Monday, November 24, 2014 8:29 PM
To: Nobo Akiya (nobo)
Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; rtg-bfd@ietf.org;
Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discri= m
[resending as mailer complained, mail is too long; removed earlier con= tent
as well)
Hi Nobo et al,
I have finally read the 'alert discriminator' document.

[NOBO] Thanks!

Keeping the solution aside, what makes it special that the use case ca= nnot
be documented in 'use case' ID?

[NOBO] I have flip-flopped on the document structure but here's my cur= rent thoughts.

Currently the S-BFD use case document describes the use cases for the = core S-BFD functionality described in the S-BFD base document.

As you described below, we do not yet have the WG consensus on the ale= rt discriminator use cases nor the mechanism, and this is something which n= eeds to get discussed more.

However, there is no reason to halt the progress of S-BFD use-case/bas= e/ip documents as there is no dependency from them to the alert discriminat= or.

Therefore at this point it makes sense [to me] that we:
1) Progress S-BFD use-case document.
2) Progress S-BFD base/ip documents.
3) Discuss the use-cases/mechanism of the alert discriminator, without= creating a dependency from (1, 2) to the alert discriminator.

Irrespectively, while explaining the solution, the problem has to be
explained anyway.

[NOBO] Agree.

But, when there is use case document, like other use cases, adding the= use
case will be good, doesn't it?

[NOBO] If they are use cases for the base functionality, then definite= ly yes. If there are use cases that require further extensions to the base = functionality, then I think the answer really depends (like where we are).<= /div>

I know it will only delay the use-case document, which I am an editor = of it.
Want to understand the rationale behind it. (Read emails, but don't th= ink I
am convinced).

[NOBO] I hope above provides more context on where we are?

Secondly, the alert-discriminator ID specifies the 'trace' option (sec= 2.2).
I am not sure if it is indeed needed as BFD was not used so far like t= his.
Just a simple extension or not is different matter. Whether we should = be
doing it with BFD (not just S-BFD) is more important and needs to be
discussed.

[NOBO] Fully agree that we need to discuss above further.

And I do not think that it should be part of S-BFD use case at this po= int.

[NOBO] Excellent! So we are in sync about the document structure then.= Let push proceed with this path, and spawn off a separate thread to discus= s the validity of the alert discriminator use-cases and the mechanism. Soun= ds like a plan?

Thanks!

-Nobo

cheers
sam

--_000_D09B4DB527AB7mmudigonciscocom_-- From nobody Tue Nov 25 20:00: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 758241A878E for ; Tue, 25 Nov 2014 20:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq7XSU0TfSDf for ; Tue, 25 Nov 2014 20:00:31 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFE71A8795 for ; Tue, 25 Nov 2014 20:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3643; q=dns/txt; s=iport; t=1416974431; x=1418184031; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=IS1z04qZNeLoRcYjV13CsOVd8SCPn2zzFZrOJH1Dgc4=; b=K+QzKaUpRreuFSyOXjiPpuWfWF1RbfQ5IDtMmtJrgZmoo9xvOZvJ9Gno VD3lRtDJ8icwbxngq4p1czrcrgTiacgrdtrzmyduXvFf92UndBoqmRX0v FZ4GwzJ63sAvVUjZx5fQCHcoEnSjqtl2wUHgAeApXDLg+In5YJlRv7I63 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAA5QdVStJA2E/2dsb2JhbABbgkJEgSkExXyJBAKBEBYBAQEBAX2EAgECBIELAQgECgMDAQIoJhMUCQgCBAESiEDRIgEBAQEBAQEDAQEBAQEBAQEajS+CewEBPhiETQWQN4IsBYwUgTWDWYgQPoU2hAqCEiWBRXeBDzmBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208,217";a="375680645" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP; 26 Nov 2014 04:00:30 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAQ40UGL023370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 04:00:30 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 22:00:29 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwH6Kv9QIwN0O1uYeLO3TR6ZxzCaiA Date: Wed, 26 Nov 2014 04:00:29 +0000 Message-ID: In-Reply-To: <20141126005002.GL20330@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.110.45] Content-Type: multipart/alternative; boundary="_000_D09B4E1227ABDmmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/E4D9ar3m0d1o326tdQy1bSa93nU 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, 26 Nov 2014 04:00:32 -0000 --_000_D09B4E1227ABDmmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I fully support the adoption of this draft as a WG item. Thanks Regards Mallik From: Jeffrey Haas > Date: Wednesday, 26 November 2014 6:20 am To: "rtg-bfd@ietf.org" > Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends Dec= ember 12, 2014) Working Group, Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was presented at IETF-91 in Honolulu and was positively received. We'd like to ask the Working Group whether we should formally adopt this draft as a Working Group item. Please indicate your support or lack thereof to the mail list by December 12, 2014. Also, please supply feedback to the authors. I believe the perception of this document is that it's very nearly complete and thus should have a shor= t lifetime prior to publication as an RFC. -- Jeff & Nobo. --_000_D09B4E1227ABDmmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0C7001D301E68D4388380B550B4A40A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

I fully support the adoption of this draft as a WG item. 

Thanks

Regards
Mallik

From: Jeffrey Haas <jhaas@pfrc.org>
Date: Wednesday, 26 November 2014 6= :20 am
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Adoption poll for draft-gr= mas-bfd-rfc5884-clarifications (ends December 12, 2014)

Working Group,

Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, wa= s
presented at IETF-91 in Honolulu and was positively received. &nb= sp;We'd like to
ask the Working Group whether we should formally adopt this draft as a=
Working Group item.

Please indicate your support or lack thereof to the mail list by
December 12, 2014.  

Also, please supply feedback to the authors.  I believe the = perception of
this document is that it's very nearly complete and thus should have a= short
lifetime prior to publication as an RFC.

-- Jeff & Nobo.


--_000_D09B4E1227ABDmmudigonciscocom_-- From nobody Tue Nov 25 20:07: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 97AE11A87A1 for ; Tue, 25 Nov 2014 20:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 dvp-onxgesau for ; Tue, 25 Nov 2014 20:07:14 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C261A70E1 for ; Tue, 25 Nov 2014 20:07:14 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id fp1so1953993pdb.0 for ; Tue, 25 Nov 2014 20:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MfDM2lbZs+0tA6TsYBe1Su6odPYGSaV+26RiLbW9QSI=; b=A0gTWYoe4vTFF3FTKvCNlYJf4vJCCb2cJxmL7vq38FUJkKr3KUB/lBhaVLulRzVkS4 SLb0PMG6UMNk2bAw1GoFJFHyaZqhPUx0o24a2k3EFvNj0FVpseHs+weiBBUItjPcOcoq vFCkWwKC/PE4hQSFP/CNvdz3c5HnSJQrdP2HsgHBZzLrzva+TuGJi3gF7DYDxvHviTIl cIXPJZrfN7MiQtLIOFsIO3Do7ch8YE5wiywcbMlK5wVDtiLtZ7cMA3soEEJSlFZGB0ov blmqTEICqvVJLTAzhnJYzW0z3DWehMhJ63AVkapbtB9w9j0VTPRIYZdpcVdsgUc5FgqQ Cz3w== X-Received: by 10.66.141.167 with SMTP id rp7mr49557569pab.118.1416974833450; Tue, 25 Nov 2014 20:07:13 -0800 (PST) Received: from [192.168.1.9] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id o12sm2868051pdj.36.2014.11.25.20.07.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 20:07:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim From: Sam Aldrin In-Reply-To: Date: Tue, 25 Nov 2014 20:07:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0iN5czGRUewjdU9INj7KTI6lvPs Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 04:07:22 -0000 Hi Nobo, Thank you for the reply. Inline for my comments. -sam > On Nov 25, 2014, at 5:55 PM, Nobo Akiya (nobo) wrote: > Hi Sam, >=20 > Good points, please see in-line with [NOBO]. >=20 >> -----Original Message----- >> From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] >> Sent: Monday, November 24, 2014 8:29 PM >> To: Nobo Akiya (nobo) >> Cc: MALLIK MUDIGONDA (mmudigon); Marc Binderberger; rtg-bfd@ietf.org; >> manav@ionosnetworks.com >> Subject: Re: Seeking opinions on = draft-akiya-bfd-seamless-alert-discrim >>=20 >> [resending as mailer complained, mail is too long; removed earlier = content >> as well) >> Hi Nobo et al, >>=20 >> I have finally read the 'alert discriminator' document. >=20 > [NOBO] Thanks! >=20 >>=20 >> Keeping the solution aside, what makes it special that the use case = cannot >> be documented in 'use case' ID? >=20 > [NOBO] I have flip-flopped on the document structure but here's my = current thoughts. >=20 > Currently the S-BFD use case document describes the use cases for the = core S-BFD functionality described in the S-BFD base document.=20 >=20 > As you described below, we do not yet have the WG consensus on the = alert discriminator use cases nor the mechanism, and this is something = which needs to get discussed more. >=20 > However, there is no reason to halt the progress of S-BFD = use-case/base/ip documents as there is no dependency from them to the = alert discriminator. Ah ok! I didn't know there would much worry about Alert Discriminator as = a use case. If you say, it was not discussed much, then I am ok with = your reasoning. >=20 > Therefore at this point it makes sense [to me] that we: > 1) Progress S-BFD use-case document. > 2) Progress S-BFD base/ip documents. > 3) Discuss the use-cases/mechanism of the alert discriminator, without = creating a dependency from (1, 2) to the alert discriminator. Sounds fair. Additionally, you should start discussion on alert = discriminator as well. Feel it has usefulness.=20 >=20 >> Irrespectively, while explaining the solution, the problem has to be >> explained anyway. >=20 > [NOBO] Agree. >=20 >> But, when there is use case document, like other use cases, adding = the use >> case will be good, doesn't it? >=20 > [NOBO] If they are use cases for the base functionality, then = definitely yes. If there are use cases that require further extensions = to the base functionality, then I think the answer really depends (like = where we are). Nod.=20 >=20 >>=20 >> I know it will only delay the use-case document, which I am an editor = of it. >> Want to understand the rationale behind it. (Read emails, but don't = think I >> am convinced). >=20 > [NOBO] I hope above provides more context on where we are? Affirm. clear now. >=20 >>=20 >> Secondly, the alert-discriminator ID specifies the 'trace' option = (sec 2.2). >> I am not sure if it is indeed needed as BFD was not used so far like = this. >> Just a simple extension or not is different matter. Whether we should = be >> doing it with BFD (not just S-BFD) is more important and needs to be >> discussed. >=20 > [NOBO] Fully agree that we need to discuss above further. >=20 >> And I do not think that it should be part of S-BFD use case at this = point. >=20 > [NOBO] Excellent! So we are in sync about the document structure then. = Let push proceed with this path, and spawn off a separate thread to = discuss the validity of the alert discriminator use-cases and the = mechanism. Sounds like a plan? Yes, indeed is a plan. -sam >=20 > Thanks! >=20 > -Nobo >=20 >>=20 >> cheers >> sam From nobody Tue Nov 25 21:36: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 9991F1A86E3 for ; Tue, 25 Nov 2014 21:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQwJF6gzJekv for ; Tue, 25 Nov 2014 21:36:33 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C461A871D for ; Tue, 25 Nov 2014 21:36:32 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Wed, 26 Nov 2014 05:36:31 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Wed, 26 Nov 2014 05:36:31 +0000 From: Santosh P K To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLuMid50QvovUCZwbFqEoEt05xyYwQA Date: Wed, 26 Nov 2014 05:36:30 +0000 Message-ID: <90cf0e8393fc4061afc0f9cecfacec76@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126005002.GL20330@pfrc> In-Reply-To: <20141126005002.GL20330@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(377454003)(51704005)(199003)(54356999)(31966008)(76176999)(64706001)(46102003)(230783001)(50986999)(66066001)(2656002)(122556002)(40100003)(87936001)(19580395003)(21056001)(19580405001)(120916001)(97736003)(101416001)(33646002)(62966003)(77156002)(107886001)(107046002)(74316001)(106356001)(106116001)(20776003)(108616004)(86362001)(99286002)(95666004)(105586002)(92566001)(76576001)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/b1Lji4rCENOXJOZ750jqu7xu5SQ 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, 26 Nov 2014 05:36:34 -0000 I do support adaption of this draft as WG document. This has clarified few = things which are not clear in RFC 5884.=20 Thanks Santosh P K =20 > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Wednesday, November 26, 2014 6:20 AM > To: rtg-bfd@ietf.org > Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends > December 12, 2014) >=20 > Working Group, >=20 > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like = to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. >=20 > Please indicate your support or lack thereof to the mail list by December= 12, > 2014. >=20 > Also, please supply feedback to the authors. I believe the perception of= this > document is that it's very nearly complete and thus should have a short > lifetime prior to publication as an RFC. >=20 > -- Jeff & Nobo. From nobody Tue Nov 25 21:46:32 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 360651A1B38; Tue, 25 Nov 2014 21:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MppxxeRnMRWF; Tue, 25 Nov 2014 21:46:27 -0800 (PST) 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 848511A1AAF; Tue, 25 Nov 2014 21:46:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1515; q=dns/txt; s=iport; t=1416980788; x=1418190388; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=d3MtDt7zHwNN1QTPdfB0ov0WgQUFHxeZMVwXI+XlzlM=; b=WxRQckF6Gv8L3S3nvoiOtNL454herWvEMbIVsEkSiBCXVlFcxzbwe2OO 3YK1xeKQw1OlJcLfQpkP8AAjcd4QHNXuKTEkW/D6rbDVwqgNHiKyJNj4I aPotU/3PjHWEfGe+fuSlQgRplEl3z5YD2Pv7nUBBzrbbE999u9z2zvlq8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADJodVStJA2D/2dsb2JhbABbgwaBKQTFfYkEAoEPFgEBAQEBfYQCAQEBBDpLBAIBCBEEAQEfCQcyFAkIAgQBEohA0UEBAQEBAQEBAQEBAQEBAQEBAQEBGY0vgnsBAVYGhEcBBJJjjBmBNYNZgzmEVz6FNoQKghIlgUV3gQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.07,460,1413244800"; d="scan'208";a="375318153" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP; 26 Nov 2014 05:46:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sAQ5kQhP022000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 05:46:26 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.205]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 23:46:26 -0600 From: "Srihari Raghavan (srihari)" To: "Nobo Akiya (nobo)" , "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwS7f2dECu50OEVSoIGHVtvZxygxeAgACkb4A= Date: Wed, 26 Nov 2014 05:46:25 +0000 Message-ID: References: <20141126005002.GL20330@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.32.121] 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/j_RLf5kXPZ7lgzXMI8pUchYQ3NY 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, 26 Nov 2014 05:46:29 -0000 Fully support the adoption, as one of the implementors of the base draft. Thanks Srihari On 26/11/14 6:58 am, "Nobo Akiya (nobo)" wrote: >Dear MPLS WG, > >As agreed at IETF91, we would like to keep the MPLS WG involved with >draft-grmas-bfd-rfc5884-clarifications. > >The document clarifies the procedures of BFD on MPLS. If this topic is of >your interest, please do read and provide comments. > >Note, the WG adoption poll for draft-grmas-bfd-rfc5884-clarifications was >just kicked off today (and ends on Dec. 12, 2014). > >Thanks! > >-Nobo and Jeff > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey >>Haas >> Sent: Tuesday, November 25, 2014 7:50 PM >> To: rtg-bfd@ietf.org >> Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends >> December 12, 2014) >>=20 >> Working Group, >>=20 >> Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was >> presented at IETF-91 in Honolulu and was positively received. We'd >>like to >> ask the Working Group whether we should formally adopt this draft as a >> Working Group item. >>=20 >> Please indicate your support or lack thereof to the mail list by >>December 12, >> 2014. >>=20 >> Also, please supply feedback to the authors. I believe the perception >>of this >> document is that it's very nearly complete and thus should have a short >> lifetime prior to publication as an RFC. >>=20 >> -- Jeff & Nobo. > From nobody Tue Nov 25 22:01:53 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 106861A1B87 for ; Tue, 25 Nov 2014 22:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI7IX3mfT1yU for ; Tue, 25 Nov 2014 22:01:48 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2D41A1B5D for ; Tue, 25 Nov 2014 22:01:48 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-45-547510f64438 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 40.A0.25146.6F015745; Wed, 26 Nov 2014 00:29:59 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 01:01:46 -0500 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLu2a9r7L5qbEmUFDJIrrzwZZxyZ0dw Date: Wed, 26 Nov 2014 06:01:45 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8985F7@eusaamb103.ericsson.se> References: <20141126005002.GL20330@pfrc> In-Reply-To: <20141126005002.GL20330@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPiO53gdIQg53HGC32H3zLavH5zzZG ByaPJUt+Mnlc7t3KGsAUxWWTkpqTWZZapG+XwJUxaZ54wQKOigkTzjE1MN5k62Lk4JAQMJE4 +Ee6i5ETyBSTuHBvPVCYi0NI4AijxKQXXewQznJGibnzn7CCVLEJGEm82NjDDmKLCHhIdB97 zghiCwskSEy4OIkZIp4osfrKQlYI20jib8caFhCbRUBVovPXbLA4r4CvxM1fy8DmCAloSnx8 38QKchCngJbEu/dMIGFGoIO+n1oDZjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsJUk5ry+ xgxRryOxYPcnNghbW2LZwtfMEGsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHKXFqWW5 6UaGmxiBkXBMgs1xB+OCT5aHGAU4GJV4eDdcLAkRYk0sK67MPcQozcGiJM6rWT0vWEggPbEk NTs1tSC1KL6oNCe1+BAjEwenVAOj4bl3chETP03r382t2K89I1jAeumnB3/OrolSXdiu7t7v o/heVqRDZfvCTRMW6l3SF3W7vK1ul0+Iio1X3tct0gseGyaeXZ1atvfHg1BRmZ16oc+u3Gqe 91Q71YPZcXb+AxeZzNIDvw2ZfQ5v9HJ4Z8dVxq5c4X549csvdvfZP/02eHE8KMJEiaU4I9FQ i7moOBEA+4rHRGUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/wwK8XV4BDAsLhU3f7RO59e1e1UY 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, 26 Nov 2014 06:01:50 -0000 yes/support As WG discussion started at IETF-90 meeting demonstrated, community would b= enefit from detailed explanation of how BFD over MPLS LSP can be used in EC= MP environment. Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, November 25, 2014 4:50 PM To: rtg-bfd@ietf.org Subject: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends Dec= ember 12, 2014) Working Group, Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was pre= sented at IETF-91 in Honolulu and was positively received. We'd like to as= k the Working Group whether we should formally adopt this draft as a Workin= g Group item. Please indicate your support or lack thereof to the mail list by December 1= 2, 2014. =20 Also, please supply feedback to the authors. I believe the perception of t= his document is that it's very nearly complete and thus should have a short= lifetime prior to publication as an RFC. -- Jeff & Nobo. From nobody Tue Nov 25 22:34:40 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 7FC8D1A1B9E for ; Tue, 25 Nov 2014 22:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drF49kxC-qYd for ; Tue, 25 Nov 2014 22:34:37 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E61C01A1B9B for ; Tue, 25 Nov 2014 22:34:36 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 742112AA0F; Wed, 26 Nov 2014 06:34:33 +0000 (GMT) Date: Tue, 25 Nov 2014 22:37:33 -0800 From: Marc Binderberger To: Sam Aldrin Message-ID: <20141125223733023799.7609dd07@sniff.de> In-Reply-To: References: Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim 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/t3xNsSyDO5AP1VGxBfWjRlYC69I Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 06:34:38 -0000 Hello Sam, > [resending as mailer complained, mail is too long; removed earlier content > as well) complained but still delivered the long email too :-) > Keeping the solution aside, what makes it special that the use case cannot > be documented in 'use case' ID? I would say it's the other way around: what makes S-BFD base and use-case so special that we separated them? And sure, there is a good answer: size and focus. Especially keeping focus on both topics - protocol and use cases - is probably easier with two documents. But for something the size of the alert-discriminator the size is not a problem and for being focused it's then in favour of one single document (IMHO). Splitting a small document makes it just fuzzy (my very personal opinion ;-) > Secondly, the alert-discriminator ID specifies the 'trace' option (sec 2.2). > I am not sure if it is indeed needed as BFD was not used so far like this. > Just a simple extension or not is different matter. Whether we should be > doing it with BFD (not just S-BFD) is more important and needs to be > discussed. Interesting point. Regards, Marc From nobody Tue Nov 25 22:56:47 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 919651A1A34 for ; Tue, 25 Nov 2014 22:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 R8PU17zsdkKh for ; Tue, 25 Nov 2014 22:56:42 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881A71A1B93 for ; Tue, 25 Nov 2014 22:56:42 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id i138so1592595oig.22 for ; Tue, 25 Nov 2014 22:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dbnMIks8G96Zga4aTvAVwPOEVAzgEhRpG2ZMg0HCaQw=; b=sJn/oic1Px+NqZvi7MnkN5fkMZ3RdnTMeVQ+gYXpixl3gH53velylg6R36lR6EfqqG giPaL78By4cM2jxTUbCPoSFohOIGhV/bzVPAj1UG4Mx2kVY2g70UIMaQO3JqrPXGKAYC 9SIk6arjvAnH+AwSfsbP7RDNHJa+reLsmRKt1PCGZonvwRFeAdW5DzM3Zr3TeJDJ2CQu Nnorl40hSikKZ6j7NF8TN5ydOoaXvnOhWHlrHyzoeN+/w6XST+tOvKoUcTTqsW7BJHnt wdHN0Dpx2psKi1xe2v3/O5tg4glS6aav1sFbC8q72CFfhd3M4f6JtJHzrXwv1j+V7SJJ UqwA== MIME-Version: 1.0 X-Received: by 10.202.80.21 with SMTP id e21mr17544267oib.65.1416985001716; Tue, 25 Nov 2014 22:56:41 -0800 (PST) Received: by 10.76.178.199 with HTTP; Tue, 25 Nov 2014 22:56:41 -0800 (PST) In-Reply-To: <20141126001931.GJ20330@pfrc> References: <20141126001931.GJ20330@pfrc> Date: Wed, 26 Nov 2014 12:26:41 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NpsdreLPbY0jIZ8FivbB0GUqAOk Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 06:56:44 -0000 Hi Jeff, I vividly remember the original intent of the stability draft was to help debug BFD failures -- to isolate the issue at the RX or the TX side Time stamping would have helped in debugging whether the BFD packet was sent late, or whether the packet was sent on time and also arrived on time but was delayed when passing it up the BFD stack/processor (lay in the RX buffer for tad too long), etc. But then time stamping came with its own set of issues, and was hence dropped from the original draft. Can the authors send a summary on the list on why time stamping was dropped so that we're all clear on that one. The current proposal does help but is not complete. Assume that the RX end loses a BFD session and learns later that it did eventually receive the missing BFD packets (based on the seq #). How would it know which end was misbehaving? Was it a delay at the TX side, or was it the RX that delayed passing the packets to the BFD process(or). This is usually what we want to debug and i want to understand how this draft with sequence numbers can unequivocally tell me that. I believe the work is important and addresses something thats really required (spent too much time debugging why BFD flapped!). Clearly what would help is putting a small section that describes how we can use the sequence numbers to debug what and where things went wrong. Cheers, Manav On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: > draft-ashesh-bfd-stability-01 was presented again during IETF-91 in > Honolulu. The slides can be viewed here: > > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > > To attempt to simplify the presentation, the contentious portion of the > timers were removed from the proposal, leaving only the sequence numbering > for detecting loss of BFD async packets. > > When the room was polled to see whether the draft should be adopted as a WG > item, the sense of the room was very quiet. As promised, this is to inquire > for support for this draft on the WG mailing list to make sure the whole > group has a voice. > > It should be noted that post-meeting discussion on the fate of this draft > noted that BFD authentication code points are plentiful and are available > with expert review. Should the draft authors wish to continue this work as > Experimental, that is an option. > > -- Jeff > From nobody Tue Nov 25 23:40: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 95D9E1A1BCB for ; Tue, 25 Nov 2014 23:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHRpYjBNko8T for ; Tue, 25 Nov 2014 23:39:59 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD131A1AEC for ; Tue, 25 Nov 2014 23:39:59 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 09CB72AA0F; Wed, 26 Nov 2014 07:39:56 +0000 (GMT) Date: Tue, 25 Nov 2014 23:42:56 -0800 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20141125234256188865.aafe8a3f@sniff.de> In-Reply-To: <20141126005002.GL20330@pfrc> References: <20141126005002.GL20330@pfrc> Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) 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/BOMhS0I9dTPTSn-Mf3_8Ve0_D7I Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 07:40:00 -0000 Hello Jeff et al., hmm. I'm not against the adoption of this draft as a workgroup draft but - and I hope I don't step on anybodies toes - the draft seems to be in an early stage. Nor can I see much of a discussion on this list about the topic. There are for sure some interesting aspects. If enough people consider the BFD session removal as relevant for RFC5884 then we have a good reason as a workgroup to move on. I have my doubts about the multiple session per as I don't see how you tackle ECMP without multiple . In other words while section 2.1 may be a correct procedure for multiple BFD sessions I wonder what problem you try to solve? Maybe this needs more discussion. Long story short: while I can see this draft becoming a workgroup draft I find the poll - well - premature. Regards, Marc On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: > Working Group, > > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. > > Please indicate your support or lack thereof to the mail list by > December 12, 2014. > > Also, please supply feedback to the authors. I believe the perception of > this document is that it's very nearly complete and thus should have a short > lifetime prior to publication as an RFC. > > -- Jeff & Nobo. > From nobody Wed Nov 26 00:47:30 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 518B41A0049 for ; Wed, 26 Nov 2014 00:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9boQW7BevEcb for ; Wed, 26 Nov 2014 00:47:27 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C26591A0007 for ; Wed, 26 Nov 2014 00:47:26 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id AFD312AA0F; Wed, 26 Nov 2014 08:47:24 +0000 (GMT) Date: Wed, 26 Nov 2014 00:50:23 -0800 From: Marc Binderberger To: Manav Bhatia Message-ID: <20141126005023981392.0c488535@sniff.de> In-Reply-To: References: <20141126001931.GJ20330@pfrc> Subject: Re: BFD stability follow-up from IETF-91 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/UGNJxUtkXjOAiIaozLaZgh7r0Nc Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 08:47:28 -0000 Hello Manav, > I believe the work is important and addresses something thats really > required (spent too much time debugging why BFD flapped!). agree :-) we should keep the discussion alive. > side Time stamping would have helped in debugging whether the BFD > packet was sent late, or whether the packet was sent on time and also > arrived on time but was delayed when passing it up the BFD > stack/processor (lay in the RX buffer for tad too long) well, I can see a point in having the Tx timestamps in the packet mainly for the purpose of knowing "this" packet was okay/not okay on the Tx side and to correlate it with your local Rx measurement. And even this point is less relevant with sequence numbers as this number allows the identification of packets and thus the correlation of information from the Tx and Rx system. Regards, Marc On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > Hi Jeff, > > I vividly remember the original intent of the stability draft was to > help debug BFD failures -- to isolate the issue at the RX or the TX > side Time stamping would have helped in debugging whether the BFD > packet was sent late, or whether the packet was sent on time and also > arrived on time but was delayed when passing it up the BFD > stack/processor (lay in the RX buffer for tad too long), etc. But then > time stamping came with its own set of issues, and was hence dropped > from the original draft. > > Can the authors send a summary on the list on why time stamping was > dropped so that we're all clear on that one. > > The current proposal does help but is not complete. > > Assume that the RX end loses a BFD session and learns later that it > did eventually receive the missing BFD packets (based on the seq #). > How would it know which end was misbehaving? Was it a delay at the TX > side, or was it the RX that delayed passing the packets to the BFD > process(or). This is usually what we want to debug and i want to > understand how this draft with sequence numbers can unequivocally tell > me that. > > I believe the work is important and addresses something thats really > required (spent too much time debugging why BFD flapped!). Clearly > what would help is putting a small section that describes how we can > use the sequence numbers to debug what and where things went wrong. > > Cheers, Manav > > > On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: >> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in >> Honolulu. The slides can be viewed here: >> >> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >> >> To attempt to simplify the presentation, the contentious portion of the >> timers were removed from the proposal, leaving only the sequence numbering >> for detecting loss of BFD async packets. >> >> When the room was polled to see whether the draft should be adopted as a WG >> item, the sense of the room was very quiet. As promised, this is to >> inquire >> for support for this draft on the WG mailing list to make sure the whole >> group has a voice. >> >> It should be noted that post-meeting discussion on the fate of this draft >> noted that BFD authentication code points are plentiful and are available >> with expert review. Should the draft authors wish to continue this work as >> Experimental, that is an option. >> >> -- Jeff >> > From nobody Wed Nov 26 01:17: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 1C54D1A6FFD for ; Wed, 26 Nov 2014 01:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4q6mkgctB9t for ; Wed, 26 Nov 2014 01:17:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546BA1A6FED for ; Wed, 26 Nov 2014 01:17:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPF95883; Wed, 26 Nov 2014 09:17:43 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Nov 2014 09:17:40 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 26 Nov 2014 17:17:33 +0800 From: Mach Chen To: Marc Binderberger , Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6rAzFT2tE9mEytVJLqLOd+Cpxx9AmAgAAfxYCAAIivkA== Date: Wed, 26 Nov 2014 09:17:32 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> In-Reply-To: <20141126005023981392.0c488535@sniff.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/q8OOYn2AOWCq8uz8J5SJ8OP1rCY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 09:17:48 -0000 Hi Marc and Manav, > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Wednesday, November 26, 2014 4:50 PM > To: Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 >=20 > Hello Manav, >=20 > > I believe the work is important and addresses something thats really > > required (spent too much time debugging why BFD flapped!). >=20 > agree :-) we should keep the discussion alive. >=20 >=20 > > side Time stamping would have helped in debugging whether the BFD > > packet was sent late, or whether the packet was sent on time and also > > arrived on time but was delayed when passing it up the BFD > > stack/processor (lay in the RX buffer for tad too long) >=20 > well, I can see a point in having the Tx timestamps in the packet mainly = for the > purpose of knowing "this" packet was okay/not okay on the Tx side and to > correlate it with your local Rx measurement. Yes, this is one solution if people think BFD delay is needed. If allow to = have Tx timestamps to be carried in the packets, seems it should be no prob= lem to leave a seat for the Rx timestamps as well :-). After all, with both= Tx and Rx timestamp, it may simplify the implementation.=20 >=20 > And even this point is less relevant with sequence numbers as this number > allows the identification of packets and thus the correlation of informat= ion from > the Tx and Rx system. Indeed, the sequence number helps a lot for the correlation between the Tx = and Rx system.=20 This triggers me think out there should be another solution for getting the= Tx and Rx timestamps without encoding the timestamps in the BFD packets. F= or example, the Tx and Rx systems could just save timestamps locally or sen= d them to a centralized entity and then use the sequence numbers to correla= te them for further analyzing. Best regards, Mach >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > Hi Jeff, > > > > I vividly remember the original intent of the stability draft was to > > help debug BFD failures -- to isolate the issue at the RX or the TX > > side Time stamping would have helped in debugging whether the BFD > > packet was sent late, or whether the packet was sent on time and also > > arrived on time but was delayed when passing it up the BFD > > stack/processor (lay in the RX buffer for tad too long), etc. But then > > time stamping came with its own set of issues, and was hence dropped > > from the original draft. > > > > Can the authors send a summary on the list on why time stamping was > > dropped so that we're all clear on that one. > > > > The current proposal does help but is not complete. > > > > Assume that the RX end loses a BFD session and learns later that it > > did eventually receive the missing BFD packets (based on the seq #). > > How would it know which end was misbehaving? Was it a delay at the TX > > side, or was it the RX that delayed passing the packets to the BFD > > process(or). This is usually what we want to debug and i want to > > understand how this draft with sequence numbers can unequivocally tell > > me that. > > > > I believe the work is important and addresses something thats really > > required (spent too much time debugging why BFD flapped!). Clearly > > what would help is putting a small section that describes how we can > > use the sequence numbers to debug what and where things went wrong. > > > > Cheers, Manav > > > > > > On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: > >> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in > >> Honolulu. The slides can be viewed here: > >> > >> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > >> > >> To attempt to simplify the presentation, the contentious portion of > >> the timers were removed from the proposal, leaving only the sequence > >> numbering for detecting loss of BFD async packets. > >> > >> When the room was polled to see whether the draft should be adopted > >> as a WG item, the sense of the room was very quiet. As promised, > >> this is to inquire for support for this draft on the WG mailing list > >> to make sure the whole group has a voice. > >> > >> It should be noted that post-meeting discussion on the fate of this > >> draft noted that BFD authentication code points are plentiful and are > >> available with expert review. Should the draft authors wish to > >> continue this work as Experimental, that is an option. > >> > >> -- Jeff > >> > > From nobody Wed Nov 26 05:01:23 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 EF3241A1BBC for ; Wed, 26 Nov 2014 05:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMGV0Qw0xsSU for ; Wed, 26 Nov 2014 05:01:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6911A01A5 for ; Wed, 26 Nov 2014 05:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1915; q=dns/txt; s=iport; t=1417006878; x=1418216478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ea4f6Gqnd9WvQkYLvC9Yffn0JZ0N701NsElxwwl7zfs=; b=FvXrZtIuZyzzbRIfhJ0L5m1sP3/JaKLOipJaMrtJhnCMEw75WwhLH1Ti QCJyW6RHgV34YFV4e2ZAhPi7PrRIAh3zqAFRuqQBuanCxqwlSm7Npw9n9 uLuL47WexSqSPL+rFIDYwkGZyfVt/hufJtNrzRMKKMX4a4p14Jc+a4D07 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAJ/OdVStJA2H/2dsb2JhbABbgmMjgSkEzmoCgQsWAQEBAQF9hAIBAQEEOj8MBAIBCBEEAQELFAkHMhQJAwUCBAENBQgTiCUB0XcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkBkQAgEeMQcGgyiBHwEEkDeCLKM1g3x3gUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.07,462,1413244800"; d="scan'208";a="375448452" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP; 26 Nov 2014 13:01:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAQD1H0C020720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 13:01:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 07:01:17 -0600 From: "Nobo Akiya (nobo)" To: Marc Binderberger , Sam Aldrin Subject: RE: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Topic: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim Thread-Index: Ac//wAdQ8oS8wTAIRaCZduflS+eKRACnnpkAALMORiAAGw69AABIby4QAFSEnAAAB0lM4AAWZpcAAD0O34AAALf5AA== Date: Wed, 26 Nov 2014 13:01:16 +0000 Message-ID: References: <20141125223733023799.7609dd07@sniff.de> In-Reply-To: <20141125223733023799.7609dd07@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.228] 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/awTATGkfSsgVvk8G8LvfrBiFVPI Cc: "rtg-bfd@ietf.org" , "manav@ionosnetworks.com" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 13:01:20 -0000 Hi Sam, Marc, Mallik, Many thanks for healthy discussions. To summarize: - I will spawn off a separate thread for the alert discriminator soon. - I [as individual contributor] believe draft-ietf-bfd-seamless-use-case do= cument is now ready to progress. Authors have the ball to poke the chairs := ) Thanks! -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Wednesday, November 26, 2014 1:38 AM > To: Sam Aldrin > Cc: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org; > manav@ionosnetworks.com > Subject: Re: Seeking opinions on draft-akiya-bfd-seamless-alert-discrim >=20 > Hello Sam, >=20 > > [resending as mailer complained, mail is too long; removed earlier > > content as well) >=20 > complained but still delivered the long email too :-) >=20 >=20 > > Keeping the solution aside, what makes it special that the use case > > cannot be documented in 'use case' ID? >=20 > I would say it's the other way around: what makes S-BFD base and use-case > so special that we separated them? >=20 > And sure, there is a good answer: size and focus. Especially keeping focu= s on > both topics - protocol and use cases - is probably easier with two docume= nts. > But for something the size of the alert-discriminator the size is not a > problem and for being focused it's then in favour of one single document > (IMHO). >=20 > Splitting a small document makes it just fuzzy (my very personal opinion = ;-) >=20 >=20 > > Secondly, the alert-discriminator ID specifies the 'trace' option (sec = 2.2). > > I am not sure if it is indeed needed as BFD was not used so far like th= is. > > Just a simple extension or not is different matter. Whether we should > > be doing it with BFD (not just S-BFD) is more important and needs to > > be discussed. >=20 > Interesting point. >=20 >=20 > Regards, Marc From nobody Wed Nov 26 09:39: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 369691A1A94 for ; Wed, 26 Nov 2014 09:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHGwiqBupy23 for ; Wed, 26 Nov 2014 09:39:48 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463601A014D for ; Wed, 26 Nov 2014 09:39:43 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E84892AA0F; Wed, 26 Nov 2014 17:39:40 +0000 (GMT) Date: Wed, 26 Nov 2014 09:42:42 -0800 From: Marc Binderberger To: Mach Chen Message-ID: <20141126094242449051.c8abfe39@sniff.de> In-Reply-To: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> Subject: RE: BFD stability follow-up from IETF-91 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/KW9SrnXjCxmlbQducELJQ_qyE78 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 17:39:50 -0000 Hello Mach, > This triggers me think out there should be another solution for getting the > Tx and Rx timestamps without encoding the timestamps in the BFD packets. > For example, the Tx and Rx systems could just save timestamps locally or > send them to a centralized entity and then use the sequence numbers to > correlate them for further analyzing. I remember some discussion on NVO3 about how many bits it takes ;-) - could you send the links/draft names you are working on to this list? May be useful for further discussions. Thanks & Regards, Marc On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > Hi Marc and Manav, > >> -----Original Message----- >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> Binderberger >> Sent: Wednesday, November 26, 2014 4:50 PM >> To: Manav Bhatia >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD stability follow-up from IETF-91 >> >> Hello Manav, >> >>> I believe the work is important and addresses something thats really >>> required (spent too much time debugging why BFD flapped!). >> >> agree :-) we should keep the discussion alive. >> >> >>> side Time stamping would have helped in debugging whether the BFD >>> packet was sent late, or whether the packet was sent on time and also >>> arrived on time but was delayed when passing it up the BFD >>> stack/processor (lay in the RX buffer for tad too long) >> >> well, I can see a point in having the Tx timestamps in the packet mainly >> for the >> purpose of knowing "this" packet was okay/not okay on the Tx side and to >> correlate it with your local Rx measurement. > > Yes, this is one solution if people think BFD delay is needed. If allow to > have Tx timestamps to be carried in the packets, seems it should be no > problem to leave a seat for the Rx timestamps as well :-). After all, with > both Tx and Rx timestamp, it may simplify the implementation. > >> >> And even this point is less relevant with sequence numbers as this number >> allows the identification of packets and thus the correlation of >> information from >> the Tx and Rx system. > > Indeed, the sequence number helps a lot for the correlation between the Tx > and Rx system. > > This triggers me think out there should be another solution for getting the > Tx and Rx timestamps without encoding the timestamps in the BFD packets. > For example, the Tx and Rx systems could just save timestamps locally or > send them to a centralized entity and then use the sequence numbers to > correlate them for further analyzing. > > Best regards, > Mach > >> >> >> Regards, Marc >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >>> Hi Jeff, >>> >>> I vividly remember the original intent of the stability draft was to >>> help debug BFD failures -- to isolate the issue at the RX or the TX >>> side Time stamping would have helped in debugging whether the BFD >>> packet was sent late, or whether the packet was sent on time and also >>> arrived on time but was delayed when passing it up the BFD >>> stack/processor (lay in the RX buffer for tad too long), etc. But then >>> time stamping came with its own set of issues, and was hence dropped >>> from the original draft. >>> >>> Can the authors send a summary on the list on why time stamping was >>> dropped so that we're all clear on that one. >>> >>> The current proposal does help but is not complete. >>> >>> Assume that the RX end loses a BFD session and learns later that it >>> did eventually receive the missing BFD packets (based on the seq #). >>> How would it know which end was misbehaving? Was it a delay at the TX >>> side, or was it the RX that delayed passing the packets to the BFD >>> process(or). This is usually what we want to debug and i want to >>> understand how this draft with sequence numbers can unequivocally tell >>> me that. >>> >>> I believe the work is important and addresses something thats really >>> required (spent too much time debugging why BFD flapped!). Clearly >>> what would help is putting a small section that describes how we can >>> use the sequence numbers to debug what and where things went wrong. >>> >>> Cheers, Manav >>> >>> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in >>>> Honolulu. The slides can be viewed here: >>>> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >>>> >>>> To attempt to simplify the presentation, the contentious portion of >>>> the timers were removed from the proposal, leaving only the sequence >>>> numbering for detecting loss of BFD async packets. >>>> >>>> When the room was polled to see whether the draft should be adopted >>>> as a WG item, the sense of the room was very quiet. As promised, >>>> this is to inquire for support for this draft on the WG mailing list >>>> to make sure the whole group has a voice. >>>> >>>> It should be noted that post-meeting discussion on the fate of this >>>> draft noted that BFD authentication code points are plentiful and are >>>> available with expert review. Should the draft authors wish to >>>> continue this work as Experimental, that is an option. >>>> >>>> -- Jeff >>>> >>> > From nobody Wed Nov 26 09:54:21 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 C063F1A0203 for ; Wed, 26 Nov 2014 09:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiAPLArGSTxq for ; Wed, 26 Nov 2014 09:54:19 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C8B381A016A for ; Wed, 26 Nov 2014 09:54:17 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 89C88C193; Wed, 26 Nov 2014 12:54:17 -0500 (EST) Date: Wed, 26 Nov 2014 12:54:17 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD Wiki updated Message-ID: <20141126175417.GD568@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/haflEWeyu-5AZm2n26ZBRhMpgFY 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, 26 Nov 2014 17:54:20 -0000 http://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart The BFD wiki page has been updated with current status as seen by the WG chairs. The Yang design team stuff needs to be filled out a bit more, but that coordination may go via the overall RTG area yang coordination page. -- Jeff From nobody Wed Nov 26 10:20:06 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 227B71A1A72 for ; Wed, 26 Nov 2014 10:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1VAqb-Zo3cd for ; Wed, 26 Nov 2014 10:19:58 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC111A1A6B for ; Wed, 26 Nov 2014 10:19:57 -0800 (PST) X-AuditID: c618062d-f79206d0000014d2-79-5475c050f4a0 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 76.31.05330.050C5745; Wed, 26 Nov 2014 12:58:09 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 13:19:47 -0500 From: Gregory Mirsky To: Mach Chen , Marc Binderberger , "Manav Bhatia" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAQXYg Date: Wed, 26 Nov 2014 18:19:46 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B898C13@eusaamb103.ericsson.se> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> 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.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B898C13eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonSjfwQGmIwb6rbBYX1gpbXJ7Uxm4x +8p/ZovPf7YxOrB47Jx1l92j5chbVo8lS34yebSu7mYJYInisklJzcksSy3St0vgylh+7wRz wbSiise3WBoYd8Z2MXJySAiYSLxb38QOYYtJXLi3nq2LkYtDSOAIo8Sfq9tYIJzljBJXVpxj A6liEzCSeLGxB6xDRKBQ4suONjCbWUBTounEZzBbWMBQYlX3YqgaI4ljM+ZC2W4S85a+YAWx WQRUJa7MPgUW5xXwlVg3dzY7xLLnjBI3Tk4FK+IUCJOYe3ItC4jNCHTe91NrmCCWiUvcejKf CeJsAYkle84zQ9iiEi8f/2OFsJUkPv6eD3VcvsSBSTeglglKnJz5hGUCo+gsJKNmISmbhaQM Iq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMvmMSbLo7GPe8tDzE KMDBqMTDu+FiSYgQa2JZcWXuIUZpDhYlcd5ZtfOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBK NTAueHHhkseb/ufayTwvCrjnxdusj00oOzWpaNbVHfkfkq+HHWWs/PRh/qTXvUmHKp+t6Z79 zPUuq1nON8Z+5ZqTW41PLlV4tii+vcFtX2XeCvXq5lO6ZXMdWHb+2vlgH+Pr1bd1CzUMI6zV 9N4z7F7L3OAiOHu5+Y+EMz8mtM1rEIj+KrB8s1u3EktxRqKhFnNRcSIAriHf9Z8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/z48idxjW9zQBHJAnX8p1PEafamU Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 18:20:01 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B898C13eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, are we turning BFD into 1588? It does seem like that by the extent of our d= iscussion of timestamping issue. The PTP has two methods of measuring Resident Time, time a packet spent in = a node (I feel that is what we're trying to measure by collecting timestamp= s): * one-step - resident time measured on a packet and reported in the s= ame packet; * two-step - more elaborate as it requires source port identification= , sequence number and proper type of a packet. Residence time measured on o= ne packet but reported in the follow-up of appropriate type. Does that sounds like what we're discussing? Regards, Greg -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen Sent: Wednesday, November 26, 2014 1:18 AM To: Marc Binderberger; Manav Bhatia Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Marc and Manav, > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > Binderberger > Sent: Wednesday, November 26, 2014 4:50 PM > To: Manav Bhatia > Cc: rtg-bfd@ietf.org > Subject: Re: BFD stability follow-up from IETF-91 > > Hello Manav, > > > I believe the work is important and addresses something thats really > > required (spent too much time debugging why BFD flapped!). > > agree :-) we should keep the discussion alive. > > > > side Time stamping would have helped in debugging whether the BFD > > packet was sent late, or whether the packet was sent on time and > > also arrived on time but was delayed when passing it up the BFD > > stack/processor (lay in the RX buffer for tad too long) > > well, I can see a point in having the Tx timestamps in the packet > mainly for the purpose of knowing "this" packet was okay/not okay on > the Tx side and to correlate it with your local Rx measurement. Yes, this is one solution if people think BFD delay is needed. If allow to = have Tx timestamps to be carried in the packets, seems it should be no prob= lem to leave a seat for the Rx timestamps as well :-). After all, with both= Tx and Rx timestamp, it may simplify the implementation. > > And even this point is less relevant with sequence numbers as this > number allows the identification of packets and thus the correlation > of information from the Tx and Rx system. Indeed, the sequence number helps a lot for the correlation between the Tx = and Rx system. This triggers me think out there should be another solution for getting the= Tx and Rx timestamps without encoding the timestamps in the BFD packets. F= or example, the Tx and Rx systems could just save timestamps locally or sen= d them to a centralized entity and then use the sequence numbers to correla= te them for further analyzing. Best regards, Mach > > > Regards, Marc > > > > > > > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > Hi Jeff, > > > > I vividly remember the original intent of the stability draft was to > > help debug BFD failures -- to isolate the issue at the RX or the TX > > side Time stamping would have helped in debugging whether the BFD > > packet was sent late, or whether the packet was sent on time and > > also arrived on time but was delayed when passing it up the BFD > > stack/processor (lay in the RX buffer for tad too long), etc. But > > then time stamping came with its own set of issues, and was hence > > dropped from the original draft. > > > > Can the authors send a summary on the list on why time stamping was > > dropped so that we're all clear on that one. > > > > The current proposal does help but is not complete. > > > > Assume that the RX end loses a BFD session and learns later that it > > did eventually receive the missing BFD packets (based on the seq #). > > How would it know which end was misbehaving? Was it a delay at the > > TX side, or was it the RX that delayed passing the packets to the > > BFD process(or). This is usually what we want to debug and i want to > > understand how this draft with sequence numbers can unequivocally > > tell me that. > > > > I believe the work is important and addresses something thats really > > required (spent too much time debugging why BFD flapped!). Clearly > > what would help is putting a small section that describes how we can > > use the sequence numbers to debug what and where things went wrong. > > > > Cheers, Manav > > > > > > On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > wrote: > >> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in > >> Honolulu. The slides can be viewed here: > >> > >> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > >> > >> To attempt to simplify the presentation, the contentious portion of > >> the timers were removed from the proposal, leaving only the > >> sequence numbering for detecting loss of BFD async packets. > >> > >> When the room was polled to see whether the draft should be adopted > >> as a WG item, the sense of the room was very quiet. As promised, > >> this is to inquire for support for this draft on the WG mailing > >> list to make sure the whole group has a voice. > >> > >> It should be noted that post-meeting discussion on the fate of this > >> draft noted that BFD authentication code points are plentiful and > >> are available with expert review. Should the draft authors wish to > >> continue this work as Experimental, that is an option. > >> > >> -- Jeff > >> > > --_000_7347100B5761DC41A166AC17F22DF1121B898C13eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
are we turning BFD into 1588? It does seem like that by the extent of = our discussion of timestamping issue.
The PTP has two methods of measuring Resident Time, time a packet spen= t in a node (I feel that is what we're trying to measure by collecting time= stamps):
  • one-step - resident time measured on a packet and reported in the same = packet;
  • two-step - more elaborate as it requires source port identi= fication, sequence number and proper type of a packet. Residence time measu= red on one packet but reported in the follow-up of appropriate type.
    • Does that sounds like what we're discussing?
     
            Regards,
               &nbs= p;    Greg
     
    -----Original Message-----
    From: Rtg-bfd [mailto:rtg-bfd-b= ounces@ietf.org] On Behalf Of Mach Chen
    Sent: Wednesday, November 26, 2014 1:18 AM
    To: Marc Binderberger; Manav Bhatia
    Cc: rtg-bfd@ietf.org
    Subject: RE: BFD stability follow-up from IETF-91
     
    Hi Marc and Manav,
     
    > -----Original Message-----
    > From: Rtg-bfd [mailto= :rtg-bfd-bounces@ietf.org] On Behalf Of Marc
    > Binderberger
    > Sent: Wednesday, November 26, 2014 4:50 PM
    > To: Manav Bhatia
    > Cc: rtg-bfd@ietf.org
    > Subject: Re: BFD stability follow-up from IETF-91
    >
    > Hello Manav,
    >
    > > I believe the work is important and addresses something that= s really
    > > required (spent too much time debugging why BFD flapped!).
    >
    > agree :-) we should keep the discussion alive.
    >
    >
    > > side Time stamping would have helped in debugging whether th= e BFD
    > > packet was sent late, or whether the packet was sent on time= and
    > > also arrived on time but was delayed when passing it up the = BFD
    > > stack/processor (lay in the RX buffer for tad too long)
    >
    > well, I can see a point in having the Tx timestamps in the packet=
    > mainly for the purpose of knowing "this" packet was oka= y/not okay on
    > the Tx side and to correlate it with your local Rx measurement.
     
    Yes, this is one solution if people think BFD delay is needed. If allo= w to have Tx timestamps to be carried in the packets, seems it should be no= problem to leave a seat for the Rx timestamps as well :-). After all, with= both Tx and Rx timestamp, it may simplify the implementation.
     
    >
    > And even this point is less relevant with sequence numbers as thi= s
    > number allows the identification of packets and thus the correlat= ion
    > of information from the Tx and Rx system.
     
    Indeed, the sequence number helps a lot for the correlation between th= e Tx and Rx system.
     
    This triggers me think out there should be another solution for gettin= g the Tx and Rx timestamps without encoding the timestamps in the BFD packe= ts. For example, the Tx and Rx systems could just save timestamps locally o= r send them to a centralized entity and then use the sequence numbers to correlate them for further analyzing.<= /div>
     
    Best regards,
    Mach
     
    >
    >
    > Regards, Marc
    >
    >
    >
    >
    >
    >
    > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote:
    > > Hi Jeff,
    > >
    > > I vividly remember the original intent of the stability draf= t was to
    > > help debug BFD failures -- to isolate the issue at the RX or= the TX
    > > side Time stamping would have helped in debugging whether th= e BFD
    > > packet was sent late, or whether the packet was sent on time= and
    > > also arrived on time but was delayed when passing it up the = BFD
    > > stack/processor (lay in the RX buffer for tad too long), etc= . But
    > > then time stamping came with its own set of issues, and was = hence
    > > dropped from the original draft.
    > >
    > > Can the authors send a summary on the list on why time stamp= ing was
    > > dropped so that we're all clear on that one.
    > >
    > > The current proposal does help but is not complete.
    > >
    > > Assume that the RX end loses a BFD session and learns later = that it
    > > did eventually receive the missing BFD packets (based on the= seq #).
    > > How would it know which end was misbehaving? Was it a delay = at the
    > > TX side, or was it the RX that delayed passing the packets t= o the
    > > BFD process(or). This is usually what we want to debug and i= want to
    > > understand how this draft with sequence numbers can unequivo= cally
    > > tell me that.
    > >
    > > I believe the work is important and addresses something that= s really
    > > required (spent too much time debugging why BFD flapped!). C= learly
    > > what would help is putting a small section that describes ho= w we can
    > > use the sequence numbers to debug what and where things went= wrong.
    > >
    > > Cheers, Manav
    > >
    > >
    > > On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
    > >> draft-ashesh-bfd-stability-01 was presented again during= IETF-91 in
    > >> Honolulu.  The slides can be viewed here:
    > >>
    > >>
    > >> To attempt to simplify the presentation, the contentious= portion of
    > >> the timers were removed from the proposal, leaving only = the
    > >> sequence numbering for detecting loss of BFD async packe= ts.
    > >>
    > >> When the room was polled to see whether the draft should= be adopted
    > >> as a WG item, the sense of the room was very quiet. = ; As promised,
    > >> this is to inquire for support for this draft on the WG = mailing
    > >> list to make sure the whole group has a voice.
    > >>
    > >> It should be noted that post-meeting discussion on the f= ate of this
    > >> draft noted that BFD authentication code points are plen= tiful and
    > >> are available with expert review.  Should the draft= authors wish to
    > >> continue this work as Experimental, that is an option.
    > >>
    > >> -- Jeff
    > >>
    > >
     
     
     --_000_7347100B5761DC41A166AC17F22DF1121B898C13eusaamb103erics_-- From nobody Wed Nov 26 12:14: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 225011A1B32 for ; Wed, 26 Nov 2014 12:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yF27iOgsTQYj for ; Wed, 26 Nov 2014 12:14:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624D01A19ED for ; Wed, 26 Nov 2014 12:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=793; q=dns/txt; s=iport; t=1417032878; x=1418242478; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gSsittZ8ZxNwcgM0oQ/ex/PFBPUszlGqaNGVd9mFop0=; b=NwIFps7zoowBO1blmITv1ikuIh21493Y4KsornMbsA+zkoJ8dTMJE1/f qKVMpQZEWBXZy3ibfneuS8Vv0CW03leIn5ac9+pJ8s/09G33lYo69mMg5 HwaMNRT44O9DC4sIfTlq78AEAa0MfG6Ia9ck/hDshTyMw+sRcptLQdrZH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGczdlStJV2Z/2dsb2JhbABbgmMjUlcExWOCN4ZNAoEQFgEBAQEBfYQCAQEBBIEFBAIBCA4DAwECLzIdCAIEARKIQAEM0mABAQEBAQUBAQEBAQEckEg6BoRHBYtohFGCLIRnhzWBdJUog3x3AYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,464,1413244800"; d="scan'208";a="375558776" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Nov 2014 20:14:37 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sAQKEbOG000544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 20:14:37 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 14:14:37 -0600 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: BFD Wiki updated Thread-Topic: BFD Wiki updated Thread-Index: AQHQCaIT63HhhUUUsE6SKFHtKjpxP5xzaK8A Date: Wed, 26 Nov 2014 20:14:36 +0000 Message-ID: References: <20141126175417.GD568@pfrc> In-Reply-To: <20141126175417.GD568@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.82.232.56] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A6FFFB1CD5D3D42B49040BA9D9A6A0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/vol6OljijJA_dUJFaH9t5egQC-o 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, 26 Nov 2014 20:14:40 -0000 Jeff, -----Original Message----- From: Jeff Haas Date: Wednesday, November 26, 2014 at 12:54 PM To: "rtg-bfd@ietf.org" Subject: BFD Wiki updated >http://wiki.tools.ietf.org/wg/bfd/trac/wiki/WikiStart > >The BFD wiki page has been updated with current status as seen by the WG >chairs. The Yang design team stuff needs to be filled out a bit more, but >that coordination may go via the overall RTG area yang coordination page. What does it mean (in practice) that coordination may go via RtgYangCoord? I=B9d suggest that a first vector of coordination and alignment for BFD Yan= g models would be LIME , which will kick off a design team very soon. Thanks, Carlos. > >-- Jeff > From nobody Wed Nov 26 15:21:11 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 C8D791A87A0 for ; Wed, 26 Nov 2014 15:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEDHcomHxwEI for ; Wed, 26 Nov 2014 15:21:06 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D46DD1A8785 for ; Wed, 26 Nov 2014 15:21:06 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 83C09C193; Wed, 26 Nov 2014 18:21:06 -0500 (EST) Date: Wed, 26 Nov 2014 18:21:06 -0500 From: Jeffrey Haas To: "Carlos Pignataro (cpignata)" Subject: Re: BFD Wiki updated Message-ID: <20141126232106.GE568@pfrc> References: <20141126175417.GD568@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/0VtR1H_x713TLBJP2E9_4QqgtPI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:21:08 -0000 Carlos, On Wed, Nov 26, 2014 at 08:14:36PM +0000, Carlos Pignataro (cpignata) wrote: > >The BFD wiki page has been updated with current status as seen by the WG > >chairs. The Yang design team stuff needs to be filled out a bit more, but > >that coordination may go via the overall RTG area yang coordination page. > > What does it mean (in practice) that coordination may go via RtgYangCoord? > I?d suggest that a first vector of coordination and alignment for BFD Yang > models would be LIME , which > will kick off a design team very soon. LIME and BFD will obviously end up coordinating in the end - at least if we manage to convince ourselves that LIME covers BFD appropriately. But even so, I'll keep pressuring everyone (in all WG) to coordinate through the wiki and the rtg-yang-coord mailing list. Even this early in the Yang efforts and it's pretty clear that many people are inventing the same wheels. :-) -- Jeff From nobody Wed Nov 26 15:32:24 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 BB8371A878C for ; Wed, 26 Nov 2014 15:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usJg-1fBLDgs for ; Wed, 26 Nov 2014 15:32:12 -0800 (PST) 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 4456D1A879E for ; Wed, 26 Nov 2014 15:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1821; q=dns/txt; s=iport; t=1417044734; x=1418254334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b+msTDaszRUDZ4HhLjlgW1WeOBiH51wAbHF5V7NUK4M=; b=WtTv44RE99fnEd+/ku8PUkCb2nygCBM+0MpEynt3ZLcvnnhMMKlrDiKN Y8BvA5lysSkqqCflBEW6FrhhQiqkhmRNsdDon4C0aBfbCJzi6Os2KkyI+ nXCAbRMBU4wnjUDIc2cDmhgPckahma6ObAxpZU918dSfaT+01Jv22dtea o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFALpidlStJA2G/2dsb2JhbABbgmMjUlfFZ4I3hk0CgQ0WAQEBAQF9hAIBAQEDATo0CwULAgEIDgoeEDIlAgQOBYg3CQEM0lUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkEgzB4MugR8FkDmCLIRnhzWBNT+DGpIOg3x3gkoBAQE X-IronPort-AV: E=Sophos;i="5.07,465,1413244800"; d="scan'208";a="375664754" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP; 26 Nov 2014 23:32:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAQNW54K001379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Nov 2014 23:32:05 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 17:32:05 -0600 From: "Carlos Pignataro (cpignata)" To: Jeffrey Haas Subject: Re: BFD Wiki updated Thread-Topic: BFD Wiki updated Thread-Index: AQHQCaIT63HhhUUUsE6SKFHtKjpxP5xzaK8AgACH8AD//558Xw== Date: Wed, 26 Nov 2014 23:32:05 +0000 Message-ID: <73E8CC11-CD0C-4632-983D-9F0F498FE1D1@cisco.com> References: <20141126175417.GD568@pfrc> ,<20141126232106.GE568@pfrc> In-Reply-To: <20141126232106.GE568@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/evRD-CIlzJuBq6zp5ULReFwlpaA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:32:15 -0000 Jeff, Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Nov 26, 2014, at 6:21 PM, Jeffrey Haas wrote: >=20 > Carlos, >=20 > On Wed, Nov 26, 2014 at 08:14:36PM +0000, Carlos Pignataro (cpignata) wro= te: >>> The BFD wiki page has been updated with current status as seen by the W= G >>> chairs. The Yang design team stuff needs to be filled out a bit more, = but >>> that coordination may go via the overall RTG area yang coordination pag= e. >>=20 >> What does it mean (in practice) that coordination may go via RtgYangCoor= d? >> I?d suggest that a first vector of coordination and alignment for BFD Ya= ng >> models would be LIME , whi= ch >> will kick off a design team very soon. >=20 > LIME and BFD will obviously end up coordinating in the end - My point is that I'd rather we have this coordination in the beginning and = not in the end.=20 > at least if we > manage to convince ourselves that LIME covers BFD appropriately. =20 >=20 Or better -- contribute to the LIME effort to ensure (and not hope) that th= is happens. I do see this starting to happen already, but I too sense brittleness in mu= lti degree coordination.=20 > But even so, I'll keep pressuring everyone (in all WG) to coordinate thro= ugh > the wiki and the rtg-yang-coord mailing list. =20 I completely agree with this. > Even this early in the Yang > efforts and it's pretty clear that many people are inventing the same > wheels. :-) Indeed! My point is that we should not reinvent an oam protocol yang model = (like BFD's) that cannot use the generic yang oam model (from LIME) -- as t= hat would be preventable wheel re-inventing.=20 -- Carlos.=20 >=20 > -- Jeff From nobody Wed Nov 26 15:42:40 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 DAC9B1A8829 for ; Wed, 26 Nov 2014 15:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 a4fKVR9tPd6A for ; Wed, 26 Nov 2014 15:42:36 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7021A87EC for ; Wed, 26 Nov 2014 15:42:35 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id uz6so3004003obc.30 for ; Wed, 26 Nov 2014 15:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lwOF/uXV9ntuanqECle2qW4a2HB2JBv5Rg5/AjxUqTI=; b=SeR8wtM2raIgpvaovd7/8P7MlcsOwrYDtA1Gocskhcg9A7iodiboKt3jubZYEXF7lP al244spVPfzILEx2AQ3DcpI400lAEedp1VoZTozRYxX65XLxMHQ9oEt8nj0MZS9L4Lr3 vZAHTEH3yswURh0Zkp23yv1z+j93QBcbUzHArJNSAEu3wd44s7XJVgKDJeqrDcn/5tAW QVdlsnbLI6jQD3+IA/D3mIKJXIgPJK6UHq//U32ogPdwEFg6I188o0KipN4/4jBJa3mk LvPbj9NdP5TXHTC1x9Qd503IOEayLunXWp0PYqqYiMy6IpM2NYnEmmsRYNBpya3BjQ1W SQvA== MIME-Version: 1.0 X-Received: by 10.60.67.165 with SMTP id o5mr22345242oet.24.1417045355155; Wed, 26 Nov 2014 15:42:35 -0800 (PST) Received: by 10.76.178.199 with HTTP; Wed, 26 Nov 2014 15:42:35 -0800 (PST) In-Reply-To: <20141126005023981392.0c488535@sniff.de> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> Date: Thu, 27 Nov 2014 05:12:35 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Marc Binderberger Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5R6B2bcjXjUzZgNCZExg7bzzKqQ Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 23:42:38 -0000 Hi Marc, (and we meet again! :-)) My claim is that just using sequence numbers may NOT help. A BFD session with an interval of 33ms on router A will flap if it does not see any BFD packet for 100ms. Assume that the last seq number that A sees from the remote end is, say 100. A will bring down the BFD session if it now does not see 101, 102 and 103 in the next 100ms. Further assume that these packets were not seen by A and the session flaps. However, we get these 3 BFD packets immediately after this flap -- at 100ms + some_delta. Now given just the sequence numbers its almost impossible for A to know whether the issue was at the RX or the TX side. Am i missing something? Cheers, Manav On Wed, Nov 26, 2014 at 2:20 PM, Marc Binderberger wrote: > Hello Manav, > >> I believe the work is important and addresses something thats really >> required (spent too much time debugging why BFD flapped!). > > agree :-) we should keep the discussion alive. > > >> side Time stamping would have helped in debugging whether the BFD >> packet was sent late, or whether the packet was sent on time and also >> arrived on time but was delayed when passing it up the BFD >> stack/processor (lay in the RX buffer for tad too long) > > well, I can see a point in having the Tx timestamps in the packet mainly for > the purpose of knowing "this" packet was okay/not okay on the Tx side and to > correlate it with your local Rx measurement. > > And even this point is less relevant with sequence numbers as this number > allows the identification of packets and thus the correlation of information > from the Tx and Rx system. > > > Regards, Marc > > > > > > > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> Hi Jeff, >> >> I vividly remember the original intent of the stability draft was to >> help debug BFD failures -- to isolate the issue at the RX or the TX >> side Time stamping would have helped in debugging whether the BFD >> packet was sent late, or whether the packet was sent on time and also >> arrived on time but was delayed when passing it up the BFD >> stack/processor (lay in the RX buffer for tad too long), etc. But then >> time stamping came with its own set of issues, and was hence dropped >> from the original draft. >> >> Can the authors send a summary on the list on why time stamping was >> dropped so that we're all clear on that one. >> >> The current proposal does help but is not complete. >> >> Assume that the RX end loses a BFD session and learns later that it >> did eventually receive the missing BFD packets (based on the seq #). >> How would it know which end was misbehaving? Was it a delay at the TX >> side, or was it the RX that delayed passing the packets to the BFD >> process(or). This is usually what we want to debug and i want to >> understand how this draft with sequence numbers can unequivocally tell >> me that. >> >> I believe the work is important and addresses something thats really >> required (spent too much time debugging why BFD flapped!). Clearly >> what would help is putting a small section that describes how we can >> use the sequence numbers to debug what and where things went wrong. >> >> Cheers, Manav >> >> >> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: >>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in >>> Honolulu. The slides can be viewed here: >>> >>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >>> >>> To attempt to simplify the presentation, the contentious portion of the >>> timers were removed from the proposal, leaving only the sequence numbering >>> for detecting loss of BFD async packets. >>> >>> When the room was polled to see whether the draft should be adopted as a WG >>> item, the sense of the room was very quiet. As promised, this is to >>> inquire >>> for support for this draft on the WG mailing list to make sure the whole >>> group has a voice. >>> >>> It should be noted that post-meeting discussion on the fate of this draft >>> noted that BFD authentication code points are plentiful and are available >>> with expert review. Should the draft authors wish to continue this work as >>> Experimental, that is an option. >>> >>> -- Jeff >>> >> From nobody Thu Nov 27 00:43: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 0C9511A1B62 for ; Thu, 27 Nov 2014 00:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRn-Ct6QTnW7 for ; Thu, 27 Nov 2014 00:43:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632EA1A1BD9 for ; Thu, 27 Nov 2014 00:43:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMC21417; Thu, 27 Nov 2014 08:43:19 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Nov 2014 08:43:17 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.51]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 27 Nov 2014 16:43:13 +0800 From: Mach Chen To: Marc Binderberger Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6rAzFT2tE9mEytVJLqLOd+Cpxx9AmAgAAfxYCAAIivkIAADAsAgAEDoaA= Date: Thu, 27 Nov 2014 08:43:12 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> In-Reply-To: <20141126094242449051.c8abfe39@sniff.de> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/2QVEWGp-gUXcz7JIUWGJeOv5XhM 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, 27 Nov 2014 08:43:25 -0000 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Thursday, November 27, 2014 1:43 AM > To: Mach Chen > Cc: Manav Bhatia; rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Mach, >=20 > > This triggers me think out there should be another solution for > > getting the Tx and Rx timestamps without encoding the timestamps in the= BFD > packets. > > For example, the Tx and Rx systems could just save timestamps locally > > or send them to a centralized entity and then use the sequence numbers > > to correlate them for further analyzing. >=20 > I remember some discussion on NVO3 about how many bits it takes ;-) - cou= ld > you send the links/draft names you are working on to this list? May be us= eful for > further discussions. Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-coloring-= based-ipfpm-framework-02) for the reference. But here I want to say is that since we have sequence number, we may not ne= ed the marking based solution. Suppose that someone want to monitor the del= ay of a BFD packet , just record and save the timestamp at the Tx side, whi= ch indexed by the sequence number. Similarly, do the same at the Rx side. T= hen based on the timestamps from both Tx and Rx, and using the sequence num= ber to correlate the timestamps, it can also provide a way to monitor the d= elay of the BFD packet.=20 That means, only if there is sequence number, even if without carrying the = timestamp in the BFD packet, BFD packet delay can be measured.=20 Best regards, Mach >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 > On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > Hi Marc and Manav, > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc > >> Binderberger > >> Sent: Wednesday, November 26, 2014 4:50 PM > >> To: Manav Bhatia > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: BFD stability follow-up from IETF-91 > >> > >> Hello Manav, > >> > >>> I believe the work is important and addresses something thats really > >>> required (spent too much time debugging why BFD flapped!). > >> > >> agree :-) we should keep the discussion alive. > >> > >> > >>> side Time stamping would have helped in debugging whether the BFD > >>> packet was sent late, or whether the packet was sent on time and > >>> also arrived on time but was delayed when passing it up the BFD > >>> stack/processor (lay in the RX buffer for tad too long) > >> > >> well, I can see a point in having the Tx timestamps in the packet > >> mainly for the purpose of knowing "this" packet was okay/not okay on > >> the Tx side and to correlate it with your local Rx measurement. > > > > Yes, this is one solution if people think BFD delay is needed. If > > allow to have Tx timestamps to be carried in the packets, seems it > > should be no problem to leave a seat for the Rx timestamps as well > > :-). After all, with both Tx and Rx timestamp, it may simplify the > implementation. > > > >> > >> And even this point is less relevant with sequence numbers as this > >> number allows the identification of packets and thus the correlation > >> of information from the Tx and Rx system. > > > > Indeed, the sequence number helps a lot for the correlation between > > the Tx and Rx system. > > > > This triggers me think out there should be another solution for > > getting the Tx and Rx timestamps without encoding the timestamps in the= BFD > packets. > > For example, the Tx and Rx systems could just save timestamps locally > > or send them to a centralized entity and then use the sequence numbers > > to correlate them for further analyzing. > > > > Best regards, > > Mach > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> > >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > >>> Hi Jeff, > >>> > >>> I vividly remember the original intent of the stability draft was to > >>> help debug BFD failures -- to isolate the issue at the RX or the TX > >>> side Time stamping would have helped in debugging whether the BFD > >>> packet was sent late, or whether the packet was sent on time and > >>> also arrived on time but was delayed when passing it up the BFD > >>> stack/processor (lay in the RX buffer for tad too long), etc. But > >>> then time stamping came with its own set of issues, and was hence > >>> dropped from the original draft. > >>> > >>> Can the authors send a summary on the list on why time stamping was > >>> dropped so that we're all clear on that one. > >>> > >>> The current proposal does help but is not complete. > >>> > >>> Assume that the RX end loses a BFD session and learns later that it > >>> did eventually receive the missing BFD packets (based on the seq #). > >>> How would it know which end was misbehaving? Was it a delay at the > >>> TX side, or was it the RX that delayed passing the packets to the > >>> BFD process(or). This is usually what we want to debug and i want to > >>> understand how this draft with sequence numbers can unequivocally > >>> tell me that. > >>> > >>> I believe the work is important and addresses something thats really > >>> required (spent too much time debugging why BFD flapped!). Clearly > >>> what would help is putting a small section that describes how we can > >>> use the sequence numbers to debug what and where things went wrong. > >>> > >>> Cheers, Manav > >>> > >>> > >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: > >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in > >>>> Honolulu. The slides can be viewed here: > >>>> > >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > >>>> > >>>> To attempt to simplify the presentation, the contentious portion of > >>>> the timers were removed from the proposal, leaving only the > >>>> sequence numbering for detecting loss of BFD async packets. > >>>> > >>>> When the room was polled to see whether the draft should be adopted > >>>> as a WG item, the sense of the room was very quiet. As promised, > >>>> this is to inquire for support for this draft on the WG mailing > >>>> list to make sure the whole group has a voice. > >>>> > >>>> It should be noted that post-meeting discussion on the fate of this > >>>> draft noted that BFD authentication code points are plentiful and > >>>> are available with expert review. Should the draft authors wish to > >>>> continue this work as Experimental, that is an option. > >>>> > >>>> -- Jeff > >>>> > >>> > > From nobody Thu Nov 27 04:55:01 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 24B6D1A88ED for ; Thu, 27 Nov 2014 04:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaaCAqbwPhAU for ; Thu, 27 Nov 2014 04:54:55 -0800 (PST) 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 4788A1A88F2 for ; Thu, 27 Nov 2014 04:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3346; q=dns/txt; s=iport; t=1417092895; x=1418302495; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=owwOePqYQNawdpmxABjHrJsk/iVWS3lPcnli3x/6Csg=; b=jl/HEGEA+EOTwl/HEfbCL+pBcv8a838HBEuOn+9WGEafkvUn9gTJOwhk sgwOH8hCguXWHG+ArAnxKqlQtJM2rnUxpzrSbICIfO3EbFq1jP6lAu/pC 29etjC9syc3vTRDoogxNcXe0zasBEgzzKXG6PQtmr/RfiTPirRK7pRBI6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAHced1StJV2U/2dsb2JhbABbgwaBLcUYiHUCgQoWAQEBAQF9hAIBAQEEOjoFDAQCAQgRBAEBAQoUCQcyFAkIAgQBDQUIiDjSNgEBAQEBAQEBAQEBAQEBAQEBAQEBAReNL4J7AQEeBisHBoMogR8BBJJljVGDWYgRPIU3hAqCN4FFb4EPOYECAQEB X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="100659218" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 27 Nov 2014 12:54:54 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sARCssxG017431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Nov 2014 12:54:54 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 06:54:54 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Marc Binderberger , Jeffrey Haas Subject: RE: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Topic: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Thread-Index: AQHQCRLwLqZvDFdkwECOCg+XQQBjhZxy654AgAGBgEA= Date: Thu, 27 Nov 2014 12:54:53 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476B1A4@xmb-rcd-x15.cisco.com> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> In-Reply-To: <20141125234256188865.aafe8a3f@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.50] 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/cuJVEEPlB9tJrMhG4tD2w_m627M 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, 27 Nov 2014 12:54:57 -0000 Hello Marc, Thank you for the note, please see replies inline marked with GVP1>. I wou= ld be happy to discuss further comments you may have regarding the draft. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc Binderber= ger Sent: Wednesday, November 26, 2014 1:13 PM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends= December 12, 2014) Hello Jeff et al., hmm. I'm not against the adoption of this draft as a workgroup draft but - = and I hope I don't step on anybodies toes - the draft seems to be in an ear= ly stage. Nor can I see much of a discussion on this list about the topic. There are for sure some interesting aspects. If enough people consider the = BFD session removal as relevant for RFC5884 then we have a good reason as a= workgroup to move on. GVP1> The issue of BFD session removal at the egress is one of the issues t= hat the draft attempts to clarify. But more importantly clarifying the mech= anisms for establishing and maintaining multiple sessions per is= the main motivation. Please see next point as well. I have my doubts about the multiple session per as I don't see = how you tackle ECMP without multiple . In other words while section 2.= 1 may be a correct procedure for multiple BFD sessions I wonder what proble= m you try to solve? Maybe this needs more discussion. GVP1> There are no new problems that this draft attempts to solve. In parti= cular, no claim is made to solve the problem of connectivity/ fault monitor= ing for ECMP paths. However, the draft provides clarifies the mechanisms to= establish multiple sessions for the already specified in RFC588= 4. Some implementations assumed the presence of only one session per partly due to the notion that discriminators cannot be changed after a= session was established. This draft was an attempt at clarifying these (mi= s)understandings. Please note that the concept of establishing multiple se= ssions to (possibly) track non-congruent paths was outlined in RFC5884 itse= lf.=20 ---snip from RFC5884--- If there are multiple alternate paths from an ingress LSR to an egress LSR for an LDP IP FEC, LSP Ping traceroute MAY be used to determine each of these alternate paths. A BFD session SHOULD be established for each alternate path that is discovered. ---snip from RFC5884--- Long story short: while I can see this draft becoming a workgroup draft I=20 find the poll - well - premature. Regards, Marc =20 On Tue, 25 Nov 2014 19:50:02 -0500, Jeffrey Haas wrote: > Working Group, >=20 > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like = to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. >=20 > Please indicate your support or lack thereof to the mail list by=20 > December 12, 2014. =20 >=20 > Also, please supply feedback to the authors. I believe the perception of > this document is that it's very nearly complete and thus should have a sh= ort > lifetime prior to publication as an RFC. >=20 > -- Jeff & Nobo. >=20 From nobody Thu Nov 27 05:00:01 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 4A9081A88F4 for ; Thu, 27 Nov 2014 04:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ihgu-uq-8HP for ; Thu, 27 Nov 2014 04:59:55 -0800 (PST) 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 A972B1A88F3 for ; Thu, 27 Nov 2014 04:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7382; q=dns/txt; s=iport; t=1417093195; x=1418302795; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BUIgSJKLdxhXYkF+cto5sG6j+yulvIYp9Qb/jPoTFpQ=; b=GvrjOHlhYKWa/hJanK4GMO7O8PPVfSqXJ25Smg9S9dmxAMPAhJ3HXFTg CMRvKEw6ijxdHMRpPhI0XuC6OTql5sWtthIg/weDK+BrK+h4fl3Yrj53p y2N+IcBagx8UoJPMXhcmFe/2voDjQD93mJEBeK4jI/w/d0USDoYLyYHFv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FADIfd1StJA2J/2dsb2JhbABbgwZRXMUYgiqGSwKBChYBAQEBAX2EAgEBAQMBOi0EAwsMBAIBCBEEAQEBChQJBzIUCQgCBAENBQgBEogcCQ3SKgEBAQEBAQEBAQEBAQEBAQEBAQEBAReQSjEHBoMogR8FkCSCQYRniGo/hzKJbIQKg3xvAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,469,1413244800"; d="scan'208";a="100662277" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP; 27 Nov 2014 12:59:54 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sARCxs3b015904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Nov 2014 12:59:54 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 06:59:54 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Mach Chen , Marc Binderberger Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sIVMf6rgiwEKxHqHxEi4wkpxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQD//+KccA== Date: Thu, 27 Nov 2014 12:59:53 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.50] 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/YEOFv5YLB6Eb6Alvfa-FMoLhAMc 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, 27 Nov 2014 12:59:58 -0000 Hello Mach, Often (definitely more than once), we have felt the need to carry sequenc= e numbers in BFD packets for debugging packet losses/ delayed delivery etc.= This extension will increase the ease of debugging BFD flaps caused due to= delayed delivery, silent drops etc. Thanks Prasad -----Original Message----- From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen Sent: Thursday, November 27, 2014 2:13 PM To: Marc Binderberger Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Marc, > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Thursday, November 27, 2014 1:43 AM > To: Mach Chen > Cc: Manav Bhatia; rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 >=20 > Hello Mach, >=20 > > This triggers me think out there should be another solution for=20 > > getting the Tx and Rx timestamps without encoding the timestamps in=20 > > the BFD > packets. > > For example, the Tx and Rx systems could just save timestamps=20 > > locally or send them to a centralized entity and then use the=20 > > sequence numbers to correlate them for further analyzing. >=20 > I remember some discussion on NVO3 about how many bits it takes ;-) -=20 > could you send the links/draft names you are working on to this list?=20 > May be useful for further discussions. Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-coloring-= based-ipfpm-framework-02) for the reference. But here I want to say is that since we have sequence number, we may not ne= ed the marking based solution. Suppose that someone want to monitor the del= ay of a BFD packet , just record and save the timestamp at the Tx side, whi= ch indexed by the sequence number. Similarly, do the same at the Rx side. T= hen based on the timestamps from both Tx and Rx, and using the sequence num= ber to correlate the timestamps, it can also provide a way to monitor the d= elay of the BFD packet.=20 That means, only if there is sequence number, even if without carrying the = timestamp in the BFD packet, BFD packet delay can be measured.=20 Best regards, Mach >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 > On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > Hi Marc and Manav, > > > >> -----Original Message----- > >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc=20 > >> Binderberger > >> Sent: Wednesday, November 26, 2014 4:50 PM > >> To: Manav Bhatia > >> Cc: rtg-bfd@ietf.org > >> Subject: Re: BFD stability follow-up from IETF-91 > >> > >> Hello Manav, > >> > >>> I believe the work is important and addresses something thats=20 > >>> really required (spent too much time debugging why BFD flapped!). > >> > >> agree :-) we should keep the discussion alive. > >> > >> > >>> side Time stamping would have helped in debugging whether the BFD=20 > >>> packet was sent late, or whether the packet was sent on time and=20 > >>> also arrived on time but was delayed when passing it up the BFD=20 > >>> stack/processor (lay in the RX buffer for tad too long) > >> > >> well, I can see a point in having the Tx timestamps in the packet=20 > >> mainly for the purpose of knowing "this" packet was okay/not okay=20 > >> on the Tx side and to correlate it with your local Rx measurement. > > > > Yes, this is one solution if people think BFD delay is needed. If=20 > > allow to have Tx timestamps to be carried in the packets, seems it=20 > > should be no problem to leave a seat for the Rx timestamps as well=20 > > :-). After all, with both Tx and Rx timestamp, it may simplify the > implementation. > > > >> > >> And even this point is less relevant with sequence numbers as this=20 > >> number allows the identification of packets and thus the=20 > >> correlation of information from the Tx and Rx system. > > > > Indeed, the sequence number helps a lot for the correlation between=20 > > the Tx and Rx system. > > > > This triggers me think out there should be another solution for=20 > > getting the Tx and Rx timestamps without encoding the timestamps in=20 > > the BFD > packets. > > For example, the Tx and Rx systems could just save timestamps=20 > > locally or send them to a centralized entity and then use the=20 > > sequence numbers to correlate them for further analyzing. > > > > Best regards, > > Mach > > > >> > >> > >> Regards, Marc > >> > >> > >> > >> > >> > >> > >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > >>> Hi Jeff, > >>> > >>> I vividly remember the original intent of the stability draft was=20 > >>> to help debug BFD failures -- to isolate the issue at the RX or=20 > >>> the TX side Time stamping would have helped in debugging whether=20 > >>> the BFD packet was sent late, or whether the packet was sent on=20 > >>> time and also arrived on time but was delayed when passing it up=20 > >>> the BFD stack/processor (lay in the RX buffer for tad too long),=20 > >>> etc. But then time stamping came with its own set of issues, and=20 > >>> was hence dropped from the original draft. > >>> > >>> Can the authors send a summary on the list on why time stamping=20 > >>> was dropped so that we're all clear on that one. > >>> > >>> The current proposal does help but is not complete. > >>> > >>> Assume that the RX end loses a BFD session and learns later that=20 > >>> it did eventually receive the missing BFD packets (based on the seq #= ). > >>> How would it know which end was misbehaving? Was it a delay at the=20 > >>> TX side, or was it the RX that delayed passing the packets to the=20 > >>> BFD process(or). This is usually what we want to debug and i want=20 > >>> to understand how this draft with sequence numbers can=20 > >>> unequivocally tell me that. > >>> > >>> I believe the work is important and addresses something thats=20 > >>> really required (spent too much time debugging why BFD flapped!).=20 > >>> Clearly what would help is putting a small section that describes=20 > >>> how we can use the sequence numbers to debug what and where things we= nt wrong. > >>> > >>> Cheers, Manav > >>> > >>> > >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: > >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91=20 > >>>> in Honolulu. The slides can be viewed here: > >>>> > >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > >>>> > >>>> To attempt to simplify the presentation, the contentious portion=20 > >>>> of the timers were removed from the proposal, leaving only the=20 > >>>> sequence numbering for detecting loss of BFD async packets. > >>>> > >>>> When the room was polled to see whether the draft should be=20 > >>>> adopted as a WG item, the sense of the room was very quiet. As=20 > >>>> promised, this is to inquire for support for this draft on the WG=20 > >>>> mailing list to make sure the whole group has a voice. > >>>> > >>>> It should be noted that post-meeting discussion on the fate of=20 > >>>> this draft noted that BFD authentication code points are=20 > >>>> plentiful and are available with expert review. Should the draft=20 > >>>> authors wish to continue this work as Experimental, that is an optio= n. > >>>> > >>>> -- Jeff > >>>> > >>> > > From nobody Thu Nov 27 05:16: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 CAAA91A88F4 for ; Thu, 27 Nov 2014 05:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 rOnUduovCaXn for ; Thu, 27 Nov 2014 05:16:32 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D0F1A888D for ; Thu, 27 Nov 2014 05:16:31 -0800 (PST) Received: by mail-oi0-f43.google.com with SMTP id a3so3452329oib.2 for ; Thu, 27 Nov 2014 05:16:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fPoaM1rd+x7F2qK8Y757pKlkG0NXM7kS0GvywrS+i6Y=; b=qbsBYzkKVqh7TKqheGxTSgNDlQFrlgUQVZtDq0O08kMX+Yni7Q8dHLl4PcTLDZ9/y8 XBnO4E1gG3+uN1eMFsaO30EeGOEyPBpi/Jy7K15/498eWXD1oqFLZjdO/FlRd481icqf pU2lRPzKfj1hs+ZgA2u8NsTzVdeuZ8wXKtn6NyrQhy6ye1vOlpT9S80YMxGrt4nPydcf wLxoHeh7FmBoeKPuksNlhcMKv+8yesRLs+CWxCYRv8OkzpWpVxiyHgPbtCO8F7A9efPW rTRxFd92Rgfr0PNxHQmMgYPtrgdcrXf7b8ubPimphALeywPpLuCUpmMPYymXEOMdAd9N imag== MIME-Version: 1.0 X-Received: by 10.182.109.129 with SMTP id hs1mr22762416obb.74.1417094190975; Thu, 27 Nov 2014 05:16:30 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 27 Nov 2014 05:16:30 -0800 (PST) In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> Date: Thu, 27 Nov 2014 18:46:30 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: "Vengada Prasad Govindan (venggovi)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/A1WqKNdPzeeor6cbNGUXGVtF6dU 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, 27 Nov 2014 13:16:35 -0000 Hi Vengada, Let me at the outset say that i am in favor of such a draft. I think its an important and a useful work that should be taken up by the WG. However, i have issues in how it current stands. I think it needs a wee bit more polishing. > Often (definitely more than once), we have felt the need to carry seque= nce numbers in > BFD packets for debugging packet losses/ delayed delivery etc. This exten= sion will > increase the ease of debugging BFD flaps caused due to delayed delivery, = silent drops etc. There are ways to detect BFD drops but then those are implementation specific and i will refrain from going there. So i concede that it would help in packet losses. However i dont see this helping much in case of delayed delivery (please see my earlier email). Can the authors add some text on how this debugging mechanism would work if somebody employs BFD authentication? Cheers, Manav > Thanks > Prasad > > -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen > Sent: Thursday, November 27, 2014 2:13 PM > To: Marc Binderberger > Cc: rtg-bfd@ietf.org > Subject: RE: BFD stability follow-up from IETF-91 > > Hi Marc, > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Thursday, November 27, 2014 1:43 AM >> To: Mach Chen >> Cc: Manav Bhatia; rtg-bfd@ietf.org >> Subject: RE: BFD stability follow-up from IETF-91 >> >> Hello Mach, >> >> > This triggers me think out there should be another solution for >> > getting the Tx and Rx timestamps without encoding the timestamps in >> > the BFD >> packets. >> > For example, the Tx and Rx systems could just save timestamps >> > locally or send them to a centralized entity and then use the >> > sequence numbers to correlate them for further analyzing. >> >> I remember some discussion on NVO3 about how many bits it takes ;-) - >> could you send the links/draft names you are working on to this list? >> May be useful for further discussions. > > Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-colorin= g-based-ipfpm-framework-02) for the reference. > > But here I want to say is that since we have sequence number, we may not = need the marking based solution. Suppose that someone want to monitor the d= elay of a BFD packet , just record and save the timestamp at the Tx side, w= hich indexed by the sequence number. Similarly, do the same at the Rx side.= Then based on the timestamps from both Tx and Rx, and using the sequence n= umber to correlate the timestamps, it can also provide a way to monitor the= delay of the BFD packet. > > That means, only if there is sequence number, even if without carrying th= e timestamp in the BFD packet, BFD packet delay can be measured. > > Best regards, > Mach > >> >> >> Thanks & Regards, >> Marc >> >> >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >> > Hi Marc and Manav, >> > >> >> -----Original Message----- >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> >> Binderberger >> >> Sent: Wednesday, November 26, 2014 4:50 PM >> >> To: Manav Bhatia >> >> Cc: rtg-bfd@ietf.org >> >> Subject: Re: BFD stability follow-up from IETF-91 >> >> >> >> Hello Manav, >> >> >> >>> I believe the work is important and addresses something thats >> >>> really required (spent too much time debugging why BFD flapped!). >> >> >> >> agree :-) we should keep the discussion alive. >> >> >> >> >> >>> side Time stamping would have helped in debugging whether the BFD >> >>> packet was sent late, or whether the packet was sent on time and >> >>> also arrived on time but was delayed when passing it up the BFD >> >>> stack/processor (lay in the RX buffer for tad too long) >> >> >> >> well, I can see a point in having the Tx timestamps in the packet >> >> mainly for the purpose of knowing "this" packet was okay/not okay >> >> on the Tx side and to correlate it with your local Rx measurement. >> > >> > Yes, this is one solution if people think BFD delay is needed. If >> > allow to have Tx timestamps to be carried in the packets, seems it >> > should be no problem to leave a seat for the Rx timestamps as well >> > :-). After all, with both Tx and Rx timestamp, it may simplify the >> implementation. >> > >> >> >> >> And even this point is less relevant with sequence numbers as this >> >> number allows the identification of packets and thus the >> >> correlation of information from the Tx and Rx system. >> > >> > Indeed, the sequence number helps a lot for the correlation between >> > the Tx and Rx system. >> > >> > This triggers me think out there should be another solution for >> > getting the Tx and Rx timestamps without encoding the timestamps in >> > the BFD >> packets. >> > For example, the Tx and Rx systems could just save timestamps >> > locally or send them to a centralized entity and then use the >> > sequence numbers to correlate them for further analyzing. >> > >> > Best regards, >> > Mach >> > >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> >>> Hi Jeff, >> >>> >> >>> I vividly remember the original intent of the stability draft was >> >>> to help debug BFD failures -- to isolate the issue at the RX or >> >>> the TX side Time stamping would have helped in debugging whether >> >>> the BFD packet was sent late, or whether the packet was sent on >> >>> time and also arrived on time but was delayed when passing it up >> >>> the BFD stack/processor (lay in the RX buffer for tad too long), >> >>> etc. But then time stamping came with its own set of issues, and >> >>> was hence dropped from the original draft. >> >>> >> >>> Can the authors send a summary on the list on why time stamping >> >>> was dropped so that we're all clear on that one. >> >>> >> >>> The current proposal does help but is not complete. >> >>> >> >>> Assume that the RX end loses a BFD session and learns later that >> >>> it did eventually receive the missing BFD packets (based on the seq = #). >> >>> How would it know which end was misbehaving? Was it a delay at the >> >>> TX side, or was it the RX that delayed passing the packets to the >> >>> BFD process(or). This is usually what we want to debug and i want >> >>> to understand how this draft with sequence numbers can >> >>> unequivocally tell me that. >> >>> >> >>> I believe the work is important and addresses something thats >> >>> really required (spent too much time debugging why BFD flapped!). >> >>> Clearly what would help is putting a small section that describes >> >>> how we can use the sequence numbers to debug what and where things w= ent wrong. >> >>> >> >>> Cheers, Manav >> >>> >> >>> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote= : >> >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 >> >>>> in Honolulu. The slides can be viewed here: >> >>>> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >> >>>> >> >>>> To attempt to simplify the presentation, the contentious portion >> >>>> of the timers were removed from the proposal, leaving only the >> >>>> sequence numbering for detecting loss of BFD async packets. >> >>>> >> >>>> When the room was polled to see whether the draft should be >> >>>> adopted as a WG item, the sense of the room was very quiet. As >> >>>> promised, this is to inquire for support for this draft on the WG >> >>>> mailing list to make sure the whole group has a voice. >> >>>> >> >>>> It should be noted that post-meeting discussion on the fate of >> >>>> this draft noted that BFD authentication code points are >> >>>> plentiful and are available with expert review. Should the draft >> >>>> authors wish to continue this work as Experimental, that is an opti= on. >> >>>> >> >>>> -- Jeff >> >>>> >> >>> >> > > From nobody Thu Nov 27 05:23: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 5FD391A8906 for ; Thu, 27 Nov 2014 05:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ZWzYWiAznA-W for ; Thu, 27 Nov 2014 05:23:04 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A861A8909 for ; Thu, 27 Nov 2014 05:23:04 -0800 (PST) Received: by mail-oi0-f53.google.com with SMTP id x69so3354146oia.26 for ; Thu, 27 Nov 2014 05:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p0SV/jU7jEZrrisVr0vjQYidWncC5Xvw7+ZMAeEfSDk=; b=Uki9OkdjHWVBVLMP9ncGFSi8GY+UBfDK4+/Pbytyuf50jTiSAEo4dkPhjPCZxrBO3d P19RoZwfYUWQlf0W4yq6xWe0mOJi5h14doZhpOIcMekapl82dc0IgrAj4mBnlE3FpN7b HmSMWvzEhfCd4Udcez2b7yT+gZqB5aIm6OI/AElzXDso5x+EJIZ0M+JmXhh+Ou9Rzw+E WkmiI+4GH/6ONWyXFwVKtU7ftADk/P6nxvaf3AoSbt4tHy8+keBnM/ig9Wk3/+zTsd4u FcQqGvnQ6yfQsais/qKVxmz8D9vbKU4fQqBU4D1ttlnI5xQ5a3Jdjrmv+rdDm287Lk/0 cOYw== MIME-Version: 1.0 X-Received: by 10.182.94.204 with SMTP id de12mr23263368obb.82.1417094583727; Thu, 27 Nov 2014 05:23:03 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 27 Nov 2014 05:23:03 -0800 (PST) In-Reply-To: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> Date: Thu, 27 Nov 2014 18:53:03 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Mach Chen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OXSPGDYOHssbETtHY0t4WgGa8bM 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, 27 Nov 2014 13:23:07 -0000 Ok so this helps. Can the authors add this to the draft? Cheers, Manav On Thu, Nov 27, 2014 at 2:13 PM, Mach Chen wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Thursday, November 27, 2014 1:43 AM >> To: Mach Chen >> Cc: Manav Bhatia; rtg-bfd@ietf.org >> Subject: RE: BFD stability follow-up from IETF-91 >> >> Hello Mach, >> >> > This triggers me think out there should be another solution for >> > getting the Tx and Rx timestamps without encoding the timestamps in th= e BFD >> packets. >> > For example, the Tx and Rx systems could just save timestamps locally >> > or send them to a centralized entity and then use the sequence numbers >> > to correlate them for further analyzing. >> >> I remember some discussion on NVO3 about how many bits it takes ;-) - co= uld >> you send the links/draft names you are working on to this list? May be u= seful for >> further discussions. > > Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-colorin= g-based-ipfpm-framework-02) for the reference. > > But here I want to say is that since we have sequence number, we may not = need the marking based solution. Suppose that someone want to monitor the d= elay of a BFD packet , just record and save the timestamp at the Tx side, w= hich indexed by the sequence number. Similarly, do the same at the Rx side.= Then based on the timestamps from both Tx and Rx, and using the sequence n= umber to correlate the timestamps, it can also provide a way to monitor the= delay of the BFD packet. > > That means, only if there is sequence number, even if without carrying th= e timestamp in the BFD packet, BFD packet delay can be measured. > > Best regards, > Mach > >> >> >> Thanks & Regards, >> Marc >> >> >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >> > Hi Marc and Manav, >> > >> >> -----Original Message----- >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> >> Binderberger >> >> Sent: Wednesday, November 26, 2014 4:50 PM >> >> To: Manav Bhatia >> >> Cc: rtg-bfd@ietf.org >> >> Subject: Re: BFD stability follow-up from IETF-91 >> >> >> >> Hello Manav, >> >> >> >>> I believe the work is important and addresses something thats really >> >>> required (spent too much time debugging why BFD flapped!). >> >> >> >> agree :-) we should keep the discussion alive. >> >> >> >> >> >>> side Time stamping would have helped in debugging whether the BFD >> >>> packet was sent late, or whether the packet was sent on time and >> >>> also arrived on time but was delayed when passing it up the BFD >> >>> stack/processor (lay in the RX buffer for tad too long) >> >> >> >> well, I can see a point in having the Tx timestamps in the packet >> >> mainly for the purpose of knowing "this" packet was okay/not okay on >> >> the Tx side and to correlate it with your local Rx measurement. >> > >> > Yes, this is one solution if people think BFD delay is needed. If >> > allow to have Tx timestamps to be carried in the packets, seems it >> > should be no problem to leave a seat for the Rx timestamps as well >> > :-). After all, with both Tx and Rx timestamp, it may simplify the >> implementation. >> > >> >> >> >> And even this point is less relevant with sequence numbers as this >> >> number allows the identification of packets and thus the correlation >> >> of information from the Tx and Rx system. >> > >> > Indeed, the sequence number helps a lot for the correlation between >> > the Tx and Rx system. >> > >> > This triggers me think out there should be another solution for >> > getting the Tx and Rx timestamps without encoding the timestamps in th= e BFD >> packets. >> > For example, the Tx and Rx systems could just save timestamps locally >> > or send them to a centralized entity and then use the sequence numbers >> > to correlate them for further analyzing. >> > >> > Best regards, >> > Mach >> > >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> >>> Hi Jeff, >> >>> >> >>> I vividly remember the original intent of the stability draft was to >> >>> help debug BFD failures -- to isolate the issue at the RX or the TX >> >>> side Time stamping would have helped in debugging whether the BFD >> >>> packet was sent late, or whether the packet was sent on time and >> >>> also arrived on time but was delayed when passing it up the BFD >> >>> stack/processor (lay in the RX buffer for tad too long), etc. But >> >>> then time stamping came with its own set of issues, and was hence >> >>> dropped from the original draft. >> >>> >> >>> Can the authors send a summary on the list on why time stamping was >> >>> dropped so that we're all clear on that one. >> >>> >> >>> The current proposal does help but is not complete. >> >>> >> >>> Assume that the RX end loses a BFD session and learns later that it >> >>> did eventually receive the missing BFD packets (based on the seq #). >> >>> How would it know which end was misbehaving? Was it a delay at the >> >>> TX side, or was it the RX that delayed passing the packets to the >> >>> BFD process(or). This is usually what we want to debug and i want to >> >>> understand how this draft with sequence numbers can unequivocally >> >>> tell me that. >> >>> >> >>> I believe the work is important and addresses something thats really >> >>> required (spent too much time debugging why BFD flapped!). Clearly >> >>> what would help is putting a small section that describes how we can >> >>> use the sequence numbers to debug what and where things went wrong. >> >>> >> >>> Cheers, Manav >> >>> >> >>> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote= : >> >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in >> >>>> Honolulu. The slides can be viewed here: >> >>>> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >> >>>> >> >>>> To attempt to simplify the presentation, the contentious portion of >> >>>> the timers were removed from the proposal, leaving only the >> >>>> sequence numbering for detecting loss of BFD async packets. >> >>>> >> >>>> When the room was polled to see whether the draft should be adopted >> >>>> as a WG item, the sense of the room was very quiet. As promised, >> >>>> this is to inquire for support for this draft on the WG mailing >> >>>> list to make sure the whole group has a voice. >> >>>> >> >>>> It should be noted that post-meeting discussion on the fate of this >> >>>> draft noted that BFD authentication code points are plentiful and >> >>>> are available with expert review. Should the draft authors wish to >> >>>> continue this work as Experimental, that is an option. >> >>>> >> >>>> -- Jeff >> >>>> >> >>> >> > From nobody Thu Nov 27 06:49:54 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 7A7921A0016 for ; Thu, 27 Nov 2014 06:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgAh2Kfr0BzC for ; Thu, 27 Nov 2014 06:49:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7891A001B for ; Thu, 27 Nov 2014 06:49:51 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 14:49:27 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 14:49:27 +0000 From: Santosh P K To: Manav Bhatia , Jeffrey Haas Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAIUeXA= Date: Thu, 27 Nov 2014 14:49:26 +0000 Message-ID: <38e429b63b8f46aca4edd0fefaac1afd@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(24454002)(51704005)(86362001)(4396001)(31966008)(33646002)(122556002)(40100003)(20776003)(561944003)(64706001)(76576001)(66066001)(19580405001)(19580395003)(15202345003)(120916001)(107046002)(97736003)(105586002)(99396003)(101416001)(106356001)(106116001)(95666004)(99286002)(2656002)(87936001)(92566001)(15975445006)(77156002)(62966003)(108616004)(50986999)(21056001)(74316001)(54356999)(76176999)(46102003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/NvX4BkPMN0OwW7aNZs8-j1j__xo 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, 27 Nov 2014 14:49:53 -0000 TWFuYXYsDQogICBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYW5kIHNvcnJ5IGZvciBsYXRlIHJl c3BvbnNlLiBQbGVhc2Ugc2VlIGlubGluZS4gDQoNCj4gSSB2aXZpZGx5IHJlbWVtYmVyIHRoZSBv cmlnaW5hbCBpbnRlbnQgb2YgdGhlIHN0YWJpbGl0eSBkcmFmdCB3YXMgdG8gaGVscCBkZWJ1Zw0K PiBCRkQgZmFpbHVyZXMgLS0gdG8gaXNvbGF0ZSB0aGUgaXNzdWUgYXQgdGhlIFJYIG9yIHRoZSBU WCBzaWRlIFRpbWUgc3RhbXBpbmcNCj4gd291bGQgaGF2ZSBoZWxwZWQgaW4gZGVidWdnaW5nIHdo ZXRoZXIgdGhlIEJGRCBwYWNrZXQgd2FzIHNlbnQgbGF0ZSwgb3INCj4gd2hldGhlciB0aGUgcGFj a2V0IHdhcyBzZW50IG9uIHRpbWUgYW5kIGFsc28gYXJyaXZlZCBvbiB0aW1lIGJ1dCB3YXMNCj4g ZGVsYXllZCB3aGVuIHBhc3NpbmcgaXQgdXAgdGhlIEJGRCBzdGFjay9wcm9jZXNzb3IgKGxheSBp biB0aGUgUlggYnVmZmVyIGZvcg0KPiB0YWQgdG9vIGxvbmcpLCBldGMuIEJ1dCB0aGVuIHRpbWUg c3RhbXBpbmcgY2FtZSB3aXRoIGl0cyBvd24gc2V0IG9mIGlzc3VlcywNCj4gYW5kIHdhcyBoZW5j ZSBkcm9wcGVkIGZyb20gdGhlIG9yaWdpbmFsIGRyYWZ0Lg0KPiBDYW4gdGhlIGF1dGhvcnMgc2Vu ZCBhIHN1bW1hcnkgb24gdGhlIGxpc3Qgb24gd2h5IHRpbWUgc3RhbXBpbmcgd2FzDQo+IGRyb3Bw ZWQgc28gdGhhdCB3ZSdyZSBhbGwgY2xlYXIgb24gdGhhdCBvbmUuDQoNClRpbWVzdGFtcCB3aWxs ICBoZWxwIGJ1dCB0aGVyZSB3ZXJlIGNvbW1lbnRzIGFib3V0IEJGRCBzdGVwcGluZyBpbiB0byBv dGhlciBwcm90b2NvbHMgd2hpY2ggYXJlIGFscmVhZHkgZG9pbmcgaXQuIEFsc28gdGhlcmUgd2Vy ZSBjb21tZW50cyBhYm91dCB0aW1lc3RhbXBpbmcgZm9yIGFnZ3Jlc3NpdmUgcHJvdG9jb2wgbGlr ZSBCRkQgd291bGQgYmUgZmVhc2libGUuIFdlIGNhbiBtYWtlIHRpbWVzdGFtcGluZyBhcyBvcHRp b25hbCwgYnV0IHdlIHNob3VsZCBiZSBjYXJlZnVsIG5vdCBzdGVwIGluIHRvIG90aGVyIHByb3Rv Y29scz8NCg0KPiBUaGUgY3VycmVudCBwcm9wb3NhbCBkb2VzIGhlbHAgYnV0IGlzIG5vdCBjb21w bGV0ZS4NCg0KRm9yIGxvc3MgZGV0ZWN0aW9uIGl0IHdpbGwgaGVscCBidXQgbm90IGZvciBkZWxh eS4gSSBhZ3JlZS4gDQoNCj4gDQo+IEkgYmVsaWV2ZSB0aGUgd29yayBpcyBpbXBvcnRhbnQgYW5k IGFkZHJlc3NlcyBzb21ldGhpbmcgdGhhdHMgcmVhbGx5DQo+IHJlcXVpcmVkIChzcGVudCB0b28g bXVjaCB0aW1lIGRlYnVnZ2luZyB3aHkgQkZEIGZsYXBwZWQhKS4gQ2xlYXJseSB3aGF0DQo+IHdv dWxkIGhlbHAgaXMgcHV0dGluZyBhIHNtYWxsIHNlY3Rpb24gdGhhdCBkZXNjcmliZXMgaG93IHdl IGNhbiB1c2UgdGhlDQo+IHNlcXVlbmNlIG51bWJlcnMgdG8gZGVidWcgd2hhdCBhbmQgd2hlcmUg dGhpbmdzIHdlbnQgd3JvbmcuDQoNCkkgYWdyZWUsIHdlIGFyZSBwbGFubmluZyB0byBhZGQgdXNl IGNhc2UgYW5kIGFsc28gaG93IHdlIHNlcXVlbmNlIG51bWJlciBjYW4gYmUgdXNlZnVsLiANCg0K DQoNClRoYW5rcw0KU2FudG9zaCBQIEsNCg0KIA0KDQo+IE9uIFdlZCwgTm92IDI2LCAyMDE0IGF0 IDU6NDkgQU0sIEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+IHdyb3RlOg0KPiA+IGRyYWZ0 LWFzaGVzaC1iZmQtc3RhYmlsaXR5LTAxIHdhcyBwcmVzZW50ZWQgYWdhaW4gZHVyaW5nIElFVEYt OTEgaW4NCj4gPiBIb25vbHVsdS4gIFRoZSBzbGlkZXMgY2FuIGJlIHZpZXdlZCBoZXJlOg0KPiA+ DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MS9zbGlkZXMvc2xpZGVzLTkx LWJmZC00LnBwdHgNCj4gPg0KPiA+IFRvIGF0dGVtcHQgdG8gc2ltcGxpZnkgdGhlIHByZXNlbnRh dGlvbiwgdGhlIGNvbnRlbnRpb3VzIHBvcnRpb24gb2YNCj4gPiB0aGUgdGltZXJzIHdlcmUgcmVt b3ZlZCBmcm9tIHRoZSBwcm9wb3NhbCwgbGVhdmluZyBvbmx5IHRoZSBzZXF1ZW5jZQ0KPiA+IG51 bWJlcmluZyBmb3IgZGV0ZWN0aW5nIGxvc3Mgb2YgQkZEIGFzeW5jIHBhY2tldHMuDQo+ID4NCj4g PiBXaGVuIHRoZSByb29tIHdhcyBwb2xsZWQgdG8gc2VlIHdoZXRoZXIgdGhlIGRyYWZ0IHNob3Vs ZCBiZSBhZG9wdGVkIGFzDQo+ID4gYSBXRyBpdGVtLCB0aGUgc2Vuc2Ugb2YgdGhlIHJvb20gd2Fz IHZlcnkgcXVpZXQuICBBcyBwcm9taXNlZCwgdGhpcyBpcw0KPiA+IHRvIGlucXVpcmUgZm9yIHN1 cHBvcnQgZm9yIHRoaXMgZHJhZnQgb24gdGhlIFdHIG1haWxpbmcgbGlzdCB0byBtYWtlDQo+ID4g c3VyZSB0aGUgd2hvbGUgZ3JvdXAgaGFzIGEgdm9pY2UuDQo+ID4NCj4gPiBJdCBzaG91bGQgYmUg bm90ZWQgdGhhdCBwb3N0LW1lZXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGUgZmF0ZSBvZiB0aGlzDQo+ ID4gZHJhZnQgbm90ZWQgdGhhdCBCRkQgYXV0aGVudGljYXRpb24gY29kZSBwb2ludHMgYXJlIHBs ZW50aWZ1bCBhbmQgYXJlDQo+ID4gYXZhaWxhYmxlIHdpdGggZXhwZXJ0IHJldmlldy4gIFNob3Vs ZCB0aGUgZHJhZnQgYXV0aG9ycyB3aXNoIHRvDQo+ID4gY29udGludWUgdGhpcyB3b3JrIGFzIEV4 cGVyaW1lbnRhbCwgdGhhdCBpcyBhbiBvcHRpb24uDQo+ID4NCj4gPiAtLSBKZWZmDQo+ID4NCg0K From nobody Thu Nov 27 06:52:23 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 D631E1A0016 for ; Thu, 27 Nov 2014 06:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXQ1r1UX6n9I for ; Thu, 27 Nov 2014 06:52:19 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0129.outbound.protection.outlook.com [207.46.100.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E521A0011 for ; Thu, 27 Nov 2014 06:52:19 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 14:52:17 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 14:52:17 +0000 From: Santosh P K To: Mach Chen , Marc Binderberger , "Manav Bhatia" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAB742Q Date: Thu, 27 Nov 2014 14:52:17 +0000 Message-ID: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(24454002)(189002)(199003)(86362001)(107046002)(122556002)(40100003)(15202345003)(120916001)(105586002)(106356001)(106116001)(99396003)(15975445006)(87936001)(101416001)(2656002)(66066001)(31966008)(4396001)(561944003)(64706001)(19580395003)(19580405001)(20776003)(33646002)(21056001)(76576001)(108616004)(74316001)(97736003)(99286002)(77156002)(50986999)(62966003)(76176999)(54356999)(46102003)(95666004)(92566001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/do2dpQERzoi0oeLzJTJTzyXbBgA 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, 27 Nov 2014 14:52:22 -0000 Mach, Thanks for your comments. Please see inline.=20 >=20 > This triggers me think out there should be another solution for getting t= he Tx > and Rx timestamps without encoding the timestamps in the BFD packets. For > example, the Tx and Rx systems could just save timestamps locally or send > them to a centralized entity and then use the sequence numbers to correla= te > them for further analyzing. This will help but it won't really tell where was the delay right? And it l= ooks more like a implementation?=20 Thanks Santosh P K=20 > > > > > > Regards, Marc > > > > > > > > > > > > > > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > > Hi Jeff, > > > > > > I vividly remember the original intent of the stability draft was to > > > help debug BFD failures -- to isolate the issue at the RX or the TX > > > side Time stamping would have helped in debugging whether the BFD > > > packet was sent late, or whether the packet was sent on time and > > > also arrived on time but was delayed when passing it up the BFD > > > stack/processor (lay in the RX buffer for tad too long), etc. But > > > then time stamping came with its own set of issues, and was hence > > > dropped from the original draft. > > > > > > Can the authors send a summary on the list on why time stamping was > > > dropped so that we're all clear on that one. > > > > > > The current proposal does help but is not complete. > > > > > > Assume that the RX end loses a BFD session and learns later that it > > > did eventually receive the missing BFD packets (based on the seq #). > > > How would it know which end was misbehaving? Was it a delay at the > > > TX side, or was it the RX that delayed passing the packets to the > > > BFD process(or). This is usually what we want to debug and i want to > > > understand how this draft with sequence numbers can unequivocally > > > tell me that. > > > > > > I believe the work is important and addresses something thats really > > > required (spent too much time debugging why BFD flapped!). Clearly > > > what would help is putting a small section that describes how we can > > > use the sequence numbers to debug what and where things went > wrong. > > > > > > Cheers, Manav > > > > > > > > > On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas wrote: > > >> draft-ashesh-bfd-stability-01 was presented again during IETF-91 in > > >> Honolulu. The slides can be viewed here: > > >> > > >> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx > > >> > > >> To attempt to simplify the presentation, the contentious portion of > > >> the timers were removed from the proposal, leaving only the > > >> sequence numbering for detecting loss of BFD async packets. > > >> > > >> When the room was polled to see whether the draft should be adopted > > >> as a WG item, the sense of the room was very quiet. As promised, > > >> this is to inquire for support for this draft on the WG mailing > > >> list to make sure the whole group has a voice. > > >> > > >> It should be noted that post-meeting discussion on the fate of this > > >> draft noted that BFD authentication code points are plentiful and > > >> are available with expert review. Should the draft authors wish to > > >> continue this work as Experimental, that is an option. > > >> > > >> -- Jeff > > >> > > > From nobody Thu Nov 27 06:59: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 3F2521A0027 for ; Thu, 27 Nov 2014 06:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9B9guDw6oy6 for ; Thu, 27 Nov 2014 06:59:32 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C54B1A0025 for ; Thu, 27 Nov 2014 06:59:32 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 14:59:09 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 14:59:09 +0000 From: Santosh P K To: Manav Bhatia , Mach Chen Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAE4wgIAAGjBQ Date: Thu, 27 Nov 2014 14:59:08 +0000 Message-ID: <39e5a096e91046d9bfe58a64de42d9c5@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB823; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(24454002)(13464003)(51704005)(86362001)(4396001)(31966008)(33646002)(122556002)(40100003)(20776003)(561944003)(64706001)(76576001)(66066001)(19580405001)(19580395003)(15202345003)(120916001)(107046002)(97736003)(105586002)(99396003)(101416001)(106356001)(106116001)(95666004)(99286002)(2656002)(87936001)(92566001)(15975445006)(77156002)(62966003)(1720100001)(108616004)(50986999)(21056001)(74316001)(54356999)(76176999)(46102003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB823; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/jj3YenAV6gtKWr_E-PChY3Mv1Fg 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, 27 Nov 2014 14:59:35 -0000 TWFuYXYgYW5kIE1hY2gsDQogICAgVGhhbmtzIGEgbG90IGZvciByZWZlcmVuY2UgYW5kIGV4cGxh bmF0aW9uLiBTbyB3aXRoIHRoaXMgd2UgZG9u4oCZdCByZWFsbHkgbmVlZCB0aW1lIHN0YW1waW5n IHRvIGJlIGNhcnJpZWQgd2l0aCBpbiB0aGUgQkZEIHBhY2tldC4gIFllcywgd2UgY2FuIGFkZCB0 aGlzIHRleHQgaW4gdGhlIGRyYWZ0LiANCg0KVGhhbmtzDQpTYW50b3MgaCBQIEsgDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hbmF2IEJoYXRpYQ0KPiBTZW50OiBUaHVy c2RheSwgTm92ZW1iZXIgMjcsIDIwMTQgNjo1MyBQTQ0KPiBUbzogTWFjaCBDaGVuDQo+IENjOiBy dGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBm cm9tIElFVEYtOTENCj4gDQo+IE9rIHNvIHRoaXMgaGVscHMuIENhbiB0aGUgYXV0aG9ycyBhZGQg dGhpcyB0byB0aGUgZHJhZnQ/DQo+IA0KPiBDaGVlcnMsIE1hbmF2DQo+IA0KPiBPbiBUaHUsIE5v diAyNywgMjAxNCBhdCAyOjEzIFBNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWkuY29tPg0K PiB3cm90ZToNCj4gPiBIaSBNYXJjLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IE1hcmMgQmluZGVyYmVyZ2VyIFttYWlsdG86bWFyY0BzbmlmZi5kZV0N Cj4gPj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDI3LCAyMDE0IDE6NDMgQU0NCj4gPj4gVG86 IE1hY2ggQ2hlbg0KPiA+PiBDYzogTWFuYXYgQmhhdGlhOyBydGctYmZkQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4gPj4N Cj4gPj4gSGVsbG8gTWFjaCwNCj4gPj4NCj4gPj4gPiBUaGlzIHRyaWdnZXJzIG1lIHRoaW5rIG91 dCB0aGVyZSBzaG91bGQgYmUgYW5vdGhlciBzb2x1dGlvbiBmb3INCj4gPj4gPiBnZXR0aW5nIHRo ZSBUeCBhbmQgUnggdGltZXN0YW1wcyB3aXRob3V0IGVuY29kaW5nIHRoZSB0aW1lc3RhbXBzIGlu DQo+ID4+ID4gdGhlIEJGRA0KPiA+PiBwYWNrZXRzLg0KPiA+PiA+IEZvciBleGFtcGxlLCB0aGUg VHggYW5kIFJ4IHN5c3RlbXMgY291bGQganVzdCBzYXZlIHRpbWVzdGFtcHMNCj4gPj4gPiBsb2Nh bGx5IG9yIHNlbmQgdGhlbSB0byBhIGNlbnRyYWxpemVkIGVudGl0eSBhbmQgdGhlbiB1c2UgdGhl DQo+ID4+ID4gc2VxdWVuY2UgbnVtYmVycyB0byBjb3JyZWxhdGUgdGhlbSBmb3IgZnVydGhlciBh bmFseXppbmcuDQo+ID4+DQo+ID4+IEkgcmVtZW1iZXIgc29tZSBkaXNjdXNzaW9uIG9uIE5WTzMg YWJvdXQgaG93IG1hbnkgYml0cyBpdCB0YWtlcyA7LSkgLQ0KPiA+PiBjb3VsZCB5b3Ugc2VuZCB0 aGUgbGlua3MvZHJhZnQgbmFtZXMgeW91IGFyZSB3b3JraW5nIG9uIHRvIHRoaXMgbGlzdD8NCj4g Pj4gTWF5IGJlIHVzZWZ1bCBmb3IgZnVydGhlciBkaXNjdXNzaW9ucy4NCj4gPg0KPiA+IFN1cmUs IGhlcmUgaXMgdGhlIGxpbmsoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1p cHBtLWNvbG9yaW5nLQ0KPiBiYXNlZC1pcGZwbS1mcmFtZXdvcmstMDIpIGZvciB0aGUgcmVmZXJl bmNlLg0KPiA+DQo+ID4gQnV0IGhlcmUgSSB3YW50IHRvIHNheSBpcyB0aGF0IHNpbmNlIHdlIGhh dmUgc2VxdWVuY2UgbnVtYmVyLCB3ZSBtYXkgbm90DQo+IG5lZWQgdGhlIG1hcmtpbmcgYmFzZWQg c29sdXRpb24uIFN1cHBvc2UgdGhhdCBzb21lb25lIHdhbnQgdG8gbW9uaXRvcg0KPiB0aGUgZGVs YXkgb2YgYSBCRkQgcGFja2V0ICwganVzdCByZWNvcmQgYW5kIHNhdmUgdGhlIHRpbWVzdGFtcCBh dCB0aGUgVHggc2lkZSwNCj4gd2hpY2ggaW5kZXhlZCBieSB0aGUgc2VxdWVuY2UgbnVtYmVyLiBT aW1pbGFybHksIGRvIHRoZSBzYW1lIGF0IHRoZSBSeA0KPiBzaWRlLiBUaGVuIGJhc2VkIG9uIHRo ZSB0aW1lc3RhbXBzIGZyb20gYm90aCBUeCBhbmQgUngsIGFuZCB1c2luZyB0aGUNCj4gc2VxdWVu Y2UgbnVtYmVyIHRvIGNvcnJlbGF0ZSB0aGUgdGltZXN0YW1wcywgaXQgY2FuIGFsc28gcHJvdmlk ZSBhIHdheSB0bw0KPiBtb25pdG9yIHRoZSBkZWxheSBvZiB0aGUgQkZEIHBhY2tldC4NCj4gPg0K PiA+IFRoYXQgbWVhbnMsIG9ubHkgaWYgdGhlcmUgaXMgc2VxdWVuY2UgbnVtYmVyLCBldmVuIGlm IHdpdGhvdXQgY2FycnlpbmcgdGhlDQo+IHRpbWVzdGFtcCBpbiB0aGUgQkZEIHBhY2tldCwgQkZE IHBhY2tldCBkZWxheSBjYW4gYmUgbWVhc3VyZWQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ ID4gTWFjaA0KPiA+DQo+ID4+DQo+ID4+DQo+ID4+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4+IE1h cmMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gV2VkLCAyNiBOb3YgMjAxNCAwOToxNzozMiAr MDAwMCwgTWFjaCBDaGVuIHdyb3RlOg0KPiA+PiA+IEhpIE1hcmMgYW5kIE1hbmF2LA0KPiA+PiA+ DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IFJ0Zy1i ZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJjDQo+ ID4+ID4+IEJpbmRlcmJlcmdlcg0KPiA+PiA+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI2 LCAyMDE0IDQ6NTAgUE0NCj4gPj4gPj4gVG86IE1hbmF2IEJoYXRpYQ0KPiA+PiA+PiBDYzogcnRn LWJmZEBpZXRmLm9yZw0KPiA+PiA+PiBTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ct dXAgZnJvbSBJRVRGLTkxDQo+ID4+ID4+DQo+ID4+ID4+IEhlbGxvIE1hbmF2LA0KPiA+PiA+Pg0K PiA+PiA+Pj4gSSBiZWxpZXZlIHRoZSB3b3JrIGlzIGltcG9ydGFudCBhbmQgYWRkcmVzc2VzIHNv bWV0aGluZyB0aGF0cw0KPiA+PiA+Pj4gcmVhbGx5IHJlcXVpcmVkIChzcGVudCB0b28gbXVjaCB0 aW1lIGRlYnVnZ2luZyB3aHkgQkZEIGZsYXBwZWQhKS4NCj4gPj4gPj4NCj4gPj4gPj4gYWdyZWUg Oi0pIHdlIHNob3VsZCBrZWVwIHRoZSBkaXNjdXNzaW9uIGFsaXZlLg0KPiA+PiA+Pg0KPiA+PiA+ Pg0KPiA+PiA+Pj4gc2lkZSBUaW1lIHN0YW1waW5nIHdvdWxkIGhhdmUgaGVscGVkIGluIGRlYnVn Z2luZyB3aGV0aGVyIHRoZQ0KPiBCRkQNCj4gPj4gPj4+IHBhY2tldCB3YXMgc2VudCBsYXRlLCBv ciB3aGV0aGVyIHRoZSBwYWNrZXQgd2FzIHNlbnQgb24gdGltZSBhbmQNCj4gPj4gPj4+IGFsc28g YXJyaXZlZCBvbiB0aW1lIGJ1dCB3YXMgZGVsYXllZCB3aGVuIHBhc3NpbmcgaXQgdXAgdGhlIEJG RA0KPiA+PiA+Pj4gc3RhY2svcHJvY2Vzc29yIChsYXkgaW4gdGhlIFJYIGJ1ZmZlciBmb3IgdGFk IHRvbyBsb25nKQ0KPiA+PiA+Pg0KPiA+PiA+PiB3ZWxsLCBJIGNhbiBzZWUgYSBwb2ludCBpbiBo YXZpbmcgdGhlIFR4IHRpbWVzdGFtcHMgaW4gdGhlIHBhY2tldA0KPiA+PiA+PiBtYWlubHkgZm9y IHRoZSBwdXJwb3NlIG9mIGtub3dpbmcgInRoaXMiIHBhY2tldCB3YXMgb2theS9ub3Qgb2theQ0K PiA+PiA+PiBvbiB0aGUgVHggc2lkZSBhbmQgdG8gY29ycmVsYXRlIGl0IHdpdGggeW91ciBsb2Nh bCBSeCBtZWFzdXJlbWVudC4NCj4gPj4gPg0KPiA+PiA+IFllcywgdGhpcyBpcyBvbmUgc29sdXRp b24gaWYgcGVvcGxlIHRoaW5rIEJGRCBkZWxheSBpcyBuZWVkZWQuIElmDQo+ID4+ID4gYWxsb3cg dG8gaGF2ZSBUeCB0aW1lc3RhbXBzIHRvIGJlIGNhcnJpZWQgaW4gdGhlIHBhY2tldHMsIHNlZW1z IGl0DQo+ID4+ID4gc2hvdWxkIGJlIG5vIHByb2JsZW0gdG8gbGVhdmUgYSBzZWF0IGZvciB0aGUg UnggdGltZXN0YW1wcyBhcyB3ZWxsDQo+ID4+ID4gOi0pLiBBZnRlciBhbGwsIHdpdGggYm90aCBU eCBhbmQgUnggdGltZXN0YW1wLCBpdCBtYXkgc2ltcGxpZnkgdGhlDQo+ID4+IGltcGxlbWVudGF0 aW9uLg0KPiA+PiA+DQo+ID4+ID4+DQo+ID4+ID4+IEFuZCBldmVuIHRoaXMgcG9pbnQgaXMgbGVz cyByZWxldmFudCB3aXRoIHNlcXVlbmNlIG51bWJlcnMgYXMgdGhpcw0KPiA+PiA+PiBudW1iZXIg YWxsb3dzIHRoZSBpZGVudGlmaWNhdGlvbiBvZiBwYWNrZXRzIGFuZCB0aHVzIHRoZQ0KPiA+PiA+ PiBjb3JyZWxhdGlvbiBvZiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBUeCBhbmQgUnggc3lzdGVtLg0K PiA+PiA+DQo+ID4+ID4gSW5kZWVkLCB0aGUgc2VxdWVuY2UgbnVtYmVyIGhlbHBzIGEgbG90IGZv ciB0aGUgY29ycmVsYXRpb24gYmV0d2Vlbg0KPiA+PiA+IHRoZSBUeCBhbmQgUnggc3lzdGVtLg0K PiA+PiA+DQo+ID4+ID4gVGhpcyB0cmlnZ2VycyBtZSB0aGluayBvdXQgdGhlcmUgc2hvdWxkIGJl IGFub3RoZXIgc29sdXRpb24gZm9yDQo+ID4+ID4gZ2V0dGluZyB0aGUgVHggYW5kIFJ4IHRpbWVz dGFtcHMgd2l0aG91dCBlbmNvZGluZyB0aGUgdGltZXN0YW1wcyBpbg0KPiA+PiA+IHRoZSBCRkQN Cj4gPj4gcGFja2V0cy4NCj4gPj4gPiBGb3IgZXhhbXBsZSwgdGhlIFR4IGFuZCBSeCBzeXN0ZW1z IGNvdWxkIGp1c3Qgc2F2ZSB0aW1lc3RhbXBzDQo+ID4+ID4gbG9jYWxseSBvciBzZW5kIHRoZW0g dG8gYSBjZW50cmFsaXplZCBlbnRpdHkgYW5kIHRoZW4gdXNlIHRoZQ0KPiA+PiA+IHNlcXVlbmNl IG51bWJlcnMgdG8gY29ycmVsYXRlIHRoZW0gZm9yIGZ1cnRoZXIgYW5hbHl6aW5nLg0KPiA+PiA+ DQo+ID4+ID4gQmVzdCByZWdhcmRzLA0KPiA+PiA+IE1hY2gNCj4gPj4gPg0KPiA+PiA+Pg0KPiA+ PiA+Pg0KPiA+PiA+PiBSZWdhcmRzLCBNYXJjDQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+IE9uIFdlZCwgMjYgTm92IDIwMTQgMTI6 MjY6NDEgKzA1MzAsIE1hbmF2IEJoYXRpYSB3cm90ZToNCj4gPj4gPj4+IEhpIEplZmYsDQo+ID4+ ID4+Pg0KPiA+PiA+Pj4gSSB2aXZpZGx5IHJlbWVtYmVyIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2Yg dGhlIHN0YWJpbGl0eSBkcmFmdCB3YXMNCj4gPj4gPj4+IHRvIGhlbHAgZGVidWcgQkZEIGZhaWx1 cmVzIC0tIHRvIGlzb2xhdGUgdGhlIGlzc3VlIGF0IHRoZSBSWCBvcg0KPiA+PiA+Pj4gdGhlIFRY IHNpZGUgVGltZSBzdGFtcGluZyB3b3VsZCBoYXZlIGhlbHBlZCBpbiBkZWJ1Z2dpbmcgd2hldGhl cg0KPiA+PiA+Pj4gdGhlIEJGRCBwYWNrZXQgd2FzIHNlbnQgbGF0ZSwgb3Igd2hldGhlciB0aGUg cGFja2V0IHdhcyBzZW50IG9uDQo+ID4+ID4+PiB0aW1lIGFuZCBhbHNvIGFycml2ZWQgb24gdGlt ZSBidXQgd2FzIGRlbGF5ZWQgd2hlbiBwYXNzaW5nIGl0IHVwDQo+ID4+ID4+PiB0aGUgQkZEIHN0 YWNrL3Byb2Nlc3NvciAobGF5IGluIHRoZSBSWCBidWZmZXIgZm9yIHRhZCB0b28gbG9uZyksDQo+ ID4+ID4+PiBldGMuIEJ1dCB0aGVuIHRpbWUgc3RhbXBpbmcgY2FtZSB3aXRoIGl0cyBvd24gc2V0 IG9mIGlzc3VlcywgYW5kDQo+ID4+ID4+PiB3YXMgaGVuY2UgZHJvcHBlZCBmcm9tIHRoZSBvcmln aW5hbCBkcmFmdC4NCj4gPj4gPj4+DQo+ID4+ID4+PiBDYW4gdGhlIGF1dGhvcnMgc2VuZCBhIHN1 bW1hcnkgb24gdGhlIGxpc3Qgb24gd2h5IHRpbWUgc3RhbXBpbmcNCj4gPj4gPj4+IHdhcyBkcm9w cGVkIHNvIHRoYXQgd2UncmUgYWxsIGNsZWFyIG9uIHRoYXQgb25lLg0KPiA+PiA+Pj4NCj4gPj4g Pj4+IFRoZSBjdXJyZW50IHByb3Bvc2FsIGRvZXMgaGVscCBidXQgaXMgbm90IGNvbXBsZXRlLg0K PiA+PiA+Pj4NCj4gPj4gPj4+IEFzc3VtZSB0aGF0IHRoZSBSWCBlbmQgbG9zZXMgYSBCRkQgc2Vz c2lvbiBhbmQgbGVhcm5zIGxhdGVyIHRoYXQNCj4gPj4gPj4+IGl0IGRpZCBldmVudHVhbGx5IHJl Y2VpdmUgdGhlIG1pc3NpbmcgQkZEIHBhY2tldHMgKGJhc2VkIG9uIHRoZSBzZXENCj4gIykuDQo+ ID4+ID4+PiBIb3cgd291bGQgaXQga25vdyB3aGljaCBlbmQgd2FzIG1pc2JlaGF2aW5nPyBXYXMg aXQgYSBkZWxheSBhdA0KPiA+PiA+Pj4gdGhlIFRYIHNpZGUsIG9yIHdhcyBpdCB0aGUgUlggdGhh dCBkZWxheWVkIHBhc3NpbmcgdGhlIHBhY2tldHMgdG8NCj4gPj4gPj4+IHRoZSBCRkQgcHJvY2Vz cyhvcikuIFRoaXMgaXMgdXN1YWxseSB3aGF0IHdlIHdhbnQgdG8gZGVidWcgYW5kIGkNCj4gPj4g Pj4+IHdhbnQgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyBkcmFmdCB3aXRoIHNlcXVlbmNlIG51bWJl cnMgY2FuDQo+ID4+ID4+PiB1bmVxdWl2b2NhbGx5IHRlbGwgbWUgdGhhdC4NCj4gPj4gPj4+DQo+ ID4+ID4+PiBJIGJlbGlldmUgdGhlIHdvcmsgaXMgaW1wb3J0YW50IGFuZCBhZGRyZXNzZXMgc29t ZXRoaW5nIHRoYXRzDQo+ID4+ID4+PiByZWFsbHkgcmVxdWlyZWQgKHNwZW50IHRvbyBtdWNoIHRp bWUgZGVidWdnaW5nIHdoeSBCRkQgZmxhcHBlZCEpLg0KPiA+PiA+Pj4gQ2xlYXJseSB3aGF0IHdv dWxkIGhlbHAgaXMgcHV0dGluZyBhIHNtYWxsIHNlY3Rpb24gdGhhdCBkZXNjcmliZXMNCj4gPj4g Pj4+IGhvdyB3ZSBjYW4gdXNlIHRoZSBzZXF1ZW5jZSBudW1iZXJzIHRvIGRlYnVnIHdoYXQgYW5k IHdoZXJlDQo+IHRoaW5ncyB3ZW50IHdyb25nLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IENoZWVycywg TWFuYXYNCj4gPj4gPj4+DQo+ID4+ID4+Pg0KPiA+PiA+Pj4gT24gV2VkLCBOb3YgMjYsIDIwMTQg YXQgNTo0OSBBTSwgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4NCj4gd3JvdGU6DQo+ID4+ ID4+Pj4gZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxpdHktMDEgd2FzIHByZXNlbnRlZCBhZ2FpbiBk dXJpbmcgSUVURi05MQ0KPiA+PiA+Pj4+IGluIEhvbm9sdWx1LiAgVGhlIHNsaWRlcyBjYW4gYmUg dmlld2VkIGhlcmU6DQo+ID4+ID4+Pj4NCj4gPj4gPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMtOTEtYmZkLTQucHB0eA0KPiA+PiA+Pj4+DQo+ID4+ ID4+Pj4gVG8gYXR0ZW1wdCB0byBzaW1wbGlmeSB0aGUgcHJlc2VudGF0aW9uLCB0aGUgY29udGVu dGlvdXMgcG9ydGlvbg0KPiA+PiA+Pj4+IG9mIHRoZSB0aW1lcnMgd2VyZSByZW1vdmVkIGZyb20g dGhlIHByb3Bvc2FsLCBsZWF2aW5nIG9ubHkgdGhlDQo+ID4+ID4+Pj4gc2VxdWVuY2UgbnVtYmVy aW5nIGZvciBkZXRlY3RpbmcgbG9zcyBvZiBCRkQgYXN5bmMgcGFja2V0cy4NCj4gPj4gPj4+Pg0K PiA+PiA+Pj4+IFdoZW4gdGhlIHJvb20gd2FzIHBvbGxlZCB0byBzZWUgd2hldGhlciB0aGUgZHJh ZnQgc2hvdWxkIGJlDQo+ID4+ID4+Pj4gYWRvcHRlZCBhcyBhIFdHIGl0ZW0sIHRoZSBzZW5zZSBv ZiB0aGUgcm9vbSB3YXMgdmVyeSBxdWlldC4gIEFzDQo+ID4+ID4+Pj4gcHJvbWlzZWQsIHRoaXMg aXMgdG8gaW5xdWlyZSBmb3Igc3VwcG9ydCBmb3IgdGhpcyBkcmFmdCBvbiB0aGUNCj4gPj4gPj4+ PiBXRyBtYWlsaW5nIGxpc3QgdG8gbWFrZSBzdXJlIHRoZSB3aG9sZSBncm91cCBoYXMgYSB2b2lj ZS4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHBvc3QtbWVl dGluZyBkaXNjdXNzaW9uIG9uIHRoZSBmYXRlIG9mDQo+ID4+ID4+Pj4gdGhpcyBkcmFmdCBub3Rl ZCB0aGF0IEJGRCBhdXRoZW50aWNhdGlvbiBjb2RlIHBvaW50cyBhcmUNCj4gPj4gPj4+PiBwbGVu dGlmdWwgYW5kIGFyZSBhdmFpbGFibGUgd2l0aCBleHBlcnQgcmV2aWV3LiAgU2hvdWxkIHRoZQ0K PiA+PiA+Pj4+IGRyYWZ0IGF1dGhvcnMgd2lzaCB0byBjb250aW51ZSB0aGlzIHdvcmsgYXMgRXhw ZXJpbWVudGFsLCB0aGF0IGlzIGFuDQo+IG9wdGlvbi4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IC0t IEplZmYNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4NCj4gPj4gPg0KDQo= From nobody Thu Nov 27 07:02:46 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 A95DA1A0025 for ; Thu, 27 Nov 2014 07:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58qrPhAWubNh for ; Thu, 27 Nov 2014 07:02:42 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:766]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921C21A002B for ; Thu, 27 Nov 2014 07:02:41 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 15:02:18 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 15:02:18 +0000 From: Santosh P K To: Manav Bhatia , "Vengada Prasad Govindan (venggovi)" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuA= Date: Thu, 27 Nov 2014 15:02:17 +0000 Message-ID: <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(199003)(189002)(377454003)(51704005)(21056001)(20776003)(33646002)(74316001)(76576001)(108616004)(1720100001)(31966008)(561944003)(64706001)(19580405001)(19580395003)(4396001)(95666004)(46102003)(92566001)(76176999)(97736003)(62966003)(99286002)(77156002)(50986999)(54356999)(105586002)(120916001)(106356001)(106116001)(122556002)(86362001)(107046002)(15202345003)(40100003)(87936001)(2656002)(66066001)(101416001)(99396003)(15975445006)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/d0xX_FciYglOahbSzQpGeIpXTaE 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, 27 Nov 2014 15:02:44 -0000 TWFuYXYsDQogICAgVGhpcyBpcyBnb29kIHF1ZXN0aW9uLiANCg0KPiBDYW4gdGhlIGF1dGhvcnMg YWRkIHNvbWUgdGV4dCBvbiBob3cgdGhpcyBkZWJ1Z2dpbmcgbWVjaGFuaXNtIHdvdWxkDQo+IHdv cmsgaWYgc29tZWJvZHkgZW1wbG95cyBCRkQgYXV0aGVudGljYXRpb24/DQoNClJpZ2h0IG5vdyB3 ZSBoYXZlIGNvbnNpZGVyZWQgd2l0aG91dCBhdXRoZW50aWNhdGlvbiAod2UgYXJlIHNldHRpbmcg QSBiaXQpLiBXZSBzaG91bGQgYWRkIHNvbWUgdGV4dCBvbiBob3cgd2UgY2FuIHVzZSBib3RoIEF1 dGggYW5kIGRlIGJ1ZyBUTFYuIElzIHRoZXJlIGFueSBzdWdnZXN0aW9uIHlvdSBoYXZlPyBJIHdp bGwgZ2V0IGJhY2sgdG8geW91IG9uIHRoaXMuIA0KDQoNClRoYW5rcw0KU2FudG9zaCBQIEsNCg0K PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUnRnLWJmZCBbbWFpbHRv OnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hY2ggQ2hlbg0KPiA+IFNl bnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyNywgMjAxNCAyOjEzIFBNDQo+ID4gVG86IE1hcmMgQmlu ZGVyYmVyZ2VyDQo+ID4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSRTogQkZE IHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQo+ID4NCj4gPiBIaSBNYXJjLA0KPiA+ DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IE1hcmMgQmluZGVy YmVyZ2VyIFttYWlsdG86bWFyY0BzbmlmZi5kZV0NCj4gPj4gU2VudDogVGh1cnNkYXksIE5vdmVt YmVyIDI3LCAyMDE0IDE6NDMgQU0NCj4gPj4gVG86IE1hY2ggQ2hlbg0KPiA+PiBDYzogTWFuYXYg QmhhdGlhOyBydGctYmZkQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBCRkQgc3RhYmlsaXR5 IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4gPj4NCj4gPj4gSGVsbG8gTWFjaCwNCj4gPj4NCj4g Pj4gPiBUaGlzIHRyaWdnZXJzIG1lIHRoaW5rIG91dCB0aGVyZSBzaG91bGQgYmUgYW5vdGhlciBz b2x1dGlvbiBmb3INCj4gPj4gPiBnZXR0aW5nIHRoZSBUeCBhbmQgUnggdGltZXN0YW1wcyB3aXRo b3V0IGVuY29kaW5nIHRoZSB0aW1lc3RhbXBzIGluDQo+ID4+ID4gdGhlIEJGRA0KPiA+PiBwYWNr ZXRzLg0KPiA+PiA+IEZvciBleGFtcGxlLCB0aGUgVHggYW5kIFJ4IHN5c3RlbXMgY291bGQganVz dCBzYXZlIHRpbWVzdGFtcHMNCj4gPj4gPiBsb2NhbGx5IG9yIHNlbmQgdGhlbSB0byBhIGNlbnRy YWxpemVkIGVudGl0eSBhbmQgdGhlbiB1c2UgdGhlDQo+ID4+ID4gc2VxdWVuY2UgbnVtYmVycyB0 byBjb3JyZWxhdGUgdGhlbSBmb3IgZnVydGhlciBhbmFseXppbmcuDQo+ID4+DQo+ID4+IEkgcmVt ZW1iZXIgc29tZSBkaXNjdXNzaW9uIG9uIE5WTzMgYWJvdXQgaG93IG1hbnkgYml0cyBpdCB0YWtl cyA7LSkgLQ0KPiA+PiBjb3VsZCB5b3Ugc2VuZCB0aGUgbGlua3MvZHJhZnQgbmFtZXMgeW91IGFy ZSB3b3JraW5nIG9uIHRvIHRoaXMgbGlzdD8NCj4gPj4gTWF5IGJlIHVzZWZ1bCBmb3IgZnVydGhl ciBkaXNjdXNzaW9ucy4NCj4gPg0KPiA+IFN1cmUsIGhlcmUgaXMgdGhlIGxpbmsoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1pcHBtLWNvbG9yaW5nLQ0KPiBiYXNlZC1pcGZw bS1mcmFtZXdvcmstMDIpIGZvciB0aGUgcmVmZXJlbmNlLg0KPiA+DQo+ID4gQnV0IGhlcmUgSSB3 YW50IHRvIHNheSBpcyB0aGF0IHNpbmNlIHdlIGhhdmUgc2VxdWVuY2UgbnVtYmVyLCB3ZSBtYXkg bm90DQo+IG5lZWQgdGhlIG1hcmtpbmcgYmFzZWQgc29sdXRpb24uIFN1cHBvc2UgdGhhdCBzb21l b25lIHdhbnQgdG8gbW9uaXRvcg0KPiB0aGUgZGVsYXkgb2YgYSBCRkQgcGFja2V0ICwganVzdCBy ZWNvcmQgYW5kIHNhdmUgdGhlIHRpbWVzdGFtcCBhdCB0aGUgVHggc2lkZSwNCj4gd2hpY2ggaW5k ZXhlZCBieSB0aGUgc2VxdWVuY2UgbnVtYmVyLiBTaW1pbGFybHksIGRvIHRoZSBzYW1lIGF0IHRo ZSBSeA0KPiBzaWRlLiBUaGVuIGJhc2VkIG9uIHRoZSB0aW1lc3RhbXBzIGZyb20gYm90aCBUeCBh bmQgUngsIGFuZCB1c2luZyB0aGUNCj4gc2VxdWVuY2UgbnVtYmVyIHRvIGNvcnJlbGF0ZSB0aGUg dGltZXN0YW1wcywgaXQgY2FuIGFsc28gcHJvdmlkZSBhIHdheSB0bw0KPiBtb25pdG9yIHRoZSBk ZWxheSBvZiB0aGUgQkZEIHBhY2tldC4NCj4gPg0KPiA+IFRoYXQgbWVhbnMsIG9ubHkgaWYgdGhl cmUgaXMgc2VxdWVuY2UgbnVtYmVyLCBldmVuIGlmIHdpdGhvdXQgY2FycnlpbmcgdGhlDQo+IHRp bWVzdGFtcCBpbiB0aGUgQkZEIHBhY2tldCwgQkZEIHBhY2tldCBkZWxheSBjYW4gYmUgbWVhc3Vy ZWQuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gTWFjaA0KPiA+DQo+ID4+DQo+ID4+DQo+ ID4+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4+IE1hcmMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4g T24gV2VkLCAyNiBOb3YgMjAxNCAwOToxNzozMiArMDAwMCwgTWFjaCBDaGVuIHdyb3RlOg0KPiA+ PiA+IEhpIE1hcmMgYW5kIE1hbmF2LA0KPiA+PiA+DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJjDQo+ID4+ID4+IEJpbmRlcmJlcmdlcg0KPiA+PiA+ PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI2LCAyMDE0IDQ6NTAgUE0NCj4gPj4gPj4gVG86 IE1hbmF2IEJoYXRpYQ0KPiA+PiA+PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiA+PiA+PiBTdWJq ZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRGLTkxDQo+ID4+ID4+DQo+ ID4+ID4+IEhlbGxvIE1hbmF2LA0KPiA+PiA+Pg0KPiA+PiA+Pj4gSSBiZWxpZXZlIHRoZSB3b3Jr IGlzIGltcG9ydGFudCBhbmQgYWRkcmVzc2VzIHNvbWV0aGluZyB0aGF0cw0KPiA+PiA+Pj4gcmVh bGx5IHJlcXVpcmVkIChzcGVudCB0b28gbXVjaCB0aW1lIGRlYnVnZ2luZyB3aHkgQkZEIGZsYXBw ZWQhKS4NCj4gPj4gPj4NCj4gPj4gPj4gYWdyZWUgOi0pIHdlIHNob3VsZCBrZWVwIHRoZSBkaXNj dXNzaW9uIGFsaXZlLg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pj4gc2lkZSBUaW1lIHN0YW1w aW5nIHdvdWxkIGhhdmUgaGVscGVkIGluIGRlYnVnZ2luZyB3aGV0aGVyIHRoZQ0KPiBCRkQNCj4g Pj4gPj4+IHBhY2tldCB3YXMgc2VudCBsYXRlLCBvciB3aGV0aGVyIHRoZSBwYWNrZXQgd2FzIHNl bnQgb24gdGltZSBhbmQNCj4gPj4gPj4+IGFsc28gYXJyaXZlZCBvbiB0aW1lIGJ1dCB3YXMgZGVs YXllZCB3aGVuIHBhc3NpbmcgaXQgdXAgdGhlIEJGRA0KPiA+PiA+Pj4gc3RhY2svcHJvY2Vzc29y IChsYXkgaW4gdGhlIFJYIGJ1ZmZlciBmb3IgdGFkIHRvbyBsb25nKQ0KPiA+PiA+Pg0KPiA+PiA+ PiB3ZWxsLCBJIGNhbiBzZWUgYSBwb2ludCBpbiBoYXZpbmcgdGhlIFR4IHRpbWVzdGFtcHMgaW4g dGhlIHBhY2tldA0KPiA+PiA+PiBtYWlubHkgZm9yIHRoZSBwdXJwb3NlIG9mIGtub3dpbmcgInRo aXMiIHBhY2tldCB3YXMgb2theS9ub3Qgb2theQ0KPiA+PiA+PiBvbiB0aGUgVHggc2lkZSBhbmQg dG8gY29ycmVsYXRlIGl0IHdpdGggeW91ciBsb2NhbCBSeCBtZWFzdXJlbWVudC4NCj4gPj4gPg0K PiA+PiA+IFllcywgdGhpcyBpcyBvbmUgc29sdXRpb24gaWYgcGVvcGxlIHRoaW5rIEJGRCBkZWxh eSBpcyBuZWVkZWQuIElmDQo+ID4+ID4gYWxsb3cgdG8gaGF2ZSBUeCB0aW1lc3RhbXBzIHRvIGJl IGNhcnJpZWQgaW4gdGhlIHBhY2tldHMsIHNlZW1zIGl0DQo+ID4+ID4gc2hvdWxkIGJlIG5vIHBy b2JsZW0gdG8gbGVhdmUgYSBzZWF0IGZvciB0aGUgUnggdGltZXN0YW1wcyBhcyB3ZWxsDQo+ID4+ ID4gOi0pLiBBZnRlciBhbGwsIHdpdGggYm90aCBUeCBhbmQgUnggdGltZXN0YW1wLCBpdCBtYXkg c2ltcGxpZnkgdGhlDQo+ID4+IGltcGxlbWVudGF0aW9uLg0KPiA+PiA+DQo+ID4+ID4+DQo+ID4+ ID4+IEFuZCBldmVuIHRoaXMgcG9pbnQgaXMgbGVzcyByZWxldmFudCB3aXRoIHNlcXVlbmNlIG51 bWJlcnMgYXMgdGhpcw0KPiA+PiA+PiBudW1iZXIgYWxsb3dzIHRoZSBpZGVudGlmaWNhdGlvbiBv ZiBwYWNrZXRzIGFuZCB0aHVzIHRoZQ0KPiA+PiA+PiBjb3JyZWxhdGlvbiBvZiBpbmZvcm1hdGlv biBmcm9tIHRoZSBUeCBhbmQgUnggc3lzdGVtLg0KPiA+PiA+DQo+ID4+ID4gSW5kZWVkLCB0aGUg c2VxdWVuY2UgbnVtYmVyIGhlbHBzIGEgbG90IGZvciB0aGUgY29ycmVsYXRpb24gYmV0d2Vlbg0K PiA+PiA+IHRoZSBUeCBhbmQgUnggc3lzdGVtLg0KPiA+PiA+DQo+ID4+ID4gVGhpcyB0cmlnZ2Vy cyBtZSB0aGluayBvdXQgdGhlcmUgc2hvdWxkIGJlIGFub3RoZXIgc29sdXRpb24gZm9yDQo+ID4+ ID4gZ2V0dGluZyB0aGUgVHggYW5kIFJ4IHRpbWVzdGFtcHMgd2l0aG91dCBlbmNvZGluZyB0aGUg dGltZXN0YW1wcyBpbg0KPiA+PiA+IHRoZSBCRkQNCj4gPj4gcGFja2V0cy4NCj4gPj4gPiBGb3Ig ZXhhbXBsZSwgdGhlIFR4IGFuZCBSeCBzeXN0ZW1zIGNvdWxkIGp1c3Qgc2F2ZSB0aW1lc3RhbXBz DQo+ID4+ID4gbG9jYWxseSBvciBzZW5kIHRoZW0gdG8gYSBjZW50cmFsaXplZCBlbnRpdHkgYW5k IHRoZW4gdXNlIHRoZQ0KPiA+PiA+IHNlcXVlbmNlIG51bWJlcnMgdG8gY29ycmVsYXRlIHRoZW0g Zm9yIGZ1cnRoZXIgYW5hbHl6aW5nLg0KPiA+PiA+DQo+ID4+ID4gQmVzdCByZWdhcmRzLA0KPiA+ PiA+IE1hY2gNCj4gPj4gPg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBSZWdhcmRzLCBNYXJj DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ ID4+ID4+IE9uIFdlZCwgMjYgTm92IDIwMTQgMTI6MjY6NDEgKzA1MzAsIE1hbmF2IEJoYXRpYSB3 cm90ZToNCj4gPj4gPj4+IEhpIEplZmYsDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSSB2aXZpZGx5IHJl bWVtYmVyIHRoZSBvcmlnaW5hbCBpbnRlbnQgb2YgdGhlIHN0YWJpbGl0eSBkcmFmdCB3YXMNCj4g Pj4gPj4+IHRvIGhlbHAgZGVidWcgQkZEIGZhaWx1cmVzIC0tIHRvIGlzb2xhdGUgdGhlIGlzc3Vl IGF0IHRoZSBSWCBvcg0KPiA+PiA+Pj4gdGhlIFRYIHNpZGUgVGltZSBzdGFtcGluZyB3b3VsZCBo YXZlIGhlbHBlZCBpbiBkZWJ1Z2dpbmcgd2hldGhlcg0KPiA+PiA+Pj4gdGhlIEJGRCBwYWNrZXQg d2FzIHNlbnQgbGF0ZSwgb3Igd2hldGhlciB0aGUgcGFja2V0IHdhcyBzZW50IG9uDQo+ID4+ID4+ PiB0aW1lIGFuZCBhbHNvIGFycml2ZWQgb24gdGltZSBidXQgd2FzIGRlbGF5ZWQgd2hlbiBwYXNz aW5nIGl0IHVwDQo+ID4+ID4+PiB0aGUgQkZEIHN0YWNrL3Byb2Nlc3NvciAobGF5IGluIHRoZSBS WCBidWZmZXIgZm9yIHRhZCB0b28gbG9uZyksDQo+ID4+ID4+PiBldGMuIEJ1dCB0aGVuIHRpbWUg c3RhbXBpbmcgY2FtZSB3aXRoIGl0cyBvd24gc2V0IG9mIGlzc3VlcywgYW5kDQo+ID4+ID4+PiB3 YXMgaGVuY2UgZHJvcHBlZCBmcm9tIHRoZSBvcmlnaW5hbCBkcmFmdC4NCj4gPj4gPj4+DQo+ID4+ ID4+PiBDYW4gdGhlIGF1dGhvcnMgc2VuZCBhIHN1bW1hcnkgb24gdGhlIGxpc3Qgb24gd2h5IHRp bWUgc3RhbXBpbmcNCj4gPj4gPj4+IHdhcyBkcm9wcGVkIHNvIHRoYXQgd2UncmUgYWxsIGNsZWFy IG9uIHRoYXQgb25lLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IFRoZSBjdXJyZW50IHByb3Bvc2FsIGRv ZXMgaGVscCBidXQgaXMgbm90IGNvbXBsZXRlLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEFzc3VtZSB0 aGF0IHRoZSBSWCBlbmQgbG9zZXMgYSBCRkQgc2Vzc2lvbiBhbmQgbGVhcm5zIGxhdGVyIHRoYXQN Cj4gPj4gPj4+IGl0IGRpZCBldmVudHVhbGx5IHJlY2VpdmUgdGhlIG1pc3NpbmcgQkZEIHBhY2tl dHMgKGJhc2VkIG9uIHRoZSBzZXENCj4gIykuDQo+ID4+ID4+PiBIb3cgd291bGQgaXQga25vdyB3 aGljaCBlbmQgd2FzIG1pc2JlaGF2aW5nPyBXYXMgaXQgYSBkZWxheSBhdA0KPiA+PiA+Pj4gdGhl IFRYIHNpZGUsIG9yIHdhcyBpdCB0aGUgUlggdGhhdCBkZWxheWVkIHBhc3NpbmcgdGhlIHBhY2tl dHMgdG8NCj4gPj4gPj4+IHRoZSBCRkQgcHJvY2VzcyhvcikuIFRoaXMgaXMgdXN1YWxseSB3aGF0 IHdlIHdhbnQgdG8gZGVidWcgYW5kIGkNCj4gPj4gPj4+IHdhbnQgdG8gdW5kZXJzdGFuZCBob3cg dGhpcyBkcmFmdCB3aXRoIHNlcXVlbmNlIG51bWJlcnMgY2FuDQo+ID4+ID4+PiB1bmVxdWl2b2Nh bGx5IHRlbGwgbWUgdGhhdC4NCj4gPj4gPj4+DQo+ID4+ID4+PiBJIGJlbGlldmUgdGhlIHdvcmsg aXMgaW1wb3J0YW50IGFuZCBhZGRyZXNzZXMgc29tZXRoaW5nIHRoYXRzDQo+ID4+ID4+PiByZWFs bHkgcmVxdWlyZWQgKHNwZW50IHRvbyBtdWNoIHRpbWUgZGVidWdnaW5nIHdoeSBCRkQgZmxhcHBl ZCEpLg0KPiA+PiA+Pj4gQ2xlYXJseSB3aGF0IHdvdWxkIGhlbHAgaXMgcHV0dGluZyBhIHNtYWxs IHNlY3Rpb24gdGhhdCBkZXNjcmliZXMNCj4gPj4gPj4+IGhvdyB3ZSBjYW4gdXNlIHRoZSBzZXF1 ZW5jZSBudW1iZXJzIHRvIGRlYnVnIHdoYXQgYW5kIHdoZXJlDQo+IHRoaW5ncyB3ZW50IHdyb25n Lg0KPiA+PiA+Pj4NCj4gPj4gPj4+IENoZWVycywgTWFuYXYNCj4gPj4gPj4+DQo+ID4+ID4+Pg0K PiA+PiA+Pj4gT24gV2VkLCBOb3YgMjYsIDIwMTQgYXQgNTo0OSBBTSwgSmVmZnJleSBIYWFzIDxq aGFhc0BwZnJjLm9yZz4NCj4gd3JvdGU6DQo+ID4+ID4+Pj4gZHJhZnQtYXNoZXNoLWJmZC1zdGFi aWxpdHktMDEgd2FzIHByZXNlbnRlZCBhZ2FpbiBkdXJpbmcgSUVURi05MQ0KPiA+PiA+Pj4+IGlu IEhvbm9sdWx1LiAgVGhlIHNsaWRlcyBjYW4gYmUgdmlld2VkIGhlcmU6DQo+ID4+ID4+Pj4NCj4g Pj4gPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRlcy9zbGlkZXMt OTEtYmZkLTQucHB0eA0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gVG8gYXR0ZW1wdCB0byBzaW1wbGlm eSB0aGUgcHJlc2VudGF0aW9uLCB0aGUgY29udGVudGlvdXMgcG9ydGlvbg0KPiA+PiA+Pj4+IG9m IHRoZSB0aW1lcnMgd2VyZSByZW1vdmVkIGZyb20gdGhlIHByb3Bvc2FsLCBsZWF2aW5nIG9ubHkg dGhlDQo+ID4+ID4+Pj4gc2VxdWVuY2UgbnVtYmVyaW5nIGZvciBkZXRlY3RpbmcgbG9zcyBvZiBC RkQgYXN5bmMgcGFja2V0cy4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IFdoZW4gdGhlIHJvb20gd2Fz IHBvbGxlZCB0byBzZWUgd2hldGhlciB0aGUgZHJhZnQgc2hvdWxkIGJlDQo+ID4+ID4+Pj4gYWRv cHRlZCBhcyBhIFdHIGl0ZW0sIHRoZSBzZW5zZSBvZiB0aGUgcm9vbSB3YXMgdmVyeSBxdWlldC4g IEFzDQo+ID4+ID4+Pj4gcHJvbWlzZWQsIHRoaXMgaXMgdG8gaW5xdWlyZSBmb3Igc3VwcG9ydCBm b3IgdGhpcyBkcmFmdCBvbiB0aGUNCj4gPj4gPj4+PiBXRyBtYWlsaW5nIGxpc3QgdG8gbWFrZSBz dXJlIHRoZSB3aG9sZSBncm91cCBoYXMgYSB2b2ljZS4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IEl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IHBvc3QtbWVldGluZyBkaXNjdXNzaW9uIG9uIHRoZSBmYXRl IG9mDQo+ID4+ID4+Pj4gdGhpcyBkcmFmdCBub3RlZCB0aGF0IEJGRCBhdXRoZW50aWNhdGlvbiBj b2RlIHBvaW50cyBhcmUNCj4gPj4gPj4+PiBwbGVudGlmdWwgYW5kIGFyZSBhdmFpbGFibGUgd2l0 aCBleHBlcnQgcmV2aWV3LiAgU2hvdWxkIHRoZQ0KPiA+PiA+Pj4+IGRyYWZ0IGF1dGhvcnMgd2lz aCB0byBjb250aW51ZSB0aGlzIHdvcmsgYXMgRXhwZXJpbWVudGFsLCB0aGF0IGlzIGFuDQo+IG9w dGlvbi4NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+IC0tIEplZmYNCj4gPj4gPj4+Pg0KPiA+PiA+Pj4N Cj4gPj4gPg0KPiA+DQoNCg== From nobody Thu Nov 27 07:42:05 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 A779D1A0056 for ; Thu, 27 Nov 2014 07:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 j-_2um2I1TCK for ; Thu, 27 Nov 2014 07:42:01 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABB71A004B for ; Thu, 27 Nov 2014 07:42:01 -0800 (PST) Received: by mail-oi0-f44.google.com with SMTP id e131so3595717oig.3 for ; Thu, 27 Nov 2014 07:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=01E3hVxY/FOv58YwbAyaVQugUn9VWosHjAYjNybrq7M=; b=kZB8IS9FDyIVoJSM3yijfPVVyFj9Wj7UZuBMDm2DI9XlpcqLeBRuAvMwbjiH+5tjFV G9+VaU1L1vLJ1iMRbWYnaDOwqENfCYDJUYhQbsqBSNhyNR4axZF114/QyHATsrKgx0yz Rekmby1ryOav6VWS5FeCJqOAuKAUsGt+m8NVZtRwtCWqcAjq0LDC/dZ3b5C/XC//Yitm ivBusmxpycgzu2TLhLrNbeN+31Kh51x8wanfjEU5eKlhIghM/waeIDcnojvuf/hXoWPW N5nu8CtVW/MhEaoy8zaUdQSwb0xUcLYO8p5B6uhUb5YPF2octFbHXLXBLFhLMkb+Iq0/ WaoQ== MIME-Version: 1.0 X-Received: by 10.182.109.129 with SMTP id hs1mr23194581obb.74.1417102920261; Thu, 27 Nov 2014 07:42:00 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 27 Nov 2014 07:42:00 -0800 (PST) In-Reply-To: <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> Date: Thu, 27 Nov 2014 21:12:00 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Santosh P K Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/srkTD0tvZETqu2o_Zk-s6Tf2abg 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, 27 Nov 2014 15:42:03 -0000 Hi Santosh, You could use the crypto sequence numbers carried in the meticulous cryptographic auth for detecting packet losses. However, this breaks when you use non-meticulous crypto authentication since the sequence number is only incremented occasionally there. This i believe is a deal breaker since i really envision non meticulous mode to be the one being widely deployed. In fact we were supposed to write a draft on that and i guess it just fell through the cracks (lemme ping my co-author on that !) One way to solve this problem is by attaching a debug trailer that only carries the seq numbers at the *end* of the BFD packet. This would not be covered in the Length field carried in the BFD header but would be accounted for in the length carried in the IP header. The concept of attaching a trailer is documented well and is used in the IGPs. RFC 6506 describes one such trailer for OSPFv3. The catch however is that this debug trailer will NOT be covered by the BFD authentication. Is this acceptable to the WG? I think the problem of diagnosing a BFD flap becomes all the more important with BFD authentication turned on since then we have more points where a delay can be inserted. Cheers, Manav On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K wrote: > Manav, > This is good question. > >> Can the authors add some text on how this debugging mechanism would >> work if somebody employs BFD authentication? > > Right now we have considered without authentication (we are setting A bit). We should add some text on how we can use both Auth and de bug TLV. Is there any suggestion you have? I will get back to you on this. > > > Thanks > Santosh P K > >> > -----Original Message----- >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach Chen >> > Sent: Thursday, November 27, 2014 2:13 PM >> > To: Marc Binderberger >> > Cc: rtg-bfd@ietf.org >> > Subject: RE: BFD stability follow-up from IETF-91 >> > >> > Hi Marc, >> > >> >> -----Original Message----- >> >> From: Marc Binderberger [mailto:marc@sniff.de] >> >> Sent: Thursday, November 27, 2014 1:43 AM >> >> To: Mach Chen >> >> Cc: Manav Bhatia; rtg-bfd@ietf.org >> >> Subject: RE: BFD stability follow-up from IETF-91 >> >> >> >> Hello Mach, >> >> >> >> > This triggers me think out there should be another solution for >> >> > getting the Tx and Rx timestamps without encoding the timestamps in >> >> > the BFD >> >> packets. >> >> > For example, the Tx and Rx systems could just save timestamps >> >> > locally or send them to a centralized entity and then use the >> >> > sequence numbers to correlate them for further analyzing. >> >> >> >> I remember some discussion on NVO3 about how many bits it takes ;-) - >> >> could you send the links/draft names you are working on to this list? >> >> May be useful for further discussions. >> > >> > Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-coloring- >> based-ipfpm-framework-02) for the reference. >> > >> > But here I want to say is that since we have sequence number, we may not >> need the marking based solution. Suppose that someone want to monitor >> the delay of a BFD packet , just record and save the timestamp at the Tx side, >> which indexed by the sequence number. Similarly, do the same at the Rx >> side. Then based on the timestamps from both Tx and Rx, and using the >> sequence number to correlate the timestamps, it can also provide a way to >> monitor the delay of the BFD packet. >> > >> > That means, only if there is sequence number, even if without carrying the >> timestamp in the BFD packet, BFD packet delay can be measured. >> > >> > Best regards, >> > Mach >> > >> >> >> >> >> >> Thanks & Regards, >> >> Marc >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >> >> > Hi Marc and Manav, >> >> > >> >> >> -----Original Message----- >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Marc >> >> >> Binderberger >> >> >> Sent: Wednesday, November 26, 2014 4:50 PM >> >> >> To: Manav Bhatia >> >> >> Cc: rtg-bfd@ietf.org >> >> >> Subject: Re: BFD stability follow-up from IETF-91 >> >> >> >> >> >> Hello Manav, >> >> >> >> >> >>> I believe the work is important and addresses something thats >> >> >>> really required (spent too much time debugging why BFD flapped!). >> >> >> >> >> >> agree :-) we should keep the discussion alive. >> >> >> >> >> >> >> >> >>> side Time stamping would have helped in debugging whether the >> BFD >> >> >>> packet was sent late, or whether the packet was sent on time and >> >> >>> also arrived on time but was delayed when passing it up the BFD >> >> >>> stack/processor (lay in the RX buffer for tad too long) >> >> >> >> >> >> well, I can see a point in having the Tx timestamps in the packet >> >> >> mainly for the purpose of knowing "this" packet was okay/not okay >> >> >> on the Tx side and to correlate it with your local Rx measurement. >> >> > >> >> > Yes, this is one solution if people think BFD delay is needed. If >> >> > allow to have Tx timestamps to be carried in the packets, seems it >> >> > should be no problem to leave a seat for the Rx timestamps as well >> >> > :-). After all, with both Tx and Rx timestamp, it may simplify the >> >> implementation. >> >> > >> >> >> >> >> >> And even this point is less relevant with sequence numbers as this >> >> >> number allows the identification of packets and thus the >> >> >> correlation of information from the Tx and Rx system. >> >> > >> >> > Indeed, the sequence number helps a lot for the correlation between >> >> > the Tx and Rx system. >> >> > >> >> > This triggers me think out there should be another solution for >> >> > getting the Tx and Rx timestamps without encoding the timestamps in >> >> > the BFD >> >> packets. >> >> > For example, the Tx and Rx systems could just save timestamps >> >> > locally or send them to a centralized entity and then use the >> >> > sequence numbers to correlate them for further analyzing. >> >> > >> >> > Best regards, >> >> > Mach >> >> > >> >> >> >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> >> >>> Hi Jeff, >> >> >>> >> >> >>> I vividly remember the original intent of the stability draft was >> >> >>> to help debug BFD failures -- to isolate the issue at the RX or >> >> >>> the TX side Time stamping would have helped in debugging whether >> >> >>> the BFD packet was sent late, or whether the packet was sent on >> >> >>> time and also arrived on time but was delayed when passing it up >> >> >>> the BFD stack/processor (lay in the RX buffer for tad too long), >> >> >>> etc. But then time stamping came with its own set of issues, and >> >> >>> was hence dropped from the original draft. >> >> >>> >> >> >>> Can the authors send a summary on the list on why time stamping >> >> >>> was dropped so that we're all clear on that one. >> >> >>> >> >> >>> The current proposal does help but is not complete. >> >> >>> >> >> >>> Assume that the RX end loses a BFD session and learns later that >> >> >>> it did eventually receive the missing BFD packets (based on the seq >> #). >> >> >>> How would it know which end was misbehaving? Was it a delay at >> >> >>> the TX side, or was it the RX that delayed passing the packets to >> >> >>> the BFD process(or). This is usually what we want to debug and i >> >> >>> want to understand how this draft with sequence numbers can >> >> >>> unequivocally tell me that. >> >> >>> >> >> >>> I believe the work is important and addresses something thats >> >> >>> really required (spent too much time debugging why BFD flapped!). >> >> >>> Clearly what would help is putting a small section that describes >> >> >>> how we can use the sequence numbers to debug what and where >> things went wrong. >> >> >>> >> >> >>> Cheers, Manav >> >> >>> >> >> >>> >> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas >> wrote: >> >> >>>> draft-ashesh-bfd-stability-01 was presented again during IETF-91 >> >> >>>> in Honolulu. The slides can be viewed here: >> >> >>>> >> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx >> >> >>>> >> >> >>>> To attempt to simplify the presentation, the contentious portion >> >> >>>> of the timers were removed from the proposal, leaving only the >> >> >>>> sequence numbering for detecting loss of BFD async packets. >> >> >>>> >> >> >>>> When the room was polled to see whether the draft should be >> >> >>>> adopted as a WG item, the sense of the room was very quiet. As >> >> >>>> promised, this is to inquire for support for this draft on the >> >> >>>> WG mailing list to make sure the whole group has a voice. >> >> >>>> >> >> >>>> It should be noted that post-meeting discussion on the fate of >> >> >>>> this draft noted that BFD authentication code points are >> >> >>>> plentiful and are available with expert review. Should the >> >> >>>> draft authors wish to continue this work as Experimental, that is an >> option. >> >> >>>> >> >> >>>> -- Jeff >> >> >>>> >> >> >>> >> >> > >> > > From nobody Thu Nov 27 07:55: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 562981A009E for ; Thu, 27 Nov 2014 07:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TSZ8lDyQxizu for ; Thu, 27 Nov 2014 07:55:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FFD1A0030 for ; Thu, 27 Nov 2014 07:55:51 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 15:55:49 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 15:55:49 +0000 From: Santosh P K To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4A== Date: Thu, 27 Nov 2014 15:55:48 +0000 Message-ID: <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(46102003)(64706001)(99396003)(15975445006)(101416001)(54356999)(31966008)(76176999)(87936001)(21056001)(15202345003)(122556002)(230783001)(19580395003)(40100003)(2656002)(97736003)(120916001)(19300405004)(1941001)(19625215002)(33646002)(107886001)(107046002)(74316001)(106356001)(106116001)(20776003)(108616004)(86362001)(99286002)(95666004)(105586002)(92566001)(4396001)(77156002)(50986999)(66066001)(76576001)(62966003)(16236675004)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_43541ae8326d4f348869f71ed9e71624CO2PR0501MB823namprd05p_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/8rjobF08fzXeQKK_EBSPsjcVy2s 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, 27 Nov 2014 15:55:54 -0000 --_000_43541ae8326d4f348869f71ed9e71624CO2PR0501MB823namprd05p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to thank all for valuable comments. I think we have made enoug= h progress now. Below are the points on which we have rough consensus . 1. Active tail. We have rough consensus that we can move all active tail stuff (reliable, s= emi-reliable and non-reliable) to new draft. 2. Demultiplexing and UDP port number. Suggestion was made to add more text for IP demux and MPLS demux in base dr= aft. For rest of the data plane can have their own draft. 3. Echo mode supported? We have rough consensus that echo mode is NOT supported. 4. bfd.ReportTailDown directed to tail by head How head directs tail to report down when tails detect timer expires should= be outside scope of this document. 5. How packets get absorbed on tails? This should go along with data plane. Add more text on how tail absorbs pac= kets for IP and MPLS in base draft. There few points which are still open. 1. Increase interval? Draft suggest not to use POLL sequence and suggests to increase multiplier = first and then interval. If we have hardware implementation and don't want = to check complete packet every time received then change in packet may be i= ndicated with POLL bit set. Since this is one to many mapping we can't have a complete PO= LL sequence and hence we need to suppress FINAL. Should we be going with PO= LL and suppress FINAL by setting desired RX interval set to 0? Please sugge= st any better idea. 2. Security consideration? No suggestions. I think I have summarized what we have discussed till now. Please let me kn= ow if I have missed something. Thanks Santosh P K --_000_43541ae8326d4f348869f71ed9e71624CO2PR0501MB823namprd05p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I would like to thank all for valuable comments. = I think we have made enough progress now. Below are the points on which we = have rough consensus .

     

    1.       Active tail.

    We have rough consensu= s that we can move all active tail stuff (reliable, semi-reliable and non-r= eliable) to new draft.

     

    2.       Demultiplexing and UDP port number.

    Suggestion was made to= add more text for IP demux and MPLS demux in base draft. For rest of the d= ata plane can have their own draft.

     

    3.       Echo mode supported?

    We have rough consensu= s that echo mode is NOT supported.

     

    4.        bfd.ReportTailDown directed to tail by head

    How head directs tail = to report down when tails detect timer expires should be outside scope of t= his document.

     

    5.       How packets get absorbed on tails?

    This should go along w= ith data plane. Add more text on how tail absorbs packets for IP and MPLS i= n base draft.

     

    There few points which are still open.

    1.       Increase interval?

    Draft suggest not to u= se POLL sequence and suggests to increase multiplier first and then interva= l. If we have hardware implementation and don’t want to check complet= e packet every time received then change in packet may be indicated with

    POLL bit set. Since th= is is one to many mapping we can't have a complete POLL sequence and hence = we need to suppress FINAL. Should we be going with POLL and suppress FINAL = by setting desired RX interval set to 0? Please suggest any better idea.

     

    2.       Security consideration?

    No suggestions. <= /o:p>

     

    I think I have summarized what we have discussed = till now. Please let me know if I have missed something.

     

    Thanks

    Santosh P K

    --_000_43541ae8326d4f348869f71ed9e71624CO2PR0501MB823namprd05p_-- From nobody Thu Nov 27 07:56:47 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 863C11A009E for ; Thu, 27 Nov 2014 07:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmuEVzlRQZgl for ; Thu, 27 Nov 2014 07:56:43 -0800 (PST) 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 7A8F61A0030 for ; Thu, 27 Nov 2014 07:56:43 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 27 Nov 2014 15:56:41 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 27 Nov 2014 15:56:41 +0000 From: Santosh P K To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAAAu3A Date: Thu, 27 Nov 2014 15:56:41 +0000 Message-ID: <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.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: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 040866B734 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(24454002)(189002)(199003)(13464003)(86362001)(107046002)(122556002)(40100003)(15202345003)(120916001)(105586002)(106356001)(106116001)(1411001)(15975445006)(99396003)(110136001)(87936001)(101416001)(2656002)(66066001)(1720100001)(31966008)(4396001)(561944003)(64706001)(19580395003)(19580405001)(20776003)(33646002)(21056001)(76576001)(108616004)(74316001)(97736003)(99286002)(77156002)(50986999)(62966003)(76176999)(54356999)(46102003)(95666004)(92566001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7pXIoyCOkO7_K0F1hxdTmNzkuYs 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, 27 Nov 2014 15:56:46 -0000 TWFuYXYsDQogICBUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lIGNvbW1lbnRzLg0KDQo+IFlvdSBj b3VsZCB1c2UgdGhlIGNyeXB0byBzZXF1ZW5jZSBudW1iZXJzIGNhcnJpZWQgaW4gdGhlIG1ldGlj dWxvdXMNCj4gY3J5cHRvZ3JhcGhpYyBhdXRoIGZvciBkZXRlY3RpbmcgcGFja2V0IGxvc3Nlcy4g SG93ZXZlciwgdGhpcyBicmVha3Mgd2hlbg0KPiB5b3UgdXNlIG5vbi1tZXRpY3Vsb3VzIGNyeXB0 byBhdXRoZW50aWNhdGlvbiBzaW5jZSB0aGUgc2VxdWVuY2UgbnVtYmVyIGlzDQo+IG9ubHkgaW5j cmVtZW50ZWQgb2NjYXNpb25hbGx5IHRoZXJlLiBUaGlzIGkgYmVsaWV2ZSBpcyBhIGRlYWwgYnJl YWtlciBzaW5jZSBpDQo+IHJlYWxseSBlbnZpc2lvbiBub24gbWV0aWN1bG91cyBtb2RlIHRvIGJl IHRoZSBvbmUgYmVpbmcgd2lkZWx5IGRlcGxveWVkLiBJbg0KPiBmYWN0IHdlIHdlcmUgc3VwcG9z ZWQgdG8gd3JpdGUgYSBkcmFmdCBvbiB0aGF0IGFuZCBpIGd1ZXNzIGl0IGp1c3QgZmVsbCB0aHJv dWdoDQo+IHRoZSBjcmFja3MgKGxlbW1lIHBpbmcgbXkgY28tYXV0aG9yIG9uIHRoYXQgISkNCj4g DQo+IE9uZSB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtIGlzIGJ5IGF0dGFjaGluZyBhIGRlYnVn IHRyYWlsZXIgdGhhdCBvbmx5IGNhcnJpZXMNCj4gdGhlIHNlcSBudW1iZXJzIGF0IHRoZSAqZW5k KiBvZiB0aGUgQkZEIHBhY2tldC4gVGhpcyB3b3VsZCBub3QgYmUgY292ZXJlZA0KPiBpbiB0aGUg TGVuZ3RoIGZpZWxkIGNhcnJpZWQgaW4gdGhlIEJGRCBoZWFkZXIgYnV0IHdvdWxkIGJlIGFjY291 bnRlZCBmb3IgaW4NCj4gdGhlIGxlbmd0aCBjYXJyaWVkIGluIHRoZSBJUCBoZWFkZXIuIFRoZSBj b25jZXB0IG9mIGF0dGFjaGluZyBhIHRyYWlsZXIgaXMNCj4gZG9jdW1lbnRlZCB3ZWxsIGFuZCBp cyB1c2VkIGluIHRoZSBJR1BzLiBSRkMgNjUwNiBkZXNjcmliZXMgb25lIHN1Y2ggdHJhaWxlcg0K DQpZb3UgYXJlIHN1Z2dlc3RpbmcgdG8gYWRkIHRoZSBkZWJ1ZyB0cmFpbGVyIHdpdGggb3Igd2l0 aG91dCBhdXRoZW50aWNhdGlvbiByaWdodD8gDQoNCg0KPiBmb3IgT1NQRnYzLiBUaGUgY2F0Y2gg aG93ZXZlciBpcyB0aGF0IHRoaXMgZGVidWcgdHJhaWxlciB3aWxsIE5PVCBiZSBjb3ZlcmVkDQo+ IGJ5IHRoZSBCRkQgYXV0aGVudGljYXRpb24uIElzIHRoaXMgYWNjZXB0YWJsZSB0byB0aGUgV0c/ DQoNCkkgZGlkIG5vdCBnZXQgdGhpcy4gRGlkIHlvdSBtZWFuIHRoZSBsZW5ndGggb2YgdGhlIGF1 dGggVFZMIHdpbGwgbm90IGluY2x1ZGUgdGhpcyBsZW5ndGggYW5kIHdpbGwgYmUgb25seSBpbiBJ UCBoZWFkZXI/IA0KDQo+IEkgdGhpbmsgdGhlIHByb2JsZW0gb2YgZGlhZ25vc2luZyBhIEJGRCBm bGFwIGJlY29tZXMgYWxsIHRoZSBtb3JlIGltcG9ydGFudA0KPiB3aXRoIEJGRCBhdXRoZW50aWNh dGlvbiB0dXJuZWQgb24gc2luY2UgdGhlbiB3ZSBoYXZlIG1vcmUgcG9pbnRzIHdoZXJlIGENCj4g ZGVsYXkgY2FuIGJlIGluc2VydGVkLg0KDQpJIGFncmVlIHdpdGggdGhpcyBhbmQgYXMgYSBkZXZl bG9wZXIgaGF2ZSBzZWVuIHRoaXMgaGFwcGVuaW5nLiANCg0KVGhhbmtzDQpTYW50b3NoIFAgSyAN Cg0KPiBPbiBUaHUsIE5vdiAyNywgMjAxNCBhdCA4OjMyIFBNLCBTYW50b3NoIFAgSyA8c2FudG9z aHBrQGp1bmlwZXIubmV0Pg0KPiB3cm90ZToNCj4gPiBNYW5hdiwNCj4gPiAgICAgVGhpcyBpcyBn b29kIHF1ZXN0aW9uLg0KPiA+DQo+ID4+IENhbiB0aGUgYXV0aG9ycyBhZGQgc29tZSB0ZXh0IG9u IGhvdyB0aGlzIGRlYnVnZ2luZyBtZWNoYW5pc20gd291bGQNCj4gPj4gd29yayBpZiBzb21lYm9k eSBlbXBsb3lzIEJGRCBhdXRoZW50aWNhdGlvbj8NCj4gPg0KPiA+IFJpZ2h0IG5vdyB3ZSBoYXZl IGNvbnNpZGVyZWQgd2l0aG91dCBhdXRoZW50aWNhdGlvbiAod2UgYXJlIHNldHRpbmcgQQ0KPiBi aXQpLiBXZSBzaG91bGQgYWRkIHNvbWUgdGV4dCBvbiBob3cgd2UgY2FuIHVzZSBib3RoIEF1dGgg YW5kIGRlIGJ1ZyBUTFYuDQo+IElzIHRoZXJlIGFueSBzdWdnZXN0aW9uIHlvdSBoYXZlPyBJIHdp bGwgZ2V0IGJhY2sgdG8geW91IG9uIHRoaXMuDQo+ID4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+IFNh bnRvc2ggUCBLDQo+ID4NCj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+ IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBNYWNoDQo+ID4+ID4gQ2hlbg0KPiA+PiA+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAy NywgMjAxNCAyOjEzIFBNDQo+ID4+ID4gVG86IE1hcmMgQmluZGVyYmVyZ2VyDQo+ID4+ID4gQ2M6 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPj4gPiBTdWJqZWN0OiBSRTogQkZEIHN0YWJpbGl0eSBmb2xs b3ctdXAgZnJvbSBJRVRGLTkxDQo+ID4+ID4NCj4gPj4gPiBIaSBNYXJjLA0KPiA+PiA+DQo+ID4+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IE1hcmMgQmluZGVy YmVyZ2VyIFttYWlsdG86bWFyY0BzbmlmZi5kZV0NCj4gPj4gPj4gU2VudDogVGh1cnNkYXksIE5v dmVtYmVyIDI3LCAyMDE0IDE6NDMgQU0NCj4gPj4gPj4gVG86IE1hY2ggQ2hlbg0KPiA+PiA+PiBD YzogTWFuYXYgQmhhdGlhOyBydGctYmZkQGlldGYub3JnDQo+ID4+ID4+IFN1YmplY3Q6IFJFOiBC RkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4gPj4gPj4NCj4gPj4gPj4gSGVs bG8gTWFjaCwNCj4gPj4gPj4NCj4gPj4gPj4gPiBUaGlzIHRyaWdnZXJzIG1lIHRoaW5rIG91dCB0 aGVyZSBzaG91bGQgYmUgYW5vdGhlciBzb2x1dGlvbiBmb3INCj4gPj4gPj4gPiBnZXR0aW5nIHRo ZSBUeCBhbmQgUnggdGltZXN0YW1wcyB3aXRob3V0IGVuY29kaW5nIHRoZSB0aW1lc3RhbXBzDQo+ ID4+ID4+ID4gaW4gdGhlIEJGRA0KPiA+PiA+PiBwYWNrZXRzLg0KPiA+PiA+PiA+IEZvciBleGFt cGxlLCB0aGUgVHggYW5kIFJ4IHN5c3RlbXMgY291bGQganVzdCBzYXZlIHRpbWVzdGFtcHMNCj4g Pj4gPj4gPiBsb2NhbGx5IG9yIHNlbmQgdGhlbSB0byBhIGNlbnRyYWxpemVkIGVudGl0eSBhbmQg dGhlbiB1c2UgdGhlDQo+ID4+ID4+ID4gc2VxdWVuY2UgbnVtYmVycyB0byBjb3JyZWxhdGUgdGhl bSBmb3IgZnVydGhlciBhbmFseXppbmcuDQo+ID4+ID4+DQo+ID4+ID4+IEkgcmVtZW1iZXIgc29t ZSBkaXNjdXNzaW9uIG9uIE5WTzMgYWJvdXQgaG93IG1hbnkgYml0cyBpdCB0YWtlcw0KPiA+PiA+ PiA7LSkgLSBjb3VsZCB5b3Ugc2VuZCB0aGUgbGlua3MvZHJhZnQgbmFtZXMgeW91IGFyZSB3b3Jr aW5nIG9uIHRvIHRoaXMNCj4gbGlzdD8NCj4gPj4gPj4gTWF5IGJlIHVzZWZ1bCBmb3IgZnVydGhl ciBkaXNjdXNzaW9ucy4NCj4gPj4gPg0KPiA+PiA+IFN1cmUsIGhlcmUgaXMgdGhlDQo+ID4+ID4g bGluayhodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWlwcG0tY29sb3Jpbmct DQo+ID4+IGJhc2VkLWlwZnBtLWZyYW1ld29yay0wMikgZm9yIHRoZSByZWZlcmVuY2UuDQo+ID4+ ID4NCj4gPj4gPiBCdXQgaGVyZSBJIHdhbnQgdG8gc2F5IGlzIHRoYXQgc2luY2Ugd2UgaGF2ZSBz ZXF1ZW5jZSBudW1iZXIsIHdlDQo+ID4+ID4gbWF5IG5vdA0KPiA+PiBuZWVkIHRoZSBtYXJraW5n IGJhc2VkIHNvbHV0aW9uLiBTdXBwb3NlIHRoYXQgc29tZW9uZSB3YW50IHRvIG1vbml0b3INCj4g Pj4gdGhlIGRlbGF5IG9mIGEgQkZEIHBhY2tldCAsIGp1c3QgcmVjb3JkIGFuZCBzYXZlIHRoZSB0 aW1lc3RhbXAgYXQgdGhlDQo+ID4+IFR4IHNpZGUsIHdoaWNoIGluZGV4ZWQgYnkgdGhlIHNlcXVl bmNlIG51bWJlci4gU2ltaWxhcmx5LCBkbyB0aGUgc2FtZQ0KPiA+PiBhdCB0aGUgUnggc2lkZS4g VGhlbiBiYXNlZCBvbiB0aGUgdGltZXN0YW1wcyBmcm9tIGJvdGggVHggYW5kIFJ4LCBhbmQNCj4g Pj4gdXNpbmcgdGhlIHNlcXVlbmNlIG51bWJlciB0byBjb3JyZWxhdGUgdGhlIHRpbWVzdGFtcHMs IGl0IGNhbiBhbHNvDQo+ID4+IHByb3ZpZGUgYSB3YXkgdG8gbW9uaXRvciB0aGUgZGVsYXkgb2Yg dGhlIEJGRCBwYWNrZXQuDQo+ID4+ID4NCj4gPj4gPiBUaGF0IG1lYW5zLCBvbmx5IGlmIHRoZXJl IGlzIHNlcXVlbmNlIG51bWJlciwgZXZlbiBpZiB3aXRob3V0DQo+ID4+ID4gY2FycnlpbmcgdGhl DQo+ID4+IHRpbWVzdGFtcCBpbiB0aGUgQkZEIHBhY2tldCwgQkZEIHBhY2tldCBkZWxheSBjYW4g YmUgbWVhc3VyZWQuDQo+ID4+ID4NCj4gPj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4+ID4gTWFjaA0K PiA+PiA+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+ID4+ ID4+IE1hcmMNCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gT24gV2VkLCAyNiBO b3YgMjAxNCAwOToxNzozMiArMDAwMCwgTWFjaCBDaGVuIHdyb3RlOg0KPiA+PiA+PiA+IEhpIE1h cmMgYW5kIE1hbmF2LA0KPiA+PiA+PiA+DQo+ID4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4+ID4+ID4+IEZyb206IFJ0Zy1iZmQgW21haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+PiA+PiA+PiBNYXJjIEJpbmRlcmJlcmdlcg0KPiA+ PiA+PiA+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI2LCAyMDE0IDQ6NTAgUE0NCj4gPj4g Pj4gPj4gVG86IE1hbmF2IEJoYXRpYQ0KPiA+PiA+PiA+PiBDYzogcnRnLWJmZEBpZXRmLm9yZw0K PiA+PiA+PiA+PiBTdWJqZWN0OiBSZTogQkZEIHN0YWJpbGl0eSBmb2xsb3ctdXAgZnJvbSBJRVRG LTkxDQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+IEhlbGxvIE1hbmF2LA0KPiA+PiA+PiA+Pg0KPiA+ PiA+PiA+Pj4gSSBiZWxpZXZlIHRoZSB3b3JrIGlzIGltcG9ydGFudCBhbmQgYWRkcmVzc2VzIHNv bWV0aGluZyB0aGF0cw0KPiA+PiA+PiA+Pj4gcmVhbGx5IHJlcXVpcmVkIChzcGVudCB0b28gbXVj aCB0aW1lIGRlYnVnZ2luZyB3aHkgQkZEDQo+IGZsYXBwZWQhKS4NCj4gPj4gPj4gPj4NCj4gPj4g Pj4gPj4gYWdyZWUgOi0pIHdlIHNob3VsZCBrZWVwIHRoZSBkaXNjdXNzaW9uIGFsaXZlLg0KPiA+ PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pj4gc2lkZSBUaW1lIHN0YW1waW5nIHdvdWxk IGhhdmUgaGVscGVkIGluIGRlYnVnZ2luZyB3aGV0aGVyIHRoZQ0KPiA+PiBCRkQNCj4gPj4gPj4g Pj4+IHBhY2tldCB3YXMgc2VudCBsYXRlLCBvciB3aGV0aGVyIHRoZSBwYWNrZXQgd2FzIHNlbnQg b24gdGltZQ0KPiA+PiA+PiA+Pj4gYW5kIGFsc28gYXJyaXZlZCBvbiB0aW1lIGJ1dCB3YXMgZGVs YXllZCB3aGVuIHBhc3NpbmcgaXQgdXANCj4gPj4gPj4gPj4+IHRoZSBCRkQgc3RhY2svcHJvY2Vz c29yIChsYXkgaW4gdGhlIFJYIGJ1ZmZlciBmb3IgdGFkIHRvbw0KPiA+PiA+PiA+Pj4gbG9uZykN Cj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gd2VsbCwgSSBjYW4gc2VlIGEgcG9pbnQgaW4gaGF2aW5n IHRoZSBUeCB0aW1lc3RhbXBzIGluIHRoZQ0KPiA+PiA+PiA+PiBwYWNrZXQgbWFpbmx5IGZvciB0 aGUgcHVycG9zZSBvZiBrbm93aW5nICJ0aGlzIiBwYWNrZXQgd2FzDQo+ID4+ID4+ID4+IG9rYXkv bm90IG9rYXkgb24gdGhlIFR4IHNpZGUgYW5kIHRvIGNvcnJlbGF0ZSBpdCB3aXRoIHlvdXIgbG9j YWwgUngNCj4gbWVhc3VyZW1lbnQuDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiBZZXMsIHRoaXMgaXMg b25lIHNvbHV0aW9uIGlmIHBlb3BsZSB0aGluayBCRkQgZGVsYXkgaXMgbmVlZGVkLg0KPiA+PiA+ PiA+IElmIGFsbG93IHRvIGhhdmUgVHggdGltZXN0YW1wcyB0byBiZSBjYXJyaWVkIGluIHRoZSBw YWNrZXRzLA0KPiA+PiA+PiA+IHNlZW1zIGl0IHNob3VsZCBiZSBubyBwcm9ibGVtIHRvIGxlYXZl IGEgc2VhdCBmb3IgdGhlIFJ4DQo+ID4+ID4+ID4gdGltZXN0YW1wcyBhcyB3ZWxsIDotKS4gQWZ0 ZXIgYWxsLCB3aXRoIGJvdGggVHggYW5kIFJ4DQo+ID4+ID4+ID4gdGltZXN0YW1wLCBpdCBtYXkg c2ltcGxpZnkgdGhlDQo+ID4+ID4+IGltcGxlbWVudGF0aW9uLg0KPiA+PiA+PiA+DQo+ID4+ID4+ ID4+DQo+ID4+ID4+ID4+IEFuZCBldmVuIHRoaXMgcG9pbnQgaXMgbGVzcyByZWxldmFudCB3aXRo IHNlcXVlbmNlIG51bWJlcnMgYXMNCj4gPj4gPj4gPj4gdGhpcyBudW1iZXIgYWxsb3dzIHRoZSBp ZGVudGlmaWNhdGlvbiBvZiBwYWNrZXRzIGFuZCB0aHVzIHRoZQ0KPiA+PiA+PiA+PiBjb3JyZWxh dGlvbiBvZiBpbmZvcm1hdGlvbiBmcm9tIHRoZSBUeCBhbmQgUnggc3lzdGVtLg0KPiA+PiA+PiA+ DQo+ID4+ID4+ID4gSW5kZWVkLCB0aGUgc2VxdWVuY2UgbnVtYmVyIGhlbHBzIGEgbG90IGZvciB0 aGUgY29ycmVsYXRpb24NCj4gPj4gPj4gPiBiZXR3ZWVuIHRoZSBUeCBhbmQgUnggc3lzdGVtLg0K PiA+PiA+PiA+DQo+ID4+ID4+ID4gVGhpcyB0cmlnZ2VycyBtZSB0aGluayBvdXQgdGhlcmUgc2hv dWxkIGJlIGFub3RoZXIgc29sdXRpb24gZm9yDQo+ID4+ID4+ID4gZ2V0dGluZyB0aGUgVHggYW5k IFJ4IHRpbWVzdGFtcHMgd2l0aG91dCBlbmNvZGluZyB0aGUgdGltZXN0YW1wcw0KPiA+PiA+PiA+ IGluIHRoZSBCRkQNCj4gPj4gPj4gcGFja2V0cy4NCj4gPj4gPj4gPiBGb3IgZXhhbXBsZSwgdGhl IFR4IGFuZCBSeCBzeXN0ZW1zIGNvdWxkIGp1c3Qgc2F2ZSB0aW1lc3RhbXBzDQo+ID4+ID4+ID4g bG9jYWxseSBvciBzZW5kIHRoZW0gdG8gYSBjZW50cmFsaXplZCBlbnRpdHkgYW5kIHRoZW4gdXNl IHRoZQ0KPiA+PiA+PiA+IHNlcXVlbmNlIG51bWJlcnMgdG8gY29ycmVsYXRlIHRoZW0gZm9yIGZ1 cnRoZXIgYW5hbHl6aW5nLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gQmVzdCByZWdhcmRzLA0KPiA+ PiA+PiA+IE1hY2gNCj4gPj4gPj4gPg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+ PiBSZWdhcmRzLCBNYXJjDQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+DQo+ID4+ ID4+ID4+DQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+IE9uIFdlZCwgMjYgTm92 IDIwMTQgMTI6MjY6NDEgKzA1MzAsIE1hbmF2IEJoYXRpYSB3cm90ZToNCj4gPj4gPj4gPj4+IEhp IEplZmYsDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gSSB2aXZpZGx5IHJlbWVtYmVyIHRoZSBv cmlnaW5hbCBpbnRlbnQgb2YgdGhlIHN0YWJpbGl0eSBkcmFmdA0KPiA+PiA+PiA+Pj4gd2FzIHRv IGhlbHAgZGVidWcgQkZEIGZhaWx1cmVzIC0tIHRvIGlzb2xhdGUgdGhlIGlzc3VlIGF0IHRoZQ0K PiA+PiA+PiA+Pj4gUlggb3IgdGhlIFRYIHNpZGUgVGltZSBzdGFtcGluZyB3b3VsZCBoYXZlIGhl bHBlZCBpbiBkZWJ1Z2dpbmcNCj4gPj4gPj4gPj4+IHdoZXRoZXIgdGhlIEJGRCBwYWNrZXQgd2Fz IHNlbnQgbGF0ZSwgb3Igd2hldGhlciB0aGUgcGFja2V0DQo+ID4+ID4+ID4+PiB3YXMgc2VudCBv biB0aW1lIGFuZCBhbHNvIGFycml2ZWQgb24gdGltZSBidXQgd2FzIGRlbGF5ZWQgd2hlbg0KPiA+ PiA+PiA+Pj4gcGFzc2luZyBpdCB1cCB0aGUgQkZEIHN0YWNrL3Byb2Nlc3NvciAobGF5IGluIHRo ZSBSWCBidWZmZXINCj4gPj4gPj4gPj4+IGZvciB0YWQgdG9vIGxvbmcpLCBldGMuIEJ1dCB0aGVu IHRpbWUgc3RhbXBpbmcgY2FtZSB3aXRoIGl0cw0KPiA+PiA+PiA+Pj4gb3duIHNldCBvZiBpc3N1 ZXMsIGFuZCB3YXMgaGVuY2UgZHJvcHBlZCBmcm9tIHRoZSBvcmlnaW5hbCBkcmFmdC4NCj4gPj4g Pj4gPj4+DQo+ID4+ID4+ID4+PiBDYW4gdGhlIGF1dGhvcnMgc2VuZCBhIHN1bW1hcnkgb24gdGhl IGxpc3Qgb24gd2h5IHRpbWUNCj4gPj4gPj4gPj4+IHN0YW1waW5nIHdhcyBkcm9wcGVkIHNvIHRo YXQgd2UncmUgYWxsIGNsZWFyIG9uIHRoYXQgb25lLg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ IFRoZSBjdXJyZW50IHByb3Bvc2FsIGRvZXMgaGVscCBidXQgaXMgbm90IGNvbXBsZXRlLg0KPiA+ PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IEFzc3VtZSB0aGF0IHRoZSBSWCBlbmQgbG9zZXMgYSBCRkQg c2Vzc2lvbiBhbmQgbGVhcm5zIGxhdGVyDQo+ID4+ID4+ID4+PiB0aGF0IGl0IGRpZCBldmVudHVh bGx5IHJlY2VpdmUgdGhlIG1pc3NpbmcgQkZEIHBhY2tldHMgKGJhc2VkDQo+ID4+ID4+ID4+PiBv biB0aGUgc2VxDQo+ID4+ICMpLg0KPiA+PiA+PiA+Pj4gSG93IHdvdWxkIGl0IGtub3cgd2hpY2gg ZW5kIHdhcyBtaXNiZWhhdmluZz8gV2FzIGl0IGEgZGVsYXkgYXQNCj4gPj4gPj4gPj4+IHRoZSBU WCBzaWRlLCBvciB3YXMgaXQgdGhlIFJYIHRoYXQgZGVsYXllZCBwYXNzaW5nIHRoZSBwYWNrZXRz DQo+ID4+ID4+ID4+PiB0byB0aGUgQkZEIHByb2Nlc3Mob3IpLiBUaGlzIGlzIHVzdWFsbHkgd2hh dCB3ZSB3YW50IHRvIGRlYnVnDQo+ID4+ID4+ID4+PiBhbmQgaSB3YW50IHRvIHVuZGVyc3RhbmQg aG93IHRoaXMgZHJhZnQgd2l0aCBzZXF1ZW5jZSBudW1iZXJzDQo+ID4+ID4+ID4+PiBjYW4gdW5l cXVpdm9jYWxseSB0ZWxsIG1lIHRoYXQuDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gSSBiZWxp ZXZlIHRoZSB3b3JrIGlzIGltcG9ydGFudCBhbmQgYWRkcmVzc2VzIHNvbWV0aGluZyB0aGF0cw0K PiA+PiA+PiA+Pj4gcmVhbGx5IHJlcXVpcmVkIChzcGVudCB0b28gbXVjaCB0aW1lIGRlYnVnZ2lu ZyB3aHkgQkZEDQo+IGZsYXBwZWQhKS4NCj4gPj4gPj4gPj4+IENsZWFybHkgd2hhdCB3b3VsZCBo ZWxwIGlzIHB1dHRpbmcgYSBzbWFsbCBzZWN0aW9uIHRoYXQNCj4gPj4gPj4gPj4+IGRlc2NyaWJl cyBob3cgd2UgY2FuIHVzZSB0aGUgc2VxdWVuY2UgbnVtYmVycyB0byBkZWJ1ZyB3aGF0DQo+ID4+ ID4+ID4+PiBhbmQgd2hlcmUNCj4gPj4gdGhpbmdzIHdlbnQgd3JvbmcuDQo+ID4+ID4+ID4+Pg0K PiA+PiA+PiA+Pj4gQ2hlZXJzLCBNYW5hdg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+DQo+ID4+ ID4+ID4+PiBPbiBXZWQsIE5vdiAyNiwgMjAxNCBhdCA1OjQ5IEFNLCBKZWZmcmV5IEhhYXMgPGpo YWFzQHBmcmMub3JnPg0KPiA+PiB3cm90ZToNCj4gPj4gPj4gPj4+PiBkcmFmdC1hc2hlc2gtYmZk LXN0YWJpbGl0eS0wMSB3YXMgcHJlc2VudGVkIGFnYWluIGR1cmluZw0KPiA+PiA+PiA+Pj4+IElF VEYtOTEgaW4gSG9ub2x1bHUuICBUaGUgc2xpZGVzIGNhbiBiZSB2aWV3ZWQgaGVyZToNCj4gPj4g Pj4gPj4+Pg0KPiA+PiA+PiA+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEv c2xpZGVzL3NsaWRlcy05MS1iZmQtNC5wcHQNCj4gPj4gPj4gPj4+PiB4DQo+ID4+ID4+ID4+Pj4N Cj4gPj4gPj4gPj4+PiBUbyBhdHRlbXB0IHRvIHNpbXBsaWZ5IHRoZSBwcmVzZW50YXRpb24sIHRo ZSBjb250ZW50aW91cw0KPiA+PiA+PiA+Pj4+IHBvcnRpb24gb2YgdGhlIHRpbWVycyB3ZXJlIHJl bW92ZWQgZnJvbSB0aGUgcHJvcG9zYWwsIGxlYXZpbmcNCj4gPj4gPj4gPj4+PiBvbmx5IHRoZSBz ZXF1ZW5jZSBudW1iZXJpbmcgZm9yIGRldGVjdGluZyBsb3NzIG9mIEJGRCBhc3luYw0KPiBwYWNr ZXRzLg0KPiA+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+Pj4gV2hlbiB0aGUgcm9vbSB3YXMgcG9sbGVk IHRvIHNlZSB3aGV0aGVyIHRoZSBkcmFmdCBzaG91bGQgYmUNCj4gPj4gPj4gPj4+PiBhZG9wdGVk IGFzIGEgV0cgaXRlbSwgdGhlIHNlbnNlIG9mIHRoZSByb29tIHdhcyB2ZXJ5IHF1aWV0Lg0KPiA+ PiA+PiA+Pj4+IEFzIHByb21pc2VkLCB0aGlzIGlzIHRvIGlucXVpcmUgZm9yIHN1cHBvcnQgZm9y IHRoaXMgZHJhZnQgb24NCj4gPj4gPj4gPj4+PiB0aGUgV0cgbWFpbGluZyBsaXN0IHRvIG1ha2Ug c3VyZSB0aGUgd2hvbGUgZ3JvdXAgaGFzIGEgdm9pY2UuDQo+ID4+ID4+ID4+Pj4NCj4gPj4gPj4g Pj4+PiBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBwb3N0LW1lZXRpbmcgZGlzY3Vzc2lvbiBvbiB0 aGUgZmF0ZQ0KPiA+PiA+PiA+Pj4+IG9mIHRoaXMgZHJhZnQgbm90ZWQgdGhhdCBCRkQgYXV0aGVu dGljYXRpb24gY29kZSBwb2ludHMgYXJlDQo+ID4+ID4+ID4+Pj4gcGxlbnRpZnVsIGFuZCBhcmUg YXZhaWxhYmxlIHdpdGggZXhwZXJ0IHJldmlldy4gIFNob3VsZCB0aGUNCj4gPj4gPj4gPj4+PiBk cmFmdCBhdXRob3JzIHdpc2ggdG8gY29udGludWUgdGhpcyB3b3JrIGFzIEV4cGVyaW1lbnRhbCwN Cj4gPj4gPj4gPj4+PiB0aGF0IGlzIGFuDQo+ID4+IG9wdGlvbi4NCj4gPj4gPj4gPj4+Pg0KPiA+ PiA+PiA+Pj4+IC0tIEplZmYNCj4gPj4gPj4gPj4+Pg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPg0K PiA+PiA+DQo+ID4NCg== From nobody Thu Nov 27 08:17: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 7F34D1A00D1 for ; Thu, 27 Nov 2014 08:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zILxHZa55n9S for ; Thu, 27 Nov 2014 08:17:17 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61A231A00C0 for ; Thu, 27 Nov 2014 08:17:17 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id gq1so3913158obb.23 for ; Thu, 27 Nov 2014 08:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iMRJdB9Is3ZhZdj3hdaMbvYIEQjBGlvAEuTgMRb1tBY=; b=qHENgB8rvj2PPXGxJDs/MZXEeb21pRj38mS6G4UCnVJlphBYPABfO912EtgioIdNXY FQr+rOOb1o65+M/NpQ61MW2nZKcQ+aW5x5H+y7ckSu0kWEO597UMsZydh6E6fLgghuv1 v3bUdImVBkFoDbLYRqHr0qHmSAuAFPUkhN1GnmtFFepJadi1NB1fSS156AIK/T+WQe2q 4QBcoKNtD9K1rDIfbGTy0+ng9KkIDL2DPw0O0tj/BoM8EBY8sfC8iEhTLnEvUvzfe1cH VRdr73RzYoV5KTDffMsg4Dv0hVc9x2VqCarPP3sZn9PPrBU1htDNV1dbybKmoar9D8vi 39rg== MIME-Version: 1.0 X-Received: by 10.182.252.225 with SMTP id zv1mr24200973obc.37.1417105036666; Thu, 27 Nov 2014 08:17:16 -0800 (PST) Received: by 10.76.178.199 with HTTP; Thu, 27 Nov 2014 08:17:16 -0800 (PST) In-Reply-To: <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> Date: Thu, 27 Nov 2014 21:47:16 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Santosh P K Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/QH4YLtCXD_sBAL3rq-Z0KTViOCk 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, 27 Nov 2014 16:17:20 -0000 Hi Santosh, >> the seq numbers at the *end* of the BFD packet. This would not be covered >> in the Length field carried in the BFD header but would be accounted for in >> the length carried in the IP header. The concept of attaching a trailer is >> documented well and is used in the IGPs. RFC 6506 describes one such trailer > > You are suggesting to add the debug trailer with or without authentication right? without. > > >> for OSPFv3. The catch however is that this debug trailer will NOT be covered >> by the BFD authentication. Is this acceptable to the WG? > > I did not get this. Did you mean the length of the auth TVL will not include this length and will be only in IP header? Yes, it would only be in the IP header. Cheers, Manav > >> I think the problem of diagnosing a BFD flap becomes all the more important >> with BFD authentication turned on since then we have more points where a >> delay can be inserted. > > I agree with this and as a developer have seen this happening. > > Thanks > Santosh P K > >> On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K >> wrote: >> > Manav, >> > This is good question. >> > >> >> Can the authors add some text on how this debugging mechanism would >> >> work if somebody employs BFD authentication? >> > >> > Right now we have considered without authentication (we are setting A >> bit). We should add some text on how we can use both Auth and de bug TLV. >> Is there any suggestion you have? I will get back to you on this. >> > >> > >> > Thanks >> > Santosh P K >> > >> >> > -----Original Message----- >> >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach >> >> > Chen >> >> > Sent: Thursday, November 27, 2014 2:13 PM >> >> > To: Marc Binderberger >> >> > Cc: rtg-bfd@ietf.org >> >> > Subject: RE: BFD stability follow-up from IETF-91 >> >> > >> >> > Hi Marc, >> >> > >> >> >> -----Original Message----- >> >> >> From: Marc Binderberger [mailto:marc@sniff.de] >> >> >> Sent: Thursday, November 27, 2014 1:43 AM >> >> >> To: Mach Chen >> >> >> Cc: Manav Bhatia; rtg-bfd@ietf.org >> >> >> Subject: RE: BFD stability follow-up from IETF-91 >> >> >> >> >> >> Hello Mach, >> >> >> >> >> >> > This triggers me think out there should be another solution for >> >> >> > getting the Tx and Rx timestamps without encoding the timestamps >> >> >> > in the BFD >> >> >> packets. >> >> >> > For example, the Tx and Rx systems could just save timestamps >> >> >> > locally or send them to a centralized entity and then use the >> >> >> > sequence numbers to correlate them for further analyzing. >> >> >> >> >> >> I remember some discussion on NVO3 about how many bits it takes >> >> >> ;-) - could you send the links/draft names you are working on to this >> list? >> >> >> May be useful for further discussions. >> >> > >> >> > Sure, here is the >> >> > link(http://tools.ietf.org/html/draft-chen-ippm-coloring- >> >> based-ipfpm-framework-02) for the reference. >> >> > >> >> > But here I want to say is that since we have sequence number, we >> >> > may not >> >> need the marking based solution. Suppose that someone want to monitor >> >> the delay of a BFD packet , just record and save the timestamp at the >> >> Tx side, which indexed by the sequence number. Similarly, do the same >> >> at the Rx side. Then based on the timestamps from both Tx and Rx, and >> >> using the sequence number to correlate the timestamps, it can also >> >> provide a way to monitor the delay of the BFD packet. >> >> > >> >> > That means, only if there is sequence number, even if without >> >> > carrying the >> >> timestamp in the BFD packet, BFD packet delay can be measured. >> >> > >> >> > Best regards, >> >> > Mach >> >> > >> >> >> >> >> >> >> >> >> Thanks & Regards, >> >> >> Marc >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >> >> >> > Hi Marc and Manav, >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> >> >> >> Marc Binderberger >> >> >> >> Sent: Wednesday, November 26, 2014 4:50 PM >> >> >> >> To: Manav Bhatia >> >> >> >> Cc: rtg-bfd@ietf.org >> >> >> >> Subject: Re: BFD stability follow-up from IETF-91 >> >> >> >> >> >> >> >> Hello Manav, >> >> >> >> >> >> >> >>> I believe the work is important and addresses something thats >> >> >> >>> really required (spent too much time debugging why BFD >> flapped!). >> >> >> >> >> >> >> >> agree :-) we should keep the discussion alive. >> >> >> >> >> >> >> >> >> >> >> >>> side Time stamping would have helped in debugging whether the >> >> BFD >> >> >> >>> packet was sent late, or whether the packet was sent on time >> >> >> >>> and also arrived on time but was delayed when passing it up >> >> >> >>> the BFD stack/processor (lay in the RX buffer for tad too >> >> >> >>> long) >> >> >> >> >> >> >> >> well, I can see a point in having the Tx timestamps in the >> >> >> >> packet mainly for the purpose of knowing "this" packet was >> >> >> >> okay/not okay on the Tx side and to correlate it with your local Rx >> measurement. >> >> >> > >> >> >> > Yes, this is one solution if people think BFD delay is needed. >> >> >> > If allow to have Tx timestamps to be carried in the packets, >> >> >> > seems it should be no problem to leave a seat for the Rx >> >> >> > timestamps as well :-). After all, with both Tx and Rx >> >> >> > timestamp, it may simplify the >> >> >> implementation. >> >> >> > >> >> >> >> >> >> >> >> And even this point is less relevant with sequence numbers as >> >> >> >> this number allows the identification of packets and thus the >> >> >> >> correlation of information from the Tx and Rx system. >> >> >> > >> >> >> > Indeed, the sequence number helps a lot for the correlation >> >> >> > between the Tx and Rx system. >> >> >> > >> >> >> > This triggers me think out there should be another solution for >> >> >> > getting the Tx and Rx timestamps without encoding the timestamps >> >> >> > in the BFD >> >> >> packets. >> >> >> > For example, the Tx and Rx systems could just save timestamps >> >> >> > locally or send them to a centralized entity and then use the >> >> >> > sequence numbers to correlate them for further analyzing. >> >> >> > >> >> >> > Best regards, >> >> >> > Mach >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> >> >> >>> Hi Jeff, >> >> >> >>> >> >> >> >>> I vividly remember the original intent of the stability draft >> >> >> >>> was to help debug BFD failures -- to isolate the issue at the >> >> >> >>> RX or the TX side Time stamping would have helped in debugging >> >> >> >>> whether the BFD packet was sent late, or whether the packet >> >> >> >>> was sent on time and also arrived on time but was delayed when >> >> >> >>> passing it up the BFD stack/processor (lay in the RX buffer >> >> >> >>> for tad too long), etc. But then time stamping came with its >> >> >> >>> own set of issues, and was hence dropped from the original draft. >> >> >> >>> >> >> >> >>> Can the authors send a summary on the list on why time >> >> >> >>> stamping was dropped so that we're all clear on that one. >> >> >> >>> >> >> >> >>> The current proposal does help but is not complete. >> >> >> >>> >> >> >> >>> Assume that the RX end loses a BFD session and learns later >> >> >> >>> that it did eventually receive the missing BFD packets (based >> >> >> >>> on the seq >> >> #). >> >> >> >>> How would it know which end was misbehaving? Was it a delay at >> >> >> >>> the TX side, or was it the RX that delayed passing the packets >> >> >> >>> to the BFD process(or). This is usually what we want to debug >> >> >> >>> and i want to understand how this draft with sequence numbers >> >> >> >>> can unequivocally tell me that. >> >> >> >>> >> >> >> >>> I believe the work is important and addresses something thats >> >> >> >>> really required (spent too much time debugging why BFD >> flapped!). >> >> >> >>> Clearly what would help is putting a small section that >> >> >> >>> describes how we can use the sequence numbers to debug what >> >> >> >>> and where >> >> things went wrong. >> >> >> >>> >> >> >> >>> Cheers, Manav >> >> >> >>> >> >> >> >>> >> >> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas >> >> wrote: >> >> >> >>>> draft-ashesh-bfd-stability-01 was presented again during >> >> >> >>>> IETF-91 in Honolulu. The slides can be viewed here: >> >> >> >>>> >> >> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.ppt >> >> >> >>>> x >> >> >> >>>> >> >> >> >>>> To attempt to simplify the presentation, the contentious >> >> >> >>>> portion of the timers were removed from the proposal, leaving >> >> >> >>>> only the sequence numbering for detecting loss of BFD async >> packets. >> >> >> >>>> >> >> >> >>>> When the room was polled to see whether the draft should be >> >> >> >>>> adopted as a WG item, the sense of the room was very quiet. >> >> >> >>>> As promised, this is to inquire for support for this draft on >> >> >> >>>> the WG mailing list to make sure the whole group has a voice. >> >> >> >>>> >> >> >> >>>> It should be noted that post-meeting discussion on the fate >> >> >> >>>> of this draft noted that BFD authentication code points are >> >> >> >>>> plentiful and are available with expert review. Should the >> >> >> >>>> draft authors wish to continue this work as Experimental, >> >> >> >>>> that is an >> >> option. >> >> >> >>>> >> >> >> >>>> -- Jeff >> >> >> >>>> >> >> >> >>> >> >> >> > >> >> > >> > From nobody Thu Nov 27 13:43:11 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 556FE1A002B for ; Thu, 27 Nov 2014 13:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k-brREze97k for ; Thu, 27 Nov 2014 13:43:05 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613271A00D8 for ; Thu, 27 Nov 2014 13:43:05 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so5171986iga.14 for ; Thu, 27 Nov 2014 13:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oV9hBxIKYHbkT+p24JKZI7dRhm9NEMq63KYH8Rg/gxw=; b=snniMc1hDEIJBQbAlVj6Ml/GPYJq2c9TNMqbVtLAvIg/o5X7kx9BDeZJnmPXbNoGnb PbVluY9ZUiP333dKEiCuxsjV81HWsJsodnvdIU3Sy6vuWUc9sAoqePGW84+gPWpuzvf/ /ULWcyXb3ygmeRRHPT8XUQmcldauGMht3sUB8whrEtNacYR4lLhc+2yE3IZC5Ff9bCLD gw8icdLL7xskM0EeiNqem8Bvwj5zKYQrRQp7SPF25nd7M9Vx2cS9oA+wfFjmYW/1RAiP ez8NKuGYrgOi/Xqs2P2/hxiDFA1uylbyrpPmRNOCzHFCu3VLUpsGoqnYyTf2rRNw0oKA MxSg== MIME-Version: 1.0 X-Received: by 10.107.150.137 with SMTP id y131mr4495779iod.11.1417124584484; Thu, 27 Nov 2014 13:43:04 -0800 (PST) Received: by 10.64.89.106 with HTTP; Thu, 27 Nov 2014 13:43:04 -0800 (PST) In-Reply-To: <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> Date: Fri, 28 Nov 2014 03:13:04 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Abhishek Verma To: Santosh P K Content-Type: multipart/alternative; boundary=001a1140f33e75f4520508de07da Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PtaLJmZ_borlassQT29kCbsXTDA 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, 27 Nov 2014 21:43:09 -0000 --001a1140f33e75f4520508de07da Content-Type: text/plain; charset=UTF-8 Hi, > > I think the problem of diagnosing a BFD flap becomes all the more > important > > with BFD authentication turned on since then we have more points where a > > delay can be inserted. > > I agree with this and as a developer have seen this happening. > Agree with Santosh. This mechanism would be most needed when authentication is turned on. Abhishek > > Thanks > Santosh P K > > > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K > > wrote: > > > Manav, > > > This is good question. > > > > > >> Can the authors add some text on how this debugging mechanism would > > >> work if somebody employs BFD authentication? > > > > > > Right now we have considered without authentication (we are setting A > > bit). We should add some text on how we can use both Auth and de bug TLV. > > Is there any suggestion you have? I will get back to you on this. > > > > > > > > > Thanks > > > Santosh P K > > > > > >> > -----Original Message----- > > >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach > > >> > Chen > > >> > Sent: Thursday, November 27, 2014 2:13 PM > > >> > To: Marc Binderberger > > >> > Cc: rtg-bfd@ietf.org > > >> > Subject: RE: BFD stability follow-up from IETF-91 > > >> > > > >> > Hi Marc, > > >> > > > >> >> -----Original Message----- > > >> >> From: Marc Binderberger [mailto:marc@sniff.de] > > >> >> Sent: Thursday, November 27, 2014 1:43 AM > > >> >> To: Mach Chen > > >> >> Cc: Manav Bhatia; rtg-bfd@ietf.org > > >> >> Subject: RE: BFD stability follow-up from IETF-91 > > >> >> > > >> >> Hello Mach, > > >> >> > > >> >> > This triggers me think out there should be another solution for > > >> >> > getting the Tx and Rx timestamps without encoding the timestamps > > >> >> > in the BFD > > >> >> packets. > > >> >> > For example, the Tx and Rx systems could just save timestamps > > >> >> > locally or send them to a centralized entity and then use the > > >> >> > sequence numbers to correlate them for further analyzing. > > >> >> > > >> >> I remember some discussion on NVO3 about how many bits it takes > > >> >> ;-) - could you send the links/draft names you are working on to > this > > list? > > >> >> May be useful for further discussions. > > >> > > > >> > Sure, here is the > > >> > link(http://tools.ietf.org/html/draft-chen-ippm-coloring- > > >> based-ipfpm-framework-02) for the reference. > > >> > > > >> > But here I want to say is that since we have sequence number, we > > >> > may not > > >> need the marking based solution. Suppose that someone want to monitor > > >> the delay of a BFD packet , just record and save the timestamp at the > > >> Tx side, which indexed by the sequence number. Similarly, do the same > > >> at the Rx side. Then based on the timestamps from both Tx and Rx, and > > >> using the sequence number to correlate the timestamps, it can also > > >> provide a way to monitor the delay of the BFD packet. > > >> > > > >> > That means, only if there is sequence number, even if without > > >> > carrying the > > >> timestamp in the BFD packet, BFD packet delay can be measured. > > >> > > > >> > Best regards, > > >> > Mach > > >> > > > >> >> > > >> >> > > >> >> Thanks & Regards, > > >> >> Marc > > >> >> > > >> >> > > >> >> > > >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: > > >> >> > Hi Marc and Manav, > > >> >> > > > >> >> >> -----Original Message----- > > >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > > >> >> >> Marc Binderberger > > >> >> >> Sent: Wednesday, November 26, 2014 4:50 PM > > >> >> >> To: Manav Bhatia > > >> >> >> Cc: rtg-bfd@ietf.org > > >> >> >> Subject: Re: BFD stability follow-up from IETF-91 > > >> >> >> > > >> >> >> Hello Manav, > > >> >> >> > > >> >> >>> I believe the work is important and addresses something thats > > >> >> >>> really required (spent too much time debugging why BFD > > flapped!). > > >> >> >> > > >> >> >> agree :-) we should keep the discussion alive. > > >> >> >> > > >> >> >> > > >> >> >>> side Time stamping would have helped in debugging whether the > > >> BFD > > >> >> >>> packet was sent late, or whether the packet was sent on time > > >> >> >>> and also arrived on time but was delayed when passing it up > > >> >> >>> the BFD stack/processor (lay in the RX buffer for tad too > > >> >> >>> long) > > >> >> >> > > >> >> >> well, I can see a point in having the Tx timestamps in the > > >> >> >> packet mainly for the purpose of knowing "this" packet was > > >> >> >> okay/not okay on the Tx side and to correlate it with your > local Rx > > measurement. > > >> >> > > > >> >> > Yes, this is one solution if people think BFD delay is needed. > > >> >> > If allow to have Tx timestamps to be carried in the packets, > > >> >> > seems it should be no problem to leave a seat for the Rx > > >> >> > timestamps as well :-). After all, with both Tx and Rx > > >> >> > timestamp, it may simplify the > > >> >> implementation. > > >> >> > > > >> >> >> > > >> >> >> And even this point is less relevant with sequence numbers as > > >> >> >> this number allows the identification of packets and thus the > > >> >> >> correlation of information from the Tx and Rx system. > > >> >> > > > >> >> > Indeed, the sequence number helps a lot for the correlation > > >> >> > between the Tx and Rx system. > > >> >> > > > >> >> > This triggers me think out there should be another solution for > > >> >> > getting the Tx and Rx timestamps without encoding the timestamps > > >> >> > in the BFD > > >> >> packets. > > >> >> > For example, the Tx and Rx systems could just save timestamps > > >> >> > locally or send them to a centralized entity and then use the > > >> >> > sequence numbers to correlate them for further analyzing. > > >> >> > > > >> >> > Best regards, > > >> >> > Mach > > >> >> > > > >> >> >> > > >> >> >> > > >> >> >> Regards, Marc > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: > > >> >> >>> Hi Jeff, > > >> >> >>> > > >> >> >>> I vividly remember the original intent of the stability draft > > >> >> >>> was to help debug BFD failures -- to isolate the issue at the > > >> >> >>> RX or the TX side Time stamping would have helped in debugging > > >> >> >>> whether the BFD packet was sent late, or whether the packet > > >> >> >>> was sent on time and also arrived on time but was delayed when > > >> >> >>> passing it up the BFD stack/processor (lay in the RX buffer > > >> >> >>> for tad too long), etc. But then time stamping came with its > > >> >> >>> own set of issues, and was hence dropped from the original > draft. > > >> >> >>> > > >> >> >>> Can the authors send a summary on the list on why time > > >> >> >>> stamping was dropped so that we're all clear on that one. > > >> >> >>> > > >> >> >>> The current proposal does help but is not complete. > > >> >> >>> > > >> >> >>> Assume that the RX end loses a BFD session and learns later > > >> >> >>> that it did eventually receive the missing BFD packets (based > > >> >> >>> on the seq > > >> #). > > >> >> >>> How would it know which end was misbehaving? Was it a delay at > > >> >> >>> the TX side, or was it the RX that delayed passing the packets > > >> >> >>> to the BFD process(or). This is usually what we want to debug > > >> >> >>> and i want to understand how this draft with sequence numbers > > >> >> >>> can unequivocally tell me that. > > >> >> >>> > > >> >> >>> I believe the work is important and addresses something thats > > >> >> >>> really required (spent too much time debugging why BFD > > flapped!). > > >> >> >>> Clearly what would help is putting a small section that > > >> >> >>> describes how we can use the sequence numbers to debug what > > >> >> >>> and where > > >> things went wrong. > > >> >> >>> > > >> >> >>> Cheers, Manav > > >> >> >>> > > >> >> >>> > > >> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas > > >> wrote: > > >> >> >>>> draft-ashesh-bfd-stability-01 was presented again during > > >> >> >>>> IETF-91 in Honolulu. The slides can be viewed here: > > >> >> >>>> > > >> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.ppt > > >> >> >>>> x > > >> >> >>>> > > >> >> >>>> To attempt to simplify the presentation, the contentious > > >> >> >>>> portion of the timers were removed from the proposal, leaving > > >> >> >>>> only the sequence numbering for detecting loss of BFD async > > packets. > > >> >> >>>> > > >> >> >>>> When the room was polled to see whether the draft should be > > >> >> >>>> adopted as a WG item, the sense of the room was very quiet. > > >> >> >>>> As promised, this is to inquire for support for this draft on > > >> >> >>>> the WG mailing list to make sure the whole group has a voice. > > >> >> >>>> > > >> >> >>>> It should be noted that post-meeting discussion on the fate > > >> >> >>>> of this draft noted that BFD authentication code points are > > >> >> >>>> plentiful and are available with expert review. Should the > > >> >> >>>> draft authors wish to continue this work as Experimental, > > >> >> >>>> that is an > > >> option. > > >> >> >>>> > > >> >> >>>> -- Jeff > > >> >> >>>> > > >> >> >>> > > >> >> > > > >> > > > > > --001a1140f33e75f4520508de07da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,


    > I think the problem of diagnosing a BFD flap becomes all the more impo= rtant
    > with BFD authentication turned on since then we have more points where= a
    > delay can be inserted.

    I agree with this and as a developer have seen this happening.

    Agree with Santosh. This mechanism would be = most needed when authentication is turned on.

    Abhi= shek
    =C2=A0

    Thanks
    Santosh P K

    > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K <santoshpk@juniper.net>
    > wrote:
    > > Manav,
    > >=C2=A0 =C2=A0 =C2=A0This is good question.
    > >
    > >> Can the authors add some text on how this debugging mechanism= would
    > >> work if somebody employs BFD authentication?
    > >
    > > Right now we have considered without authentication (we are setti= ng A
    > bit). We should add some text on how we can use both Auth and de bug T= LV.
    > Is there any suggestion you have? I will get back to you on this.
    > >
    > >
    > > Thanks
    > > Santosh P K
    > >
    > >> > -----Original Message-----
    > >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Mach
    > >> > Chen
    > >> > Sent: Thursday, November 27, 2014 2:13 PM
    > >> > To: Marc Binderberger
    > >> > Cc: rtg-bfd@ietf.org=
    > >> > Subject: RE: BFD stability follow-up from IETF-91
    > >> >
    > >> > Hi Marc,
    > >> >
    > >> >> -----Original Message-----
    > >> >> From: Marc Binderberger [mailto:marc@sniff.de]
    > >> >> Sent: Thursday, November 27, 2014 1:43 AM
    > >> >> To: Mach Chen
    > >> >> Cc: Manav Bhatia; rtg-bfd@ietf.org
    > >> >> Subject: RE: BFD stability follow-up from IETF-91 > >> >>
    > >> >> Hello Mach,
    > >> >>
    > >> >> > This triggers me think out there should be anot= her solution for
    > >> >> > getting the Tx and Rx timestamps without encodi= ng the timestamps
    > >> >> > in the BFD
    > >> >> packets.
    > >> >> > For example, the Tx and Rx systems could just s= ave timestamps
    > >> >> > locally or send them to a centralized entity an= d then use the
    > >> >> > sequence numbers to correlate them for further = analyzing.
    > >> >>
    > >> >> I remember some discussion on NVO3 about how many bi= ts it takes
    > >> >> ;-) - could you send the links/draft names you are w= orking on to this
    > list?
    > >> >> May be useful for further discussions.
    > >> >
    > >> > Sure, here is the
    > >> > link(http://tools.ietf.org/html/draft-chen-ippm-= coloring-
    > >> based-ipfpm-framework-02) for the reference.
    > >> >
    > >> > But here I want to say is that since we have sequence nu= mber, we
    > >> > may not
    > >> need the marking based solution. Suppose that someone want to= monitor
    > >> the delay of a BFD packet , just record and save the timestam= p at the
    > >> Tx side, which indexed by the sequence number. Similarly, do = the same
    > >> at the Rx side. Then based on the timestamps from both Tx and= Rx, and
    > >> using the sequence number to correlate the timestamps, it can= also
    > >> provide a way to monitor the delay of the BFD packet.
    > >> >
    > >> > That means, only if there is sequence number, even if wi= thout
    > >> > carrying the
    > >> timestamp in the BFD packet, BFD packet delay can be measured= .
    > >> >
    > >> > Best regards,
    > >> > Mach
    > >> >
    > >> >>
    > >> >>
    > >> >> Thanks & Regards,
    > >> >> Marc
    > >> >>
    > >> >>
    > >> >>
    > >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote:=
    > >> >> > Hi Marc and Manav,
    > >> >> >
    > >> >> >> -----Original Message-----
    > >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of
    > >> >> >> Marc Binderberger
    > >> >> >> Sent: Wednesday, November 26, 2014 4:50 PM<= br> > >> >> >> To: Manav Bhatia
    > >> >> >> Cc: rtg= -bfd@ietf.org
    > >> >> >> Subject: Re: BFD stability follow-up from I= ETF-91
    > >> >> >>
    > >> >> >> Hello Manav,
    > >> >> >>
    > >> >> >>> I believe the work is important and add= resses something thats
    > >> >> >>> really required (spent too much time de= bugging why BFD
    > flapped!).
    > >> >> >>
    > >> >> >> agree :-) we should keep the discussion ali= ve.
    > >> >> >>
    > >> >> >>
    > >> >> >>> side Time stamping would have helped in= debugging whether the
    > >> BFD
    > >> >> >>> packet was sent late, or whether the pa= cket was sent on time
    > >> >> >>> and also arrived on time but was delaye= d when passing it up
    > >> >> >>> the BFD stack/processor (lay in the RX = buffer for tad too
    > >> >> >>> long)
    > >> >> >>
    > >> >> >> well, I can see a point in having the Tx ti= mestamps in the
    > >> >> >> packet mainly for the purpose of knowing &q= uot;this" packet was
    > >> >> >> okay/not okay on the Tx side and to correla= te it with your local Rx
    > measurement.
    > >> >> >
    > >> >> > Yes, this is one solution if people think BFD d= elay is needed.
    > >> >> > If allow to have Tx timestamps to be carried in= the packets,
    > >> >> > seems it should be no problem to leave a seat f= or the Rx
    > >> >> > timestamps as well :-). After all, with both Tx= and Rx
    > >> >> > timestamp, it may simplify the
    > >> >> implementation.
    > >> >> >
    > >> >> >>
    > >> >> >> And even this point is less relevant with s= equence numbers as
    > >> >> >> this number allows the identification of pa= ckets and thus the
    > >> >> >> correlation of information from the Tx and = Rx system.
    > >> >> >
    > >> >> > Indeed, the sequence number helps a lot for the= correlation
    > >> >> > between the Tx and Rx system.
    > >> >> >
    > >> >> > This triggers me think out there should be anot= her solution for
    > >> >> > getting the Tx and Rx timestamps without encodi= ng the timestamps
    > >> >> > in the BFD
    > >> >> packets.
    > >> >> > For example, the Tx and Rx systems could just s= ave timestamps
    > >> >> > locally or send them to a centralized entity an= d then use the
    > >> >> > sequence numbers to correlate them for further = analyzing.
    > >> >> >
    > >> >> > Best regards,
    > >> >> > Mach
    > >> >> >
    > >> >> >>
    > >> >> >>
    > >> >> >> Regards, Marc
    > >> >> >>
    > >> >> >>
    > >> >> >>
    > >> >> >>
    > >> >> >>
    > >> >> >>
    > >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav B= hatia wrote:
    > >> >> >>> Hi Jeff,
    > >> >> >>>
    > >> >> >>> I vividly remember the original intent = of the stability draft
    > >> >> >>> was to help debug BFD failures -- to is= olate the issue at the
    > >> >> >>> RX or the TX side Time stamping would h= ave helped in debugging
    > >> >> >>> whether the BFD packet was sent late, o= r whether the packet
    > >> >> >>> was sent on time and also arrived on ti= me but was delayed when
    > >> >> >>> passing it up the BFD stack/processor (= lay in the RX buffer
    > >> >> >>> for tad too long), etc. But then time s= tamping came with its
    > >> >> >>> own set of issues, and was hence droppe= d from the original draft.
    > >> >> >>>
    > >> >> >>> Can the authors send a summary on the l= ist on why time
    > >> >> >>> stamping was dropped so that we're = all clear on that one.
    > >> >> >>>
    > >> >> >>> The current proposal does help but is n= ot complete.
    > >> >> >>>
    > >> >> >>> Assume that the RX end loses a BFD sess= ion and learns later
    > >> >> >>> that it did eventually receive the miss= ing BFD packets (based
    > >> >> >>> on the seq
    > >> #).
    > >> >> >>> How would it know which end was misbeha= ving? Was it a delay at
    > >> >> >>> the TX side, or was it the RX that dela= yed passing the packets
    > >> >> >>> to the BFD process(or). This is usually= what we want to debug
    > >> >> >>> and i want to understand how this draft= with sequence numbers
    > >> >> >>> can unequivocally tell me that.
    > >> >> >>>
    > >> >> >>> I believe the work is important and add= resses something thats
    > >> >> >>> really required (spent too much time de= bugging why BFD
    > flapped!).
    > >> >> >>> Clearly what would help is putting a sm= all section that
    > >> >> >>> describes how we can use the sequence n= umbers to debug what
    > >> >> >>> and where
    > >> things went wrong.
    > >> >> >>>
    > >> >> >>> Cheers, Manav
    > >> >> >>>
    > >> >> >>>
    > >> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffre= y Haas <jhaas@pfrc.org>
    > >> wrote:
    > >> >> >>>> draft-ashesh-bfd-stability-01 was p= resented again during
    > >> >> >>>> IETF-91 in Honolulu.=C2=A0 The slid= es can be viewed here:
    > >> >> >>>>
    > >> >> >>>> http://www.ietf.or= g/proceedings/91/slides/slides-91-bfd-4.ppt
    > >> >> >>>> x
    > >> >> >>>>
    > >> >> >>>> To attempt to simplify the presenta= tion, the contentious
    > >> >> >>>> portion of the timers were removed = from the proposal, leaving
    > >> >> >>>> only the sequence numbering for det= ecting loss of BFD async
    > packets.
    > >> >> >>>>
    > >> >> >>>> When the room was polled to see whe= ther the draft should be
    > >> >> >>>> adopted as a WG item, the sense of = the room was very quiet.
    > >> >> >>>> As promised, this is to inquire for= support for this draft on
    > >> >> >>>> the WG mailing list to make sure th= e whole group has a voice.
    > >> >> >>>>
    > >> >> >>>> It should be noted that post-meetin= g discussion on the fate
    > >> >> >>>> of this draft noted that BFD authen= tication code points are
    > >> >> >>>> plentiful and are available with ex= pert review.=C2=A0 Should the
    > >> >> >>>> draft authors wish to continue this= work as Experimental,
    > >> >> >>>> that is an
    > >> option.
    > >> >> >>>>
    > >> >> >>>> -- Jeff
    > >> >> >>>>
    > >> >> >>>
    > >> >> >
    > >> >
    > >

    --001a1140f33e75f4520508de07da-- From nobody Thu Nov 27 18:25: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 B5CFB1A047A for ; Thu, 27 Nov 2014 18:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8LX9MGOwcVU for ; Thu, 27 Nov 2014 18:25:18 -0800 (PST) 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 DF54D1A03FF for ; Thu, 27 Nov 2014 18:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3768; q=dns/txt; s=iport; t=1417141518; x=1418351118; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=NWXCU09gvxkSF2tyOG3mYcGtoViNIl0PYNVT/F5Zn/c=; b=JVeVJgZfTzE/fg4qdRbSju7ZDzhdON8OhGyVNBUmZWVNCXvYmZWNwCgV KQF9TNGaHh98/vsOAlSE6tadwcH5QOqCASlwl8316/Dl5AbFS2b573gxI 61qjHgbdZdzyZLSlShIpTahSlUhr6P4STb1q6eqJ4j31uBVquRi4uf80H U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFjcd1StJV2R/2dsb2JhbABRAQmCYyOBLc4PAoEJFgEBAQEBfYQDAQEDAX4LAgEIIiQyJQIEARAKiC8JAdFyAQEBAQEBAQEBAQEBAQEBAQEBARmQHwEqOIMugR8Fi2iEUYIsjVGDWY4EhAqDfEOBdIECAQEB X-IronPort-AV: E=Sophos;i="5.07,473,1413244800"; d="scan'208";a="375959177" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2014 02:25:16 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sAS2PGZ7011690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 02:25:16 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, 27 Nov 2014 20:25:16 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmCALuR+AIABnSoAgAINGWCAAHZvgIAAJV+AgAALRACAAXLjgIAAcEsAgAAV3gCABP9EAIAAPLwQ Date: Fri, 28 Nov 2014 02:25:15 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> In-Reply-To: <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.102.238] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zHPS_Rkru_gY2xXUDgzS__F5puI 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, 28 Nov 2014 02:25:19 -0000 Hi Santosh, [snip] > There few points which are still open. > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > Draft suggest not to use POLL sequence and suggests to increase multiplie= r > first and then interval. If we have hardware implementation and don't wan= t > to check complete packet every time received then change in packet may be > indicated with > POLL bit set. Since this is one to many mapping we can't have a complete > POLL sequence and hence we need to suppress FINAL. Should we be going > with POLL and suppress FINAL by setting desired RX interval set to 0? Ple= ase > suggest any better idea. With removal of all flavors of active tails, it's definitely no longer poss= ible to have P/F sequences. However, I do think that it's a good idea to ha= ve an explicit indication in the packet to communicate to MultipointTail se= ssions that the transmit timers are about to change, this is very helpful f= or some implementations. I'm not clear on what you mean by "... by setting = desired RX interval set to 0?". Can you elaborate? > 2.=A0=A0=A0=A0=A0=A0 Security consideration? > No suggestions. Section 4.7: Sessions on the tail MAY be established dynamically, based on the receipt of a Multipoint BFD Control packet from the head, and are of type MultipointTail. Tail sessions always take the Passive role. One concerning area of this mechanism is the dynamic creation of Multipoint= Tail sessions, as described by above text. This must not become the point o= f DoS attack, and for that we should beef up the texts. In Section 4.8, making the tail demux'ing more stricter may be helpful. [OLD] The head sends Multipoint BFD Control packets over the MultipointHead session with My Discr set to a value bound to the multipoint path, and with Your Discr set to zero. The tails MUST demultiplex these packets based on a combination of the source address and My Discr, which together uniquely identify the head and the multipoint path. [NEW] The head sends Multipoint BFD Control packets over the MultipointHead session with My Discr set to a value bound to the multipoint path, and with Your Discr set to zero. The tails MUST demultiplex these packets based on a combination of the source address, My Discriminator and the identity of the multicast tree which the Multipoint BFD Control packet was received from. Together they uniquely identify the head of the multipoint path. In Security Considerations section, texts like below may be helpful. [NEW] Implementations that creates MultpointTail sessions dynamically upon receipt of Multipoint BFD Control packets MUST implement protective measures to prevent infinite number of MultipointTail session being created. Below lists some points to be considered in such implementations. o If a Multipoint BFD Control packet did not arrive on a multicast tree (ex: on expected interface, with expected MPLS label, etc), then a MultipointTail session should not be created. o If redundant streams are expected for a given multicast stream, then the implementations should not create more MultipointTail sessions than the number of streams. Additionally, when the number of MultipointTail sessions exceeds the number of expected streams, then the implementation should generate an alarm to users to indicate the anomaly. o The implementation should have a reasonable upper bound on the number of MultipointTail sessions that can be created, with the upper bound potentially being computed based on the number of multicast streams that the system is expecting. Thanks! -Nobo From nobody Fri Nov 28 02:51:24 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 ED69D1A1B07 for ; Fri, 28 Nov 2014 02:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.21 X-Spam-Level: ** X-Spam-Status: No, score=2.21 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RELAY_IS_221=2.222, 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 BYDQkVVwkrnW for ; Fri, 28 Nov 2014 02:51:20 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id A6D901A1B11 for ; Fri, 28 Nov 2014 02:51:19 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee1547853a0d3b-21236; Fri, 28 Nov 2014 18:51:12 +0800 (CST) X-RM-TRANSID: 2ee1547853a0d3b-21236 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[223.69.29.130]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee55478539efcd-78c2c; Fri, 28 Nov 2014 18:51:12 +0800 (CST) X-RM-TRANSID: 2ee55478539efcd-78c2c From: "Fan, Peng" To: References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> Subject: RE: BFD stability follow-up from IETF-91 Date: Fri, 28 Nov 2014 18:50:43 +0800 Message-ID: <007701d00af9$28719050$7954b0f0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI18HhYe6tGWNESNbniYme3DP4jzQHs2X59A36o7WAByV58bgMd6y/MAfpW6v8Clvl7hpsy71Tg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uLZxcr35j6g5Mm6AEGFxYCV3i1o 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, 28 Nov 2014 10:51:22 -0000 Hi Jeff, all, I have been following this stability extension from the beginning, and as an operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng From nobody Fri Nov 28 03:53:24 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 01C891A1B39 for ; Fri, 28 Nov 2014 03:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2RNLurAySUT for ; Fri, 28 Nov 2014 03:53:21 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923391A1B07 for ; Fri, 28 Nov 2014 03:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4181; q=dns/txt; s=iport; t=1417175602; x=1418385202; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=SL7zeuhWhz/WwDcwnYowMMAmgKY+fezDMY/M/5BwGTA=; b=iSR8Xh4tbDiHfTVKtaBPwW0JmXTOQUzDQlqishHoZdjvF6ZI08AC6Lwt 25kkj/ZWLJwimY4W0CvUGTIiXIZzM4KyyUmzusfXRayd6lntY0yDe/8+i R+4MURipQEeKCXCwgSf/V3dLhNROFcluETFJHGsFagsbsLRunXOopoMAx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAPdgeFStJA2L/2dsb2JhbABbgkJEgS3FFIh1AoEMFgEBAQEBfYQCAQIEgQsBCAQNAwECKCYTFAkIAgQBEohA0hwBAQEBAQUBAQEBAQEckGoYAoRLBZA5giwFjBeXHIN8b4FIgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208,217";a="100881411" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP; 28 Nov 2014 11:53:21 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sASBrKQM015066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 11:53:20 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 05:53:20 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Fan, Peng" , "rtg-bfd@ietf.org" Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIABbj+AgABtsgA= Date: Fri, 28 Nov 2014 11:53:20 +0000 Message-ID: In-Reply-To: <007701d00af9$28719050$7954b0f0$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.65] Content-Type: multipart/alternative; boundary="_000_D09E5FAC27C51mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/TvxTPvvMjM_dNsYa4vdv4tsBsCA 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, 28 Nov 2014 11:53:23 -0000 --_000_D09E5FAC27C51mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Peng, If the BFD packets are lost, doesn=92t the BFD session go DOWN? Are you say= ing that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng > Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as a= n operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng --_000_D09E5FAC27C51mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <19655BF8D5D2454B92023103E2D7E923@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hi Peng,

    If the BFD packets are lost, doesn=92t the BFD session go DOWN? Are yo= u saying that packet loss is not big enough to make BFD session go DOWN?

    Thanks

    Regards
    Mallik

    From: <Fan>, Peng <fanpeng@chinamobile.com>
    Date: Friday, 28 November 2014 4:20= pm
    To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
    Subject: RE: BFD stability follow-u= p from IETF-91

    Hi Jeff, all,

    I have been following this stability extension from the beginning, and= as an
    operator I would like to express that this draft enables the "adv= anced
    feature" we desire for BFD to provide additional useful informati= on that
    helps operators understand network issues. A relevant use case is dete= cting
    lossy or "quasi-disconnected" links or member LAG links. An = example of such
    situation we experienced was a loosely connected fiber link resulting = in
    continuous, small amount of packet loss. BFD could get the information= of
    lost BFD frames on such unstable link, and probably report when a targ= et
    level is reached, say a certain number of frames are lost over a perio= d or
    among a total number of frames.

    Best regards,
    Peng




     --_000_D09E5FAC27C51mmudigonciscocom_-- From nobody Fri Nov 28 04:34: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 349851A1B47 for ; Fri, 28 Nov 2014 04:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, 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 fT2sMrFItCO8 for ; Fri, 28 Nov 2014 04:34:49 -0800 (PST) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 73E4B1A1AFB for ; Fri, 28 Nov 2014 04:34:47 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee354786bde498-249a5; Fri, 28 Nov 2014 20:34:39 +0800 (CST) X-RM-TRANSID: 2ee354786bde498-249a5 X-RM-SPAM-FLAG: 00000000 Received: from cmccPC (unknown[223.69.29.130]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee954786bdfb77-7acae; Fri, 28 Nov 2014 20:34:39 +0800 (CST) X-RM-TRANSID: 2ee954786bdfb77-7acae From: "Fan, Peng" To: "'MALLIK MUDIGONDA \(mmudigon\)'" , References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> In-Reply-To: Subject: RE: BFD stability follow-up from IETF-91 Date: Fri, 28 Nov 2014 20:34:08 +0800 Message-ID: <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01D00B4A.AA287D10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7LgWhTxiY1ngk8SuipszYBU4dopqfrnhg Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/YkiMCBfhQ2CBoQn8FjY2N3KcupQ 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, 28 Nov 2014 12:34:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01D00B4A.AA287D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mallik, Exactly. Packets may be experiencing slight loss, but the link can hardly be regarded as connected. More importantly, the experience of upper-level applications can be degraded severely (e.g. TCP traffic is not able to go fast in face of even small continuous loss). But what if one BFD frame is lost every three frames? Then the loss rate is 30% on average, which is already a very severe value. Best regards, Peng From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, November 28, 2014 7:53 PM To: Fan, Peng; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Peng, If the BFD packets are lost, doesn't the BFD session go DOWN? Are you saying that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as an operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng ------=_NextPart_000_007F_01D00B4A.AA287D10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Mallik,

     

    Exactly. Packets may be experiencing slight loss, but the link can = hardly be regarded as connected. More importantly, the experience of = upper-level applications can be degraded severely (e.g. TCP traffic is = not able to go fast in face of even small continuous loss). But what if = one BFD frame is lost every three frames? Then the loss rate is 30% on = average, which is already a very severe value.

     

    Best regards,

    Peng

     

    From:= MALLIK = MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
    Sent: = Friday, November 28, 2014 7:53 PM
    To: Fan, Peng; = rtg-bfd@ietf.org
    Subject: Re: BFD stability follow-up from = IETF-91

     

    H= i Peng,

    <= o:p> 

    I= f the BFD packets are lost, doesn’t the BFD session go DOWN? Are = you saying that packet loss is not big enough to make BFD session go = DOWN?

    <= o:p> 

    T= hanks

    <= o:p> 

    R= egards

    M= allik

    <= o:p> 

    From: <Fan>, Peng <fanpeng@chinamobile.com>Date: Friday, 28 November 2014 4:20 pm
    To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
    Subject: = RE: BFD stability follow-up from = IETF-91

    <= o:p> 

    H= i Jeff, all,

    <= o:p> 

    I= have been following this stability extension from the beginning, and as = an

    o= perator I would like to express that this draft enables the = "advanced

    f= eature" we desire for BFD to provide additional useful information = that

    h= elps operators understand network issues. A relevant use case is = detecting

    l= ossy or "quasi-disconnected" links or member LAG links. An = example of such

    s= ituation we experienced was a loosely connected fiber link resulting = in

    c= ontinuous, small amount of packet loss. BFD could get the information = of

    l= ost BFD frames on such unstable link, and probably report when a = target

    l= evel is reached, say a certain number of frames are lost over a period = or

    a= mong a total number of frames.

    <= o:p> 

    B= est regards,

    P= eng

    <= o:p> 

    <= o:p> 

    <= o:p> 

    <= o:p> 

    ------=_NextPart_000_007F_01D00B4A.AA287D10-- From nobody Fri Nov 28 04:52: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 56FAD1A1AD3 for ; Fri, 28 Nov 2014 04:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F6_HiBrFD1z for ; Fri, 28 Nov 2014 04:52:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4AF1A1B49 for ; Fri, 28 Nov 2014 04:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14902; q=dns/txt; s=iport; t=1417179118; x=1418388718; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=xXO0UYWVqavq4Q9SXGR4jBmNhtjwk+FW/vzQ1XM/QWw=; b=DKi16wkB98Zs4yqC8SY1hQOPSm0zoNMgo4jUzZEIn2d3Xuhm1MXTigJy hrjfoEeGpqMCbg59Or5IPfBsdz+KSmN3ThJirwc9uItsGWIdfSvujbgNN XpSoU8ICfpzXJf3gNTxBxSLkUNenBW22vIjKa5B48kCyci3QFzw3M33YG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFADBveFStJA2M/2dsb2JhbABbgkJEUVzFFYh1AoEOFgEBAQEBfYQCAQEBBC1eAQgRAwEBASgmExQJCAIEARKIQNItAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXExcBAoRLBZA5giwFjBeXHIN8b4FIgQIBAQE X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208,217";a="372872472" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 28 Nov 2014 12:51:57 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sASCpuwm012347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 12:51:56 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 06:51:56 -0600 From: "MALLIK MUDIGONDA (mmudigon)" To: "Fan, Peng" , "rtg-bfd@ietf.org" Subject: Re: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIABbj+AgABtsgD//68zAIAAYSuA Date: Fri, 28 Nov 2014 12:51:56 +0000 Message-ID: In-Reply-To: <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.50.65] Content-Type: multipart/alternative; boundary="_000_D09E6DA927C62mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0U9KMMquBsLwzUSdeu35ILlXXCM 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, 28 Nov 2014 12:52:03 -0000 --_000_D09E6DA927C62mmudigonciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Peng. Regards Mallik From: , Peng > Date: Friday, 28 November 2014 6:04 pm To: Cisco Employee >, "rtg-bf= d@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, Exactly. Packets may be experiencing slight loss, but the link can hardly b= e regarded as connected. More importantly, the experience of upper-level ap= plications can be degraded severely (e.g. TCP traffic is not able to go fas= t in face of even small continuous loss). But what if one BFD frame is lost= every three frames? Then the loss rate is 30% on average, which is already= a very severe value. Best regards, Peng From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, November 28, 2014 7:53 PM To: Fan, Peng; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Peng, If the BFD packets are lost, doesn=92t the BFD session go DOWN? Are you say= ing that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng > Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as a= n operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng --_000_D09E6DA927C62mmudigonciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Thanks Peng.

    Regards
    Mallik

    From: <Fan>, Peng <fanpeng@chinamobile.com>
    Date: Friday, 28 November 2014 6:04= pm
    To: Cisco Employee <mmudigon@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
    Subject: RE: BFD stability follow-u= p from IETF-91

    Hi Mallik,

     <= /span>

    Exactly. Packets m= ay be experiencing slight loss, but the link can hardly be regarded as conn= ected. More importantly, the experience of upper-level applications can be degraded severely (e.g. TCP traffic is = not able to go fast in face of even small continuous loss). But what if one= BFD frame is lost every three frames? Then the loss rate is 30% on average= , which is already a very severe value.

     <= /span>

    Best regards,=

    Peng

     <= /span>

     

    Hi Peng,

     

    If the BFD packets are lost, do= esn=92t the BFD session go DOWN? Are you saying that packet loss is not big= enough to make BFD session go DOWN?

     

    Thanks

     

    Regards

    Mallik

     

    From: <Fan>, Peng <fanpeng@chinamobile.com>
    Date: Friday, 28 November 2014 4:20 pm
    To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
    Subject: RE: BFD stability follow-up from IETF-91<= /p>

     

    Hi Jeff, all,=

     

    I have been following this stab= ility extension from the beginning, and as an

    operator I would like to expres= s that this draft enables the "advanced

    feature" we desire for BFD= to provide additional useful information that

    helps operators understand netw= ork issues. A relevant use case is detecting

    lossy or "quasi-disconnect= ed" links or member LAG links. An example of such

    situation we experienced was a = loosely connected fiber link resulting in

    continuous, small amount of pac= ket loss. BFD could get the information of

    lost BFD frames on such unstabl= e link, and probably report when a target

    level is reached, say a certain= number of frames are lost over a period or

    among a total number of frames.=

     

    Best regards,=

    Peng

     

     

     

     

     --_000_D09E6DA927C62mmudigonciscocom_-- From nobody Fri Nov 28 05:04: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 76F4A1A1B49 for ; Fri, 28 Nov 2014 05:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMDOhhNwA3kO for ; Fri, 28 Nov 2014 05:04:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864801A1A6D for ; Fri, 28 Nov 2014 05:04:52 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 28 Nov 2014 13:04:51 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Fri, 28 Nov 2014 13:04:51 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4IAAtdiAgACuVoA= Date: Fri, 28 Nov 2014 13:04:50 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.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: [116.197.184.15] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 04097B7F7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(230783001)(93886004)(106356001)(107046002)(108616004)(20776003)(77156002)(101416001)(92566001)(86362001)(97736003)(33646002)(2656002)(87936001)(64706001)(62966003)(95666004)(99286002)(106116001)(66066001)(105586002)(76176999)(50986999)(107886001)(54356999)(31966008)(122556002)(40100003)(46102003)(74316001)(21056001)(76576001)(120916001)(4396001)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/uQv2HZh6_zL3KPqpmTXPlV9DaUQ 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, 28 Nov 2014 13:04:55 -0000 Nobo, Thanks for your suggestions on last two open items. Please see inline.=20 > > There few points which are still open. > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > Draft suggest not to use POLL sequence and suggests to increase > > multiplier first and then interval. If we have hardware implementation > > and don't want to check complete packet every time received then > > change in packet may be indicated with POLL bit set. Since this is one > > to many mapping we can't have a complete POLL sequence and hence we > > need to suppress FINAL. Should we be going with POLL and suppress > > FINAL by setting desired RX interval set to 0? Please suggest any > > better idea. >=20 > With removal of all flavors of active tails, it's definitely no longer po= ssible to > have P/F sequences. However, I do think that it's a good idea to have an > explicit indication in the packet to communicate to MultipointTail sessio= ns > that the transmit timers are about to change, this is very helpful for so= me > implementations. I'm not clear on what you mean by "... by setting desire= d > RX interval set to 0?". Can you elaborate? >=20 We do not really want to have complete POLL sequence with many to one mappi= ng. So we somehow need to indicate to tails that packet has changed. Only p= ossible way today is with POLL bit set, one way to suppress FINAL being gen= erated from tail is to have desired RX interval to 0. This is something whi= ch goes against RFC 5880 where it says POLL should have FINAL in reply. I w= anted to know if WG has any other alternative solution or if it ok to suppr= ess FINAL. =20 > > 2.=A0=A0=A0=A0=A0=A0 Security consideration? > > No suggestions. >=20 > Section 4.7: >=20 > Sessions on the tail MAY be established dynamically, based on the > receipt of a Multipoint BFD Control packet from the head, and are of > type MultipointTail. Tail sessions always take the Passive role. >=20 > One concerning area of this mechanism is the dynamic creation of > MultipointTail sessions, as described by above text. This must not become > the point of DoS attack, and for that we should beef up the texts. >=20 > In Section 4.8, making the tail demux'ing more stricter may be helpful. >=20 > [OLD] > The head sends Multipoint BFD Control packets over the MultipointHead > session with My Discr set to a value bound to the multipoint path, > and with Your Discr set to zero. The tails MUST demultiplex these > packets based on a combination of the source address and My Discr, > which together uniquely identify the head and the multipoint path. >=20 > [NEW] > The head sends Multipoint BFD Control packets over the MultipointHead > session with My Discr set to a value bound to the multipoint path, > and with Your Discr set to zero. The tails MUST demultiplex these > packets based on a combination of the source address, My > Discriminator and the identity of the multicast tree which the > Multipoint BFD Control packet was received from. Together they > uniquely identify the head of the multipoint path. >=20 > In Security Considerations section, texts like below may be helpful. >=20 > [NEW] > Implementations that creates MultpointTail sessions dynamically upon > receipt of Multipoint BFD Control packets MUST implement protective > measures to prevent infinite number of MultipointTail session being > created. Below lists some points to be considered in such > implementations. >=20 > o If a Multipoint BFD Control packet did not arrive on a multicast > tree (ex: on expected interface, with expected MPLS label, etc), > then a MultipointTail session should not be created. >=20 > o If redundant streams are expected for a given multicast stream, > then the implementations should not create more MultipointTail > sessions than the number of streams. Additionally, when the > number of MultipointTail sessions exceeds the number of expected > streams, then the implementation should generate an alarm to users > to indicate the anomaly. >=20 > o The implementation should have a reasonable upper bound on the > number of MultipointTail sessions that can be created, with the > upper bound potentially being computed based on the number of > multicast streams that the system is expecting. These suggestion are good, I will add this text in draft.=20 Thanks Santosh P K =20 From nobody Fri Nov 28 05:12:08 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 58F1E1A1AFB for ; Fri, 28 Nov 2014 05:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFUOGprdloRM for ; Fri, 28 Nov 2014 05:12:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1691A1AD3 for ; Fri, 28 Nov 2014 05:12:01 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Fri, 28 Nov 2014 13:11:38 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Fri, 28 Nov 2014 13:11:38 +0000 From: Santosh P K To: Manav Bhatia Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIAABKUAgAAczuCAAAvZAIAAAu3AgAAG7QCAAV2GoA== Date: Fri, 28 Nov 2014 13:11:36 +0000 Message-ID: <284b2137c42a402d8e712bb4c7f6c9d6@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.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: [116.197.184.15] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 04097B7F7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(13464003)(377454003)(51704005)(199003)(76176999)(54356999)(31966008)(64706001)(46102003)(15975445006)(101416001)(2656002)(122556002)(15202345003)(40100003)(1720100001)(87936001)(19580395003)(21056001)(19580405001)(561944003)(120916001)(110136001)(33646002)(107046002)(74316001)(106356001)(106116001)(20776003)(108616004)(93886004)(86362001)(99286002)(95666004)(105586002)(92566001)(76576001)(77156002)(50986999)(66066001)(62966003)(1411001)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/I1W6AWqwiP1zA1m33fYuvCABYsc 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, 28 Nov 2014 13:12:06 -0000 SGkgTWFuYXYsDQogICAgICBUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lLiANCg0KPiA+PiB0aGUg c2VxIG51bWJlcnMgYXQgdGhlICplbmQqIG9mIHRoZSBCRkQgcGFja2V0LiBUaGlzIHdvdWxkIG5v dCBiZQ0KPiA+PiBjb3ZlcmVkIGluIHRoZSBMZW5ndGggZmllbGQgY2FycmllZCBpbiB0aGUgQkZE IGhlYWRlciBidXQgd291bGQgYmUNCj4gPj4gYWNjb3VudGVkIGZvciBpbiB0aGUgbGVuZ3RoIGNh cnJpZWQgaW4gdGhlIElQIGhlYWRlci4gVGhlIGNvbmNlcHQgb2YNCj4gPj4gYXR0YWNoaW5nIGEg dHJhaWxlciBpcyBkb2N1bWVudGVkIHdlbGwgYW5kIGlzIHVzZWQgaW4gdGhlIElHUHMuIFJGQw0K PiA+PiA2NTA2IGRlc2NyaWJlcyBvbmUgc3VjaCB0cmFpbGVyDQo+ID4NCj4gPiBZb3UgYXJlIHN1 Z2dlc3RpbmcgdG8gYWRkIHRoZSBkZWJ1ZyB0cmFpbGVyIHdpdGggb3Igd2l0aG91dCBhdXRoZW50 aWNhdGlvbg0KPiByaWdodD8NCj4gDQo+IHdpdGhvdXQuDQoNCklmIHdlIGNhbiBnbyB3aXRoIHRy YWlsZXIgbWV0aG9kIHRoZW4gaXQgY2FuIGJlIGFwcGxpY2FibGUgdG8gYm90aCB3aXRoIGFuZCB3 aXRob3V0IEF1dGggcmlnaHQ/IEkgd2FzIHRoaW5raW5nIGhhdmluZyB0d28gc29sdXRpb24gbWln aHQgY29tcGxpY2F0ZSB0aGluZ3MgOik/IA0KDQoNClRoYW5rcw0KU2FudG9zaCBQIEsgDQoNCj4g Pg0KPiA+PiBPbiBUaHUsIE5vdiAyNywgMjAxNCBhdCA4OjMyIFBNLCBTYW50b3NoIFAgSyA8c2Fu dG9zaHBrQGp1bmlwZXIubmV0Pg0KPiA+PiB3cm90ZToNCj4gPj4gPiBNYW5hdiwNCj4gPj4gPiAg ICAgVGhpcyBpcyBnb29kIHF1ZXN0aW9uLg0KPiA+PiA+DQo+ID4+ID4+IENhbiB0aGUgYXV0aG9y cyBhZGQgc29tZSB0ZXh0IG9uIGhvdyB0aGlzIGRlYnVnZ2luZyBtZWNoYW5pc20NCj4gPj4gPj4g d291bGQgd29yayBpZiBzb21lYm9keSBlbXBsb3lzIEJGRCBhdXRoZW50aWNhdGlvbj8NCj4gPj4g Pg0KPiA+PiA+IFJpZ2h0IG5vdyB3ZSBoYXZlIGNvbnNpZGVyZWQgd2l0aG91dCBhdXRoZW50aWNh dGlvbiAod2UgYXJlIHNldHRpbmcNCj4gPj4gPiBBDQo+ID4+IGJpdCkuIFdlIHNob3VsZCBhZGQg c29tZSB0ZXh0IG9uIGhvdyB3ZSBjYW4gdXNlIGJvdGggQXV0aCBhbmQgZGUgYnVnDQo+IFRMVi4N Cj4gPj4gSXMgdGhlcmUgYW55IHN1Z2dlc3Rpb24geW91IGhhdmU/IEkgd2lsbCBnZXQgYmFjayB0 byB5b3Ugb24gdGhpcy4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gVGhhbmtzDQo+ID4+ID4gU2Fu dG9zaCBQIEsNCj4gPj4gPg0KPiA+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+ID4+ID4gRnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+ID4+ID4+ID4gTWFjaCBDaGVuDQo+ID4+ID4+ID4gU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDI3LCAyMDE0IDI6MTMgUE0NCj4gPj4gPj4gPiBUbzogTWFyYyBCaW5kZXJi ZXJnZXINCj4gPj4gPj4gPiBDYzogcnRnLWJmZEBpZXRmLm9yZw0KPiA+PiA+PiA+IFN1YmplY3Q6 IFJFOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTENCj4gPj4gPj4gPg0KPiA+ PiA+PiA+IEhpIE1hcmMsDQo+ID4+ID4+ID4NCj4gPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gPj4gPj4gRnJvbTogTWFyYyBCaW5kZXJiZXJnZXIgW21haWx0bzptYXJj QHNuaWZmLmRlXQ0KPiA+PiA+PiA+PiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjcsIDIwMTQg MTo0MyBBTQ0KPiA+PiA+PiA+PiBUbzogTWFjaCBDaGVuDQo+ID4+ID4+ID4+IENjOiBNYW5hdiBC aGF0aWE7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gPj4gPj4gPj4gU3ViamVjdDogUkU6IEJGRCBzdGFi aWxpdHkgZm9sbG93LXVwIGZyb20gSUVURi05MQ0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+PiBIZWxs byBNYWNoLA0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+PiA+IFRoaXMgdHJpZ2dlcnMgbWUgdGhpbmsg b3V0IHRoZXJlIHNob3VsZCBiZSBhbm90aGVyIHNvbHV0aW9uDQo+ID4+ID4+ID4+ID4gZm9yIGdl dHRpbmcgdGhlIFR4IGFuZCBSeCB0aW1lc3RhbXBzIHdpdGhvdXQgZW5jb2RpbmcgdGhlDQo+ID4+ ID4+ID4+ID4gdGltZXN0YW1wcyBpbiB0aGUgQkZEDQo+ID4+ID4+ID4+IHBhY2tldHMuDQo+ID4+ ID4+ID4+ID4gRm9yIGV4YW1wbGUsIHRoZSBUeCBhbmQgUnggc3lzdGVtcyBjb3VsZCBqdXN0IHNh dmUgdGltZXN0YW1wcw0KPiA+PiA+PiA+PiA+IGxvY2FsbHkgb3Igc2VuZCB0aGVtIHRvIGEgY2Vu dHJhbGl6ZWQgZW50aXR5IGFuZCB0aGVuIHVzZSB0aGUNCj4gPj4gPj4gPj4gPiBzZXF1ZW5jZSBu dW1iZXJzIHRvIGNvcnJlbGF0ZSB0aGVtIGZvciBmdXJ0aGVyIGFuYWx5emluZy4NCj4gPj4gPj4g Pj4NCj4gPj4gPj4gPj4gSSByZW1lbWJlciBzb21lIGRpc2N1c3Npb24gb24gTlZPMyBhYm91dCBo b3cgbWFueSBiaXRzIGl0IHRha2VzDQo+ID4+ID4+ID4+IDstKSAtIGNvdWxkIHlvdSBzZW5kIHRo ZSBsaW5rcy9kcmFmdCBuYW1lcyB5b3UgYXJlIHdvcmtpbmcgb24NCj4gPj4gPj4gPj4gdG8gdGhp cw0KPiA+PiBsaXN0Pw0KPiA+PiA+PiA+PiBNYXkgYmUgdXNlZnVsIGZvciBmdXJ0aGVyIGRpc2N1 c3Npb25zLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gU3VyZSwgaGVyZSBpcyB0aGUNCj4gPj4gPj4g PiBsaW5rKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4taXBwbS1jb2xvcmlu Zy0NCj4gPj4gPj4gYmFzZWQtaXBmcG0tZnJhbWV3b3JrLTAyKSBmb3IgdGhlIHJlZmVyZW5jZS4N Cj4gPj4gPj4gPg0KPiA+PiA+PiA+IEJ1dCBoZXJlIEkgd2FudCB0byBzYXkgaXMgdGhhdCBzaW5j ZSB3ZSBoYXZlIHNlcXVlbmNlIG51bWJlciwgd2UNCj4gPj4gPj4gPiBtYXkgbm90DQo+ID4+ID4+ IG5lZWQgdGhlIG1hcmtpbmcgYmFzZWQgc29sdXRpb24uIFN1cHBvc2UgdGhhdCBzb21lb25lIHdh bnQgdG8NCj4gPj4gPj4gbW9uaXRvciB0aGUgZGVsYXkgb2YgYSBCRkQgcGFja2V0ICwganVzdCBy ZWNvcmQgYW5kIHNhdmUgdGhlDQo+ID4+ID4+IHRpbWVzdGFtcCBhdCB0aGUgVHggc2lkZSwgd2hp Y2ggaW5kZXhlZCBieSB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KPiA+PiA+PiBTaW1pbGFybHksIGRv IHRoZSBzYW1lIGF0IHRoZSBSeCBzaWRlLiBUaGVuIGJhc2VkIG9uIHRoZQ0KPiA+PiA+PiB0aW1l c3RhbXBzIGZyb20gYm90aCBUeCBhbmQgUngsIGFuZCB1c2luZyB0aGUgc2VxdWVuY2UgbnVtYmVy IHRvDQo+ID4+ID4+IGNvcnJlbGF0ZSB0aGUgdGltZXN0YW1wcywgaXQgY2FuIGFsc28gcHJvdmlk ZSBhIHdheSB0byBtb25pdG9yIHRoZQ0KPiBkZWxheSBvZiB0aGUgQkZEIHBhY2tldC4NCj4gPj4g Pj4gPg0KPiA+PiA+PiA+IFRoYXQgbWVhbnMsIG9ubHkgaWYgdGhlcmUgaXMgc2VxdWVuY2UgbnVt YmVyLCBldmVuIGlmIHdpdGhvdXQNCj4gPj4gPj4gPiBjYXJyeWluZyB0aGUNCj4gPj4gPj4gdGlt ZXN0YW1wIGluIHRoZSBCRkQgcGFja2V0LCBCRkQgcGFja2V0IGRlbGF5IGNhbiBiZSBtZWFzdXJl ZC4NCj4gPj4gPj4gPg0KPiA+PiA+PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4gPj4gPiBNYWNoDQo+ ID4+ID4+ID4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gVGhhbmtzICYgUmVn YXJkcywNCj4gPj4gPj4gPj4gTWFyYw0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+ Pg0KPiA+PiA+PiA+PiBPbiBXZWQsIDI2IE5vdiAyMDE0IDA5OjE3OjMyICswMDAwLCBNYWNoIENo ZW4gd3JvdGU6DQo+ID4+ID4+ID4+ID4gSGkgTWFyYyBhbmQgTWFuYXYsDQo+ID4+ID4+ID4+ID4N Cj4gPj4gPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gPj4gPj4g RnJvbTogUnRnLWJmZCBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+ID4+ID4+ID4+ID4+IE1hcmMgQmluZGVyYmVyZ2VyDQo+ID4+ID4+ID4+ID4+IFNlbnQ6 IFdlZG5lc2RheSwgTm92ZW1iZXIgMjYsIDIwMTQgNDo1MCBQTQ0KPiA+PiA+PiA+PiA+PiBUbzog TWFuYXYgQmhhdGlhDQo+ID4+ID4+ID4+ID4+IENjOiBydGctYmZkQGlldGYub3JnDQo+ID4+ID4+ ID4+ID4+IFN1YmplY3Q6IFJlOiBCRkQgc3RhYmlsaXR5IGZvbGxvdy11cCBmcm9tIElFVEYtOTEN Cj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4gSGVsbG8gTWFuYXYsDQo+ID4+ID4+ID4+ID4+ DQo+ID4+ID4+ID4+ID4+PiBJIGJlbGlldmUgdGhlIHdvcmsgaXMgaW1wb3J0YW50IGFuZCBhZGRy ZXNzZXMgc29tZXRoaW5nDQo+ID4+ID4+ID4+ID4+PiB0aGF0cyByZWFsbHkgcmVxdWlyZWQgKHNw ZW50IHRvbyBtdWNoIHRpbWUgZGVidWdnaW5nIHdoeQ0KPiA+PiA+PiA+PiA+Pj4gQkZEDQo+ID4+ IGZsYXBwZWQhKS4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4gYWdyZWUgOi0pIHdlIHNo b3VsZCBrZWVwIHRoZSBkaXNjdXNzaW9uIGFsaXZlLg0KPiA+PiA+PiA+PiA+Pg0KPiA+PiA+PiA+ PiA+Pg0KPiA+PiA+PiA+PiA+Pj4gc2lkZSBUaW1lIHN0YW1waW5nIHdvdWxkIGhhdmUgaGVscGVk IGluIGRlYnVnZ2luZyB3aGV0aGVyDQo+ID4+ID4+ID4+ID4+PiB0aGUNCj4gPj4gPj4gQkZEDQo+ ID4+ID4+ID4+ID4+PiBwYWNrZXQgd2FzIHNlbnQgbGF0ZSwgb3Igd2hldGhlciB0aGUgcGFja2V0 IHdhcyBzZW50IG9uDQo+ID4+ID4+ID4+ID4+PiB0aW1lIGFuZCBhbHNvIGFycml2ZWQgb24gdGlt ZSBidXQgd2FzIGRlbGF5ZWQgd2hlbiBwYXNzaW5nDQo+ID4+ID4+ID4+ID4+PiBpdCB1cCB0aGUg QkZEIHN0YWNrL3Byb2Nlc3NvciAobGF5IGluIHRoZSBSWCBidWZmZXIgZm9yIHRhZA0KPiA+PiA+ PiA+PiA+Pj4gdG9vDQo+ID4+ID4+ID4+ID4+PiBsb25nKQ0KPiA+PiA+PiA+PiA+Pg0KPiA+PiA+ PiA+PiA+PiB3ZWxsLCBJIGNhbiBzZWUgYSBwb2ludCBpbiBoYXZpbmcgdGhlIFR4IHRpbWVzdGFt cHMgaW4gdGhlDQo+ID4+ID4+ID4+ID4+IHBhY2tldCBtYWlubHkgZm9yIHRoZSBwdXJwb3NlIG9m IGtub3dpbmcgInRoaXMiIHBhY2tldCB3YXMNCj4gPj4gPj4gPj4gPj4gb2theS9ub3Qgb2theSBv biB0aGUgVHggc2lkZSBhbmQgdG8gY29ycmVsYXRlIGl0IHdpdGggeW91cg0KPiA+PiA+PiA+PiA+ PiBsb2NhbCBSeA0KPiA+PiBtZWFzdXJlbWVudC4NCj4gPj4gPj4gPj4gPg0KPiA+PiA+PiA+PiA+ IFllcywgdGhpcyBpcyBvbmUgc29sdXRpb24gaWYgcGVvcGxlIHRoaW5rIEJGRCBkZWxheSBpcyBu ZWVkZWQuDQo+ID4+ID4+ID4+ID4gSWYgYWxsb3cgdG8gaGF2ZSBUeCB0aW1lc3RhbXBzIHRvIGJl IGNhcnJpZWQgaW4gdGhlIHBhY2tldHMsDQo+ID4+ID4+ID4+ID4gc2VlbXMgaXQgc2hvdWxkIGJl IG5vIHByb2JsZW0gdG8gbGVhdmUgYSBzZWF0IGZvciB0aGUgUngNCj4gPj4gPj4gPj4gPiB0aW1l c3RhbXBzIGFzIHdlbGwgOi0pLiBBZnRlciBhbGwsIHdpdGggYm90aCBUeCBhbmQgUngNCj4gPj4g Pj4gPj4gPiB0aW1lc3RhbXAsIGl0IG1heSBzaW1wbGlmeSB0aGUNCj4gPj4gPj4gPj4gaW1wbGVt ZW50YXRpb24uDQo+ID4+ID4+ID4+ID4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4gQW5k IGV2ZW4gdGhpcyBwb2ludCBpcyBsZXNzIHJlbGV2YW50IHdpdGggc2VxdWVuY2UgbnVtYmVycw0K PiA+PiA+PiA+PiA+PiBhcyB0aGlzIG51bWJlciBhbGxvd3MgdGhlIGlkZW50aWZpY2F0aW9uIG9m IHBhY2tldHMgYW5kIHRodXMNCj4gPj4gPj4gPj4gPj4gdGhlIGNvcnJlbGF0aW9uIG9mIGluZm9y bWF0aW9uIGZyb20gdGhlIFR4IGFuZCBSeCBzeXN0ZW0uDQo+ID4+ID4+ID4+ID4NCj4gPj4gPj4g Pj4gPiBJbmRlZWQsIHRoZSBzZXF1ZW5jZSBudW1iZXIgaGVscHMgYSBsb3QgZm9yIHRoZSBjb3Jy ZWxhdGlvbg0KPiA+PiA+PiA+PiA+IGJldHdlZW4gdGhlIFR4IGFuZCBSeCBzeXN0ZW0uDQo+ID4+ ID4+ID4+ID4NCj4gPj4gPj4gPj4gPiBUaGlzIHRyaWdnZXJzIG1lIHRoaW5rIG91dCB0aGVyZSBz aG91bGQgYmUgYW5vdGhlciBzb2x1dGlvbg0KPiA+PiA+PiA+PiA+IGZvciBnZXR0aW5nIHRoZSBU eCBhbmQgUnggdGltZXN0YW1wcyB3aXRob3V0IGVuY29kaW5nIHRoZQ0KPiA+PiA+PiA+PiA+IHRp bWVzdGFtcHMgaW4gdGhlIEJGRA0KPiA+PiA+PiA+PiBwYWNrZXRzLg0KPiA+PiA+PiA+PiA+IEZv ciBleGFtcGxlLCB0aGUgVHggYW5kIFJ4IHN5c3RlbXMgY291bGQganVzdCBzYXZlIHRpbWVzdGFt cHMNCj4gPj4gPj4gPj4gPiBsb2NhbGx5IG9yIHNlbmQgdGhlbSB0byBhIGNlbnRyYWxpemVkIGVu dGl0eSBhbmQgdGhlbiB1c2UgdGhlDQo+ID4+ID4+ID4+ID4gc2VxdWVuY2UgbnVtYmVycyB0byBj b3JyZWxhdGUgdGhlbSBmb3IgZnVydGhlciBhbmFseXppbmcuDQo+ID4+ID4+ID4+ID4NCj4gPj4g Pj4gPj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4+ID4+ID4+ID4gTWFjaA0KPiA+PiA+PiA+PiA+DQo+ ID4+ID4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+DQo+ID4+ID4+ID4+ID4+IFJlZ2FyZHMsIE1hcmMN Cj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4g Pj4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gPj4gT24gV2VkLCAy NiBOb3YgMjAxNCAxMjoyNjo0MSArMDUzMCwgTWFuYXYgQmhhdGlhIHdyb3RlOg0KPiA+PiA+PiA+ PiA+Pj4gSGkgSmVmZiwNCj4gPj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+PiBJIHZpdmlkbHkg cmVtZW1iZXIgdGhlIG9yaWdpbmFsIGludGVudCBvZiB0aGUgc3RhYmlsaXR5DQo+ID4+ID4+ID4+ ID4+PiBkcmFmdCB3YXMgdG8gaGVscCBkZWJ1ZyBCRkQgZmFpbHVyZXMgLS0gdG8gaXNvbGF0ZSB0 aGUNCj4gPj4gPj4gPj4gPj4+IGlzc3VlIGF0IHRoZSBSWCBvciB0aGUgVFggc2lkZSBUaW1lIHN0 YW1waW5nIHdvdWxkIGhhdmUNCj4gPj4gPj4gPj4gPj4+IGhlbHBlZCBpbiBkZWJ1Z2dpbmcgd2hl dGhlciB0aGUgQkZEIHBhY2tldCB3YXMgc2VudCBsYXRlLA0KPiA+PiA+PiA+PiA+Pj4gb3Igd2hl dGhlciB0aGUgcGFja2V0IHdhcyBzZW50IG9uIHRpbWUgYW5kIGFsc28gYXJyaXZlZCBvbg0KPiA+ PiA+PiA+PiA+Pj4gdGltZSBidXQgd2FzIGRlbGF5ZWQgd2hlbiBwYXNzaW5nIGl0IHVwIHRoZSBC RkQNCj4gPj4gPj4gPj4gPj4+IHN0YWNrL3Byb2Nlc3NvciAobGF5IGluIHRoZSBSWCBidWZmZXIg Zm9yIHRhZCB0b28gbG9uZyksDQo+ID4+ID4+ID4+ID4+PiBldGMuIEJ1dCB0aGVuIHRpbWUgc3Rh bXBpbmcgY2FtZSB3aXRoIGl0cyBvd24gc2V0IG9mIGlzc3VlcywNCj4gYW5kIHdhcyBoZW5jZSBk cm9wcGVkIGZyb20gdGhlIG9yaWdpbmFsIGRyYWZ0Lg0KPiA+PiA+PiA+PiA+Pj4NCj4gPj4gPj4g Pj4gPj4+IENhbiB0aGUgYXV0aG9ycyBzZW5kIGEgc3VtbWFyeSBvbiB0aGUgbGlzdCBvbiB3aHkg dGltZQ0KPiA+PiA+PiA+PiA+Pj4gc3RhbXBpbmcgd2FzIGRyb3BwZWQgc28gdGhhdCB3ZSdyZSBh bGwgY2xlYXIgb24gdGhhdCBvbmUuDQo+ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gVGhl IGN1cnJlbnQgcHJvcG9zYWwgZG9lcyBoZWxwIGJ1dCBpcyBub3QgY29tcGxldGUuDQo+ID4+ID4+ ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gQXNzdW1lIHRoYXQgdGhlIFJYIGVuZCBsb3NlcyBhIEJG RCBzZXNzaW9uIGFuZCBsZWFybnMgbGF0ZXINCj4gPj4gPj4gPj4gPj4+IHRoYXQgaXQgZGlkIGV2 ZW50dWFsbHkgcmVjZWl2ZSB0aGUgbWlzc2luZyBCRkQgcGFja2V0cw0KPiA+PiA+PiA+PiA+Pj4g KGJhc2VkIG9uIHRoZSBzZXENCj4gPj4gPj4gIykuDQo+ID4+ID4+ID4+ID4+PiBIb3cgd291bGQg aXQga25vdyB3aGljaCBlbmQgd2FzIG1pc2JlaGF2aW5nPyBXYXMgaXQgYSBkZWxheQ0KPiA+PiA+ PiA+PiA+Pj4gYXQgdGhlIFRYIHNpZGUsIG9yIHdhcyBpdCB0aGUgUlggdGhhdCBkZWxheWVkIHBh c3NpbmcgdGhlDQo+ID4+ID4+ID4+ID4+PiBwYWNrZXRzIHRvIHRoZSBCRkQgcHJvY2Vzcyhvciku IFRoaXMgaXMgdXN1YWxseSB3aGF0IHdlDQo+ID4+ID4+ID4+ID4+PiB3YW50IHRvIGRlYnVnIGFu ZCBpIHdhbnQgdG8gdW5kZXJzdGFuZCBob3cgdGhpcyBkcmFmdCB3aXRoDQo+ID4+ID4+ID4+ID4+ PiBzZXF1ZW5jZSBudW1iZXJzIGNhbiB1bmVxdWl2b2NhbGx5IHRlbGwgbWUgdGhhdC4NCj4gPj4g Pj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+PiBJIGJlbGlldmUgdGhlIHdvcmsgaXMgaW1wb3J0YW50 IGFuZCBhZGRyZXNzZXMgc29tZXRoaW5nDQo+ID4+ID4+ID4+ID4+PiB0aGF0cyByZWFsbHkgcmVx dWlyZWQgKHNwZW50IHRvbyBtdWNoIHRpbWUgZGVidWdnaW5nIHdoeQ0KPiA+PiA+PiA+PiA+Pj4g QkZEDQo+ID4+IGZsYXBwZWQhKS4NCj4gPj4gPj4gPj4gPj4+IENsZWFybHkgd2hhdCB3b3VsZCBo ZWxwIGlzIHB1dHRpbmcgYSBzbWFsbCBzZWN0aW9uIHRoYXQNCj4gPj4gPj4gPj4gPj4+IGRlc2Ny aWJlcyBob3cgd2UgY2FuIHVzZSB0aGUgc2VxdWVuY2UgbnVtYmVycyB0byBkZWJ1Zw0KPiB3aGF0 DQo+ID4+ID4+ID4+ID4+PiBhbmQgd2hlcmUNCj4gPj4gPj4gdGhpbmdzIHdlbnQgd3JvbmcuDQo+ ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+Pj4gQ2hlZXJzLCBNYW5hdg0KPiA+PiA+PiA+PiA+ Pj4NCj4gPj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+ID4+PiBPbiBXZWQsIE5vdiAyNiwgMjAxNCBh dCA1OjQ5IEFNLCBKZWZmcmV5IEhhYXMNCj4gPj4gPj4gPj4gPj4+IDxqaGFhc0BwZnJjLm9yZz4N Cj4gPj4gPj4gd3JvdGU6DQo+ID4+ID4+ID4+ID4+Pj4gZHJhZnQtYXNoZXNoLWJmZC1zdGFiaWxp dHktMDEgd2FzIHByZXNlbnRlZCBhZ2FpbiBkdXJpbmcNCj4gPj4gPj4gPj4gPj4+PiBJRVRGLTkx IGluIEhvbm9sdWx1LiAgVGhlIHNsaWRlcyBjYW4gYmUgdmlld2VkIGhlcmU6DQo+ID4+ID4+ID4+ ID4+Pj4NCj4gPj4gPj4gPj4gPj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkx L3NsaWRlcy9zbGlkZXMtOTEtYmZkLTQuDQo+ID4+ID4+ID4+ID4+Pj4gcHB0DQo+ID4+ID4+ID4+ ID4+Pj4geA0KPiA+PiA+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+Pj4gVG8gYXR0ZW1wdCB0byBz aW1wbGlmeSB0aGUgcHJlc2VudGF0aW9uLCB0aGUgY29udGVudGlvdXMNCj4gPj4gPj4gPj4gPj4+ PiBwb3J0aW9uIG9mIHRoZSB0aW1lcnMgd2VyZSByZW1vdmVkIGZyb20gdGhlIHByb3Bvc2FsLA0K PiA+PiA+PiA+PiA+Pj4+IGxlYXZpbmcgb25seSB0aGUgc2VxdWVuY2UgbnVtYmVyaW5nIGZvciBk ZXRlY3RpbmcgbG9zcyBvZg0KPiA+PiA+PiA+PiA+Pj4+IEJGRCBhc3luYw0KPiA+PiBwYWNrZXRz Lg0KPiA+PiA+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+Pj4gV2hlbiB0aGUgcm9vbSB3YXMgcG9s bGVkIHRvIHNlZSB3aGV0aGVyIHRoZSBkcmFmdCBzaG91bGQNCj4gPj4gPj4gPj4gPj4+PiBiZSBh ZG9wdGVkIGFzIGEgV0cgaXRlbSwgdGhlIHNlbnNlIG9mIHRoZSByb29tIHdhcyB2ZXJ5DQo+IHF1 aWV0Lg0KPiA+PiA+PiA+PiA+Pj4+IEFzIHByb21pc2VkLCB0aGlzIGlzIHRvIGlucXVpcmUgZm9y IHN1cHBvcnQgZm9yIHRoaXMgZHJhZnQNCj4gPj4gPj4gPj4gPj4+PiBvbiB0aGUgV0cgbWFpbGlu ZyBsaXN0IHRvIG1ha2Ugc3VyZSB0aGUgd2hvbGUgZ3JvdXAgaGFzIGENCj4gdm9pY2UuDQo+ID4+ ID4+ID4+ID4+Pj4NCj4gPj4gPj4gPj4gPj4+PiBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBwb3N0 LW1lZXRpbmcgZGlzY3Vzc2lvbiBvbiB0aGUNCj4gPj4gPj4gPj4gPj4+PiBmYXRlIG9mIHRoaXMg ZHJhZnQgbm90ZWQgdGhhdCBCRkQgYXV0aGVudGljYXRpb24gY29kZQ0KPiA+PiA+PiA+PiA+Pj4+ IHBvaW50cyBhcmUgcGxlbnRpZnVsIGFuZCBhcmUgYXZhaWxhYmxlIHdpdGggZXhwZXJ0IHJldmll dy4NCj4gPj4gPj4gPj4gPj4+PiBTaG91bGQgdGhlIGRyYWZ0IGF1dGhvcnMgd2lzaCB0byBjb250 aW51ZSB0aGlzIHdvcmsgYXMNCj4gPj4gPj4gPj4gPj4+PiBFeHBlcmltZW50YWwsIHRoYXQgaXMg YW4NCj4gPj4gPj4gb3B0aW9uLg0KPiA+PiA+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+Pj4gLS0g SmVmZg0KPiA+PiA+PiA+PiA+Pj4+DQo+ID4+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+PiA+DQo+ID4+ ID4+ID4NCj4gPj4gPg0K From nobody Fri Nov 28 05:21:28 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 50DE31A00E8 for ; Fri, 28 Nov 2014 05:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 563bYeKAE_N5 for ; Fri, 28 Nov 2014 05:21:22 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA691A1B45 for ; Fri, 28 Nov 2014 05:21:21 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id uy5so5044781obc.18 for ; Fri, 28 Nov 2014 05:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKUnlwG6Qg8RHhCPjrjhcboxNUuJMGyTDKd5Oqevq2c=; b=WxmPeIKV67iLL9xNoBPN9JF1KtMt938hqqZmTjijdltvim3HHvChcpq+X2SC7BEpO7 Pdhnf8rD+9vXn7qNmb3W4mC/g7+Kj7YRFo1dn3aPdIy0k7tU9isridG1a/YoX2RBp3hw IjeDuxVG0OWDR3zes4TduxtNf42lBgZDkX/8AyYzB2EPjSsYEdQZLUgWm1+ET3BvmURa yTTF/zxhDvwhQt0hq2Il9Gw3Y4PF2tPFPn9HEKjc3/s4o0XERE5Qa43IK4WK1YcjDSvX jRnOoMUNxVlf2Mcu4wit4wzBd7TveHhPHqD3udT1iwpsxI/at3Dth6cxz2wV1Yy6BFHK jVkw== MIME-Version: 1.0 X-Received: by 10.202.231.139 with SMTP id e133mr19309648oih.8.1417180880279; Fri, 28 Nov 2014 05:21:20 -0800 (PST) Received: by 10.76.178.199 with HTTP; Fri, 28 Nov 2014 05:21:20 -0800 (PST) In-Reply-To: <284b2137c42a402d8e712bb4c7f6c9d6@CO2PR0501MB823.namprd05.prod.outlook.com> References: <20141126001931.GJ20330@pfrc> <20141126005023981392.0c488535@sniff.de> <20141126094242449051.c8abfe39@sniff.de> <315041E4211CB84E86EF7C25A2AB583D3476B1C0@xmb-rcd-x15.cisco.com> <05bc7896aad04c0797eb2759c857f949@CO2PR0501MB823.namprd05.prod.outlook.com> <7595889a8ea9451f8043f7587b6d9631@CO2PR0501MB823.namprd05.prod.outlook.com> <284b2137c42a402d8e712bb4c7f6c9d6@CO2PR0501MB823.namprd05.prod.outlook.com> Date: Fri, 28 Nov 2014 18:51:20 +0530 Message-ID: Subject: Re: BFD stability follow-up from IETF-91 From: Manav Bhatia To: Santosh P K Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/spiWHVj8Cwuvyz9xK1aU16AYjJc 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, 28 Nov 2014 13:21:25 -0000 Yes, it will work for both with and without Auth. Cheers, Manav On Fri, Nov 28, 2014 at 6:41 PM, Santosh P K wrote: > Hi Manav, > Thanks. Please see inline. > >> >> the seq numbers at the *end* of the BFD packet. This would not be >> >> covered in the Length field carried in the BFD header but would be >> >> accounted for in the length carried in the IP header. The concept of >> >> attaching a trailer is documented well and is used in the IGPs. RFC >> >> 6506 describes one such trailer >> > >> > You are suggesting to add the debug trailer with or without authentication >> right? >> >> without. > > If we can go with trailer method then it can be applicable to both with and without Auth right? I was thinking having two solution might complicate things :)? > > > Thanks > Santosh P K > >> > >> >> On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K >> >> wrote: >> >> > Manav, >> >> > This is good question. >> >> > >> >> >> Can the authors add some text on how this debugging mechanism >> >> >> would work if somebody employs BFD authentication? >> >> > >> >> > Right now we have considered without authentication (we are setting >> >> > A >> >> bit). We should add some text on how we can use both Auth and de bug >> TLV. >> >> Is there any suggestion you have? I will get back to you on this. >> >> > >> >> > >> >> > Thanks >> >> > Santosh P K >> >> > >> >> >> > -----Original Message----- >> >> >> > From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> >> >> > Mach Chen >> >> >> > Sent: Thursday, November 27, 2014 2:13 PM >> >> >> > To: Marc Binderberger >> >> >> > Cc: rtg-bfd@ietf.org >> >> >> > Subject: RE: BFD stability follow-up from IETF-91 >> >> >> > >> >> >> > Hi Marc, >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Marc Binderberger [mailto:marc@sniff.de] >> >> >> >> Sent: Thursday, November 27, 2014 1:43 AM >> >> >> >> To: Mach Chen >> >> >> >> Cc: Manav Bhatia; rtg-bfd@ietf.org >> >> >> >> Subject: RE: BFD stability follow-up from IETF-91 >> >> >> >> >> >> >> >> Hello Mach, >> >> >> >> >> >> >> >> > This triggers me think out there should be another solution >> >> >> >> > for getting the Tx and Rx timestamps without encoding the >> >> >> >> > timestamps in the BFD >> >> >> >> packets. >> >> >> >> > For example, the Tx and Rx systems could just save timestamps >> >> >> >> > locally or send them to a centralized entity and then use the >> >> >> >> > sequence numbers to correlate them for further analyzing. >> >> >> >> >> >> >> >> I remember some discussion on NVO3 about how many bits it takes >> >> >> >> ;-) - could you send the links/draft names you are working on >> >> >> >> to this >> >> list? >> >> >> >> May be useful for further discussions. >> >> >> > >> >> >> > Sure, here is the >> >> >> > link(http://tools.ietf.org/html/draft-chen-ippm-coloring- >> >> >> based-ipfpm-framework-02) for the reference. >> >> >> > >> >> >> > But here I want to say is that since we have sequence number, we >> >> >> > may not >> >> >> need the marking based solution. Suppose that someone want to >> >> >> monitor the delay of a BFD packet , just record and save the >> >> >> timestamp at the Tx side, which indexed by the sequence number. >> >> >> Similarly, do the same at the Rx side. Then based on the >> >> >> timestamps from both Tx and Rx, and using the sequence number to >> >> >> correlate the timestamps, it can also provide a way to monitor the >> delay of the BFD packet. >> >> >> > >> >> >> > That means, only if there is sequence number, even if without >> >> >> > carrying the >> >> >> timestamp in the BFD packet, BFD packet delay can be measured. >> >> >> > >> >> >> > Best regards, >> >> >> > Mach >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Thanks & Regards, >> >> >> >> Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote: >> >> >> >> > Hi Marc and Manav, >> >> >> >> > >> >> >> >> >> -----Original Message----- >> >> >> >> >> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of >> >> >> >> >> Marc Binderberger >> >> >> >> >> Sent: Wednesday, November 26, 2014 4:50 PM >> >> >> >> >> To: Manav Bhatia >> >> >> >> >> Cc: rtg-bfd@ietf.org >> >> >> >> >> Subject: Re: BFD stability follow-up from IETF-91 >> >> >> >> >> >> >> >> >> >> Hello Manav, >> >> >> >> >> >> >> >> >> >>> I believe the work is important and addresses something >> >> >> >> >>> thats really required (spent too much time debugging why >> >> >> >> >>> BFD >> >> flapped!). >> >> >> >> >> >> >> >> >> >> agree :-) we should keep the discussion alive. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> side Time stamping would have helped in debugging whether >> >> >> >> >>> the >> >> >> BFD >> >> >> >> >>> packet was sent late, or whether the packet was sent on >> >> >> >> >>> time and also arrived on time but was delayed when passing >> >> >> >> >>> it up the BFD stack/processor (lay in the RX buffer for tad >> >> >> >> >>> too >> >> >> >> >>> long) >> >> >> >> >> >> >> >> >> >> well, I can see a point in having the Tx timestamps in the >> >> >> >> >> packet mainly for the purpose of knowing "this" packet was >> >> >> >> >> okay/not okay on the Tx side and to correlate it with your >> >> >> >> >> local Rx >> >> measurement. >> >> >> >> > >> >> >> >> > Yes, this is one solution if people think BFD delay is needed. >> >> >> >> > If allow to have Tx timestamps to be carried in the packets, >> >> >> >> > seems it should be no problem to leave a seat for the Rx >> >> >> >> > timestamps as well :-). After all, with both Tx and Rx >> >> >> >> > timestamp, it may simplify the >> >> >> >> implementation. >> >> >> >> > >> >> >> >> >> >> >> >> >> >> And even this point is less relevant with sequence numbers >> >> >> >> >> as this number allows the identification of packets and thus >> >> >> >> >> the correlation of information from the Tx and Rx system. >> >> >> >> > >> >> >> >> > Indeed, the sequence number helps a lot for the correlation >> >> >> >> > between the Tx and Rx system. >> >> >> >> > >> >> >> >> > This triggers me think out there should be another solution >> >> >> >> > for getting the Tx and Rx timestamps without encoding the >> >> >> >> > timestamps in the BFD >> >> >> >> packets. >> >> >> >> > For example, the Tx and Rx systems could just save timestamps >> >> >> >> > locally or send them to a centralized entity and then use the >> >> >> >> > sequence numbers to correlate them for further analyzing. >> >> >> >> > >> >> >> >> > Best regards, >> >> >> >> > Mach >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Regards, Marc >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote: >> >> >> >> >>> Hi Jeff, >> >> >> >> >>> >> >> >> >> >>> I vividly remember the original intent of the stability >> >> >> >> >>> draft was to help debug BFD failures -- to isolate the >> >> >> >> >>> issue at the RX or the TX side Time stamping would have >> >> >> >> >>> helped in debugging whether the BFD packet was sent late, >> >> >> >> >>> or whether the packet was sent on time and also arrived on >> >> >> >> >>> time but was delayed when passing it up the BFD >> >> >> >> >>> stack/processor (lay in the RX buffer for tad too long), >> >> >> >> >>> etc. But then time stamping came with its own set of issues, >> and was hence dropped from the original draft. >> >> >> >> >>> >> >> >> >> >>> Can the authors send a summary on the list on why time >> >> >> >> >>> stamping was dropped so that we're all clear on that one. >> >> >> >> >>> >> >> >> >> >>> The current proposal does help but is not complete. >> >> >> >> >>> >> >> >> >> >>> Assume that the RX end loses a BFD session and learns later >> >> >> >> >>> that it did eventually receive the missing BFD packets >> >> >> >> >>> (based on the seq >> >> >> #). >> >> >> >> >>> How would it know which end was misbehaving? Was it a delay >> >> >> >> >>> at the TX side, or was it the RX that delayed passing the >> >> >> >> >>> packets to the BFD process(or). This is usually what we >> >> >> >> >>> want to debug and i want to understand how this draft with >> >> >> >> >>> sequence numbers can unequivocally tell me that. >> >> >> >> >>> >> >> >> >> >>> I believe the work is important and addresses something >> >> >> >> >>> thats really required (spent too much time debugging why >> >> >> >> >>> BFD >> >> flapped!). >> >> >> >> >>> Clearly what would help is putting a small section that >> >> >> >> >>> describes how we can use the sequence numbers to debug >> what >> >> >> >> >>> and where >> >> >> things went wrong. >> >> >> >> >>> >> >> >> >> >>> Cheers, Manav >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas >> >> >> >> >>> >> >> >> wrote: >> >> >> >> >>>> draft-ashesh-bfd-stability-01 was presented again during >> >> >> >> >>>> IETF-91 in Honolulu. The slides can be viewed here: >> >> >> >> >>>> >> >> >> >> >>>> http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4. >> >> >> >> >>>> ppt >> >> >> >> >>>> x >> >> >> >> >>>> >> >> >> >> >>>> To attempt to simplify the presentation, the contentious >> >> >> >> >>>> portion of the timers were removed from the proposal, >> >> >> >> >>>> leaving only the sequence numbering for detecting loss of >> >> >> >> >>>> BFD async >> >> packets. >> >> >> >> >>>> >> >> >> >> >>>> When the room was polled to see whether the draft should >> >> >> >> >>>> be adopted as a WG item, the sense of the room was very >> quiet. >> >> >> >> >>>> As promised, this is to inquire for support for this draft >> >> >> >> >>>> on the WG mailing list to make sure the whole group has a >> voice. >> >> >> >> >>>> >> >> >> >> >>>> It should be noted that post-meeting discussion on the >> >> >> >> >>>> fate of this draft noted that BFD authentication code >> >> >> >> >>>> points are plentiful and are available with expert review. >> >> >> >> >>>> Should the draft authors wish to continue this work as >> >> >> >> >>>> Experimental, that is an >> >> >> option. >> >> >> >> >>>> >> >> >> >> >>>> -- Jeff >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> > >> >> >> > >> >> > From nobody Fri Nov 28 05:28:28 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 087F81A1A73 for ; Fri, 28 Nov 2014 05:28:26 -0800 (PST) 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 eXW-R1IrdrA7 for ; Fri, 28 Nov 2014 05:28:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA351A1B26 for ; Fri, 28 Nov 2014 05:28:21 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128132821.5499.39304.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 05:28:21 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/zFX770cINUmt3QAvpUs3RacQAuA 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, 28 Nov 2014 13:28:26 -0000 Changed milestone "Submit the BFD Seamless Use Case document to the IESG to be considered as a Proposed Standard", set due date to December 2014 from November 2014. URL: http://datatracker.ietf.org/wg/bfd/charter/ From nobody Fri Nov 28 05:41: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 9F4BD1A1A6C for ; Fri, 28 Nov 2014 05:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LvGQ5Qpu5Wo for ; Fri, 28 Nov 2014 05:41:34 -0800 (PST) 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 3C7DC1A1B42 for ; Fri, 28 Nov 2014 05:41:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6382; q=dns/txt; s=iport; t=1417182093; x=1418391693; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OZOJ9J8K4a4vFIYjxYoDi5t/Qd3GGWa/J3sQVa9ZkcI=; b=AkMD/x7lfafYHZgkWfUxAgomFau79YOYPKJn4wA25tQJnQk0SsnbMorj Sr9d4zU22+h9TmZKEEJ3r8zopOC3hV7h0vSCz/iqRCse051J1mz+WmKhe 6UlFlxWLf4CNaXxX1FE1j6RiIBeKuLLKLILJ1+gQOxr00VQfnuefUH2yb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAPJ6eFStJA2K/2dsb2JhbABRAQmCYyOBLc4KAoENFgEBAQEBfYQCAQEBAwF+BwQCAQgRBAEBCx0HMhQJCAIEARACCBOIHAkB0iEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXkB8BKjgGgyiBHwEEi2iEUYIsjVGDWYpIgzyECoN8QyyBSIECAQEB X-IronPort-AV: E=Sophos;i="5.07,477,1413244800"; d="scan'208";a="100915201" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 28 Nov 2014 13:41:32 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sASDfWXC030467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 13:41:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 07:41:31 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmCALuR+AIABnSoAgAINGWCAAHZvgIAAJV+AgAALRACAAXLjgIAAcEsAgAAV3gCABP9EAIAAPLwQgAEl1AD//6MF8A== Date: Fri, 28 Nov 2014 13:41:30 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.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.228] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_TXRgHxGUquyWeWfKaWw9JI7dHE 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, 28 Nov 2014 13:41:35 -0000 Hi Santosh, > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Friday, November 28, 2014 8:05 AM > To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; > Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Nobo, > Thanks for your suggestions on last two open items. Please see inline. >=20 > > > There few points which are still open. > > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > > Draft suggest not to use POLL sequence and suggests to increase > > > multiplier first and then interval. If we have hardware > > > implementation and don't want to check complete packet every time > > > received then change in packet may be indicated with POLL bit set. > > > Since this is one to many mapping we can't have a complete POLL > > > sequence and hence we need to suppress FINAL. Should we be going > > > with POLL and suppress FINAL by setting desired RX interval set to > > > 0? Please suggest any better idea. > > > > With removal of all flavors of active tails, it's definitely no longer > > possible to have P/F sequences. However, I do think that it's a good > > idea to have an explicit indication in the packet to communicate to > > MultipointTail sessions that the transmit timers are about to change, > > this is very helpful for some implementations. I'm not clear on what > > you mean by "... by setting desired RX interval set to 0?". Can you > elaborate? > > >=20 > We do not really want to have complete POLL sequence with many to one > mapping. So we somehow need to indicate to tails that packet has changed. > Only possible way today is with POLL bit set, one way to suppress FINAL > being generated from tail is to have desired RX interval to 0. This is > something which goes against RFC 5880 where it says POLL should have > FINAL in reply. I wanted to know if WG has any other alternative solution= or > if it ok to suppress FINAL. To me, having sufficient texts to describe MultipointHead sending P bit and= MultipointTail suppressing F bit (since it never sends BFD packets to head= ) is sufficient. In other words, I don't see a need to tweak other bits to = make sure that MultipointTail sessions do not send F bit. The only other po= int to consider is, how long does MultipointHead wait before applying the c= hange. If we take an extreme example: - Current interval is 15 ms. - Current detection multiplier is 3. - MultipointHead wants to change the interval to 2 sec. - MultipointHead sends P bit in next 3 BFD packets (3 x 15ms). - MultipointHead update the interval to 2 sec. - MultipointTail does not receive the first 2 P bit (for whatever reason) b= ut receives the last P bit. Now MultipointTail has 45ms to update the detection timer (since next packe= t is expected 2 sec later). Under scaled number of sessions, does this raise any concerns to implementa= tions? In other words: - Should MultipointHead send P bit set in next "multiplier" number of packe= ts and change the interval at that point? - Should the document specify a minimal time (say 1 second) before Multipoi= ntHead can change the interval? Something to think about in implementations. >=20 >=20 >=20 > > > 2.=A0=A0=A0=A0=A0=A0 Security consideration? > > > No suggestions. > > > > Section 4.7: > > > > Sessions on the tail MAY be established dynamically, based on the > > receipt of a Multipoint BFD Control packet from the head, and are of > > type MultipointTail. Tail sessions always take the Passive role. > > > > One concerning area of this mechanism is the dynamic creation of > > MultipointTail sessions, as described by above text. This must not > > become the point of DoS attack, and for that we should beef up the text= s. > > > > In Section 4.8, making the tail demux'ing more stricter may be helpful. > > > > [OLD] > > The head sends Multipoint BFD Control packets over the MultipointHea= d > > session with My Discr set to a value bound to the multipoint path, > > and with Your Discr set to zero. The tails MUST demultiplex these > > packets based on a combination of the source address and My Discr, > > which together uniquely identify the head and the multipoint path. > > > > [NEW] > > The head sends Multipoint BFD Control packets over the MultipointHea= d > > session with My Discr set to a value bound to the multipoint path, > > and with Your Discr set to zero. The tails MUST demultiplex these > > packets based on a combination of the source address, My > > Discriminator and the identity of the multicast tree which the > > Multipoint BFD Control packet was received from. Together they > > uniquely identify the head of the multipoint path. > > > > In Security Considerations section, texts like below may be helpful. > > > > [NEW] > > Implementations that creates MultpointTail sessions dynamically upon > > receipt of Multipoint BFD Control packets MUST implement protective > > measures to prevent infinite number of MultipointTail session being > > created. Below lists some points to be considered in such > > implementations. > > > > o If a Multipoint BFD Control packet did not arrive on a multicast > > tree (ex: on expected interface, with expected MPLS label, etc), > > then a MultipointTail session should not be created. > > > > o If redundant streams are expected for a given multicast stream, > > then the implementations should not create more MultipointTail > > sessions than the number of streams. Additionally, when the > > number of MultipointTail sessions exceeds the number of expected > > streams, then the implementation should generate an alarm to user= s > > to indicate the anomaly. > > > > o The implementation should have a reasonable upper bound on the > > number of MultipointTail sessions that can be created, with the > > upper bound potentially being computed based on the number of > > multicast streams that the system is expecting. >=20 > These suggestion are good, I will add this text in draft. Thanks! -Nobo >=20 >=20 >=20 > Thanks > Santosh P K >=20 >=20 >=20 >=20 From nobody Fri Nov 28 09:31:40 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 C02971A008A for ; Fri, 28 Nov 2014 09:31:38 -0800 (PST) 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 rr40AvuDAAQg for ; Fri, 28 Nov 2014 09:31:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A20FC1A00D6 for ; Fri, 28 Nov 2014 09:31:36 -0800 (PST) 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.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141128173136.16597.54049.idtracker@ietfa.amsl.com> Date: Fri, 28 Nov 2014 09:31:36 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/xIJu1Vq0E6eu4lu1VmQ7BvdZ1FI 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, 28 Nov 2014 17:31:39 -0000 Changed milestone "Submit the BFD Seamless IP draft 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 nobody Fri Nov 28 10:45:32 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 365811A0119 for ; Fri, 28 Nov 2014 10:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zuy0KceE-rY0 for ; Fri, 28 Nov 2014 10:45:26 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D7FDA1A0110 for ; Fri, 28 Nov 2014 10:45:24 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 52297C16E; Fri, 28 Nov 2014 13:45:24 -0500 (EST) Date: Fri, 28 Nov 2014 13:45:24 -0500 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014) Message-ID: <20141128184524.GA1274@pfrc> References: <20141126005002.GL20330@pfrc> <20141125234256188865.aafe8a3f@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141125234256188865.aafe8a3f@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/hwrU5EMJrlxPhyRwkXBWNRUGppA 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, 28 Nov 2014 18:45:31 -0000 Marc, On Tue, Nov 25, 2014 at 11:42:56PM -0800, Marc Binderberger wrote: > Long story short: while I can see this draft becoming a workgroup draft I > find the poll - well - premature. The poll is for adoption. The document is done when it is done. It's my personal expectation that its life in draft form is short, not the WG's. If you have feedback that suggests need for additional work, that's exactly the kind of thing I'm suggesting you contribute! -- Jeff From nobody Fri Nov 28 11:37: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 7DCBF1A0149 for ; Fri, 28 Nov 2014 11:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDBR-Z43fbzC for ; Fri, 28 Nov 2014 11:36:51 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC5D1A0126 for ; Fri, 28 Nov 2014 11:36:50 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-f1-547872d5d508 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.0B.25146.5D278745; Fri, 28 Nov 2014 14:04:21 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:36:31 -0500 From: Gregory Mirsky To: "Fan, Peng" , "'MALLIK MUDIGONDA (mmudigon)'" , "rtg-bfd@ietf.org" Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9Pg Date: Fri, 28 Nov 2014 19:36:30 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> In-Reply-To: <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8998E7eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPoO7VoooQg5bTOhbrG16wWxx5dYzZ 4vOfbYwOzB7zLixk85jyeyOrx5IlP5kCmKO4bFJSczLLUov07RK4Mi5eu8lS8KuXseL5BtUG xp31XYycHBICJhLfXn5ghrDFJC7cW8/WxcjFISRwhFHixtpFUM5yRolt9+eyg1SxCRhJvNjY ww6SEBHoYJRY+nIpWLuwgKHEqu7FYEUiQEXHZsyFsvMk1uz4zwJiswioSvTtmAtkc3DwCvhK HDhQCrFgOqNEy5U2sBpOATuJJ12zmUBsRqCTvp9aA2YzC4hL3HoynwniVAGJJXvOQ50tKvHy 8T9WCFtJYs7ra8wQ9fkSp+dOAovzCghKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti 2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAiMqmMSbI47GBd8sjzEKMDBqMTD+2FNeYgQ a2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgl7FJK6qVusim3 pR6NuHS8OSR77e2naQe99t2uFPpzSuzzhqzwxyxT5mgFP85/Gdede/l38bs/+xa+X/rp4fQj DdFPfB9dc24V/H5fziitYqXW3EfrNn09W1r2pOX0y+jVGYJcwlkqcnw+nNMt3m1X9XCd62Nj GxNxp+ngRckns6ZpbIjfIZmixFKckWioxVxUnAgA5OrXeosCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/u0--Llp4WHZsJls2lUA9VWR4WW8 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, 28 Nov 2014 19:37:00 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B8998E7eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, this is very interesting scenario. I think that if BFD experiences ~30% pac= ket loss, then highly likely so are affected other applications. Then it is= not just BFD issue but condition that should be detected by performance m= easurement method, whether active or passive packet loss measurement. I'm convinced that overloading BFD with performance measurement provisions = is counter-productive and is inappropriate. Regards, Greg From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng Sent: Friday, November 28, 2014 4:34 AM To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Mallik, Exactly. Packets may be experiencing slight loss, but the link can hardly b= e regarded as connected. More importantly, the experience of upper-level ap= plications can be degraded severely (e.g. TCP traffic is not able to go fas= t in face of even small continuous loss). But what if one BFD frame is lost= every three frames? Then the loss rate is 30% on average, which is already= a very severe value. Best regards, Peng From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com] Sent: Friday, November 28, 2014 7:53 PM To: Fan, Peng; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 Hi Peng, If the BFD packets are lost, doesn't the BFD session go DOWN? Are you sayin= g that packet loss is not big enough to make BFD session go DOWN? Thanks Regards Mallik From: , Peng > Date: Friday, 28 November 2014 4:20 pm To: "rtg-bfd@ietf.org" > Subject: RE: BFD stability follow-up from IETF-91 Hi Jeff, all, I have been following this stability extension from the beginning, and as a= n operator I would like to express that this draft enables the "advanced feature" we desire for BFD to provide additional useful information that helps operators understand network issues. A relevant use case is detecting lossy or "quasi-disconnected" links or member LAG links. An example of such situation we experienced was a loosely connected fiber link resulting in continuous, small amount of packet loss. BFD could get the information of lost BFD frames on such unstable link, and probably report when a target level is reached, say a certain number of frames are lost over a period or among a total number of frames. Best regards, Peng --_000_7347100B5761DC41A166AC17F22DF1121B8998E7eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Peng,

    this is very interesting = scenario. I think that if BFD experiences ~30% packet loss, then highly lik= ely so are affected other applications. Then it is not just BFD issue but condition that should be detected  by performance measu= rement method, whether active or passive packet loss measurement.

    I’m convinced that = overloading BFD with performance measurement provisions is counter-producti= ve and is inappropriate.

     <= /p>

        &= nbsp;           Regards,<= o:p>

        &= nbsp;           &nbs= p;            &= nbsp;  Greg

     <= /p>

    From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng
    Sent: Friday, November 28, 2014 4:34 AM
    To: 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org
    Subject: RE: BFD stability follow-up from IETF-91    <= /p>

     

    From: MALLIK MUDIGONDA (mmudigon) [= mailto:mmudigon@cisco.com]
    Sent: Friday, November 28, 2014 7:53 PM
    To: Fan, Peng; rtg-bfd@ietf.org<= /a>
    Subject: Re: BFD stability follow-up from IETF-91    <= /p>

    &nbs= p;

    Hi= Peng,

     

    If= the BFD packets are lost, doesn’t the BFD session go DOWN? Are you s= aying that packet loss is not big enough to make BFD session go DOWN?

     

    Th= anks

     

    Re= gards

    Ma= llik

     

    From: <Fan>,= Peng <fanpeng@chinamobile.co= m>
    Date: Friday, 28 November 2014 4:20 pm
    To: "rtg-bfd@ietf.org&q= uot; <rtg-bfd@ietf.org>
    Subject: RE: BFD stability follow-up from IETF-91<= /p>

     

    Hi= Jeff, all,

     

    I = have been following this stability extension from the beginning, and as an<= o:p>

    op= erator I would like to express that this draft enables the "advanced

    fe= ature" we desire for BFD to provide additional useful information that=

    he= lps operators understand network issues. A relevant use case is detecting

    lo= ssy or "quasi-disconnected" links or member LAG links. An example= of such

    si= tuation we experienced was a loosely connected fiber link resulting in=

    co= ntinuous, small amount of packet loss. BFD could get the information of

    lo= st BFD frames on such unstable link, and probably report when a target=

    le= vel is reached, say a certain number of frames are lost over a period or

    am= ong a total number of frames.

     

    Be= st regards,

    Pe= ng

     

     

     

     

    --_000_7347100B5761DC41A166AC17F22DF1121B8998E7eusaamb103erics_-- From nobody Fri Nov 28 11:43:39 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 5BA2C1A0126 for ; Fri, 28 Nov 2014 11:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7ACge6yslbs for ; Fri, 28 Nov 2014 11:43:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A6CD81A0113 for ; Fri, 28 Nov 2014 11:43:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 734E7C16E; Fri, 28 Nov 2014 14:43:37 -0500 (EST) Date: Fri, 28 Nov 2014 14:43:37 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IPR Reminder (was Re: Adoption poll for draft-grmas-bfd-rfc5884-clarifications (ends December 12, 2014)) Message-ID: <20141128194337.GE1274@pfrc> References: <20141126005002.GL20330@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141126005002.GL20330@pfrc> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5HGZuOcsQdP0cCX_KgCTRcnJq6s 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, 28 Nov 2014 19:43:38 -0000 The chairs would like to take this opportunity to remind everyone that if you have IPR on this Internet-draft - or any other draft - to disclose it as soon as possible. -- Jeff & Nobo On Tue, Nov 25, 2014 at 07:50:02PM -0500, Jeffrey Haas wrote: > Working Group, > > Clarifications to RFC 5884, draft-grmas-bfd-rfc5884-clarifications, was > presented at IETF-91 in Honolulu and was positively received. We'd like to > ask the Working Group whether we should formally adopt this draft as a > Working Group item. > > Please indicate your support or lack thereof to the mail list by > December 12, 2014. > > Also, please supply feedback to the authors. I believe the perception of > this document is that it's very nearly complete and thus should have a short > lifetime prior to publication as an RFC. > > -- Jeff & Nobo. From nobody Fri Nov 28 11:55:40 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 56A931A0143 for ; Fri, 28 Nov 2014 11:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f5DV8xWnTO3 for ; Fri, 28 Nov 2014 11:55:37 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCF31A0196 for ; Fri, 28 Nov 2014 11:55:37 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 161FAC16E; Fri, 28 Nov 2014 14:55:37 -0500 (EST) Date: Fri, 28 Nov 2014 14:55:37 -0500 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: BFD stability follow-up from IETF-91 Message-ID: <20141128195536.GG1274@pfrc> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OEP_79Sc80OpvTi-1efIW7NUuCo 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, 28 Nov 2014 19:55:38 -0000 [Speaking as an individual contributor...] On Fri, Nov 28, 2014 at 07:36:30PM +0000, Gregory Mirsky wrote: > this is very interesting scenario. I think that if BFD experiences ~30% packet loss, then highly likely so are affected other applications. Then it is not just BFD issue but condition that should be detected by performance measurement method, whether active or passive packet loss measurement. > I'm convinced that overloading BFD with performance measurement provisions is counter-productive and is inappropriate. My opinion is about halfway between your opinion, Greg. I agree that we wish to be very cautious about overloading BFD with components that are in other OAM mechanisms. Among my desire for such caution is that IEEE has expressed interest in not having us step on their technologies and this would create paperwork for the chairs. :-) But where I think we diverge slightly comes from experience in helping the working group and vendors wend their way through implementing BFD for LAG. During that discussion, it was very clear that depending on the vendor, the architecture and sometimes specific chipsets that "BFD" lived in very different pieces of underlying architecture. What this means is that trying to do very tight timing things will run into practical issues in having to figure out what the perspective of the timings are. Is it some underlying L2? L3? Something between? At what point do you realize you are measuring contradictory things? But similarly, when trying to measure and account for loss, having some data is useful simply because it helps you determine that the component that is *responsible for BFD* may be experiencing loss. Depending on your architecture, this may be the underlying layer-1, layer-2 or something else. In such cases, the lower-layer OAM is better to troubleshoot. But in cases where your lower-layer OAM doesn't indicate the loss, you still need to understand that there is BFD-level loss. I encourage participants in this discussion to remember this detail: We are trying to help measure BFD loss. Trying to read too much detail into what that means outside of BFD may lead you to erroneous conclusions depending on a given implementation. Thus, consider what is best for BFD. -- Jeff From nobody Fri Nov 28 19:18:03 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 013141A0395 for ; Fri, 28 Nov 2014 19:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTxRWu45uuGk for ; Fri, 28 Nov 2014 19:17:58 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84051A0404 for ; Fri, 28 Nov 2014 19:17:57 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-e0-5478dee9e300 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 49.34.25146.9EED8745; Fri, 28 Nov 2014 21:45:30 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 22:17:55 -0500 From: Gregory Mirsky To: Jeffrey Haas Subject: RE: BFD stability follow-up from IETF-91 Thread-Topic: BFD stability follow-up from IETF-91 Thread-Index: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9PggABjhoCAACJJkA== Date: Sat, 29 Nov 2014 03:17:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B89C865@eusaamb103.ericsson.se> References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <20141128195536.GG1274@pfrc> In-Reply-To: <20141128195536.GG1274@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPrO6rexUhBs9Oc1isb3jBbrH/4FtW iyOvjjFbfP6zjdGBxWPehYVsHlN+b2T1WLLkJ5PH5d6trAEsUVw2Kak5mWWpRfp2CVwZvz7c ZClYJ1VxtK+LrYHxkGgXIyeHhICJxOeG38wQtpjEhXvr2boYuTiEBI4wSnxv3sYK4SxnlPjV t4ARpIpNwEjixcYedhBbREBRYv7/TjYQm1mgg1Gi+2opiC0sYCixqnsxVI2RxLEZc6HsOol3 T3+wgtgsAqoSJ28eApvJK+Ar8evEFEaIZb8YJfrOfgQbyimgKTFhbwvYeYxA530/tYYJYpm4 xK0n85kgzhaQWLLnPNQLohIvH/9jhbCVJD7+ns8OUa8jsWD3J6hDtSWWLXzNDLFYUOLkzCcs ExjFZiEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25kuIkRGFHHJNgcdzAu+GR5iFGAg1GJh/fD mvIQIdbEsuLK3EOM0hwsSuK8mtXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwVm3dszvp 7ged0y5z6p7vvxJ5M7k15PpMuaYsJ/5gvySXbQ8mvMlMP6J9WbPwZqbxzliHL9EmV4Nkm5f9 /yhnE3y1pGOxA0fwygSz3Jv5MZfNI75+k9KVbw+fNd2HPz2G4ynPY0GmlNvSAg4nPc4bxbl5 VLB578yt5Hx3/5BS9cV+YaXmh2uUWIozEg21mIuKEwFErn/LiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GLsseB9xZZTg0aJw-z75RqS34n8 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: Sat, 29 Nov 2014 03:18:00 -0000 Hi Jeff, I absolutely agree with continuing discussion and sharing experiences from = real-life deployments and interoperability of BFD in IP and MPLS networks, = single-, multi-hop and over LAG constituents. From that we're learning and = that helps us make our implementations more robust, reliable, and interoper= able. And certainly, where it benefits the community informational RFCs, li= ke BFD intervals or RFC 7325 MPLS Forwarding Compliance and Performance Req= uirements, to document the cases and our recommendations. But I'm somewhat = concerned with anything that targets standard status, even as optional func= tionality, even though it is not proven that the problem is in the standard= , not in an implementation. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Friday, November 28, 2014 11:56 AM To: Gregory Mirsky Cc: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org Subject: Re: BFD stability follow-up from IETF-91 [Speaking as an individual contributor...] On Fri, Nov 28, 2014 at 07:36:30PM +0000, Gregory Mirsky wrote: > this is very interesting scenario. I think that if BFD experiences ~30% p= acket loss, then highly likely so are affected other applications. Then it = is not just BFD issue but condition that should be detected by performance= measurement method, whether active or passive packet loss measurement. > I'm convinced that overloading BFD with performance measurement provision= s is counter-productive and is inappropriate. My opinion is about halfway between your opinion, Greg. I agree that we wish to be very cautious about overloading BFD with compone= nts that are in other OAM mechanisms. Among my desire for such caution is = that IEEE has expressed interest in not having us step on their technologie= s and this would create paperwork for the chairs. :-) But where I think we diverge slightly comes from experience in helping the = working group and vendors wend their way through implementing BFD for LAG. During that discussion, it was very clear that depending on the vendor, the= architecture and sometimes specific chipsets that "BFD" lived in very diff= erent pieces of underlying architecture. What this means is that trying to do very tight timing things will run into= practical issues in having to figure out what the perspective of the timin= gs are. Is it some underlying L2? L3? Something between? At what point do= you realize you are measuring contradictory things? But similarly, when trying to measure and account for loss, having some dat= a is useful simply because it helps you determine that the component that i= s *responsible for BFD* may be experiencing loss. Depending on your archit= ecture, this may be the underlying layer-1, layer-2 or something else. In such cases, the lower-layer OAM is better to troubleshoot. But in cases= where your lower-layer OAM doesn't indicate the loss, you still need to un= derstand that there is BFD-level loss. I encourage participants in this discussion to remember this detail: We are= trying to help measure BFD loss. Trying to read too much detail into what= that means outside of BFD may lead you to erroneous conclusions depending = on a given implementation. Thus, consider what is best for BFD. -- Jeff From nobody Fri Nov 28 21:56: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 E7B251A006D for ; Fri, 28 Nov 2014 21:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqiQmzq0pr5y for ; Fri, 28 Nov 2014 21:56:19 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E83F1A002B for ; Fri, 28 Nov 2014 21:56:19 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB821.namprd05.prod.outlook.com (10.141.244.143) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sat, 29 Nov 2014 05:56:17 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sat, 29 Nov 2014 05:56:17 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4IAAtdiAgACuVoCAAA6bAIABCCjQ Date: Sat, 29 Nov 2014 05:56:16 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.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: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB821; x-forefront-prvs: 041032FF37 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(21056001)(77156002)(46102003)(62966003)(101416001)(76176999)(50986999)(54356999)(97736003)(20776003)(31966008)(66066001)(64706001)(74316001)(106356001)(120916001)(92566001)(108616004)(93886004)(95666004)(106116001)(99286002)(99396003)(230783001)(86362001)(122556002)(107046002)(107886001)(40100003)(4396001)(76576001)(33646002)(2656002)(87936001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB821; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX: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/nUndC9tEZz9cG-GaDZK92gp_k80 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, 29 Nov 2014 05:56:21 -0000 Hi Nobo, Please see my inline comments.=20 > > Nobo, > > Thanks for your suggestions on last two open items. Please see inlin= e. > > > > > > There few points which are still open. > > > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > > > Draft suggest not to use POLL sequence and suggests to increase > > > > multiplier first and then interval. If we have hardware > > > > implementation and don't want to check complete packet every time > > > > received then change in packet may be indicated with POLL bit set. > > > > Since this is one to many mapping we can't have a complete POLL > > > > sequence and hence we need to suppress FINAL. Should we be going > > > > with POLL and suppress FINAL by setting desired RX interval set to > > > > 0? Please suggest any better idea. > > > > > > With removal of all flavors of active tails, it's definitely no > > > longer possible to have P/F sequences. However, I do think that it's > > > a good idea to have an explicit indication in the packet to > > > communicate to MultipointTail sessions that the transmit timers are > > > about to change, this is very helpful for some implementations. I'm > > > not clear on what you mean by "... by setting desired RX interval > > > set to 0?". Can you > > elaborate? > > > > > > > We do not really want to have complete POLL sequence with many to one > > mapping. So we somehow need to indicate to tails that packet has > changed. > > Only possible way today is with POLL bit set, one way to suppress > > FINAL being generated from tail is to have desired RX interval to 0. > > This is something which goes against RFC 5880 where it says POLL > > should have FINAL in reply. I wanted to know if WG has any other > > alternative solution or if it ok to suppress FINAL. >=20 > To me, having sufficient texts to describe MultipointHead sending P bit a= nd > MultipointTail suppressing F bit (since it never sends BFD packets to hea= d) is > sufficient. In other words, I don't see a need to tweak other bits to mak= e > sure that MultipointTail sessions do not send F bit. The only other point= to > consider is, how long does MultipointHead wait before applying the change= . We are surely removing active tail but only form this draft right. Meaning = we will still have active tail in extended draft. So can we really rule ou= t that tail will not reply to head at all?=20 > If we take an extreme example: > - Current interval is 15 ms. > - Current detection multiplier is 3. > - MultipointHead wants to change the interval to 2 sec. > - MultipointHead sends P bit in next 3 BFD packets (3 x 15ms). > - MultipointHead update the interval to 2 sec. > - MultipointTail does not receive the first 2 P bit (for whatever reason)= but > receives the last P bit. >=20 > Now MultipointTail has 45ms to update the detection timer (since next > packet is expected 2 sec later). > Under scaled number of sessions, does this raise any concerns to > implementations? This is really a good point. I think we should have a suggestion where it b= alances between number of POLL sent and how long does it wait before changi= ng the timer. We should not end up sending too many POLL packets to tail as= some implementation might end up sending all POLL packets to software. Do = you agree?=20 How about suggesting that we should first send POLL till detect time and po= st that head sends regular packet without POLL with the same rate (in this = example 15ms) for next detect time and only then fall to higher interval? A= ny other suggestions?=20 > In other words: > - Should MultipointHead send P bit set in next "multiplier" number of pac= kets > and change the interval at that point? > - Should the document specify a minimal time (say 1 second) before > MultipointHead can change the interval? >=20 > Something to think about in implementations. > Yes, we need to add suggestions for implementation. From nobody Sat Nov 29 00:31: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 C8C3C1A0115 for ; Sat, 29 Nov 2014 00:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NTthwnR8NMe for ; Sat, 29 Nov 2014 00:31:48 -0800 (PST) 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 E3D521A0108 for ; Sat, 29 Nov 2014 00:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4921; q=dns/txt; s=iport; t=1417249908; x=1418459508; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=j3s5GhZl874d4jETO9JY4vFlItQ0Jm/peO0eqabMivY=; b=QiUElb0wwuGyUQeHCuvm8P1Dv43MDxtn10Ay6E97Cqt9ESvIu6Aiwqot wy1LfkHk+Ltho5prUgLjzXJOLg/Bdi+lJf6NhuabrQ7r4vOyqAFLBvdaE c4Ro4HNb0hYdeoZSBjqGtpYhPNdMqxuMPF94AeZ2GK1SU4WdBiV4aLSXJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAJyDeVStJV2c/2dsb2JhbABbgwaBLcRtiHYCgQcWAQEBAQF9hAIBAQEDAWUZBwQCAQgRBAEBCx0HMhQJCAIEARIIE4gcCdIYAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BKOAaDI4EfBYpehieMcIM7iVCDCIQCg3tvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,482,1413244800"; d="scan'208";a="101088143" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 29 Nov 2014 08:31:47 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAT8Vl5n020857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Nov 2014 08:31:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Sat, 29 Nov 2014 02:31:46 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Santosh P K , "Nobo Akiya (nobo)" , Mingui Zhang , Gregory Mirsky , "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: AQHPu0hU1nryP7dQOU2cGGfuY/WCWpvYS1kAgEtadQCAAAnegIAE26WAgAA3/wCAAIDAgIAAy7EAgAYPawCAALvkgIAFsnwAgAU+f4CALo2NAIABnSoAgAJ5AYCAAAqHgIAAJV+AgAALRACAAXLjgIAAC2AQgAB6yQCABP9EAIAAr92AgACyswCAAAo/AIABEFgA///GTVA= Date: Sat, 29 Nov 2014 08:31:45 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.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.68.218.26] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PwYG073nF5RjKgs1wrDSbpVX8QI 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, 29 Nov 2014 08:31:50 -0000 Hello Santosh, >How about suggesting that we should first send POLL till detect time and p= ost that head sends regular packet without POLL with the >same rate (in thi= s example 15ms) for next detect time and only then fall to higher interval?= Any other suggestions? Sorry to make you repeat, but can you please clarify the above? Do you mea= n to say (assuming a detect multiplier of 3) that the head sends 3 packet w= ith Poll bit set AND 3 more packets without it set (in effect 6 packets at = 15 ms)? Thanks Prasad -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Saturday, November 29, 2014 11:26 AM To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; Gr= egory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hi Nobo, Please see my inline comments.=20 > > Nobo, > > Thanks for your suggestions on last two open items. Please see inlin= e. > > > > > > There few points which are still open. > > > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > > > Draft suggest not to use POLL sequence and suggests to increase=20 > > > > multiplier first and then interval. If we have hardware=20 > > > > implementation and don't want to check complete packet every=20 > > > > time received then change in packet may be indicated with POLL bit = set. > > > > Since this is one to many mapping we can't have a complete POLL=20 > > > > sequence and hence we need to suppress FINAL. Should we be going=20 > > > > with POLL and suppress FINAL by setting desired RX interval set=20 > > > > to 0? Please suggest any better idea. > > > > > > With removal of all flavors of active tails, it's definitely no=20 > > > longer possible to have P/F sequences. However, I do think that=20 > > > it's a good idea to have an explicit indication in the packet to=20 > > > communicate to MultipointTail sessions that the transmit timers=20 > > > are about to change, this is very helpful for some=20 > > > implementations. I'm not clear on what you mean by "... by setting=20 > > > desired RX interval set to 0?". Can you > > elaborate? > > > > > > > We do not really want to have complete POLL sequence with many to=20 > > one mapping. So we somehow need to indicate to tails that packet has > changed. > > Only possible way today is with POLL bit set, one way to suppress=20 > > FINAL being generated from tail is to have desired RX interval to 0. > > This is something which goes against RFC 5880 where it says POLL=20 > > should have FINAL in reply. I wanted to know if WG has any other=20 > > alternative solution or if it ok to suppress FINAL. >=20 > To me, having sufficient texts to describe MultipointHead sending P=20 > bit and MultipointTail suppressing F bit (since it never sends BFD=20 > packets to head) is sufficient. In other words, I don't see a need to=20 > tweak other bits to make sure that MultipointTail sessions do not send=20 > F bit. The only other point to consider is, how long does MultipointHead = wait before applying the change. We are surely removing active tail but only form this draft right. Meaning = we will still have active tail in extended draft. So can we really rule ou= t that tail will not reply to head at all?=20 > If we take an extreme example: > - Current interval is 15 ms. > - Current detection multiplier is 3. > - MultipointHead wants to change the interval to 2 sec. > - MultipointHead sends P bit in next 3 BFD packets (3 x 15ms). > - MultipointHead update the interval to 2 sec. > - MultipointTail does not receive the first 2 P bit (for whatever=20 > reason) but receives the last P bit. >=20 > Now MultipointTail has 45ms to update the detection timer (since next=20 > packet is expected 2 sec later). > Under scaled number of sessions, does this raise any concerns to=20 > implementations? This is really a good point. I think we should have a suggestion where it b= alances between number of POLL sent and how long does it wait before changi= ng the timer. We should not end up sending too many POLL packets to tail as= some implementation might end up sending all POLL packets to software. Do = you agree?=20 How about suggesting that we should first send POLL till detect time and po= st that head sends regular packet without POLL with the same rate (in this = example 15ms) for next detect time and only then fall to higher interval? A= ny other suggestions?=20 > In other words: > - Should MultipointHead send P bit set in next "multiplier" number of=20 > packets and change the interval at that point? > - Should the document specify a minimal time (say 1 second) before=20 > MultipointHead can change the interval? >=20 > Something to think about in implementations. > Yes, we need to add suggestions for implementation. From nobody Sat Nov 29 05:10: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 4447C1A1A02 for ; Sat, 29 Nov 2014 05:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2hGVdqFksOq for ; Sat, 29 Nov 2014 05:10:51 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572E71A19F7 for ; Sat, 29 Nov 2014 05:10:51 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sat, 29 Nov 2014 13:10:49 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sat, 29 Nov 2014 13:10:49 +0000 From: Santosh P K To: "Vengada Prasad Govindan (venggovi)" , "Nobo Akiya (nobo)" , Mingui Zhang , "Gregory Mirsky" , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4IAAtdiAgACuVoCAAA6bAIABCCjQgAAzooCAAE19oA== Date: Sat, 29 Nov 2014 13:10:48 +0000 Message-ID: <9ea07f274f164443a67014eca298b93f@CO2PR0501MB823.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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824; x-forefront-prvs: 041032FF37 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(199003)(13464003)(51704005)(230783001)(93886004)(106356001)(107046002)(108616004)(20776003)(77156002)(101416001)(92566001)(86362001)(97736003)(33646002)(19580405001)(2656002)(19580395003)(87936001)(64706001)(62966003)(95666004)(99286002)(106116001)(66066001)(105586002)(76176999)(50986999)(107886001)(54356999)(31966008)(122556002)(40100003)(46102003)(74316001)(21056001)(76576001)(120916001)(4396001)(99396003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/yIhDNLPnMVZG69-a6NbM7NUJyJQ 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, 29 Nov 2014 13:10:53 -0000 Hi Prasad, =20 > >How about suggesting that we should first send POLL till detect time and > post that head sends regular packet without POLL with the >same rate (in > this example 15ms) for next detect time and only then fall to higher inte= rval? > Any other suggestions? >=20 > Sorry to make you repeat, but can you please clarify the above? Do you > mean to say (assuming a detect multiplier of 3) that the head sends 3 pac= ket > with Poll bit set AND 3 more packets without it set (in effect 6 packets = at 15 > ms)? Yes, that's correct. I know this not as per RFC 5880 but is this ok for WG?= If not any better solution?=20 Thanks Santosh P K=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Saturday, November 29, 2014 11:26 AM > To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; > Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hi Nobo, > Please see my inline comments. >=20 > > > Nobo, > > > Thanks for your suggestions on last two open items. Please see inl= ine. > > > > > > > > There few points which are still open. > > > > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > > > > Draft suggest not to use POLL sequence and suggests to increase > > > > > multiplier first and then interval. If we have hardware > > > > > implementation and don't want to check complete packet every > > > > > time received then change in packet may be indicated with POLL bi= t > set. > > > > > Since this is one to many mapping we can't have a complete POLL > > > > > sequence and hence we need to suppress FINAL. Should we be going > > > > > with POLL and suppress FINAL by setting desired RX interval set > > > > > to 0? Please suggest any better idea. > > > > > > > > With removal of all flavors of active tails, it's definitely no > > > > longer possible to have P/F sequences. However, I do think that > > > > it's a good idea to have an explicit indication in the packet to > > > > communicate to MultipointTail sessions that the transmit timers > > > > are about to change, this is very helpful for some > > > > implementations. I'm not clear on what you mean by "... by setting > > > > desired RX interval set to 0?". Can you > > > elaborate? > > > > > > > > > > We do not really want to have complete POLL sequence with many to > > > one mapping. So we somehow need to indicate to tails that packet has > > changed. > > > Only possible way today is with POLL bit set, one way to suppress > > > FINAL being generated from tail is to have desired RX interval to 0. > > > This is something which goes against RFC 5880 where it says POLL > > > should have FINAL in reply. I wanted to know if WG has any other > > > alternative solution or if it ok to suppress FINAL. > > > > To me, having sufficient texts to describe MultipointHead sending P > > bit and MultipointTail suppressing F bit (since it never sends BFD > > packets to head) is sufficient. In other words, I don't see a need to > > tweak other bits to make sure that MultipointTail sessions do not send > > F bit. The only other point to consider is, how long does MultipointHea= d > wait before applying the change. >=20 > We are surely removing active tail but only form this draft right. Meanin= g we > will still have active tail in extended draft. So can we really rule out= that tail > will not reply to head at all? >=20 > > If we take an extreme example: > > - Current interval is 15 ms. > > - Current detection multiplier is 3. > > - MultipointHead wants to change the interval to 2 sec. > > - MultipointHead sends P bit in next 3 BFD packets (3 x 15ms). > > - MultipointHead update the interval to 2 sec. > > - MultipointTail does not receive the first 2 P bit (for whatever > > reason) but receives the last P bit. > > > > Now MultipointTail has 45ms to update the detection timer (since next > > packet is expected 2 sec later). > > Under scaled number of sessions, does this raise any concerns to > > implementations? >=20 > This is really a good point. I think we should have a suggestion where it > balances between number of POLL sent and how long does it wait before > changing the timer. We should not end up sending too many POLL packets to > tail as some implementation might end up sending all POLL packets to > software. Do you agree? >=20 > How about suggesting that we should first send POLL till detect time and = post > that head sends regular packet without POLL with the same rate (in this > example 15ms) for next detect time and only then fall to higher interval?= Any > other suggestions? >=20 >=20 >=20 > > In other words: > > - Should MultipointHead send P bit set in next "multiplier" number of > > packets and change the interval at that point? > > - Should the document specify a minimal time (say 1 second) before > > MultipointHead can change the interval? > > > > Something to think about in implementations. > > >=20 > Yes, we need to add suggestions for implementation. From nobody Sat Nov 29 17:30: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 1825B1A0087 for ; Sat, 29 Nov 2014 17:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_HHnpiVsnhD for ; Sat, 29 Nov 2014 17:30:38 -0800 (PST) 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 EE8DD1A0084 for ; Sat, 29 Nov 2014 17:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6323; q=dns/txt; s=iport; t=1417311038; x=1418520638; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K+yPM/bjzWSjwKEwRhWFPjLvasvx7EFdOoWnP85lvyQ=; b=Yp2rI6ZTs3eQIOZDz3Z6imX5nSdeBk4ekypQK9NNlUVp67e3aYitfcv/ 0wbkmg+9k8b36ZVVcl/roqXpn9UFCTU00j503ZfDPkIi8xkszWlhqVR1z YzePRg4htCRdrulCoNaSZUHncCjXvNkS5Gl19x1kLzDCUvYq6xnrMp80/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOxyelStJV2c/2dsb2JhbABbgmMjgSkEzWMCgQoWAQEBAQF9hAIBAQEDAWUgBAIBCBEEAQELHQcyFAkIAgQBEggTiBwJAdITAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BKOAaDI4EfBYpehB+CCIxwgzuJUIMIhAKDe2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,485,1413244800"; d="scan'208";a="376250036" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 30 Nov 2014 01:30:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sAU1UaRx017725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 30 Nov 2014 01:30:36 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sat, 29 Nov 2014 19:30:36 -0600 From: "Nobo Akiya (nobo)" To: Santosh P K , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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+kgCAANSjgIAAY87wgAZ3TgCAAFqOoIAGE9IAgATnjmCALuR+AIABnSoAgAINGWCAAHZvgIAAJV+AgAALRACAAXLjgIAAcEsAgAAV3gCABP9EAIAAPLwQgAEl1AD//6MF8IABd5IAgAArcYCAAE34AIAAZ8gg Date: Sun, 30 Nov 2014 01:30:35 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> <9ea07f274f164443a67014eca298b93f@CO2PR0501MB823.namprd05.prod.outlook.com> In-Reply-To: <9ea07f274f164443a67014eca298b93f@CO2PR0501MB823.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.34.178] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/kBmxnQR74JVFl2PlnHr6V8Z4fMI 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, 30 Nov 2014 01:30:40 -0000 Hi Santosh, Prasad, et al, > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net] > Sent: Saturday, November 29, 2014 8:11 AM > To: Vengada Prasad Govindan (venggovi); Nobo Akiya (nobo); Mingui Zhang; > Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt >=20 > Hi Prasad, >=20 >=20 > > >How about suggesting that we should first send POLL till detect time > > >and > > post that head sends regular packet without POLL with the >same rate > > (in this example 15ms) for next detect time and only then fall to highe= r > interval? > > Any other suggestions? > > > > Sorry to make you repeat, but can you please clarify the above? Do > > you mean to say (assuming a detect multiplier of 3) that the head > > sends 3 packet with Poll bit set AND 3 more packets without it set (in > > effect 6 packets at 15 ms)? >=20 > Yes, that's correct. I know this not as per RFC 5880 but is this ok for W= G? If > not any better solution? I would reword that slightly differently. Before the MultipointHead changes it's transmit interval: - The MultipointHead MUST send BFD packets "detect mult" times with P bit s= et, via transmit interval timer expiry. - The MultipointHead MAY wait also wait some amount of time before making t= he changes to the transmit interval (this can be configured, but ultimately= out of scope). When the interval is slowing down, then: - The MultipointHead SHOULD gradually slow down the transmit interval. Something like that. Thanks! -Nobo >=20 > Thanks > Santosh P K >=20 >=20 >=20 > > -----Original Message----- > > From: Santosh P K [mailto:santoshpk@juniper.net] > > Sent: Saturday, November 29, 2014 11:26 AM > > To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui > > Zhang; Gregory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; > > rtg-bfd@ietf.org > > Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt > > > > Hi Nobo, > > Please see my inline comments. > > > > > > Nobo, > > > > Thanks for your suggestions on last two open items. Please see i= nline. > > > > > > > > > > There few points which are still open. > > > > > > 1.=A0=A0=A0=A0=A0=A0 Increase interval? > > > > > > Draft suggest not to use POLL sequence and suggests to > > > > > > increase multiplier first and then interval. If we have > > > > > > hardware implementation and don't want to check complete > > > > > > packet every time received then change in packet may be > > > > > > indicated with POLL bit > > set. > > > > > > Since this is one to many mapping we can't have a complete > > > > > > POLL sequence and hence we need to suppress FINAL. Should we > > > > > > be going with POLL and suppress FINAL by setting desired RX > > > > > > interval set to 0? Please suggest any better idea. > > > > > > > > > > With removal of all flavors of active tails, it's definitely no > > > > > longer possible to have P/F sequences. However, I do think that > > > > > it's a good idea to have an explicit indication in the packet to > > > > > communicate to MultipointTail sessions that the transmit timers > > > > > are about to change, this is very helpful for some > > > > > implementations. I'm not clear on what you mean by "... by > > > > > setting desired RX interval set to 0?". Can you > > > > elaborate? > > > > > > > > > > > > > We do not really want to have complete POLL sequence with many to > > > > one mapping. So we somehow need to indicate to tails that packet > > > > has > > > changed. > > > > Only possible way today is with POLL bit set, one way to suppress > > > > FINAL being generated from tail is to have desired RX interval to 0= . > > > > This is something which goes against RFC 5880 where it says POLL > > > > should have FINAL in reply. I wanted to know if WG has any other > > > > alternative solution or if it ok to suppress FINAL. > > > > > > To me, having sufficient texts to describe MultipointHead sending P > > > bit and MultipointTail suppressing F bit (since it never sends BFD > > > packets to head) is sufficient. In other words, I don't see a need > > > to tweak other bits to make sure that MultipointTail sessions do not > > > send F bit. The only other point to consider is, how long does > > > MultipointHead > > wait before applying the change. > > > > We are surely removing active tail but only form this draft right. > > Meaning we will still have active tail in extended draft. So can we > > really rule out that tail will not reply to head at all? > > > > > If we take an extreme example: > > > - Current interval is 15 ms. > > > - Current detection multiplier is 3. > > > - MultipointHead wants to change the interval to 2 sec. > > > - MultipointHead sends P bit in next 3 BFD packets (3 x 15ms). > > > - MultipointHead update the interval to 2 sec. > > > - MultipointTail does not receive the first 2 P bit (for whatever > > > reason) but receives the last P bit. > > > > > > Now MultipointTail has 45ms to update the detection timer (since > > > next packet is expected 2 sec later). > > > Under scaled number of sessions, does this raise any concerns to > > > implementations? > > > > This is really a good point. I think we should have a suggestion where > > it balances between number of POLL sent and how long does it wait > > before changing the timer. We should not end up sending too many POLL > > packets to tail as some implementation might end up sending all POLL > > packets to software. Do you agree? > > > > How about suggesting that we should first send POLL till detect time > > and post that head sends regular packet without POLL with the same > > rate (in this example 15ms) for next detect time and only then fall to > > higher interval? Any other suggestions? > > > > > > > > > In other words: > > > - Should MultipointHead send P bit set in next "multiplier" number > > > of packets and change the interval at that point? > > > - Should the document specify a minimal time (say 1 second) before > > > MultipointHead can change the interval? > > > > > > Something to think about in implementations. > > > > > > > Yes, we need to add suggestions for implementation. From nobody Sat Nov 29 19:59: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 640CE1A0162 for ; Sat, 29 Nov 2014 19:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c131VIxHfmnz for ; Sat, 29 Nov 2014 19:59:51 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA501A010C for ; Sat, 29 Nov 2014 19:59:51 -0800 (PST) Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.26.15; Sun, 30 Nov 2014 03:59:49 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Sun, 30 Nov 2014 03:59:49 +0000 From: Santosh P K To: "Nobo Akiya (nobo)" , "Vengada Prasad Govindan (venggovi)" , Mingui Zhang , Gregory Mirsky , "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/wCAAICfcIAAy9MAgAYMzyCAAL5/gIAFryHggAVB2oCALmknIIABsM0AgAJ5AYCAAAZnEIAAKX+AgAAGxbCAAXdhgIAAcEwAgAAVyUCABPle4IAAtdiAgACuVoCAAA6bAIABCCjQgAAzooCAAE19oIAAzyyAgAAofsA= Date: Sun, 30 Nov 2014 03:59:49 +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> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> <9ea07f274f164443a67014eca298b93f@CO2PR0501MB823.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: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB822; x-forefront-prvs: 04111BAC64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(74316001)(76576001)(108616004)(93886004)(97736003)(99286002)(46102003)(64706001)(4396001)(21056001)(20776003)(33646002)(50986999)(92566001)(105586002)(62966003)(76176999)(77156002)(230783001)(54356999)(95666004)(120916001)(106356001)(106116001)(122556002)(86362001)(107886001)(107046002)(40100003)(87936001)(101416001)(99396003)(66066001)(2656002)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; 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/N7D6brlWmiHDqYAnVVleEFOJPHA 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, 30 Nov 2014 03:59:54 -0000 Hi Nobo, =20 > > > >How about suggesting that we should first send POLL till detect > > > >time and > > > post that head sends regular packet without POLL with the >same rate > > > (in this example 15ms) for next detect time and only then fall to > > > higher > > interval? > > > Any other suggestions? > > > > > > Sorry to make you repeat, but can you please clarify the above? Do > > > you mean to say (assuming a detect multiplier of 3) that the head > > > sends 3 packet with Poll bit set AND 3 more packets without it set > > > (in effect 6 packets at 15 ms)? > > > > Yes, that's correct. I know this not as per RFC 5880 but is this ok > > for WG? If not any better solution? >=20 > I would reword that slightly differently. >=20 > Before the MultipointHead changes it's transmit interval: >=20 > - The MultipointHead MUST send BFD packets "detect mult" times with P bit > set, via transmit interval timer expiry. > - The MultipointHead MAY wait also wait some amount of time before > making the changes to the transmit interval (this can be configured, but > ultimately out of scope). >=20 > When the interval is slowing down, then: >=20 > - The MultipointHead SHOULD gradually slow down the transmit interval. For slowing down interval we should fall to faster interval faster. For wor= dings you suggested was exactly what I thought. We don't want to mandate ho= w an head implementation MUST behave during interval but we can give sugges= tion in the draft.=20 Thanks Santos h P K=20 From nobody Sun Nov 30 20:21:24 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 94D041A039C for ; Sun, 30 Nov 2014 20:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HeyYsUK3cA1 for ; Sun, 30 Nov 2014 20:21:20 -0800 (PST) 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 CC94A1A0A85 for ; Sun, 30 Nov 2014 20:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1981; q=dns/txt; s=iport; t=1417407679; x=1418617279; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HdBGR/L99TTU0BBCUjdec2c3tQZOMIS4onfvMCsm4Dc=; b=bTfzUQrlowJItQvPm80xR8VYz1ZWIU0/c1n8kf05pzV7XTAiBkQrqT9w teoi45MR29ToN/7mn6zfSlgrpV3+KYBK2W+C5qrYCZqSePoFdxKQ9z2SD 5+yAZcskzY3N4A9GobkPrQREz2mOLb+ZCRfQCM3MOtlOYSXiZGimWgySk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAMnre1StJV2P/2dsb2JhbABbgwaBKQTEVIh2AoEPFgEBAQEBfYQCAQEBBDpLBAIBCBEEAQELFAkHMhQJCAIEARIIE4gl0hEBAQEBAQEBAQEBAQEBAQEBAQEBARiQSjgGgyOBHwEEkQWMcIM7kFqDe2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208";a="101388666" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 01 Dec 2014 04:21:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB14LIXa014136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 04:21:18 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.22]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 22:21:18 -0600 From: "Vengada Prasad Govindan (venggovi)" To: Santosh P K , "Nobo Akiya (nobo)" , Mingui Zhang , Gregory Mirsky , "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: AQHPu0hU1nryP7dQOU2cGGfuY/WCWpvYS1kAgEtadQCAAAnegIAE26WAgAA3/wCAAIDAgIAAy7EAgAYPawCAALvkgIAFsnwAgAU+f4CALo2NAIABnSoAgAJ5AYCAAAqHgIAAJV+AgAALRACAAXLjgIAAC2AQgAB6yQCABP9EAIAAr92AgACyswCAAAo/AIABEFgA///GTVCAALMcAIAAzrGAgAApsoCAATOfUA== Date: Mon, 1 Dec 2014 04:21:17 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3476D934@xmb-rcd-x15.cisco.com> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> <20140819140828.GJ30106@pfrc> <5df61f06c178457784f50308209a5c2d@BLUPR05MB755.namprd05.prod.outlook.com> <224170ffcb1642eda82302cd41ad2743@BLUPR05MB755.namprd05.prod.outlook.com> <48e22f9306f64bb29df1883372665a78@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B896423@eusaamb103.ericsson.se> <4552F0907735844E9204A62BBDD325E76AADF0A1@nkgeml512-mbx.china.huawei.com> <315041E4211CB84E86EF7C25A2AB583D34763084@xmb-rcd-x15.cisco.com> <43541ae8326d4f348869f71ed9e71624@CO2PR0501MB823.namprd05.prod.outlook.com> <315041E4211CB84E86EF7C25A2AB583D3476D6A7@xmb-rcd-x15.cisco.com> <9ea07f274f164443a67014eca298b93f@CO2PR0501MB823.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.143.26.6] 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/PyjdFYS27i8lxA6GkDlN74cR7u0 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, 01 Dec 2014 04:21:21 -0000 Hello Santosh/ Nobo, Agree with the conclusions below. Thanks Prasad -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Sunday, November 30, 2014 9:30 AM To: Nobo Akiya (nobo); Vengada Prasad Govindan (venggovi); Mingui Zhang; Gr= egory Mirsky; Henderickx, Wim (Wim); Jeffrey Haas; rtg-bfd@ietf.org Subject: RE: I-D Action: draft-ietf-bfd-multipoint-04.txt Hi Nobo, =20 > > > >How about suggesting that we should first send POLL till detect=20 > > > >time and > > > post that head sends regular packet without POLL with the >same=20 > > > rate (in this example 15ms) for next detect time and only then=20 > > > fall to higher > > interval? > > > Any other suggestions? > > > > > > Sorry to make you repeat, but can you please clarify the above?=20 > > > Do you mean to say (assuming a detect multiplier of 3) that the=20 > > > head sends 3 packet with Poll bit set AND 3 more packets without=20 > > > it set (in effect 6 packets at 15 ms)? > > > > Yes, that's correct. I know this not as per RFC 5880 but is this ok=20 > > for WG? If not any better solution? >=20 > I would reword that slightly differently. >=20 > Before the MultipointHead changes it's transmit interval: >=20 > - The MultipointHead MUST send BFD packets "detect mult" times with P=20 > bit set, via transmit interval timer expiry. > - The MultipointHead MAY wait also wait some amount of time before=20 > making the changes to the transmit interval (this can be configured,=20 > but ultimately out of scope). >=20 > When the interval is slowing down, then: >=20 > - The MultipointHead SHOULD gradually slow down the transmit interval. For slowing down interval we should fall to faster interval faster. For wor= dings you suggested was exactly what I thought. We don't want to mandate ho= w an head implementation MUST behave during interval but we can give sugges= tion in the draft.=20 Thanks Santos h P K=20