From nobody Wed Mar 4 13:19:14 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177D1A891B for ; Wed, 4 Mar 2015 13:19:13 -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 oQPylUYmN6zJ for ; Wed, 4 Mar 2015 13:19:12 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2F71A890B for ; Wed, 4 Mar 2015 13:19:12 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1175AC1B5; Wed, 4 Mar 2015 16:19:12 -0500 (EST) Date: Wed, 4 Mar 2015 16:19:12 -0500 From: Jeffrey Haas To: Manav Bhatia Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00 Message-ID: <20150304211911.GA9406@pfrc> References: <20150224211328.GF25639@pfrc> <7347100B5761DC41A166AC17F22DF1121B91363E@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: 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, 04 Mar 2015 21:19:13 -0000 Manav, On Wed, Feb 25, 2015 at 06:05:18AM +0530, Manav Bhatia wrote: > It requires no changes on the RX side. I concede that it does require some > changes on the TX side. > > If somebody tells me that this requires changes on the RX side as well, > then that vendor's implementation is broken! :-) Thinking about this a bit further, I think this is partially a matter that authentication transitions are "under-specified" in RFC 5880. Basically, if you have authentication enabled on your session as a receiver, and you don't see a packet coming in that you're expecting to be authenticated, you'd probably just ignore it. What I believe you're saying in that first sentence almost sounds like you're saying that the receiver should just trust the auth bit. :-) I suspect you don't mean that. My observation is that implementations likely have additional rules about when they expect to receive authenticated packets. This could be modeled as a state variable for the general packet reception rules, an overlay on the BFD FSM, whatever. There's expectations that must be kept in sync. The proposal in the draft as written are a bit vague as to when things can turn on, turn off the authentication bit. I think in fairness to the WG to evaluate the proposal more fully, those details should be described in more detail. As an aside, I've made a few inquiries as to the caching suggestion I had made previously. It seems at least one implementation is already doing some of that work. I'm awaiting more details before pursuing that direction further. -- Jeff From nobody Thu Mar 5 08:36:27 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D837C1A1B14; Thu, 5 Mar 2015 08:36:19 -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 h1iS13-ouBC6; Thu, 5 Mar 2015 08:36:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 892EE1A1B43; Thu, 5 Mar 2015 08:32:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-bfd-rfc5884-clarifications-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305163206.7959.27094.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 08:32:06 -0800 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 16:36:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Clarifications to RFC 5884 Authors : Vengada Prasad Govindan Kalyani Rajaraman Gregory Mirsky Nobo Akiya Sam Aldrin Filename : draft-ietf-bfd-rfc5884-clarifications-01.txt Pages : 6 Date : 2015-03-05 Abstract: This document clarifies the procedures for establishing, maintaining and removing multiple, concurrent BFD sessions for a given described in RFC5884. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-rfc5884-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-rfc5884-clarifications-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-rfc5884-clarifications-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 09:23:23 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58B81A1B9E for ; Thu, 5 Mar 2015 09:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDySyv3m87cA for ; Thu, 5 Mar 2015 09:23:15 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6FC1A1B98 for ; Thu, 5 Mar 2015 09:17:43 -0800 (PST) Received: by iecvy18 with SMTP id vy18so14232714iec.1 for ; Thu, 05 Mar 2015 09:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=i7OHR4Na0PoiYxx+inljUALgTMDI30ZqMADb47S9jEg=; b=WXzZsaR2FyBRv9fOniGwnqu8dSv1dnBik9jNBOnbshgw/BrjGnUKKHTjFPS5etcdGH 26kzQaM314eZA/IE7wnnzJOIErEjjtL8T0OfWJNjeJP6DIDyZRYNOq66SB37ZW75/lJj k4G/7oyx9Zlegy287sHlPtKfe3ZP2HgNABnW2oBqmt8VM4Gqe0B89dflCaTTTz8n7P8T 2b3FHvRUSVpYCOvIed5UJxw8rFi91TsMBmAuPdTCrvuUIs6BxK+s4c/zywvZwtQqR7Xq Nt92FNKMCIHLCRCv39MfADEnMj4hSWaqInkHqwG7v0fL+09ZE0Yh099YhGsAnyPMbUIT wJmw== X-Received: by 10.107.32.14 with SMTP id g14mr22217002iog.3.1425575862704; Thu, 05 Mar 2015 09:17:42 -0800 (PST) Received: from NoboAkiyaPC (CPE0c473d2ae981-CM0c473d2ae980.cpe.net.cable.rogers.com. [99.224.118.67]) by mx.google.com with ESMTPSA id ao5sm13188364igc.3.2015.03.05.09.17.40 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Mar 2015 09:17:41 -0800 (PST) From: "Nobo Akiya" To: Subject: IETF92 BFD WG Session Date: Thu, 5 Mar 2015 12:17:37 -0500 Message-ID: <01fd01d05768$48479350$d8d6b9f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01D0573E.5F718B50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBXaB0inGPAdZHwQ8eG342xzxGfYQ== Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:23:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01FE_01D0573E.5F718B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, IETF92 BFD WG session is the second session on Monday. Date: MONDAY, March 23, 2015 Time: 1300-1500 CDT Place: Royal Session agenda has also been posted. https://datatracker.ietf.org/meeting/92/agenda/bfd/ Owners of topics w/o unpublished documents (those mentioned with TBD in the agenda), publication cut-off is March 9th which is fast approaching. Owners of all topics, please send Jeff and I your presentation material by no later than March 20th (sooner the better). Thanks! -Nobo and Jeff ------=_NextPart_000_01FE_01D0573E.5F718B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

IETF92 BFD = WG session is the second session on Monday.

 

Date:  = MONDAY, March 23, 2015

Time:  = 1300-1500 CDT

Place: = Royal

 

Session agenda has also been posted.

 

https://data= tracker.ietf.org/meeting/92/agenda/bfd/

 

Owners of = topics w/o unpublished documents (those mentioned with TBD in the = agenda), publication cut-off is March 9th which is fast = approaching.

 

Owners of all topics, please send Jeff and I your = presentation material by no later than March 20th (sooner the = better).

 

Thanks!

 

-Nobo and = Jeff

 

------=_NextPart_000_01FE_01D0573E.5F718B50-- From nobody Thu Mar 5 10:30:07 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210851A6F0B; Thu, 5 Mar 2015 10:30:07 -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 xO0-v2YyD50l; Thu, 5 Mar 2015 10:30:05 -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 56CB91A1BE6; Thu, 5 Mar 2015 10:30:05 -0800 (PST) X-AuditID: c6180641-f796f6d000004ccc-1b-54f83fbf06f7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 52.17.19660.FBF38F45; Thu, 5 Mar 2015 12:36:31 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Thu, 5 Mar 2015 13:30:03 -0500 From: Gregory Mirsky To: "mpls@ietf.org" , "rtg-bfd@ietf.org" , "spring@ietf.org" Subject: FW: New Version Notification for draft-mirsky-mpls-bfd-directed-03.txt Thread-Topic: New Version Notification for draft-mirsky-mpls-bfd-directed-03.txt Thread-Index: AQHQV3GDdZyQilfqPEGH7rZut4nfHJ0ONJ9A Date: Thu, 5 Mar 2015 18:30:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B919322@eusaamb103.ericsson.se> References: <20150305182336.4210.87970.idtracker@ietfa.amsl.com> In-Reply-To: <20150305182336.4210.87970.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyuXRPrO5++x8hBi/6pSxuLV3JavH5zzZG i+MXfjM6MHssWfKTKYAxissmJTUnsyy1SN8ugStj6WeLgnvCFV9OPWFtYJwj3MXIySEhYCLR Pv8JC4QtJnHh3nq2LkYuDiGBI4wSXR3HWSCcZYwSd64/ZwWpYhMwknixsYcdxBYRKJT4vO8a WLewQKDE/OlnGCHiQRIvf/+Gso0k/p+bBGazCKhI7JnbA2bzCvhKvLx1EGyOkICDxJllC8Fs TgFHiUMnv4DVMAJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSixr3860BwO oHpNifW79CFaFSWmdD9kh1grKHFy5hOWCYyis5BMnYXQMQtJxywkHQsYWVYxcpQWp5blphsZ bmIERsIxCTbHHYwLPlkeYhTgYFTi4TUI+x4ixJpYVlyZe4hRmoNFSZy37MrBECGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MdrtTPuyNy3e78SLvwGmxn7vrH60tU+l/0SiYonu+3nrb2sVa 0mfW+m/ib5r11fSs0+yk6zKsmnazLBdOSEtkfifcq6m1ce2+nyXhLg0fop9yOYVPXH3g2pkA L4n8/1JLI7bOaOeJyUxn1pRKn64m4cV4vfBm9VN9LnsPz6qrNibpl9cyZlcqsRRnJBpqMRcV JwIASPdDEWUCAAA= Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 18:30:07 -0000 RGVhciBBbGwsDQpuZXcgdmVyc2lvbiBvZiBCRkQgRGlyZWN0ZWQgUmV0dXJuIFBhdGggYmVlbiBw dWJsaXNoZWQuIENoYW5nZXMgYXJlIHRvIGFkZHJlc3MgY29tbWVudHMgYnkgTG9hIEFuZGVyc3Nv bi4NCkF1dGhvcnMgd2VsY29tZSB5b3VyIGNvbW1lbnRzLCBxdWVzdGlvbnMgb24gdGhlIGxpc3Qg YW5kIGFyZSBsb29raW5nIGZvcndhcmQgdG8gZGlzY3Vzc2lvbiBpbiBEYWxsYXMuDQoNCglSZWdh cmRzLA0KCQlHcmVnDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogVGh1cnNkYXksIE1hcmNoIDA1LCAyMDE1IDEwOjI0IEFNDQpUbzogTWFjaCBDaGVuOyBHcmVn b3J5IE1pcnNreTsgSmVmZiBUYW50c3VyYTsgR3JlZ29yeSBNaXJza3k7IEplZmYgVGFudHN1cmE7 IE1hY2ggQ2hlbiAoR3VveWkpOyBJbHlhIFZhcmxhc2hraW47IElseWEgVmFybGFzaGtpbg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1taXJza3ktbXBscy1iZmQt ZGlyZWN0ZWQtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1pcnNreS1t cGxzLWJmZC1kaXJlY3RlZC0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtbWlyc2t5LW1wbHMtYmZkLWRpcmVjdGVkDQpSZXZpc2lvbjoJMDMNClRpdGxlOgkJ QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBEaXJlY3RlZCBSZXR1cm4g UGF0aA0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1p c3Npb24NClBhZ2VzOgkJMTANClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy1iZmQtZGlyZWN0ZWQtMDMudHh0DQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWlyc2t5 LW1wbHMtYmZkLWRpcmVjdGVkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LW1pcnNreS1tcGxzLWJmZC1kaXJlY3RlZC0wMw0KRGlmZjogICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1pcnNreS1tcGxzLWJmZC1k aXJlY3RlZC0wMw0KDQpBYnN0cmFjdDoNCiAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRl Y3Rpb24gKEJGRCkgaXMgZXhwZWN0ZWQgdG8gbW9uaXRvciBiaS0NCiAgIGRpcmVjdGlvbmFsIHBh dGhzLiAgV2hlbiBhIEJGRCBzZXNzaW9uIG1vbml0b3JzIGluIGl0cyBmb3J3YXJkDQogICBkaXJl Y3Rpb24gYW4gZXhwbGljaXRseSByb3V0ZWQgcGF0aCB0aGVyZSBpcyBhIG5lZWQgdG8gYmUgYWJs ZSB0bw0KICAgZGlyZWN0IGVncmVzcyBCRkQgcGVlciB0byB1c2Ugc3BlY2lmaWMgcGF0aCBhcyBy ZXZlcnNlIGRpcmVjdGlvbiBvZg0KICAgdGhlIEJGRCBzZXNzaW9uLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Mar 5 14:35:53 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77011A9084 for ; Thu, 5 Mar 2015 14:35:51 -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 Gg8xI1MZ3pVN for ; Thu, 5 Mar 2015 14:35:50 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF681A9073 for ; Thu, 5 Mar 2015 14:35:49 -0800 (PST) Received: by igal13 with SMTP id l13so45847261iga.1 for ; Thu, 05 Mar 2015 14:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=U/FPE1MbNiI9KpfedQfH+xWATU8xs/QwHPLrPmkTWtE=; b=iYJuObkGUOuK/QjRmmHDquKb+9ekb1MUaWgOUthu8exWawOI3+PITYf8DX8S07K7EW QwkGGYAN64xWQMaYnIofJEWTaTnEhCiYFwnTOm6rYqLDuICerbGya867OEVlhsSAWL38 qmKV+8zVFTe2BwbjmsnU28205iUWgQs44azhwiUfOExA8BQ6GRBRrZtM82qYcuMXn/Cj A7OkCk593aGFeavIyRZVC5sB5KxvV5UtNqdetPJOy3tc6VvAU5olI/CQsvBgXU4yYiHV KH4SxihCxNRk0u5cuU8U47XLeof8h6Ku4IH9Px3BSCtdEsrrtlqVfKVFFYSMbpEYfW7x e1Wg== X-Received: by 10.107.167.145 with SMTP id q139mr24022485ioe.16.1425594949505; Thu, 05 Mar 2015 14:35:49 -0800 (PST) Received: from NoboAkiyaPC (ip-64-134-160-83.public.wayport.net. [64.134.160.83]) by mx.google.com with ESMTPSA id t1sm13605485igs.0.2015.03.05.14.35.47 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Mar 2015 14:35:48 -0800 (PST) From: "Nobo Akiya" To: Subject: IETF92 BFD WG Session Date: Thu, 5 Mar 2015 17:35:43 -0500 Message-ID: <003901d05794$b8976410$29c62c30$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01D0576A.CFC3CD10" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBXlLRvq6KsyYVUT9Opx2xlsfqLDQ== Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 22:35:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003A_01D0576A.CFC3CD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Folks, IETF92 BFD WG session is the second session on Monday. Date: MONDAY, March 23, 2015 Time: 1300-1500 CDT Place: Royal Session agenda has also been posted. https://datatracker.ietf.org/meeting/92/agenda/bfd/ Owners of topics w/o unpublished documents (those mentioned with TBD in the agenda), publication cut-off is March 9th which is fast approaching. Owners of all topics, please send Jeff and I your presentation material by no later than March 20th (sooner the better). Thanks! -Nobo and Jeff ------=_NextPart_000_003A_01D0576A.CFC3CD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

IETF92 BFD = WG session is the second session on Monday.

 

Date:  = MONDAY, March 23, 2015

Time:  = 1300-1500 CDT

Place: = Royal

 

Session agenda has also been posted.

 

https://data= tracker.ietf.org/meeting/92/agenda/bfd/

 

Owners of = topics w/o unpublished documents (those mentioned with TBD in the = agenda), publication cut-off is March 9th which is fast = approaching.

 

Owners of all topics, please send Jeff and I your = presentation material by no later than March 20th (sooner the = better).

 

Thanks!

 

-Nobo and = Jeff

 

------=_NextPart_000_003A_01D0576A.CFC3CD10-- From nobody Tue Mar 10 06:21:40 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF81B2A2C for ; Tue, 10 Mar 2015 06:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpULiB6twjbP for ; Tue, 10 Mar 2015 06:21:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C26E41ACDC9 for ; Tue, 10 Mar 2015 06:21:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 71F42C204; Tue, 10 Mar 2015 09:21:37 -0400 (EDT) Date: Tue, 10 Mar 2015 09:21:37 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: bfd yang work Message-ID: <20150310132137.GA23658@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 13:21:39 -0000 Working Group, The BFD yang design team would appreciate your review of their initial work on the BFD yang module: : A New Internet-Draft is available from the on-line Internet-Drafts : directories. : : : Title : Yang Data Model for Bidirectional Forwarding Detection (BFD) : Authors : Lianshu Zheng : Reshad Rahman : Santosh Pallagatti : Mahesh Jethanandani : Filename : draft-zheng-bfd-yang-00.txt : Pages : 29 : Date : 2015-03-09 : : Abstract: : This document defines a YANG data model that can be used to configure : and manage Bidirectional Forwarding Detection (BFD). : : : : The IETF datatracker status page for this draft is: : https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ : : There's also a htmlized version available at: : http://tools.ietf.org/html/draft-zheng-bfd-yang-00 : : : Please note that it may take a couple of minutes from the time of submission : until the htmlized version and diff are available at tools.ietf.org. : : Internet-Drafts are also available by anonymous FTP at: : ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 11 09:52:48 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C571A1AB8; Wed, 11 Mar 2015 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DBRZBu4nWgTt; Wed, 11 Mar 2015 09:52:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687101A0235; Wed, 11 Mar 2015 09:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9774; q=dns/txt; s=iport; t=1426092764; x=1427302364; h=from:to:cc:subject:date:message-id:mime-version; bh=pZr2Os3Uh3cyUyN7rTF1QqLN1rZmFACrxGsQDhyVsKo=; b=WiKMI8bJU2cPoyD0gxT5esOngi7gsuuoLLOsXWPynJdOTJYTvLeknL/q f2kyQ8yQ3mdJPrD3gU8m5HEvUIAShBQrG/Lik0PymYgYl6nIC6GAu5w2C XdXRSQ0ZxfW1g86LV7uVDUeW+ZgMVdRwXjHV9HxysnHljoPblktHgyIjF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfDADOcQBV/4kNJK1cgwZSWgSDB7pWg0iCOYVuAhyBHE0BAQEBAQF8hBEBBCNWEgEqIAIEMCYBBAENDQEFiCABDa0vmyUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixeEPTEQgl8vgRYFkBuBZoIChw85gm+PNSODbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.11,382,1422921600"; d="scan'208";a="131053761" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 11 Mar 2015 16:52:43 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2BGqhS0019250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 16:52:43 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.64]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 11 Mar 2015 11:52:43 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "rtg-bfd@ietf.org" , "pals@ietf.org" Subject: Requesting comments on SBFD-VCCV drafts Thread-Topic: Requesting comments on SBFD-VCCV drafts Thread-Index: AdBcG8bbDt4lFsaSQwiuvYh/1U3PNA== Date: Wed, 11 Mar 2015 16:52:42 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [171.70.240.57] Content-Type: multipart/mixed; boundary="_003_315041E4211CB84E86EF7C25A2AB583D54337F7Cxmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" 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, 11 Mar 2015 16:52:46 -0000 --_003_315041E4211CB84E86EF7C25A2AB583D54337F7Cxmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We have submitted two new drafts: a. draft-gp-pals-seamless-vccv: This draft defines the SBFD protocol operat= ion for VCCV. https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ b. draft-gp-l2tpext-sbfd-discriminator: This draft defines AVPs for adverti= sement of SBFD discriminators in L2TP. We welcome comments/ feedback on these drafts. https://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ Thanks Prasad --_003_315041E4211CB84E86EF7C25A2AB583D54337F7Cxmbrcdx15ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 11 Mar 2015 16:52:41 GMT"; modification-date="Wed, 11 Mar 2015 16:52:41 GMT" Received: from alln-iport-8.cisco.com (173.37.142.95) by mail.cisco.com (173.37.183.80) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 5 Mar 2015 07:29:05 -0600 Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP; 05 Mar 2015 13:29:05 +0000 Received: from alln-inbound-l.cisco.com (alln-inbound-l.cisco.com [173.37.147.242]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t25DT5FA015299; Thu, 5 Mar 2015 13:29:05 GMT Received: from mail.ietf.org ([4.31.198.44]) by alln-inbound-l.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2015 13:29:04 +0000 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A21B2C77; Thu, 5 Mar 2015 05:29:03 -0800 (PST) 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 0R0DNOCVo8yB; Thu, 5 Mar 2015 05:29:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 553E91B2C71; Thu, 5 Mar 2015 05:29:01 -0800 (PST) From: "internet-drafts@ietf.org" To: "Vengada Prasad Govindan (venggovi)" , "Carlos Pignataro (cpignata)" , "Vengada Prasad Govindan (venggovi)" , "Carlos Pignataro (cpignata)" Subject: New Version Notification for draft-gp-l2tpext-sbfd-discriminator-00.txt Thread-Topic: New Version Notification for draft-gp-l2tpext-sbfd-discriminator-00.txt Thread-Index: AQHQV0haWx5e+oLBVUaIs7ScOfsoDQ== Date: Thu, 5 Mar 2015 13:29:01 +0000 Message-ID: <20150305132901.11644.17474.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: xhc-rcd-x06.cisco.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-ironport-av: E=Sophos;i="5.11,347,1422921600"; d="scan'208";a="126760009" x-ironport-anti-spam-filtered: true x-ironport-anti-spam-result: A0HIAQAFWfhUnCzGHwRagmN0WoMLvFuBIxsMhW+BOTgUAQEBAQEBAQIOAQEBAQEGDQkJFC6CKhQQKwgEHQI+EgEBHAUCIFQRJgImAgIDRBYBFwSIJwIKvQiGWJQbAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXOEWYMEgUMFimOJBYVpAYEaOYJtjyoChDJOAYJCAQEB x-from-outside-cisco: 4.31.198.44 received-spf: None (alln-inbound-l.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=4.31.198.44; receiver=alln-inbound-l.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3AtbDJ0cGV4dC1zYmZkLWRpc2NyaW1pbmF0 b3ItMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZlbmdhZGEgUHJh c2FkIEdvdmluZGFuIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6 ICAgICAgICAgICBkcmFmdC1ncC1sMnRwZXh0LXNiZmQtZGlzY3JpbWluYXRvcg0KUmV2aXNpb246 ICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgQWR2ZXJ0aXNpbmcgUy1CRkQgRGlzY3JpbWluYXRv cnMgaW4gTDJUUHYzDQpEb2N1bWVudCBkYXRlOiAgMjAxNS0wMy0wNQ0KR3JvdXA6ICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgICAgIDUNClVSTDogICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ncC1sMnRwZXh0LXNi ZmQtZGlzY3JpbWluYXRvci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1ncC1sMnRwZXh0LXNiZmQtZGlzY3JpbWluYXRvci8NCkh0 bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ncC1sMnRwZXh0 LXNiZmQtZGlzY3JpbWluYXRvci0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGEgbmV3IEFWUCBmb3IgYWR2ZXJ0aXNpbmcgb25lIG9yIG1vcmUgUy1CRkQNCiAgIERp c2NyaW1pbmF0b3JzIHVzaW5nIHRoZSBMMlRQdjMgQ29udHJvbCBQcm90b2NvbCBBVlAuDQoNCg0K DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0K --_003_315041E4211CB84E86EF7C25A2AB583D54337F7Cxmbrcdx15ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Wed, 11 Mar 2015 16:52:41 GMT"; modification-date="Wed, 11 Mar 2015 16:52:41 GMT" Received: from alln-iport-4.cisco.com (173.37.142.91) by mail.cisco.com (173.37.183.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 6 Mar 2015 07:48:38 -0600 Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 06 Mar 2015 13:48:38 +0000 Received: from alln-inbound-f.cisco.com (alln-inbound-f.cisco.com [173.37.147.236]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t26DmbYj002709; Fri, 6 Mar 2015 13:48:37 GMT Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-f.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2015 13:48:37 +0000 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81F41A0636; Fri, 6 Mar 2015 05:48:36 -0800 (PST) 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 xVLoaP6OgfTE; Fri, 6 Mar 2015 05:48:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986D91A1A4F; Fri, 6 Mar 2015 05:48:34 -0800 (PST) From: "internet-drafts@ietf.org" To: "Vengada Prasad Govindan (venggovi)" , "Carlos Pignataro (cpignata)" , "Vengada Prasad Govindan (venggovi)" , "Carlos Pignataro (cpignata)" Subject: New Version Notification for draft-gp-pals-seamless-vccv-00.txt Thread-Topic: New Version Notification for draft-gp-pals-seamless-vccv-00.txt Thread-Index: AQHQWBQ/uM0jHgUQIUaokp2Rm8/8/g== Date: Fri, 6 Mar 2015 13:48:34 +0000 Message-ID: <20150306134834.2384.86433.idtracker@ietfa.amsl.com> Content-Language: en-US X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: xhc-rcd-x14.cisco.com X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-ironport-av: E=Sophos;i="5.11,352,1422921600"; d="scan'208";a="129510374" x-ironport-anti-spam-filtered: true x-ironport-anti-spam-result: A8G7AQD7rvlUlwAZASCDgISAEQAsXIJkdFqDCr0ZgSMgCoVwgTs4FAEBAQEBAQECDgEBAQEBCBYHQoIqFBArCAQdAj4SAQEcBQIgVBEmAiYCAgNEFgEXBIgnAgq0JYZYk30BAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJdoRZgwSBQwWKZYkFhWkBgRo5gm2PLQKEMk4BgkIBAQE x-from-outside-cisco: 2001:1900:3001:11::2c received-spf: None (alln-inbound-f.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-f.cisco.com; envelope-from="internet-drafts@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Content-Type: text/plain; charset="utf-8" Content-ID: <54106D5C92B6534BA86FBF52CB4CD701@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ3AtcGFscy1zZWFtbGVzcy12Y2N2LTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBWZW5nYWRhIFByYXNhZCBHb3Zp bmRhbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAg ICAgZHJhZnQtZ3AtcGFscy1zZWFtbGVzcy12Y2N2DQpSZXZpc2lvbjogICAgICAgMDANClRpdGxl OiAgICAgICAgICBTZWFtbGVzcyBCRkQgZm9yIFZDQ1YNCkRvY3VtZW50IGRhdGU6ICAyMDE1LTAz LTA2DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAg ICAgOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWdwLXBhbHMtc2VhbWxlc3MtdmNjdi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ncC1wYWxzLXNlYW1sZXNzLXZjY3Yv DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ3AtcGFs cy1zZWFtbGVzcy12Y2N2LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGV4dGVu ZHMgdGhlIHByb2NlZHVyZXMgYW5kIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24NCiAgIChDVikg dHlwZXMgYWxyZWFkeSBkZWZpbmVkIGZvciBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uDQogICAoQkZEKSBmb3IgVmlydHVhbCBDaXJjdWl0IENvbm5lY3Rpdml0eSBWZXJpZmljYXRp b24gKFZDQ1YpIHRvIGRlZmluZQ0KICAgU2VhbWxlc3MgQkZEIChTLUJGRCkgZm9yIFZDQ1YuICBU aGlzIGRvY3VtZW50IHdpbGwgYmUgZXh0ZW5kZWQgaW4NCiAgIGZ1dHVyZSB0byBpbmNsdWRlIGRl ZmluaXRpb24gb2YgcHJvY2VkdXJlcyBmb3IgUy1CRkQgb3ZlciBUdW5uZWxzLg0KICAgVGhpcyBk b2N1bWVudCBleHRlbmRzIHRoZSBDViB2YWx1ZXMgZGVmaW5lZCBpbiBSRkM1ODg1Lg0KDQoNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlh dA0KDQo= --_003_315041E4211CB84E86EF7C25A2AB583D54337F7Cxmbrcdx15ciscoc_-- From nobody Mon Mar 16 11:38:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7811A8A60 for ; Mon, 16 Mar 2015 11:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 oucr1MxfGYlx for ; Mon, 16 Mar 2015 11:38:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 56DC31A8A3D for ; Mon, 16 Mar 2015 11:38:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E5C4FC0B9; Mon, 16 Mar 2015 14:38:15 -0400 (EDT) Date: Mon, 16 Mar 2015 14:38:15 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 92 - Get your slides in! Message-ID: <20150316183815.GA1645@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:38:17 -0000 Working Group, http://www.ietf.org/proceedings/92/agenda/agenda-92-bfd We meet very early during IETF 92. Now is a *great* time to send the chairs your slides to post. -- Jeff From nobody Wed Mar 18 13:08:56 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DFC1A88A4 for ; Wed, 18 Mar 2015 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apH5PfmOaKZv for ; Wed, 18 Mar 2015 13:08:52 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE361A8891 for ; Wed, 18 Mar 2015 13:08:52 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 36E59C283; Wed, 18 Mar 2015 16:08:52 -0400 (EDT) Date: Wed, 18 Mar 2015 16:08:52 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [rfc-editor@rfc-editor.org: RFC 7492 on Analysis of Bidirectional Forwarding Detection (BFD) SecurityAccording to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines] Message-ID: <20150318200852.GA30710@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 20:08:54 -0000 Thanks to the reviewers in BFD for supporting this KARP work. -- Jeff ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Wed, 18 Mar 2015 13:05:11 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: rfc-editor@rfc-editor.org Subject: RFC 7492 on Analysis of Bidirectional Forwarding Detection (BFD) SecurityAccording to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines A new Request for Comments is now available in online RFC libraries. RFC 7492 Title: Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines Author: M. Bhatia, D. Zhang, M. Jethanandani Status: Informational Stream: IETF Date: March 2015 Mailbox: manav@ionosnetworks.com, dacheng.zhang@gmail.com, mjethanandani@gmail.com Pages: 9 Characters: 21689 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-karp-bfd-analysis-08.txt URL: https://www.rfc-editor.org/info/rfc7492 This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ----- End forwarded message ----- From nobody Sun Mar 22 08:35:35 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8261A8A07 for ; Sun, 22 Mar 2015 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BD0fQDKqvMw9 for ; Sun, 22 Mar 2015 08:35:30 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5247F1A89F9 for ; Sun, 22 Mar 2015 08:35:30 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so107565020obb.1 for ; Sun, 22 Mar 2015 08:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=VkbDuBw2STniSn1Uq64mjayKnodngRwuvU1d745CpRU=; b=u7gOaGsG6HXvdTyZeZUVvni5wXRV9OFG2zaXs1Sm11O85X00SKyRlXC2p5iEAsuq5j G2IUnXQvtqw4nO7Dei5vOpKsLvkMDkMewG9q8qm//q48Gdc7igfgKk0g1NfjXADg1WSq wwWR3xpFSHkOis8uKMh3dE7jnjWD+fuEeYlZils/CsexhYQKcj0PalTuuDSbKWGbhxS9 jMQtVpUUH5QM3+gKU2pqo2vPYs/oif91HK+S01X+uBqGJMs6nlK2D6twcwU5hhpL4oLy KB/Zi3pMIN84AvoJEFTFUBWd5VS6tTI+gmD9fqSkva1Kv8tG6o1mWIr4+CTFwApfQ37Q yNEA== X-Received: by 10.60.120.36 with SMTP id kz4mr72438390oeb.47.1427038529747; Sun, 22 Mar 2015 08:35:29 -0700 (PDT) Received: from NoboAkiyaPC (ip-64-134-6-222.public.wayport.net. [64.134.6.222]) by mx.google.com with ESMTPSA id x8sm6169778oew.4.2015.03.22.08.35.28 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Mar 2015 08:35:28 -0700 (PDT) From: "Nobo Akiya" To: Subject: Affiliation change Date: Sun, 22 Mar 2015 10:35:24 -0500 Message-ID: <010301d064b5$d1c41090$754c31b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBktbRRbsZ8eQxHRFmWO8vqQq3FuQ== Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:35:32 -0000 Hello BFD WG, We all contribute to IETF as individuals, thus our affiliations do not really matter, officially :) However, I wanted to send out this email to be transparent. I am no longer with Cisco Systems, and have joined a smaller company. This change should have no impact as I will continue my contributions to the BFD WG as both an individual contributor and a co-chair (and looking forward to doing so!). If you have any comments/questions/concerns, please do grab me at Dallas to discuss or drop me an email. Thanks! -Nobo From nobody Mon Mar 23 08:31:58 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0581A9031; Mon, 23 Mar 2015 08:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsEgbPbwtPnK; Mon, 23 Mar 2015 08:31:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA681A90D9; Mon, 23 Mar 2015 08:31:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-zheng-bfd-yang-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323153149.2892.45453.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:31:49 -0700 Archived-At: Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:31:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Yang Data Model for Bidirectional Forwarding Detection (BFD) Authors : Lianshu Zheng Reshad Rahman Santosh Pallagatti Mahesh Jethanandani Filename : draft-zheng-bfd-yang-01.txt Pages : 29 Date : 2015-03-23 Abstract: This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-zheng-bfd-yang-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-zheng-bfd-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 08:31:59 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ED81A9031; Mon, 23 Mar 2015 08:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lbpGz84WcaU; Mon, 23 Mar 2015 08:31:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA44F1A90DE; Mon, 23 Mar 2015 08:31:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , Subject: New Version Notification - draft-zheng-bfd-yang-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323153149.2892.21500.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:31:49 -0700 Archived-At: 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: Mon, 23 Mar 2015 15:31:56 -0000 A new version (-01) has been submitted for draft-zheng-bfd-yang: http://www.ietf.org/internet-drafts/draft-zheng-bfd-yang-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-zheng-bfd-yang/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-zheng-bfd-yang-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Mar 23 11:54:07 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7791AD244 for ; Mon, 23 Mar 2015 11:54:05 -0700 (PDT) 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 NsP98EyV0I6f for ; Mon, 23 Mar 2015 11:54:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DD11AD1D5 for ; Mon, 23 Mar 2015 11:53:44 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-a6-550fff5d1585 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B2.DD.17241.D5FFF055; Mon, 23 Mar 2015 12:56:13 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 14:53:42 -0400 From: Gregory Mirsky To: "rtg-bfd@ietf.org" Subject: BFD Echo format Thread-Topic: BFD Echo format Thread-Index: AdBlmmopgPWDaLKzRLmVoox6EijHOA== Date: Mon, 23 Mar 2015 18:53:42 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> 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_7347100B5761DC41A166AC17F22DF1121B9382C1eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPlG7sf/5Qg7UHTS0+/9nG6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJa5bUwFr9QrTu7ZxdjA2KfcxcjJISFgInF+13d2CFtM4sK9 9WxdjFwcQgJHGCXu9W9khXCWM0o0TXjHAlLFJmAk8WJjD1iHiICmxNo521lBbGEBCYmV614y Q8RlJa49PwtUzwFk60nsX8sNEmYRUJXYuuw4G4jNK+ArcfboNbAxjECLv59awwRiMwuIS9x6 Mp8J4iABiSV7zjND2KISLx//Y4WwlSTmvL7GDFGfL7F48g2omYISJ2c+YZnAKDQLyahZSMpm ISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQID/5gEm+MOxgWf LA8xCnAwKvHwGgjyhwqxJpYVV+YeYpTmYFES5y27cjBESCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA2PepMyKlplm3qXvfmxhm5neKHpSsjXx0ZNMQdateluDlBr/rynwc3iyb88rf8v6fw1b T3Q9bW/a5i/QVXzXdOWDjtY2ywUtbk3L1woEyjNvKv83n7PFtam0dLJp8NyaDVF3f+nLZsn4 n1xl92DjB6Z1CjelHvC1zo/iZVVermVY/Fhb7oaalRJLcUaioRZzUXEiAIpXDHldAgAA Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:54:05 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B9382C1eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I stand corrected, BFD Echo format is not defined in the RFC 5880 but there= requirement suggesting that BFD Discriminator MAY be used to demux Echo re= plies: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B9382C1eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

I stand corrected, BFD Echo format is not defined in= the RFC 5880 but there requirement suggesting that BFD Discriminator MAY b= e used to demux Echo replies:

  = ; The payload of a BFD Echo packet is a local matter, since only the

  = ; sending system ever processes the content.  The only requirement is<= o:p>

  = ; that sufficient information is included to demultiplex the received<= /o:p>

  = ; packet to the correct BFD session after it is looped back to the

  = ; sender.  The contents are otherwise outside the scope of this

  = ; specification.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B9382C1eusaamb103erics_-- From nobody Mon Mar 23 16:19:04 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488EE1A1AA1 for ; Mon, 23 Mar 2015 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6NB-EdRBhcO for ; Mon, 23 Mar 2015 16:19:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680501A1AB4 for ; Mon, 23 Mar 2015 16:19:00 -0700 (PDT) Received: by wetk59 with SMTP id k59so150245108wet.3 for ; Mon, 23 Mar 2015 16:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=e62PpQ+Ynw29S64Olt/jcgGw4DwCH9pXhU6NkQ/u2lk=; b=o+0NS+DenDz+JdhppLAdgj6zn/IvwlQ72aL4I02MF/IQS/Pu+gKoFl5WgQWz+hV20o x45mhJ6eM1jCAq4h6lHlvJWXqDVBPrA/gNP5dDwGO/8MTgE7YrOYcNX/r+j0MYeMOD2s rT1vrYLgYsakaZJxpY7gLaNTNzooL2s/1WQ8jkRUQ7gk9WZCBBtLac4RkWLappFVRjsr HpVJVqRIlMPpIT2kUCLJ6a1sqsNeq0cmYSMXm/8pim9VeTlUDroCiUCP2nw4WBXjGfGA eMPRX9TtPw+1vjhSxvU6qTjQoqRFolyIKE81nObDZtwZ+JnlZtZ+CvQ6cy0OBrKezwD4 JzPg== X-Received: by 10.180.23.193 with SMTP id o1mr23347180wif.14.1427152738941; Mon, 23 Mar 2015 16:18:58 -0700 (PDT) Received: from NoboAkiyaPC ([2001:67c:370:176:ce0:9608:56b6:2a52]) by mx.google.com with ESMTPSA id u18sm13324141wib.1.2015.03.23.16.18.57 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Mar 2015 16:18:58 -0700 (PDT) From: "Nobo Akiya" To: "'Gregory Mirsky'" , References: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> Subject: RE: BFD Echo format Date: Mon, 23 Mar 2015 18:18:52 -0500 Message-ID: <006c01d065bf$bbd82d10$33888730$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01D06595.D3053250" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE16SkKAgHCp/TfSUXqHdNEmlPOpZ5fp2Cg Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:19:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01D06595.D3053250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Greg, I believe this comment was in context of S-BFD for VCCV. >From what I understand, the scenario which S-BFD for VCCV is looked into is the case where one end of the PW has very constrained resources. Using the classical BFD will require such devices to maintain a session object per PW, as opposed to S-BFD which only requires one reflector session. Your comment about why not send BFD echo packets over the PW? Sending a probe (BFD echo) with IP destination having the sender address, across multiple physical hops, always has the danger of the probe packet still coming back to the sender despite issues. Yes this is more likely on LSPs like LDP, RSVP (and less likely on PW) but it is possible that PW label gets exposed "somewhere" and that label value happens to match a different LSP, picking up traversal to a different node. Then there's the desire for return packets to come back on the reverse direction of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, this (i.e., reflector bouncing back packets on the reverse PW) is a change that needs to be made/standardized. So to me, S-BFD for VCCV makes sense. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM To: rtg-bfd@ietf.org Subject: BFD Echo format Dear All, I stand corrected, BFD Echo format is not defined in the RFC 5880 but there requirement suggesting that BFD Discriminator MAY be used to demux Echo replies: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Greg ------=_NextPart_000_006D_01D06595.D3053250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

I believe this comment = was in context of S-BFD for VCCV.

 

From what I understand, = the scenario which S-BFD for VCCV is looked into is the case where one = end of the PW has very constrained resources. Using the classical BFD = will require such devices to maintain a session object per PW, as = opposed to S-BFD which only requires one reflector = session.

 

Your comment about why = not send BFD echo packets over the PW? Sending a probe (BFD echo) with = IP destination having the sender address, across multiple physical hops, = always has the danger of the probe packet still coming back to the = sender despite issues. Yes this is more likely on LSPs like LDP, RSVP = (and less likely on PW) but it is possible that PW label gets exposed = “somewhere” and that label value happens to match a = different LSP, picking up traversal to a different = node.

 

Then there’s the = desire for return packets to come back on the reverse direction of the = forward PW. Whether we go with S-BFD for VCCV or BFD echo, this (i.e., = reflector bouncing back packets on the reverse PW) is a change that = needs to be made/standardized.

 

So to me, S-BFD for VCCV = makes sense.

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       

Thanks!

 

-Nobo

 

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory = Mirsky
Sent: March-23-15 1:54 PM
To: = rtg-bfd@ietf.org
Subject: BFD Echo = format

 

Dear All,

I stand corrected, BFD Echo format is not defined in the = RFC 5880 but there requirement suggesting that BFD Discriminator MAY be = used to demux Echo replies:

   The payload of a BFD Echo packet is a = local matter, since only the

   sending system ever processes the = content.  The only requirement is

   that sufficient information is included = to demultiplex the received

   packet to the correct BFD session after = it is looped back to the

   sender.  The contents are otherwise = outside the scope of this

   specification.

 

          =       Regards,

          =             &= nbsp;         = Greg

------=_NextPart_000_006D_01D06595.D3053250-- From nobody Mon Mar 23 16:19:13 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259EA1A1A97 for ; Mon, 23 Mar 2015 16:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KFc0kRjnI7L9 for ; Mon, 23 Mar 2015 16:19:06 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD141A1ABB for ; Mon, 23 Mar 2015 16:19:06 -0700 (PDT) Received: by wibg7 with SMTP id g7so60561883wib.1 for ; Mon, 23 Mar 2015 16:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=4pt6Kk0vUytii4QI6w9W4wLuDhGXqloMKm+3LzvlSQ0=; b=YaS8wvm9uDLK72kLDme40u2R8W2K72+NQ1iOV2DtXiZ5wRDCUfyhKB+0lxy34LzaoO y26xnEjtIt+oaFW7ou913RO81wqPrKtvm5Zy5SjgbysC2E6Fp74i/gpg366/U26woc15 Xo0W5zQM7FysrDi/aj93jw6Hd3+O5Qqn27UsjL9nkLa6IP0o51t8jXgWEw9wR3b4yulW KUMJ3DXwzZXFjOn0JdvSFMD4aqcs+kJyf9pxWPC+5DNDZuuSRwlIwC/M8cMy6Lt5wRMD pAyV7uc+giMD9ZSuouYP2ddhIKGMip2YmA64NX6YsIIuLSL3HYJUkvtGofWW/5LSCl+5 EPYA== X-Received: by 10.194.8.99 with SMTP id q3mr2759065wja.88.1427152745258; Mon, 23 Mar 2015 16:19:05 -0700 (PDT) Received: from NoboAkiyaPC ([2001:67c:370:176:ce0:9608:56b6:2a52]) by mx.google.com with ESMTPSA id dz6sm13339522wib.0.2015.03.23.16.19.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Mar 2015 16:19:04 -0700 (PDT) From: "Nobo Akiya" To: Subject: S-BFD Alert Discriminator Date: Mon, 23 Mar 2015 18:18:59 -0500 Message-ID: <007101d065bf$bfc8c830$3f5a5890$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdBlvzca4eHZ+83oS7yMNwyIl2hyfA== Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:19:11 -0000 Hello WG, At the mic during the BFD session, there was a comment about "let's not do this alert discriminator". The consequence of not doing the alert discriminator is that all usages of S-BFD will require protocol extensions to advertise S-BFD discriminators. Speaking with Greg and others after the session, we do have a consensus. - Let's not pursue the alert discriminator for now. - If the WG feel that this is needed at a later time, we can revive this mechanism. If anyone feels differently, please do chime in. Thanks! -Nobo From nobody Mon Mar 23 18:21:05 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3038A1B2B08 for ; Mon, 23 Mar 2015 18:21:04 -0700 (PDT) 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 8K0AwrRsQQIG for ; Mon, 23 Mar 2015 18:20:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308D41B2B05 for ; Mon, 23 Mar 2015 18:20:59 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-6b-551066463729 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 09.8D.12456.64660155; Mon, 23 Mar 2015 20:15:18 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Mon, 23 Mar 2015 21:20:55 -0400 From: Gregory Mirsky To: Nobo Akiya , "rtg-bfd@ietf.org" Subject: RE: BFD Echo format Thread-Topic: BFD Echo format Thread-Index: AdBlmmopgPWDaLKzRLmVoox6EijHOAARtZ0AAASfruA= Date: Tue, 24 Mar 2015 01:20:55 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B93885F@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> <006c01d065bf$bbd82d10$33888730$@gmail.com> In-Reply-To: <006c01d065bf$bbd82d10$33888730$@gmail.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_7347100B5761DC41A166AC17F22DF1121B93885Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPrK5bmkCowbsXkhZPzr1jsfj8Zxuj A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUxYfEJpoKlZRVLl9Y2MN5M62Lk4JAQMJFo 7+PsYuQEMsUkLtxbz9bFyMUhJHCEUeLtyiZmCGc5o8TO2yeYQarYBIwkXmzsYQexRQSCJP60 HGQFsYUFZCRW7XzBCBGXlbj2/CwLhG0l8XveLrA4i4CqxMFzx8DqeQV8JW4+6GQCsYUEqiV+ XzwCVs8pYCGx7fFeMJsR6KLvp9aA1TALiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUk5ry+ xgxRny+xZX4nM8QuQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DET svgCRvZVjBylxalluelGBpsYgbFzTIJNdwfjnpeWhxgFOBiVeHg3JAmECrEmlhVX5h5ilOZg URLnXfTgYIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRv5buzPWTfMWPj7D6s46+ZaPrn8T +5cEh/U6XvvZLL4yRfjdLz+lmjUXY68IcPQGlT0+yaRQszH7OGvx3oN7N8YuXry0smaFlxGX xJ4LFdfvHme6srr2QmziKgHxe97vt5Tw33IzT0ucEv0q9NSbiymPJ12IqfEsdxCJaYgQrrQp fXs+8nTQMiWW4oxEQy3mouJEAGQRH5Z+AgAA Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 01:21:04 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B93885Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nobo, thank you for your thoughtful and interesting, as always, comments. I've realized, after the session, that encapsulation of BFD Echo over LSP o= r PW MUST be different from what defined in RFC 5880. I think it must follo= w the same principle as set in RFC 5884 for Async BFD mode. And I agree that PW, unlike LSP (at least most LSP constructs), is a bi-dir= ectional construct. Thus, as I think of it, operators more interested in ve= rifying data plane availability in both directions. If we propose two-way s= ingle-ended mechanism to check data path of the particular PW, then, I imag= ine, the return path MUST be in-band, not over IP path. I think that we nee= d to note that in our discussion of S-BFD or BFD Echo over VCCV as a requir= ement. Then we can see whether extending BFD Echo to MPLS LSP and PW or usi= ng S-BFD bring better solution, particularly since we already have ICMP and= LSP Ping over VCCV defined. Regards, Greg From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] Sent: Monday, March 23, 2015 6:19 PM To: Gregory Mirsky; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Greg, I believe this comment was in context of S-BFD for VCCV. >From what I understand, the scenario which S-BFD for VCCV is looked into is= the case where one end of the PW has very constrained resources. Using the= classical BFD will require such devices to maintain a session object per P= W, as opposed to S-BFD which only requires one reflector session. Your comment about why not send BFD echo packets over the PW? Sending a pro= be (BFD echo) with IP destination having the sender address, across multipl= e physical hops, always has the danger of the probe packet still coming bac= k to the sender despite issues. Yes this is more likely on LSPs like LDP, R= SVP (and less likely on PW) but it is possible that PW label gets exposed "= somewhere" and that label value happens to match a different LSP, picking u= p traversal to a different node. Then there's the desire for return packets to come back on the reverse dire= ction of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, thi= s (i.e., reflector bouncing back packets on the reverse PW) is a change tha= t needs to be made/standardized. So to me, S-BFD for VCCV makes sense. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM To: rtg-bfd@ietf.org Subject: BFD Echo format Dear All, I stand corrected, BFD Echo format is not defined in the RFC 5880 but there= requirement suggesting that BFD Discriminator MAY be used to demux Echo re= plies: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B93885Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Nobo,

thank you for your tho= ughtful and interesting, as always, comments.

 

I’ve realized, a= fter the session, that encapsulation of BFD Echo over LSP or PW MUST be dif= ferent from what defined in RFC 5880. I think it must follow the same princ= iple as set in RFC 5884 for Async BFD mode.

 

And I agree that PW, u= nlike LSP (at least most LSP constructs), is a bi-directional construct. Th= us, as I think of it, operators more interested in verifying data plane ava= ilability in both directions. If we propose two-way single-ended mechanism to check data path of the particula= r PW, then, I imagine, the return path MUST be in-band, not over IP path. I= think that we need to note that in our discussion of S-BFD or BFD Echo ove= r VCCV as a requirement. Then we can see whether extending BFD Echo to MPLS LSP and PW or using S-BFD bring= better solution, particularly since we already have ICMP and LSP Ping over= VCCV defined.

 

   &nbs= p;            Regard= s,

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

 

From: Nobo Aki= ya [mailto:nobo.akiya.dev@gmail.com]
Sent: Monday, March 23, 2015 6:19 PM
To: Gregory Mirsky; rtg-bfd@ietf.org
Subject: RE: BFD Echo format

 

Hi Greg= ,

&n= bsp;

I belie= ve this comment was in context of S-BFD for VCCV.

&n= bsp;

From wh= at I understand, the scenario which S-BFD for VCCV is looked into is the ca= se where one end of the PW has very constrained resources. Using the classi= cal BFD will require such devices to maintain a session object per PW, as opposed to S-BFD which only requires one refle= ctor session.

&n= bsp;

Your co= mment about why not send BFD echo packets over the PW? Sending a probe (BFD= echo) with IP destination having the sender address, across multiple physi= cal hops, always has the danger of the probe packet still coming back to the sender despite issues. Yes this is m= ore likely on LSPs like LDP, RSVP (and less likely on PW) but it is possibl= e that PW label gets exposed “somewhere” and that label value h= appens to match a different LSP, picking up traversal to a different node.

&n= bsp;

Then th= ere’s the desire for return packets to come back on the reverse direc= tion of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, this= (i.e., reflector bouncing back packets on the reverse PW) is a change that needs to be made/standardized.

&n= bsp;

So to m= e, S-BFD for VCCV makes sense.

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

Thanks!=

&n= bsp;

-Nobo

&n= bsp;

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM
To: rtg-bfd@ietf.org
Subject: BFD Echo format

 

Dear All,

I stand corrected, BFD Echo format is not defined in= the RFC 5880 but there requirement suggesting that BFD Discriminator MAY b= e used to demux Echo replies:

  = ; The payload of a BFD Echo packet is a local matter, since only the

  = ; sending system ever processes the content.  The only requirement is<= o:p>

  = ; that sufficient information is included to demultiplex the received<= /o:p>

  = ; packet to the correct BFD session after it is looped back to the

  = ; sender.  The contents are otherwise outside the scope of this

  = ; specification.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B93885Feusaamb103erics_-- From nobody Tue Mar 24 07:35:55 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43B21A8770 for ; Tue, 24 Mar 2015 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOLxxzPXCA5Y for ; Tue, 24 Mar 2015 07:35:50 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6581A8764 for ; Tue, 24 Mar 2015 07:35:49 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so98037803wib.1 for ; Tue, 24 Mar 2015 07:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=4kz20T21Yay7SI8atBxMSQpn5QANea1k/qDZIseNEPs=; b=avPnWA1HvsQ3N/NgVGqAn2vAvIo32eJ8oVmM3k7CLKipQk99op6eYgu3UbQ6va4kNB z2pQemDdwFBituGawYr3btaiDO5OgWf9v5muJLjD3JRnagkZayGod/v+O/HmT6JdZi9c WAap8+PydvX9HzeNl2v3KgIkPU267E+QL1cGqNXKzDoHQMobyp2X8hO/06YpoHsqGFIg oOaemKDaAJ/1w8a2HL0bQPsgzxIAu25FK02wcd+mFMmowrcbb9FkNWk4a7HmSZU7SBDB T7QHe7QhOqIOmHC6kJd/ypwEgwEQ0Z/CxVOsKIdywXen96R0b1M4TQR+phbism2ntKqS 4y2A== X-Received: by 10.194.223.5 with SMTP id qq5mr8769956wjc.152.1427207748316; Tue, 24 Mar 2015 07:35:48 -0700 (PDT) Received: from NoboAkiyaPC ([2001:67c:370:176:7c71:12fa:9826:8d5e]) by mx.google.com with ESMTPSA id hj10sm6329874wjc.48.2015.03.24.07.35.46 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Mar 2015 07:35:47 -0700 (PDT) From: "Nobo Akiya" To: "'Gregory Mirsky'" , References: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> <006c01d065bf$bbd82d10$33888730$@gmail.com> <7347100B5761DC41A166AC17F22DF1121B93885F@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B93885F@eusaamb103.ericsson.se> Subject: RE: BFD Echo format Date: Tue, 24 Mar 2015 09:35:41 -0500 Message-ID: <002301d0663f$cfbd3200$6f379600$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01D06615.E6EBE4F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE16SkKAgHCp/TfSUXqHdNEmlPOpQIn0A2HAwUQA6GeN0VYUA== Content-Language: en-ca Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:35:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01D06615.E6EBE4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Greg, I absolutely agree on the S-BFD reverse path needing to take the corresponding PW. I peeked into draft-gp-pals-seamless-vccv, and I did find a text for this. 2.2.2. S-BFD Reflector Operation All point to point pseudowires are bidirectional, the S-BFD Reflector therefore reflects the S-BFD packet back to the Initiator using the VCCV channel of the reverse direction of the PW on which it was received. So, even though this key aspect was not described in the presentation, it looks like the authors did consider this. Thanks! -Nobo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: March-23-15 8:21 PM To: Nobo Akiya; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Nobo, thank you for your thoughtful and interesting, as always, comments. I've realized, after the session, that encapsulation of BFD Echo over LSP or PW MUST be different from what defined in RFC 5880. I think it must follow the same principle as set in RFC 5884 for Async BFD mode. And I agree that PW, unlike LSP (at least most LSP constructs), is a bi-directional construct. Thus, as I think of it, operators more interested in verifying data plane availability in both directions. If we propose two-way single-ended mechanism to check data path of the particular PW, then, I imagine, the return path MUST be in-band, not over IP path. I think that we need to note that in our discussion of S-BFD or BFD Echo over VCCV as a requirement. Then we can see whether extending BFD Echo to MPLS LSP and PW or using S-BFD bring better solution, particularly since we already have ICMP and LSP Ping over VCCV defined. Regards, Greg From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] Sent: Monday, March 23, 2015 6:19 PM To: Gregory Mirsky; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Greg, I believe this comment was in context of S-BFD for VCCV. >From what I understand, the scenario which S-BFD for VCCV is looked into is the case where one end of the PW has very constrained resources. Using the classical BFD will require such devices to maintain a session object per PW, as opposed to S-BFD which only requires one reflector session. Your comment about why not send BFD echo packets over the PW? Sending a probe (BFD echo) with IP destination having the sender address, across multiple physical hops, always has the danger of the probe packet still coming back to the sender despite issues. Yes this is more likely on LSPs like LDP, RSVP (and less likely on PW) but it is possible that PW label gets exposed "somewhere" and that label value happens to match a different LSP, picking up traversal to a different node. Then there's the desire for return packets to come back on the reverse direction of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, this (i.e., reflector bouncing back packets on the reverse PW) is a change that needs to be made/standardized. So to me, S-BFD for VCCV makes sense. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM To: rtg-bfd@ietf.org Subject: BFD Echo format Dear All, I stand corrected, BFD Echo format is not defined in the RFC 5880 but there requirement suggesting that BFD Discriminator MAY be used to demux Echo replies: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Greg ------=_NextPart_000_0024_01D06615.E6EBE4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

I absolutely agree on = the S-BFD reverse path needing to take the corresponding PW. I peeked = into draft-gp-pals-seamless-vccv, and I did find a text for = this.

 

2.2.2.  = S-BFD Reflector Operation

 

      All point to point pseudowires are = bidirectional, the S-BFD

      Reflector therefore reflects the = S-BFD packet back to the

      Initiator using the VCCV channel of = the reverse direction of the

      PW on which it was = received.

 

So, even though this key = aspect was not described in the presentation, it looks like the authors = did consider this.

 

Thanks!

 

-Nobo

 

From: Gregory Mirsky = [mailto:gregory.mirsky@ericsson.com]
Sent: March-23-15 8:21 = PM
To: Nobo Akiya; rtg-bfd@ietf.org
Subject: RE: BFD = Echo format

 

Hi Nobo,

thank you = for your thoughtful and interesting, as always, = comments.

 

I’ve = realized, after the session, that encapsulation of BFD Echo over LSP or = PW MUST be different from what defined in RFC 5880. I think it must = follow the same principle as set in RFC 5884 for Async BFD = mode.

 

And I agree = that PW, unlike LSP (at least most LSP constructs), is a bi-directional = construct. Thus, as I think of it, operators more interested in = verifying data plane availability in both directions. If we propose = two-way single-ended mechanism to check data path of the particular PW, = then, I imagine, the return path MUST be in-band, not over IP path. I = think that we need to note that in our discussion of S-BFD or BFD Echo = over VCCV as a requirement. Then we can see whether extending BFD Echo = to MPLS LSP and PW or using S-BFD bring better solution, particularly = since we already have ICMP and LSP Ping over VCCV = defined.

 

        &= nbsp;       = Regards,

        &= nbsp;           &n= bsp;           = Greg

 

 

Hi = Greg,

 

I believe this comment = was in context of S-BFD for VCCV.

 

From what I understand, = the scenario which S-BFD for VCCV is looked into is the case where one = end of the PW has very constrained resources. Using the classical BFD = will require such devices to maintain a session object per PW, as = opposed to S-BFD which only requires one reflector = session.

 

Your comment about why = not send BFD echo packets over the PW? Sending a probe (BFD echo) with = IP destination having the sender address, across multiple physical hops, = always has the danger of the probe packet still coming back to the = sender despite issues. Yes this is more likely on LSPs like LDP, RSVP = (and less likely on PW) but it is possible that PW label gets exposed = “somewhere” and that label value happens to match a = different LSP, picking up traversal to a different = node.

 

Then there’s the = desire for return packets to come back on the reverse direction of the = forward PW. Whether we go with S-BFD for VCCV or BFD echo, this (i.e., = reflector bouncing back packets on the reverse PW) is a change that = needs to be made/standardized.

 

So to me, S-BFD for VCCV = makes sense.

        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;       

Thanks!

 

-Nobo

 

From: Rtg-bfd [mailto:rtg-bfd-bounces= @ietf.org] On Behalf Of Gregory Mirsky
Sent: = March-23-15 1:54 PM
To: rtg-bfd@ietf.org
Subject: = BFD Echo format

 

Dear All,

I stand corrected, BFD Echo format is not defined in the = RFC 5880 but there requirement suggesting that BFD Discriminator MAY be = used to demux Echo replies:

   The payload of a BFD Echo packet is a = local matter, since only the

   sending system ever processes the = content.  The only requirement is

   that sufficient information is included = to demultiplex the received

   packet to the correct BFD session after = it is looped back to the

   sender.  The contents are otherwise = outside the scope of this

   specification.

 

          =       Regards,

          =             &= nbsp;         = Greg

------=_NextPart_000_0024_01D06615.E6EBE4F0-- From nobody Tue Mar 24 08:27:28 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB141A879E for ; Tue, 24 Mar 2015 08:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 dmi18RKOrRWu for ; Tue, 24 Mar 2015 08:27:19 -0700 (PDT) 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 0EC951A88EF for ; Tue, 24 Mar 2015 08:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24687; q=dns/txt; s=iport; t=1427210837; x=1428420437; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SOAD/MndeoQFApMlmepUQ8IXv0lQrDlkmdJNGceve3w=; b=XViH1/dQ6YFGHdBOn5xsw+5x4a5TRX/S1mKEm6CQkfkfuLVlyykrQB7X G3to999wBLiZNEkOD6t5p9mXIzNgYEQjJ/HoXkVoe5EOU0Ak1qRjkTnSJ 2GX2ofYI0jVDm8h8mNAn7Jxntfji4SBINz2SXis3+8+Wl0V/UN6DoOkG8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BvCgBogRFV/4gNJK1cgkNDUloExBGIMAKBOUwBAQEBAQF9hBQBAQEELVwCAQgRBAEBCxYHByERFAkIAQEEARIIE4gAAxHDOA2FRAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLIYJHgUQ6NwGDF4EWBY5Cgg6IIoJojGiCYoNHIoICHIFQbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.11,458,1422921600"; d="scan'208,217";a="403148342" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP; 24 Mar 2015 15:27:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2OFRFLA008277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 15:27:15 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.24]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 10:27:15 -0500 From: "Vengada Prasad Govindan (venggovi)" To: Nobo Akiya , "'Gregory Mirsky'" , "rtg-bfd@ietf.org" Subject: RE: BFD Echo format Thread-Topic: BFD Echo format Thread-Index: AdBlmmopgPWDaLKzRLmVoox6EijHOAATzg4AAARDN4AAG8HEgAAI+wXQ Date: Tue, 24 Mar 2015 15:27:14 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D5438F68C@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B9382C1@eusaamb103.ericsson.se> <006c01d065bf$bbd82d10$33888730$@gmail.com> <7347100B5761DC41A166AC17F22DF1121B93885F@eusaamb103.ericsson.se> <002301d0663f$cfbd3200$6f379600$@gmail.com> In-Reply-To: <002301d0663f$cfbd3200$6f379600$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.30] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D5438F68Cxmbrcdx15ciscoc_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:27:24 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D5438F68Cxmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Greg/ Nobo, Thanks for this thoughtful discussion, I would like to clarify the motiva= tion of this draft: 1. There are scenarios where fault detection be initiated and managed= from one end since the logic to failover (to a backup PW) is present on on= ly on that end. The other end may participate in the PW establishment (sign= aling) or the PW may be provisioned but does not need to be actively involv= ed in fault detection. Also, the action of failing over to a backup PW is = made at one end. This motivated us to use SBFD instead of classical BFD. Wi= th classical BFD, though we could use echo in one direction, both ends need= to actively participate in the BFD session (through Async and by allocatin= g other BFD session resources). 2. However the circuit (PW) in use is a bi-directional construct as y= ou point out and hence the text in Sec2.2.2. Thanks to Nobo for helping clarify this. Prasad From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya Sent: Tuesday, March 24, 2015 7:36 AM To: 'Gregory Mirsky'; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Greg, I absolutely agree on the S-BFD reverse path needing to take the correspond= ing PW. I peeked into draft-gp-pals-seamless-vccv, and I did find a text fo= r this. 2.2.2. S-BFD Reflector Operation All point to point pseudowires are bidirectional, the S-BFD Reflector therefore reflects the S-BFD packet back to the Initiator using the VCCV channel of the reverse direction of the PW on which it was received. So, even though this key aspect was not described in the presentation, it l= ooks like the authors did consider this. Thanks! -Nobo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: March-23-15 8:21 PM To: Nobo Akiya; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Nobo, thank you for your thoughtful and interesting, as always, comments. I've realized, after the session, that encapsulation of BFD Echo over LSP o= r PW MUST be different from what defined in RFC 5880. I think it must follo= w the same principle as set in RFC 5884 for Async BFD mode. And I agree that PW, unlike LSP (at least most LSP constructs), is a bi-dir= ectional construct. Thus, as I think of it, operators more interested in ve= rifying data plane availability in both directions. If we propose two-way s= ingle-ended mechanism to check data path of the particular PW, then, I imag= ine, the return path MUST be in-band, not over IP path. I think that we nee= d to note that in our discussion of S-BFD or BFD Echo over VCCV as a requir= ement. Then we can see whether extending BFD Echo to MPLS LSP and PW or usi= ng S-BFD bring better solution, particularly since we already have ICMP and= LSP Ping over VCCV defined. Regards, Greg From: Nobo Akiya [mailto:nobo.akiya.dev@gmail.com] Sent: Monday, March 23, 2015 6:19 PM To: Gregory Mirsky; rtg-bfd@ietf.org Subject: RE: BFD Echo format Hi Greg, I believe this comment was in context of S-BFD for VCCV. >From what I understand, the scenario which S-BFD for VCCV is looked into is= the case where one end of the PW has very constrained resources. Using the= classical BFD will require such devices to maintain a session object per P= W, as opposed to S-BFD which only requires one reflector session. Your comment about why not send BFD echo packets over the PW? Sending a pro= be (BFD echo) with IP destination having the sender address, across multipl= e physical hops, always has the danger of the probe packet still coming bac= k to the sender despite issues. Yes this is more likely on LSPs like LDP, R= SVP (and less likely on PW) but it is possible that PW label gets exposed "= somewhere" and that label value happens to match a different LSP, picking u= p traversal to a different node. Then there's the desire for return packets to come back on the reverse dire= ction of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, thi= s (i.e., reflector bouncing back packets on the reverse PW) is a change tha= t needs to be made/standardized. So to me, S-BFD for VCCV makes sense. Thanks! -Nobo From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM To: rtg-bfd@ietf.org Subject: BFD Echo format Dear All, I stand corrected, BFD Echo format is not defined in the RFC 5880 but there= requirement suggesting that BFD Discriminator MAY be used to demux Echo re= plies: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Greg --_000_315041E4211CB84E86EF7C25A2AB583D5438F68Cxmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Greg/ Nobo,=

  Thanks for this= thoughtful discussion, I would like to clarify the motivation of this draf= t:

1.&n= bsp;      There are scen= arios where fault detection be initiated and managed from one end since the= logic to failover (to a backup PW) is present on only on that end. The oth= er end may participate in the PW establishment (signaling) or the PW may be provisioned but does not need to be actively = involved in fault detection. Also, the action  of failing over to a ba= ckup PW is made at one end. This motivated us to use SBFD instead of classi= cal BFD. With classical BFD, though we could use echo in one direction, both ends need to actively participate in= the BFD session (through Async and by allocating other BFD session resourc= es).

2.&n= bsp;      However the ci= rcuit (PW) in use is a bi-directional construct as you point out and hence = the text in Sec2.2.2.

Thanks to Nobo for hel= ping clarify this.

Prasad

 

From: Rtg-bfd = [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo Akiya
Sent: Tuesday, March 24, 2015 7:36 AM
To: 'Gregory Mirsky'; rtg-bfd@ietf.org
Subject: RE: BFD Echo format

 

Hi Greg= ,

&n= bsp;

I absol= utely agree on the S-BFD reverse path needing to take the corresponding PW.= I peeked into draft-gp-pals-seamless-vccv, and I did find a text for this.=

&n= bsp;

2.2.2.  S-BFD Refl= ector Operation

&n= bsp;

  &n= bsp;   All point to point pseudowires are bidirectional, the S-BF= D

  &n= bsp;   Reflector therefore reflects the S-BFD packet back to the<= o:p>

  &n= bsp;   Initiator using the VCCV channel of the reverse direction = of the

      PW on which = it was received.

&n= bsp;

So, eve= n though this key aspect was not described in the presentation, it looks li= ke the authors did consider this.

&n= bsp;

Thanks!=

&n= bsp;

-Nobo

&n= bsp;

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: March-23-15 8:21 PM
To: Nobo Akiya; rtg-bfd@ietf.org=
Subject: RE: BFD Echo format

 

Hi Nobo,

thank you for your tho= ughtful and interesting, as always, comments.

 

I’ve realized, a= fter the session, that encapsulation of BFD Echo over LSP or PW MUST be dif= ferent from what defined in RFC 5880. I think it must follow the same princ= iple as set in RFC 5884 for Async BFD mode.

 

And I agree that PW, u= nlike LSP (at least most LSP constructs), is a bi-directional construct. Th= us, as I think of it, operators more interested in verifying data plane ava= ilability in both directions. If we propose two-way single-ended mechanism to check data path of the particula= r PW, then, I imagine, the return path MUST be in-band, not over IP path. I= think that we need to note that in our discussion of S-BFD or BFD Echo ove= r VCCV as a requirement. Then we can see whether extending BFD Echo to MPLS LSP and PW or using S-BFD bring= better solution, particularly since we already have ICMP and LSP Ping over= VCCV defined.

 

   &nbs= p;            Regard= s,

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

 

From: Nobo Aki= ya [mailto:nobo.akiya.dev@gmail= .com]
Sent: Monday, March 23, 2015 6:19 PM
To: Gregory Mirsky; rtg-bfd@ietf= .org
Subject: RE: BFD Echo format

 

Hi Greg= ,

&n= bsp;

I belie= ve this comment was in context of S-BFD for VCCV.

&n= bsp;

From wh= at I understand, the scenario which S-BFD for VCCV is looked into is the ca= se where one end of the PW has very constrained resources. Using the classi= cal BFD will require such devices to maintain a session object per PW, as opposed to S-BFD which only requires one refle= ctor session.

&n= bsp;

Your co= mment about why not send BFD echo packets over the PW? Sending a probe (BFD= echo) with IP destination having the sender address, across multiple physi= cal hops, always has the danger of the probe packet still coming back to the sender despite issues. Yes this is m= ore likely on LSPs like LDP, RSVP (and less likely on PW) but it is possibl= e that PW label gets exposed “somewhere” and that label value h= appens to match a different LSP, picking up traversal to a different node.

&n= bsp;

Then th= ere’s the desire for return packets to come back on the reverse direc= tion of the forward PW. Whether we go with S-BFD for VCCV or BFD echo, this= (i.e., reflector bouncing back packets on the reverse PW) is a change that needs to be made/standardized.

&n= bsp;

So to m= e, S-BFD for VCCV makes sense.

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

Thanks!=

&n= bsp;

-Nobo

&n= bsp;

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: March-23-15 1:54 PM
To: rtg-bfd@ietf.org
Subject: BFD Echo format

 

Dear All,

I stand corrected, BFD Echo format is not defined in= the RFC 5880 but there requirement suggesting that BFD Discriminator MAY b= e used to demux Echo replies:

  = ; The payload of a BFD Echo packet is a local matter, since only the

  = ; sending system ever processes the content.  The only requirement is<= o:p>

  = ; that sufficient information is included to demultiplex the received<= /o:p>

  = ; packet to the correct BFD session after it is looped back to the

  = ; sender.  The contents are otherwise outside the scope of this

  = ; specification.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_315041E4211CB84E86EF7C25A2AB583D5438F68Cxmbrcdx15ciscoc_-- From nobody Tue Mar 24 12:42:02 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE97E1A891F; Tue, 24 Mar 2015 11:20:47 -0700 (PDT) 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 0eaR5z2vaxpJ; Tue, 24 Mar 2015 11:20:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB57C1A8835; Tue, 24 Mar 2015 11:20:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUC03297; Tue, 24 Mar 2015 18:20:41 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Mar 2015 18:20:40 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.68]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 02:20:31 +0800 From: Jiangyuanlong To: "Vengada Prasad Govindan (venggovi)" , "rtg-bfd@ietf.org" , "pals@ietf.org" Subject: RE: Requesting comments on SBFD-VCCV drafts Thread-Topic: Requesting comments on SBFD-VCCV drafts Thread-Index: AdBcG8bbDt4lFsaSQwiuvYh/1U3PNAKKHR4w Date: Tue, 24 Mar 2015 18:20:29 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A8C38BB@szxema506-mbs.china.huawei.com> References: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D54337F7C@xmb-rcd-x15.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.69.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 24 Mar 2015 12:42:00 -0700 Cc: "Carlos Pignataro \(cpignata\)" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 18:20:47 -0000 Hi Stewart, Jeffrey and other authors, If the purpose of this draft is not to deprecate the original VCCV BFD (0x1= 0) function for MPLS PW, please make it clear: - One option is clearly removing MPLS/PW-ACH Encapsulation from SBFD so tha= t BFD and SBFD complement with each other. - Another option is as the document describes, the same MPLS/PW is supporte= d by both SBFD and original BFD, then a guideline section is needed so that= consistent BFD type (SBFD or original BFD) can be chosen by the peer PEs (= e.g., both BFD types are supported by two PEs associated with a specific BF= D session). Regards, Yuanlong -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Vengada Prasad Govin= dan (venggovi) Sent: Thursday, March 12, 2015 12:53 AM To: rtg-bfd@ietf.org; pals@ietf.org Cc: Jeffrey Haas (jhaas@pfrc.org); Carlos Pignataro (cpign= ata); agmalis@gmail.com; nobo.akiya.dev@gmail.com; Stewart Bryant (stbryant= ) Subject: [Pals] Requesting comments on SBFD-VCCV drafts Hello all, We have submitted two new drafts: a. draft-gp-pals-seamless-vccv: This draft defines the SBFD protocol operat= ion for VCCV. https://datatracker.ietf.org/doc/draft-gp-pals-seamless-vccv/ b. draft-gp-l2tpext-sbfd-discriminator: This draft defines AVPs for adverti= sement of SBFD discriminators in L2TP. We welcome comments/ feedback on these drafts. https://datatracker.ietf.org/doc/draft-gp-l2tpext-sbfd-discriminator/ Thanks Prasad From nobody Wed Mar 25 09:13:34 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687881A8547 for ; Wed, 25 Mar 2015 09:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga6NaQXjE7L4 for ; Wed, 25 Mar 2015 09:13:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF061A87A9 for ; Wed, 25 Mar 2015 09:13:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2A3F2C281; Wed, 25 Mar 2015 12:13:27 -0400 (EDT) Date: Wed, 25 Mar 2015 12:13:27 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Candidate minutes for IETF92 BFD session Message-ID: <20150325161327.GA9607@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 16:13:33 -0000 https://www.ietf.org/proceedings/92/minutes/minutes-92-bfd Please review and send comments. -- Jeff and Nobo From nobody Thu Mar 26 07:57:57 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AC91A01AA for ; Thu, 26 Mar 2015 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 WGY8wJdJn8ZR for ; Thu, 26 Mar 2015 07:57:54 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0793A1A1A9E for ; Thu, 26 Mar 2015 07:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=252; q=dns/txt; s=iport; t=1427381764; x=1428591364; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b81ydzdUjxywHps+sj9NcjbYeWSI1LpCjiyTSK2iLgk=; b=lvhOhg1Szl8w4An0f7eWsm4gz+knatE2UNMH67xISCDM1ueIr3Fdffj9 dgS2hfk+6nvd93WKjg79ckdcSyRvqJnm2abeYsy6HYVuo/E96kgsw6qoU eqQtwNkha3UpWzF41JNAiahDUhJRzapP51sbLZ6i/CMJ9aqBX3pa6kDs8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBQAtHRRV/4ENJK1cgwZSWgTDV4FPhXUCgVg6EgEBAQEBAQF8hBUBAQQ6TwIBCA4oEDIlAgQBEogvDcsdAQEBAQEBAQEBAQEBAQEBAQEBARUEiyGEfIQtAQSQT4ltgRuDMI9eIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,472,1422921600"; d="scan'208";a="135548780" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP; 26 Mar 2015 14:56:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t2QEu3D6025977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Mar 2015 14:56:03 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 26 Mar 2015 09:56:03 -0500 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Candidate minutes for IETF92 BFD session Thread-Topic: Candidate minutes for IETF92 BFD session Thread-Index: AQHQZxb2a9uwwDCNgUy/1QlHaHdePZ0u294A Date: Thu, 26 Mar 2015 14:56:03 +0000 Message-ID: References: <20150325161327.GA9607@pfrc> In-Reply-To: <20150325161327.GA9607@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.86.250.98] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 14:57:56 -0000 Jeff and Nobo, looks good to me. Regards, Reshad. On 2015-03-25, 11:13 AM, "Jeffrey Haas" wrote: >https://www.ietf.org/proceedings/92/minutes/minutes-92-bfd > >Please review and send comments. > >-- Jeff and Nobo > From kd6913@att.com Fri Mar 27 16:08:58 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1605A1A00C2 for ; Fri, 27 Mar 2015 16:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6qTT8jmd7_qE for ; Fri, 27 Mar 2015 16:08:56 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41471A000B for ; Fri, 27 Mar 2015 16:08:55 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 703e5155.0.450236.00-2241.1202628.nbfkord-smmo06.seg.att.com (envelope-from ); Fri, 27 Mar 2015 23:08:55 +0000 (UTC) X-MXL-Hash: 5515e307491bcde6-5a6f0f60f6c5a8d46a3c5fdd503bd3431ba387f4 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2RN8sae001897 for ; Fri, 27 Mar 2015 19:08:54 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2RN8l9r001853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 27 Mar 2015 19:08:52 -0400 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Fri, 27 Mar 2015 23:08:29 GMT Received: from MISOUT7MSGUSRDH.ITServices.sbc.com ([169.254.8.97]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0224.002; Fri, 27 Mar 2015 19:08:29 -0400 From: "D'SOUZA, KEVIN L" To: "'rtg-bfd@ietf.org'" Subject: Questions on draft-ashesh-bfd-stability-00.txt Thread-Topic: Questions on draft-ashesh-bfd-stability-00.txt Thread-Index: AdBo4mW50xu/AiZzTyGNpo8P5Uim8w== Date: Fri, 27 Mar 2015 23:08:28 +0000 Message-ID: <9ED31ABC3EC39645977C39A2E8283C7C20CA75D1@MISOUT7MSGUSRDH.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.53.211] Content-Type: multipart/alternative; boundary="_000_9ED31ABC3EC39645977C39A2E8283C7C20CA75D1MISOUT7MSGUSRDH_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=bvz78jmi c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=DugL2gm1cRYA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqp] X-AnalysisOut: [o32RAAAA:8 a=emO1SXQWCLwA:10 a=taPFFvfeCmkL2QF6fzQA:9 a=Cj] X-AnalysisOut: [uIK1q_8ugA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4R] X-AnalysisOut: [SVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA] X-AnalysisOut: [:10 a=GTDQhsSdk7lQVVUj:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 23:10:34 -0000 --_000_9ED31ABC3EC39645977C39A2E8283C7C20CA75D1MISOUT7MSGUSRDH_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Ashesh and team, This is the first time I am posting to this list so please bear with me if = I am in error.... I have a few comments/questions on your draft: 1) Could you clarify if interop will be supported between these feature= s and a BFD instantiation that does not support these features 2) Can you specify that these features will be optional for an implemen= tation and some method should be provided to turn this capability off if ne= eded 3) Can you clarify in the scope the relationship between the measuremen= ts that one would obtain with this method vs other traditional methods to m= easure such criteria (e.g., CFM, TWAMP). My concern is if this feature pro= duces measurements that are different from the traditional methods, then it= would be difficult to reconcile them in a production environment 4) How would this impact the scale of the BFD protocol? Thanks Kevin --_000_9ED31ABC3EC39645977C39A2E8283C7C20CA75D1MISOUT7MSGUSRDH_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Ashesh and team,

 

This is the first time I am posting to this list so = please bear with me if I am in error….

I have a few comments/questions on your draft:<= /o:p>

 

1)     Could you clarify if interop will be supported betw= een these features and a BFD instantiation that does not support these feat= ures

2)     Can you specify that these features will be optiona= l for an implementation and some method should be provided to turn this cap= ability off if needed

3)     Can you clarify in the scope the relationship betwe= en the measurements that one would obtain with this method vs other traditi= onal methods to measure such criteria (e.g., CFM, TWAMP).  My concern = is if this feature produces measurements that are different from the traditional methods, then it would be difficul= t to reconcile them in a production environment

4)     How would this impact the scale of the BFD protocol= ?

 

Thanks

 

Kevin

 

--_000_9ED31ABC3EC39645977C39A2E8283C7C20CA75D1MISOUT7MSGUSRDH_-- From nobody Sat Mar 28 07:45:19 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F721A8867 for ; Sat, 28 Mar 2015 07:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[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 j4f2ZYfAe5HK for ; Sat, 28 Mar 2015 07:45:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25F781A8837 for ; Sat, 28 Mar 2015 07:45:16 -0700 (PDT) Received: from CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) by CO2PR0501MB1000.namprd05.prod.outlook.com (25.160.10.139) with Microsoft SMTP Server (TLS) id 15.1.125.19; Sat, 28 Mar 2015 14:45:01 +0000 Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB822.namprd05.prod.outlook.com (10.141.244.144) with Microsoft SMTP Server (TLS) id 15.1.112.19; Sat, 28 Mar 2015 14:44:59 +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.0125.002; Sat, 28 Mar 2015 14:45:00 +0000 From: Santosh P K To: "D'SOUZA, KEVIN L" , "'rtg-bfd@ietf.org'" Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt Thread-Topic: Questions on draft-ashesh-bfd-stability-00.txt Thread-Index: AdBo4mW50xu/AiZzTyGNpo8P5Uim8wAgqUcA Date: Sat, 28 Mar 2015 14:44:59 +0000 Message-ID: References: <9ED31ABC3EC39645977C39A2E8283C7C20CA75D1@MISOUT7MSGUSRDH.ITServices.sbc.com> In-Reply-To: <9ED31ABC3EC39645977C39A2E8283C7C20CA75D1@MISOUT7MSGUSRDH.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.12] authentication-results: att.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB822; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB1000; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(76576001)(87936001)(66066001)(2900100001)(62966003)(77096005)(92566002)(33656002)(2950100001)(86362001)(2656002)(99286002)(230783001)(74316001)(102836002)(122556002)(50986999)(77156002)(76176999)(40100003)(107886001)(46102003)(54356999)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB822; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:CO2PR0501MB822; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB822; x-forefront-prvs: 05299D545B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2015 14:44:59.7205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB822 X-OriginatorOrg: juniper.net Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 14:45:19 -0000 Hello Kevin, Thanks for your comments. Please see my inline reply.=20 >1) Could you clarify if interop will be supported between these features a= nd a BFD instantiation that does not support these features Yes, it should have a backward compatibility. We will update document on ba= ckward compatibility section with use cases.=20 > 2) Can you specify that these features will be optional for an implementa= tion and some method should be provided to turn this capability off if need= ed This is optional and it might be turned off by configuration? I think this = is implementation detail but we could have recommendation in draft.=20 >3) Can you clarify in the scope the relationship between the measurements = that one would obtain with this method vs other traditional methods to meas= ure >such criteria (e.g., CFM, TWAMP).=A0 My concern is if this feature pro= duces measurements that are different from the traditional methods, then it= would be >difficult to reconcile them in a production environment BFD will not replace CFM or TWAMP and it is not equipped to do so. We are u= pdating the document with use cases and other recommendation please stayed = tuned.=20 > 4) How would this impact the scale of the BFD protocol? Do you mean scale impact in steady state?=20 Thanks Santosh P K=20 From nobody Mon Mar 30 06:38:31 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D24B1ACEC3 for ; Mon, 30 Mar 2015 06:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 VTiYtsAfk9Sw for ; Mon, 30 Mar 2015 06:38:29 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6331ACE26 for ; Mon, 30 Mar 2015 06:38:28 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 4d159155.0.3681130.00-2321.9438760.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 30 Mar 2015 13:38:28 +0000 (UTC) X-MXL-Hash: 551951d455559f46-97ca81abd783b0cb77de87757bdcbc4dec702c25 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2UDcROB019770; Mon, 30 Mar 2015 09:38:27 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2UDcLf2019654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 09:38:24 -0400 Received: from MISOUT7MSGHUBAB.ITServices.sbc.com (MISOUT7MSGHUBAB.itservices.sbc.com [130.9.129.146]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 30 Mar 2015 13:38:15 GMT Received: from MISOUT7MSGUSRDH.ITServices.sbc.com ([169.254.8.97]) by MISOUT7MSGHUBAB.ITServices.sbc.com ([130.9.129.146]) with mapi id 14.03.0224.002; Mon, 30 Mar 2015 09:38:15 -0400 From: "D'SOUZA, KEVIN L" To: "'Santosh P K'" , "'rtg-bfd@ietf.org'" Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt Thread-Topic: Questions on draft-ashesh-bfd-stability-00.txt Thread-Index: AdBo4mW50xu/AiZzTyGNpo8P5Uim8wAgqUcAAGJaM0A= Date: Mon, 30 Mar 2015 13:38:15 +0000 Message-ID: <9ED31ABC3EC39645977C39A2E8283C7C20CA80CB@MISOUT7MSGUSRDH.ITServices.sbc.com> References: <9ED31ABC3EC39645977C39A2E8283C7C20CA75D1@MISOUT7MSGUSRDH.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.156.14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=WNbIqAQR c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=WLgGahgkwsUA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=emO1SXQWCLwA:10 a=OUXY8nFuA] X-AnalysisOut: [AAA:8 a=48vgC7mUAAAA:8 a=zt4B2SYcfcup1frjRrYA:9 a=wPNLvfGT] X-AnalysisOut: [eEIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:38:30 -0000 Hi Santosh, Thanks for your responses. Will look the updated version. On my last question, yes it is about scale impact in steady state. Kevin -----Original Message----- From: Santosh P K [mailto:santoshpk@juniper.net]=20 Sent: Saturday, March 28, 2015 10:45 AM To: D'SOUZA, KEVIN L; 'rtg-bfd@ietf.org' Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt Hello Kevin, Thanks for your comments. Please see my inline reply.=20 >1) Could you clarify if interop will be supported between these features a= nd a BFD instantiation that does not support these features Yes, it should have a backward compatibility. We will update document on ba= ckward compatibility section with use cases.=20 > 2) Can you specify that these features will be optional for an implementa= tion and some method should be provided to turn this capability off if need= ed This is optional and it might be turned off by configuration? I think this = is implementation detail but we could have recommendation in draft.=20 >3) Can you clarify in the scope the relationship between the measurements = that one would obtain with this method vs other traditional methods to meas= ure >such criteria (e.g., CFM, TWAMP).=A0 My concern is if this feature pro= duces measurements that are different from the traditional methods, then it= would be >difficult to reconcile them in a production environment BFD will not replace CFM or TWAMP and it is not equipped to do so. We are u= pdating the document with use cases and other recommendation please stayed = tuned.=20 > 4) How would this impact the scale of the BFD protocol? Do you mean scale impact in steady state?=20 Thanks Santosh P K=20 From nobody Mon Mar 30 10:29:31 2015 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4031A9062 for ; Mon, 30 Mar 2015 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5L10YTPKWRE for ; Mon, 30 Mar 2015 10:29:22 -0700 (PDT) Received: from BAY004-OMC2S7.hotmail.com (bay004-omc2s7.hotmail.com [65.54.190.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069DB1A905D for ; Mon, 30 Mar 2015 10:29:22 -0700 (PDT) Received: from BAY176-W15 ([65.54.190.123]) by BAY004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 30 Mar 2015 10:29:22 -0700 X-TMN: [kHErPCmkMECjiW5YLkqdK0FlH1TaAoBa] X-Originating-Email: [mishra.ashesh@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_212b32bc-7f67-4caa-8f84-b2680b4044d6_" From: Ashesh Mishra To: "D'SOUZA, KEVIN L" , 'Santosh P K' , "'rtg-bfd@ietf.org'" Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt Date: Mon, 30 Mar 2015 10:29:21 -0700 Importance: Normal In-Reply-To: <9ED31ABC3EC39645977C39A2E8283C7C20CA80CB@MISOUT7MSGUSRDH.ITServices.sbc.com> References: <9ED31ABC3EC39645977C39A2E8283C7C20CA75D1@MISOUT7MSGUSRDH.ITServices.sbc.com>, , <9ED31ABC3EC39645977C39A2E8283C7C20CA80CB@MISOUT7MSGUSRDH.ITServices.sbc.com> MIME-Version: 1.0 X-OriginalArrivalTime: 30 Mar 2015 17:29:22.0115 (UTC) FILETIME=[0F6BD130:01D06B0F] Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 17:29:24 -0000 --_212b32bc-7f67-4caa-8f84-b2680b4044d6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kevin=2C In steady state=2C there will be a scale impact of enabling stability measu= rement. However=2C it can be fairly small if the implementation is efficien= t. In our prototype=2C we saw less than 3% impact on CPU performance (and h= ence=2C little-to-no impact on scale) when we enabled this measurement (we = monitored both=2C timestamps and sequence numbers).=20 Best=2CAshesh > From: kd6913@att.com > To: santoshpk@juniper.net=3B rtg-bfd@ietf.org > Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt > Date: Mon=2C 30 Mar 2015 13:38:15 +0000 >=20 > Hi Santosh=2C >=20 > Thanks for your responses. Will look the updated version. > On my last question=2C yes it is about scale impact in steady state. >=20 > Kevin >=20 > -----Original Message----- > From: Santosh P K [mailto:santoshpk@juniper.net]=20 > Sent: Saturday=2C March 28=2C 2015 10:45 AM > To: D'SOUZA=2C KEVIN L=3B 'rtg-bfd@ietf.org' > Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt >=20 > Hello Kevin=2C > Thanks for your comments. Please see my inline reply.=20 >=20 > >1) Could you clarify if interop will be supported between these features= and a BFD instantiation that does not support these features >=20 > Yes=2C it should have a backward compatibility. We will update document o= n backward compatibility section with use cases.=20 >=20 > > 2) Can you specify that these features will be optional for an implemen= tation and some method should be provided to turn this capability off if ne= eded >=20 > This is optional and it might be turned off by configuration? I think thi= s is implementation detail but we could have recommendation in draft.=20 >=20 > >3) Can you clarify in the scope the relationship between the measurement= s that one would obtain with this method vs other traditional methods to me= asure >such criteria (e.g.=2C CFM=2C TWAMP). My concern is if this feature= produces measurements that are different from the traditional methods=2C t= hen it would be >difficult to reconcile them in a production environment >=20 > BFD will not replace CFM or TWAMP and it is not equipped to do so. We are= updating the document with use cases and other recommendation please staye= d tuned.=20 >=20 > > 4) How would this impact the scale of the BFD protocol? >=20 > Do you mean scale impact in steady state?=20 >=20 >=20 > Thanks > Santosh P K=20 >=20 = --_212b32bc-7f67-4caa-8f84-b2680b4044d6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Kevin=2C

I= n steady state=2C there will be a scale impact of enabling stability measur= ement. However=2C it can be fairly small if the implementation is efficient= . In our prototype=2C we saw less than 3% impact on CPU performance (and he= nce=2C little-to-no impact on scale) when we enabled this measurement (we m= onitored both=2C timestamps and sequence numbers). =3B

Best=2C
Ashesh



>= =3B From: kd6913@att.com
>=3B To: santoshpk@juniper.net=3B rtg-bfd@iet= f.org
>=3B Subject: RE: Questions on draft-ashesh-bfd-stability-00.txt=
>=3B Date: Mon=2C 30 Mar 2015 13:38:15 +0000
>=3B
>=3B Hi = Santosh=2C
>=3B
>=3B Thanks for your responses. Will look the up= dated version.
>=3B On my last question=2C yes it is about scale impac= t in steady state.
>=3B
>=3B Kevin
>=3B
>=3B -----Ori= ginal Message-----
>=3B From: Santosh P K [mailto:santoshpk@juniper.ne= t]
>=3B Sent: Saturday=2C March 28=2C 2015 10:45 AM
>=3B To: D'S= OUZA=2C KEVIN L=3B 'rtg-bfd@ietf.org'
>=3B Subject: RE: Questions on d= raft-ashesh-bfd-stability-00.txt
>=3B
>=3B Hello Kevin=2C
>= =3B Thanks for your comments. Please see my inline reply.
>=3B <= br>>=3B >=3B1) Could you clarify if interop will be supported between t= hese features and a BFD instantiation that does not support these features<= br>>=3B
>=3B Yes=2C it should have a backward compatibility. We wil= l update document on backward compatibility section with use cases.
>= =3B
>=3B >=3B 2) Can you specify that these features will be option= al for an implementation and some method should be provided to turn this ca= pability off if needed
>=3B
>=3B This is optional and it might b= e turned off by configuration? I think this is implementation detail but we= could have recommendation in draft.
>=3B
>=3B >=3B3) Can you= clarify in the scope the relationship between the measurements that one wo= uld obtain with this method vs other traditional methods to measure >=3Bs= uch criteria (e.g.=2C CFM=2C TWAMP). =3B My concern is if this feature = produces measurements that are different from the traditional methods=2C th= en it would be >=3Bdifficult to reconcile them in a production environmen= t
>=3B
>=3B BFD will not replace CFM or TWAMP and it is not equi= pped to do so. We are updating the document with use cases and other recomm= endation please stayed tuned.
>=3B
>=3B >=3B 4) How would thi= s impact the scale of the BFD protocol?
>=3B
>=3B Do you mean sc= ale impact in steady state?
>=3B
>=3B
>=3B Thanks
>= =3B Santosh P K
>=3B
= --_212b32bc-7f67-4caa-8f84-b2680b4044d6_--