From nobody Fri Aug 1 12:24:29 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901401B288E; Fri, 1 Aug 2014 11:00:18 -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 2colnJCOotv6; Fri, 1 Aug 2014 11:00:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A851A02D1; Fri, 1 Aug 2014 11:00:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: nobo@cisco.com, cpignata@cisco.com, wardd@cisco.com, santoshpk@juniper.net, manav@ionosnetworks.com Subject: IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-bfd-seamless-base-01 X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801180012.28778.28153.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 11:00:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AtGi-DZYr13Pwh2tGFCx7L-zmvg X-Mailman-Approved-At: Fri, 01 Aug 2014 12:24:28 -0700 Cc: akatlas@gmail.com, rtg-bfd@ietf.org, ipr-announce@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: Fri, 01 Aug 2014 18:00:18 -0000 Dear Nobo Akiya, Carlos Pignataro, David Ward, Juniper Networks, Manav Bhatia: An IPR disclosure that pertains to your Internet-Draft entitled "Seamless Bidirectional Forwarding Detection (S-BFD)" (draft-ietf-bfd-seamless-base) was submitted to the IETF Secretariat on 2014-07-31 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2402/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-bfd-seamless-base-01.""); The IETF Secretariat From nobody Fri Aug 1 16:40:46 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491201A01CB; Fri, 1 Aug 2014 16:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st7Xv8sjHH1X; Fri, 1 Aug 2014 16:40:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBD81A01D0; Fri, 1 Aug 2014 16:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-base-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140801234041.19675.62372.idtracker@ietfa.amsl.com> Date: Fri, 01 Aug 2014 16:40:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0-YHC0LUzNaBuYAcL8k1DUZ5rys 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: Fri, 01 Aug 2014 23:40:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Juniper Networks Filename : draft-ietf-bfd-seamless-base-02.txt Pages : 18 Date : 2014-08-01 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 1 17:07:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F88A1A01EE for ; Fri, 1 Aug 2014 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK6J1iJOqqYw for ; Fri, 1 Aug 2014 17:07:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91491A01F6 for ; Fri, 1 Aug 2014 17:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2575; q=dns/txt; s=iport; t=1406938067; x=1408147667; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=cAs9uwilsR92bzPtm1MqGsK6DTLleQiFVh9Dyw2JmKQ=; b=i1b6qifbDCGc+uLmEcOQuLnI7VTPk8NfsEwzg4ui0VuiWpUAQ9EtfIAV JVIVBvpgobZ3nrsnmlXC42HFxesq6jiS0bn0OBmb/OKlnjLbUPk0XTAUf tnC3TYLxMMIyMvPqP5mR423I19WF71hzIFmdr92LBKVr1C+j++yM60FoX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAIYq3FOtJV2d/2dsb2JhbABbgmojUlMEBMwVh0oBgQcWd4QFAQQ6UQEqFEImAQQbAYg5AQcFoUynBhePG4NngRwFjm6OYJMGg0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,783,1400025600"; d="scan'208";a="344527139" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 02 Aug 2014 00:07:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7207kZT029678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 2 Aug 2014 00:07:46 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 19:07:46 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: New Revisions of S-BFD Base/IP Documents Posted Thread-Topic: New Revisions of S-BFD Base/IP Documents Posted Thread-Index: Ac+t5WTz4ugJHOWYQc+4qnHimcnhvA== Date: Sat, 2 Aug 2014 00:07:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7cD5h5pSJVZF9N7aAwcQYV7aSls 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, 02 Aug 2014 00:07:51 -0000 Hello BFD WG, Authors have published new versions of s-bfd-base and s-bfd-ip documents (L= inks & diffs are listed below). In these versions: - Restructured the documents so that s-bfd-base describes BFD header mechan= ics and s-bfd-ip describes MPLS/IP/UDP mechanics. - Incorporated comments received from folks on the list (thanks guys!), and= special thanks for Marc Binderberger and Greg Mirsky for providing large s= et of comments. - Added texts for S-BFD Echo function. Note that mechanism are described in= s-bfd-base and port allocation is made in s-bfd-ip, but the the use case a= uthors have in mind is Segment Routing. Authors are planning to: - Request for WG adoption poll for s-bfd-ip document in a week or two. - Start working on s-bfd-sr (Segment Routing) document as the next priority= . Progressing s-bfd-base and s-bfd-ip documents will allow for basic S-BFD im= plementations via configuring remote discriminators on the IP and the MPLS = data planes. Progressing ISIS/OSPF S-BFD discriminator advertisement documents (links to= these also listed below) will allow for S-BFD implementations without manu= ally configuring remote discriminators. Progressing s-bfd-sr document will allow for S-BFD implementations (includi= ng echo) on the Segment Routing technology. And to accomplish above, we need your help to review the documents and prov= ide comments. Note that we welcome comments in all forms, including simple = positive comments like "revisions look good!" :) =3D=3D draft-ietf-bfd-seamless-base-02 URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-seamless= -base-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ba= se/ Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-= base-02 =3D=3D draft-akiya-bfd-seamless-ip-04 URL: http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamles= s-ip-04.txt Status: https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-i= p/ Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless= -ip-04 =3D=3D draft-ginsberg-isis-sbfd-discriminator http://datatracker.ietf.org/doc/draft-ginsberg-isis-sbfd-discriminator/ =3D=3D draft-bhatia-ospf-sbfd-discriminator http://datatracker.ietf.org/doc/draft-bhatia-ospf-sbfd-discriminator/ Thanks! -Nobo, on behalf of authors From nobody Mon Aug 4 07:59:07 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524301B2B34 for ; Mon, 4 Aug 2014 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hix20Og9VWL5 for ; Mon, 4 Aug 2014 07:58:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22851B2B2F for ; Mon, 4 Aug 2014 07:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2401; q=dns/txt; s=iport; t=1407164334; x=1408373934; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TolkdLK72VMxhcGJrIxrc3cjD7v+TSrT/lIIPJ/3jqI=; b=Q+K3w9YnumNqQf+Pu1DgryzvMuZvSIq5j2j1lisdyQ6WrNbx8LETQPQQ wP7NeHfT9x3hU0jinq+uwN92qSxsHzmayqzYuquZha3YgSQuYvAARcAGZ j35FRW7kksPclLIMzKiABMtfmI5iU+7GAQqqkCA9AMmuVnGiLUWJSEQWY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAIWf31OtJA2E/2dsb2JhbABagmojgSkE03UBgQ8Wd4QDAQEBBDoxGgQCAQgRBAEBAQoUCQcyFAkIAQEEEwiIOgHFLBePGzgGgymBHAWOd6Fug01sgQQEIB4 X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="344960939" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP; 04 Aug 2014 14:58:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s74EwqZW022471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Aug 2014 14:58:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 09:58:52 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: RE: S-BFD UDP Port Early Allocation Request Thread-Topic: S-BFD UDP Port Early Allocation Request Thread-Index: Ac+JWnLSI0Mb+nKFSUSh/rVVlhnVIQAaK1yAAApkkkD//8A2AP+ztW1g Date: Mon, 4 Aug 2014 14:58:51 +0000 Message-ID: References: <20140616192857.GE31387@pfrc> <20140616203814.GH31387@pfrc> In-Reply-To: <20140616203814.GH31387@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/4LqoV0HS4k1KKZwvVVBOiNfWC9g 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, 04 Aug 2014 14:58:58 -0000 Hello BFD WG, Recent S-BFD document restructure has pushed the UDP port assignment from d= raft-ietf-bfd-seamless-base to draft-akiya-bfd-seamless-ip. Due to this, th= e early port allocation request we had made became invalid (i.e. UDP port i= s now being requested from an individual document). Thus we have officially cancelled the early port allocation request. Here's the plan going forward. Step one: - draft-akiya-bfd-seamless-ip becomes a WG document. - the WG have a consensus that BOTH draft-ietf-bfd-seamless-base to draft-a= kiya-bfd-seamless-ip are technically (and structurally) solid. Step two: We will go with "Expert Review" to request the UDP port for S-BFD. Thanks! -Nobo > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@pfrc.org] > Sent: Monday, June 16, 2014 4:38 PM > To: Nobo Akiya (nobo) > Cc: Jeffrey Haas; Jeff Haas (jhaas@juniper.net); rtg-bfd@ietf.org; > adrian@olddog.co.uk; Alia Atlas > Subject: Re: S-BFD UDP Port Early Allocation Request >=20 > Nobo, >=20 > On Mon, Jun 16, 2014 at 08:31:30PM +0000, Nobo Akiya (nobo) wrote: > > > I do have a minor concern that, similar to other applications of BFD > > > that there may be multiple ports required for the S-BFD application > > > depending on transport. While the case in the base draft is > > > reasonably clear, the various application drafts haven't yet reached > > > maturity for us to be ready to consider adopting them. > > > > > > Do you believe the above is incorrect? > > > > That's a very fair question. It is my belief that one port will suffice= for S- > BFD on all transports, rather I strongly believe this is preferred to kee= p S- > BFD transport agnostic. > > > > > > > > Secondly, this is a reminder that such a request starts a timer: > > > Upon assignment, the temporary reservation is good for one year with > > > the possibility of a single one-year extension. Do you believe > > > we're ready to start that timer? > > > > Because folks are starting to implement this, we need a common port > number. Indeed this request will start the timer, but that's necessary at= this > point. Let us proceed to start the timer and aim to progress the draft be= fore > the timer expiry. >=20 > I think given the above, we have sufficient cause to advance early alloca= tion. > It's now up to the ADs. >=20 > -- Jeff From nobody Tue Aug 5 05:53:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD291A0149 for ; Mon, 4 Aug 2014 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Gtv25EHTV7HT for ; Mon, 4 Aug 2014 12:02:21 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9471A01AF for ; Mon, 4 Aug 2014 12:02:09 -0700 (PDT) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id s74J25Tr007043; Mon, 4 Aug 2014 19:02:05 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 40F51560B58; Mon, 4 Aug 2014 19:02:05 +0000 (UTC) RT-Owner: amanda.baber Subject: [IANA #772997] Early allocation of User Port for draft-ietf-bfd-seamless-base From: "Amanda Baber via RT" In-Reply-To: References: <086401cfa510$f8132de0$e83989a0$@olddog.co.uk> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #772997 Managed-BY: RT 4.0.8 (http://www.bestpractical.com/rt/) RT-Originator: amanda.baber@icann.org To: adrian@olddog.co.uk, draft-ietf-bfd-seamless-base@tools.ietf.org, jhaas@pfrc.org, michelle.cotton@icann.org, nobo@cisco.com, rtg-bfd@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 4 Aug 2014 19:02:05 +0000 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/29ILDksIsZb7M3d8-8GCb4fCdNU X-Mailman-Approved-At: Tue, 05 Aug 2014 05:53:53 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-prot-param@iana.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:02:25 -0000 Hi Nobo, No problem. I'll close the ticket. Best regards, Amanda Baber IANA Request Specialist ICANN On Mon Aug 04 14:37:08 2014, nobo@cisco.com wrote: > Hi Amanda and IANA folks, > > Adrian and myself have exchanged emails on this. > > First of all, please consider this email as an official cancellation > request of the early allocation request that we made (i.e. please > close this without doing the early allocation of the port). > > Second, I realize that this premature early allocation request > resulted in you to spend unnecessary time/effort. I am deeply sorry > about that. > > Regards, > Nobo > > > -----Original Message----- > > From: Nobo Akiya (nobo) > > Sent: Saturday, August 02, 2014 10:06 AM > > To: 'iana-prot-param@iana.org'; adrian@olddog.co.uk; draft-ietf-bfd- > > seamless-base@tools.ietf.org > > Cc: Jeffrey Haas (jhaas@pfrc.org) > > Subject: RE: [IANA #772997] Early allocation of User Port for draft- > ietf-bfd- > > seamless-base > > > > Hello Adrian, > > > > We are in a pickle, and need your input first. > > > > Here's where we are: > > > > - There is a consensus to do early allocation of UDP port for S-BFD, > as > > implementations are underway. > > - Port description was originally in draft-ietf-bfd-seamless-base. > > - WG consensus was that UDP procedures should be described in the > > companion document: draft-akiya-bfd-seamless-ip. > > - UDP procedures were moved from draft-ietf-bfd-seamless-base to > draft- > > akiya-bfd-seamless-ip (published on August 1st). > > - Authors of draft-akiya-bfd-seamless-ip will be requesting WG > adoption > > poll in a week or two. > > > > Given above, it would be beneficial to still continue with early > IANA > > allocation of the S-BFD UDP port. > > > > However, reference document, technically, is an individual document. > > > > I believe we have 3 options. > > 1) Do early IANA allocation with reference document as draft-ietf- > bfd- > > seamless-base (this was the correct document when early IANA > allocation > > was originally requested). > > 2) Do early IANA allocation with reference document as draft-akiya- > bfd- > > seamless-ip (correct document, but is an individual document). > > 3) Wait for early IANA allocation until draft-akiya-bfd-seamless-ip > is a WG > > document, but this will delay the allocation by roughly a month. > > > > Will it be possible to go with (1) or (2)? > > > > If we were to go with (1), then the information will be: > > > > Service Name (REQUIRED) > > s-bfd > > Transport Protocol(s) (REQUIRED) > > udp > > Assignee (REQUIRED) > > IESG > > Contact (REQUIRED) > > BFD Chairs > > Description (REQUIRED) > > Seamless Bidirectional Forwarding Detection (S-BFD) > > Reference (REQUIRED) > > draft-ietf-bfd-seamless-base > > Port Number (OPTIONAL) > > TBD1 (Requesting 7784) > > > > If we were to go with (2), then the information will be: > > > > Service Name (REQUIRED) > > s-bfd > > Transport Protocol(s) (REQUIRED) > > udp > > Assignee (REQUIRED) > > IESG > > Contact (REQUIRED) > > BFD Chairs > > Description (REQUIRED) > > Seamless Bidirectional Forwarding Detection (S-BFD) > > Reference (REQUIRED) > > draft-akiya-bfd-seamless-ip > > Port Number (OPTIONAL) > > TBD1 (Requesting 7784) > > > > Amanda, thank you for taking our case. Please wait for input by > Adrian > > before proceeding. > > > > Thanks, > > Nobo > > > > > -----Original Message----- > > > From: Amanda Baber via RT [mailto:iana-prot-param@iana.org] > > > Sent: Friday, August 01, 2014 8:56 PM > > > To: adrian@olddog.co.uk; draft-ietf-bfd-seamless- > base@tools.ietf.org > > > Subject: [IANA #772997] Early allocation of User Port for > > > draft-ietf-bfd- seamless-base > > > > > > Dear Authors, > > > > > > Before we can assign a port number for this document, we need you > to > > > supply the registration data required by RFC6335: > > > > > > Service Name (REQUIRED) > > > Transport Protocol(s) (REQUIRED) > > > Assignee (REQUIRED) > > > Contact (REQUIRED) > > > Description (REQUIRED) > > > Reference (REQUIRED) > > > Port Number (OPTIONAL) > > > Service Code (REQUIRED for DCCP only) > > > Known Unauthorized Uses (OPTIONAL) > > > Assignment Notes (OPTIONAL) > > > > > > Per Section 8.1.1, since this registration is being made on behalf > of > > > an IETF- stream document, the Assignee would be the IESG, and the > > > Contact should be the IETF Chair. > > > > > > This data also has to be added to the document's IANA > Considerations > > > section, although we can make the assignment before you publish an > > > update. > > > > > > Let us know if you have any questions. > > > > > > thanks, > > > > > > Amanda Baber > > > IANA Request Specialist > > > ICANN > > > > > > On Mon Jul 21 19:00:24 2014, adrian@olddog.co.uk wrote: > > > > Hi, > > > > > > > > The authors of draft-ietf-bfd-seamless-base > > > > (http://www.ietf.org/id/draft-ietf-bfd-seamless-base-01.txt) > have > > > > requested early allocation of a User Port from the "Service Name > and > > > > Transport Protocol Port Number Registry". > > > > > > > > This meets all of the 7120 criteria. > > > > > > > > Please invoke the expert review and make the allocation. > > > > > > > > Thanks, > > > > Adrian > > > > > > > > > > > > > > From nobody Wed Aug 6 13:48:02 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E321A01BD for ; Wed, 6 Aug 2014 13:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44_oBNI9iblk for ; Wed, 6 Aug 2014 13:47:58 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5141A01C6 for ; Wed, 6 Aug 2014 13:47:58 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.129 is permitted sender) identity=mailfrom; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.129; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos; i="5.01,813,1400040000"; d="scan'208,217"; a="12225662" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.129]) by ironport.idirect.net with ESMTP; 06 Aug 2014 16:47:57 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB02.idirect.net ([fe80::1134:c923:6861:3e3e%14]) with mapi id 14.02.0387.000; Wed, 6 Aug 2014 16:47:57 -0400 From: "Snyder, Brian" To: "rtg-bfd@ietf.org" Subject: Status of bfd proxy document from IETF 90. Thread-Topic: Status of bfd proxy document from IETF 90. Thread-Index: Ac+xsf8PfqQ2HjTpRXu7iFAGwNnS3A== Date: Wed, 6 Aug 2014 20:47:56 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF734306803B@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/alternative; boundary="_000_84585478AABBBF4B9DF597FC0F84AF734306803BVAUSMBX03idirec_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AGvshAg_EuInvRjRMbm_NPZWxPA 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, 06 Aug 2014 20:48:01 -0000 --_000_84585478AABBBF4B9DF597FC0F84AF734306803BVAUSMBX03idirec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, I wanted to follow up and report some status of this document that I presen= ted in Toronto. (http://tools.ietf.org/html/draft-snyder-bfd-proxy-connec= tions-monitored-links-00 ) As you may recall, due to time constraints there was not time to field any = questions related to the document. I did also present this same paper to t= he MANET group and it caused quite a bit of discussion there. Probably bec= ause there was another document in the same space as requiring some changes= for satellite market. I believe it was generally considered a pretty nove= l approach to solving the problem and used BFD to solve a new use case that= DLEP wasn't as optimized for. It started a discussion about using BFD "un= derneath" of DLEP as well. It could be a useful way to recognizing/speedin= g up L3 state notification in the radio/router link as well as through othe= r L2 networks. I am planning on studying DLEP further and attempting a pro= of of concept of DLEP in our radio gear as well as continuing with the BFD = proxy approach. As for how it relates specifically to BFD I think the use case described in= #4 in the following document ( http://datatracker.ietf.org/doc/draft-zhang= -bfd-new-use-cases/?include_text=3D1 ) could also be solved via the proxy i= dea put forth in this paper. With all this in mind, the authors current plan is to revise this document = as a generic BFD proxy framework. While we tried to keep it more generic, = we feel the satellite focus as it's currently written will hamper it's viab= ility and interest. With this plan in mind, we would be happy to answer an= y comments that may have been on your mind and/or generally get feedback to= the interest in this approach. Thanks, Brian --_000_84585478AABBBF4B9DF597FC0F84AF734306803BVAUSMBX03idirec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

I wanted to follow up and report some status of t= his document that I presented in Toronto.   (ht= tp://tools.ietf.org/html/draft-snyder-bfd-proxy-connections-monitored-links= -00 )

 

As you may recall, due to time constraints there = was not time to field any questions related to the document.  I did al= so present this same paper to the MANET group and it caused quite a bit of = discussion there.  Probably because there was another document in the same space as requiring some changes for satel= lite market.  I believe it was generally considered a pretty novel app= roach to solving the problem and used BFD to solve a new use case that DLEP= wasn’t as optimized for.  It started a discussion about using BFD “underneath” of DLEP as well.&nbs= p; It could be a useful way to recognizing/speeding up L3 state notificatio= n in the radio/router link as well as through other L2 networks.  I am= planning on studying DLEP further and attempting a proof of concept of DLEP in our radio gear as well as continuing with the BFD pr= oxy approach.

 

As for how it relates specifically to BFD I think= the use case described in #4 in the following document ( http://datatracker.ietf.org/doc/draft-zhang-bfd-new-use-cases/?include_text= =3D1 ) could also be solved via the proxy idea put forth in this paper.=

 

With all this in mind, the authors current plan i= s to revise this document as a generic BFD proxy framework.  While we = tried to keep it more generic, we feel the satellite focus as it’s cu= rrently written will hamper it’s viability and interest.  With this plan in mind, we would be happy to answer any co= mments that may have been on your mind and/or generally get feedback to the= interest in this approach.



Thanks,

Brian

 

--_000_84585478AABBBF4B9DF597FC0F84AF734306803BVAUSMBX03idirec_-- From nobody Thu Aug 7 01:21:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81C1B2995 for ; Thu, 7 Aug 2014 01:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Yu7tubnqsoJs for ; Thu, 7 Aug 2014 01:21:45 -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 DE85C1B2993 for ; Thu, 7 Aug 2014 01:21:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ22753; Thu, 07 Aug 2014 08:21:43 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Aug 2014 09:21:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.78]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 7 Aug 2014 16:21:40 +0800 From: Mingui Zhang To: "Snyder, Brian" , "rtg-bfd@ietf.org" Subject: RE: Status of bfd proxy document from IETF 90. Thread-Topic: Status of bfd proxy document from IETF 90. Thread-Index: Ac+xsf8PfqQ2HjTpRXu7iFAGwNnS3AAYpk/Q Date: Thu, 7 Aug 2014 08:21:39 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E76AAAA8A4@nkgeml512-mbx.china.huawei.com> References: <84585478AABBBF4B9DF597FC0F84AF734306803B@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF734306803B@VAUS-MBX03.idirect.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.175] Content-Type: multipart/alternative; boundary="_000_4552F0907735844E9204A62BBDD325E76AAAA8A4nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aG2iI_fwfubpwggZNDDVHAidvlI 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, 07 Aug 2014 08:21:50 -0000 --_000_4552F0907735844E9204A62BBDD325E76AAAA8A4nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, I think a generic BFD proxy framework document will be helpful. It can cove= r those use cases that can be handled by the proxy method. Requirements and= guidelines can be developed therein. Thanks, Mingui From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder, Brian Sent: Thursday, August 07, 2014 4:48 AM To: rtg-bfd@ietf.org Subject: Status of bfd proxy document from IETF 90. WG, I wanted to follow up and report some status of this document that I presen= ted in Toronto. (http://tools.ietf.org/html/draft-snyder-bfd-proxy-connec= tions-monitored-links-00 ) As you may recall, due to time constraints there was not time to field any = questions related to the document. I did also present this same paper to t= he MANET group and it caused quite a bit of discussion there. Probably bec= ause there was another document in the same space as requiring some changes= for satellite market. I believe it was generally considered a pretty nove= l approach to solving the problem and used BFD to solve a new use case that= DLEP wasn't as optimized for. It started a discussion about using BFD "un= derneath" of DLEP as well. It could be a useful way to recognizing/speedin= g up L3 state notification in the radio/router link as well as through othe= r L2 networks. I am planning on studying DLEP further and attempting a pro= of of concept of DLEP in our radio gear as well as continuing with the BFD = proxy approach. As for how it relates specifically to BFD I think the use case described in= #4 in the following document ( http://datatracker.ietf.org/doc/draft-zhang= -bfd-new-use-cases/?include_text=3D1 ) could also be solved via the proxy i= dea put forth in this paper. With all this in mind, the authors current plan is to revise this document = as a generic BFD proxy framework. While we tried to keep it more generic, = we feel the satellite focus as it's currently written will hamper it's viab= ility and interest. With this plan in mind, we would be happy to answer an= y comments that may have been on your mind and/or generally get feedback to= the interest in this approach. Thanks, Brian --_000_4552F0907735844E9204A62BBDD325E76AAAA8A4nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bria= n,

&n= bsp;

I think a generic BFD proxy framework document will be helpful. It can =
cover those use cases that can be handled by the proxy method. Requirements=
 and guidelines can be developed therein.

&n= bsp;

Thanks,=

Mingui<= o:p>

&n= bsp;

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Snyder, Brian
Sent: Thursday, August 07, 2014 4:48 AM
To: rtg-bfd@ietf.org
Subject: Status of bfd proxy document from IETF 90.

 

WG,

I wanted to follow up and re= port some status of this document that I presented in Toronto.   = (http://tools.ietf.org/html/draft-snyder-bfd-proxy-connec= tions-monitored-links-00 )

 

As you may recall, due to ti= me constraints there was not time to field any questions related to the doc= ument.  I did also present this same paper to the MANET group and it c= aused quite a bit of discussion there.  Probably because there was another document in the same space as requiring some cha= nges for satellite market.  I believe it was generally considered a pr= etty novel approach to solving the problem and used BFD to solve a new use = case that DLEP wasn’t as optimized for.  It started a discussion about using BFD “underneath” of DLEP a= s well.  It could be a useful way to recognizing/speeding up L3 state = notification in the radio/router link as well as through other L2 networks.=   I am planning on studying DLEP further and attempting a proof of concept of DLEP in our radio gear as well as continuing with th= e BFD proxy approach.

 

As for how it relates specif= ically to BFD I think the use case described in #4 in the following documen= t ( http://datatracker.ietf.org/doc/draft-zhang-bfd-new-use-cases/?include_text= =3D1 ) could also be solved via the proxy idea put forth in this paper.=

 

With all this in mind, the a= uthors current plan is to revise this document as a generic BFD proxy frame= work.  While we tried to keep it more generic, we feel the satellite f= ocus as it’s currently written will hamper it’s viability and interest.  With this plan in mind, we would = be happy to answer any comments that may have been on your mind and/or gene= rally get feedback to the interest in this approach.



Thanks,

Brian

 

--_000_4552F0907735844E9204A62BBDD325E76AAAA8A4nkgeml512mbxchi_-- From nobody Fri Aug 8 12:02:16 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387501A0016 for ; Fri, 8 Aug 2014 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 2l2-_5sSGpRy for ; Fri, 8 Aug 2014 12:02:13 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCB31A0109 for ; Fri, 8 Aug 2014 12:02:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78J2AJq005357; Fri, 8 Aug 2014 20:02:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s78J29Qv005349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 20:02:09 +0100 From: "Adrian Farrel" To: Subject: AD review of draft-ietf-bfd-intervals Date: Fri, 8 Aug 2014 20:02:07 +0100 Message-ID: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+zOz3k9ZAze7soSd2QofDV+HM0cQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.002 X-TM-AS-Result: No--12.020-10.0-31-10 X-imss-scan-details: No--12.020-10.0-31-10 X-TMASE-MatchedRID: oqy2XPQsRGTEZ8p2vbEqHZNd1m5RlE+K1kqyrcMalqW638ZUY6gSd0j8 AtVpDcmg23e6ga05Tac3HexY7VSIcVuK9PbhoyLtlwzEyYDh4ndZbM2hfH4YXukqWnetZv3r/Ye Zxxk7KcjlYBLfdrVGsnCTUr5Stccgy0VPpWGlsb5buDP8ZuCmXpE+3DCX3uibmoS7AWklQp0Rq8 VDNou3Lo/1zKj4Efplcinqd2E69r9211r83OOoVvSG/+sPtZVkOL9BEHibhsjaNaTWtewY9Dl32 fTh8s1mo5+SKLVRg5XF+fjFK01nugosIIcjztMu1QWGBM/v9tYHsnt0u0M2ADDJ9a3KikGoY4sa AwRtkCJ+24QgLio3vqE3ZvSlixPb7YGIARphfZ6jFYHTfcPkwr3T39qxnreJ2qqh/6B8PpHCb9Z jqJMAXBdki+J3a14B2/JAtGgo7/6WV6M+N/Jptev8QGaI25e3L34I8IpvQcJDCjK5zgZdxwOiVF pF7nSJUmRjgBcG9aE24JZWpgUA409PXwvU8eutngIgpj8eDcC063Wh9WVqghziNLWewPgd+gtHj 7OwNO0YzpbdT4ued8QoHnYJyi0bb4I3GSUXQB0Y1jZNRmQ6rZcsAejMUCLl Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6AeQG9f67KFYvs5REDoySDlyZGM Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:02:15 -0000 Hello, If you considered that Jeff helped find the line between "exact" and "pedantic" then you may rest assured that I have crossed it (in one direction or the other). This is my usual AD review of your document to advance the publication request. It is a short document (Hooray!) and is perfectly clear. Nevertheless, I have picked a few holes for style and clarity. Please feel free to dispute these points with me if you like. Until then, or until I see a revised version of the document, I have placed the I-D in "Revised I-D Needed" state. Thanks for your work, Adrian === It seems to me that the main benefit in this work is to improve the chances of interoperability between hardware implementations that need to select a hard-wired subset of interval values at build time. There are two points arising from this: - You should recommend that implementations that can do so, should support a superset of the values identified here, and suggest that implementations try to support a considerably more flexible set of values to facilitate operator control of the responsiveness and scalability of BFD. - You should observe that not all implementations of BFD are intended to interoperate. This may be particularly true for certain hardware implementations (e.g., BFD for MPLS-TP and BFD for Ethernet LAG). This *might* have an impact on whether every implementation has to support every value in the set. Whether or not is does have an impact could usefully be commented in the document. --- The Abstract might benefit from one line saying what an "interval value" is. Something like, "BFD requires that messages are transmitted at well-known intervals and provides a way to negotiate the interval used by BFD peers." --- I only see one use of RFC 2119 language. Section 3 has In technical terms the requirement is as follows: a BFD implementation SHOULD support all values in the set of Common interval values which are equal to or larger than the fastest, i.e. lowest, interval the particular BFD implementation supports. Maybe you don't actually need uppercase "SHOULD" and then you could drop the "Requirements Language" paragraph. --- Section 1 number of BFD sessions in increasing. s/in/is/ --- Section 3 This document is not adding new requirements with respect to how exact a timer value must be implemented. I think you don't mean "the precision with which a timer value must be implemented", but if you do, please change to say that. Otherwise, I suggest This document is not adding new requirements with respect to how a timer value must be implemented. --- Section 3 How is the "Common interval set" used exactly? In the example above, vendor "A" has a fastest interval of 10msec and thus would be required to support all intervals in the common set that are equal or larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, 100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus would need to support 20msec, 50msec, 100msec and 1sec. As long as this requirement is met for the common set of values, then both vendor "A" and "B" are free to support additional values outside of the common set. I disagree! In the example you have used, implementation "A" will try to set up the session with 10msec and implementation "B" will support that interval because it is in the set. I think that, to give the example meaning you need to have "A" initially suggest a value that is not in the set, for example 15msec. Then "B" will respond with 20msec and that value will be chosen because it is in the set. --- Section 5 This is rally to check with you. Can influencing the interval value used by a BFD session be used as part of an attack? For example, can forcing the transmission time to be slower make it harder to detect naughtiness? And can forcing the interval to be faster help cause DoS? If so, does limiting the set of available values make attacks easier? From nobody Fri Aug 8 17:39:26 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9596B1A02C2 for ; Fri, 8 Aug 2014 17:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.502 X-Spam-Level: X-Spam-Status: No, score=-114.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uocyEGrxTmgX for ; Fri, 8 Aug 2014 17:39:24 -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 1A2FA1A02C1 for ; Fri, 8 Aug 2014 17:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1860; q=dns/txt; s=iport; t=1407544764; x=1408754364; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2BT25T8Oy0UGezO+wkP8X3N1cBR6fPme/qDInoO9zSo=; b=I70zxF7WhcMozt2nzVAlRZWBLkW3PaQxJFwLy4zxXulIe0pSTKf+oPBZ xZkU5PtBlPZP4kh7qh8COL2P6F4i0RCTQJAVl84gk17VK/skUtSe84MLx kWgvOvHbhZEMSbIgTS1hAAPR2t2pV398MzYRkuNFuJZbB8dy0/h8b05+s Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEps5VOtJV2Y/2dsb2JhbABagmojgS2Cc9FJARl2FneEBAEBAwEjEUUFCwIBCBoCBiACAgIwFRABAQQBDQ2IMggBsBKVdBeBLI1vMQeCeTaBHAEEjwOCE6ALg1eBcQc7 X-IronPort-AV: E=Sophos;i="5.01,828,1400025600"; d="scan'208";a="67785796" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 09 Aug 2014 00:39:24 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s790dN2W028637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 00:39:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 8 Aug 2014 19:39:23 -0500 From: "Nobo Akiya (nobo)" To: Pablo Frank , Marc Binderberger Subject: RE: S-BFD open items, seeking comments Thread-Topic: S-BFD open items, seeking comments Thread-Index: Ac+nQ1JkI7xBGFdISdiCs4MsO7iGlAA+ApiAAGJabBAAVf/wgAB51Z+AAZk+MnA= Date: Sat, 9 Aug 2014 00:39:21 +0000 Message-ID: References: <20140728230349548813.048d9b16@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.248.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/eIWShxQekW9zfRQC6y6fB0k4e8c Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 00:39:25 -0000 SGkgUGFibG8sDQoNCj4gQnkgdGhlIHdheSwgbXkgcmVhZGluZyBvZiB0aGUgY3VycmVudCAob3B0 aW9uIDEpIGRyYWZ0IGlzIHRoYXQgdGhlIHJlZmxlY3Rvcg0KPiB3b3VsZCByZXNwb25kIHRvIGFu IGFkbWluLWRvd24gcGFja2V0IHdpdGggYW4gVVAgc3RhdGUuIMKgSSdtIG5vdCBzdXJlIGlmDQo+ IHRoYXQgd2FzIGF1dGhvcnMnIGludGVudC4uLj8gwqBDb3VsZCB1c2Ugc29tZSBjbGFyaWZ5aW5n IHRleHQuDQoNCkNvcnJlY3QsIHRoYXQncyB3aGF0IF93aWxsXyBoYXBwZW4gKG5vIHNwZWNpYWwg Y2FzaW5nIHRoYXQgc2NlbmFyaW8pLiBBbHRob3VnaCBpZiBTQkZESW5pdGlhdG9yIHdhbnRzIHRv IHRyYW5zaXRpb24gdG8gQWRtaW5Eb3duIHN0YXRlLCB0aGVuIHRoZSBTQkZESW5pdGlhdG9yIGNh biBqdXN0IHN0b3Agc2VuZGluZyBTLUJGRCBwYWNrZXRzIGltbWVkaWF0ZWx5LiBUaGVyZSdzIHJl YWxseSBubyBuZWVkIGZvciBTQkZESW5pdGlhdG9yIHRvIHNlbmQgUy1CRkQgcGFja2V0cyB0byAi Y29tbXVuaWNhdGUiIGl0cyBzdGF0ZSBjaGFuZ2VzIHRvIEFkbWluRG93bi4gSWYgeW91IHRoaW5r IGNsYXJpZmljYXRpb24gdGV4dCB3aWxsIGJlIGJlbmVmaWNpYWwsIHdlJ2xsIGJlIGhhcHB5IHRv IGNvbnNpZGVyIHRoYXQuDQoNCj4gUEY+PiDCoEkndmUgZ290IGEgaGFsZi1iYWtlZCBpZGVhIGFi b3V0IHJlZmxlY3RvciBzZXNzaW9ucyB0aGF0IGFyZSBhc3NvY2lhdGVkDQo+IHdpdGggcG9pbnQt dG8tcG9pbnQgbGlua3MgKGUuZy4gYSBiaS1kaXJlY3Rpb25hbCBMU1ApIGNvdWxkIHRyYW5zaXRp b24gaW50byBhbg0KPiBpbml0aWF0b3IgdGhlbXNlbHZlcy4gwqBUaGUgaWRlYSBpcyB0aGF0IGFu IFMtQkZEIHNlc3Npb24gKHVuZGVyIHNwZWNpZmljDQo+IGNpcmN1bXN0YW5jZXMpIGNvdWxkIGJh c2ljYWxseSBtb3JwaCBpbnRvIGEgcmVndWxhciBCRkQgc2Vzc2lvbiAodGhlIG1haW4NCj4gdXNl LWNhc2UgaXMgZmFzdCBicmluZy11cCBvZiBwcm90ZWN0ZWQgTFNQcykuIMKgSSdtIHN0aWxsIHNr ZXRjaGluZyB0aGUgaWRlYSBvdXQNCj4gb24gcGFwZXIgdGhvdWdoLiDCoEkgaGF2ZW4ndCBjb252 aW5jZWQgbXlzZWxmIGl0IHdvcmtzIHlldC4uLiA6LSkNCg0KU291bmRzIGludGVyZXN0aW5nLCBh bmQgSSBhZ3JlZSB0aGF0IGZhc3QgYnJpbmctdXAgaXMgb25lIG9mIHRoZSBzdHJlbmd0aCBvZiBT LUJGRCB0aHVzIHVzaW5nIFMtQkZEIGluaXRpYWxseSBldmVuIHdoZW4gY2xhc3NpY2FsIEJGRCBp cyBkZXNpcmVkIG9uIGFuIExTUCBieSBvcGVyYXRvcnMgbWF5IGJlIGJlbmVmaWNpYWwuIExvb2sg Zm9yd2FyZCB0byBoZWFyaW5nIG1vcmUuDQoNClRoYW5rcyENCg0KLU5vYm8NCg0K From nobody Mon Aug 11 10:27:40 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A081D1A0487 for ; Mon, 11 Aug 2014 10:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.464 X-Spam-Level: X-Spam-Status: No, score=0.464 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 hqfSTYgQqYyU for ; Mon, 11 Aug 2014 10:27:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C29D61A0037 for ; Mon, 11 Aug 2014 10:27:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 64740C25D; Mon, 11 Aug 2014 13:27:36 -0400 (EDT) Date: Mon, 11 Aug 2014 13:27:36 -0400 From: Jeffrey Haas To: Adrian Farrel Subject: Re: AD review of draft-ietf-bfd-intervals Message-ID: <20140811172736.GC12728@pfrc> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/CsoyBjxtXgz5vDdnPEMCXTrRydI Cc: rtg-bfd@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 17:27:38 -0000 Adrian, On Fri, Aug 08, 2014 at 08:02:07PM +0100, Adrian Farrel wrote: > It seems to me that the main benefit in this work is to improve the > chances of interoperability between hardware implementations that need > to select a hard-wired subset of interval values at build time. A non-obvious property is that it additionally helps software implementations as well. BFD scaling tends to be a matter of both sessions and the relevant timers. By providing a common timer set, it may be possible to supplement the logic in software implementations to better multiplex sessions. Such points were left out of the document simply because it's endlessly easy to justify common intervals. :-) > There > are two points arising from this: > > - You should recommend that implementations that can do so, should > support a superset of the values identified here, and suggest that > implementations try to support a considerably more flexible set of > values to facilitate operator control of the responsiveness and > scalability of BFD. I'm unclear on the benefit of such text. This document roughly says "here's the minimum". You're essentially saying "but do better if you can!" That seems implied. > - You should observe that not all implementations of BFD are intended > to interoperate. This may be particularly true for certain hardware > implementations (e.g., BFD for MPLS-TP and BFD for Ethernet LAG). > This *might* have an impact on whether every implementation has to > support every value in the set. Whether or not is does have an impact > could usefully be commented in the document. I'm also unclear on why this would be the case. BFD "interoperates" perfectly fine as long as you can configure at least one interval set both sides are willing to respect. If you observation is that a given pair of implementations must have at least one set of intervals they're willing to use - again that seems implied. > Section 5 > > This is rally to check with you. Can influencing the interval value used > by a BFD session be used as part of an attack? For example, can forcing > the transmission time to be slower make it harder to detect naughtiness? > And can forcing the interval to be faster help cause DoS? If so, does > limiting the set of available values make attacks easier? BFD is incredibly good at being used to say "this has gone down" and is often implemented just with that edge transition in mind. In order to maliciously manipulate the timers in question, it would be necessary to have a full man-in-the-middle that is capable of actively attacking at BFD speeds. If you're to that point, you should have turned on authentication in the first place. In such an event, you're already vulnerable to the slow-down attack courtesy of cryptography. I believe the case is academic and useful for beer discussion. :-) Now... S-BFD may be a different matter. -- Jeff From nobody Tue Aug 12 00:34:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1441A0775 for ; Tue, 12 Aug 2014 00:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 UzXinGsIFAbt for ; Tue, 12 Aug 2014 00:34:12 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D837C1A0771 for ; Tue, 12 Aug 2014 00:34:11 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 43A672AA0F; Tue, 12 Aug 2014 07:34:06 +0000 (GMT) Date: Tue, 12 Aug 2014 00:34:39 -0700 From: Marc Binderberger To: adrian@olddog.co.uk Message-ID: <20140812003439717481.408f4350@sniff.de> In-Reply-To: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> Subject: Re: AD review of draft-ietf-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/KX8iVWNbxXI-FoxVCnmHJz8L9eA Cc: rtg-bfd@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org, "Marc Binderberger \(mbinderb\)" 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, 12 Aug 2014 07:34:14 -0000 Hello Adrian, I see Jeff has already replied, which reminds me I should focus on this email thread as well. > It seems to me that the main benefit in this work is to improve the > chances of interoperability between hardware implementations that need > to select a hard-wired subset of interval values at build time. There > are two points arising from this: correct. > - You should recommend that implementations that can do so, should > support a superset of the values identified here, and suggest that > implementations try to support a considerably more flexible set of > values to facilitate operator control of the responsiveness and > scalability of BFD. we actually mention 2 times - in the abstract and in section 3 that implementations are not restricted to the Common Interval set and can add more supported intervals. I don't think I have to encourage vendors here. If "more is better" depends on the scenario, e.g. for last-mile-copper-to-IP devices to residential customers the 100msec + 1sec may be all that is needed. Core/Access router vendors will likely support more values than we list in the draft, to offer flexibility for the customers. > - You should observe that not all implementations of BFD are intended > to interoperate. This may be particularly true for certain hardware > implementations (e.g., BFD for MPLS-TP and BFD for Ethernet LAG). > This *might* have an impact on whether every implementation has to > support every value in the set. Whether or not is does have an impact > could usefully be commented in the document. you lost me here. You don't mean that BFD for MPLS-TP does not talk to BFD for LAG? I would think it is obvious that trying this combination is outside what any document talks about. Also the document is informational and we talk about a "SHOULD" when it comes to support the Common Interval set. Plus we have the rule that every implementation can defines it's own fastest interval and everything in the Common set that is faster does not need to be supported. So the fact that you can implement only a subset is "clear" I think. Our interest is to encourage implementors to go with the full set instead of "cherry picking", thus we haven't been more explicit. But I'm still not sure I understand your comment, so my reply may be completely "off" :-) > The Abstract might benefit from one line saying what an "interval value" > is. Something like, > > "BFD requires that messages are transmitted at well-known intervals > and provides a way to negotiate the interval used by BFD peers." Ah I see, we jumped immediately in the middle of the topic. Good idea, let me add this. > I only see one use of RFC 2119 language. Section 3 has > > In technical terms the requirement is as follows: a BFD > implementation SHOULD support all values in the set of Common > interval values which are equal to or larger than the fastest, i.e. > lowest, interval the particular BFD implementation supports. > > Maybe you don't actually need uppercase "SHOULD" and then you could > drop the "Requirements Language" paragraph. oh, indeed. Hmm, I think this SHOULD remained as this is the core of the draft: we encourage implementors to implement the full set of Common values (*), otherwise the effect of this draft would be reduced as the chances to find an agree-able interval are reduced. Thus the "official" language. I personally would like to keep it. (*: full set from the fastest interval the implementation suports) > number of BFD sessions in increasing. > > s/in/is/ sorry for the mistake and Merci! Fixed. > This document is not adding new requirements with respect to how > exact a timer value must be implemented. > > I think you don't mean "the precision with which a timer value must be > implemented", but if you do, please change to say that. Otherwise, I > suggest Ah yes, "precision" is a better fit for what we want to say. Thanks, correcting it. > Section 3 > > How is the "Common interval set" used exactly? In the example above, > vendor "A" has a fastest interval of 10msec and thus would be > required to support all intervals in the common set that are equal or > larger than 10msec, i.e. it would support 10msec, 20msec, 50msec, > 100msec, 1sec. Vendor "B" has a fastest interval of 20msec and thus > would need to support 20msec, 50msec, 100msec and 1sec. As long as > this requirement is met for the common set of values, then both > vendor "A" and "B" are free to support additional values outside of > the common set. > > I disagree! In the example you have used, implementation "A" will try to > set up the session with 10msec and implementation "B" will support that > interval because it is in the set. I disagree :-) Section 3 says this In technical terms the requirement is as follows: a BFD implementation SHOULD support all values in the set of Common interval values which are equal to or larger than the fastest, i.e. lowest, interval the particular BFD implementation supports. In other words we allow for an implementor to define the fastest interval that the platform should support and ask to implement all Common Interval values that are equal/larger than this fastest value. It comes from the original draft when we wanted to define mandatory requirements. We have soften the draft since then but it still serves the purpose to define how to deviate from the Common set: you may drop the very fast values. Not every hardware implementation will support 3.3msec and 3.3/10/20 msec is hard or even impossible for software-based BFD. > This is rally to check with you. Can influencing the interval value used > by a BFD session be used as part of an attack? For example, can forcing > the transmission time to be slower make it harder to detect naughtiness? > And can forcing the interval to be faster help cause DoS? If so, does > limiting the set of available values make attacks easier? okay, the sentence in section 5 is short I admit :-) But this draft is not introducing any new mechanism how to negotiate the interval; it only shows how the mechanism of RFC5880 can be used to build a negotiation-sequence. We do not force faster intervals, the adjustment is to slower intervals when the negotiation fails. There is a risk - although I don't see an attack vector - with the fact that the final interval may be slower than the initial request, i.e.you don't get the service requested. What the draft contributes is it helps to find a common interval and sessions go up where otherwise they may stay down. Regards, Marc From nobody Tue Aug 12 00:42:44 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954AA1A0771 for ; Tue, 12 Aug 2014 00:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 e7Gv9B8RFrsd for ; Tue, 12 Aug 2014 00:42:42 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C87CE1A076E for ; Tue, 12 Aug 2014 00:42:41 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id A1CDE2AA0F; Tue, 12 Aug 2014 07:42:38 +0000 (GMT) Date: Tue, 12 Aug 2014 00:43:11 -0700 From: Marc Binderberger To: Jeffrey Haas Message-ID: <20140812004311371053.b8e07806@sniff.de> In-Reply-To: <20140811172736.GC12728@pfrc> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140811172736.GC12728@pfrc> Subject: Re: AD review of draft-ietf-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GkGGSKO4xi8EluMq5Rl0cL7my3M Cc: rtg-bfd@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 07:42:43 -0000 Hello Jeff, > I believe the case is academic and useful for beer discussion. :-) and fortunately US and UK are in agreement that the "correct" metric is a pint ;-) > Now... S-BFD may be a different matter. What potential problem do you see? Actually for S-BFD I would have thought we don't have the interval problem as the reflector just reflects. It will introduce some minimum interval it can handle but otherwise all it does is introducing jitter. There are no timers on the reflector. And for the initiator, well, it's the same node, so it should support the same intervals for Rx detect timer that it supports for Tx (?). Regards, Marc On Mon, 11 Aug 2014 13:27:36 -0400, Jeffrey Haas wrote: > Adrian, > > On Fri, Aug 08, 2014 at 08:02:07PM +0100, Adrian Farrel wrote: >> It seems to me that the main benefit in this work is to improve the >> chances of interoperability between hardware implementations that need >> to select a hard-wired subset of interval values at build time. > > A non-obvious property is that it additionally helps software > implementations as well. BFD scaling tends to be a matter of both sessions > and the relevant timers. By providing a common timer set, it may be > possible to supplement the logic in software implementations to better > multiplex sessions. > > Such points were left out of the document simply because it's endlessly easy > to justify common intervals. :-) > >> There >> are two points arising from this: >> >> - You should recommend that implementations that can do so, should >> support a superset of the values identified here, and suggest that >> implementations try to support a considerably more flexible set of >> values to facilitate operator control of the responsiveness and >> scalability of BFD. > > I'm unclear on the benefit of such text. This document roughly says "here's > the minimum". You're essentially saying "but do better if you can!" That > seems implied. > >> - You should observe that not all implementations of BFD are intended >> to interoperate. This may be particularly true for certain hardware >> implementations (e.g., BFD for MPLS-TP and BFD for Ethernet LAG). >> This *might* have an impact on whether every implementation has to >> support every value in the set. Whether or not is does have an impact >> could usefully be commented in the document. > > I'm also unclear on why this would be the case. BFD "interoperates" > perfectly fine as long as you can configure at least one interval set both > sides are willing to respect. If you observation is that a given pair of > implementations must have at least one set of intervals they're willing to > use - again that seems implied. > >> Section 5 >> >> This is rally to check with you. Can influencing the interval value used >> by a BFD session be used as part of an attack? For example, can forcing >> the transmission time to be slower make it harder to detect naughtiness? >> And can forcing the interval to be faster help cause DoS? If so, does >> limiting the set of available values make attacks easier? > > BFD is incredibly good at being used to say "this has gone down" and is > often implemented just with that edge transition in mind. In order to > maliciously manipulate the timers in question, it would be necessary to have > a full man-in-the-middle that is capable of actively attacking at BFD > speeds. If you're to that point, you should have turned on authentication > in the first place. In such an event, you're already vulnerable to the > slow-down attack courtesy of cryptography. > > I believe the case is academic and useful for beer discussion. :-) > > Now... S-BFD may be a different matter. > > -- Jeff > From nobody Tue Aug 12 08:44:19 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE021A0990 for ; Tue, 12 Aug 2014 08:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 dPVMLFKcdESJ for ; Tue, 12 Aug 2014 08:44:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AA1A098A for ; Tue, 12 Aug 2014 08:44:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 42B72C2AC; Tue, 12 Aug 2014 11:44:16 -0400 (EDT) Date: Tue, 12 Aug 2014 11:44:16 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: AD review of draft-ietf-bfd-intervals Message-ID: <20140812154416.GJ12728@pfrc> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140811172736.GC12728@pfrc> <20140812004311371053.b8e07806@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140812004311371053.b8e07806@sniff.de> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/3tcHWjox-GVdDLIdIpD3LU6N1Dg Cc: rtg-bfd@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:44:17 -0000 Marc, On Tue, Aug 12, 2014 at 12:43:11AM -0700, Marc Binderberger wrote: > > Now... S-BFD may be a different matter. > > What potential problem do you see? Actually for S-BFD I would have thought > we don't have the interval problem as the reflector just reflects. It will > introduce some minimum interval it can handle but otherwise all it does is > introducing jitter. There are no timers on the reflector. > > And for the initiator, well, it's the same node, so it should support the > same intervals for Rx detect timer that it supports for Tx (?). The distinction has less to do with the intervals (S-BFD has DoS-like security considerations that are still highest on my list of concerns) than it does with expected use case. In regular BFD, we're often most interested in hearing that the session has gone down. It's partially why the slower negotiation isn't that big a deal. In S-BFD, a big portion of the use case is the *up* transition. Doing a connectivity check prior to using a negotiated segment routed path, for example. In such cases, attacks that slow down the negotiated session, especially given that they are much more likely to be multi-hop, are far more interesting and a bit less academic. -- Jeff From nobody Tue Aug 12 09:57:52 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14061A0354 for ; Tue, 12 Aug 2014 09:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7BcuIHEwGhH for ; Tue, 12 Aug 2014 09:57:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD271A034A for ; Tue, 12 Aug 2014 09:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1786; q=dns/txt; s=iport; t=1407862658; x=1409072258; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gaTwX4MhP+76OjZnoRVsfu3QTLCpcSYh/ysJFLSSuwE=; b=D51iI78URePYIbs9yNnXWMmhNBI6bCDywy6zTHBwmb8uXZr/xhRti0ny jvBsXXoPFEMFGwcOxg/j4AR+Hie7JCOutA1WsZTx527NXFuOnz0P71axM LIcBhVs2A+pDsFqSdzB4H8fU6jGjUpLYXBDbaKafIHX8GBy81Yboz6ULm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIJG6lOtJA2G/2dsb2JhbABagmojgS3UdAGBEhZ3hAQBAQMBOj8QAgEIIhQQMiUBAQQBDQ2IMggBxRsXjxsxB4MvgR0BBI8KghOgGoNcgjQ X-IronPort-AV: E=Sophos;i="5.01,850,1400025600"; d="scan'208";a="346928505" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2014 16:57:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7CGvbpI001340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 16:57:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 11:57:37 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger , "adrian@olddog.co.uk" Subject: RE: AD review of draft-ietf-bfd-intervals Thread-Topic: AD review of draft-ietf-bfd-intervals Thread-Index: Ac+zOz3k9ZAze7soSd2QofDV+HM0cQC7oqSAAAi4xFA= Date: Tue, 12 Aug 2014 16:57:36 +0000 Message-ID: References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140812003439717481.408f4350@sniff.de> In-Reply-To: <20140812003439717481.408f4350@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0FRUd9fxzdC4yulC6T2VdSDjFQI Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-intervals.all@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 12 Aug 2014 16:57:46 -0000 Hi Marc, Adrian, > > This is rally to check with you. Can influencing the interval value use= d > > by a BFD session be used as part of an attack? For example, can forcing > > the transmission time to be slower make it harder to detect naughtiness= ? > > And can forcing the interval to be faster help cause DoS? If so, does > > limiting the set of available values make attacks easier? >=20 > okay, the sentence in section 5 is short I admit :-) But this draft is no= t > introducing any new mechanism how to negotiate the interval; it only > shows > how the mechanism of RFC5880 can be used to build a negotiation- > sequence. > We do not force faster intervals, the adjustment is to slower intervals w= hen > the negotiation fails. > There is a risk - although I don't see an attack vector - with the fact t= hat > the final interval may be slower than the initial request, i.e.you don't = get > the service requested. What the draft contributes is it helps to find a > common interval and sessions go up where otherwise they may stay down. I've spent some time thinking about this, but my conclusion is still the sa= me: this document does not introduce any new security concerns. Attackers k= nowing or not knowing the common intervals won't result in any additional s= ecurity concerns to devices implementing the common intervals. Perhaps we c= an expand the Security Considerations section a bit to make it more obvious= on what we mean. This document does not introduce any additional security concerns. The security considerations described in the BFD documents, [RFC5880] and others, apply to devices implementing the BFD protocol, regardless of whether or not the common interval set is implemented. Thanks! -Nobo From nobody Tue Aug 12 10:43:49 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CBB1A0456 for ; Tue, 12 Aug 2014 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh8wvgcMhAG0 for ; Tue, 12 Aug 2014 10:43:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0373D1A03B9 for ; Tue, 12 Aug 2014 10:43:44 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-be-53e9fbdde5e5 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.FB.25146.DDBF9E35; Tue, 12 Aug 2014 13:34:53 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Tue, 12 Aug 2014 13:43:36 -0400 From: Gregory Mirsky To: Jeffrey Haas , Marc Binderberger Subject: RE: AD review of draft-ietf-bfd-intervals Thread-Topic: AD review of draft-ietf-bfd-intervals Thread-Index: Ac+zOz3k9ZAze7soSd2QofDV+HM0cQCb9PsAAB3hg4AAEM04AAAEdlfQ Date: Tue, 12 Aug 2014 17:43:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B7FD77F@eusaamb103.ericsson.se> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140811172736.GC12728@pfrc> <20140812004311371053.b8e07806@sniff.de> <20140812154416.GJ12728@pfrc> In-Reply-To: <20140812154416.GJ12728@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B7FD77Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPrO7d3y+DDXrW6Vr86LnBbHH3xS9G i/0H37JazL7yn9ni859tjA6sHkuW/GTyWLF5JaPH5d6trB6tq7tZPL5c/swWwBrFZZOSmpNZ llqkb5fAlXGvr5et4JBuxZxjq1gbGL+odjFyckgImEg0LOhhgrDFJC7cW8/WxcjFISRwlFHi 0/kvTBDOckaJU8vuMoJUsQkYSbzY2MMOYosIuEh8/rqJHaSIWWA9o8TnG5PBRgkDFXVu3sIK UWQscevybagGN4muSwvBalgEVCUeXGhhAbF5BXwlbv7sglq9mFHi178nYEWcAloS96f2s4HY jED3fT+1BizOLCAucevJfKi7BSSW7DnPDGGLSrx8/I8VwlaU2Nc/nR2iPl/iYMsrVohlghIn Zz5hmcAoOgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctON DDcxAuPymASb4w7GBZ8sDzEKcDAq8fAuePoyWIg1say4MvcQozQHi5I4r2b1vGAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjHqM7askV20S9nqssFV7/TlZ9ZZ30zb+f88qsb57kZfHsvLa Q15bQnW29bawnNygc6MsLH5WeXJou1rHlqN/+sslVtwqvT+zWX+G0a5vPEufm4U4aTo5LzC5 7mByo/d4Q2GZxbslj+oYLUR+fd+8+vr/SwkJXDk64p5Hvt1Q/CD20boickWXghJLcUaioRZz UXEiALMYiWesAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/neph0pk5kwA1zs8yJtzqA10R7kw Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-intervals.all@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 17:43:48 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B7FD77Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jeff, taking a step into pedantic camp (not the first time though). "Doing a connectivity check prior to using a negotiated segment routed path= ..." Two notes: * we will do either continuity check or connectivity verification. I = think that with S-BFd it will be former; * failure on reverse path may give us false negative unless we ensure= S-BFD uses co-routed bi-directional associated OAM channel that, in forwar= ding direction, is co-routed with the negotiated segment routed path. Regards, Greg -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Tuesday, August 12, 2014 8:44 AM To: Marc Binderberger Cc: Jeffrey Haas; Adrian Farrel; rtg-bfd@ietf.org; draft-ietf-bfd-intervals= .all@tools.ietf.org Subject: Re: AD review of draft-ietf-bfd-intervals Marc, On Tue, Aug 12, 2014 at 12:43:11AM -0700, Marc Binderberger wrote: > > Now... S-BFD may be a different matter. > > What potential problem do you see? Actually for S-BFD I would have > thought we don't have the interval problem as the reflector just > reflects. It will introduce some minimum interval it can handle but > otherwise all it does is introducing jitter. There are no timers on the r= eflector. > > And for the initiator, well, it's the same node, so it should support > the same intervals for Rx detect timer that it supports for Tx (?). The distinction has less to do with the intervals (S-BFD has DoS-like secur= ity considerations that are still highest on my list of concerns) than it d= oes with expected use case. In regular BFD, we're often most interested in hearing that the session has= gone down. It's partially why the slower negotiation isn't that big a dea= l. In S-BFD, a big portion of the use case is the *up* transition. Doing a co= nnectivity check prior to using a negotiated segment routed path, for examp= le. In such cases, attacks that slow down the negotiated session, especial= ly given that they are much more likely to be multi-hop, are far more inter= esting and a bit less academic. -- Jeff --_000_7347100B5761DC41A166AC17F22DF1121B7FD77Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
taking a step into pedantic camp (not the first time though).
 
"Doing a connectivity check prior to using a negotiated segment r= outed path ..."
 
Two notes:
  • we will do either continuity check or connectivity verification. I thin= k that with S-BFd it will be former;
  • failure on reverse path may gi= ve us false negative unless we ensure S-BFD uses co-routed bi-directional a= ssociated OAM channel that, in forwarding direction, is co-routed with the = negotiated segment routed path.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@pfrc.org= ]
Sent: Tuesday, August 12, 2014 8:44 AM
To: Marc Binderberger
Cc: Jeffrey Haas; Adrian Farrel; rtg-bfd@ietf.org; draft-ietf-bfd-intervals= .all@tools.ietf.org
Subject: Re: AD review of draft-ietf-bfd-intervals
 
Marc,
 
On Tue, Aug 12, 2014 at 12:43:11AM -0700, Marc Binderberger wrote:
> > Now... S-BFD may be a different matter.
>
> What potential problem do you see?  Actually for S-BFD I wou= ld have
> thought we don't have the interval problem as the reflector just =
> reflects. It will introduce some minimum interval it can handle b= ut
> otherwise all it does is introducing jitter. There are no timers = on the reflector.
>
> And for the initiator, well, it's the same node, so it should sup= port
> the same intervals for Rx detect timer that it supports for Tx (?= ).
 
The distinction has less to do with the intervals (S-BFD has DoS-like = security considerations that are still highest on my list of concerns) than= it does with expected use case.
 
In regular BFD, we're often most interested in hearing that the sessio= n has gone down.  It's partially why the slower negotiation isn't that= big a deal.
 
In S-BFD, a big portion of the use case is the *up* transition.  = Doing a connectivity check prior to using a negotiated segment routed path,= for example.  In such cases, attacks that slow down the negotiated se= ssion, especially given that they are much more likely to be multi-hop, are far more interesting and a bit less academ= ic.
 
-- Jeff
 
 --_000_7347100B5761DC41A166AC17F22DF1121B7FD77Feusaamb103erics_-- From nobody Tue Aug 12 11:07:14 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC02D1A0545 for ; Tue, 12 Aug 2014 11:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 Ke2E7KK0SZRE for ; Tue, 12 Aug 2014 11:07:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A0D881A050E for ; Tue, 12 Aug 2014 11:07:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2F952C4A8; Tue, 12 Aug 2014 14:07:06 -0400 (EDT) Date: Tue, 12 Aug 2014 14:07:06 -0400 From: Jeffrey Haas To: Gregory Mirsky Subject: Re: AD review of draft-ietf-bfd-intervals Message-ID: <20140812180705.GN12728@pfrc> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140811172736.GC12728@pfrc> <20140812004311371053.b8e07806@sniff.de> <20140812154416.GJ12728@pfrc> <7347100B5761DC41A166AC17F22DF1121B7FD77F@eusaamb103.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B7FD77F@eusaamb103.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uYDIpj9IIBJWPyljjEvtDftvMBQ Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-intervals.all@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 18:07:09 -0000 On Tue, Aug 12, 2014 at 05:43:36PM +0000, Gregory Mirsky wrote: > Hi Jeff, > taking a step into pedantic camp (not the first time though). Something we appreciate you for. :-) > "Doing a connectivity check prior to using a negotiated segment routed path ..." > > Two notes: > * we will do either continuity check or connectivity verification. I think that with S-BFd it will be former; Agreed and I carefully chose that wording based on prior discussions. > * failure on reverse path may give us false negative unless we ensure S-BFD uses co-routed bi-directional associated OAM channel that, in forwarding direction, is co-routed with the negotiated segment routed path. The SR use cases are still new enough that while this is true, this may not be the desired check. Presume one wants to validate a service chain where the tested point is the ingress. By allowing the BFD traffic to follow through the chain to the egress, the chain is more fully exercised in the check. Your point, however, is taken. Again, the point is to emphasize that the edge transition of interest is not quite the same as regular BFD use cases and thus the timing "attack" scenarios are potentially different. -- Jeff From nobody Tue Aug 12 22:55:25 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A581A02BB for ; Tue, 12 Aug 2014 22:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 g_-6jrD4JFhQ for ; Tue, 12 Aug 2014 22:55:20 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5791A03A7 for ; Tue, 12 Aug 2014 22:55:20 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3946A2AA0F; Wed, 13 Aug 2014 05:55:15 +0000 (GMT) Date: Tue, 12 Aug 2014 22:55:51 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140812225551488111.db741812@sniff.de> In-Reply-To: <20140801234153.16679.46692.idtracker@ietfa.amsl.com> References: <20140801234153.16679.46692.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-akiya-bfd-seamless-ip-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_4tvyQMbMnhTbfhY0_8eWRHSZX0 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, 13 Aug 2014 05:55:24 -0000 Hello Nobo and BFD experts, looking at your latest version of S-BFD IP - btw, thanks for splitting off the IP/MPLS specifics from the base draft into this draft! - I have a few comments and questions: (1) you mention several times "local IP address" in the draft. Is this enough for IPv6 to be clear regarding routable vs. link-local addresses? Or do you want to allow link-local addresses at all? (most S-BFD is likely multihop?) (2) the UDP destination port for packets from the Reflector to the Initiator ... your draft defines this port to be the copied value of the UDP source port from the Initiator-to-Reflector packet and forces the port to be in the range [49152, 65535]. I hesitate to see this port range as suitable for a relevant service. It's typically "open" for traceroute, DNS replies and such, which means is can be "wide open" with respect to the source IP of incoming packets. If you don't want to define a specific UDP port to receive S-BFD packets on the Initiator then maybe allowing any source port (except from other well-known BFD ports :-) for outgoing Initiator-to-Reflector packets would help the network administrator to write access lists better tailored for S-BFD. (3) In section 7 security considerations you write Implementations MUST ensure that response S-BFD packets generated to the initiator by the SBFDReflector have a reachable target (ex: destination IP address). What does this mean? :-) Seriously, how shall the Reflector know if the destination IP is reachable? Routing table is enough? (even a default route? ;-) (4) New UDP port for S-BFD echo. Sure, can be done but why not simply using 3785/udp for this? I fail to see what is the difference between S-BFD echo and an ordinary echo, considering that both leave many details to the implementor. (5) Nitpicks in the References: bfd-seamless-base is meanwhile version 02. And the author list "Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Networks" has somehow dropped P.K. Santosh ;-) Regards, Marc On Fri, 01 Aug 2014 16:41:53 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Seamless Bidirectional Forwarding Detection > (S-BFD) for IPv4, IPv6 and MPLS > Authors : Nobo Akiya > Carlos Pignataro > Dave Ward > Filename : draft-akiya-bfd-seamless-ip-04.txt > Pages : 7 > Date : 2014-08-01 > > Abstract: > This document defines procedures to use Seamless Bidirectional > Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-akiya-bfd-seamless-ip-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Aug 13 07:09:06 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A5E1A0346 for ; Wed, 13 Aug 2014 07:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHyX92GrQBuz for ; Wed, 13 Aug 2014 07:08:57 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6131A037A for ; Wed, 13 Aug 2014 07:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4188; q=dns/txt; s=iport; t=1407938919; x=1409148519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i6H7aXh5RHUZSF09bHnbz0H5+wQ/Puf0d+ipbhMEeIc=; b=kFpsFfEFmx+cv//tQHgdRa3FwbWw/u5hyYWFkm/a5mGruKksG+F0RrSE Yx0IaYJBR0uQ76GNfMlZEVhehrrcQvklBHpUkWvSNp77eZyAv1dem/W2x bcrSwX4z2lylaO+cDOVAdInfOZxlBxGn1iFLXoCPtUh/rerD2EjN08D47 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFABFx61OtJA2G/2dsb2JhbABagmojgS3RVIMbAYETFneEBAEBAwE6PwULAgEIIhQQMiUCBA4NiDIIAcZCF4l/hRwxB4MvgR0FjwqCE6AagWGBe4I0 X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68864430" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 13 Aug 2014 14:08:38 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7DE8cwO010143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 14:08:38 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 09:08:38 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: I-D Action: draft-akiya-bfd-seamless-ip-04.txt Thread-Topic: I-D Action: draft-akiya-bfd-seamless-ip-04.txt Thread-Index: AQHPtrsuZ2aU+r0eH0STd/N4d8gdYpvOfB9w Date: Wed, 13 Aug 2014 14:08:38 +0000 Message-ID: References: <20140801234153.16679.46692.idtracker@ietfa.amsl.com> <20140812225551488111.db741812@sniff.de> In-Reply-To: <20140812225551488111.db741812@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/uNUPdNU3b_QNvfVw8PUtE-_pkSw 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, 13 Aug 2014 14:09:02 -0000 Hi Marc, > looking at your latest version of S-BFD IP - btw, thanks for splitting of= f the > IP/MPLS specifics from the base draft into this draft! - I have a few > comments and questions: Good to hear a comment implying that document restructure effort was worth = the effort :) And thanks again for further review! > (1) you mention several times "local IP address" in the draft. Is this en= ough > for IPv6 to be clear regarding routable vs. link-local addresses? Or do = you > want to allow link-local addresses at all? (most S-BFD is likely multihop= ?) Good point. It would be a good idea to add some texts to clarify what "loca= l IP address" is. My immediate thought is that we add some texts stating th= at "local IP address" MUST be a routable address by the remote target. We p= robably should not get into what "type" of IPv6 address SBFDInitiator uses = and when. Does that sound reasonable? =20 > (2) the UDP destination port for packets from the Reflector to the Initia= tor ... > your draft defines this port to be the copied value of the UDP source por= t > from the Initiator-to-Reflector packet and forces the port to be in the r= ange > [49152, 65535]. I hesitate to see this port range as suitable for a relev= ant > service. It's typically "open" for traceroute, DNS replies and such, whic= h > means is can be "wide open" with respect to the source IP of incoming > packets. >=20 > If you don't want to define a specific UDP port to receive S-BFD packets = on > the Initiator then maybe allowing any source port (except from other well= - > known BFD ports :-) for outgoing Initiator-to-Reflector packets would hel= p > the network administrator to write access lists better tailored for S-BFD= . Interesting comment. Let me first say that it's probably a good idea to rel= ax the port range as you said. Now whether we keep the port range [49152, 6= 5535] or relax it, I would see identification of S-BFD packets on the initi= ator side to be: - well-known source udp port MUST be matched - initiator assigned destination port MAY matched So the tailoring of access lists won't change. In terms of relaxing the port range, I'm thinking something along the line = of: Initiator can use any UDP port but the port MUST NOT be the well-known S-BF= D port (TBD1). What do you think? > (3) In section 7 security considerations you write >=20 > Implementations MUST ensure that response S-BFD packets generated > to the initiator by the SBFDReflector have a reachable target (ex: > destination IP address). >=20 > What does this mean? :-) > Seriously, how shall the Reflector know if the destination IP is reachabl= e? > Routing table is enough? (even a default route? ;-) It says exactly what you said, but details of how to implement such check i= s up to implementations. > (4) New UDP port for S-BFD echo. Sure, can be done but why not simply > using 3785/udp for this? I fail to see what is the difference between S-= BFD > echo and an ordinary echo, considering that both leave many details to th= e > implementor. I understand where you are coming from. However there may be implementation= s out there which detects BFD echo packets to take them through special pat= h in forwarding. We don't automatically want S-BFD echo packets to get same= treatments applied. Hence authors decided that it's best to make sure the = BFD/S-BFD echo ports are separate. Authors are working through S-BFD-SR doc= ument that describes how to use multi-hop S-BFD echo, we should be able to = roll out the document within next few weeks. > (5) Nitpicks in the References: bfd-seamless-base is meanwhile version 02= . > And the author list "Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and = J. > Networks" has somehow dropped P.K. Santosh ;-) Right, we roll out the two documents same time, thus xml2rfc picked up the = base-01 version (it takes a while for the just submitted document to be tra= nslated xml2rfc). Heh, Name=3D"J. Networks" is a bit funny. Let me see if I= can work with Santosh to clean this up. Thanks! -Nobo From nobody Wed Aug 13 20:14:10 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228B81A0746 for ; Wed, 13 Aug 2014 20:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 fD_wJQPXsrPv for ; Wed, 13 Aug 2014 20:14:04 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9B1A00B2 for ; Wed, 13 Aug 2014 20:14:03 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8B5B92AA0F; Thu, 14 Aug 2014 03:13:59 +0000 (GMT) Date: Wed, 13 Aug 2014 20:14:39 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , "adrian@olddog.co.uk" Message-ID: <20140813201439097437.33605c21@sniff.de> In-Reply-To: References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140812003439717481.408f4350@sniff.de> Subject: RE: AD review of draft-ietf-bfd-intervals MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=Multipart_20140813201439096606 X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/X63Iv3wciSOXiR8vGMKZUzwzgc8 Cc: "rtg-bfd@ietf.org" , "draft-ietf-bfd-intervals.all@tools.ietf.org" , "Marc Binderberger \(mbinderb\)" 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, 14 Aug 2014 03:14:07 -0000 This is a multi-part message in MIME format. --Multipart_20140813201439096606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Adrian, attached the (side-by-side) changes we plan to add to a new draft version, based on your comments. And I hope the replies we have provided are satisfactory for you - otherwise we need another round of discussion ;-) Thanks & Regards, Marc --Multipart_20140813201439096606 Content-Type: application/x-gzip; name=Diff--draft-ietf-bfd-intervals-02.txt--draft-ietf-bfd-intervals-03-B.txt.html.gz Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0=Diff--draft-ietf-bfd-intervals-02.txt--d; filename*1=raft-ietf-bfd-intervals-03-B.txt.html.gz H4sICIPk6lMCA0RpZmYtLWRyYWZ0LWlldGYtYmZkLWludGVydmFscy0wMi50eHQtLWRyYWZ0 LWlldGYtYmZkLWludGVydmFscy0wMy1CLnR4dC5odG1sAOw9/XPjNq6/969g3Zl+zMR27CS7 2Ww2N958bLez2eZt0uvdu3ZuaIm21ciijpTi+G7e//4AkJK/YzrmKr2m25lGtikCBEEQAAHw i+Mvz348vfn71TkbZMOYXf309sP7U1arN5s/7502m2c3Z+xv399cfmCtxi67UTzRURbJhMfN 5vnHGqsNsiw9ajZHo1FjtNeQqt+8+dS8x75a+LJ9rGdTbzbCLKydsC+Ov6zX2TuRCMUzEbLu mKleEEa9HsDabx2Vn7Jh2mw1Q8V7WT0SWa/e7YX1KMmEuuOxru+2G9l9Rq3aD7Taq7+ldvV6 Afp6rDMxPGIfoiS/Z/+Okh5PQhGzvUa7sVvfr/Nh+GKffdVi15dX7Ex0I57Qb3sH9Ta7P3zx T/j13cefmub9Sb8/6SjpMz66PWLNXKtmN0qaffoIrVlndMv2G7uN1sIbONipV8xHosC3+CI+ 5VkU6+8Qi4W3R3Ov28+jSQf0+B0Qt1W+jpNDfwUP4S9jx0ORcYaTWhf/yqO7N7VTCTRMsvrN OBU1FphPb2qZuM+a+PprFgy40iJ7E2lZPzw8eFVv1VhzTW/X2TgWS/sMtC5fz6IsFidnhhBr 5r/O1s79cdN0SH1rxIBlgMEUYPqJsa4Mx/j3P2zIVT9KjthuY1/cv7Yf6yrqD7IjxvNMvmb/ Z97JFGPmneKLsPhiNIgyUdcpD8QRS5V4zXow5HqPD6N4fMSGMpH042t2J1QWBTyu8zjqA9hM praxjv4tEI3DF2L4uoAwKCAsNimwaOghj+OFNtTEfIN0OGJRBiCDOcz+KlTIE77DvhfxnUDM dpiGhVzXQkW9CYxY9DLCo8uD276SeRLWAxlLdcS+Oj8/nzQkwq1oeHFxMWlIXLui4enpVMO4 G8vgdnnDtxdvp0A/0PDi4nDSMEpgdNnyhoczOIpYZGJ5w840jncyCtnKUU/hiCvBiY5xlIiu WgG605ltmEhoaH9VIny9kvgzHPISOQQXRsGLNHevWcrDEOQNNGHt9H4CScRRqiPtgBIyixnq 0sZnZ2fzDPNA61mymDl+oPmrs1cLLPEgLi8WGOOB5rvTqFv2eKD5YWequc54pnfsXxAek8fB AyMvZwPmgu3a3o6btKhRsDetZD8mkWalKu+C5OtKFQr1prYLAljEse2o/IwCyX62bynW7RPs NzUJu3lf1E6Os8EJCNWBeQBJr0TvTa1pN+6/5Cpuv1kjt2uMcH1TM8P6anf30LJdKAKAgyrD USIT8bp28nWcvT5u8pOvk65OX0/g4TbU3BxO7WTNO1OwikGy8mlDJOwWtCEa5ca1OOgpIrfe PAbuajL3DZknM9s0/1N2eyRugF9CFsRc6zc1I2Vq7I5EBeynMq3hC+FMI1j3k2+JkjO/01Jf 8trqvhGjrRF6j7RKRMbOE9jaBWxsoEzdcH3LLqQKBFv372ODdW6jMV87MN+AqiZQ/QyZjLn/ u2ywtxFo1KorVF8oZwL5AlQlgQB6yFBe5/qIvU96Ug25sXYexPw00oG0hoh2IpBPQI8iEMr5 hA9BlKD42d3dJW3fDzlpP66dnN+nkRIwvmPYhZLiV7Of1k5+4EnO1Zi1D3dYe7d1gNsdNDtx YpV3DXYZKX07foDYD2JhlIDayQXoX4RGa8+gsRUWVbEq2/LfuYrATJLJWlb1DcgPq7a9s+qj B7iUtRn7IY+Bs19aZiLO2l/Pqn6wKFi7k/dznbFWeykWVbHq705RWC5X5RDMd/beKlzsOk9T CUZClLC3F2ePWyZuffpZEXsVrYjVCurShVCw3mNZ3xFcwfF7c+CeLY93ujpTPMjWIjbf8I9B sYXlsf85lse1HApcySwaprEYiiQjDU6zIR+zrmCgdGSw/aFPPJNMJrAjaCsCtLgTisdOy2Ip pyNYhb5YAMKyAc/YUGjN+/CJK8HITT+MMoQNvynRz2OuWLl+GE/C6tfKZEwFIvhCLnSDsZ8H IgHyBIOlFNWp4LdIRcGhhcwGQu2sJ95SygH0VMm7KERSsRFMFXSbiL7MIp4B5QZigl2uzXkG opSCpacbpXZYTP6TkA/HD2jiAFKpddSN4igbM9lj2UgyTWNLZAZMSCcY6CaCQfbAtoI3AtqW nFjv0YxdkvB3wF2Io8ppzwX0gFowkobT8LdgznKKqieA09AezzhPOLXuk/bgnD9nzfdmAFIj lEGO/MtCAVNLctCcLmmRIS/MSWfWk4ooSfvMSLhowz7hVEieALGrnc4yuq7t4H4JYg9XgEhC vSACgN2sBHQhjj8oFZIGN0Yzj+EE54adaS3jO1JEBG6uIDaGOL8oN0iOOPkZvACokCDzuwwy bRekvxE6uCeAwgBznZSb42gQgUCFyZcjwtqFKv6gVEgajZwb9SKcyRkeZhymUsBmikt9wFU4 Am213uWoZ8GAYLbfg7SQQruQxh+UCkmDu2uhPwHfzmPeU3JYzCTO3lAqMaW2R04ryReMCsmC p5aEHMg4XOTzwrHhMm7nTp6tBvDJmIzIC5p94Ek/B5NxLZYPvuUDdc/kWwp2curdV3xcY8ZP YDoYTBwGKVdZPTYOZlJWTvRtlKa4ToCrggEemINJDXYg/XgshicsBXKw1g5D8Gz/8LgJXy45 aZ6FoR4Bo13AmAYR/tF11tnzROPgGEl1S7F2VsXUZMPAml92OusiO7wBqVKZnxw6f/v+/Obi O9jZPsrMaglkiDIMNkmN5Q4SULIwwn2hm2duarwXCBWSZHHKQBeYm1vSKQWsJE1WSJArhUZK 2cqFMD7hVEgey9zoOcqYDfkNOegFigegSDbQ007Bv+R4102Lc9Np+9268+dsmC+TP0SnKRbD nkJSajkst/tomJMVpKN7jD3NBvqxgu7RgKrUEME2tv7HPA0x0nwHlNw05gE+AaqyC0aisBHo RjRNrU5UhMdOSqRHOFWa59FQGMMmQhWep2Amp8q4tCU6shcnXsO4egKWYOC0F/iBUCFJhoAa 4BfjpKFeFRn3/tBOGmxhZCnWUJbjoSyMpw9mk27UXMixfe9+jrYOfj+xEAtRCS7+WnLvzIWM jaI4ZoLidhgYcGsDd4pTGYzfaTzJkcOmo1gSBLV0EA8cbj33TfNUpmMTVg4aaeQgw1a98JzV jglNvg2+o/gghno+u1EYOoR7IblchdLogI5C2OSMx42TM9ZFUHoCUSFRynMLnmcDqVCR78BS pkHglgYC6E6ETjrxhl39eTRV0At9/nn3NxFkuLu+Pb1iLw9LZpnwzzeafRD9ByMpVpxJPRJA hQS5wjAFOrpkn0TMM+sfItzOCo3TZeAbdVThAL+1RmKGhBZiYiDGIJ1hm69HSU9+h8qT6PVw otC1i6dEqHPKnsvQPYGokChp3gXcjKee3E1TTAvS4yoWXGMIxl0kRogqfAg3YQYf/Vd6Igsm RB7H4x27H4xZKHSgIrDPxjJXhSg1R6fmzIM4fRRlA/wmFYHjoaxHQFUafnJhDk9lSIcfqUzI KBX3FOMHWyod/cw0Z0NYGE7mn0c4lZ7SBnEOaF5PDgvfXp+xD2b5U+oUzncx1Xj0zK4FTS3b b7iKGX9QKj7RN0oY7XDT2wQyOTqGbKRcSEwuc7BpuFI8ycYwGtczfQ8gqtT9pqcI0V8+pW7K 34Z9PVvt74YizWA3smUF1vPWyjeeswbdapB7V8kwN6KFNTb8j7G2C2N7BVQhgdr2SKYIIaKt uwd6jo2GmI48Yivw3nMhkFdAfvyELz6Hn3APg2NFHNdt4NbOfJCoZmsZYalfbG+TxBHvWBQ+ xv0nyieBl/dxiXU+dlDAYVyusjGAmyyxfRdW9QqoQgIdAGBQoXKFAcyPwt2RQF4B+VnLLz/H Wn6BvqngNpGjWIR9G+2zoVBfupb3N1nL3rEo1vLB063ll4DUp+IgTG++WeKYDlxY1SugSvMx XzZaFFpCWfB3YuNROBLIK6CKCdQmpav3SMw3IJA3QBUSqJOmIgmje9ahdJ0x05ifNZXvRiGu ZIRZ3QBzEB5BIK+AnoJAb1E1jYZCMR7+BpY5OWdIP01kUjfHL8FUBhfiTxMPsnkjAvkA5Ge7 PPwc22XHHOh8wzphiOf6m8vbFdvly022S+9YFNvl4Z+p1AaheVt3LYKrXnjeZ3sCi90kIVch +8eni9ODw8PdX0sHmWYDOaIoGh4HeVzk4dosZkrfczvg8wXlKdKIirPHEKSA8apMIq4wWYXS Oob8VmCEGZUOIu14oySiLWFU6pyWeX9QzBilf2H6YJTl5uhqRPm1MhHTiVCYB4Uj2CAXzyec in33JRuHJjmM5A5L8QgmCoQ5fsFIRpPQKxJM+rX+KHfvvRcgFRImlpjzhgmDvYzSvsrkJ8xW R3UExACHSSZkKcGfTiJ0+aZjWItXQBUSqA/iDotB2Lxvymq36I5wOJSgC6prCmMKi0yquUxd F/r4hFMheUzme+mm3WFRA3h+dtaYUEqqQs2nQU0wH7mtLZ9wqszsXJi29gHGbgWo3P+GBUeU 09HYJv0877QAmvuh4AnOP9V8EZrO2jGtBEP074Qasx7X2fzq2YEtfYTJkG5pAR4BVUigvcbe UIuAELy8+nBdv7lCD2JGo9FgBdK6oU92SFh3EXY1Qa84Cnt/UPxYtK8+h0Wb5MMuSBgQ1tNl M1i01EpNinDlKAmU4Fi6HijyVlIszFS6KG2BoYruhFvJGSckCiNVPx6JClkUoIZgoxdZEh9F RjkBV0oGMDz85duPV9/tsIurdx1NGSaUQTCbuO7CpV4BVbmpyDgvK1zIXi+WvAwKjmQYBSzF DLJsxlQrbRlceTJ3Uva9Aqo0KKUw16wuoEQg0DUbAovTDyiNWCoxFAJzUmbOnVFHdwtX8QWl QtIslnfAyF7Efk4BnVEvjSLqpKl4AeBF6rd2vUv9FdVLveX/ODoynyITVpCbGnRtG/E7VySD qppxitmYOPdNXqBTLuz23VcpgCdmyGgQgaGG9WQCjpsIYSdBPnJbK8wu+rIyTxHg6SR/PcKp MiQbEJPa1K9aXrmK0uH1QOZxiImjkyifLibFO2UneANSpe9ytkBVA/k+45E9Bot5FDKM6LTb SU8WNYm02U7cBLA3IM/WjtwkGm0t8o/p7Dlb8B8E5hDBdyC9rIbOap1aQS7NWrtoWu7AX3og dbOFD/OFFh9aJP6gVJyzrjCXvFSygLf+apF/O4W8INeDqYBGqQVtGoRr1roPGBWSRSaAJm6R uLL4vJrZQqxgDBdUnWHKSKb5zlSEO4WTy8cnnD9kFai9zSs07dsKTa1XjlWgtoDRfvGsykDZ TQeVpLBQkeYqvBWaUqSPCpfdTiH5XA+QPYCoMqLdivWDFeLdScNy7uSZe+LL+oJFqU307bZ2 p3dRWLp9QV41kqrDPM6iNI4cbk3yB6JK16ZZDHlqTnAO0DVSFrA15zrFQEDeBphgScmTIPqc ONNH/8897mYq+g5Lc8UjPsadG/d+DeYT3rRlTx81WE70YfPTXq+AqqwXh5XdjecuIp9miVK5 D4B1bVzEePpqImRKU8eJiX3B+GPezdFqfY6zrIVaD0hSczUmS8BYnTkems7gRpGy1Cs6kKNN AjP9IVAcdtEh4hNd2bHKTyzu6e4YcwjHbYiCsaEw3xvdVFNhMZhIMyk7zBMXC3ftVR4ioIRi Q0PyKj4OnycpG2VRE9wcSfGQLo7WNq7K/GodW2dCA7+El1Fyc19eKbV0XkBta27Cqnxeu3VC 6PfDhFIVM24LFSORPk2I1ItEHBYnNHSVCx3ymRR0GKTNQHei1fpZKJgTZ2FTzJ7mMhnjISHv MnpU8SBdJrwbj6Ex7E6wSqZjac1NDpr3RDa296hrJ9Itp/pG4J+EPjaAo0C0OzZEIBFmQ5UY 3aPsdqnMcgo+Aspz1mu/l6PiFHb+Hg2022sm3pJ2p3j8lzK6Cb5A6c94V94JJ4+AV0CVx5yQ q27A8UwJ47bEdOgWuvgmZn42yEENsUdL7rEmWwKokCBW35oxGTEEcfreg/msrVImwbtU6NOF MF4BVRk4TQaaqVtaHBaQsRZldt6K0RS/zrmNnIKmfQGpsqrGbuEWMw7xqcOD1ZzfnuV8p6Ia HuFUWnEdpy0Rsxy/1qXIWKeMdXYruO4NTKVpGuSwKk093EuGIit3+ykZAJNZRNNm6DDAS37c kjS8gHiavQnnCRkcZV9PCTEjNK0rdOJzl3mGxRcca3J5BFN1Yk85ZQ3nNJ3FV56tfriiosla PNe895z17Y+yiGunwqFAJCfOfOC1Z0vNB8rJrMXV4d0/qJO4/fmdxGX+a2STt00S7NT+oAvS L/VERVrjbbGPdxI/FoHC4xTIJBAqWUDh93RB6yo/LqVuF6MLZossLZRRRB9eWZN2Z9o99F83 btRMKAsDxsHTNKbbqENxF2G1ldJVTTEhhfNSyUwGMt75LxytEn2uwlhouklrNDDH2KCkIddP qTHTLha6bWTKZ/9nXQqD0LJCWWuRfOil56zf/CysgRlHt8IkI/Pkll2P4zsOQucSWgtaq50k 4Ox/+bAXKbKwunj1Gy7PPHVRiHzCqfru30gHuU2I6mLANX55Jek2Z1DxYOsx9xf/IHpgYo3Z 95xrNhBx6pa75glEhUQpLh+mqHOMx6OgvK7IRpjwXyOfsDU9AUFMqw1qTlrzVh0/21U8W/tu LXrLmz9j6q0qi+dAyXWvug7ii1kTYDvKLVBnMfoX43FB5YhRoXhTO4A1ZfDCIgRC1SZGiEjC 2snXSVenr88TOrA14bm6wVrtIlSXdB/dMM2Om9wG5s4iYHHFyjq6Nhd8HJ20W7TWte0yRNXI mBcg4KJJNDE0ZfNftPcX3wXTYebNpUQxNFxJhRJljEIGlLuqeUJ2yyAbxgzNM6rnkRqLhUKZ VC+g71uNfWANugOTk+f6DvRcyi/VjMOGF1MRbwq2B1IPlOi9qdn7OkajUSOTgNTkxg762LR9 N2vspLja46FmOA9sdtDwgHDtc1eGY/uIAzr54m/1dyJB20OqI5aOBxnbbewdfPHF8Zf1OuOq r4/Yf76p12UcIivl6psj9o0S4Tc7DL4dRWE2wG/wIyKQjVOBn+t17B2/7UWxQK5q49e/JOa/ ZRfKTl++uu7fxwbr3EZjPunJ3kHm/u+ywd7CxiNUV+AZjemJgiyRWXMYdlkTkmzRh/6dwkYu QavRmRjqX5JzugMNepi+s43uOXPC7F2DXUZK345/SbbNSD1XUaC1TLboqZP3MZKo1aYR7Jv5 W04FY8yU0R421gitWDDkVqFAd3HWkZ3r3V5YL48N67t7CKnT1XTJhoWKFqF1/tsYiiFYV7wv THaczWPPMCuL46XwfczwmC5XmYTUj43GwGOmEScjNBF9mUVFkbTSIsttuCKZokLQjVbXWAKz GNJcul5xl2ZxZYo5v6H018IDrzH1ZioskroxvniqsSkSUz2IUq/neqeCXNij4NCCLGk63MAq nJo64iyVoFParFKMtRlJpmmspmYVhVigIIJeUPWCN+bM0AlC2EblyUxtioadijlnjg3z4LbU zYqcTtTtsTOaupGgjgJsPx9toGs79uoZG/2sF2gxOdSgbkydNyqIPumlyKalQmcmrqFI5APs Cs2TmxHNRYURjnhmNF0KTVMObzGVo0GEUQ9FCianbvTk1ou5LGisA4U6LVJhMc9+UpaOusHZ KriIYtZm+6JtRE/CC4dSiZlDd8MNRXy9LTg1T2WazKX33ZezLNgt2B4jiVHNtcufrm9gZugv +/gjPX86/5+f3n86P8Pn6+87Hz6UD6YF9QNf/PjTB9sGnyZvn/54eXn+8cx0cNn5u5352o9X N+9//Nj5UDN+MMvfkxvmFLFn1446VXRH7fytM58uTlm71XpFXjN8+JWGfE0yHnmA2ONSDOU0 W8/tKubuNCtXoFO8Nwm9drQ/gOZXVIQQE9liyrhgWZfJTWv0+KpYP1vfwG7Q3erGcurCx93e 1NGjL8R+gCIbX9Vs2N7DpcZGqGx1CTB18fiLcwttiVSdHSYwsKYxvbsbPWOtmvGPK0yja/36 S/LPFQrTw1v3gjIwowg4XAW7gCDN+Pz9pLa/Le/PnBMSD15DuXQnc7wo8ZfipkTqwunKQWq5 5Q19RsJscaed3XI9XP5mFoiHa9Ls5rvtlWKlFrDFDVyGexzvsUL2WbiYyfKUlyuDqCcvd+tQ Tz7ujdmnnrxcokI9eblthHrycZPGAfXk5VoJa+94uH+h7GnriwqoJy8V/Wd72qb0venJiOlf tqrrfohLb37dTamx25XKnrUQHllY2oqo7Uswl7Juq3rF1IuXwr7Uk48SuNSRj2KxxhRzKLta Kp8eCoJaMbtt8Uxj/62oDKk3qP5oLHkfZRINOX3UE/Sr1bY/k1a7fXFA6maranrGqHp8ZTUz Zx5qkBVm7XYFu5a5yzavboXz8//tXWtT22YW/iuafCl0bBfbEBJ3ui00kCFdAkO87eyHnY6Q ZaNWljySDbgz+9/33N6bLBPjy27CvuRLSuz3fm7POefpc1wiuc+/x+Sxb8IYpAPCTfh1aJBt MNHw5cJFIFkAVROVpi9UGlEYnsJlzfDiVPE8P0BZWl7QSPUNe3gGdS2AlR45MaJilELWdBpQ HZipgptHGrP/iGLA60EdBjdeEnpOW0wMAKaASgW4oWDBFy6ZBCIOqOeeNTRClTFbU06uw8sY MyJ3C+NnaFBZ0MY4uXL+9ZuXhxKS8xemyV+ck4bdJNOK9dV1+NaiS8IoccRQQ93Y+GwaMBu6 vVRluzMMaqRHxO0jMm8Ff+hOn31DfZrhwVqNvhA9mc6yW1XjVCuflKZBg/WG3Epg6xSUbEJI +SDKilyKp5OUCu8Nxvm92BL8kXgwhqm+k8dJPX94l5XZsSVkGBZUKxaqWFIPREpsCu8rfsTI NJzaQPUthhjmoiLST/dJTm6eeca4/VkZy3rGC5IfWL2R8H5tO3CxxETQy6HpZlTnosdhNxl2 YdhMREguwQf+IegE3waXeArg6Ud34osXhQq6A8dAief5EfxJEELqMUXVGUZTfexwLGkSJVMw FbJxPY45AE4jCGw2da4xNPIJD2QAlkBISvQwRwe/KzMmja/fs/MZKXPA3iqcA/FDaKVknQqI Bfr+8AbgYiY5AiKFtM7iXuE0yzgdGghIPqG67PQ4hKCF47GE+AieW+/CaiNSF+bC4RIuOD2N ZhvgO6k9wMGKPameUCS7cvI+bKStHv1SdtSqmifbkDB6zgtGgLzLciHiigbqFb7AoSOHcib8 zPCwkkLSAdLfbhlIaY6ZuowmpM1gU9JVZB0ID2QdCli67DknQ6di+ybBqyO9vSNnex3Z3hlO kVT3GKZ/qjgoKepsf4P9TkyAqe8gMJmhbcYVi3XhHY2wUQbdVZt5iLJfGMItZMDcP9txZru7 cGY/j/pYj16JPF4TZTF1kYNuz671+sAPcr1N8flq/L1+zWsbx1jFkZSs0flZOblJI0a29VI2 nI0CY66gMyHupHG0ecmLZJRgEl/iLTvmg5kzAidgzHGpozKruwwtD/mhZY/9sRpHNpCklt0B q2Q8E//MolerSTeWYuhMWyzGWIXTQsp6nboiOSaWAP6Bf6GfLSlhkPOIst+LeWStXFru1a9L BMc45ed6E82hb8L6ZWXL1+PJsra8MYMT58825DtaloV4DoOOyT0u8sM8kxhGEmjrcKRIwFpD GcLsICvSgvBONqfPkEB+Q/4JuZ6tMCNYeMyaVAI0wlZ67ll3bNqgzsmOLbRySyp6465n8Qg2 ahKuXtO6/bQGpTXtqviclqRP5KXVdBHivzyRKamvyFm9vUp3UhmsfNPeJJ2GX7PbR9755v0z 2/XQDnfhodVlruRKt9FAYaqj1u83YH9qnUJ93IibUOPfLEuLycZ1uU4QnBbhIEPj+6kFAcIv uhgJt8kwJlb5kG26gAVGdnQrP1aFE4Ra9zGVl2Fqv33Y0CVCDTjOAsxl++3b45a1DI6Og1/C 6V+N4F2LIZdW8BtBeK9OEx3uw52f5wV6D3hK71SAXl3MHryG/Vc8L47dCD7MkN74oH0gp7U8 0aeW9b715qDd/f2frfZxt/2v6gwX/X80+wF/5jv+DKyUf3t1chkMZ5nk86lQRjnfZXUcPOEz lDmsPGIEO+PsASz/Ixg0ylDAwrv6vN7fNDtH3ebPVzdnC8vqx2kEN5eE8DfwuvM0HyWody+y CG/20zyL7oo8y8HcXU04YyjJioUj/HT18ay/H/Qxz0BCJsW3PSWFVNScRMHPoMWw/EbK0Kyf q2ia8/IPuCZrrcSo5U3q4qhljnMwLeZSGHIbplQ4dh8WSS7GL6eiE7hvp9pK8HTUeKCLpyj1 FOSgLpeRQUqx+s/GpxHFkTRRXJc1iPKSirqueD8q4wOvAbWt7WNLobvyh4NROJFSCuM8/zEb TwiWxRpEJ+zRAYoFcDLER77UTAoiYQdgVvjKLdsK2moKd8CuCnoFLPSUgnMSNHARWOFmhwoK 5NcxTq4zcz3jQIHfJyk6RGfziTZGLrymbDn5Opzcw9jSee3WPPyZXjCiynoqFSzjrJzxI8gr PpWNZ8ua1WSTNMwkDhyA553CfQ7m5i7VAGbmjswMwoqHiamh+zxBKMe6P1VPac68CnSC4WVk 89MUARMqcC3B/2q+5t3z6ejyILz2PTx89X0L1kRPb58+GeXYD8FoPaV0VMLZJBhrEkTbR1mO dpQyzAPxUHvwEAdxiiHFJM3nFmLhMoJa8VMRD1M40dJcQKjqt8cKflqsfx6Ec+fVyexlMk4w 8CcUne7LmknuknEONJ/maVesSnVCOHiMNxN6Vlb262Iqg6pxrBdOj06S27CXt8Gj9t5FZvFl qODGpE6kWJMeOYp8F74oyCcV3iajmXJJVYW+UhalBUtTKjysCnOZYnVbijg3LJuTfDjJr/nF tSzLPlY6U9Sx6KvmXF5uHAOyFZhmczK4ONy7/EHbfhXNCq5GU9rgDjru9Ax1llWy9RJQau1D t5mzVC8mcIWToQ7VMTk4vhMrViwZe2mYQnaqr9X2BF1FuLzDTusoGCfZbBqXKnVZEfSjI5U6 FligDP6MJ5y0UGHRMr89RDhc4R5aQQ/J2wdHKNXIACd7+EUywJFHEK1ooG1224Td5KibKIBH XwqcAy5VoBE4GxBjWiZkU4TTVJGiBiLOaHUkitis3GnBoaSaQs7JMFauUI06wM5qOpDIau6A OiqoF2Ce4VWN9avKIOotMRCmKi2i3ZbUOWLFAiYtQLAVwUYolnO32v2cgNW98/3gNpnyRWZ2 5kH35NDvXUkUQxdG5BZmo3SOi0yoSxHOcDRDV9A1EwYASrjSnCvCeRw8xonk5DhlkJm0E7xP 1ZxiSmsWQWXb96FJzKjBXZ4OSsb7FvtClMqzJVZX/FScQSWhmPh+wEu/C/Fx2WMvjGsEVkM5 ICmLqLu6sR/BSmUaf0I8BCQwdooexNkR0H1RJCfpDLP0djGBGsRkqCyBdmDtkr8uWpswGsoI 0e54GPaplT6XwrJiJon4qZhTyW3KzCcBJRX1V1ByO3oOiJcxjta7AlEGDaUxz9qWHtKzrFgF DIRbweq8AeGqcxkojLiuB1Njkxx2+aNc4nlSoGhYyyulYidU9VAkMWaVqJivSV7ow1NXClC/ 2+alzwlnFneQ1XlpzqbhOqsmBMCRu8G3atKe6drbO9lXGG3/sac+AMFvkmE3xY39u+smLFJ9 ET/NswYNiW579hwyxQ0fxGmA91DVGqDGznHjlUIBWOypKjCguy3GdBB2rlSqEKq1GDISp4ji qWSB+ETJSIa6NGaYgu9rgNRt+pSvd+RTElzg3Fe35r70785Xuq+uc18JJsqxpgIOkPNckr3j 21dPWKqGLKti344Uu6kqUenJ7q23i+s1dtEXe4AvQzQwa1ZjcKkKt+RwkW3Q69ab1rHBwlh6 7NJFrESojZLhNB5iziaXsWRCaHy3fy8NpXQUwemWlo0TNz+fgPFVqodsXJ5ZCoxKFAZiZ+lg bEm2RLhyPu0FkTyp5J5UrKt9xK4FrD/oupW2KkVKxI1SKHpd8TN/jVwHTE/l2cBOT+ndOKgj B9OiQE8bMCmurC21alqxKkDbKR3AdVyGj3taZcke9pdrvHb14bXrZeezx2pLC94h1gC7G3ta aEhgpOC5XmhWWvj1sxeuVfQqz7DyBF2RtmR5+XTmOcm7kEzAAvzsPIST3pZ0YPvJxbFZGeLW 0jmV7FtPjk+Gqh704fQWBfDpGS4y0RwMW5vBsSU0GOE5FFQnp5Erxw9nbTIDfzjlTi12RZ6u jFAe/w1+lovppSgiNKHZCOxaCN9QfqMKQneAuRzvwj7WdI3oFNptrhgiFvkZ6Hdn4zBJe6BP bvOfIvz3VoQFhfKvmAmo8EM8Pc74lj9cM9b7Ih7ZjA6GlMEeYASfyot5a0wf/CmWD5mRNvuz nWt8A9dok3q0/w9JPT6EGR1U580zOD2+MFKPIPgwA8XROf6vk3p0akg9FJ/G+lwadfVUa3Fp qKid+DQ24NKo5ZPwXBqeS8NzaXguDc+l8b/h0liNrKJq31euIPqcY7A9Gg5lvrXp9lQankrD U2l8ZVQa3RdNpXHoqTS+XiqNY0+l4ak0Xj6VRvbVU2l8MUwV23SRO7twkT2VhqfS8FQankrD U2l4Kg1PpeGpNDyVxhdDpeEZKuoZKrbnUXd35FF7Ag1PoPEyCDTu8gdpDUFj/zzGDJstw/p/ Z6zCmLGcLYON3qqUGUvoMuw4ayXKjCV0GVLu6CkzPGWGp8woKp12L56+4Tl1hKv5I4e78Ec8 y4RnmfAsE55lwrNMeJaJdVgmPIXDligctusrHO0Iu/AsE55lwrNMeJYJzzLhWSY8y4RnmdgZ y8TLoHHYnkP3encOnWeZ8CwTnmXCs0x4lomvhGViVxQO27NWxzuyVi+OYWI3mSLFODErUiKb wL9z/zD+F+HvZA+T4VA+1lEfazaz+CHK03xW4K+wKCn75t9Bs/m3/wBIF4a3PiYBAA== --Multipart_20140813201439096606 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, 12 Aug 2014 16:57:36 +0000, Nobo Akiya (nobo) wrote: > Hi Marc, Adrian, > >>> This is rally to check with you. Can influencing the interval value used >>> by a BFD session be used as part of an attack? For example, can forcing >>> the transmission time to be slower make it harder to detect naughtiness? >>> And can forcing the interval to be faster help cause DoS? If so, does >>> limiting the set of available values make attacks easier? >> >> okay, the sentence in section 5 is short I admit :-) But this draft is not >> introducing any new mechanism how to negotiate the interval; it only >> shows >> how the mechanism of RFC5880 can be used to build a negotiation- >> sequence. >> We do not force faster intervals, the adjustment is to slower intervals >> when >> the negotiation fails. >> There is a risk - although I don't see an attack vector - with the fact >> that >> the final interval may be slower than the initial request, i.e.you don't >> get >> the service requested. What the draft contributes is it helps to find a >> common interval and sessions go up where otherwise they may stay down. > > I've spent some time thinking about this, but my conclusion is still the > same: this document does not introduce any new security concerns. Attackers > knowing or not knowing the common intervals won't result in any additional > security concerns to devices implementing the common intervals. Perhaps we > can expand the Security Considerations section a bit to make it more > obvious on what we mean. > > This document does not introduce any additional security concerns. > The security considerations described in the BFD documents, [RFC5880] > and others, apply to devices implementing the BFD protocol, > regardless of whether or not the common interval set is implemented. > > Thanks! > > -Nobo > --Multipart_20140813201439096606-- From nobody Fri Aug 15 08:10:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3850A1A0B07 for ; Fri, 15 Aug 2014 08:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 o6Rr0kiB1KQx for ; Fri, 15 Aug 2014 08:10:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20F931A0B0E for ; Fri, 15 Aug 2014 08:10:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AC706C3F8; Fri, 15 Aug 2014 11:10:07 -0400 (EDT) Date: Fri, 15 Aug 2014 11:10:07 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD MIBs Message-ID: <20140815151007.GA30106@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/BsYwf2YAK_byUUvCVqBFpDsTWU0 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, 15 Aug 2014 15:10:41 -0000 Congratulations to the Working Group and those who worked on the MIBs. We finally have them published and out of the WG queue. Let's try to make progress on the BFD MPLS MIB and make our targeted milestone for this year. -- Jeff ----- Forwarded message from rfc-editor@rfc-editor.org ----- Date: Thu, 14 Aug 2014 11:37:43 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: RFC 7331 on Bidirectional Forwarding Detection (BFD) Management Information Base A new Request for Comments is now available in online RFC libraries. RFC 7331 Title: Bidirectional Forwarding Detection (BFD) Management Information Base Author: T. Nadeau, Z. Ali, N. Akiya Status: Standards Track Stream: IETF Date: August 2014 Mailbox: tnadeau@lucidvision.com, zali@cisco.com, nobo@cisco.com Pages: 39 Characters: 72272 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bfd-mib-22.txt URL: https://www.rfc-editor.org/rfc/rfc7331.txt This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Bidirectional Forwarding Detection (BFD) protocol. This document is a product of the Bidirectional Forwarding Detection Working Group of the IETF. This is now a Proposed Standard. [...] ----- End forwarded message ----- From nobody Sat Aug 16 05:34:03 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C41A09F0 for ; Sat, 16 Aug 2014 05:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 b_QMPxHzM_80 for ; Sat, 16 Aug 2014 05:34:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E0E1A8776 for ; Sat, 16 Aug 2014 05:33:59 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7GCXqEN031563; Sat, 16 Aug 2014 13:33:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7GCXp9F031548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Aug 2014 13:33:52 +0100 From: "Adrian Farrel" To: "'Marc Binderberger'" , "'Nobo Akiya \(nobo\)'" References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140812003439717481.408f4350@sniff.de> <20140813201439097437.33605c21@sniff.de> In-Reply-To: <20140813201439097437.33605c21@sniff.de> Subject: RE: AD review of draft-ietf-bfd-intervals Date: Sat, 16 Aug 2014 13:33:51 +0100 Message-ID: <061901cfb94e$560f3aa0$022dafe0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJUCaKWjC6fmNPcsGyfoiuSg4xChQHoELPrAQFqKuQBbSGZFpqn1C3A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20882.006 X-TM-AS-Result: No--9.742-10.0-31-10 X-imss-scan-details: No--9.742-10.0-31-10 X-TMASE-MatchedRID: 7ySqCuYCpfinykMun0J1wgRH1Nr7oERdOhJ9m53n4aB6GeWCu+JlEMLm p4jPUF8tRFsqph676uC7Ud+6yGPYg/l9KkqHi12rXP5rFAucBUHDHSNFHFxB89qCxkzSpW/XmsV WwUeYm+gkco3l/dxf/OB/3JwU36BJkfRhdidsajM5f9Xw/xqKXdivpTdmVCR22bNx1HEv7HAqtq 5d3cxkNY8uVL0xheujhpzjiiAz3K9+i8q72k7zwhpDb1hQgfTCIbngHADc2XA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bGzc9fakT70drzmXsZfetHS4omM Cc: rtg-bfd@ietf.org, draft-ietf-bfd-intervals.all@tools.ietf.org, "'Marc Binderberger \(mbinderb\)'" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 12:34:02 -0000 All, Thanks for the emails putting me straight on some points. Marc, these changes are good. Please post the I-D and we'll move on. Cheers, Adrian > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: 14 August 2014 04:15 > To: Nobo Akiya (nobo); adrian@olddog.co.uk > Cc: draft-ietf-bfd-intervals.all@tools.ietf.org; rtg-bfd@ietf.org; Gregory Mirsky; > Marc Binderberger (mbinderb) > Subject: RE: AD review of draft-ietf-bfd-intervals > > Hello Adrian, > > attached the (side-by-side) changes we plan to add to a new draft version, > based on your comments. And I hope the replies we have provided are > satisfactory for you - otherwise we need another round of discussion ;-) > > > Thanks & Regards, > Marc From nobody Sat Aug 16 10:54:17 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7F1A0039; Sat, 16 Aug 2014 10:54:13 -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 qXRx5TpM2_u6; Sat, 16 Aug 2014 10:54:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1541A0060; Sat, 16 Aug 2014 10:54:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-intervals-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140816175411.20762.16996.idtracker@ietfa.amsl.com> Date: Sat, 16 Aug 2014 10:54:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/PySfYpJZNO_eoCldvw1G7taxV14 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: Sat, 16 Aug 2014 17:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Common Interval Support in BFD Authors : Nobo Akiya Marc Binderberger Greg Mirsky Filename : draft-ietf-bfd-intervals-03.txt Pages : 8 Date : 2014-08-16 Abstract: BFD requires that messages are transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-intervals-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-intervals-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 16 10:58:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47C71A0078 for ; Sat, 16 Aug 2014 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 E8fDj9LjTCls for ; Sat, 16 Aug 2014 10:58:44 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7951A0048 for ; Sat, 16 Aug 2014 10:58:35 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4DF702AA0F; Sat, 16 Aug 2014 17:58:30 +0000 (GMT) Date: Sat, 16 Aug 2014 10:59:19 -0700 From: Marc Binderberger To: adrian@olddog.co.uk Message-ID: <20140816105919732923.1dce2da1@sniff.de> In-Reply-To: <061901cfb94e$560f3aa0$022dafe0$@olddog.co.uk> References: <03dd01cfb33b$40a2d7d0$c1e88770$@olddog.co.uk> <20140812003439717481.408f4350@sniff.de> <20140813201439097437.33605c21@sniff.de> <061901cfb94e$560f3aa0$022dafe0$@olddog.co.uk> Subject: RE: AD review of draft-ietf-bfd-intervals MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/AQoyEv7b0G1VgF-ufCEL6eUeoFg Cc: draft-ietf-bfd-intervals.all@tools.ietf.org, rtg-bfd@ietf.org, "'Marc Binderberger ' \(mbinderb\)" 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, 16 Aug 2014 17:58:47 -0000 Hello Adrian, thanks. The new version -03 is available: The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ Best regards, Marc On Sat, 16 Aug 2014 13:33:51 +0100, Adrian Farrel wrote: > All, > > Thanks for the emails putting me straight on some points. > > Marc, these changes are good. Please post the I-D and we'll move on. > > Cheers, > Adrian > >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: 14 August 2014 04:15 >> To: Nobo Akiya (nobo); adrian@olddog.co.uk >> Cc: draft-ietf-bfd-intervals.all@tools.ietf.org; rtg-bfd@ietf.org; Gregory > Mirsky; >> Marc Binderberger (mbinderb) >> Subject: RE: AD review of draft-ietf-bfd-intervals >> >> Hello Adrian, >> >> attached the (side-by-side) changes we plan to add to a new draft version, >> based on your comments. And I hope the replies we have provided are >> satisfactory for you - otherwise we need another round of discussion ;-) >> >> >> Thanks & Regards, >> Marc > > From nobody Sun Aug 17 13:57:38 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF671A0010 for ; Sun, 17 Aug 2014 13:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 Iy6UbaXaXyvL for ; Sun, 17 Aug 2014 13:57:35 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0FC1A000F for ; Sun, 17 Aug 2014 13:57:35 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 71E192AA0F; Sun, 17 Aug 2014 20:57:32 +0000 (GMT) Date: Sun, 17 Aug 2014 13:57:31 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) Message-ID: <20140817135731109565.9da317d3@sniff.de> In-Reply-To: References: <20140801234153.16679.46692.idtracker@ietfa.amsl.com> <20140812225551488111.db741812@sniff.de> Subject: RE: I-D Action: draft-akiya-bfd-seamless-ip-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/IS4o0Kc3eSYU9g00PBlBhAcuE1s Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 20:57:37 -0000 Hello Nobo, > Good to hear a comment implying that document restructure effort was worth > the effort :) sorry for the extra effort but I strongly believe it helps to focus on the "base" and "ip" aspects :-) > Good point. It would be a good idea to add some texts to clarify what > "local IP address" is. My immediate thought is that we add some texts > stating that "local IP address" MUST be a routable address by the remote > target. We probably should not get into what "type" of IPv6 address > SBFDInitiator uses and when. Does that sound reasonable? sounds good to me. > Interesting comment. Let me first say that it's probably a good idea to > relax the port range as you said. Now whether we keep the port range > [49152, 65535] or relax it, I would see identification of S-BFD packets on > the initiator side to be: > > - well-known source udp port MUST be matched > - initiator assigned destination port MAY matched > > So the tailoring of access lists won't change. For most implementations you are right. But I like to use the basic BSD socket as a test because anything else is not standardized (de-facto or official). So the Initiator opens a socket with a source UDP port S, sends out a UDP packet to the Reflector with destination UDP port TBD1 and receives the reply back to port S. For the Initiator the port S is what is matched on receiving the packet. Thus my idea to relax it so an implementor can move S into a range where it suites best. While I assume that most ACL implementations do allow for a source port check I think it's still convenient to follow "destination port defines the service". > In terms of relaxing the port range, I'm thinking something along the line > of: > > Initiator can use any UDP port but the port MUST NOT be the well-known > S-BFD port (TBD1). > > What do you think? Yes please! > I understand where you are coming from. However there may be > implementations out there which detects BFD echo packets to take them > through special path in forwarding. We don't automatically want S-BFD echo > packets to get same treatments applied. oh, you are right. Not that I ever liked this "smart behaviour" but it's reality, so okay with a clean sheet approach. > Heh, Name="J. Networks" is a bit funny. Let me see if > I can work with Santosh to clean this up. :-) Regards, Marc From nobody Mon Aug 18 17:19:42 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB2A1A6FAB for ; Mon, 18 Aug 2014 17:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1or45gMj_fJ for ; Mon, 18 Aug 2014 17:19:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B3D1A6FC8 for ; Mon, 18 Aug 2014 17:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3029; q=dns/txt; s=iport; t=1408407576; x=1409617176; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3E1Nc5rxX3CSDHoMu71MM/DryfUqRpI6FiGkOQe0Sac=; b=cqaeY4eA+lyzj86i2Q+WQQfix76/BDcJoS+kj56bHHUlXtjiavwiqz6O lkOTBKNiEctjgOJKERECSd9yZ2utb2R+Vlqg6LiYLUu3RciKhVKHtOO6c +YaoDC1Nn5WwRkmI2u+FXa+EMW9l8ntbro6S5ent/bGZdEEeI4yX0EtBb E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAMeX8lOtJA2D/2dsb2JhbABZgmojgSoE1FgBgR4Wd4QDAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBA4FCIg6AcIeF4l/hRwxBwaDKYEdAQSPEoIToCCDXWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,890,1400025600"; d="scan'208";a="348480906" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 19 Aug 2014 00:19:33 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7J0JWkh027608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 00:19:32 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 19:19:32 -0500 From: "Nobo Akiya (nobo)" To: Marc Binderberger Subject: RE: I-D Action: draft-akiya-bfd-seamless-ip-04.txt Thread-Topic: I-D Action: draft-akiya-bfd-seamless-ip-04.txt Thread-Index: AQHPtrsuZ2aU+r0eH0STd/N4d8gdYpvOfB9wgAcl9YCAAXZNgA== Date: Tue, 19 Aug 2014 00:19:32 +0000 Message-ID: References: <20140801234153.16679.46692.idtracker@ietfa.amsl.com> <20140812225551488111.db741812@sniff.de> <20140817135731109565.9da317d3@sniff.de> In-Reply-To: <20140817135731109565.9da317d3@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/LCstg1dcQofleo5kaiVzY7pqOXg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 00:19:40 -0000 Hi Marc, ACK on all the points. Will revise the s-bfd-ip document to address your co= mments and publish soon (aiming this week). Thanks! -Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Sunday, August 17, 2014 4:58 PM > To: Nobo Akiya (nobo) > Cc: rtg-bfd@ietf.org > Subject: RE: I-D Action: draft-akiya-bfd-seamless-ip-04.txt >=20 > Hello Nobo, >=20 >=20 > > Good to hear a comment implying that document restructure effort was > > worth the effort :) >=20 > sorry for the extra effort but I strongly believe it helps to focus on th= e > "base" and "ip" aspects :-) >=20 >=20 > > Good point. It would be a good idea to add some texts to clarify what > > "local IP address" is. My immediate thought is that we add some texts > > stating that "local IP address" MUST be a routable address by the remot= e > > target. We probably should not get into what "type" of IPv6 address > > SBFDInitiator uses and when. Does that sound reasonable? >=20 > sounds good to me. >=20 >=20 > > Interesting comment. Let me first say that it's probably a good idea to > > relax the port range as you said. Now whether we keep the port range > > [49152, 65535] or relax it, I would see identification of S-BFD packets= on > > the initiator side to be: > > > > - well-known source udp port MUST be matched > > - initiator assigned destination port MAY matched > > > > So the tailoring of access lists won't change. >=20 > For most implementations you are right. But I like to use the basic BSD > socket as a test because anything else is not standardized (de-facto or > official). >=20 > So the Initiator opens a socket with a source UDP port S, sends out a UDP > packet to the Reflector with destination UDP port TBD1 and receives the > reply > back to port S. For the Initiator the port S is what is matched on receiv= ing > the packet. >=20 > Thus my idea to relax it so an implementor can move S into a range where = it > suites best. While I assume that most ACL implementations do allow for a > source port check I think it's still convenient to follow "destination po= rt > defines the service". >=20 >=20 > > In terms of relaxing the port range, I'm thinking something along the l= ine > > of: > > > > Initiator can use any UDP port but the port MUST NOT be the well-known > > S-BFD port (TBD1). > > > > What do you think? >=20 > Yes please! >=20 >=20 > > I understand where you are coming from. However there may be > > implementations out there which detects BFD echo packets to take them > > through special path in forwarding. We don't automatically want S-BFD > echo > > packets to get same treatments applied. >=20 > oh, you are right. Not that I ever liked this "smart behaviour" but it's > reality, so okay with a clean sheet approach. >=20 >=20 > > Heh, Name=3D"J. Networks" is a bit funny. Let me see if > > I can work with Santosh to clean this up. >=20 > :-) >=20 >=20 > Regards, Marc From nobody Mon Aug 18 17:43:00 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37531A872C; Mon, 18 Aug 2014 17:42:56 -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 AykT4ZEzurDj; Mon, 18 Aug 2014 17:42:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A782F1A8725; Mon, 18 Aug 2014 17:42:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Common Interval Support in BFD) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140819004255.4554.16917.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 17:42:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bUrZJwi1fE-OiJzPNRuIOSaptaU Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 00:42:57 -0000 The IESG has received a request from the Bidirectional Forwarding Detection WG (bfd) to consider the following document: - 'Common Interval Support in BFD' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract BFD requires that messages are transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common interval value to run BFD sessions. This document defines a small set of interval values for BFD that we call "Common intervals", and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common intervals. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Aug 18 17:55:41 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAF41A8725; Mon, 18 Aug 2014 17:55:39 -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 doFtWYQmL-_C; Mon, 18 Aug 2014 17:55:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6996B1A8746; Mon, 18 Aug 2014 17:55:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 17:55:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_u7plz-uNdO3OYNJxQYlcCuEQ1o Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 00:55:39 -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 : BFD for Multipoint Networks Authors : Dave Katz Dave Ward Santosh Pallagatti Filename : draft-ietf-bfd-multipoint-04.txt Pages : 27 Date : 2014-08-12 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 19 07:08:47 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF401A0382 for ; Tue, 19 Aug 2014 07:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 PjExIYZn_eDn for ; Tue, 19 Aug 2014 07:08:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DEDDE1A88B8 for ; Tue, 19 Aug 2014 07:08:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 25538C27E; Tue, 19 Aug 2014 10:08:28 -0400 (EDT) Date: Tue, 19 Aug 2014 10:08:28 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-multipoint-04.txt Message-ID: <20140819140828.GJ30106@pfrc> References: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140819005537.9770.19923.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Jbth4cscxn1VU4r4OUscOHGplaU 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, 19 Aug 2014 14:08:45 -0000 Note that this consists mostly of a re-publish with Santosh as the new editor. (And moving from .nroff to .xml.) In the next few weeks, Santosh will be working with known implementors to edit the document to match implementation. Ideally these edits will be complete prior to the next IETF session in Honolulu. This will put us a bit past our original milestone for publication, but still much better on track than many of our previous documents. -- Jeff On Mon, Aug 18, 2014 at 05:55:37PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. > > Title : BFD for Multipoint Networks > Authors : Dave Katz > Dave Ward > Santosh Pallagatti > Filename : draft-ietf-bfd-multipoint-04.txt > Pages : 27 > Date : 2014-08-12 > > Abstract: > This document describes extensions to the Bidirectional Forwarding > Detection (BFD) protocol for its use in multipoint and multicast > networks. Comments on this draft should be directed to rtg- > bfd@ietf.org. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-multipoint-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-multipoint-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 20 17:50:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BD1A6F90 for ; Wed, 20 Aug 2014 17:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 xVZpoF9mNzqZ for ; Wed, 20 Aug 2014 17:49:59 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A81A0039 for ; Wed, 20 Aug 2014 17:49:58 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 4BCE42AA0F; Thu, 21 Aug 2014 00:49:55 +0000 (GMT) Date: Wed, 20 Aug 2014 17:49:58 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Manav Bhatia , Santosh P K Message-ID: <20140820174958312789.d9618a46@sniff.de> In-Reply-To: <20140801234041.19675.62372.idtracker@ietfa.amsl.com> References: <20140801234041.19675.62372.idtracker@ietfa.amsl.com> Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/C3DKVA1sAxgN7AHejk_Yd15vlMc Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 00:50:02 -0000 Hello BFD experts, thanks for the restructuring of the document. The downside of the document improvement is that certain aspects become more prominent now and I would like to comment these ;-) C1: What came to my mind is how much is written about the Discriminator pools. As an implementation proposal it's a great read but from a protocol perspective I think we don't need this. What actually stays as a hard requirement is (1) S-BFD Discriminator Uniqueness as you want to detect to end up on the wrong target. (2) the receiver must know from the lower-layer (e.g. UDP port) that the packet is a S-BFD packet. If another pool is used and what it is used for should be left to the implementor. E.g. if the my_discr on the Initiator side comes from the "normal" pool or from the S-BFD pool - well, using the S-BFD pool for both would make sense to avoid any interference with an existing BFD implementation. Point (2) above allows the implementor to know if the packet is related to S-BFD. Otherwise the Initiator discriminator has a local meaning only. Long story short, section 4.1 IMHO should be a note to the implementor, that collisions are a topic not faced before and a new pool may help; the protocol is designed to provide the information from the lower layer, if needed. C2: section 6.1. New State Variables: the variable bfd.SessionType can have only two values, Initiator and Reflector. As an implementor I would take the liberty to add a state "not-SBFD" as you add this state variable to the base specification ... nitpick, I agree :-) C3: the demand bit. The logic you describe is to avoid a loop attack. I wonder if this can be replaced or at least be reduced as we don't use the same UDP port anymore on Initiator and Reflector ? Open question, I think I stumbled over section 7.7 "If the SBFDInitiator receives an S-BFD packet with Demand (D) bit set, the packet MUST be discarded.", which doesn't make much sense to me anymore. Regards, Marc On Fri, 01 Aug 2014 16:40:41 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > > Title : Seamless Bidirectional Forwarding Detection > (S-BFD) > Authors : Nobo Akiya > Carlos Pignataro > Dave Ward > Manav Bhatia > Juniper Networks > Filename : draft-ietf-bfd-seamless-base-02.txt > Pages : 18 > Date : 2014-08-01 > > Abstract: > This document defines a simplified mechanism to use Bidirectional > Forwarding Detection (BFD) with large portions of negotiation aspects > eliminated, thus providing benefits such as quick provisioning as > well as improved control and flexibility to network nodes initiating > the path monitoring. > > This document updates RFC5880. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-02 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Aug 20 22:37:21 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799071A8035 for ; Wed, 20 Aug 2014 22:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoiXx4Y7zE9K for ; Wed, 20 Aug 2014 22:37:15 -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 A0C221A8034 for ; Wed, 20 Aug 2014 22:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14878; q=dns/txt; s=iport; t=1408599436; x=1409809036; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=2H1Sc4UtUVLJ0b1y+k9UTAS5AD2aOMzoXIJUciZc8FM=; b=mM58RlPHvRPlzMK7U82P3HlR45eWAuJTa2Bfz8MSKnyp9ySn+6/3wE/h LdhQR+nJptEn/bJYs1C6pVqc1pZYRFM0+FwwbLpyia+5bJklok98H/qjt vssC3x4oHJi5UVllWADskC9CnXgP8fkVWg+pC0EZIYQ4CpCwsdEkV8SFD 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkOAJWE9VOtJA2D/2dsb2JhbABagkdGU1MEBIQUxlSBWQEJh1kBgQ8Wd4QDAQEBBAEBAWgDCxIBCBEDAQIoJggLFAkIAgQBDQUJiDkIBcFSF487DQQHCYRDBY8SghMDhCOGeYFXjQGGMoNdbAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.01,906,1400025600"; d="scan'208,217";a="346043635" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP; 21 Aug 2014 05:37:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7L5bEJj005705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 05:37:14 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.163]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 00:37:13 -0500 From: "MALLIK MUDIGONDA (mmudigon)" To: Marc Binderberger , "Nobo Akiya (nobo)" , Manav Bhatia , Santosh P K Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-02.txt Thread-Index: AQHPreIKVXh1NChCl0++bG2K8eZKIpvaq7cAgACscQA= Date: Thu, 21 Aug 2014 05:37:13 +0000 Message-ID: In-Reply-To: <20140820174958312789.d9618a46@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.182] Content-Type: multipart/alternative; boundary="_000_D01B809224200mmudigonciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/WFaEEVKEatqlTjsPLv7e9Oqrdm8 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 05:37:18 -0000 --_000_D01B809224200mmudigonciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marc, Please find my response inline Thanks Regards Mallik From: Marc Binderberger > Date: Thursday 21 August 2014 6:19 AM To: "Nobo Akiya (nobo)" >, Manav Bhat= ia >, Santosh P K <= santoshpk@juniper.net> Cc: "rtg-bfd@ietf.org" > Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt Hello BFD experts, thanks for the restructuring of the document. The downside of the document improvement is that certain aspects become more prominent now and I would like to comment these ;-) C1: What came to my mind is how much is written about the Discriminator pools. As an implementation proposal it's a great read but from a protocol perspective I think we don't need this. What actually stays as a hard requirement is (1) S-BFD Discriminator Uniqueness as you want to detect to end up on the wrong target. (2) the receiver must know from the lower-layer (e.g. UDP port) that the packet is a S-BFD packet. If another pool is used and what it is used for should be left to the implementor. E.g. if the my_discr on the Initiator side comes from the "normal" pool or from the S-BFD pool - well, using the S-BFD pool for both would make sense to avoid any interference with an existing BFD implementation. Point (2) above allows the implementor to know if the packe= t is related to S-BFD. Otherwise the Initiator discriminator has a local meaning only. Long story short, section 4.1 IMHO should be a note to the implementor, tha= t collisions are a topic not faced before and a new pool may help; the protoc= ol is designed to provide the information from the lower layer, if needed. C2: section 6.1. New State Variables: the variable bfd.SessionType can hav= e only two values, Initiator and Reflector. As an implementor I would take th= e liberty to add a state "not-SBFD" as you add this state variable to the bas= e specification ... nitpick, I agree :-) C3: the demand bit. The logic you describe is to avoid a loop attack. I wonder if this can be replaced or at least be reduced as we don't use the same UDP port anymore on Initiator and Reflector ? Open question, I think I stumbled over section 7.7 "If the SBFDInitiator receives an S-BFD packet with Demand (D) bit set, the packet MUST be discarded.", which doesn't make much sense to me anymore. Mallik>> You are suggesting that based on the Source or Destination UDP por= t which can be well known UDP port, we can decide whether a packet can be r= eflected. E.g., If Source UDP is a well known port, then the packet is comi= ng from reflector and should not be reflected back. I agree. If there is some way of identifying this case then it should be ok= . Anyway we can wait for others to comment on this. Regards, Marc On Fri, 01 Aug 2014 16:40:41 -0700, internet-drafts@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF. Title : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Juniper Networks Filename : draft-ietf-bfd-seamless-base-02.txt Pages : 18 Date : 2014-08-01 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_D01B809224200mmudigonciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4BDE6B6335CBC14E84BB10B2BAD321FC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Marc,

Please find my response inline

Thanks

Regards
Mallik

From: Marc Binderberger <marc@sniff.de>
Date: Thursday 21 August 2014 6:19 = AM
To: "Nobo Akiya (nobo)" &= lt;nobo@cisco.com>, Manav Bhatia &= lt;manav@ionosnetworks.com&g= t;, Santosh P K <santoshpk@juni= per.net>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: I-D Action: draft-ietf= -bfd-seamless-base-02.txt

Hello BFD experts,

thanks for the restructuring of the document. The downside of the docu= ment
improvement is that certain aspects become more prominent now and I wo= uld
like to comment these ;-)


C1: What came to my mind is how much is written about the Discriminato= r
pools. As an implementation proposal it's a great read but from a prot= ocol
perspective I think we don't need this. What actually stays as a hard =
requirement is

(1) S-BFD Discriminator Uniqueness as you want to detect to end up on = the
wrong target.

(2) the receiver must know from the lower-layer (e.g. UDP port) that t= he
packet is a S-BFD packet.

If another pool is used and what it is used for should be left to the =
implementor. E.g. if the my_discr on the Initiator side comes from the=
"normal" pool or from the S-BFD pool - well, using the S-BFD= pool for both
would make sense to avoid any interference with an existing BFD
implementation. Point (2) above allows the implementor to know if the = packet
is related to S-BFD. Otherwise the Initiator discriminator has a local=
meaning only.

Long story short, section 4.1 IMHO should be a note to the implementor= , that
collisions are a topic not faced before and a new pool may help; the p= rotocol
is designed to provide the information from the lower layer, if needed= .


C2: section 6.1.  New State Variables: the variable bfd.Sess= ionType can have
only two values, Initiator and Reflector. As an implementor I would ta= ke the
liberty to add a state "not-SBFD" as you add this state vari= able to the base
specification ... nitpick, I agree :-)


C3: the demand bit. The logic you describe is to avoid a loop attack. = I
wonder if this can be replaced or at least be reduced as we don't use = the
same UDP port anymore on Initiator and Reflector ?
Open question, I think I stumbled over section 7.7 "If the SBFDIn= itiator
receives an S-BFD packet with Demand (D) bit set, the packet MUST be <= /div>
discarded.", which doesn't make much sense to me anymore.

Mallik>> You are suggesting that based on the Source or Destinat= ion UDP port which can be well known UDP port, we can decide whether a pack= et can be reflected. E.g., If Source UDP is a well known port, then the pac= ket is coming from reflector and should not be reflected back. 
I agree. If there is some way of identifying this case then it should = be ok. Anyway we can wait for others to comment on this.


Regards, Marc




On Fri, 01 Aug 2014 16:40:41 -0700, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
  This draft is a work item of the Bidirectional Forwarding = Detection
Working Group of the IETF.
         Title  &nbs= p;        : Seamless Bidirectional Forwa= rding Detection
(S-BFD)
         Authors  &n= bsp;      : Nobo Akiya
           &nbs= p;            &= nbsp;  Carlos Pignataro
           &nbs= p;            &= nbsp;  Dave Ward
           &nbs= p;            &= nbsp;  Manav Bhatia
           &nbs= p;            &= nbsp;  Juniper Networks
Filena= me        : draft-ietf-bfd-seamless= -base-02.txt
Pages&= nbsp;          : 18
Date&n= bsp;           : 201= 4-08-01
Abstract:
    This document defines a simplified mechanism t= o use Bidirectional
    Forwarding Detection (BFD) with large portions= of negotiation aspects
    eliminated, thus providing benefits such as qu= ick provisioning as
    well as improved control and flexibility to ne= twork nodes initiating
    the path monitoring.
    This document updates RFC5880.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/
There's also a htmlized version available at:
A diff from the previous version is available at:
Please note that it may take a couple of minutes from the time of subm= ission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
_______________________________________________
I-D-Announce mailing list


 --_000_D01B809224200mmudigonciscocom_-- From nobody Fri Aug 22 14:51:15 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6883E1A0AF1 for ; Fri, 22 Aug 2014 14:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAwbC2ap_WFW for ; Fri, 22 Aug 2014 14:51:12 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89021A067D for ; Fri, 22 Aug 2014 14:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7530; q=dns/txt; s=iport; t=1408744271; x=1409953871; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c7FazVEjr+iXx+nUjW8Gm5ZoUV0IUQRC59OUsuqpE/I=; b=YwXwJVNkiyCT0RnvDf9/qwTOP2OznARl1/dOM6akvlI6B+Q78PdIPprC JBrg34AQeHdnyi06kal6Jw9NMPUJxJRf9dOFqXkcoONLlzqMDri6Y0r2s SpoKTsUr5rzCe08G+4XekXJujaGKWxuGEavhebagQ9ljuST4a7QnANxg3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAJi691OtJV2R/2dsb2JhbABZgmojU1MEBMxQCodNAYEQFneEAwEBAQMBAQEBaAMLDAQCAQgRAwEBAQEKJCcLHQgCBAENBQgBiDEIAQcFxH8XiX+FHDECBQaDKYEdBYpmhC2CE4QpiFKNAoYyg15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,383,1406592000"; d="scan'208";a="71585470" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 22 Aug 2014 21:51:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7MLpAU6015508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 21:51:10 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 16:51:10 -0500 From: "Nobo Akiya (nobo)" To: "MALLIK MUDIGONDA (mmudigon)" , Marc Binderberger , Manav Bhatia , Santosh P K Subject: RE: I-D Action: draft-ietf-bfd-seamless-base-02.txt Thread-Topic: I-D Action: draft-ietf-bfd-seamless-base-02.txt Thread-Index: AQHPreIKV14qRNXvQUaHJOI+93xwk5vaq7cAgABQQYCAAjFJQA== Date: Fri, 22 Aug 2014 21:51:10 +0000 Message-ID: References: <20140820174958312789.d9618a46@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/2RV6lI7deEu-hwl1EeIbm6sqUoY Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:51:14 -0000 Hi Marc, Mallik, et al, Please see in-line for [NOBO]. > -----Original Message----- > From: MALLIK MUDIGONDA (mmudigon) > Sent: Thursday, August 21, 2014 1:37 AM > To: Marc Binderberger; Nobo Akiya (nobo); Manav Bhatia; Santosh P K > Cc: rtg-bfd@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt >=20 > Hi Marc, >=20 > Please find my response inline >=20 > Thanks >=20 > Regards > Mallik >=20 > From: Marc Binderberger > Date: Thursday 21 August 2014 6:19 AM > To: "Nobo Akiya (nobo)" , Manav Bhatia > , Santosh P K > Cc: "rtg-bfd@ietf.org" > Subject: Re: I-D Action: draft-ietf-bfd-seamless-base-02.txt >=20 > Hello BFD experts, >=20 > thanks for the restructuring of the document. The downside of the > document > improvement is that certain aspects become more prominent now and I > would > like to comment these ;-) >=20 >=20 > C1: What came to my mind is how much is written about the Discriminator > pools. As an implementation proposal it's a great read but from a protoco= l > perspective I think we don't need this. What actually stays as a hard > requirement is >=20 > (1) S-BFD Discriminator Uniqueness as you want to detect to end up on the > wrong target. >=20 > (2) the receiver must know from the lower-layer (e.g. UDP port) that the > packet is a S-BFD packet. >=20 > If another pool is used and what it is used for should be left to the > implementor. E.g. if the my_discr on the Initiator side comes from the > "normal" pool or from the S-BFD pool - well, using the S-BFD pool for bot= h > would make sense to avoid any interference with an existing BFD > implementation. Point (2) above allows the implementor to know if the > packet > is related to S-BFD. Otherwise the Initiator discriminator has a local > meaning only. >=20 > Long story short, section 4.1 IMHO should be a note to the implementor, > that > collisions are a topic not faced before and a new pool may help; the > protocol > is designed to provide the information from the lower layer, if needed. I see your point, but do also note that the entire Section 4 grew over time= as more and more clarifications were requested. So I think it's worth pres= erving most of the texts in this section. With that said, I do have an idea= on how we can address your concern. Section 4.2 will be moved before section 4.1, and pre-text will be added in= the "Discriminator Pools" section. New Section 4 will look like: ---- snip ---- 4. S-BFD Discriminators 4.1. S-BFD Discriminator Uniqueness 4.2. Discriminator Pools This subsection describes a discriminator pool implementation technique to minimize S-BFD discriminator collisions. The result will allow an implementation to better satisfy the S-BFD discriminator uniqueness requirement defined in Section 4.1. o SBFDInitiator is to allocate a discriminator from the BFD discriminator pool. If the system also supports classical BFD that runs on [RFC5880], then the BFD discriminator pool SHOULD be shared by SBFDInitiator sessions and classical BFD sessions. ---- snip ---- What do you think? >=20 >=20 > C2: section 6.1.=A0=A0New State Variables: the variable bfd.SessionType c= an have > only two values, Initiator and Reflector. As an implementor I would take = the > liberty to add a state "not-SBFD" as you add this state variable to the b= ase > specification ... nitpick, I agree :-) Ah yes, that should be clarified. We will change the text to: o bfd.SessionType: This is a variable introduced by [I-D.ietf-bfd-multipoint] and describes the type of this session. Allowable values for S-BFD sessions are: >=20 >=20 > C3: the demand bit. The logic you describe is to avoid a loop attack. I > wonder if this can be replaced or at least be reduced as we don't use the > same UDP port anymore on Initiator and Reflector ? > Open question, I think I stumbled over section 7.7 "If the SBFDInitiator > receives an S-BFD packet with Demand (D) bit set, the packet MUST be > discarded.", which doesn't make much sense to me anymore. >=20 > Mallik>> You are suggesting that based on the Source or Destination UDP > port which can be well known UDP port, we can decide whether a packet > can be reflected. E.g., If Source UDP is a well known port, then the pack= et is > coming from reflector and should not be reflected back. > I agree. If there is some way of identifying this case then it should be = ok. > Anyway we can wait for others to comment on this. I think it is ok (or I would even go to the extent of saying it is desirabl= e) to keep the (D)emand based loop prevention. This way: - We have a loop prevention in the base. - Data plane procedures can have an additional loop prevention if possible = (which is the case for IP based S-BFD with UDP ports as you indicated). Thanks! -Nobo >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On Fri, 01 Aug 2014 16:40:41 -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > =A0=A0This draft is a work item of the Bidirectional Forwarding Detection > Working Group of the IETF. > =A0=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Seamless B= idirectional Forwarding Detection > (S-BFD) > =A0=A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Nobo Akiya > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Carlos Pignataro > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Dave Ward > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Manav Bhatia > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Juniper Networks > Filename=A0=A0=A0=A0=A0=A0=A0=A0: draft-ietf-bfd-seamless-base-02.txt > Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 18 > Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2014-08-01 > Abstract: > =A0=A0=A0=A0This document defines a simplified mechanism to use Bidirecti= onal > =A0=A0=A0=A0Forwarding Detection (BFD) with large portions of negotiation= aspects > =A0=A0=A0=A0eliminated, thus providing benefits such as quick provisionin= g as > =A0=A0=A0=A0well as improved control and flexibility to network nodes ini= tiating > =A0=A0=A0=A0the path monitoring. > =A0=A0=A0=A0This document updates RFC5880. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-02 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-base-02 > 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/ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Fri Aug 22 14:52:11 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714EB1A0AF1 for ; Fri, 22 Aug 2014 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leYSkTL3MNsG for ; Fri, 22 Aug 2014 14:52:08 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9261A0ADA for ; Fri, 22 Aug 2014 14:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3844; q=dns/txt; s=iport; t=1408744329; x=1409953929; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LSbWGiuqrXfeivutZypKxgDmsi8maHAkt51OzxzX13g=; b=DvxgnRSZaxqhRjjil5Kowvp7c7jhl/5L70GRBmIhuvDeRfSfuMiwtFgU wC2dfPdTy7UCOJKHRMcgBfdwnhsX/Re4eUy7TDk1QHcxSpQ3XQ6CPsRQ3 VxUYvi2DOUbub/Lm2Ch9p8ADhNibBTBYJwYcOZtIwWoATYLulpKe1HMQv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEy791OtJV2Y/2dsb2JhbABZgmojU00OzFyHSwGBEBZ3hAMBAQEDATo4BwUHBAIBCBEEAQELFBAyHQgBAQQODYgyCAEMxQETBIl/hRwxBwaDKYEdBY8TghOEKZwGg16CNIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,383,1406592000"; d="scan'208";a="71638798" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 22 Aug 2014 21:51:57 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7MLpumW011070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Aug 2014 21:51:56 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 16:51:56 -0500 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" Subject: RE: A few thoughts on S-BFD drafts Thread-Topic: A few thoughts on S-BFD drafts Thread-Index: Ac+98Se65rKjYjyuTDCs3LZOq9i/3QAHo8lQ Date: Fri, 22 Aug 2014 21:51:55 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D346812BC@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D346812BC@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/5ycPhn-6aMRJmGUkCE8nZSQcf74 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:52:10 -0000 Hi Prasad, Thanks for good comments. I hope you are ok with the list being cc'ed on th= is response. > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) > Sent: Friday, August 22, 2014 6:10 AM > To: Nobo Akiya (nobo) > Subject: A few thoughts on S-BFD drafts >=20 > Hello Nobo, >=20 > 1. Encapsulation for MPLS based: Do we always assume IP address based > encapsulation? Yes IP/UDP headers are required. When there's a need, a new document descri= bing GAL/GACh based S-BFD is needed. > 2. S-BFD echo: > a. For IP single-hop : No issues, however the SBFD initiator MUST NOT = send > echo packets when the reflector sets EchoMinRxInterval to 0. Sec 7.3.2 of > the base requires that this field SHOULD be set to 0. This may need to b= e > reworded. Sec 10 also is not clear (in my understanding) on the usage of = the > EchoMinRxInterval field. Right. Both Sections 7.2.2/7.3.2 states that "Required Min Echo RX Interval= " SHOULD be zero. Section 10 further expands this by stating that "Required= Min Echo RX Interval" MAY be set but explains why that's not useful. I don= 't believe Sections 7.2.2/7.3.2 needs to be changed, but let me see if Sect= ion 10 can be clarified a bit more. > b. For IP multi-hop: This is a difference from RFC 5882. How does an > intermediate node (unaware of any S-BFD procedure) avoid U-turning the S- > BFD echo packet? Would it be better to say that S-BFD echo MUST NOT be > used if the Reflector is more than one hop away? This topic should become clearer once we roll out the new revision of draft= -akiya-bfd-seamless-sr, it's almost ready. > c. BFD for MPLS-TE LSPs: How is SBFDReflector supposed to work? Will t= he > SBFDReflector always be at the tail of the tunnel? Usually when using S-BFD on an RSVP-TE LSP, one would send in-band S-BFD pa= ckets with max TTL on the label. So the target node of S-BFD packets will b= e the egress of the RSVP-TE LSP. However, S-BFD packets could be terminated= on transit LSR with careful TTL tweaking if that was ever required. Section 5.2 of https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip= /?include_text=3D1. > d. BFD for PW: Does SBFD apply here? S-BFD best benefits monitoring of uni-directional paths. Personally I would= not push S-BFD usage on the PW being bi-directional, but continue using th= e classical BFD. However, it is technically possible for the two end points= to use S-BFD if that was desired. > 3. Base draft should mention the relationship between S-BFD and P2MP BFD > (if any). The way the document is structured is that we have the base and the related= data plane documents. P2MP is another data plane type, thus IMO, one shoul= d write a new P2MP S-BFD document when P2MP S-BFD is desired. > 4. Names of packet types: Why not consider disambiguating S-BFD packets > as S-BFD Async now that we have S-BFD Echo? For example, does Sec 5.1 of > the base draft apply to S-BFD (Async) packets only or does it apply to S-= BFD > Echo as well? Good point. I think that will improve the readability. Will incorporate thi= s in the next revision. > 5. Sec 7.3.2 of the base draft: Why should the desired MinTx interval be > copied from the received packet at the reflector? Can it not be set to 0 = as > the reflector does not originate packets. The Required Min Rx can be used > to do the rate controlling as specified in the draft. You are right, but a counter argument to what you are saying is that SBFDRe= flector is sending (or reflecting) S-BFD packets, so one can argue that zer= o(0) may not be an accurate reflection of the behavior. This is something w= e can go with whatever the WG wants (i.e. either way is likely reasonable). Thanks! -Nobo > Regards > Prasad >=20 From nobody Sat Aug 23 07:13:54 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD111A0378; Sat, 23 Aug 2014 07:13:48 -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 rRo3ewf2ZqSx; Sat, 23 Aug 2014 07:13:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1411A03A3; Sat, 23 Aug 2014 07:13:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-seamless-base-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140823141346.6235.36811.idtracker@ietfa.amsl.com> Date: Sat, 23 Aug 2014 07:13:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/FBXK-2ZcsEBC4ulJLtB3OvWiXWI 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: Sat, 23 Aug 2014 14:13:49 -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 : Seamless Bidirectional Forwarding Detection (S-BFD) Authors : Nobo Akiya Carlos Pignataro Dave Ward Manav Bhatia Santosh Pallagatti Filename : draft-ietf-bfd-seamless-base-03.txt Pages : 18 Date : 2014-08-23 Abstract: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. This document updates RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-seamless-base-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 23 07:23:50 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAAB1A02BA for ; Sat, 23 Aug 2014 07:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzNCBzvc1DYJ for ; Sat, 23 Aug 2014 07:23:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9111A026E for ; Sat, 23 Aug 2014 07:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1408803828; x=1410013428; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2hKufo/xGQGyOhn9SZ9hEsvE74ds9ryz5pnD8xLs8MQ=; b=UcUm4rhUmXesrx9Y3JkzTk/bB0mXn4OG4r99MdcUk78mIQ9njVtmKTZ7 PqwREootTdRWAzRlEpxHqNpmDYCjmd4YgvCarZBFS40Btudmr8QdAfuXk Wp6Ge6CH6XPsvwJoE/uIadRnzM8JStHloPWP0Z/CNkkLXHipBFfkpk8a3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALai+FOtJV2b/2dsb2JhbABZgmojU1MEBMxfh0sBgQcWd4QFAQQ6MSABKhRCJgEEGwGIOQEHBaAzo3oXjxuDZ4EdBY8TghOEKYhSkzSDXmwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,386,1406592000"; d="scan'208";a="349759832" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 23 Aug 2014 14:23:47 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7NENlQs027516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 23 Aug 2014 14:23:47 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 09:23:47 -0500 From: "Nobo Akiya (nobo)" To: "rtg-bfd@ietf.org" Subject: New Versions for S-BFD Base/IP/SR Thread-Topic: New Versions for S-BFD Base/IP/SR Thread-Index: Ac++3Z0MxZejLMUNRRCQ1W33YEbNxQ== Date: Sat, 23 Aug 2014 14:23:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/7t2LOLFuVc_emLV5CUqrdz3u0i0 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, 23 Aug 2014 14:23:50 -0000 Hello BFD WG, S-BFD authors have just published revisions for the base, IP and Segment Ro= uting documents. Links to the 3 documents can be found below. Many thanks to those who provided comments! We are seeking further comments from experts to solidify the S-BFD mechanis= m. We also believe draft-akiya-bfd-seamless-ip-05 is ready for the WG adoption= poll. We will ask Jeff to initiate the WG adoption poll soon, followed by expert = review to allocate the port assignment if the document adopted. Thanks! -Nobo, on behalf of authors URL: http://www.ietf.org/internet-drafts/draft-ietf-bfd-seamless= -base-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-ba= se/ Htmlized: http://tools.ietf.org/html/draft-ietf-bfd-seamless-base-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-seamless-= base-03 URL: http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamles= s-ip-05.txt Status: https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-i= p/ Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-ip-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless= -ip-05 URL: http://www.ietf.org/internet-drafts/draft-akiya-bfd-seamles= s-sr-03.txt Status: https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-s= r/ Htmlized: http://tools.ietf.org/html/draft-akiya-bfd-seamless-sr-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-seamless= -sr-03 From nobody Sun Aug 24 22:14:58 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FC1A8A16; Sun, 24 Aug 2014 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.893 X-Spam-Level: X-Spam-Status: No, score=-100.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FcHkN6Hy9UV1; Sun, 24 Aug 2014 22:14:51 -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 341401A8A15; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-05-53fa71a3aa42 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.D5.05330.3A17AF35; Mon, 25 Aug 2014 01:13:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 25 Aug 2014 01:14:48 -0400 From: Gregory Mirsky To: "'draft-tissa-netmod-oam@tools.ietf.org'" Subject: draft-tissa-netmod-oam Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9A== Date: Mon, 25 Aug 2014 05:14:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82567E@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.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn+6Swl/BBt8a+Sz2bnvJavH42yF2 i1tLV7JazL/YyGrxdL6kxec/2xgtjl/4zWgxb9cHJgcOjyVLfjJ5fLn8mS2AKYrLJiU1J7Ms tUjfLoEr4/yZ1ewFN6oqdrT/YGlg3JTVxcjJISFgIvHgxG0mCFtM4sK99WwgtpDAUUaJX4/0 IezljBJbvumA2GwCRhIvNvawg9giAuESK+7/ALK5OJgFGpkk5j5+BdYsLKAgsfndbxaIIlWJ /Y3/mSFsPYn38w+CxVmA4lc6JoIN4hXwlZjWfAaslxHoiO+n1oAdxCwgLnHryXyo4wQkluw5 zwxhi0q8fPyPFcJWkvj4ez47RH2+xJUdp1kgZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMr2MSbLo7GPe8tDzEKMDBqMTD u2D7z2Ah1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk2JL7 oOnR171K7X9yJ/8N3Gi1VcxsvsNGufZ+i3lznpjezzKb6+DSW3XFP3ey28Rp7U0+1e/WlL2N 4t280WCqyoLXKxKfak7dan3F5eXBuX1f37vMrzaasdZdfjHjTTV2Kft/r8yuH+linHP6FN83 HfN7B7o3KpqlB1jWZUQdb45PPTBlUd4aJZbijERDLeai4kQAvcFrVJACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6sJXmVdaz5zsAfqsatBk4QNq8G0 Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:14:54 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_-- From nobody Mon Aug 25 04:12:55 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055E51A902D for ; Mon, 25 Aug 2014 04:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCg4yZxWS4WI for ; Mon, 25 Aug 2014 04:12:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC6D1A9029 for ; Mon, 25 Aug 2014 04:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6172; q=dns/txt; s=iport; t=1408965169; x=1410174769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jPsgdEsK9j4uHUY/+PYfn7urIELka1ppYDhVnNz+7QQ=; b=L2EadA+KVCTI9mrIMURiCJ0VrK8wnw38U/xjrs0cy4VzQKp02AhdjQqW qlmaeCYTRJKh5Ard7vwThCxoafhr/28TM0Cjbs79XXa+ZbMbFPosQKWIY mL8wA63LqvUe3C3pswsY2J3sbBd/ri2uIfznUuFMx9X1jfP6LQFc1VpIj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABwZ+1OtJA2L/2dsb2JhbABagw1TTQoEzFWHSwGBHBZ3hAMBAQEDATo4BwUHBAIBCBEEAQELFBAyHQgBAQQOBQiIMggNv28TBIl/hRwxBwaDKYEdBY8TghOEKZwGg15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,396,1406592000"; d="scan'208";a="350039943" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 25 Aug 2014 11:12:48 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7PBClVo012282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 11:12:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.207]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 06:12:47 -0500 From: "Vengada Prasad Govindan (venggovi)" To: "Nobo Akiya (nobo)" Subject: RE: A few thoughts on S-BFD drafts Thread-Topic: A few thoughts on S-BFD drafts Thread-Index: Ac+98Se65rKjYjyuTDCs3LZOq9i/3QAHo8lQAIzhzdA= Date: Mon, 25 Aug 2014 11:12:47 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D3468270F@xmb-rcd-x15.cisco.com> References: <315041E4211CB84E86EF7C25A2AB583D346812BC@xmb-rcd-x15.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.143.25.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/GyBqnQty8lD-7o2bWQW3lxmrGMg Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 11:12:51 -0000 Hello Nobo, Many thanks to you for taking this thread to the list, please find response= s to previous comments in-line with GVP1>. Additionally, please find a thre= e more comments on draft-akiya-bfd-seamless-ip-05.=20 =20 Sec 2. S-BFD UDP port: A minor nit: Should this section be called S-BFD Control UDP port (if it a= chieves better clarity) Sec 4: Reference to "classical BFD" may need to have a reference cited to RFC 588= 0? Sec 7.2: ---snip--- o Implementations MUST provide filtering capability based on source IP addresses of received S-BFD control packets: [RFC2827]. ---snip--- A few questions regarding the above text: 1. How will an implementation demonstrate its capability to support the abo= ve requirement? In other words should this be a mandatory requirement? I un= derstand that the intent of the requirement is to achieve resource/ equipme= nt protection against DoS attacks.=20 2. Should the section refer to mechanisms like GTSM?=20 Thanks Prasad -----Original Message----- From: Nobo Akiya (nobo)=20 Sent: Saturday, August 23, 2014 3:22 AM To: Vengada Prasad Govindan (venggovi) Cc: rtg-bfd@ietf.org Subject: RE: A few thoughts on S-BFD drafts Hi Prasad, Thanks for good comments. I hope you are ok with the list being cc'ed on th= is response. > -----Original Message----- > From: Vengada Prasad Govindan (venggovi) > Sent: Friday, August 22, 2014 6:10 AM > To: Nobo Akiya (nobo) > Subject: A few thoughts on S-BFD drafts >=20 > Hello Nobo, >=20 > 1. Encapsulation for MPLS based: Do we always assume IP address based=20 > encapsulation? Yes IP/UDP headers are required. When there's a need, a new document descri= bing GAL/GACh based S-BFD is needed. GVP1> Would you think that this understanding needs to be recorded in the d= ocument. Perhaps, somewhere in Sec 5. My suggestion is to make the opening = sentence of Sec 5 a mandatory requirement. But I leave it to you to decide. > 2. S-BFD echo: > a. For IP single-hop : No issues, however the SBFD initiator MUST=20 > NOT send echo packets when the reflector sets EchoMinRxInterval to 0.=20 > Sec 7.3.2 of the base requires that this field SHOULD be set to 0. =20 > This may need to be reworded. Sec 10 also is not clear (in my=20 > understanding) on the usage of the EchoMinRxInterval field. Right. Both Sections 7.2.2/7.3.2 states that "Required Min Echo RX Interval= " SHOULD be zero. Section 10 further expands this by stating that "Required= Min Echo RX Interval" MAY be set but explains why that's not useful. I don= 't believe Sections 7.2.2/7.3.2 needs to be changed, but let me see if Sect= ion 10 can be clarified a bit more. > b. For IP multi-hop: This is a difference from RFC 5882. How does=20 > an intermediate node (unaware of any S-BFD procedure) avoid U-turning=20 > the S- BFD echo packet? Would it be better to say that S-BFD echo MUST=20 > NOT be used if the Reflector is more than one hop away? This topic should become clearer once we roll out the new revision of draft= -akiya-bfd-seamless-sr, it's almost ready. GVP1> Just for further understanding, S-BFD echo procedures would work in s= ingle-hop for IPv4 and IPv6. S-BFD echo requires IPv6 or MPLS Segment Routi= ng dataplanes to work. Is this correct?=20 > c. BFD for MPLS-TE LSPs: How is SBFDReflector supposed to work?=20 > Will the SBFDReflector always be at the tail of the tunnel? Usually when using S-BFD on an RSVP-TE LSP, one would send in-band S-BFD pa= ckets with max TTL on the label. So the target node of S-BFD packets will b= e the egress of the RSVP-TE LSP. However, S-BFD packets could be terminated= on transit LSR with careful TTL tweaking if that was ever required. Section 5.2 of https://datatracker.ietf.org/doc/draft-akiya-bfd-seamless-ip= /?include_text=3D1. > d. BFD for PW: Does SBFD apply here? S-BFD best benefits monitoring of uni-directional paths. Personally I would= not push S-BFD usage on the PW being bi-directional, but continue using th= e classical BFD. However, it is technically possible for the two end points= to use S-BFD if that was desired. > 3. Base draft should mention the relationship between S-BFD and P2MP=20 > BFD (if any). The way the document is structured is that we have the base and the related= data plane documents. P2MP is another data plane type, thus IMO, one shoul= d write a new P2MP S-BFD document when P2MP S-BFD is desired. GVP1> Agreed, it may be help to add a clarifying statement mentioning that = P2MP BFD is outside the scope of the current document. > 4. Names of packet types: Why not consider disambiguating S-BFD=20 > packets as S-BFD Async now that we have S-BFD Echo? For example, does=20 > Sec 5.1 of the base draft apply to S-BFD (Async) packets only or does=20 > it apply to S-BFD Echo as well? Good point. I think that will improve the readability. Will incorporate thi= s in the next revision. > 5. Sec 7.3.2 of the base draft: Why should the desired MinTx interval=20 > be copied from the received packet at the reflector? Can it not be set=20 > to 0 as the reflector does not originate packets. The Required Min Rx=20 > can be used to do the rate controlling as specified in the draft. You are right, but a counter argument to what you are saying is that SBFDRe= flector is sending (or reflecting) S-BFD packets, so one can argue that zer= o(0) may not be an accurate reflection of the behavior. This is something w= e can go with whatever the WG wants (i.e. either way is likely reasonable). GVP1> Agreed. One could make it a non-zero value based on the packet rate t= hat can be actually supported by the reflector (note that this can be a val= ue less than or equal to the required minRx set by the initiator). This hig= hlights one important (in my view at least) difference with respect to clas= sical BFD. In classical BFD, while the packet rates in each direction can b= e asymmetric, the packet rates of S-BFD have to (eventually) be symmetric. = In any case a copy may not be possible. Thanks! -Nobo > Regards > Prasad >=20 From nobody Mon Aug 25 08:33:24 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C945A1A000A for ; Mon, 25 Aug 2014 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmt9p2LK35Qt for ; Mon, 25 Aug 2014 08:33:21 -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 9B1CF1A0030 for ; Mon, 25 Aug 2014 08:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5297; q=dns/txt; s=iport; t=1408980788; x=1410190388; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iqOmmuYDLnRfM+JLC9zaYce9NZ93Ap75y6AaeXAOnUY=; b=bQSVHFG8P8t82Jrh5fplV9C+G8ACbrSzZ5BnW3to3JIKQgcY7DixGJu2 FagK6andRMy69saVo9eLPbpr9ZrlEZUFkvS7anl1F8GZ+hstfY3hsIJ0p 4nZocI3SuWn7BOy/HvjmVFEm99uShuAdfZgDj/ov7orBnYAT5TRT2iaak Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAPxW+1OtJV2S/2dsb2JhbABagmojgSAO1CABgSEWd4QEAQEDATo4BwULAgEIIhQQMiUBAQQODYgyCAHAGxePGzEHgy+BHQWPE4IToC+DXoI0gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="346979556" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 25 Aug 2014 15:33:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7PFX7dh007640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 15:33:07 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 10:33:07 -0500 From: "Nobo Akiya (nobo)" To: "Vengada Prasad Govindan (venggovi)" Subject: RE: A few thoughts on S-BFD drafts Thread-Topic: A few thoughts on S-BFD drafts Thread-Index: Ac+98Se65rKjYjyuTDCs3LZOq9i/3QAHo8lQAIzhzdAADFXtcA== Date: Mon, 25 Aug 2014 15:33:07 +0000 Message-ID: References: <315041E4211CB84E86EF7C25A2AB583D346812BC@xmb-rcd-x15.cisco.com> <315041E4211CB84E86EF7C25A2AB583D3468270F@xmb-rcd-x15.cisco.com> In-Reply-To: <315041E4211CB84E86EF7C25A2AB583D3468270F@xmb-rcd-x15.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/_JPuLqRRh-BsGr64raT2a8jiLDI Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:33:23 -0000 Hi Prasad, Thanks for further comments. Snipping out the ones we converged. Note that few minor tweaks are required to S-BFD IP document as result of y= our further comments below, but we will plan to incorporate them later when= we need to re-spin the document. We will likely proceed with the WG adopti= on with S-BFD IP -05. Let us know if you have any concern with this. > Sec 2. S-BFD UDP port: > A minor nit: Should this section be called S-BFD Control UDP port (if it > achieves better clarity) Sounds good. Will update IP/SR documents accordingly. > Sec 4: > Reference to "classical BFD" may need to have a reference cited to RFC > 5880? The term is already defined in S-BFD base document. o Classical BFD - BFD session types based on [RFC5880]. But let me update Introduction section slightly. [OLD] The reader is expected to be familiar with the IP, MPLS BFD and S-BFD terminologies and protocol constructs. [NEW] The reader is expected to be familiar with the IP, MPLS, BFD [RFC5880] and S-BFD [I-D.ietf-bfd-seamless-base] terminologies and protocol constructs. > Sec 7.2: > ---snip--- > o Implementations MUST provide filtering capability based on source > IP addresses of received S-BFD control packets: [RFC2827]. > ---snip--- > A few questions regarding the above text: > 1. How will an implementation demonstrate its capability to support the > above requirement? In other words should this be a mandatory > requirement? I understand that the intent of the requirement is to achiev= e > resource/ equipment protection against DoS attacks. I think it should be stated as mandatory in the document. > 2. Should the section refer to mechanisms like GTSM? GTSM is purposely not mentioned to allow for texts described in Section 5.2= . > > 1. Encapsulation for MPLS based: Do we always assume IP address based > > encapsulation? >=20 > Yes IP/UDP headers are required. When there's a need, a new document > describing GAL/GACh based S-BFD is needed. > GVP1> Would you think that this understanding needs to be recorded in the > document. Perhaps, somewhere in Sec 5. My suggestion is to make the > opening sentence of Sec 5 a mandatory requirement. But I leave it to you = to > decide. Well, the first sentence of Section 5 is: S-BFD control packets are transmitted with IP header, UDP header and BFD control header ([RFC5880]). My thought is that this is sufficient. > > b. For IP multi-hop: This is a difference from RFC 5882. How does > > an intermediate node (unaware of any S-BFD procedure) avoid U-turning > > the S- BFD echo packet? Would it be better to say that S-BFD echo MUST > > NOT be used if the Reflector is more than one hop away? >=20 > This topic should become clearer once we roll out the new revision of dra= ft- > akiya-bfd-seamless-sr, it's almost ready. > GVP1> Just for further understanding, S-BFD echo procedures would work in > single-hop for IPv4 and IPv6. S-BFD echo requires IPv6 or MPLS Segment > Routing dataplanes to work. Is this correct? Segment Routing is the primary driver for the S-BFD echo function. For bi-d= irectional single-hop continuity check, I don't see the need to migrate awa= y from classical BFD sessions IMHO, it is working well. > > 3. Base draft should mention the relationship between S-BFD and P2MP > > BFD (if any). >=20 > The way the document is structured is that we have the base and the > related data plane documents. P2MP is another data plane type, thus IMO, > one should write a new P2MP S-BFD document when P2MP S-BFD is desired. > GVP1> Agreed, it may be help to add a clarifying statement mentioning tha= t > P2MP BFD is outside the scope of the current document. Let's not even mention P2MP, i.e. take similar approach as RFC5881 (which a= lso doesn't mention this). > > 5. Sec 7.3.2 of the base draft: Why should the desired MinTx interval > > be copied from the received packet at the reflector? Can it not be set > > to 0 as the reflector does not originate packets. The Required Min Rx > > can be used to do the rate controlling as specified in the draft. >=20 > You are right, but a counter argument to what you are saying is that > SBFDReflector is sending (or reflecting) S-BFD packets, so one can argue = that > zero(0) may not be an accurate reflection of the behavior. This is someth= ing > we can go with whatever the WG wants (i.e. either way is likely reasonabl= e). > GVP1> Agreed. One could make it a non-zero value based on the packet rate > that can be actually supported by the reflector (note that this can be a = value > less than or equal to the required minRx set by the initiator). This high= lights > one important (in my view at least) difference with respect to classical = BFD. > In classical BFD, while the packet rates in each direction can be asymmet= ric, > the packet rates of S-BFD have to (eventually) be symmetric. In any case = a > copy may not be possible. Some other BFD fields are copied by the SBFDReflector, but not "Required Mi= n Echo RX Interval". o "Required Min Echo RX Interval" SHOULD be set to zero. Let us know if you have any concern with this. Thanks! -Nobo From nobody Tue Aug 26 13:41:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3971A8892; Tue, 26 Aug 2014 13:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.319 X-Spam-Level: X-Spam-Status: No, score=-0.319 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 SS2SmUDHqaXF; Tue, 26 Aug 2014 13:40:59 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFB01A8891; Tue, 26 Aug 2014 13:40:58 -0700 (PDT) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 8640E2AA0F; Tue, 26 Aug 2014 20:40:54 +0000 (GMT) Date: Tue, 26 Aug 2014 13:41:00 -0700 From: Marc Binderberger To: Nobo Akiya (nobo) , Uma Chunduri , Gregory Mirsky , Mach Chen , Hannes Gredler , Les Ginsberg (ginsberg) , Jeffrey Haas Message-ID: <20140826134100782350.a68cbcf3@sniff.de> In-Reply-To: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> Subject: Re: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.15 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/Ms19iSAteDPPZqU6Afetwf1wL7A Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:41:01 -0000 Hello everyone, think I missed some discussions as they showed as "ISIS" WG. So my apology for bringing this up again but ... looking at draft-ginsberg-isis-sbfd-discriminator-00 there is this part in the document: Inclusion of the S-BFD Discriminators sub-TLV in a Router Capability TLV is optional. Multiple S-BFD Discriminators sub-TLVs MAY be advertised by an IS. When multiple S-BFD discriminators are advertised how a given discriminator is mapped to a specific use case is out of scope for this document. There is something right about it, at the same time something is missing, IMHO. How BFD is using the discriminator value(s) is likely something the IS-IS protocol does not want to know; it would create interdependencies and complexity. On the other hand the solution does not provide enough context for each discriminator. For a single discriminator - fine, no choice anyway. But transporting multiple discriminators without context seems "useless" to me. I would have expected a slightly different layout: No. of octets +-----------------------------+ | Type (to be assigned by | 1 | IANA) | +-----------------------------+ | Length (multiple of 8) | 1 +-----------------------------+ | Discriminator Value | 4 per Discriminator | Context Value | 4 (?) per Context : (potentially more pairs of : : Discriminator/Context) : +-----------------------------+ How many bits per Context value can be discussed; I used 32bit due to lack of fantasy ;-) What a "context value" is/means doesn't matter to IS-IS, it just transports it. But the IS-IS clients - be it BFD or BFD clients - can use it. We don't even need to discuss the details of a Context Value within the BFD WG for now but not having any value for administrative purposes seems "jumping short" to me (think communities in BGP, route tags in certain RIB implementations etc.) Again, sorry for commenting with a delay of "only" a few month :-) Regards, Marc On Wed, 21 May 2014 01:24:37 +0000, Nobo Akiya (nobo) wrote: > Thanks for prompt response Greg. > > Will incorporate the text in draft-ietf-...-01. > > -Nobo > >> -----Original Message----- >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >> Sent: Tuesday, May 20, 2014 9:22 PM >> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler >> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org >> Subject: RE: [Isis-wg] New Version Notification for >> draft-ginsberg-isis-sbfd- >> discriminator-00.txt >> >> Hi Nobo, >> I like it. >> >> Regards, >> Greg >> >> -----Original Message----- >> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] >> Sent: Tuesday, May 20, 2014 6:18 PM >> To: Gregory Mirsky; Mach Chen; Hannes Gredler >> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org >> Subject: RE: [Isis-wg] New Version Notification for >> draft-ginsberg-isis-sbfd- >> discriminator-00.txt >> >> Hi Greg, >> >> That's true, the whole paragraph in the section 7 of S-BFD base document is >> just describing some possible implementation techniques. How about we >> change the paragraph: >> >> [old] >> Note that incoming BFD control packets destined to BFD target >> identifier types may be IPv4, IPv6 or MPLS based. For those BFD >> target identifier types, implementations MAY either allow the same >> reflector BFD session to handle all incoming BFD control packets in >> address family agnostic fashion, or setup multiple reflector BFD >> sessions to handle incoming BFD control packets with different >> address families. This policy is again a local matter, and is >> outside the scope of this document. >> >> [new] >> Note that incoming BFD control packets destined to BFD target >> identifier types may be IPv4, IPv6 or MPLS based. How such packets >> reach an appropriate reflector BFD session is a local matter, and is >> outside the scope of this document. >> >> -Nobo >> >>> -----Original Message----- >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] >>> Sent: Tuesday, May 20, 2014 6:46 PM >>> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler >>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org >>> Subject: RE: [Isis-wg] New Version Notification for >>> draft-ginsberg-isis-sbfd- discriminator-00.txt >>> >>> Dear All, >>> according to Section 7 of the S-BFD Base document differentiation >>> among address families by S-BFD is optional and mention in connection >>> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've >>> missed that part of S-BFD Base discussion but I don't see the benefit of >> supporting such mode. >>> BFD control packets been AF-agnostic since RFC 5880 and I think that >>> S-BFD should maintain that approach. >>> >>> I agree with Mach that discriminators in S-BFD, as well as in BFD, are >>> and must remain AF blind. >>> >>> Regards, >>> Greg >>> >>> -----Original Message----- >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo >>> Akiya >>> (nobo) >>> Sent: Thursday, May 15, 2014 7:07 AM >>> To: Mach Chen; Hannes Gredler >>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org >>> Subject: RE: [Isis-wg] New Version Notification for >>> draft-ginsberg-isis-sbfd- discriminator-00.txt >>> >>> Hi Mach, Hannes, et al, >>> >>>> IMHO, the capability issue should not be a S-BFD specific issue, >>>> even not BFD specified issue. It is actually a forwarding capability >>>> issue, it is about whether the target node can process IPv4, IPv6, >>>> MPLS, SR encapsulated BFD packets. >>> >>> I agree Mach, mostly :) >>> >>> I can also see one arguing that forwarding supporting X does not >>> always mean S-BFD is supported on X. If we want to address this, then >>> it is an S-BFD specific issue, and we _may_ want to solve this via >>> introducing S-BFD capability advertisements. >>> >>> With that said, S-BFD discriminator advertisement is one area which >>> the capability problem can be solved, but not necessary a problem that >>> has to be solved with S-BFD discriminator advertisement. Rather I >>> don't think the two should be bundled together. >>> >>> Let us continue the capability discussion separate from the >>> discriminator advertisements? >>> >>> -Nobo >>> > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > From nobody Tue Aug 26 16:52:13 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94A1A0201; Tue, 26 Aug 2014 16:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll2CL_7WgOdU; Tue, 26 Aug 2014 16:52:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D8E1A01F7; Tue, 26 Aug 2014 16:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8800; q=dns/txt; s=iport; t=1409097129; x=1410306729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iNl5m/Ms6sTAU1pJAI/z1w3EjKDJ46lqvPfAfiQfbtY=; b=lWaP5wsEwsno/TebALIGSl5I9HwWIpQAeAuqLO7QduSIBzTan5c1oXUX od3G93GkfoUWCSGm4H/PGNvPd6Jlo0ELKnsyuMgYJtmbm3kbd4NT5BUSw kO8wiwkPS7SFD2+QYRPf5UECu343nkG5bkADH5vBr/m6Q+ya96MaJQb4q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAEkc/VOtJV2T/2dsb2JhbABbgmojU1cEzFAKh0wBgRIWd4QDAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgTiCcBDL9QEwSPGzEHBoMpgR0BBIYTixqgO4IYgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208";a="72656089" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 26 Aug 2014 23:52:08 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7QNq6vN005958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 23:52:06 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 18:52:06 -0500 From: "Les Ginsberg (ginsberg)" To: Marc Binderberger , "Nobo Akiya (nobo)" , Uma Chunduri , Gregory Mirsky , Mach Chen , "Hannes Gredler" , Jeffrey Haas Subject: RE: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Topic: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt Thread-Index: AQHPwW4N06XhmNogNE2vZUS6BLomNJvjaXTw Date: Tue, 26 Aug 2014 23:52:05 +0000 Message-ID: References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <20140514155739.GA14148@juniper.net> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> <20140826134100782350.a68cbcf3@sniff.de> In-Reply-To: <20140826134100782350.a68cbcf3@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.163.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/VzDTr8NGIpJSdUJpvX8sIFd4EFU Cc: "rtg-bfd@ietf.org" , "isis-wg@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 23:52:10 -0000 Marc - No apologies necessary - the draft is still V0 and not yet a WG item. Your = comments are welcome and still timely. That said, we made a conscious decision in both the IS-IS and OSPF drafts t= o stay out of the "application context" space. Despite rumors to the contr= ary, the IGPs are NOT a distribution mechanism for application information.= Their primary purpose is to advertise information necessary for the operat= ion of the routing protocol. It is in fact arguable that we are "crossing t= he line" by advertising S-BFD Discriminators at all - however the fact that= IGPs are a likely S-BFD client as well as the convenience of using the IGP= s makes this compromise seem justifiable.=20 RFC 6823 (GENINFO) is the defined way to advertise application information = using IS-IS. If BFD WG is serious about advertising application context alo= ng with the S-BFD Discriminators then this would be the way forward. That b= rings with it a significant amount of additional specification - so such a = decision needs to be well considered. Les > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Tuesday, August 26, 2014 1:41 PM > To: Nobo Akiya (nobo); Uma Chunduri; Gregory Mirsky; Mach Chen; Hannes > Gredler; Les Ginsberg (ginsberg); Jeffrey Haas > Cc: rtg-bfd@ietf.org; isis-wg@ietf.org > Subject: Re: [Isis-wg] New Version/Proposed isis-wg documents draft- > ginsberg-isis-sbfd-discriminator-00.txt >=20 > Hello everyone, >=20 > think I missed some discussions as they showed as "ISIS" WG. So my apolog= y > for bringing this up again but ... >=20 > looking at draft-ginsberg-isis-sbfd-discriminator-00 there is this part i= n > the document: >=20 >=20 > Inclusion of the S-BFD Discriminators sub-TLV in a Router Capability > TLV is optional. Multiple S-BFD Discriminators sub-TLVs MAY be > advertised by an IS. When multiple S-BFD discriminators are > advertised how a given discriminator is mapped to a specific use case > is out of scope for this document. >=20 >=20 > There is something right about it, at the same time something is missing, > IMHO. >=20 > How BFD is using the discriminator value(s) is likely something the IS-IS > protocol does not want to know; it would create interdependencies and > complexity. >=20 > On the other hand the solution does not provide enough context for each > discriminator. For a single discriminator - fine, no choice anyway. But > transporting multiple discriminators without context seems "useless" to > me. >=20 > I would have expected a slightly different layout: >=20 > No. of octets > +-----------------------------+ > | Type (to be assigned by | 1 > | IANA) | > +-----------------------------+ > | Length (multiple of 8) | 1 > +-----------------------------+ > | Discriminator Value | 4 per Discriminator > | Context Value | 4 (?) per Context > : (potentially more pairs of : > : Discriminator/Context) : > +-----------------------------+ >=20 >=20 > How many bits per Context value can be discussed; I used 32bit due to lac= k > of > fantasy ;-) What a "context value" is/means doesn't matter to IS-IS, it = just > transports it. But the IS-IS clients - be it BFD or BFD clients - can use= it. >=20 > We don't even need to discuss the details of a Context Value within the B= FD > WG for now but not having any value for administrative purposes seems > "jumping short" to me (think communities in BGP, route tags in certain RI= B > implementations etc.) >=20 >=20 > Again, sorry for commenting with a delay of "only" a few month :-) >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 >=20 >=20 > On Wed, 21 May 2014 01:24:37 +0000, Nobo Akiya (nobo) wrote: > > Thanks for prompt response Greg. > > > > Will incorporate the text in draft-ietf-...-01. > > > > -Nobo > > > >> -----Original Message----- > >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >> Sent: Tuesday, May 20, 2014 9:22 PM > >> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > >> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > >> Subject: RE: [Isis-wg] New Version Notification for > >> draft-ginsberg-isis-sbfd- > >> discriminator-00.txt > >> > >> Hi Nobo, > >> I like it. > >> > >> Regards, > >> Greg > >> > >> -----Original Message----- > >> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] > >> Sent: Tuesday, May 20, 2014 6:18 PM > >> To: Gregory Mirsky; Mach Chen; Hannes Gredler > >> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > >> Subject: RE: [Isis-wg] New Version Notification for > >> draft-ginsberg-isis-sbfd- > >> discriminator-00.txt > >> > >> Hi Greg, > >> > >> That's true, the whole paragraph in the section 7 of S-BFD base docume= nt > is > >> just describing some possible implementation techniques. How about > we > >> change the paragraph: > >> > >> [old] > >> Note that incoming BFD control packets destined to BFD target > >> identifier types may be IPv4, IPv6 or MPLS based. For those BFD > >> target identifier types, implementations MAY either allow the same > >> reflector BFD session to handle all incoming BFD control packets in > >> address family agnostic fashion, or setup multiple reflector BFD > >> sessions to handle incoming BFD control packets with different > >> address families. This policy is again a local matter, and is > >> outside the scope of this document. > >> > >> [new] > >> Note that incoming BFD control packets destined to BFD target > >> identifier types may be IPv4, IPv6 or MPLS based. How such packets > >> reach an appropriate reflector BFD session is a local matter, and i= s > >> outside the scope of this document. > >> > >> -Nobo > >> > >>> -----Original Message----- > >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > >>> Sent: Tuesday, May 20, 2014 6:46 PM > >>> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler > >>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > >>> Subject: RE: [Isis-wg] New Version Notification for > >>> draft-ginsberg-isis-sbfd- discriminator-00.txt > >>> > >>> Dear All, > >>> according to Section 7 of the S-BFD Base document differentiation > >>> among address families by S-BFD is optional and mention in connection > >>> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I'v= e > >>> missed that part of S-BFD Base discussion but I don't see the benefit= of > >> supporting such mode. > >>> BFD control packets been AF-agnostic since RFC 5880 and I think that > >>> S-BFD should maintain that approach. > >>> > >>> I agree with Mach that discriminators in S-BFD, as well as in BFD, ar= e > >>> and must remain AF blind. > >>> > >>> Regards, > >>> Greg > >>> > >>> -----Original Message----- > >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo > >>> Akiya > >>> (nobo) > >>> Sent: Thursday, May 15, 2014 7:07 AM > >>> To: Mach Chen; Hannes Gredler > >>> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org > >>> Subject: RE: [Isis-wg] New Version Notification for > >>> draft-ginsberg-isis-sbfd- discriminator-00.txt > >>> > >>> Hi Mach, Hannes, et al, > >>> > >>>> IMHO, the capability issue should not be a S-BFD specific issue, > >>>> even not BFD specified issue. It is actually a forwarding capability > >>>> issue, it is about whether the target node can process IPv4, IPv6, > >>>> MPLS, SR encapsulated BFD packets. > >>> > >>> I agree Mach, mostly :) > >>> > >>> I can also see one arguing that forwarding supporting X does not > >>> always mean S-BFD is supported on X. If we want to address this, then > >>> it is an S-BFD specific issue, and we _may_ want to solve this via > >>> introducing S-BFD capability advertisements. > >>> > >>> With that said, S-BFD discriminator advertisement is one area which > >>> the capability problem can be solved, but not necessary a problem tha= t > >>> has to be solved with S-BFD discriminator advertisement. Rather I > >>> don't think the two should be bundled together. > >>> > >>> Let us continue the capability discussion separate from the > >>> discriminator advertisements? > >>> > >>> -Nobo > >>> > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > From nobody Thu Aug 28 08:29:04 2014 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9C1A030A; Thu, 28 Aug 2014 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.168 X-Spam-Level: X-Spam-Status: No, score=-13.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDtdGBpeqD9G; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C96D1A06FC; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29477; q=dns/txt; s=iport; t=1409239473; x=1410449073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UUaWlJnTkIdT2jpeN2ooo6VAdPLfWpG3/ZUrZmZ7C7o=; b=haYGHHnGj4B1Y2Tx04CiPsMf2sKsQxzuhGAmkkvXrElFO6Ra94bOS4kG Ixc5ncHRZAYdoLggiZwDsm7CGKbmDBFuh2tpXZUkyqR0ctCz4DaFZjEsQ SlLkPv3Szn64ip29nnzxCJdyT1A+W37xaLUC3Jhge7MjN4QaQQTvbgU1G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACFJ/1OtJV2R/2dsb2JhbABbgkdGU1cE03YBgRkWd4QDAQEBBC05DAcQAgEIEQEDAQELFgcHMhQDBggBAQQBDQUIE4gnv0oXjnQnMQYBgy+BHQWRL6BIg15sgQYCHgYcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208,217";a="351062464" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 15:24:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFOF8Q007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:24:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:24:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: Gregory Mirsky , "'draft-tissa-netmod-oam@tools.ietf.org'" Subject: RE: draft-tissa-netmod-oam Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1w Date: Thu, 28 Aug 2014 15:24:14 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.14.1] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/dow_Gm1Cr2GYa3sUOEzwyPUbOGg X-Mailman-Approved-At: Thu, 28 Aug 2014 08:29:00 -0700 Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 15:24:39 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_--