From nobody Mon Feb 4 10:25:23 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17038130EE2; Mon, 4 Feb 2019 10:25:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: rtg-bfd@ietf.org, ipr-announce@ietf.org Subject: IPR Disclosure Juniper's Statement about IPR related to draft-ietf-bfd-base X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154930471708.28619.10460178548250721289@ietfa.amsl.com> Date: Mon, 04 Feb 2019 10:25:17 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 18:25:17 -0000 Dear Dave Katz, David Ward: An IPR disclosure that pertains to your RFC entitled "Bidirectional Forwarding Detection (BFD)" (RFC5880) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3416/). The title of the IPR disclosure is "Juniper's Statement about IPR related to draft-ietf-bfd-base" Thank you IETF Secretariat From nobody Wed Feb 6 08:56:29 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1B112F1AC for ; Wed, 6 Feb 2019 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-MsfvONL1Oq for ; Wed, 6 Feb 2019 08:56:25 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAD9130934 for ; Wed, 6 Feb 2019 08:56:25 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id r10-v6so974445ljj.4 for ; Wed, 06 Feb 2019 08:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ea4GtiFAqTUaJRobPZmyT2ty1tzSInW+zgKq0a0gUPk=; b=dlRlhnJN1Tlx4Df5U4d/X16WiGcNR4R0GGV6m0qZqqAwla7wbfTr6pBA2h3Pavit7k /NG1UJ120hicBv5BvrkSlBciFHGKy8q/tx9NL4wP/igG3zeASr8+4m15L1IWU9XIKwj6 yIo3HKDduPdFqaUjS7sKrNEFFrIagNQnmtmIPDIqIBKMuZlkHiit5ep3A2Gp/eDUSc2v h2SaH6nVLch7MVLX3TIggqfXsHIf7fVZutDri6JwmdNi0tWf97S+wVyWjOEXP6SU0vKk t47ylnfJtIDzPJ4OboK36lrwXNJ2CjMOECbBVi0l9f4DhqZakmlkL1TJEpmrjh1Bq58f Tuyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ea4GtiFAqTUaJRobPZmyT2ty1tzSInW+zgKq0a0gUPk=; b=fnXuSZUOt/41pDjB9Y7YDqkAa76pSvoTgLMUD8fNAYkat+Pymxo48Hri3wp5zgAN23 hED8bqBBeSSqRXXkJ6Fv9rzYmofn43WHTYrhwN/c0dbVgF2JOsxS2IEL0acSLxuzivPn uEZCRUxS7oKD2KoLbajYbzPcGeTzpmcGeoeRWX2IMfqRHv+M9ttk20EkT6rnMEs3somi Jk5m1wd0We/HDI247MJoFuZGBKIFeyQSTJ6VU9Wmbqk4helon15bUD5PimfeiXQE64kr jZRHcmFxUHTEDo5nrPk+YWR0GWGMG1F9kL+EtqWx+lGz+rIfreRVNrrzcT6TxQ3X35bW BTzQ== X-Gm-Message-State: AHQUAubFdUQP6hQtjiLDgcKw+rlPoDwhV35QQaZOgzsfdZDIN3sqU2mp bjcQ7gSfXOOPcEDf6DT9rJb+YNZjMmatxn5Ex5c= X-Google-Smtp-Source: AHgI3IYt8pP3nD29ONFs2whE+q+AFvVpStZaMQVJlPs69Itfcj2NvRYBk14Hygnl0F8sIKAOQJlFWHvAvTl9byYlehI= X-Received: by 2002:a2e:6a13:: with SMTP id f19-v6mr7090416ljc.41.1549472183258; Wed, 06 Feb 2019 08:56:23 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> In-Reply-To: <20181210220953.GA6053@pfrc.org> From: Greg Mirsky Date: Wed, 6 Feb 2019 08:56:12 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: rtg-bfd WG Content-Type: multipart/alternative; boundary="00000000000012924105813c9bd5" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 16:56:28 -0000 --00000000000012924105813c9bd5 Content-Type: text/plain; charset="UTF-8" Hi Jeff, Reshad, et al., now I can confirm that the IPR licensing terms to this draft were updated by this IPR Disclosure submitted on December 11, 2018. Much appreciate your consideration and welcome technical comments on the draft. Regards, Greg On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas wrote: > Greg, > > Apologies for the long delay in reply. > > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: > > I respectfully ask to summarize the comments that were shared with you > and > > to publish them to the WG without naming the authors. > > Tersely: > - The document is not addressing fundamental issues. > - It is encumbered by IPR. > - Observed list traffic regarding question on the feature was not > satisfactorily converging. > > > And I have to admit that I don't understand your suggestion to use the > > Errata. The procedures to apply the Demand mode described in the draft > are > > not in contradiction with RFC 5880, so the suggestion to use Errata > > surprised me. > > I will respond on my own analysis in detail hopefully this week. I am > awaiting the resolution of a particular bit of correspondence before > determining the tenor of my response. > > -- Jeff > --00000000000012924105813c9bd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff, Reshad, et al.,
now I can confirm that the IP= R licensing terms to this draft were updated by this IPR Disclosure submitted on December 11, 2= 018. Much appreciate your consideration and welcome technical comments on t= he draft.

Regards,
Greg

<= div class=3D"gmail_quote">
On Mon, Dec= 10, 2018 at 2:10 PM Jeffrey Haas <jha= as@pfrc.org> wrote:
Greg,

Apologies for the long delay in reply.=C2=A0

On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
> I respectfully ask to summarize the comments that were shared with you= and
> to publish them to the WG without naming the authors.

Tersely:
- The document is not addressing fundamental issues.
- It is encumbered by IPR.
- Observed list traffic regarding question on the feature was not
=C2=A0 satisfactorily converging.

> And I have to admit that I don't understand your suggestion to use= the
> Errata. The procedures to apply the Demand mode described in the draft= are
> not in contradiction with RFC 5880, so the suggestion to use Errata > surprised me.

I will respond on my own analysis in detail hopefully this week.=C2=A0 I am=
awaiting the resolution of a particular bit of correspondence before
determining the tenor of my response.

-- Jeff
--00000000000012924105813c9bd5-- From nobody Thu Feb 14 08:40:35 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9401200D7; Wed, 13 Feb 2019 07:28:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "=?utf-8?q?Ole_Tr=C3=B8an?=" , "Ron Bonica" , "Reshad Rahman" , "Bill Cerveny" , "Jeffrey Haas" , "Chris Bowers" , "Bob Hinden" , "Brian Trammell" , "Jeff Tantsura" , "Tommy Pauly" , "Fred Baker" Cc: Deborah Brungard , Bidirectional Forwarding Detection Discussion List , =?utf-8?q?Mirja_K=C3=BChlewind?= , Bob Hinden , Jeff Tantsura , Fred Baker , Ron Bonica , Ignas Bagdonas , Bill Cerveny , Warren Kumari , Martin Vigoureux , Brian Trammell , IPv6 Maintenance Discussion List , IPv6 Operations Discussion List , Terry Manderson , =?utf-8?q?Ole_Tr=C3=B8an?= , rraghu@ciena.com, Tommy Pauly , Raghu Ranganathan , Reshad Rahman , Jeffrey Haas , Chris Bowers , IP Performance Measurement Discussion List , Alvaro Retana , Spencer Dawkins , Routing Area Working Group Discussion List , Suresh Krishnan Subject: New Liaison Statement, "Status of MEF IP Services Projects" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155007172917.9348.7524674738392964663.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2019 07:28:49 -0800 Archived-At: X-Mailman-Approved-At: Thu, 14 Feb 2019 08:40:34 -0800 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:28:50 -0000 Title: Status of MEF IP Services Projects Submission Date: 2019-02-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1628/ From: Liaison Mef To: Jeffrey Haas ,Reshad Rahman ,Chris Bowers ,Jeff Tantsura ,Ron Bonica ,Fred Baker ,Brian Trammell ,Bill Cerveny ,Tommy Pauly ,Bob Hinden ,Ole Trøan Cc: Jeffrey Haas ,Bidirectional Forwarding Detection Discussion List ,Bob Hinden ,Deborah Brungard ,Jeff Tantsura ,Fred Baker ,Ron Bonica ,Terry Manderson ,Alvaro Retana ,Bill Cerveny ,Warren Kumari ,Martin Vigoureux ,Brian Trammell ,IPv6 Maintenance Discussion List ,IPv6 Operations Discussion List ,Ignas Bagdonas ,Tommy Pauly ,Raghu Ranganathan ,Reshad Rahman ,Ole Trøan ,Chris Bowers ,IP Performance Measurement Discussion List ,Mirja Kühlewind ,Spencer Dawkins ,Routing Area Working Group Discussion List ,Suresh Krishnan Response Contacts: rraghu@ciena.com Technical Contacts: Purpose: For information Body: Following the previous liaisons between our organizations, we would like to provide an update on the status of the active projects in MEF that relate to IP Services. There are four active projects: IP Service Attributes. This project is defining the generic Service Attributes that are agreed between the provider and user of an IP Service, to describe the service being provided. MEF 61, covering Service Attributes for Subscriber IP Services (for end users), was published in April 2018. We have since been working on a revision to this standard, to add support for wholesale IP Services between Operators. An Approved Draft of the revision was included in an earlier liaison, and a Letter Ballot (final approval) has now been initiated. Publication of the revision is expected in Q2 2019. IP Service Definitions. This project is defining a number of specific IP Services, based on the Service Attributes defined in MEF 61. The initial phase is focusing on two forms of Internet Access Service: Consumer-grade Internet Access, and Commercial-grade Internet Access. A later phase will also define one or more IP-VPN Services. A Letter Ballot (final approval) on the first phase is expected to be initiated in April 2019, with publication to follow in the Summer. Service OAM for IP Services. This project is defining how Fault Management and Performance Monitoring can be performed for IP Services (based on techniques and protocols defined in IETF). Fault Management is based on ping, traceroute, and BFD. Performance Monitoring is based on TWAMP, TWAMP-light and STAMP. The initial phase is focusing on Subscriber IP Services, and a Draft Standard release of this document is available on the MEF public web site (see below). We would welcome any comments you have on this Draft Standard. A Letter Ballot (final approval) is expected to be initiated in April 2019, therefore we would request that you send any comments by the end of March 2019. Service Activation Testing for IP Services. This project is defining a methodology for Service Activation Testing of IP Services. The initial phase again focuses on Subscriber IP Services, based on the Service Attributes in MEF 61. A later phase will cover IP Services between Operators. A Draft Standard for review is expected to be available in Spring 2019. Note that MEF has replaced our previous mechanism of "Approved Drafts", which were shared only with liaison partners and could be accessed using a username and password, with a mechanism of Draft Standards, which are published on the MEF web site. Current Draft Standards can be found at https://www.mef.net/draft-standards. Published MEF Standards can be found, as always, at https://www.mef.net/resources/technical-specifications. The forthcoming MEF meetings are: 29 April - 2 May, 2019 - Dubrovnik, Croatia 29 July - 1 August, 2019 - North America Attachments: No document has been attached From nobody Sat Feb 16 08:33:04 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951AF130F04 for ; Sat, 16 Feb 2019 08:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F__EW6QlIxdu for ; Sat, 16 Feb 2019 08:33:00 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A54BF130EFF for ; Sat, 16 Feb 2019 08:33:00 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4A80F1E2D8; Sat, 16 Feb 2019 11:31:55 -0500 (EST) Date: Sat, 16 Feb 2019 11:31:55 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190216163154.GC28950@pfrc.org> References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 16:33:03 -0000 Greg, On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote: > Hi Jeff, Reshad, et al., > now I can confirm that the IPR licensing terms to this draft were updated > by this IPR Disclosure submitted > on December 11, 2018. Much appreciate your consideration and welcome > technical comments on the draft. Thanks for the update on the IPR declaration. It's good to see that the terms of the licensing have shifted such that open source implementations would be able to be done. I'll note that we're still in that limbo phase wherein it's not possible for the Working Group, or holders of IPR against the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is distinct vs. previously published IPR declarations. And my apologies for not providing my technical comments more quickly. The last month and a half has been particularly challenging at the day job. (Englightening, but challenging.) draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profile against which BFD, in a MPLS network, can use demand mode. What I (and some others) have found puzzling is why there's any perceived need for this document. Working through your document beginning in section 3: - It is pointed out that demand mode exists. Its procedures are documented as part of the core BFD RFC 5880. - It points out in the case of MPLS as a transport that LSP Ping is necessary to bootstrap the BFD session. These procedures are defined in RFC 5884. - It points out that we can shift to demand mode. Again, this procedure is documented in RFC 5880; see section 6.6. - It points out that we can test liveness using a poll sequence. Again, this procedure is documented in third paragaph of section 6.6 in RFC 5880. - The procedures for declaring a session down when in demand mode and a poll sequence is in progress is covered in paragraph 6 of section 6.8.4 of RFC 5880. - The procedure for a down system reporting its state once per second is covered by paragraph 5 of section 6.8.3 of RFC 5880. I don't believe I agree with your procedure that a system in demand mode must initiate a poll sequence to declare that it is down. Am I missing something? -- Jeff > > Regards, > Greg > > On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas wrote: > > > Greg, > > > > Apologies for the long delay in reply. > > > > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: > > > I respectfully ask to summarize the comments that were shared with you > > and > > > to publish them to the WG without naming the authors. > > > > Tersely: > > - The document is not addressing fundamental issues. > > - It is encumbered by IPR. > > - Observed list traffic regarding question on the feature was not > > satisfactorily converging. > > > > > And I have to admit that I don't understand your suggestion to use the > > > Errata. The procedures to apply the Demand mode described in the draft > > are > > > not in contradiction with RFC 5880, so the suggestion to use Errata > > > surprised me. > > > > I will respond on my own analysis in detail hopefully this week. I am > > awaiting the resolution of a particular bit of correspondence before > > determining the tenor of my response. > > > > -- Jeff > > From nobody Sat Feb 16 09:08:49 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A1A130F04 for ; Sat, 16 Feb 2019 09:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlaqB9H8xzIT for ; Sat, 16 Feb 2019 09:08:46 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE9130F02 for ; Sat, 16 Feb 2019 09:08:46 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 924871E2D8; Sat, 16 Feb 2019 12:07:40 -0500 (EST) Date: Sat, 16 Feb 2019 12:07:40 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Progressing BFD authentication documents Message-ID: <20190216170740.GA31558@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:08:48 -0000 Working Group, On March 28, 2018, we started Working Group Last Call on the following document bundle: draft-ietf-bfd-secure-sequence-numbers draft-ietf-bfd-optimizing-authentication draft-ietf-bfd-stability The same day, Mahesh Jethanandani acknowledged there was pending IPR declarations against these drafts. An IPR declaration was finally posted on November 1, 2018. In particular, it notes a patent. The licenseing is RAND. https://datatracker.ietf.org/ipr/3328/ In the time since the WGLC was requested, there were a number of technical comments made on these drafts. It's my belief that all substantial technical comments had been addressed in the last posted version of these documents. Note that there was one lingering comment about Yang considerations for the BFD module with regard to enabling this optimized authentication mode which can be dealt with separably. The chairs did not carry out a further consensus call to ensure that there are no further outstanding technical issues. On November 21, Greg Mirsky indicated an objection to progressing the document due to late disclosure. https://mailarchive.ietf.org/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtDo Since we are a little over a month prior to the upcoming IETF 104, this seems a good time to try to decide how the Working Group shall finish this work. Since we are meeting in Prague, this may progress to microphone conversation. For the moment, the chairs' perceived status of the documents are: - No pending technical issues with the documents with one known issue. - Concerns over late disclosure of IPR. - No solid consensus from the Working Group that we're ready to proceed. This part may be covered by a future consensus call, but let's hear list discussion first. -- Jeff From nobody Sat Feb 16 09:10:41 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5F6130F04 for ; Sat, 16 Feb 2019 09:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxtQa-b9Ogw7 for ; Sat, 16 Feb 2019 09:10:38 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C61D112008F for ; Sat, 16 Feb 2019 09:10:38 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id BB9F11E2D8; Sat, 16 Feb 2019 12:09:33 -0500 (EST) Date: Sat, 16 Feb 2019 12:09:33 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Call for presentations, IETF 104 - Prague Message-ID: <20190216170933.GE28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:10:40 -0000 Working Group, We will be meeting in Prague for IETF 104. We're currently a little over a month out from the meeting. Please send a request to the chairs for timeslots for our session. -- Jeff From nobody Sat Feb 16 09:22:54 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619A0130F1B for ; Sat, 16 Feb 2019 09:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGx5GaEiy4iP for ; Sat, 16 Feb 2019 09:22:51 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE3F130F04 for ; Sat, 16 Feb 2019 09:22:50 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id g80so10974352ljg.6 for ; Sat, 16 Feb 2019 09:22:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DPTFCWEPQyQ5L4gSkcqnbvctbaSnofFoyZNgj/gJ+Cw=; b=uSun6bCxaGj3lKaVdSRoPc08irhtzx/E0xO1JfuPxoWdScqomxMswYrIKkPvr5zhCA 3pXPiSwVVOO4885BLa+uOrBCFb7SCAlnDo5Fi5xIbJa2gSFl81J1h94oEdYhpKLucmzh Q/WpyJp2xmKFSXEJ4YmQXszxUOPiGnCj4tLj1Yw7gJCbXSBoIo0zHXC3S9b71rAoLeOm RKAeiwilAK+jPV6qAijahCGgZR3+/rUlCgUTR6Q0A1pyC/ncZsxy9HEneTQgpbvE3oYi +vvKjhSK/PdRt/3x2gCPI4xPmE6VRh9vJuEDC3SLP+55x+guoMMSHAKvyfH9DVbAJszu NUwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DPTFCWEPQyQ5L4gSkcqnbvctbaSnofFoyZNgj/gJ+Cw=; b=NPUoPDndh78vXsgMe3nj2QcqA/pEN9r/G7NJcTsnDlLot/XtlgmAFIg1rODjXMKb/x XzITKYXeN1edHQOPot5kLILxFuV3q6aLvOieFGNEI0HDWRrQn5B0sOjekKh7CaLkVZt4 qxmPHA/7dnRTQVCFcD0ojDUmpXkwG3ckJlJemd32lkxutga1u1RGuliRg1CnnRb1oPYV leZsSFo5yzbnVfHDwkN+PL65G92tcMVwkkZoxl8x67uZL6dVN22k8kV1anUSVA/8DTHf 6TFvsrzlPu0loMa99bZh34ApjTjdIZPzPjyNdY6D90Nry0kS5Ia3rEwbGTR7cxAazBFy hX+w== X-Gm-Message-State: AHQUAuafO1TogayjMT2MOgwQT4AHbVcnVz+gMzXffi9wbxglWycEea3J h6y3SPUxDtcLIfyiWQgcYEbJ50/iEP/PjG/5h5p2Tg== X-Google-Smtp-Source: AHgI3IZXrSdYNsTdx0W9/gqs0ol9wzJgUtSByxfqFQwjbqMbpR35lR6kv7Gf4/tZx8dt0xZNCpmxN6a2qhmfk7uVvuw= X-Received: by 2002:a2e:424f:: with SMTP id p76mr1684240lja.140.1550337768690; Sat, 16 Feb 2019 09:22:48 -0800 (PST) MIME-Version: 1.0 References: <20190216170740.GA31558@pfrc.org> In-Reply-To: <20190216170740.GA31558@pfrc.org> From: Greg Mirsky Date: Sat, 16 Feb 2019 09:22:37 -0800 Message-ID: Subject: Re: Progressing BFD authentication documents To: Jeffrey Haas Cc: rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000fc188f0582062355" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:22:53 -0000 --000000000000fc188f0582062355 Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for the clear and concise summary. I need to note that my concerns are not only with how late the IPR Disclosure was made but, I want to stress, with the licensing terms set forth by the holder of IPR that allow for possible request of royalties from an implementor. Regards, Greg On Sat, Feb 16, 2019 at 9:08 AM Jeffrey Haas wrote: > Working Group, > > On March 28, 2018, we started Working Group Last Call on the following > document > bundle: > > draft-ietf-bfd-secure-sequence-numbers > draft-ietf-bfd-optimizing-authentication > draft-ietf-bfd-stability > > The same day, Mahesh Jethanandani acknowledged there was pending IPR > declarations against these drafts. An IPR declaration was finally posted > on > November 1, 2018. In particular, it notes a patent. The licenseing is > RAND. > > https://datatracker.ietf.org/ipr/3328/ > > In the time since the WGLC was requested, there were a number of technical > comments made on these drafts. It's my belief that all substantial > technical comments had been addressed in the last posted version of these > documents. Note that there was one lingering comment about Yang > considerations for the BFD module with regard to enabling this optimized > authentication mode which can be dealt with separably. > > The chairs did not carry out a further consensus call to ensure that there > are no further outstanding technical issues. > > On November 21, Greg Mirsky indicated an objection to progressing the > document due to late disclosure. > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtDo > > Since we are a little over a month prior to the upcoming IETF 104, this > seems a good time to try to decide how the Working Group shall finish this > work. Since we are meeting in Prague, this may progress to microphone > conversation. > > For the moment, the chairs' perceived status of the documents are: > - No pending technical issues with the documents with one known issue. > - Concerns over late disclosure of IPR. > - No solid consensus from the Working Group that we're ready to proceed. > This part may be covered by a future consensus call, but let's hear list > discussion first. > > -- Jeff > > --000000000000fc188f0582062355 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for the clear and concise summary. = I need to note that my concerns are not only with how late the IPR Disclosu= re was made but, I want to stress, with the licensing terms set forth by th= e holder of IPR that allow for possible request of royalties from an implem= entor.

Regards,
Greg

On Sat, Feb 16= , 2019 at 9:08 AM Jeffrey Haas <jhaas@= pfrc.org> wrote:
Working Group,

On March 28, 2018, we started Working Group Last Call on the following docu= ment
bundle:

=C2=A0 draft-ietf-bfd-secure-sequence-numbers
=C2=A0 draft-ietf-bfd-optimizing-authentication
=C2=A0 draft-ietf-bfd-stability

The same day, Mahesh Jethanandani acknowledged there was pending IPR
declarations against these drafts.=C2=A0 An IPR declaration was finally pos= ted on
November 1, 2018.=C2=A0 In particular, it notes a patent.=C2=A0 The license= ing is
RAND.=C2=A0

https://datatracker.ietf.org/ipr/3328/

In the time since the WGLC was requested, there were a number of technical<= br> comments made on these drafts.=C2=A0 It's my belief that all substantia= l
technical comments had been addressed in the last posted version of these documents.=C2=A0 Note that there was one lingering comment about Yang
considerations for the BFD module with regard to enabling this optimized authentication mode which can be dealt with separably.

The chairs did not carry out a further consensus call to ensure that there<= br> are no further outstanding technical issues.

On November 21, Greg Mirsky indicated an objection to progressing the
document due to late disclosure.

https://mailarchive.ietf.or= g/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtDo

Since we are a little over a month prior to the upcoming IETF 104, this
seems a good time to try to decide how the Working Group shall finish this<= br> work.=C2=A0 Since we are meeting in Prague, this may progress to microphone=
conversation.

For the moment, the chairs' perceived status of the documents are:
- No pending technical issues with the documents with one known issue.
- Concerns over late disclosure of IPR.
- No solid consensus from the Working Group that we're ready to proceed= .
=C2=A0 This part may be covered by a future consensus call, but let's h= ear list
=C2=A0 discussion first.

-- Jeff

--000000000000fc188f0582062355-- From nobody Sat Feb 16 09:38:25 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21A9130F05 for ; Sat, 16 Feb 2019 09:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llyVwCExHZ7j for ; Sat, 16 Feb 2019 09:38:21 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4923A130D7A for ; Sat, 16 Feb 2019 09:38:21 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id j13-v6so11030880ljc.2 for ; Sat, 16 Feb 2019 09:38:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cLKDNUCWPoFhE7tiM8S+0FpmHUuIkKxBSz0rBpcJHpU=; b=dVL8YIRf30tx3NS1HdwBxjAQIVn2QiHmXsRNODm9tQYb6OUhG3cJIy0NuxgWbYhBmF qvUAVs1ZWq5ODJOUGJPPsB/qm8NOzc6ersqZSioa75wxkSRjCn0Gh0EXePzziLTcY3iu is5M38ouBAcgr3LGF3oICA6x/gxvlvEPw+y8lk6ZKAJu5UNUcVUi2kfgoO9nRW55fft8 D6INbo9JuNiFdLFDxPXztfCzwoFkx4GgIrPdGbL5LhOdeHx1UHSmKf1HRKW5ulnG9FmZ DpT65vKYZsjRGmWuTUU62bQi2U90/I2uXpAKcAeOGisF3HS/8/KUtOi/XNQOcgibGIMj EcAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cLKDNUCWPoFhE7tiM8S+0FpmHUuIkKxBSz0rBpcJHpU=; b=EyhxN4BSzt+EUk2vng7LV0FPgirM5qbqldxcsLq+87JJzNGBaO18GSvx9toDKWOaWH YnqgmcNpiYc1WeXpvOFtRnaK+bqUK3By5rTxisM5wegLgpWVrwM7kvxYcZmbQ/aOSaXJ JrAKFqmBfpce297jsvfKl0us4qpAEvOhEGkVBlxJRmVRe6rusNjYrWb9jbZfVQURXoS0 cLGiLUEq2+1jUz6aU6IthvYaFa0fj77mEf0QC5nHqHJ1kx3ktEb4Ld2JIrY8zMxsDSac qGFMO7WUqKIMTkIjp3MsAx1CiqVU8PKUKMhT20Hya5vZmL/wQIrZKtCpLgWYC3wgDcLw s/gw== X-Gm-Message-State: AHQUAuZlsA8Fzf42ChlUQJLbLe+S8gRZqLk+pq0eMjLIpWiCmODUSun1 DaauB7CTcAEnTGfTJ6hCSmAz+8Dy+LIcRn/sv44= X-Google-Smtp-Source: AHgI3IbQcy5ZHES2rj/+whWnS96wnsyB7Gswu7O0Bu2jfnlWmnkJ9KcB7uvhmcFQAcoXY9Hqa0gjA8Lvt47f/UgZYYQ= X-Received: by 2002:a2e:424f:: with SMTP id p76mr1711520lja.140.1550338699292; Sat, 16 Feb 2019 09:38:19 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> In-Reply-To: <20190216163154.GC28950@pfrc.org> From: Greg Mirsky Date: Sat, 16 Feb 2019 09:38:08 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: rtg-bfd WG Content-Type: multipart/alternative; boundary="00000000000073f4b60582065b9e" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:38:24 -0000 --00000000000073f4b60582065b9e Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for your detailed analysis of the mechanism proposed in the draft. I've in-lined one question and one note under tag GIM>>. Regards, Greg On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas wrote: > Greg, > > On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote: > > Hi Jeff, Reshad, et al., > > now I can confirm that the IPR licensing terms to this draft were updated > > by this IPR Disclosure > submitted > > on December 11, 2018. Much appreciate your consideration and welcome > > technical comments on the draft. > > Thanks for the update on the IPR declaration. It's good to see that the > terms of the licensing have shifted such that open source implementations > would be able to be done. I'll note that we're still in that limbo phase > wherein it's not possible for the Working Group, or holders of IPR against > the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is > distinct vs. previously published IPR declarations. > GIM>> My understanding of the legal side of IPR Disclosures is that the last overwrites, including in regard to the licensing terms, previous disclosures. > > And my apologies for not providing my technical comments more quickly. The > last month and a half has been particularly challenging at the day job. > (Englightening, but challenging.) > > draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profile > against which BFD, in a MPLS network, can use demand mode. What I (and > some > others) have found puzzling is why there's any perceived need for this > document. > > Working through your document beginning in section 3: > - It is pointed out that demand mode exists. Its procedures are documented > as part of the core BFD RFC 5880. > - It points out in the case of MPLS as a transport that LSP Ping is > necessary to bootstrap the BFD session. These procedures are defined in > RFC 5884. > - It points out that we can shift to demand mode. Again, this procedure is > documented in RFC 5880; see section 6.6. > - It points out that we can test liveness using a poll sequence. Again, > this procedure is documented in third paragaph of section 6.6 in RFC > 5880. > - The procedures for declaring a session down when in demand mode and a > poll > sequence is in progress is covered in paragraph 6 of section 6.8.4 of RFC > 5880. > - The procedure for a down system reporting its state once per second is > covered by paragraph 5 of section 6.8.3 of RFC 5880. I don't believe I > agree with your procedure that a system in demand mode must initiate a > poll > sequence to declare that it is down. > GIM>> The behavior of the system in Demand mode is introduced as optional. And that is precisely the update to RFC 5880. > > Am I missing something? > > -- Jeff > > > > > Regards, > > Greg > > > > On Mon, Dec 10, 2018 at 2:10 PM Jeffrey Haas wrote: > > > > > Greg, > > > > > > Apologies for the long delay in reply. > > > > > > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote: > > > > I respectfully ask to summarize the comments that were shared with > you > > > and > > > > to publish them to the WG without naming the authors. > > > > > > Tersely: > > > - The document is not addressing fundamental issues. > > > - It is encumbered by IPR. > > > - Observed list traffic regarding question on the feature was not > > > satisfactorily converging. > > > > > > > And I have to admit that I don't understand your suggestion to use > the > > > > Errata. The procedures to apply the Demand mode described in the > draft > > > are > > > > not in contradiction with RFC 5880, so the suggestion to use Errata > > > > surprised me. > > > > > > I will respond on my own analysis in detail hopefully this week. I am > > > awaiting the resolution of a particular bit of correspondence before > > > determining the tenor of my response. > > > > > > -- Jeff > > > > --00000000000073f4b60582065b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for your detailed = analysis of the mechanism proposed in the draft. I've in-lined one ques= tion and one note under tag GIM>>.=C2=A0

Reg= ards,
Greg

On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <= jhaas@pfrc.org> wrote:
Greg,

On Wed, Feb 06, 2019 at 08:56:12AM -0800, Greg Mirsky wrote:
> Hi= Jeff, Reshad, et al.,
> now I can confirm that the IPR licensing ter= ms to this draft were updated
> by this IPR Disclosure <https://datatracker.ietf.org/ipr/3359/> submitted
> on Dece= mber 11, 2018. Much appreciate your consideration and welcome
> techn= ical comments on the draft.

Thanks for the update on the IPR declaration.=C2=A0 It's good to se= e that the
terms of the licensing have shifted such that open source imp= lementations
would be able to be done.=C2=A0 I'll note that we'r= e still in that limbo phase
wherein it's not possible for the Workin= g Group, or holders of IPR against
the impacted RFCs 5880, 5883, and 588= 4, know what is being asserted that is
distinct vs. previously published= IPR declarations.
GIM>> My understanding of the= legal side of IPR Disclosures is that the last overwrites, including in re= gard to the licensing terms, previous disclosures.=C2=A0

And my apologies for not providing my technical comments more quickly.= =C2=A0 The
last month and a half has been particularly challenging at th= e day job.
(Englightening, but challenging.)

draft-mirsky-bfd-mpls-demand seems to be an attempt to provide a profil= e
against which BFD, in a MPLS network, can use demand mode.=C2=A0 What = I (and some
others) have found puzzling is why there's any perceived= need for this
document.

Working through your document beginning in section 3:
- It is pointe= d out that demand mode exists.=C2=A0 Its procedures are documented
=C2= =A0 as part of the core BFD RFC 5880.
- It points out in the case of MPL= S as a transport that LSP Ping is
=C2=A0 necessary to bootstrap the BFD = session.=C2=A0 These procedures are defined in
=C2=A0 RFC 5884.
- It = points out that we can shift to demand mode.=C2=A0 Again, this procedure is=
=C2=A0 documented in RFC 5880; see section 6.6.
- It points out that= we can test liveness using a poll sequence.=C2=A0 Again,
=C2=A0 this pr= ocedure is documented in third paragaph of section 6.6 in RFC 5880.
- Th= e procedures for declaring a session down when in demand mode and a poll=C2=A0 sequence is in progress is covered in paragraph 6 of section 6.8.4 = of RFC
=C2=A0 5880.
- The procedure for a down system reporting its s= tate once per second is
=C2=A0 covered by paragraph 5 of section 6.8.3 o= f RFC 5880.=C2=A0 I don't believe I
=C2=A0 agree with your procedure= that a system in demand mode must initiate a poll
=C2=A0 sequence to de= clare that it is down.
GIM>> The behavior of the= system in Demand mode is introduced as optional. And that is precisely the= update to RFC 5880.=C2=A0

Am I missing something?

-- Jeff

>
> Regards,
> Greg
>
> On Mon, Dec 10, 20= 18 at 2:10 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > Greg,
> &= gt;
> > Apologies for the long delay in reply.
> >
>= ; > On Wed, Nov 21, 2018 at 02:40:50PM -0800, Greg Mirsky wrote:
>= > > I respectfully ask to summarize the comments that were shared wi= th you
> > and
> > > to publish them to the WG without= naming the authors.
> >
> > Tersely:
> > - The = document is not addressing fundamental issues.
> > - It is encumbe= red by IPR.
> > - Observed list traffic regarding question on the = feature was not
> >=C2=A0 =C2=A0satisfactorily converging.
>= >
> > > And I have to admit that I don't understand you= r suggestion to use the
> > > Errata. The procedures to apply t= he Demand mode described in the draft
> > are
> > > no= t in contradiction with RFC 5880, so the suggestion to use Errata
> &= gt; > surprised me.
> >
> > I will respond on my own a= nalysis in detail hopefully this week.=C2=A0 I am
> > awaiting the= resolution of a particular bit of correspondence before
> > deter= mining the tenor of my response.
> >
> > -- Jeff
> = >
--00000000000073f4b60582065b9e-- From nobody Sat Feb 16 10:46:19 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8629B128CB7 for ; Sat, 16 Feb 2019 10:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-v8xFobkiau for ; Sat, 16 Feb 2019 10:46:16 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4A046126C7E for ; Sat, 16 Feb 2019 10:46:16 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 30AD41E2D8; Sat, 16 Feb 2019 13:45:11 -0500 (EST) Date: Sat, 16 Feb 2019 13:45:10 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190216184510.GF28950@pfrc.org> References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 18:46:17 -0000 Greg, On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote: > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas wrote: > > Thanks for the update on the IPR declaration. It's good to see that the > > terms of the licensing have shifted such that open source implementations > > would be able to be done. I'll note that we're still in that limbo phase > > wherein it's not possible for the Working Group, or holders of IPR against > > the impacted RFCs 5880, 5883, and 5884, know what is being asserted that is > > distinct vs. previously published IPR declarations. > > > GIM>> My understanding of the legal side of IPR Disclosures is that the > last overwrites, including in regard to the licensing terms, previous > disclosures. The IPR disclosure and the licensing terms are clear. The patent is still pending. The draft is against procedures largely specified in 5880, 5883, and 5884. Presumably IPR has been filed because you're saying that you're doing something new against these documents. > GIM>> The behavior of the system in Demand mode is introduced as optional. > And that is precisely the update to RFC 5880. I don't understand. Basically, 5880, 5884 leave demand as an option. It's built into the specs. It's unclear what you're suggesting being changed. -- Jeff From nobody Sat Feb 16 14:20:05 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C86F1286D8 for ; Sat, 16 Feb 2019 14:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aReMBViu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kOoMQxYS 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 NMJkqQ8f8fqL for ; Sat, 16 Feb 2019 14:20:02 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F363127598 for ; Sat, 16 Feb 2019 14:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1550355602; x=1551565202; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f5LIIPYdnFuZYq05b0HULpcpSiGFCxz+1zfUKaeE9Y8=; b=aReMBViuw6+0OweWgibTaiJZ596BAICealJmcE9KCggJuz2PHcwjbGrR 9Zg9Gt1tQPNDxqx95Adufi/R6kKSQUumv5TA/UY5y/ON1WchSjJsV6eAZ W87iXsZ0J0P4erGjrZ+Id2Zl4jtQey76v0OycX1rjFydqn+iHphA7Y+MI E=; IronPort-PHdr: =?us-ascii?q?9a23=3AtSYCGRTfxmc2hdo+NUB1gbKvM9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYgFcRHXVlN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAAGjGhc/5tdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBME8DgVsECyeEBoNHA4RQixlKgg2YGoEkA1Q?= =?us-ascii?q?LAQEshEACF4NTIjQJDQEDAQECAQECbRwMhUoBAQEDASMRDAEBNwEPAgEIDgo?= =?us-ascii?q?CAiYCAgIwFRACBAENBYMggVsDDQgBAp93AooUcYEvgngBAQWCRYI2GIILCIE?= =?us-ascii?q?LizkXgUA/gTgfgkyBKBkBg1aCcjGCJqNECQKSVRmBb4VUizmKQ4EQkGoCBAI?= =?us-ascii?q?EBQINAQEFgUY4gVZwFWUBgkGCHBiDVopTcoEojmEBAQ?= X-IronPort-AV: E=Sophos;i="5.58,378,1544486400"; d="scan'208";a="239431000" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2019 22:20:00 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x1GMK06m032110 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Feb 2019 22:20:00 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 Feb 2019 16:20:00 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 16 Feb 2019 16:19:42 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 16 Feb 2019 16:19:42 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f5LIIPYdnFuZYq05b0HULpcpSiGFCxz+1zfUKaeE9Y8=; b=kOoMQxYSGLyqfab0tT2EoUc1OHD6cguycUBXvaOARBHtKc2FtrUN8blS/AFl11B63hHWY/AnOzp/jB6Zxeih8b0hvg0BqMuOeOQAWpVshHbFBK56WYVAuemn2q9Y6DHZFb07e4XAsO9RU2qkCxn7yDg3CUuDO3Aj2yAvvX8td7I= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3664.namprd11.prod.outlook.com (20.178.252.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 22:19:40 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::bd63:a546:ac2c:85d5]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::bd63:a546:ac2c:85d5%4]) with mapi id 15.20.1622.018; Sat, 16 Feb 2019 22:19:40 +0000 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , Greg Mirsky CC: rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Topic: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Index: AQHUZmhJfgrcUNAMK02QPg3oNJil7qVbaqmAgAADnACAHdOmgIBaav4AgA+wiICAABKAAIAAErsA///oG4A= Date: Sat, 16 Feb 2019 22:19:40 +0000 Message-ID: <41B05C23-A13E-4ECC-B9C8-33F43C5AF2A5@cisco.com> References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> In-Reply-To: <20190216184510.GF28950@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:c0c4:1004::8d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c60a230b-3959-413d-15b1-08d6945cd87c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3664; x-ms-traffictypediagnostic: MN2PR11MB3664: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNTjJQUjExTUIzNjY0OzIzOmJPTlZpK3NMQ3pGVlNrY21MZ2V1bnR6Z0ZR?= =?utf-8?B?aDVoaUQ0MzNldUNZbkZBR2UzclRKNnRBNFdkK3QwcmhrM3Q5OXFNU1hqbVVj?= =?utf-8?B?U0NhMTB1QUh6NjJTTStEeUpLUERnSmFJcFJwSjg3WXB2bXc0RDhJelppYkxB?= =?utf-8?B?cXJtVlZNUVJPYU1sdnhZZnhudytnMXBWTEdsdENaSS91aGZTeWVKenFSNVp2?= =?utf-8?B?REZRT1pNamlmemFGaFVsWHZBWTRzazZTUHg0cmFxVFl3bGUzTXhqdG5YSjhq?= =?utf-8?B?Qi93REVRKzM1alJCKzIzUDNMd3RyK05ZTGRMS3Flc1J0MFJ4VTlNcWNiNXZt?= =?utf-8?B?QWNGL1NMSW1EV2FKeW1VKzRMUmQ1Ky90dC9oTFEvMjRxcXJxSnFWcHlmblNw?= =?utf-8?B?ODhaKy9NWkZLalRlL01QS29yUHh1QlJtQ1BwS2ZLNEZSNE1uTWdtMDVocm5Z?= =?utf-8?B?TnAraVcwMnYrYmpuVlRpSVlnVW5ReFBscnN4bFdHOVY4ZlBGQlcxWUhmZ1Ru?= =?utf-8?B?WjhsR1prUGs4SUdwMHBXWndYNUVaOGJFM080VHRQWHVXUmZsRU9ZYmJzemRs?= =?utf-8?B?Wkh5LzMvRXpYRnhndmlKQkNBd214TlFwaWp0VnBhQ3U0bkxzRE5ieElkRGty?= =?utf-8?B?bUJyUXByTXd2RTR5R3N3b3Ntc3JQWXhIZEZTYWlZbXoyS0xqN1ZMaVdER1ZN?= =?utf-8?B?enMzV0J4K3J4blBWSmcvQUF1OVZaMnRlR3NWVHJ5Sk0xZHA1Qm80bEtlNTlj?= =?utf-8?B?ekhjdXlQdGZuQzdXTmcwODRXQVFvU3BzQ1I0RFlrcFJnaElvUUgvZGZPTTVh?= =?utf-8?B?RkhnTE5kNHRHMy9ycmdubDRCVjZaMXNUN2V4cjBVVkVGenNDcWV4U2VhM0lj?= =?utf-8?B?ZndwRE9hZ0dYUzFvMmZBcjdTcThrb3RZZHd6WEVONVpsYmk2Sjl6NWtJQjND?= =?utf-8?B?ZU40MVN0Rld5RDRBM0xpQkJVeDE1RjdVMHIyNTM0ZjZJa0NXU0E0dzNNd1ZE?= =?utf-8?B?UTJZUStZcDFrRlNFdnNLRTB4SlE5NTJ2SW9RcmZuczB0cUtPN2JSZVAvdGxi?= =?utf-8?B?Z2FndVhCTmJUbmVuZ3BJOW16RURMaUJHSHlMM21ZdXNUcEFBWVdORDZiQ21T?= =?utf-8?B?amdRY3ZZSitldjFDT1BKMUtJQ1pJWWt6UlJvZGVYMHFiNzhtVDZpZklXZWs2?= =?utf-8?B?azRncVp3ck5IWnpUVFBsZlkrS3I0LzY3U25qbVAreEwwa2YyK0dROFBrdlRo?= =?utf-8?B?dFU0YmUzSlRyd0VZdzkxR1hwN0tJZzdaQnNST3JUdTVHak5PTDhDM1Bsdm4y?= =?utf-8?B?NVJHb3lvRTdqTUdZWENFdTZralhxR3VXSlRvcisrV3lXL0FmNFlxVkZVOXBl?= =?utf-8?B?Y0hxQUNCZkIyQjI1eTJEeWJWWi9VRzJzMndQWnVhbUpnaXQ5V0Q0bkw4c2ZW?= =?utf-8?B?TDdTUnlDc2V4YkRlY1NpS2YyanM2VGlpSmJuL1RhT1RkREs5eENZMkhYUGRH?= =?utf-8?B?dXhTekhyVXJtY0ZzejZnaXppbEE5WHpGS1F6Z2NXVkh0MUlaS3JDMUYvdW05?= =?utf-8?B?UGV1WFNhTmdVcjk3SHRZV1ErNzBKK1JZb3pZeXkrWEYxRFp4Z0JYVzZnTUR5?= =?utf-8?B?SXM1Mmt6RTFjQW5kWlVCSVFRUERIbkN4VW9jZkI1bENteUN0cXFMWFZIWExX?= =?utf-8?Q?oiyv/sQL3Aer+ogqZ32Vu9PHVelyDDak3u1XJRb?= x-microsoft-antispam-prvs: x-forefront-prvs: 0950706AC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(376002)(39860400002)(396003)(189003)(199004)(51914003)(99286004)(476003)(36756003)(2616005)(486006)(83716004)(33656002)(71190400001)(71200400001)(229853002)(6116002)(86362001)(6512007)(6486002)(316002)(478600001)(11346002)(6246003)(446003)(14454004)(2906002)(6436002)(110136005)(5660300002)(76176011)(58126008)(53936002)(186003)(8936002)(105586002)(25786009)(4326008)(7736002)(106356001)(82746002)(102836004)(6506007)(53546011)(305945005)(46003)(8676002)(81156014)(81166006)(14444005)(256004)(93886005)(97736004)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3664; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4EwJgP8AnbPQQI9vQLECbUy26m7didgkA6vGMAnVcmL73HBH1WxNbVWGdr0Y7smFzgLlKs7Wyd4rAR0nbBDWw2k/NKl+F8w7odKlUIeUo/j18PzUfuJ755aVeJxoCdnKfKogN+yi3KcTOHRWM3/O4pQhMqkB3xsgc2HUw5kVRpDErGf8lRUpA1T9Fbq6RTtFS3bNF5L/4Z6RSf4a8bT59gjdCOXLoxJ3vb3tSVJY17FxF4DaVUkTrjQhcQvw8PPd70LLI4FTvEURKf1TH8fG84s574K0vGGLHiK2kxMwBHQjHh5a6pm4Cn/noB3oG73jnYCUSkhKAY4UzruYd3ulxvAj6ZU+V+yg9AwT0nGvaiN/hI1BpWwtPXOu8xkaDJJ4DFPPtxMaAo9zg6HTUxWhTRaE7PcV01l27BfFVz5/O+E= Content-Type: text/plain; charset="utf-8" Content-ID: <82AF9C17425402449FABEDAB61BC7DF7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c60a230b-3959-413d-15b1-08d6945cd87c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2019 22:19:40.8335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3664 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 22:20:04 -0000 SGkgR3JlZywNCg0KSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHdoYXQncyB0aGUgaW50ZW5kZWQg cHVycG9zZSBvZiB0aGUgZHJhZnQuIERvZXMgaXQgY2hhbmdlL3VwZGF0ZSBhbnkgcHJvY2VkdXJl cyBpbiA1ODgwLzU4ODMgYW5kIGlmIHNvIGNvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB3aHkgYW5k IGhvdz8NCiAgIA0KUmVnYXJkcywNClJlc2hhZC4NCg0KDQrvu79PbiAyMDE5LTAyLTE2LCAxOjQ2 IFBNLCAiUnRnLWJmZCBvbiBiZWhhbGYgb2YgSmVmZnJleSBIYWFzIiA8cnRnLWJmZC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQoNCiAgICBHcmVn LA0KICAgIA0KICAgIE9uIFNhdCwgRmViIDE2LCAyMDE5IGF0IDA5OjM4OjA4QU0gLTA4MDAsIEdy ZWcgTWlyc2t5IHdyb3RlOg0KICAgID4gT24gU2F0LCBGZWIgMTYsIDIwMTkgYXQgODozMyBBTSBK ZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPiB3cm90ZToNCiAgICA+ID4gVGhhbmtzIGZvciB0 aGUgdXBkYXRlIG9uIHRoZSBJUFIgZGVjbGFyYXRpb24uICBJdCdzIGdvb2QgdG8gc2VlIHRoYXQg dGhlDQogICAgPiA+IHRlcm1zIG9mIHRoZSBsaWNlbnNpbmcgaGF2ZSBzaGlmdGVkIHN1Y2ggdGhh dCBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbnMNCiAgICA+ID4gd291bGQgYmUgYWJsZSB0byBi ZSBkb25lLiAgSSdsbCBub3RlIHRoYXQgd2UncmUgc3RpbGwgaW4gdGhhdCBsaW1ibyBwaGFzZQ0K ICAgID4gPiB3aGVyZWluIGl0J3Mgbm90IHBvc3NpYmxlIGZvciB0aGUgV29ya2luZyBHcm91cCwg b3IgaG9sZGVycyBvZiBJUFIgYWdhaW5zdA0KICAgID4gPiB0aGUgaW1wYWN0ZWQgUkZDcyA1ODgw LCA1ODgzLCBhbmQgNTg4NCwga25vdyB3aGF0IGlzIGJlaW5nIGFzc2VydGVkIHRoYXQgaXMNCiAg ICA+ID4gZGlzdGluY3QgdnMuIHByZXZpb3VzbHkgcHVibGlzaGVkIElQUiBkZWNsYXJhdGlvbnMu DQogICAgPiA+DQogICAgPiBHSU0+PiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBsZWdhbCBzaWRl IG9mIElQUiBEaXNjbG9zdXJlcyBpcyB0aGF0IHRoZQ0KICAgID4gbGFzdCBvdmVyd3JpdGVzLCBp bmNsdWRpbmcgaW4gcmVnYXJkIHRvIHRoZSBsaWNlbnNpbmcgdGVybXMsIHByZXZpb3VzDQogICAg PiBkaXNjbG9zdXJlcy4NCiAgICANCiAgICBUaGUgSVBSIGRpc2Nsb3N1cmUgYW5kIHRoZSBsaWNl bnNpbmcgdGVybXMgYXJlIGNsZWFyLg0KICAgIA0KICAgIFRoZSBwYXRlbnQgaXMgc3RpbGwgcGVu ZGluZy4gIFRoZSBkcmFmdCBpcyBhZ2FpbnN0IHByb2NlZHVyZXMgbGFyZ2VseQ0KICAgIHNwZWNp ZmllZCBpbiA1ODgwLCA1ODgzLCBhbmQgNTg4NC4gIFByZXN1bWFibHkgSVBSIGhhcyBiZWVuIGZp bGVkIGJlY2F1c2UNCiAgICB5b3UncmUgc2F5aW5nIHRoYXQgeW91J3JlIGRvaW5nIHNvbWV0aGlu ZyBuZXcgYWdhaW5zdCB0aGVzZSBkb2N1bWVudHMuDQogICAgDQogICAgPiBHSU0+PiBUaGUgYmVo YXZpb3Igb2YgdGhlIHN5c3RlbSBpbiBEZW1hbmQgbW9kZSBpcyBpbnRyb2R1Y2VkIGFzIG9wdGlv bmFsLg0KICAgID4gQW5kIHRoYXQgaXMgcHJlY2lzZWx5IHRoZSB1cGRhdGUgdG8gUkZDIDU4ODAu DQogICAgDQogICAgSSBkb24ndCB1bmRlcnN0YW5kLg0KICAgIA0KICAgIEJhc2ljYWxseSwgNTg4 MCwgNTg4NCBsZWF2ZSBkZW1hbmQgYXMgYW4gb3B0aW9uLiAgSXQncyBidWlsdCBpbnRvIHRoZSBz cGVjcy4NCiAgICBJdCdzIHVuY2xlYXIgd2hhdCB5b3UncmUgc3VnZ2VzdGluZyBiZWluZyBjaGFu Z2VkLg0KICAgIA0KICAgIC0tIEplZmYNCiAgICANCiAgICANCg0K From nobody Sun Feb 17 16:40:49 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8C12EB11 for ; Sun, 17 Feb 2019 16:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUyTmRQzpPoI for ; Sun, 17 Feb 2019 16:40:44 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFB7128D52 for ; Sun, 17 Feb 2019 16:40:44 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id z25so4997171ljk.8 for ; Sun, 17 Feb 2019 16:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uG9XDBMjrKEC/qyUJrwFRFBolvt3YuqdnvzDKFMsJQo=; b=MzHsP5nQ9kWiUYx3Bz0f0aIpp9klqwpLc0AAs+VLqhIZnJJmeiRYyg2WBu6bE3LIuG xCcG00ZdMyvexmrcAjUUfE/p4wZN1KHD47HQ/qMREWFPZFX8/uH3DDP2xI6BZI6ZVt7X oKnraHraR/fNjum9pAbl4RybXDI4naeHBW6Oa3PjHDVk9WCEG+gUAxl+7pUyi9TTMkc6 GuYgLrYmK3Y8XZNQyNfgYyXu3R6yC9uPeCHEy+S42TanXjwah1+pO+Ve7c46ae/bir7P A7pfs3AjrZlVPbz5LElf9TNjYH/i3CB9CSehgynjrVUjiEWIfd6bL5gIpbhUxOzB5yRB Z2Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uG9XDBMjrKEC/qyUJrwFRFBolvt3YuqdnvzDKFMsJQo=; b=nuy/19jnge2+OzgYHxcw0RkaPHMebPpiksR2wILLexVI7HcBSiu0iIFRKSnSJ13HXs t9BLpfngA8BCgQdl3noFdp2QnKcl9MRbqR4f5IYOlJihaD/H0ul1fuEOynFi2WrmMFF7 +Fu01KIVwazK63IpqLMaftIKWxYtJki68r8JqXYvU29Y7MK8ichozC4Y4LFNM/uBbNi/ sH4wNSjwPoxw+mfVVIPNIWhcoG+eldP2HqtqfnP0Hkj24lRYMByWJGkr9cazjQtTBIv1 t+KiMHQMpBoYC6tE9+mYrnrz4iZvVDd16MhV5reuy3czIQkwhLw+3Dc/BOXYryAsBRON /XYA== X-Gm-Message-State: AHQUAuYJrMqFOgjt2rE4fGbvU2SfmAc7pE4kdzMRE2JmBhVTdhg2xfyp sNo9BNX9+lSWQ7ABHlbv4sNSJWJM0KTl/9VPoG8= X-Google-Smtp-Source: AHgI3Ib2/qBwSSj2FnpKPixlffLzTkK/vmxyywL2NifQTBFCTjWt1Ezq+m9Cskp2pg8+qfZmGpDcYVDr0DsULvA5IQI= X-Received: by 2002:a2e:8847:: with SMTP id z7mr11193477ljj.99.1550450442288; Sun, 17 Feb 2019 16:40:42 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> In-Reply-To: <20190216184510.GF28950@pfrc.org> From: Greg Mirsky Date: Sun, 17 Feb 2019 16:40:31 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas , "Reshad Rahman (rrahman)" , Martin Vigoureux Cc: rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000dac2e50582205f64" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 00:40:47 -0000 --000000000000dac2e50582205f64 Content-Type: text/plain; charset="UTF-8" Hi Jeff and Reshad, thank you for your comments and questions. Please find my answers in-line and tagged GIM2>>. Regards, Greg On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas wrote: > Greg, > > On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote: > > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas wrote: > > > Thanks for the update on the IPR declaration. It's good to see that > the > > > terms of the licensing have shifted such that open source > implementations > > > would be able to be done. I'll note that we're still in that limbo > phase > > > wherein it's not possible for the Working Group, or holders of IPR > against > > > the impacted RFCs 5880, 5883, and 5884, know what is being asserted > that is > > > distinct vs. previously published IPR declarations. > GIM2>> Is the fact that the patent application is not yet published the sole foundation for your objection to adopting this draft as Chair of BFD WG or as an individual contributor? Is there any IETF document that requires that the patent must be published before the draft can be adopted or published as RFC? > > > > > GIM>> My understanding of the legal side of IPR Disclosures is that the > > last overwrites, including in regard to the licensing terms, previous > > disclosures. > > The IPR disclosure and the licensing terms are clear. > > The patent is still pending. The draft is against procedures largely > specified in 5880, 5883, and 5884. Presumably IPR has been filed because > you're saying that you're doing something new against these documents. > GIM2>> I don't recall that I've ever claimed that the draft updates RFC 5883 BFD for Multi-hop paths or RFC 5884 BFD for MPLS LSPs. The draft describes how the BFD Demand mode may be used over MPLS LSP. I consider it to be complementary to RFC 5884, which only describes the use of BFD in Asynchronous mode and leaves the Demand mode out of its scope. > > > GIM>> The behavior of the system in Demand mode is introduced as > optional. > > And that is precisely the update to RFC 5880. > > I don't understand. > > Basically, 5880, 5884 leave demand as an option. It's built into the > specs. > It's unclear what you're suggesting being changed. > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does not discuss how the Demand mode may be used in BFD over MPLS LSPs. > > -- Jeff > --000000000000dac2e50582205f64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff and Reshad,
thank you for you= r comments and questions. Please find my=C2=A0answers in-line and tagged GI= M2>>.

Regards,
Greg


On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:
> On= Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
> > Thanks f= or the update on the IPR declaration.=C2=A0 It's good to see that the> > terms of the licensing have shifted such that open source imple= mentations
> > would be able to be done.=C2=A0 I'll note that = we're still in that limbo phase
> > wherein it's not possi= ble for the Working Group, or holders of IPR against
> > the impac= ted RFCs 5880, 5883, and 5884, know what is being asserted that is
> = > distinct vs. previously published IPR declarations.
GIM2>> Is the fact that the patent application is not yet publishe= d the sole foundation for your objection to adopting this draft as Chair of= BFD WG or as an individual contributor? Is there any IETF document that re= quires that the patent must be published before the draft can be adopted or= published as RFC?
&= gt; >
> GIM>> My understanding of the legal side of IPR Disc= losures is that the
> last overwrites, including in regard to the lic= ensing terms, previous
> disclosures.

The IPR disclosure and the licensing terms are clear.

The patent is still pending.=C2=A0 The draft is against procedures larg= ely
specified in 5880, 5883, and 5884.=C2=A0 Presumably IPR has been fil= ed because
you're saying that you're doing something new against= these documents.
GIM2>> I don't recall that= I've ever claimed that the draft updates RFC 5883 BFD for Multi-hop pa= ths or RFC 5884 BFD for MPLS LSPs. The draft describes how the BFD Demand m= ode may be used over MPLS LSP. I consider it to be complementary to RFC 588= 4, which only describes the use of BFD in Asynchronous mode and leaves the = Demand mode out of its scope.

> GIM>> The behavior of the system in Demand mode is introduce= d as optional.
> And that is precisely the update to RFC 5880.

I don't understand.

Basically, 5880, 5884 leave demand as an option.=C2=A0 It's built i= nto the specs.
It's unclear what you're suggesting being changed= .
GIM2>> RFC 5884 leaves the Demand mode outside= its scope. RFC 5884 does not discuss how the Demand mode may be used in BF= D over MPLS LSPs.=C2=A0

-- Jeff
--000000000000dac2e50582205f64-- From nobody Sun Feb 17 16:49:13 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63D1130DD3 for ; Sun, 17 Feb 2019 16:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEvCPOU3aWsx for ; Sun, 17 Feb 2019 16:49:10 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75508130DC2 for ; Sun, 17 Feb 2019 16:49:09 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id g80so12840718ljg.6 for ; Sun, 17 Feb 2019 16:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sfvE+4IvkmY8wFEay2KiKM87PqAtG5LGP0QybzhFKoo=; b=lr2uUtCJkq7xjyB7srp+dj5rIpBcK3uju9er/Fg8rPTLMaZHeIqWzvwqHUiCdiQgTo Q+hrLgtRcoePpaMgUJ3RQD66tGBIY0P+0EbpiTMx4U3RBBeCQF653e2LfzpfCZtmxCMk etoX1+zj27JDGzD2t0dwec8rkI8OEMNklj87RLm5mT5i0o/fsC1035HsUy0U89v8NVwr wX1klKykoisLizQKBamiStXwhaLr6Dm6zCOfXS+f+diYoaRhUSB5srEds8wVbHa9b8gU FTdK3K/PPd5RFX5doszPMgpImuSVcsTDXB0yUUMDFN4A7YNNDz3CYTPTcoH5vU2qPXLu Mr1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sfvE+4IvkmY8wFEay2KiKM87PqAtG5LGP0QybzhFKoo=; b=uj/NFP4QETWbMcBu5JB2T8A7Mek7uKya9ep4jMaJfqQb15kihrG3pbilgxcaXftJ56 d4MWyNSrvAwCVyOX4JL4Ecv7rbCc1MEcLMLaVQcK/9TnFZOOH+HEPU9d0c5kFe5HpsOj /n1lXX1eBL4NGq/hG9+x/oUbnTeHf1LM0m4I1xnhB7k3rhs2mzvQGPnw4xbJ81ORU64V NGo6G9XIeuBHD8rAWyptTKKg/uV4oKV98h0elLrenahF/LVP3dkc5Y0OAZEU/LaSaIZd SCCVmpkGvdPwdoCAsoWxXt/dKTuVOc7VzdtaBuSBxxBCj7Yv0LQhFEhiO3qTYTLdR+rQ Q6Uw== X-Gm-Message-State: AHQUAuab95Q3FXPskdidXsFvlPjoFx+NQ1gJeqWqUGuEDZVVdARfMe9I Z+QfB5bituisX2RgywJk3EwW1E8J2QBn9NArHpQ= X-Google-Smtp-Source: AHgI3IZMY0qLomC+usPO/UfKNA8anejLEtZVzUsjqpEzmnQ2UZnnmt0VW/EEw56jmWUAP3P85svH06/wJgz2xsH6n/A= X-Received: by 2002:a2e:81a:: with SMTP id 26-v6mr12328813lji.14.1550450947244; Sun, 17 Feb 2019 16:49:07 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <41B05C23-A13E-4ECC-B9C8-33F43C5AF2A5@cisco.com> In-Reply-To: <41B05C23-A13E-4ECC-B9C8-33F43C5AF2A5@cisco.com> From: Greg Mirsky Date: Sun, 17 Feb 2019 16:48:56 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: "Reshad Rahman (rrahman)" Cc: Jeffrey Haas , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000f3c66a0582207de2" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 00:49:12 -0000 --000000000000f3c66a0582207de2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for your question. As I've noted, this draft has no relation to RFC 5883 BFD for Multi-hop paths. Also, it is not to update RFC 5884 BFD for MPLS LSPs as the latter describes only the use of BFD in Asynchronous mode. The draft describes procedures to use the Demand mode of BFD, which is beneficial in monitoring unidirectional MPLS paths, e.g. LSP or SR-MPLS tunnel. The draft proposes to update RFC 5880 in regard to the behavior of BFD system in Demand mode so that such system MAY start Poll sequence to inform the remote BFD system of the change in BFD session state, i.e. signal RDI. Regards, Greg On Sat, Feb 16, 2019 at 2:20 PM Reshad Rahman (rrahman) wrote: > Hi Greg, > > I still don't understand what's the intended purpose of the draft. Does i= t > change/update any procedures in 5880/5883 and if so could you please > clarify why and how? > > Regards, > Reshad. > > > =EF=BB=BFOn 2019-02-16, 1:46 PM, "Rtg-bfd on behalf of Jeffrey Haas" < > rtg-bfd-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote: > > Greg, > > On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote: > > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas wrote= : > > > Thanks for the update on the IPR declaration. It's good to see > that the > > > terms of the licensing have shifted such that open source > implementations > > > would be able to be done. I'll note that we're still in that > limbo phase > > > wherein it's not possible for the Working Group, or holders of IP= R > against > > > the impacted RFCs 5880, 5883, and 5884, know what is being > asserted that is > > > distinct vs. previously published IPR declarations. > > > > > GIM>> My understanding of the legal side of IPR Disclosures is that > the > > last overwrites, including in regard to the licensing terms, previo= us > > disclosures. > > The IPR disclosure and the licensing terms are clear. > > The patent is still pending. The draft is against procedures largely > specified in 5880, 5883, and 5884. Presumably IPR has been filed > because > you're saying that you're doing something new against these documents= . > > > GIM>> The behavior of the system in Demand mode is introduced as > optional. > > And that is precisely the update to RFC 5880. > > I don't understand. > > Basically, 5880, 5884 leave demand as an option. It's built into the > specs. > It's unclear what you're suggesting being changed. > > -- Jeff > > > > --000000000000f3c66a0582207de2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad,
thank you for your question. As I've no= ted, this draft has no relation to RFC 5883 BFD for Multi-hop paths. Also, = it is not to update RFC 5884 BFD for MPLS LSPs as the latter describes only= the use of BFD in Asynchronous mode. The draft describes procedures to use= the Demand mode of BFD, which is beneficial in monitoring unidirectional M= PLS paths, e.g. LSP or SR-MPLS tunnel. The draft proposes to update RFC 588= 0 in regard to the behavior of BFD system in Demand mode so that such syste= m MAY start Poll sequence to inform the remote BFD system of the change in = BFD session state, i.e. signal RDI.

Regards,
=
Greg

On Sat, Feb 16, 2019 at 2:20 PM Reshad Rahman (rrahman) <= ;rrahman@cisco.com> wrote:
<= /div>
Hi Greg,

I still don't understand what's the intended purpose of the draft. = Does it change/update any procedures in 5880/5883 and if so could you pleas= e clarify why and how?

Regards,
Reshad.


=EF=BB=BFOn 2019-02-16, 1:46 PM, "Rtg-bfd on behalf of Jeffrey Haas&qu= ot; <rtg-b= fd-bounces@ietf.org on behalf of jhaas@pfrc.org> wrote:

=C2=A0 =C2=A0 Greg,

=C2=A0 =C2=A0 On Sat, Feb 16, 2019 at 09:38:08AM -0800, Greg Mirsky wrote:<= br> =C2=A0 =C2=A0 > On Sat, Feb 16, 2019 at 8:33 AM Jeffrey Haas <jhaas@pfrc.org> wrote:<= br> =C2=A0 =C2=A0 > > Thanks for the update on the IPR declaration.=C2=A0= It's good to see that the
=C2=A0 =C2=A0 > > terms of the licensing have shifted such that open = source implementations
=C2=A0 =C2=A0 > > would be able to be done.=C2=A0 I'll note that = we're still in that limbo phase
=C2=A0 =C2=A0 > > wherein it's not possible for the Working Group= , or holders of IPR against
=C2=A0 =C2=A0 > > the impacted RFCs 5880, 5883, and 5884, know what i= s being asserted that is
=C2=A0 =C2=A0 > > distinct vs. previously published IPR declarations.=
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > GIM>> My understanding of the legal side of IPR Di= sclosures is that the
=C2=A0 =C2=A0 > last overwrites, including in regard to the licensing te= rms, previous
=C2=A0 =C2=A0 > disclosures.

=C2=A0 =C2=A0 The IPR disclosure and the licensing terms are clear.

=C2=A0 =C2=A0 The patent is still pending.=C2=A0 The draft is against proce= dures largely
=C2=A0 =C2=A0 specified in 5880, 5883, and 5884.=C2=A0 Presumably IPR has b= een filed because
=C2=A0 =C2=A0 you're saying that you're doing something new against= these documents.

=C2=A0 =C2=A0 > GIM>> The behavior of the system in Demand mode is= introduced as optional.
=C2=A0 =C2=A0 > And that is precisely the update to RFC 5880.

=C2=A0 =C2=A0 I don't understand.

=C2=A0 =C2=A0 Basically, 5880, 5884 leave demand as an option.=C2=A0 It'= ;s built into the specs.
=C2=A0 =C2=A0 It's unclear what you're suggesting being changed.
=C2=A0 =C2=A0 -- Jeff



--000000000000f3c66a0582207de2-- From nobody Mon Feb 18 07:26:50 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1C1130F18 for ; Mon, 18 Feb 2019 07:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTSpXujCCuIM for ; Mon, 18 Feb 2019 07:26:47 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C6567130F03 for ; Mon, 18 Feb 2019 07:26:47 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id A4B171E2D8; Mon, 18 Feb 2019 10:25:44 -0500 (EST) Date: Mon, 18 Feb 2019 10:25:44 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190218152544.GG28950@pfrc.org> References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 15:26:49 -0000 Greg, Answering this message with the reply partially reorganized. On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote: > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas wrote: > > > GIM>> The behavior of the system in Demand mode is introduced as > > optional. > > > And that is precisely the update to RFC 5880. > > > > I don't understand. > > > > Basically, 5880, 5884 leave demand as an option. It's built into the > > specs. > > It's unclear what you're suggesting being changed. > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does not > discuss how the Demand mode may be used in BFD over MPLS LSPs. Even thought the RFC says demand mode is out of scope, 5880 is clear about how demand mode works. I'm not seeing anything in your draft that alters that procedure. Basically, no draft is needed for a one-liner: you can use demand mode. > GIM2>> Is the fact that the patent application is not yet published the > sole foundation for your objection to adopting this draft as Chair of BFD > WG or as an individual contributor? Is there any IETF document that > requires that the patent must be published before the draft can be adopted > or published as RFC? The sole reason for mentioning this is demand mode is clear. BFD over mpls is clear. You're asserting some sort of IPR on things that are already clear. So, either your draft itself is unclear on some new thing you're asserting IPR on, or you're not actually covering something new. That's it. -- Jeff From nobody Mon Feb 18 07:32:47 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F71130F18 for ; Mon, 18 Feb 2019 07:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwRwL4Hk7c1s for ; Mon, 18 Feb 2019 07:32:43 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E81130F03 for ; Mon, 18 Feb 2019 07:32:42 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id g80so14730706ljg.6 for ; Mon, 18 Feb 2019 07:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x98uWyJBrJtaEk5g/7guGODlGHKs2UifJb/tz3igrLk=; b=Hej/PvAZVAw1RyilVT6dCzEHH2zIpEB6/i9JZrx8iKZFTgKiDGbPXU0IwCvdCQC2dd YWzpAqUILWrT0zW0ytPZPwJbOaJuai2HOLc6Jn0n91Z3dGCcj7dEu9HKbcV0t4Kcq58h Ylal3E+uRtrACgCtL2D8UAuNV14pir9qJxLbUaCcP2YCis5oDu6W8t0lKqXObPcCSQS6 uB8mWvYMRemzJKh1sn21ThgfrpsWOijpMH+DtxTMqDnEXqL7Gn911htjZiZ6edHB5aC1 9m3xuptEZJPyPfS/Bo3lB1BuGVG8EKAi6sbFZvGLwF6UlUw9iQYEe6VpE60AAGPYuqhK nQQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x98uWyJBrJtaEk5g/7guGODlGHKs2UifJb/tz3igrLk=; b=qiyX3doqua+tFz5n1/vCDkr5oGJBYX0octX2Jf5ZDj5Z/Ps/d6QNNfMmere7dXwgry i+F6i9sf75i5y1sGnbx4sPrsjSqimswTuCavn5rYOzjLvxNWwjOILnu/IXUSSdxRIZAz CSvytfphoUFitF137P5C0/8g9CeESEGLqZhFFX+mfpkfS5z4hXgVyKFJ9Myrr0eI0YM4 SWoXHJJxPELf+DjKurV7cn2uL4Ljlay4OdpFUM/59roOPwZe9otAsw8DGTwtn/+1w7wq QAdChsGauIxZvX02JjkD8KYFqlYASs6xSjbgDIXyl+9U7GOaYroHwBafA/7SEtBtRCTQ vw5Q== X-Gm-Message-State: AHQUAuaX2HFdKnz1Vz4UZQLcXLSnVL26lNgenL1t64xuhO4NDduAV6Gq L1b1w1vfRYuH2wPyjwzXK4dGI0iPnxUspsA1wEc= X-Google-Smtp-Source: AHgI3Ibu6XoJsqiswh4Gm9iNQ5AoRcJOwJN7ENwwosRsJhk8gGhXQNXz0icWkEkPTC9y6aXqUjzmpSeY06S0OuzqFrs= X-Received: by 2002:a2e:81a:: with SMTP id 26-v6mr14488737lji.14.1550503960762; Mon, 18 Feb 2019 07:32:40 -0800 (PST) MIME-Version: 1.0 References: <20181017222431.GK17157@pfrc.org> <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> In-Reply-To: <20190218152544.GG28950@pfrc.org> From: Greg Mirsky Date: Mon, 18 Feb 2019 07:32:30 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000cddc4305822cd57e" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 15:32:45 -0000 --000000000000cddc4305822cd57e Content-Type: text/plain; charset="UTF-8" Hi Jeff, could you please clarify which of your roles, BFD WG chair or individual contributor, you are in this discussion. Regards, Greg On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas wrote: > Greg, > > Answering this message with the reply partially reorganized. > > > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote: > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas wrote: > > > > GIM>> The behavior of the system in Demand mode is introduced as > > > optional. > > > > And that is precisely the update to RFC 5880. > > > > > > I don't understand. > > > > > > Basically, 5880, 5884 leave demand as an option. It's built into the > > > specs. > > > It's unclear what you're suggesting being changed. > > > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does > not > > discuss how the Demand mode may be used in BFD over MPLS LSPs. > > Even thought the RFC says demand mode is out of scope, 5880 is clear about > how demand mode works. I'm not seeing anything in your draft that alters > that procedure. > > Basically, no draft is needed for a one-liner: you can use demand mode. > > > GIM2>> Is the fact that the patent application is not yet published the > > sole foundation for your objection to adopting this draft as Chair of BFD > > WG or as an individual contributor? Is there any IETF document that > > requires that the patent must be published before the draft can be > adopted > > or published as RFC? > > The sole reason for mentioning this is demand mode is clear. BFD over mpls > is clear. You're asserting some sort of IPR on things that are already > clear. So, either your draft itself is unclear on some new thing you're > asserting IPR on, or you're not actually covering something new. That's > it. > > -- Jeff > --000000000000cddc4305822cd57e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
could you please clarify which of your roles,= BFD WG chair or individual contributor, you are in this discussion.
<= div>
Regards,
Greg

On Mon, Feb 18, 2019 at 7:2= 6 AM Jeffrey Haas <jhaas@pfrc.org&= gt; wrote:
Greg,=

Answering this message with the reply partially reorganized.


On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
> > > GIM>> The behavior of the system in Demand mode is int= roduced as
> > optional.
> > > And that is precisely the update to RFC 5880.
> >
> > I don't understand.
> >
> > Basically, 5880, 5884 leave demand as an option.=C2=A0 It's b= uilt into the
> > specs.
> > It's unclear what you're suggesting being changed.
> >
> GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 58= 84 does not
> discuss how the Demand mode may be used in BFD over MPLS LSPs.

Even thought the RFC says demand mode is out of scope, 5880 is clear about<= br> how demand mode works.=C2=A0 I'm not seeing anything in your draft that= alters
that procedure.

Basically, no draft is needed for a one-liner: you can use demand mode.

> GIM2>> Is the fact that the patent application is not yet publis= hed the
> sole foundation for your objection to adopting this draft as Chair of = BFD
> WG or as an individual contributor? Is there any IETF document that > requires that the patent must be published before the draft can be ado= pted
> or published as RFC?

The sole reason for mentioning this is demand mode is clear.=C2=A0 BFD over= mpls
is clear.=C2=A0 You're asserting some sort of IPR on things that are al= ready
clear.=C2=A0 So, either your draft itself is unclear on some new thing you&= #39;re
asserting IPR on, or you're not actually covering something new.=C2=A0 = That's it.

-- Jeff
--000000000000cddc4305822cd57e-- From nobody Mon Feb 18 08:24:57 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206831277D2 for ; Mon, 18 Feb 2019 08:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhIm510afD3x for ; Mon, 18 Feb 2019 08:24:53 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A8DE71277CC for ; Mon, 18 Feb 2019 08:24:53 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id C88061E2D8; Mon, 18 Feb 2019 11:23:50 -0500 (EST) Date: Mon, 18 Feb 2019 11:23:50 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190218162350.GH28950@pfrc.org> References: <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 16:24:55 -0000 On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote: > Hi Jeff, > could you please clarify which of your roles, BFD WG chair or individual > contributor, you are in this discussion. In this case I am speaking as a chair. For the Working Group to adopt a draft, it needs to solve a problem. In this case, changes to the protocol. We are asking you what changes there are to the protocol. Please answer that question. In the prior adoption call, IPR declaration concerns were one of the considerations for some respondents as to whether we should adopt this or not. You answered those, and the licensing in the current IPR declaration is the in the form that is the most agreeable from a licensing perspective, especially for open source implementors. Again, the only motivation to inquire about the IPR at this point is that there appears to be no protocol changes in your draft. If you are asserting IPR, it implies that there is something new. If there's something new, it should be reflected as protocol changes in your draft. Even if you're not to the point where you or the IPR holder can disclose, the draft itself must be clear. If you have any further concerns beyond the above with specific regard to my stance as chair on the IPR considerations, I strongly suggest you request Martin to ask the IESG to have the IETF legal group intervene. This would be preferable to further aspersions to implicit bias. Please note that IETF legal will be asking similar questions to the above. -- Jeff > > Regards, > Greg > > On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas wrote: > > > Greg, > > > > Answering this message with the reply partially reorganized. > > > > > > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote: > > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas wrote: > > > > > GIM>> The behavior of the system in Demand mode is introduced as > > > > optional. > > > > > And that is precisely the update to RFC 5880. > > > > > > > > I don't understand. > > > > > > > > Basically, 5880, 5884 leave demand as an option. It's built into the > > > > specs. > > > > It's unclear what you're suggesting being changed. > > > > > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 does > > not > > > discuss how the Demand mode may be used in BFD over MPLS LSPs. > > > > Even thought the RFC says demand mode is out of scope, 5880 is clear about > > how demand mode works. I'm not seeing anything in your draft that alters > > that procedure. > > > > Basically, no draft is needed for a one-liner: you can use demand mode. > > > > > GIM2>> Is the fact that the patent application is not yet published the > > > sole foundation for your objection to adopting this draft as Chair of BFD > > > WG or as an individual contributor? Is there any IETF document that > > > requires that the patent must be published before the draft can be > > adopted > > > or published as RFC? > > > > The sole reason for mentioning this is demand mode is clear. BFD over mpls > > is clear. You're asserting some sort of IPR on things that are already > > clear. So, either your draft itself is unclear on some new thing you're > > asserting IPR on, or you're not actually covering something new. That's > > it. > > > > -- Jeff > > From nobody Mon Feb 18 08:48:25 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDC31277CC for ; Mon, 18 Feb 2019 08:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxUaoFoVOyis for ; Mon, 18 Feb 2019 08:48:21 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8361277D2 for ; Mon, 18 Feb 2019 08:48:21 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id f24-v6so14963742ljk.0 for ; Mon, 18 Feb 2019 08:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LRXBG1aqA3uAAXKsaIDy1p8BSnqmuhNPtp0hGet2/Wk=; b=BW9UH2nh7LanAGQKh1kCQMSCEpcNYZAAIIyzpKIu+2pTAzqqVee64DXXhrrgQk1gOw TT0qsGo+d8Ni9aFLwXIxgURIWMnFhCGWWnnQ5KCT9DU5moECKbUC0sp3ioQUoAdrTN0w ngmVqkmMHvnp8KnE5JxKvfc26WK0C+MffgXv11NFFX0GMI4HNv/aEFtZgWyveheRlcB+ avkoV3tEcszEIkfBtjq2xbkssdijS61jj9MrYaE+b5rw0lJgxGZRzaCy6yVHGC6NV0f0 H6NDD8mgAdaYMazHQM5wEClMEnv90opxibhvaSQB+thzUDMjLRe54ftziL5yNheHjFDQ U7xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LRXBG1aqA3uAAXKsaIDy1p8BSnqmuhNPtp0hGet2/Wk=; b=UQ6TF5UAohiD9Daha9P2Sdmhery8o/3Olhk7KXVG+bS6WCgQOSUsJ/IGp84PaXScod Co1iW475QNhMQIEcJmZw6tkb1YN4L++oooxaWTMai/dN/aHDIeP0T8TlkcCR+JSHyjg3 KAmjuxiYehKAFKzy0HwsGGj3n92YErWtMXwi6+j7LVFvMFNwfYZrNmA2EP9MpzxGJzED B5Qb7j7lNw5Trf4QGC5j1mW+/PZ0tDNT/IFIFJ2QEnv1j5QbFyKBilOz411b7PkNE6XI TS4KcT2vR0bI2rdts8gfxQVVk1kT6DCiHVs0w79BxVXcN0SY7UZ6Rkyxj/2aJnCv+nbj C1Fg== X-Gm-Message-State: AHQUAuagOpIDwspwrypTX21aA1q9XFOrtPXS/OoGUvzqDvCzx9/BYOHj gj7Nv4xMzIwakEZtRpNbdrWnOSFL4E+vBEQOm2o= X-Google-Smtp-Source: AHgI3IYZrp9Red8PooOUuaV8cf4pnhKtHJb+Qx3pj3mpFRqS2zDkls6QmsGdiGPS8hsMLRZnAfSXIPfkpblFJVtQmXk= X-Received: by 2002:a2e:20b:: with SMTP id 11mr11533792ljc.41.1550508499114; Mon, 18 Feb 2019 08:48:19 -0800 (PST) MIME-Version: 1.0 References: <20181121222755.GC23096@pfrc.org> <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> In-Reply-To: <20190218162350.GH28950@pfrc.org> From: Greg Mirsky Date: Mon, 18 Feb 2019 08:48:08 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000004f9e9705822de4e3" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 16:48:24 -0000 --0000000000004f9e9705822de4e3 Content-Type: text/plain; charset="UTF-8" Hi Jeff, I haven't heard that IETF encourages the discussion of the relevance of the IPR Disclosure to the draft it referred to, less the validity of IPR. I always was told to stay away from these topics. As for your question of what is the change proposed in the draft I'll point to section 6.6 RFC 5880 that describes the Demand mode. It states that the periodic transmission of control messages MUST be stopped. The draft defines, and that is what I consider the update to section 6.6, the procedure by which the system in Demand mode initiates the Poll sequence to inform the remote BFD system of RDI. And coming back to WGAP, I don't recall any concerns or questions being brought up on the WG list. The volume of responses was not enthusiastic, I agree, but all were in favor of adopting the draft. Regards, Greg On Mon, Feb 18, 2019 at 8:24 AM Jeffrey Haas wrote: > On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote: > > Hi Jeff, > > could you please clarify which of your roles, BFD WG chair or individual > > contributor, you are in this discussion. > > In this case I am speaking as a chair. > > For the Working Group to adopt a draft, it needs to solve a problem. In > this case, changes to the protocol. We are asking you what changes there > are to the protocol. Please answer that question. > > In the prior adoption call, IPR declaration concerns were one of the > considerations for some respondents as to whether we should adopt this or > not. You answered those, and the licensing in the current IPR declaration > is the in the form that is the most agreeable from a licensing perspective, > especially for open source implementors. > > Again, the only motivation to inquire about the IPR at this point is that > there appears to be no protocol changes in your draft. If you are > asserting > IPR, it implies that there is something new. If there's something new, it > should be reflected as protocol changes in your draft. Even if you're not > to the point where you or the IPR holder can disclose, the draft itself > must > be clear. > > If you have any further concerns beyond the above with specific regard to > my > stance as chair on the IPR considerations, I strongly suggest you request > Martin to ask the IESG to have the IETF legal group intervene. This would > be preferable to further aspersions to implicit bias. Please note that > IETF > legal will be asking similar questions to the above. > > -- Jeff > > > > > > > > Regards, > > Greg > > > > On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas wrote: > > > > > Greg, > > > > > > Answering this message with the reply partially reorganized. > > > > > > > > > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote: > > > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas > wrote: > > > > > > GIM>> The behavior of the system in Demand mode is introduced as > > > > > optional. > > > > > > And that is precisely the update to RFC 5880. > > > > > > > > > > I don't understand. > > > > > > > > > > Basically, 5880, 5884 leave demand as an option. It's built into > the > > > > > specs. > > > > > It's unclear what you're suggesting being changed. > > > > > > > > > GIM2>> RFC 5884 leaves the Demand mode outside its scope. RFC 5884 > does > > > not > > > > discuss how the Demand mode may be used in BFD over MPLS LSPs. > > > > > > Even thought the RFC says demand mode is out of scope, 5880 is clear > about > > > how demand mode works. I'm not seeing anything in your draft that > alters > > > that procedure. > > > > > > Basically, no draft is needed for a one-liner: you can use demand mode. > > > > > > > GIM2>> Is the fact that the patent application is not yet published > the > > > > sole foundation for your objection to adopting this draft as Chair > of BFD > > > > WG or as an individual contributor? Is there any IETF document that > > > > requires that the patent must be published before the draft can be > > > adopted > > > > or published as RFC? > > > > > > The sole reason for mentioning this is demand mode is clear. BFD over > mpls > > > is clear. You're asserting some sort of IPR on things that are already > > > clear. So, either your draft itself is unclear on some new thing > you're > > > asserting IPR on, or you're not actually covering something new. > That's > > > it. > > > > > > -- Jeff > > > > --0000000000004f9e9705822de4e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
I haven't heard that IETF encourages the = discussion of the relevance of the IPR Disclosure to the draft it referred= =C2=A0to, less the validity of IPR. I always was told to stay away from the= se topics.

As for your question of what is the cha= nge proposed in the draft I'll point to section 6.6 RFC 5880 that descr= ibes the Demand mode. It states that the periodic transmission of control m= essages MUST be stopped. The draft defines, and that is what I consider the= update to section 6.6, the procedure by which the system in Demand mode in= itiates the Poll sequence to inform the remote BFD system of RDI.

And coming back to WGAP, I don't recall any concerns or= questions being brought up on the WG list. The volume of=C2=A0responses wa= s not enthusiastic, I agree, but all were in favor of adopting the draft.

Regards,
Greg

<= br>
On Mon,= Feb 18, 2019 at 8:24 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
On Mon, Feb 18, 2019 at 07:32:30AM -0800, Greg Mirsky wrote:=
> Hi Jeff,
> could you please clarify which of your roles, BFD WG chair or individu= al
> contributor, you are in this discussion.

In this case I am speaking as a chair.

For the Working Group to adopt a draft, it needs to solve a problem.=C2=A0 = In
this case, changes to the protocol.=C2=A0 We are asking you what changes th= ere
are to the protocol.=C2=A0 Please answer that question.

In the prior adoption call, IPR declaration concerns were one of the
considerations for some respondents as to whether we should adopt this or not.=C2=A0 You answered those, and the licensing in the current IPR declara= tion
is the in the form that is the most agreeable from a licensing perspective,=
especially for open source implementors.

Again, the only motivation to inquire about the IPR at this point is that there appears to be no protocol changes in your draft.=C2=A0 If you are ass= erting
IPR, it implies that there is something new.=C2=A0 If there's something= new, it
should be reflected as protocol changes in your draft.=C2=A0 Even if you= 9;re not
to the point where you or the IPR holder can disclose, the draft itself mus= t
be clear.

If you have any further concerns beyond the above with specific regard to m= y
stance as chair on the IPR considerations, I strongly suggest you request Martin to ask the IESG to have the IETF legal group intervene.=C2=A0 This w= ould
be preferable to further aspersions to implicit bias.=C2=A0 Please note tha= t IETF
legal will be asking similar questions to the above.

-- Jeff




>
> Regards,
> Greg
>
> On Mon, Feb 18, 2019 at 7:26 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > Greg,
> >
> > Answering this message with the reply partially reorganized.
> >
> >
> > On Sun, Feb 17, 2019 at 04:40:31PM -0800, Greg Mirsky wrote:
> > > On Sat, Feb 16, 2019 at 10:46 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
> > > > > GIM>> The behavior of the system in Demand m= ode is introduced as
> > > > optional.
> > > > > And that is precisely the update to RFC 5880.
> > > >
> > > > I don't understand.
> > > >
> > > > Basically, 5880, 5884 leave demand as an option.=C2=A0 = It's built into the
> > > > specs.
> > > > It's unclear what you're suggesting being chang= ed.
> > > >
> > > GIM2>> RFC 5884 leaves the Demand mode outside its sco= pe. RFC 5884 does
> > not
> > > discuss how the Demand mode may be used in BFD over MPLS LSP= s.
> >
> > Even thought the RFC says demand mode is out of scope, 5880 is cl= ear about
> > how demand mode works.=C2=A0 I'm not seeing anything in your = draft that alters
> > that procedure.
> >
> > Basically, no draft is needed for a one-liner: you can use demand= mode.
> >
> > > GIM2>> Is the fact that the patent application is not = yet published the
> > > sole foundation for your objection to adopting this draft as= Chair of BFD
> > > WG or as an individual contributor? Is there any IETF docume= nt that
> > > requires that the patent must be published before the draft = can be
> > adopted
> > > or published as RFC?
> >
> > The sole reason for mentioning this is demand mode is clear.=C2= =A0 BFD over mpls
> > is clear.=C2=A0 You're asserting some sort of IPR on things t= hat are already
> > clear.=C2=A0 So, either your draft itself is unclear on some new = thing you're
> > asserting IPR on, or you're not actually covering something n= ew.=C2=A0 That's
> > it.
> >
> > -- Jeff
> >
--0000000000004f9e9705822de4e3-- From nobody Mon Feb 18 09:34:58 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FA0130E6E for ; Mon, 18 Feb 2019 09:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZKHP_kTIwuk for ; Mon, 18 Feb 2019 09:34:54 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 37715128D0B for ; Mon, 18 Feb 2019 09:34:54 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7F1FA1E2D8; Mon, 18 Feb 2019 12:33:51 -0500 (EST) Date: Mon, 18 Feb 2019 12:33:51 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190218173351.GI28950@pfrc.org> References: <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 17:34:57 -0000 On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote: > As for your question of what is the change proposed in the draft I'll point > to section 6.6 RFC 5880 that describes the Demand mode. It states that the > periodic transmission of control messages MUST be stopped. Correct. > The draft > defines, and that is what I consider the update to section 6.6, the > procedure by which the system in Demand mode initiates the Poll sequence to > inform the remote BFD system of RDI. Would you clarify where in your draft this is discussed? > Greg -- Jeff From nobody Mon Feb 18 10:02:29 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB9130F66 for ; Mon, 18 Feb 2019 10:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLxyove69y51 for ; Mon, 18 Feb 2019 10:02:25 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C21E130F74 for ; Mon, 18 Feb 2019 10:02:21 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id m11so12947091lfc.6 for ; Mon, 18 Feb 2019 10:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kHQ6PBltAKreukSy5t5R4nrXQ0D7oQ5ovBw5KqqteVA=; b=bbgUoFjH+mTl5NXJZvyNp8AmRId9/4bDrMnE9HTCUajaBgu0Cs3wVuI01PSPMY3Lem UvzZpAn451kl/ydM4HqsMkuWDcClv0g/KT8yPuB1ylhulipxMI9JxOOdm6bwReCynwIm OAUmSkD6GYvwDBacuclGg0CKSDa9Y8JGhrPgBq1FqjV3FL3IBG132xOGQMPO7UfCAx0V OBnaE1qHnIxcH5XSNERFrBTZZN/VLZmZPV+SQlxt5dCpIAbwTOhd1arNhJmOp55kr+e8 3jaOXvyk5qAtnEE5MEIXXJGyfkfO40dOMU/srhfhUbY1ouoYlr52J47Ea1nrJ2Ad1i8r JoOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kHQ6PBltAKreukSy5t5R4nrXQ0D7oQ5ovBw5KqqteVA=; b=QPmXLalxFCiinFJso0ddg9MjXihdvQOX5l43QH2T5HdHOmOPMBz/8H9TcVLdNJq3mj wRHJ+DkIEu30V8Jjb2IOQyx2esSh3+39xqe7YJjnuv3BPNQzE5qTBuEiUTE5GtDsrhrp RTsk4de8PxPcvp8ADQgyxi265tgNEaSMlAkkivJPxSyafHVXlL8V4QQ4/Z+9ajYpLD7d cbOQtZryXW4SJPhgHEZubi3T/r6n6TFsoZT82Z3UDEUmjZA/zepHIyEFKmCUE5cXQq9k Ev/qndrvR7zXuHDOf1gn1L74REU5Hsq/N+8TBR67KkAZF6iUShyGKb426k2/k2mA9WS4 BmbA== X-Gm-Message-State: AHQUAuaRRaUYrYOEjUIkhNiiYC8l+29g95i8o2Ar6dh2ys03fQRpSKo0 52jwrVvhSQMtbFIfrlSzsgDaa5YrxX5wf81n0nc= X-Google-Smtp-Source: AHgI3IauN0cxtIYC7n1Q3cSx6+hq8m+Fa8lnamiHqBhwikfCYS/rVHLp+JxuYtqJx3CjpNgEw09kO1IuOb8jE4BM/dQ= X-Received: by 2002:a19:c396:: with SMTP id t144mr4640425lff.127.1550512939484; Mon, 18 Feb 2019 10:02:19 -0800 (PST) MIME-Version: 1.0 References: <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> In-Reply-To: <20190218173351.GI28950@pfrc.org> From: Greg Mirsky Date: Mon, 18 Feb 2019 10:02:09 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000fa4b4205822eece8" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 18 Feb 2019 18:02:28 -0000 --000000000000fa4b4205822eece8 Content-Type: text/plain; charset="UTF-8" Hi Jeff, here's the text from the draft that describes the behavior on the BFD system: If the Detection timer at the egress LER expires it MUST send BFD Control packet to the ingress LER with the Poll (P) bit set, Status (Sta) field set to Down value, and the Diagnostic (Diag) field set to Control Detection Time Expired value. The egress LER sends these Control packets to the ingress LER at the rate of one per second until either it receives the valid for this BFD session control packet with the Final (F) bit set from the ingress LER or the defect condition clears and the BFD session state reaches Up state at the egress LER. Regards, Greg On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas wrote: > On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote: > > As for your question of what is the change proposed in the draft I'll > point > > to section 6.6 RFC 5880 that describes the Demand mode. It states that > the > > periodic transmission of control messages MUST be stopped. > > Correct. > > > The draft > > defines, and that is what I consider the update to section 6.6, the > > procedure by which the system in Demand mode initiates the Poll sequence > to > > inform the remote BFD system of RDI. > > Would you clarify where in your draft this is discussed? > > > Greg > > -- Jeff > --000000000000fa4b4205822eece8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
here's the text from the= draft that describes the behavior on the BFD system:
=C2=A0= =C2=A0If the Detection timer at the egress LER expires it MUST send BFD
=C2=A0 =C2=A0Control packet to the ingress LER with the Poll (P) bi= t set, Status
=C2=A0 =C2=A0(Sta) field set to Down value, and the= Diagnostic (Diag) field set to
=C2=A0 =C2=A0Control Detection Ti= me Expired value.=C2=A0 The egress LER sends these
=C2=A0 =C2=A0C= ontrol packets to the ingress LER at the rate of one per second
= =C2=A0 =C2=A0until either it receives the valid for this BFD session contro= l
=C2=A0 =C2=A0packet with the Final (F) bit set from the ingress= LER or the defect
=C2=A0 =C2=A0condition clears and the BFD sess= ion state reaches Up state at the
=C2=A0 =C2=A0egress LER.
<= /div>

Regards,
Greg

On Mon, Feb 18,= 2019 at 9:34 AM Jeffrey Haas <jhaas@p= frc.org> wrote:
On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote:
> As for your question of what is the change proposed in the draft I'= ;ll point
> to section 6.6 RFC 5880 that describes the Demand mode. It states that= the
> periodic transmission of control messages MUST be stopped.

Correct.

> The draft
> defines, and that is what I consider the update to section 6.6, the > procedure by which the system in Demand mode initiates the Poll sequen= ce to
> inform the remote BFD system of RDI.

Would you clarify where in your draft this is discussed?

> Greg

-- Jeff
--000000000000fa4b4205822eece8-- From nobody Mon Feb 18 19:53:08 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974521295EC for ; Mon, 18 Feb 2019 19:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lKSFXJbF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jdYJ0wIl 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 MOd5XZEuylAl for ; Mon, 18 Feb 2019 19:53:03 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03F3127287 for ; Mon, 18 Feb 2019 19:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13819; q=dns/txt; s=iport; t=1550548383; x=1551757983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZsIGYsU71AUVc3ANnr3otHKswkIJzUwUNxPLtPR1pdw=; b=lKSFXJbF1eo5PB5dCz4x90PQXLqlwCmwxVW8QGIoAMR29XiYfqNle12R HVimPO2kptd15NfR7bFWgUs8K0Al+PXNZAG8RgRlIkM1kgWceCbLpphX9 dDH/zf2bPZcr/TBhTktZd7Jk2ScIVjgsoRvgdDur2ymovma83pM60VgkN I=; IronPort-PHdr: =?us-ascii?q?9a23=3A9+C5pRcWLMzJahGDtwbo0AvJlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTYzHMFLUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACFfGtc/5FdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ0jJCwDZ3QECycKg3yDRwOEUIsdgle?= =?us-ascii?q?JLIh9hXEUgRADVAsBASMJhEACF4NZIjQJDQEDAQECAQECbRwMhUoBAQEDASM?= =?us-ascii?q?dAQE3AQQLAgEIEQMBAgEnAwICAh8RFAkIAgQBDQWDIAGBDkwDDQgBAgygYwK?= =?us-ascii?q?KFHGBL4J4AQEFhQUNC4ILAwWMRBeBQD+BEScfgkyBKBkBgRVHAQECAYErARI?= =?us-ascii?q?BPw0JglMxgiaKAYYsgX2FGotPMwkChzuBGoZFgzsZgXCREIpDgRCEOoEsiwU?= =?us-ascii?q?CBAIEBQINAQEFgUY4ZXFwFWUBgkGCHBiDVoUUhT9yAYEni3+BHwGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,385,1544486400"; d="scan'208,217";a="520734435" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 03:53:02 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x1J3r2qG021955 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Feb 2019 03:53:02 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Feb 2019 21:53:01 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Feb 2019 22:53:00 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 18 Feb 2019 21:53:00 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZsIGYsU71AUVc3ANnr3otHKswkIJzUwUNxPLtPR1pdw=; b=jdYJ0wIlp4wW5yTv59sXGM4ernmcCQ06SALPpZ7s4TtAA9R6Vrq7oO9ltY8lxSpDpzQhSzFsXhEvnoiTsYsiVJW7u+TzotON2vfaaCrOzbIZTxGk/EKurdYx3ZTYZzUYYvjqQDskdPvrvIHIvMkcIPVdx7Pw1jeZVrCcgkmU2a8= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB4000.namprd11.prod.outlook.com (10.255.181.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Tue, 19 Feb 2019 03:52:59 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::bd63:a546:ac2c:85d5]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::bd63:a546:ac2c:85d5%4]) with mapi id 15.20.1622.018; Tue, 19 Feb 2019 03:52:59 +0000 From: "Reshad Rahman (rrahman)" To: Greg Mirsky , Jeffrey Haas CC: Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Topic: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Index: AQHUZmhJfgrcUNAMK02QPg3oNJil7qVbaqmAgAADnACAHdOmgIBaav4AgA+wiICAABKAAIAAErsAgAH1nYCAAPdUAIAAAeQAgAAOVwCAAAbKAIAADMaAgAAH6ICAAFFAgA== Date: Tue, 19 Feb 2019 03:52:58 +0000 Message-ID: <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> References: <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 x-originating-ip: [173.38.117.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68e252b2-0f64-4df8-bd27-08d6961dbd1b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB4000; x-ms-traffictypediagnostic: MN2PR11MB4000: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNTjJQUjExTUI0MDAwOzIzOmRxVXFLZlB4a0hoVDRjMXl0RU1wclN5RlJh?= =?utf-8?B?K01xY012aHNCeGhnRjdmN1hMMklUTEtXek11YmlUbHlGZmJXci9hYmhQRFlp?= =?utf-8?B?dUdYaFIwSTNEUk1GeUpMQkt2djhET2o1QWV3VkxhWUpQSUJxdnZQWEtXNEpR?= =?utf-8?B?N3BoYVRCOG1UQmJXa0psYitNb2pQRmdxVmJJUDBqUzRIQlZJRk1vRmN6RWNh?= =?utf-8?B?UHk0NVpITkFnOUszUEtwL0hadWZXTmI3a0RaU05SLzVqd016bXF6R21MT29p?= =?utf-8?B?dy9qSzFibGZTbWtocjVKVmxlRHYvYlRia3p6V3RxS0RGZjdsYjluUkk1cDlM?= =?utf-8?B?ekNRSjd4SUpMWmluektMWnJqTGhGOWs3RkIwZ0lCMklQS21qQVhLWURDNkVR?= =?utf-8?B?NDc3YTYvVFBadlpXNmE5dFNBL1FoN1hsMkVRU0pkQVhOOUdsN2xGakl4dUIw?= =?utf-8?B?bWJEcDlkNjV1ZzEreWNhaUdoYXBhRXpnWXUrMkhqcS9DSjR3bFVFRTBZSWd0?= =?utf-8?B?dWVYZmxCb3dvTnY3ZHpZK1NlMDFRcW5wNkZSeGU2czE2Y3FZNDZVeXF1QlY0?= =?utf-8?B?ZGQ4N2xRWFJ1RlR0RmpyNXR6WDI3Zk1OQTAwNG81dGlDeittNGtZb1JQYUI4?= =?utf-8?B?VjR3Q1lPYjNKck1qc3NtNkhpbHpxazREdUM4TzVOYzdmN1YxZmRnNWpzZEVT?= =?utf-8?B?aFUwT0RLU3VTYzUwcEgxUUNGcGI2L2tWSkZLSEV4NnlFL3VwbnNoTW5oRlU3?= =?utf-8?B?bXZJQWZUdXkrMEVFZGtJS0ZIMXlTdmIxN3dqSU95RVZxdDVhUnVDcmNkdUJs?= =?utf-8?B?ZlFVUS9HVVhsemh0aGNna3FLRXRYUWs1WEUrMjN0NncyNXRTMGswdVQ3WFFx?= =?utf-8?B?VzhwZnhNMWF4STdpUENBL25vSHNEM3AzcHR4WmQrRTNxOGxPbUJ1VHo5TmNi?= =?utf-8?B?Rm9HVzEzN0pIV1JMTVdzWGpDdHJCMnpSUGZQT2M5dWs2UldMcXhabVB1SVJk?= =?utf-8?B?UUlkMlJlS0dVa04xVCtSMGdGNlZKUTdoL1RBMzJsd3ZKWEdqZ2tNR29uUm0y?= =?utf-8?B?Q3YxYmZxbk41WU1MbE93bDJCRVlnTFoxaHB5WWpyd0JyL1o2ZG5DcTJFbzFF?= =?utf-8?B?bW5tYVdVT2M2bnB6NllEUmZIdWpQdU9GbGthSC9pNDFSVEN2Sjh3MHZzUXgr?= =?utf-8?B?em1MMEFvSmV4Wnd3WTdhamM4Z0ZRSE5vMUZ3RTVVVFVGT1BEK3lCMDMrSldr?= =?utf-8?B?ZDMvRnk4SVFzNmY0WU5XV25GK3J0bEJxek9NYW5FZnpacDdiM3pDYmZhSmNR?= =?utf-8?B?MFlpMHJHcVArcHExQWd4UXgyYzIzN3NlSFIzaGswYmZzcGE1SUhhQ25vVHJm?= =?utf-8?B?ejF1cWhneWFzdGdQWlNKcnFQUWVLdzNqZlBYY2NwRktyWEtTVWxBNDJSUXBi?= =?utf-8?B?clFBTFFhZzh2V3pDbUtOdERJbFFjWjBNM1p0eEYrOXprOFhzRi85V3RTMlRu?= =?utf-8?B?L3d6bTFWZ0hlKzk0YjBwWVh4ZlY0SElJVktNVWtWTW9XbVU2NExqS09PeEww?= =?utf-8?B?SllsTE92TzU0ZGNEc2F3K2RMb3NyTUx5SW9Oa2JucCtaWVJVdlV5dlFpWDhL?= =?utf-8?B?WkpJMzFSbW8yR1M1QTFPTmFuSUJnL08zdm8yUHNKRitCcVVKZlhlK3B2aW05?= =?utf-8?B?MS9ObitkU3NqZUJmVzJWSjNicWpveGVMUUd6bmg0NjdheWxJaitpdG1DRTls?= =?utf-8?B?SjBpZVVMdGZ2RDdaLzNaUmlhTmtBUkVyVnA3QThlaExwQ3RKQzZhQlZlMVUr?= =?utf-8?B?ZTVoOUcxWDB6UzVIV2xHU0E0QnRHM3ExaWdIVUFNR21SK3U0TWhpZUozejRs?= =?utf-8?Q?LPTDAUYF2A3e2Z3aoAhYvh4KkgYYU/er?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(3846002)(105586002)(8936002)(106356001)(6116002)(9326002)(81156014)(8676002)(81166006)(6346003)(6436002)(6306002)(236005)(229853002)(2906002)(6512007)(5660300002)(6486002)(7736002)(68736007)(86362001)(97736004)(82746002)(54896002)(53936002)(93886005)(316002)(4326008)(478600001)(66066001)(606006)(25786009)(99286004)(54906003)(14454004)(6506007)(53546011)(102836004)(76176011)(446003)(110136005)(11346002)(36756003)(186003)(486006)(476003)(2616005)(26005)(71200400001)(83716004)(256004)(14444005)(71190400001)(58126008)(33656002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4000; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Rvf9MD/m5gZ4XzJm4U2aVnTN0yNRtisp7QzsUy5eliow3W1/4R6Zwo4vQVjGQ4TAbVZQltw8Y/TCc2Gv3H6q1pB+NvCW8zOIVYjJbM2SlQ1cRGfoL7fVk6BEjZAUc1lFmZPfjHei7EygLVSzExFzxSVmmAZUYqhyugqNnRw1z06WOvdgoJqe2HhQdoTDfDNI8VzhtbE2PJkrtRN34IuS8qVoFxCaobqVRl15MrHnvt4WNpXg6KD9Qt+w4GG+XMNy/s7QcoJCaCVz1cn1r//qogmiNSa/8x0JMgPO8uqlWeghtWZnHWx+AGvgTeug08SRV9conoe/UM58SNXyqIuJgWdTo3dyTJLu9SHqmxRckjtGfAd9aaA0P6/62RQiDeyyMhXb5o5cpU9ndl8dQCWX+AmdyoKbkuuvKGqW0nuTLqQ= Content-Type: multipart/alternative; boundary="_000_542FBF1D4D614E458CD2CE9EC8BF6A38ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 68e252b2-0f64-4df8-bd27-08d6961dbd1b X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 03:52:58.9172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4000 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 03:53:07 -0000 --_000_542FBF1D4D614E458CD2CE9EC8BF6A38ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KU28gdGhlIHRleHQgYmVsb3cgaXMgZm9yIHdoYXQgeW91IGhhZCBtZW50aW9u ZWQgaW4gYSBwcmV2aW91cyBlbWFpbDog4oCcVGhlIGRyYWZ0IHByb3Bvc2VzIHRvIHVwZGF0ZSBS RkMgNTg4MCBpbiByZWdhcmQgdG8gdGhlIGJlaGF2aW9yIG9mIEJGRCBzeXN0ZW0gaW4gRGVtYW5k IG1vZGUgc28gdGhhdCBzdWNoIHN5c3RlbSBNQVkgc3RhcnQgUG9sbCBzZXF1ZW5jZSB0byBpbmZv cm0gdGhlIHJlbW90ZSBCRkQgc3lzdGVtIG9mIHRoZSBjaGFuZ2UgaW4gQkZEIHNlc3Npb24gc3Rh dGUsIGkuZS4gc2lnbmFsIFJESS7igJ0gQnV0IGlzbuKAmXQgdGhhdCBhbHJlYWR5IGNvdmVyZWQg aW4gc2VjdGlvbiA2LjY8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODAjc2VjdGlv bi02LjY+IG9mIDU4ODA/DQoNCg0KICAgSWYgRGVtYW5kIG1vZGUgaXMgYWN0aXZlIG9uIGVpdGhl ciBvciBib3RoIHN5c3RlbXMsIGEgUG9sbCBTZXF1ZW5jZQ0KDQogICBNVVNUIGJlIGluaXRpYXRl ZCB3aGVuZXZlciB0aGUgY29udGVudHMgb2YgdGhlIG5leHQgQkZEIENvbnRyb2wNCg0KICAgcGFj a2V0IHRvIGJlIHNlbnQgd291bGQgYmUgZGlmZmVyZW50IHRoYW4gdGhlIGNvbnRlbnRzIG9mIHRo ZQ0KDQogICBwcmV2aW91cyBwYWNrZXQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgUG9sbCAo UCkgYW5kIEZpbmFsIChGKQ0KDQogICBiaXRzLiAgVGhpcyBlbnN1cmVzIHRoYXQgcGFyYW1ldGVy IGNoYW5nZXMgYXJlIHRyYW5zbWl0dGVkIHRvIHRoZQ0KDQogICByZW1vdGUgc3lzdGVtIGFuZCB0 aGF0IHRoZSByZW1vdGUgc3lzdGVtIGFja25vd2xlZGdlcyB0aGVzZSBjaGFuZ2VzLg0KDQpSZWdh cmRzLA0KUmVzaGFkIChubyBoYXQpLg0KDQpGcm9tOiBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lA Z21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBGZWJydWFyeSAxOCwgMjAxOSBhdCAxOjAzIFBNDQpU bzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4NCkNjOiAiUmVzaGFkIFJhaG1hbiAocnJh aG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4sIE1hcnRpbiBWaWdvdXJldXggPG1hcnRpbi52aWdv dXJldXhAbm9raWEuY29tPiwgInJ0Zy1iZmRAaWV0Zi5vcmciIDxydGctYmZkQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFdHIEFkb3B0aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LW1pcnNreS1iZmQtbXBs cy1kZW1hbmQNCg0KSGkgSmVmZiwNCmhlcmUncyB0aGUgdGV4dCBmcm9tIHRoZSBkcmFmdCB0aGF0 IGRlc2NyaWJlcyB0aGUgYmVoYXZpb3Igb24gdGhlIEJGRCBzeXN0ZW06DQogICBJZiB0aGUgRGV0 ZWN0aW9uIHRpbWVyIGF0IHRoZSBlZ3Jlc3MgTEVSIGV4cGlyZXMgaXQgTVVTVCBzZW5kIEJGRA0K ICAgQ29udHJvbCBwYWNrZXQgdG8gdGhlIGluZ3Jlc3MgTEVSIHdpdGggdGhlIFBvbGwgKFApIGJp dCBzZXQsIFN0YXR1cw0KICAgKFN0YSkgZmllbGQgc2V0IHRvIERvd24gdmFsdWUsIGFuZCB0aGUg RGlhZ25vc3RpYyAoRGlhZykgZmllbGQgc2V0IHRvDQogICBDb250cm9sIERldGVjdGlvbiBUaW1l IEV4cGlyZWQgdmFsdWUuICBUaGUgZWdyZXNzIExFUiBzZW5kcyB0aGVzZQ0KICAgQ29udHJvbCBw YWNrZXRzIHRvIHRoZSBpbmdyZXNzIExFUiBhdCB0aGUgcmF0ZSBvZiBvbmUgcGVyIHNlY29uZA0K ICAgdW50aWwgZWl0aGVyIGl0IHJlY2VpdmVzIHRoZSB2YWxpZCBmb3IgdGhpcyBCRkQgc2Vzc2lv biBjb250cm9sDQogICBwYWNrZXQgd2l0aCB0aGUgRmluYWwgKEYpIGJpdCBzZXQgZnJvbSB0aGUg aW5ncmVzcyBMRVIgb3IgdGhlIGRlZmVjdA0KICAgY29uZGl0aW9uIGNsZWFycyBhbmQgdGhlIEJG RCBzZXNzaW9uIHN0YXRlIHJlYWNoZXMgVXAgc3RhdGUgYXQgdGhlDQogICBlZ3Jlc3MgTEVSLg0K DQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBNb24sIEZlYiAxOCwgMjAxOSBhdCA5OjM0IEFNIEplZmZy ZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4gd3JvdGU6DQpP biBNb24sIEZlYiAxOCwgMjAxOSBhdCAwODo0ODowOEFNIC0wODAwLCBHcmVnIE1pcnNreSB3cm90 ZToNCj4gQXMgZm9yIHlvdXIgcXVlc3Rpb24gb2Ygd2hhdCBpcyB0aGUgY2hhbmdlIHByb3Bvc2Vk IGluIHRoZSBkcmFmdCBJJ2xsIHBvaW50DQo+IHRvIHNlY3Rpb24gNi42IFJGQyA1ODgwIHRoYXQg ZGVzY3JpYmVzIHRoZSBEZW1hbmQgbW9kZS4gSXQgc3RhdGVzIHRoYXQgdGhlDQo+IHBlcmlvZGlj IHRyYW5zbWlzc2lvbiBvZiBjb250cm9sIG1lc3NhZ2VzIE1VU1QgYmUgc3RvcHBlZC4NCg0KQ29y cmVjdC4NCg0KPiBUaGUgZHJhZnQNCj4gZGVmaW5lcywgYW5kIHRoYXQgaXMgd2hhdCBJIGNvbnNp ZGVyIHRoZSB1cGRhdGUgdG8gc2VjdGlvbiA2LjYsIHRoZQ0KPiBwcm9jZWR1cmUgYnkgd2hpY2gg dGhlIHN5c3RlbSBpbiBEZW1hbmQgbW9kZSBpbml0aWF0ZXMgdGhlIFBvbGwgc2VxdWVuY2UgdG8N Cj4gaW5mb3JtIHRoZSByZW1vdGUgQkZEIHN5c3RlbSBvZiBSREkuDQoNCldvdWxkIHlvdSBjbGFy aWZ5IHdoZXJlIGluIHlvdXIgZHJhZnQgdGhpcyBpcyBkaXNjdXNzZWQ/DQoNCj4gR3JlZw0KDQot LSBKZWZmDQo= --_000_542FBF1D4D614E458CD2CE9EC8BF6A38ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3280E434FE765C46A0143C99F84F48D3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5IaSBHcmVnLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPlNvIHRoZSB0ZXh0IGJlbG93IGlzIGZvciB3aGF0IHlvdSBo YWQgbWVudGlvbmVkIGluIGEgcHJldmlvdXMgZW1haWw6IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZSBkcmFmdCBwcm9wb3NlcyB0byB1cGRhdGUgUkZDIDU4ODAgaW4gcmVn YXJkIHRvIHRoZSBiZWhhdmlvciBvZiBCRkQgc3lzdGVtIGluIERlbWFuZCBtb2RlIHNvDQogdGhh dCBzdWNoIHN5c3RlbSBNQVkgc3RhcnQgUG9sbCBzZXF1ZW5jZSB0byBpbmZvcm0gdGhlIHJlbW90 ZSBCRkQgc3lzdGVtIG9mIHRoZSBjaGFuZ2UgaW4gQkZEIHNlc3Npb24gc3RhdGUsIGkuZS4gc2ln bmFsIFJESS7igJ0gQnV0IGlzbuKAmXQgdGhhdCBhbHJlYWR5IGNvdmVyZWQgaW4NCjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3NlY3Rpb24tNi42Ij5zZWN0aW9u IDYuNjwvYT4gb2YgNTg4MD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgSWYgRGVtYW5k IG1vZGUgaXMgYWN0aXZlIG9uIGVpdGhlciBvciBib3RoIHN5c3RlbXMsIGEgUG9sbCBTZXF1ZW5j ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBNVVNUIGJlIGluaXRpYXRlZCB3aGVuZXZlciB0aGUgY29udGVudHMgb2Yg dGhlIG5leHQgQkZEIENvbnRyb2w8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcGFja2V0IHRvIGJlIHNlbnQgd291bGQg YmUgZGlmZmVyZW50IHRoYW4gdGhlIGNvbnRlbnRzIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcmV2aW91 cyBwYWNrZXQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgUG9sbCAoUCkgYW5kIEZpbmFsIChG KTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBiaXRzLiZuYnNwOyBUaGlzIGVuc3VyZXMgdGhhdCBwYXJhbWV0ZXIgY2hh bmdlcyBhcmUgdHJhbnNtaXR0ZWQgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHJlbW90ZSBzeXN0ZW0gYW5k IHRoYXQgdGhlIHJlbW90ZSBzeXN0ZW0gYWNrbm93bGVkZ2VzIHRoZXNlIGNoYW5nZXMuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlJlc2hhZCAobm8gaGF0KS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5HcmVnIE1pcnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDE5IGF0IDE6MDMgUE08YnI+DQo8Yj5UbzogPC9i PkplZmZyZXkgSGFhcyAmbHQ7amhhYXNAcGZyYy5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtSZXNoYWQgUmFobWFuIChycmFobWFuKSZxdW90OyAmbHQ7cnJhaG1hbkBjaXNjby5jb20mZ3Q7 LCBNYXJ0aW4gVmlnb3VyZXV4ICZsdDttYXJ0aW4udmlnb3VyZXV4QG5va2lhLmNvbSZndDssICZx dW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Zy1iZmRAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPlJlOiBXRyBBZG9wdGlvbiByZXF1ZXN0IGZvciBkcmFmdC1taXJza3kt YmZkLW1wbHMtZGVtYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSmVmZiwgPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGVyZSdzIHRoZSB0ZXh0IGZyb20gdGhlIGRyYWZ0IHRo YXQgZGVzY3JpYmVzIHRoZSBiZWhhdmlvciBvbiB0aGUgQkZEIHN5c3RlbTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7SWYgdGhlIERldGVjdGlvbiB0aW1lciBhdCB0aGUgZWdyZXNzIExFUiBleHBpcmVzIGl0IE1V U1Qgc2VuZCBCRkQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtDb250cm9sIHBhY2tldCB0byB0aGUgaW5ncmVzcyBMRVIgd2l0 aCB0aGUgUG9sbCAoUCkgYml0IHNldCwgU3RhdHVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7KFN0YSkgZmllbGQgc2V0IHRv IERvd24gdmFsdWUsIGFuZCB0aGUgRGlhZ25vc3RpYyAoRGlhZykgZmllbGQgc2V0IHRvPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7Q29udHJvbCBEZXRlY3Rpb24gVGltZSBFeHBpcmVkIHZhbHVlLiZuYnNwOyBUaGUgZWdyZXNz IExFUiBzZW5kcyB0aGVzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0NvbnRyb2wgcGFja2V0cyB0byB0aGUgaW5ncmVzcyBM RVIgYXQgdGhlIHJhdGUgb2Ygb25lIHBlciBzZWNvbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt1bnRpbCBlaXRoZXIgaXQg cmVjZWl2ZXMgdGhlIHZhbGlkIGZvciB0aGlzIEJGRCBzZXNzaW9uIGNvbnRyb2w8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtw YWNrZXQgd2l0aCB0aGUgRmluYWwgKEYpIGJpdCBzZXQgZnJvbSB0aGUgaW5ncmVzcyBMRVIgb3Ig dGhlIGRlZmVjdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwO2NvbmRpdGlvbiBjbGVhcnMgYW5kIHRoZSBCRkQgc2Vzc2lvbiBz dGF0ZSByZWFjaGVzIFVwIHN0YXRlIGF0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2VncmVzcyBMRVIuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEZlYiAxOCwgMjAxOSBhdCA5OjM0IEFNIEplZmZyZXkgSGFhcyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gTW9uLCBGZWIgMTgsIDIwMTkgYXQgMDg6NDg6MDhBTSAtMDgwMCwgR3JlZyBN aXJza3kgd3JvdGU6PGJyPg0KJmd0OyBBcyBmb3IgeW91ciBxdWVzdGlvbiBvZiB3aGF0IGlzIHRo ZSBjaGFuZ2UgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0IEknbGwgcG9pbnQ8YnI+DQomZ3Q7IHRvIHNl Y3Rpb24gNi42IFJGQyA1ODgwIHRoYXQgZGVzY3JpYmVzIHRoZSBEZW1hbmQgbW9kZS4gSXQgc3Rh dGVzIHRoYXQgdGhlPGJyPg0KJmd0OyBwZXJpb2RpYyB0cmFuc21pc3Npb24gb2YgY29udHJvbCBt ZXNzYWdlcyBNVVNUIGJlIHN0b3BwZWQuPGJyPg0KPGJyPg0KQ29ycmVjdC48YnI+DQo8YnI+DQom Z3Q7IFRoZSBkcmFmdDxicj4NCiZndDsgZGVmaW5lcywgYW5kIHRoYXQgaXMgd2hhdCBJIGNvbnNp ZGVyIHRoZSB1cGRhdGUgdG8gc2VjdGlvbiA2LjYsIHRoZTxicj4NCiZndDsgcHJvY2VkdXJlIGJ5 IHdoaWNoIHRoZSBzeXN0ZW0gaW4gRGVtYW5kIG1vZGUgaW5pdGlhdGVzIHRoZSBQb2xsIHNlcXVl bmNlIHRvPGJyPg0KJmd0OyBpbmZvcm0gdGhlIHJlbW90ZSBCRkQgc3lzdGVtIG9mIFJESS48YnI+ DQo8YnI+DQpXb3VsZCB5b3UgY2xhcmlmeSB3aGVyZSBpbiB5b3VyIGRyYWZ0IHRoaXMgaXMgZGlz Y3Vzc2VkPzxicj4NCjxicj4NCiZndDsgR3JlZzxicj4NCjxicj4NCi0tIEplZmY8bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_542FBF1D4D614E458CD2CE9EC8BF6A38ciscocom_-- From nobody Mon Feb 18 20:10:00 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D64130E6A for ; Mon, 18 Feb 2019 20:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClWC7MQkKr8P for ; Mon, 18 Feb 2019 20:09:56 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46020130E62 for ; Mon, 18 Feb 2019 20:09:56 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id z20so15177658ljj.10 for ; Mon, 18 Feb 2019 20:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EegwS9jq1kuV1djefdx9chRecc2z5ZTWgt3M7HU9mvA=; b=Yu1cMZ3O7+gX1aMtQddggvVO6eAmetJx/nZeuHyUE+gd1qAvonpg8VP+Aw+EThVlRp OGprTZTpUe0275UCYSJh0oDZ6u4BH6j46pDN4V0vnt04uzapxXmPvsrqZRymOV3dCV8B yt/9ChB4io8yAzR1cXuKZKnubbH3uoTgTtoXYknykTi9sYkb/g9zkn9Ph7gFe/Me4y9g h0zeDDp4se4Jp6s1NB+WYoIEj11jIzAAvAvG58Np6KHlcNBHUcJ8EjhDjyQ1g8rJQT0B QegUkD9ijvKAewBM3gdv+/sB45tBLn1c3OAP3qmNJplv0ZYq05m3tOs/ohH7Ja9fRzpg bGJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EegwS9jq1kuV1djefdx9chRecc2z5ZTWgt3M7HU9mvA=; b=o8aQmuzvg4IALlGx57xgQzy7crEsnmzGudj6sKkgWl58uQuGdUwrQScOrUM6144rgl 3blQJ+vrf60lSxdhTqr6XnaKVZbgS/lY3Z1BNMbejrcplwGcoHG0M8xWgEGZz68/LWGr vDkvb/iySkSLjKQJ36GWtbYZh5cKCdwmkxPQjAZRe/WlZT9bS8MyQxb6e9nw4EotA8Ee oPl3G4V1bsec2IGk7C4/vXZXtw+F8I6ofsCWLafz95BdWF70MP+brR7gms3swLSRQ8VU Lu4HFqzIFAgcMoYqOBPfieedpqaJx1tvz8/cYc/wCeWF+GLRHzJyubsIf/sg2TtG9jJ9 Wh5Q== X-Gm-Message-State: AHQUAuZG/T8D9t53uFW5sPKBRmq+KpCmiL2Ek29U8jC29BAjsTeFSfDH BqHVSJXcVLhIiEpf6S2jUeP/eJ+GaelLyJB1hJw= X-Google-Smtp-Source: AHgI3IZoyfxb7yRs+ARjdbR7owiWqHW+FU20LWnabG5pFu2dRU092olaRmztDg59+btz3VLQJvmXyEcnD5oaHNDOwq8= X-Received: by 2002:a2e:424f:: with SMTP id p76mr8527015lja.140.1550549394233; Mon, 18 Feb 2019 20:09:54 -0800 (PST) MIME-Version: 1.0 References: <20181210220953.GA6053@pfrc.org> <20190216163154.GC28950@pfrc.org> <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> In-Reply-To: <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> From: Greg Mirsky Date: Mon, 18 Feb 2019 20:09:43 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: "Reshad Rahman (rrahman)" Cc: Jeffrey Haas , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="000000000000d9a07305823769e0" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 04:09:59 -0000 --000000000000d9a07305823769e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for your question. I've thought that it is the case but then have asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead uses a combination of multicast and unicast Poll sequences to verify whether the particular MultipointTail considers the p2mp BFD session Up. Would it be simpler, assuming that the quote describes the same behavior as proposed in the draft, to enable MultipointTail to send Poll sequence with RDI? Thus I've concluded that RFC 5880 does not cover the scenario and have started the draft. Regards, Greg On Mon, Feb 18, 2019 at 7:53 PM Reshad Rahman (rrahman) wrote: > Hi Greg, > > > > So the text below is for what you had mentioned in a previous email: =E2= =80=9CThe > draft proposes to update RFC 5880 in regard to the behavior of BFD system > in Demand mode so that such system MAY start Poll sequence to inform the > remote BFD system of the change in BFD session state, i.e. signal RDI.=E2= =80=9D But > isn=E2=80=99t that already covered in section 6.6 > of 5880? > > > > If Demand mode is active on either or both systems, a Poll Sequence > > MUST be initiated whenever the contents of the next BFD Control > > packet to be sent would be different than the contents of the > > previous packet, with the exception of the Poll (P) and Final (F) > > bits. This ensures that parameter changes are transmitted to the > > remote system and that the remote system acknowledges these changes. > > > > Regards, > > Reshad (no hat). > > > > *From: *Greg Mirsky > *Date: *Monday, February 18, 2019 at 1:03 PM > *To: *Jeffrey Haas > *Cc: *"Reshad Rahman (rrahman)" , Martin Vigoureux < > martin.vigoureux@nokia.com>, "rtg-bfd@ietf.org" > *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand > > > > Hi Jeff, > > here's the text from the draft that describes the behavior on the BFD > system: > > If the Detection timer at the egress LER expires it MUST send BFD > > Control packet to the ingress LER with the Poll (P) bit set, Status > > (Sta) field set to Down value, and the Diagnostic (Diag) field set to > > Control Detection Time Expired value. The egress LER sends these > > Control packets to the ingress LER at the rate of one per second > > until either it receives the valid for this BFD session control > > packet with the Final (F) bit set from the ingress LER or the defect > > condition clears and the BFD session state reaches Up state at the > > egress LER. > > > > Regards, > > Greg > > > > On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas wrote: > > On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsky wrote: > > As for your question of what is the change proposed in the draft I'll > point > > to section 6.6 RFC 5880 that describes the Demand mode. It states that > the > > periodic transmission of control messages MUST be stopped. > > Correct. > > > The draft > > defines, and that is what I consider the update to section 6.6, the > > procedure by which the system in Demand mode initiates the Poll sequenc= e > to > > inform the remote BFD system of RDI. > > Would you clarify where in your draft this is discussed? > > > Greg > > -- Jeff > > --000000000000d9a07305823769e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad,
thank you for your question. I've thoug= ht that it is the case but then have asked why in draft-ietf-bfd-multipoint= -active-tail the MultipointHead uses a combination of multicast and unicast= Poll sequences to verify whether the particular MultipointTail considers t= he p2mp BFD session Up. Would it be simpler, assuming that the quote descri= bes the same behavior as proposed in the draft, to enable MultipointTail to= send Poll sequence with RDI? Thus I've concluded that RFC 5880 does no= t cover the scenario and have started the draft.

R= egards,
Greg

On Mon, Feb 18, 2019 at 7:53 PM Reshad Rahman= (rrahman) <rrahman@cisco.com&g= t; wrote:

Hi Greg,

= =C2=A0

So the te= xt below is for what you had mentioned in a previous email: =E2=80=9CThe draft proposes to update RFC 5880 in regar= d to the behavior of BFD system in Demand mode so that such system MAY start Poll sequence to inform the remote BFD system o= f the change in BFD session state, i.e. signal RDI.=E2=80=9D But isn=E2=80= =99t that already covered in section 6.6 of 5880?

=C2=A0

=C2=A0=C2=A0 If Demand mode is active on e=
ither or both systems, a Poll Sequence
=C2=A0=C2=A0 MUST be initiated whenever th=
e contents of the next BFD Control
=C2=A0=C2=A0 packet to be sent would be di=
fferent than the contents of the
=C2=A0=C2=A0 previous packet, with the exc=
eption of the Poll (P) and Final (F)
=C2=A0=C2=A0 bits.=C2=A0 This ensures that=
 parameter changes are transmitted to the
=C2=A0=C2=A0 remote system and that the re=
mote system acknowledges these changes.

= =C2=A0

Regards,<= u>

Reshad (n= o hat).

=C2=A0

From: = Greg Mirsky <gregimirsky@gmail.com= >
Date: Monday, February 18, 2019 at 1:03 PM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Martin Vigoureux = <martin.= vigoureux@nokia.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand=

=C2=A0

Hi Jeff,

here's the text from the draft that describes th= e behavior on the BFD system:

=C2=A0 =C2=A0If the Detection timer at the egress LE= R expires it MUST send BFD

=C2=A0 =C2=A0Control packet to the ingress LER with = the Poll (P) bit set, Status

=C2=A0 =C2=A0(Sta) field set to Down value, and the = Diagnostic (Diag) field set to

=C2=A0 =C2=A0Control Detection Time Expired value.= =C2=A0 The egress LER sends these

=C2=A0 =C2=A0Control packets to the ingress LER at t= he rate of one per second

=C2=A0 =C2=A0until either it receives the valid for = this BFD session control

=C2=A0 =C2=A0packet with the Final (F) bit set from = the ingress LER or the defect

=C2=A0 =C2=A0condition clears and the BFD session st= ate reaches Up state at the

=C2=A0 =C2=A0egress LER.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 18, 2019 at 9:34 AM Jeffrey Haas <jhaas@pfrc.org> wro= te:

On Mon, Feb 18, 2019 at 08:48:08AM -0800, Greg Mirsk= y wrote:
> As for your question of what is the change proposed in the draft I'= ;ll point
> to section 6.6 RFC 5880 that describes the Demand mode. It states that= the
> periodic transmission of control messages MUST be stopped.

Correct.

> The draft
> defines, and that is what I consider the update to section 6.6, the > procedure by which the system in Demand mode initiates the Poll sequen= ce to
> inform the remote BFD system of RDI.

Would you clarify where in your draft this is discussed?

> Greg

-- Jeff

--000000000000d9a07305823769e0-- From nobody Tue Feb 19 01:55:51 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAB5130DE3 for ; Tue, 19 Feb 2019 01:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv-EoM8DX6a4 for ; Tue, 19 Feb 2019 01:55:47 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E94130E81 for ; Tue, 19 Feb 2019 01:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cyv6kJuW8/GyLEis13VJONEBotQn1C3nngvz/z046/8=; b=C/B7N8fy8hmeY3t7paBKAHYhYAsYQ/6mO/TcqLTXVjBcal2p7enwq906iuHJDyAHellYipaGbs2AwnZ8/EBnjUzH/4kf5FgxTf6IuGIE9yKXWY/OGu8H9DVJhzNpkHJwVp6bd7bbIboUDf5P4O8l3lyK11SK9PEa94csigFzNDw= Received: from DB6PR0701MB2885.eurprd07.prod.outlook.com (10.168.83.18) by DB6PR0701MB2486.eurprd07.prod.outlook.com (10.168.76.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Tue, 19 Feb 2019 09:55:44 +0000 Received: from DB6PR0701MB2885.eurprd07.prod.outlook.com ([fe80::9d52:abd1:d9a0:3a18]) by DB6PR0701MB2885.eurprd07.prod.outlook.com ([fe80::9d52:abd1:d9a0:3a18%10]) with mapi id 15.20.1643.014; Tue, 19 Feb 2019 09:55:44 +0000 From: tom petch To: Jeffrey Haas , "rtg-bfd@ietf.org" Subject: Re: Progressing BFD authentication documents Thread-Topic: Progressing BFD authentication documents Thread-Index: AQHUyDlHyDsCW3in4k2Mm413naewVA== Date: Tue, 19 Feb 2019 09:55:44 +0000 Message-ID: <025701d4c839$0b3fab00$4001a8c0@gateway.2wire.net> References: <20190216170740.GA31558@pfrc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0334.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::34) To DB6PR0701MB2885.eurprd07.prod.outlook.com (2603:10a6:4:70::18) x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.156.84.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3fc71019-70d1-4d32-1729-08d696506a20 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DB6PR0701MB2486; x-ms-traffictypediagnostic: DB6PR0701MB2486: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(396003)(376002)(366004)(189003)(13464003)(199004)(106356001)(44716002)(476003)(486006)(446003)(84392002)(52116002)(99286004)(76176011)(81816011)(81686011)(62236002)(1556002)(4720700003)(71190400001)(53936002)(61296003)(7736002)(26005)(14496001)(105586002)(110136005)(186003)(71200400001)(305945005)(478600001)(66066001)(14444005)(256004)(2501003)(86362001)(86152003)(6306002)(6512007)(9686003)(966005)(81156014)(5660300002)(6346003)(3480700005)(6246003)(6436002)(316002)(8676002)(102836004)(81166006)(386003)(8936002)(97736004)(6506007)(25786009)(68736007)(33896004)(14454004)(50226002)(6116002)(44736005)(3846002)(229853002)(2906002)(6486002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2486; H:DB6PR0701MB2885.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfa@btconnect.com; x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2486; 23:9v30nU604UD93waHX32/VjKPoylpAJlRp8coU?= =?iso-8859-1?Q?+UQ+Z/w4XplWyi0aqSq4qtPsh2bee2mW/iG+nDI+eFWEh72V7JM4y8OI1D?= =?iso-8859-1?Q?e9fiiA9D3DXiOx8Unu5HwuEibFaVjsXdihIOoD3I2cBR4VSYDy3MWqYbwz?= =?iso-8859-1?Q?aQUjps7tl64We715v7W8Iv+crZO509uke2ymcolDKodlD3W9CcJTqfzict?= =?iso-8859-1?Q?09sOuKxKRDERCpyyy5ACENG5CLSgEfz3SzvTfyx8WNpUZle/z+WbfOdAVe?= =?iso-8859-1?Q?LAZn8kHAPHN8A0ji0NuQ/8PFLihVqa4/2Dq7JuL3NSTFPrH1Gnlm6ekmMr?= =?iso-8859-1?Q?oR0VXVAMqHONaZ2L/F96Lc3/iGOrDIN4HSc23nEMHK/YHeqmrQxJihuEQm?= =?iso-8859-1?Q?qrxaefY411tf2nZeX6vH1mcUTPu7qBd6s8Bmpz7yO65vcrGHT6Vbe5mf3j?= =?iso-8859-1?Q?5gR6LYxr7XVMEZb4uc0NAAYB9bqYf7SSJeXnAQ6Cj+GM6mFALqxoEPpEjx?= =?iso-8859-1?Q?TsJmkY1HQUIl8cskIRbNx6dyLJbsGAExRn6NDGCmZ0masv4Se8lVuZNH5O?= =?iso-8859-1?Q?kP9YXcLgKDEY0uazu2bJfG5wOf6KcoPc5C2ANqaStLl9QhmtKNH5HIfr3Z?= =?iso-8859-1?Q?3nk5B9wKP3Mc0zyDbqjFeIj98zwhylxZAGx+uTSlk07p3E9bBD0CPaFQt0?= =?iso-8859-1?Q?HlBkfnVjavx5qhqcpcwao3Mj4NrSbT0QB8StRJfjcwyW9bAtj774qYX2tB?= =?iso-8859-1?Q?y4d5ZQsvqcQ2YA4E/UBUrWrTMrOf7NfpnzTlFgWsNdHqNBPrU4dwYOUW9C?= =?iso-8859-1?Q?vm3Ixet+tG2G+CesADl1qw6qV1tbSQeKu1ScUDfDat1BISd+396XrH+5qu?= =?iso-8859-1?Q?JliX04nWiQEj4b2cbzf+oiQEQtloMd4rjuxYbpBPa2ryYL6tqhjTXFlin1?= =?iso-8859-1?Q?PuO3aK6GZNUecttXgxx/rPLL3oDbIPoe79ncQPFXAS5x4XVIt5CQ+NC50x?= =?iso-8859-1?Q?+CftIDioyegoe+lqWid7i4ngDws3yE32wDWt0NFrxlZng4I12/Bur5ZEFA?= =?iso-8859-1?Q?zusMlVzn63CFZevNmkULFsW0Us3V1gHuJNf2eX7ejoE4nDw90J85JCGLYt?= =?iso-8859-1?Q?6FY6X7N1Uwt4mGf6NtUhFV9ySBtwIc5RiZlz/Xfnp3NFBONoJCxqAMd1GQ?= =?iso-8859-1?Q?SGazZ1+gRs3ciSv2l67WGb7cFdNFbDsZEG1FH5Kxj5cgvgUlMt2XvAuRfH?= =?iso-8859-1?Q?P/VUJkmQbtyWHRwf51x5et6B5VcMVGwLfwUHw4wi1bS6SweeiExwSpSUKF?= =?iso-8859-1?Q?LFnwmZvHbo6hAv74qbwzObe1l1ZDKpBRF7hSameogb3ODzTw5CV111K8Te?= =?iso-8859-1?Q?Ld6lOCIUhtBnM3PH6p3hIYVp/+gosDz8/0mxzbVPaK1hV9OTVgtYR2Jj/C?= =?iso-8859-1?Q?6aLb30085smW+RHACkWzG8O+cOg/nv8HWEPo94QCyeLg40miI4npO/iQJI?= =?iso-8859-1?Q?EN3Y60jvIlQq8lG6kJ+bXPN7F84D6hwycaEGD7FGkTGG7ch/RyPgJ88h3h?= =?iso-8859-1?Q?gd4cthj51aCh40yqPhf9qA9r27Z7B+/tObKG63i+0+tHsKYuoVrgfIpCBV?= =?iso-8859-1?Q?2L0Y8/9RLYHHiipD6UJh4anA+9gsD3lpmU=3D?= x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RqUywGHj03qwbWlyVtFKj0uJZcm0CZSD2xTHe6sfCHcvtzOU3QKD6msrTgctl8lsyMDfys+bhFg57UY5wV9UGdtDi3H7b+xYojj37wNdX14aChi9AFDtqSCRujTMslM7EtdSdxcmNg0X/Ms3lHa+7azelS+aBoBhGW6XRUyVT1KAlHHoWO3vYPnI1FLSMcQoeCcRd6O5slU+omTRPuTLOaJmwtuUkLdHeoXoZLPmPYmLXt2+7zElhkVsAUZBR0+qBiJ0nOtnxR+DSPm9UD8paeNepX62qUS2Uzmg126j1md35YwxvJt+VsCNbttnn15AZyUVJdKoNbMomcU1GfrmYo6pEafiI0T90Zcm81zTw3y+BmBtsriwunSSeCfcIuFbf/oJ4geCH75zoeUyVq3jSLBSUtLEAJyJMcqRWdIU6Fo= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fc71019-70d1-4d32-1729-08d696506a20 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 09:55:43.9159 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2486 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 09:55:50 -0000 Jeff Two of the three I-D you mention have timed out and are not available through the usual channels. I suggest that the first step needs to be a refresh so that they are available. (Yes, I know I can jump through hoops and find obsoleted I-Ds but life is too short:-) Tom Petch ----- Original Message ----- From: "Jeffrey Haas" To: Sent: Saturday, February 16, 2019 5:07 PM > Working Group, > > On March 28, 2018, we started Working Group Last Call on the following document > bundle: > > draft-ietf-bfd-secure-sequence-numbers > draft-ietf-bfd-optimizing-authentication > draft-ietf-bfd-stability > > The same day, Mahesh Jethanandani acknowledged there was pending IPR > declarations against these drafts. An IPR declaration was finally posted on > November 1, 2018. In particular, it notes a patent. The licenseing is > RAND. > > https://datatracker.ietf.org/ipr/3328/ > > In the time since the WGLC was requested, there were a number of technical > comments made on these drafts. It's my belief that all substantial > technical comments had been addressed in the last posted version of these > documents. Note that there was one lingering comment about Yang > considerations for the BFD module with regard to enabling this optimized > authentication mode which can be dealt with separably. > > The chairs did not carry out a further consensus call to ensure that there > are no further outstanding technical issues. > > On November 21, Greg Mirsky indicated an objection to progressing the > document due to late disclosure. > > https://mailarchive.ietf.org/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtD o > > Since we are a little over a month prior to the upcoming IETF 104, this > seems a good time to try to decide how the Working Group shall finish this > work. Since we are meeting in Prague, this may progress to microphone > conversation. > > For the moment, the chairs' perceived status of the documents are: > - No pending technical issues with the documents with one known issue. > - Concerns over late disclosure of IPR. > - No solid consensus from the Working Group that we're ready to proceed. > This part may be covered by a future consensus call, but let's hear list > discussion first. > > -- Jeff > From nobody Tue Feb 19 09:42:17 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5C4130F7B for ; Tue, 19 Feb 2019 09:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7nKmx8RERs0 for ; Tue, 19 Feb 2019 09:42:14 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96F130F5B for ; Tue, 19 Feb 2019 09:42:14 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 381D21E2D8; Tue, 19 Feb 2019 12:41:11 -0500 (EST) Date: Tue, 19 Feb 2019 12:41:10 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190219174109.GN28950@pfrc.org> References: <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:42:16 -0000 A reminder from 5880's state machine (6.8.6) : Else [...] : Else (bfd.SessionState is Up) : If received State is Down : Set bfd.LocalDiag to 3 (Neighbor signaled : session down) : Set bfd.SessionState to Down : : Check to see if Demand mode should become active or not (see : section 6.6). [...] : If the Poll (P) bit is set, send a BFD Control packet to the : remote system with the Poll (P) bit clear, and the Final (F) bit : set (see section 6.8.7). A change of state doesn't need a poll sequence. A change of state is dealt with prior to considering demand mode considerations. Poll behavior is considered after both of these. On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote: > Hi Reshad, > thank you for your question. I've thought that it is the case but then have > asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead uses > a combination of multicast and unicast Poll sequences to verify whether the > particular MultipointTail considers the p2mp BFD session Up. Because tails are normally expected to be silent. A core motivation of splitting the active tail procedures from the original draft is there are many applications where the head doesn't need or want the state from the tails. In cases where the head does care, the differing procedures attempts to determine a given tail's perception of the state. A multipoint poll would determine if the tail is hearing the session via the multipoint BFD packets. In absence of that, unicast might be used, although it doesn't verify that multipoint connectivity is working. Section 5 of the draft goes through the different scenarios. > Would it be > simpler, assuming that the quote describes the same behavior as proposed in > the draft, to enable MultipointTail to send Poll sequence with RDI? Thus > I've concluded that RFC 5880 does not cover the scenario and have started > the draft. You keep on mentioning RDI. Are you intending to have this in the context of RFC 6428? If so, the discussion is really against the procedures in that RFC which are deviations from core RFC 5880/5884 behaviors. This is really the point lacking clarity. -- Jeff From nobody Tue Feb 19 13:40:06 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85824130FA8 for ; Tue, 19 Feb 2019 13:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30-MGG8MLRre for ; Tue, 19 Feb 2019 13:40:02 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DC7130FA5 for ; Tue, 19 Feb 2019 13:40:02 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id p8so11063311plo.2 for ; Tue, 19 Feb 2019 13:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njQYlEAaCIzu32GJyls4QigFtsPmLewE8a50/vcBom8=; b=IthzMEYgMKmG9nFyWbiVIerD5rXSCJ7gz+0jdS0eLdCXPY178uwauhLFao34wPafuf v71ILMw3hzEbKxUYWqE4gyIQabwHUwpZNQB352vpHR5CKz9/wFcEF97mGErwOAWXvM5V ZLOK+CEYo37SNb7h+ZX8G0FmSS0Tt8PU3EPj820B9nj1oahpdt6ublwSF7lU/97UX+cV fnEVSFDkbydhCIOGcZ9XbOgpCAhNSWZeA0gDRkt09HPXtCyUlScA7qMdCh62jRrH/eOR R4+4tpOxSOSpTB0JFHk2ogCvNjm1z9YjGSmI852L9F5uia8mEX1Q+6a3T+0lhqYhBFkk 9CvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=njQYlEAaCIzu32GJyls4QigFtsPmLewE8a50/vcBom8=; b=N2Nb2LhgMYVRG7u4QMSM3JhrNqHF+4CeMyjUo/G8pTHYN4+CH6H8R9xiEoaZ2cfKSr T26sE+Rrb5p/JI2gzxV3FV3PscklCBrDYazMAdwjshIOpHjZEUekMtvdmAbDvjm8tKt0 FOQc5kGuQwxB034Eyg7JdhMIj8J+Hv7+08ee2MlI+I3uPgvPcGJCSLBR2cQ4BHpSvNwZ vhCusVwjPCXBP4uOU72+x2H6YzMCDSAwwGNsy50Q+vP9mKVZBFYokausJZHo2y4xsetM H2MzopSspPcccRnX9Yg7D0DR5KSzOj82M2GVKJEv+wuLjt2uQ/AH17mIn3KSd8LU/nUl nCXw== X-Gm-Message-State: AHQUAuYTUZhUTW4RzJ2m0qG8xBofa/0HImThy8okrnc4qf/rUWyrnPhB /UmEN7T4smgMv5v4xspzas0= X-Google-Smtp-Source: AHgI3IY+hGfDUYxaWvdcilUJNSMwfUS7M0cXT3FIj3WB+P/Va0yk1aQNWp6+eXoUoIXqxphGRd1C/A== X-Received: by 2002:a17:902:34a:: with SMTP id 68mr33591092pld.268.1550612401598; Tue, 19 Feb 2019 13:40:01 -0800 (PST) Received: from [10.5.5.171] ([47.88.78.156]) by smtp.gmail.com with ESMTPSA id e63sm20800922pfb.25.2019.02.19.13.39.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 13:40:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Progressing BFD authentication documents From: Mahesh Jethanandani In-Reply-To: <025701d4c839$0b3fab00$4001a8c0@gateway.2wire.net> Date: Wed, 20 Feb 2019 05:39:54 +0800 Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <8C156D80-7B7C-4BCE-B550-8684185CC064@gmail.com> References: <20190216170740.GA31558@pfrc.org> <025701d4c839$0b3fab00$4001a8c0@gateway.2wire.net> To: tom petch X-Mailer: Apple Mail (2.3445.9.1) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 21:40:04 -0000 Hi Tom, We are in the process of refreshing all the drafts that have expired. Cheers. > On Feb 19, 2019, at 5:55 PM, tom petch wrote: > > Jeff > > Two of the three I-D you mention have timed out and are not available > through the usual channels. > > I suggest that the first step needs to be a refresh so that they are > available. > > (Yes, I know I can jump through hoops and find obsoleted I-Ds but life > is too short:-) > > Tom Petch > > ----- Original Message ----- > From: "Jeffrey Haas" > To: > Sent: Saturday, February 16, 2019 5:07 PM >> Working Group, >> >> On March 28, 2018, we started Working Group Last Call on the following > document >> bundle: >> >> draft-ietf-bfd-secure-sequence-numbers >> draft-ietf-bfd-optimizing-authentication >> draft-ietf-bfd-stability >> >> The same day, Mahesh Jethanandani acknowledged there was pending IPR >> declarations against these drafts. An IPR declaration was finally > posted on >> November 1, 2018. In particular, it notes a patent. The licenseing > is >> RAND. >> >> https://datatracker.ietf.org/ipr/3328/ >> >> In the time since the WGLC was requested, there were a number of > technical >> comments made on these drafts. It's my belief that all substantial >> technical comments had been addressed in the last posted version of > these >> documents. Note that there was one lingering comment about Yang >> considerations for the BFD module with regard to enabling this > optimized >> authentication mode which can be dealt with separably. >> >> The chairs did not carry out a further consensus call to ensure that > there >> are no further outstanding technical issues. >> >> On November 21, Greg Mirsky indicated an objection to progressing the >> document due to late disclosure. >> >> > https://mailarchive.ietf.org/arch/msg/rtg-bfd/u8rvWwvDWRKI3jseGHecAB9WtD > o >> >> Since we are a little over a month prior to the upcoming IETF 104, > this >> seems a good time to try to decide how the Working Group shall finish > this >> work. Since we are meeting in Prague, this may progress to microphone >> conversation. >> >> For the moment, the chairs' perceived status of the documents are: >> - No pending technical issues with the documents with one known issue. >> - Concerns over late disclosure of IPR. >> - No solid consensus from the Working Group that we're ready to > proceed. >> This part may be covered by a future consensus call, but let's hear > list >> discussion first. >> >> -- Jeff >> > Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Feb 19 14:48:16 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8410130E66; Tue, 19 Feb 2019 14:48:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-secure-sequence-numbers-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155061648790.20620.16419336195751568218@ietfa.amsl.com> Date: Tue, 19 Feb 2019 14:48:07 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 22:48:08 -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 WG of the IETF. Title : Secure BFD Sequence Numbers Authors : Mahesh Jethanandani Sonal Agarwal Ashesh Mishra Ankur Saxena Alan DeKok Filename : draft-ietf-bfd-secure-sequence-numbers-03.txt Pages : 6 Date : 2019-02-19 Abstract: This document describes a security enhancements for the BFD packet's sequence number. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-secure-sequence-numbers-03 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-secure-sequence-numbers-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-secure-sequence-numbers-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 Tue Feb 19 15:59:53 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8613104F for ; Tue, 19 Feb 2019 15:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLKYizPhoRte for ; Tue, 19 Feb 2019 15:59:49 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76396130FD0 for ; Tue, 19 Feb 2019 15:59:48 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id l5so15779435lje.1 for ; Tue, 19 Feb 2019 15:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q26tU34DYleVpoJYqAKFZXq4L3JpliDr6zIVbFoGnL4=; b=F+uz9Hp4uw6Spl466AeGrBJm7gR0fQ15DgbW+cPtI1icWLpqklqJ/efGp+oU6GQIDX w3EPyV90L+QrnVheDps442VAxJMEsX4dfCJrA22SduZE+Vcqa/2LvyCW1r9jcRf3Dxxd XijyVWQujuiWYu/DUItubvfq0xbZ+kiWWcXpaw0ZUdHH9T58GgpimjJ5OwIS5oSHmSJA rBqoxE2cM35E1LL5TezNoSINunt6TPO1YiJxjMDnCv9Uuf8UHOu/+ewvn4bwgfrh7Idr YREOLrf5cHHXI7hqLxdMpZMVH/yN+gDG3c60kXLrC3zhYtplFRzXQ8iMAtaLzXz/g07J unKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q26tU34DYleVpoJYqAKFZXq4L3JpliDr6zIVbFoGnL4=; b=H7fVYxaSAaUAPB3uBPspy4s5U2jcinpF29fSoZlMfj432q5kLiGIAn0QxeVXLggWbg 1zbWOjJQXqwfWeTZDOT0rGKmaCk/xkwBs/nA5t6r16OiyK8vkqYugfoXVIVNJSyNi50x EIBhtROtxfJgvNB4A2xBumY6cuhKn8cNxO9huiB1M9eTC5gLjDbW/466qxfSS6omlapM 9LQgURx5nmucXBWB0jhXSyLP5vMV8FOAjHLvyJ8xot/zMMbCEiS85PD7nZBUg/eBL6Sd nPONo5dSh4PLBcJUwM4JW3yAqDhxPF8nVT2fPfOppMrff3hBIVR6Aug2BkcyCBUpDC9/ DtVQ== X-Gm-Message-State: AHQUAuY/QxUUgLmYrNL4IUejCAZwWQu0MqDjYstwMYqivxgyb/h6hmzD JNpRGqaXHJUo/oQyxz5SgqLbc2mov3KnUzQvt1i1NcHx X-Google-Smtp-Source: AHgI3IZJGIynQ82r1Q25+zRKJ9ht4RNSHvZQSKlxJRmfqMASRadZwI2ALrX5rT4eDgbQVAb5AtqP2ihMIre/jHuiiYY= X-Received: by 2002:a2e:4c0a:: with SMTP id z10-v6mr18915776lja.85.1550620786309; Tue, 19 Feb 2019 15:59:46 -0800 (PST) MIME-Version: 1.0 References: <20190216184510.GF28950@pfrc.org> <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> In-Reply-To: <20190219174109.GN28950@pfrc.org> From: Greg Mirsky Date: Tue, 19 Feb 2019 15:59:36 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000002640da0582480929" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 23:59:51 -0000 --0000000000002640da0582480929 Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for pointing to the sloppy terminology I've used referring to what is the proposed update to RFC 5880. In fact, the draft, as I should have done too, refers to the Diag field. Below are quotes from RFC 5880 to help me explain the intended update: - is section 6.1 Poll sequence in Demand mode MAY be used by any peer to verify the bidirectional path continuity (connectivity): If either system wishes to verify bidirectional connectivity, it can initiate a short exchange of BFD Control packets (a "Poll Sequence"; see section 6.5) to do so. - similarly, the first paragraph in section 6.5: A Poll Sequence is an exchange of BFD Control packets that is used in some circumstances to ensure that the remote system is aware of parameter changes. It is also used in Demand mode (see section 6.6) to validate bidirectional connectivity. Again, no reference that the Poll sequence MAY be used to signal the change in the Diag field. - And the very last sentence of section 6.6: Resolving the issue of one system requesting Demand mode while the other requires continuous bidirectional connectivity verification is outside the scope of this specification. Is what is in the scope of the draft we discuss. (Apologies for taking too much time to find the right text in RFC 5880.) Regards, Greg On Tue, Feb 19, 2019 at 9:42 AM Jeffrey Haas wrote: > A reminder from 5880's state machine (6.8.6) > > : Else > [...] > : Else (bfd.SessionState is Up) > : If received State is Down > : Set bfd.LocalDiag to 3 (Neighbor signaled > : session down) > : Set bfd.SessionState to Down > : > : Check to see if Demand mode should become active or not (see > : section 6.6). > > [...] > : If the Poll (P) bit is set, send a BFD Control packet to the > : remote system with the Poll (P) bit clear, and the Final (F) bit > : set (see section 6.8.7). > > A change of state doesn't need a poll sequence. > A change of state is dealt with prior to considering demand mode > considerations. > Poll behavior is considered after both of these. > > > On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote: > > Hi Reshad, > > thank you for your question. I've thought that it is the case but then > have > > asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead > uses > > a combination of multicast and unicast Poll sequences to verify whether > the > > particular MultipointTail considers the p2mp BFD session Up. > > Because tails are normally expected to be silent. A core motivation of > splitting the active tail procedures from the original draft is there are > many applications where the head doesn't need or want the state from the > tails. > > In cases where the head does care, the differing procedures attempts to > determine a given tail's perception of the state. A multipoint poll would > determine if the tail is hearing the session via the multipoint BFD > packets. > In absence of that, unicast might be used, although it doesn't verify that > multipoint connectivity is working. Section 5 of the draft goes through > the > different scenarios. > > > Would it be > > simpler, assuming that the quote describes the same behavior as proposed > in > > the draft, to enable MultipointTail to send Poll sequence with RDI? Thus > > I've concluded that RFC 5880 does not cover the scenario and have started > > the draft. > > You keep on mentioning RDI. Are you intending to have this in the context > of RFC 6428? If so, the discussion is really against the procedures in > that > RFC which are deviations from core RFC 5880/5884 behaviors. > > This is really the point lacking clarity. > > -- Jeff > > --0000000000002640da0582480929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff= ,
thank you for pointing to the sloppy terminology I've used referr= ing to what is the proposed update to RFC 5880. In fact, the draft, as I sh= ould have done too, refers to the Diag field. Below are quotes from RFC 588= 0 to help me explain the intended update:
  • is section 6.1 = Poll sequence in Demand mode MAY be used by any peer to verify the bidirect= ional path continuity (connectivity):
=C2=A0 =C2=A0If either = system wishes to verify
=C2=A0 =C2=A0bidirectional connectivity, = it can initiate a short exchange of BFD
=C2=A0 =C2=A0Control pack= ets (a "Poll Sequence"; see section 6.5) to do so.
  • similarly, the first paragraph in section 6.5:
=C2=A0 =C2=A0A Poll Sequence is an exchange of BFD Control packets t= hat is used in
=C2=A0 =C2=A0some circumstances to ensure that the= remote system is aware of
=C2=A0 =C2=A0parameter changes.=C2=A0 = It is also used in Demand mode (see section 6.6)
=C2=A0 =C2=A0to = validate bidirectional connectivity.
Again, no reference th= at the Poll sequence MAY be used to signal the change in the Diag field.
  • And the very last sentence of section 6.6:
= =C2=A0 =C2=A0Resolving the issue of one system requesting Demand
= =C2=A0 =C2=A0mode while the other requires continuous bidirectional connect= ivity
=C2=A0 =C2=A0verification is outside the scope of this spec= ification.
Is what is in the scope of the draft we discuss.= (Apologies for taking too much time to find the right text in RFC 5880.)

Regards,
Greg

On T= ue, Feb 19, 2019 at 9:42 AM Jeffrey Haas <jhaas@pfrc.org> wrote:
A reminder from 5880's state machine (6.8.6)

:=C2=A0 =C2=A0 =C2=A0 =C2=A0Else
[...]
:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Else (bfd.SessionState is Up)
:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If received State i= s Down
:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set b= fd.LocalDiag to 3 (Neighbor signaled
:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0session down)
:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Set b= fd.SessionState to Down
:
:=C2=A0 =C2=A0 =C2=A0 =C2=A0Check to see if Demand mode should become activ= e or not (see
:=C2=A0 =C2=A0 =C2=A0 =C2=A0section 6.6).

[...]
:=C2=A0 =C2=A0 =C2=A0 =C2=A0If the Poll (P) bit is set, send a BFD Control = packet to the
:=C2=A0 =C2=A0 =C2=A0 =C2=A0remote system with the Poll (P) bit clear, and = the Final (F) bit
:=C2=A0 =C2=A0 =C2=A0 =C2=A0set (see section 6.8.7).

A change of state doesn't need a poll sequence.
A change of state is dealt with prior to considering demand mode
considerations.
Poll behavior is considered after both of these.


On Mon, Feb 18, 2019 at 08:09:43PM -0800, Greg Mirsky wrote:
> Hi Reshad,
> thank you for your question. I've thought that it is the case but = then have
> asked why in draft-ietf-bfd-multipoint-active-tail the MultipointHead = uses
> a combination of multicast and unicast Poll sequences to verify whethe= r the
> particular MultipointTail considers the p2mp BFD session Up.

Because tails are normally expected to be silent.=C2=A0 A core motivation o= f
splitting the active tail procedures from the original draft is there are many applications where the head doesn't need or want the state from th= e
tails.

In cases where the head does care, the differing procedures attempts to
determine a given tail's perception of the state.=C2=A0 A multipoint po= ll would
determine if the tail is hearing the session via the multipoint BFD packets= .
In absence of that, unicast might be used, although it doesn't verify t= hat
multipoint connectivity is working.=C2=A0 Section 5 of the draft goes throu= gh the
different scenarios.

>=C2=A0 Would it be
> simpler, assuming that the quote describes the same behavior as propos= ed in
> the draft, to enable MultipointTail to send Poll sequence with RDI? Th= us
> I've concluded that RFC 5880 does not cover the scenario and have = started
> the draft.

You keep on mentioning RDI.=C2=A0 Are you intending to have this in the con= text
of RFC 6428?=C2=A0 If so, the discussion is really against the procedures i= n that
RFC which are deviations from core RFC 5880/5884 behaviors.

This is really the point lacking clarity.

-- Jeff

--0000000000002640da0582480929-- From nobody Tue Feb 19 20:44:35 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3365130DBE for ; Tue, 19 Feb 2019 20:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBvKYJNbvki7 for ; Tue, 19 Feb 2019 20:44:32 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E6D1A12F18C for ; Tue, 19 Feb 2019 20:44:31 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id B52C61E2D8; Tue, 19 Feb 2019 23:43:30 -0500 (EST) Date: Tue, 19 Feb 2019 23:43:30 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190220044330.GA14326@pfrc.org> References: <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 20 Feb 2019 04:44:34 -0000 Greg, We seem now to be converging on the substance of your draft. Thanks for sticking with this. On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote: > thank you for pointing to the sloppy terminology I've used referring to > what is the proposed update to RFC 5880. In fact, the draft, as I should > have done too, refers to the Diag field. Below are quotes from RFC 5880 to > help me explain the intended update: > > - is section 6.1 Poll sequence in Demand mode MAY be used by any peer to > verify the bidirectional path continuity (connectivity): > > If either system wishes to verify > bidirectional connectivity, it can initiate a short exchange of BFD > Control packets (a "Poll Sequence"; see section 6.5) to do so. > > - similarly, the first paragraph in section 6.5: > > A Poll Sequence is an exchange of BFD Control packets that is used in > some circumstances to ensure that the remote system is aware of > parameter changes. It is also used in Demand mode (see section 6.6) > to validate bidirectional connectivity. > Again, no reference that the Poll sequence MAY be used to signal the change > in the Diag field. > > - And the very last sentence of section 6.6: > > Resolving the issue of one system requesting Demand > mode while the other requires continuous bidirectional connectivity > verification is outside the scope of this specification. > Is what is in the scope of the draft we discuss. (Apologies for taking too > much time to find the right text in RFC 5880.) I think we're still in the scope of what 5880 permits. Consider the following: :6.8.17. Concatenated Paths : : If the path being monitored by BFD is concatenated with other paths : (connected end-to-end in series), it may be desirable to propagate : the indication of a failure of one of those paths across the BFD : session (providing an interworking function for liveness monitoring : between BFD and other technologies). : [...] : : A system MAY signal one of these failure states by simply setting : bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD : session is not taken down. If Demand mode is not active on the : remote system, no other action is necessary, as the diagnostic code : will be carried via the periodic transmission of BFD Control packets. : If Demand mode is active on the remote system (the local system is : not transmitting periodic BFD Control packets), a Poll Sequence MUST : be initiated to ensure that the diagnostic code is transmitted. Note : that if the BFD session subsequently fails, the diagnostic code will : be overwritten with a code detailing the cause of the failure. It is : up to the interworking agent to perform the above procedure again, : once the BFD session reaches Up state, if the propagation of the : concatenated path failure is to resume. We thus see here: 1. You can propagate state, perhaps your RDI, in a session that is Up. 2. If we are in demand mode, by initiating the poll sequence. Your point about 6.6 and asymmetric configuration of demand mode perhaps should be considered in the context of the word "bidirectional". In a profile where we have gone half duplex on the session (one side async continuous, other demand), we're likely in a mode where we mostly want unidirectional information. This seems to be perhaps along the lines of what you're looking for. And in such a case, shifting into the poll to pass along RDI is perfectly reasonable. If the above reflects a rough understanding of the use case, the core content of your draft reduces to: - RFC 5880 permits state, such as RDI, to be communicated on an Up session when in demand mode via a poll sequence in the Diag field. -- Jeff From nobody Thu Feb 21 20:43:08 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77188128D52; Thu, 21 Feb 2019 20:43:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-stability-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155081058541.18600.8248280502945138701@ietfa.amsl.com> Date: Thu, 21 Feb 2019 20:43:05 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 04:43:06 -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 WG of the IETF. Title : BFD Stability Authors : Ashesh Mishra Mahesh Jethanandani Ankur Saxena Santosh Pallagatti Mach Chen Peng Fan Filename : draft-ietf-bfd-stability-03.txt Pages : 5 Date : 2019-02-21 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-stability-03 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-stability-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-stability-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 Sun Feb 24 09:53:39 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071A0128AFB for ; Sun, 24 Feb 2019 09:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euS47ejfDnFq for ; Sun, 24 Feb 2019 09:53:35 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF18124BF6 for ; Sun, 24 Feb 2019 09:53:34 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id q12so5197273lfm.0 for ; Sun, 24 Feb 2019 09:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XqqknZZ/khcW13sqgFL1E7t62OizjnA7uDjsPuRg7B0=; b=F4yPfvwTziNS15C9xCefXQw7NPmFxn47lKUWrI5RYg+o5iwuRUz5m+9BkqBAR85wCT 1TV4B8/5FQOviNfzzDUgjW9DzhN5mQ2jgaQTYYtwViejOJ/+aonpvcWeLSLnfoDmJQkB W83Gs1mtORIzPuBPgsM9UFsPvGXslVZbWlD5GauYstyYXZs3VHVt8DFynE6RsvgzF3Yo DG84zoitagzvyhQmXF2A5v43Eh99CFdUgA4C+gD+VUVg7JEpXQwb0AvfmQ/wKjImKEpA +sJZGyVvIHmD+/zeYHx7XS2qEqBRBSTS5eadBtg8hPunypYLHDzS7g8HaT9/KkH0SBCa byxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XqqknZZ/khcW13sqgFL1E7t62OizjnA7uDjsPuRg7B0=; b=IwisceR3s5XqqThbbcTB2+3L7VEfPaw9+4ZvKT+gIwu+tLOWuGhF93lGiphFO/BWaY +M/uCWE+0hQgYCb3SPHJhfSX4hVYEtnZ0cbGFL9K2r7wYKzsLPgPfiHlzLV7fIqbAm/m mik8YMBEPCOUIq8YszlS/WTs9bE7D4fONfcWH+G7o4sry/Bg+NOjpRcmVHVLiAWuDGN7 UYxBz9SC+3nK+SHDrXb9COnO8nWy4yCepQKm+DuFY4KVSY5PHxFcHLYd+Ko5RIhay9Hm E0SvsMCdzV1YtSxfkStS1oo5hnBOE7kLPaqtAWJf3TgU15JCP4ENGKqI9MwFSILfBlac xoCA== X-Gm-Message-State: AHQUAua/aXaI0pNwkCqhYrjb+Jp3PUiKn7ydwN0T8yuqyIje1Uvp8lus oHkO3qiycwgKGns8o8mNaB2aBZcNRQ3RwvWSMQs= X-Google-Smtp-Source: AHgI3IZ9lm/Us1UP1cwBy9QuFrmxhJ/vAP1N5EwSvItyMIzAKrU0ZKro6hycaA5TSi9dWxLssLFVYuvGamd9aw9vf28= X-Received: by 2002:a19:c6cd:: with SMTP id w196mr7513375lff.127.1551030812453; Sun, 24 Feb 2019 09:53:32 -0800 (PST) MIME-Version: 1.0 References: <20190218152544.GG28950@pfrc.org> <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> In-Reply-To: <20190220044330.GA14326@pfrc.org> From: Greg Mirsky Date: Sun, 24 Feb 2019 09:53:20 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000009cae470582a78065" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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, 24 Feb 2019 17:53:38 -0000 --0000000000009cae470582a78065 Content-Type: text/plain; charset="UTF-8" Hi Jeff, I'm glad that you feel that our discussion is helpful. I want to point that the use of the Poll sequence to communicate to the remote BFD system in the Concatenated Paths section is to relay the failure detected in the downstream segment of the multi-segment OAM domain. Also, section 6.8.17 does not specify how the upstream BFD system responds to the situation: Note that if the BFD session subsequently fails, the diagnostic code will be overwritten with a code detailing the cause of the failure. It is up to the interworking agent to perform the above procedure again, once the BFD session reaches Up state, if the propagation of the concatenated path failure is to resume. And so far we were discussing RFC 5880 though the scope of the draft is on the use of Demand mode over MPLS LSP. And the draft does describe how the BFD system acts after it receives the control message with Diag field set to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In that, I consider, the draft is complimentary to RFC 5884 whose scope is on the Asynchronous mode only. I believe that the draft addresses practical scenario with the technical and innovative solution. And it was recognized as such by several WG participants during the WG AP. Much appreciate your consideration. Regards, Greg On Tue, Feb 19, 2019 at 8:44 PM Jeffrey Haas wrote: > Greg, > > We seem now to be converging on the substance of your draft. Thanks for > sticking with this. > > On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote: > > thank you for pointing to the sloppy terminology I've used referring to > > what is the proposed update to RFC 5880. In fact, the draft, as I should > > have done too, refers to the Diag field. Below are quotes from RFC 5880 > to > > help me explain the intended update: > > > > - is section 6.1 Poll sequence in Demand mode MAY be used by any peer > to > > verify the bidirectional path continuity (connectivity): > > > > If either system wishes to verify > > bidirectional connectivity, it can initiate a short exchange of BFD > > Control packets (a "Poll Sequence"; see section 6.5) to do so. > > > > - similarly, the first paragraph in section 6.5: > > > > A Poll Sequence is an exchange of BFD Control packets that is used in > > some circumstances to ensure that the remote system is aware of > > parameter changes. It is also used in Demand mode (see section 6.6) > > to validate bidirectional connectivity. > > Again, no reference that the Poll sequence MAY be used to signal the > change > > in the Diag field. > > > > - And the very last sentence of section 6.6: > > > > Resolving the issue of one system requesting Demand > > mode while the other requires continuous bidirectional connectivity > > verification is outside the scope of this specification. > > Is what is in the scope of the draft we discuss. (Apologies for taking > too > > much time to find the right text in RFC 5880.) > > I think we're still in the scope of what 5880 permits. > > Consider the following: > :6.8.17. Concatenated Paths > : > : If the path being monitored by BFD is concatenated with other paths > : (connected end-to-end in series), it may be desirable to propagate > : the indication of a failure of one of those paths across the BFD > : session (providing an interworking function for liveness monitoring > : between BFD and other technologies). > : > [...] > : > : A system MAY signal one of these failure states by simply setting > : bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD > : session is not taken down. If Demand mode is not active on the > : remote system, no other action is necessary, as the diagnostic code > : will be carried via the periodic transmission of BFD Control packets. > : If Demand mode is active on the remote system (the local system is > : not transmitting periodic BFD Control packets), a Poll Sequence MUST > : be initiated to ensure that the diagnostic code is transmitted. Note > : that if the BFD session subsequently fails, the diagnostic code will > : be overwritten with a code detailing the cause of the failure. It is > : up to the interworking agent to perform the above procedure again, > : once the BFD session reaches Up state, if the propagation of the > : concatenated path failure is to resume. > > > We thus see here: > 1. You can propagate state, perhaps your RDI, in a session that is Up. > 2. If we are in demand mode, by initiating the poll sequence. > > Your point about 6.6 and asymmetric configuration of demand mode perhaps > should be considered in the context of the word "bidirectional". In a > profile where we have gone half duplex on the session (one side async > continuous, other demand), we're likely in a mode where we mostly want > unidirectional information. This seems to be perhaps along the lines of > what you're looking for. And in such a case, shifting into the poll to > pass > along RDI is perfectly reasonable. > > If the above reflects a rough understanding of the use case, the core > content of your draft reduces to: > - RFC 5880 permits state, such as RDI, to be communicated on an Up session > when in demand mode via a poll sequence in the Diag field. > > -- Jeff > --0000000000009cae470582a78065 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff= ,
I'm glad that you feel that our discussion is h= elpful. I want to point that the use of the Poll sequence to communicate to= the remote BFD system in the Concatenated Paths section is to relay the fa= ilure detected in the downstream segment of the multi-segment OAM domain. A= lso, section 6.8.17 does not specify how the upstream BFD system responds t= o the situation:
=C2=A0 =C2=A0Note t= hat if the BFD session subsequently fails, the diagnostic code will
=C2=A0 =C2=A0be overwritten with a code detailing the cause = of the failure.=C2=A0 It is
=C2=A0 =C2=A0up to the in= terworking agent to perform the above procedure again,
=C2=A0 =C2=A0once the BFD session reaches Up state, if the propagation of= the
=C2=A0 =C2=A0concatenated path failure is to res= ume.
And so far we were discussing RFC 5880 though the scope of t= he draft is on the use of Demand mode over MPLS LSP. And the draft does des= cribe how the BFD system acts after it receives the control message with Di= ag field set to=C2=A0Control Detection Time Expired, a.k.a. RDI, and the Po= ll flag set. In that, I consider, the draft is complimentary to RFC 5884 wh= ose scope is on the Asynchronous mode only.

I beli= eve that the draft addresses practical scenario with the technical and inno= vative solution. And it was recognized as such by several WG participants d= uring the WG AP. Much appreciate your consideration.

Regards,
Greg


On Tue, Feb 19, 2019 at 8:44= PM Jeffrey Haas <jhaas@pfrc.org&g= t; wrote:
Greg,<= br>
We seem now to be converging on the substance of your draft.=C2=A0 Thanks f= or
sticking with this.

On Tue, Feb 19, 2019 at 03:59:36PM -0800, Greg Mirsky wrote:
> thank you for pointing to the sloppy terminology I've used referri= ng to
> what is the proposed update to RFC 5880. In fact, the draft, as I shou= ld
> have done too, refers to the Diag field. Below are quotes from RFC 588= 0 to
> help me explain the intended update:
>
>=C2=A0 =C2=A0 - is section 6.1 Poll sequence in Demand mode MAY be used= by any peer to
>=C2=A0 =C2=A0 verify the bidirectional path continuity (connectivity):<= br> >
>=C2=A0 =C2=A0 If either system wishes to verify
>=C2=A0 =C2=A0 bidirectional connectivity, it can initiate a short excha= nge of BFD
>=C2=A0 =C2=A0 Control packets (a "Poll Sequence"; see section= 6.5) to do so.
>
>=C2=A0 =C2=A0 - similarly, the first paragraph in section 6.5:
>
>=C2=A0 =C2=A0 A Poll Sequence is an exchange of BFD Control packets tha= t is used in
>=C2=A0 =C2=A0 some circumstances to ensure that the remote system is aw= are of
>=C2=A0 =C2=A0 parameter changes.=C2=A0 It is also used in Demand mode (= see section 6.6)
>=C2=A0 =C2=A0 to validate bidirectional connectivity.
> Again, no reference that the Poll sequence MAY be used to signal the c= hange
> in the Diag field.
>
>=C2=A0 =C2=A0 - And the very last sentence of section 6.6:
>
>=C2=A0 =C2=A0 Resolving the issue of one system requesting Demand
>=C2=A0 =C2=A0 mode while the other requires continuous bidirectional co= nnectivity
>=C2=A0 =C2=A0 verification is outside the scope of this specification.<= br> > Is what is in the scope of the draft we discuss. (Apologies for taking= too
> much time to find the right text in RFC 5880.)

I think we're still in the scope of what 5880 permits.

Consider the following:
:6.8.17.=C2=A0 Concatenated Paths
:
:=C2=A0 =C2=A0If the path being monitored by BFD is concatenated with other= paths
:=C2=A0 =C2=A0(connected end-to-end in series), it may be desirable to prop= agate
:=C2=A0 =C2=A0the indication of a failure of one of those paths across the = BFD
:=C2=A0 =C2=A0session (providing an interworking function for liveness moni= toring
:=C2=A0 =C2=A0between BFD and other technologies).
:
[...]
:
:=C2=A0 =C2=A0A system MAY signal one of these failure states by simply set= ting
:=C2=A0 =C2=A0bfd.LocalDiag to the appropriate diagnostic code.=C2=A0 Note = that the BFD
:=C2=A0 =C2=A0session is not taken down.=C2=A0 If Demand mode is not active= on the
:=C2=A0 =C2=A0remote system, no other action is necessary, as the diagnosti= c code
:=C2=A0 =C2=A0will be carried via the periodic transmission of BFD Control = packets.
:=C2=A0 =C2=A0If Demand mode is active on the remote system (the local syst= em is
:=C2=A0 =C2=A0not transmitting periodic BFD Control packets), a Poll Sequen= ce MUST
:=C2=A0 =C2=A0be initiated to ensure that the diagnostic code is transmitte= d.=C2=A0 Note
:=C2=A0 =C2=A0that if the BFD session subsequently fails, the diagnostic co= de will
:=C2=A0 =C2=A0be overwritten with a code detailing the cause of the failure= .=C2=A0 It is
:=C2=A0 =C2=A0up to the interworking agent to perform the above procedure a= gain,
:=C2=A0 =C2=A0once the BFD session reaches Up state, if the propagation of = the
:=C2=A0 =C2=A0concatenated path failure is to resume.


We thus see here:
1. You can propagate state, perhaps your RDI, in a session that is Up.
2. If we are in demand mode, by initiating the poll sequence.

Your point about 6.6 and asymmetric configuration of demand mode perhaps should be considered in the context of the word "bidirectional".= =C2=A0 In a
profile where we have gone half duplex on the session (one side async
continuous, other demand), we're likely in a mode where we mostly want<= br> unidirectional information.=C2=A0 This seems to be perhaps along the lines = of
what you're looking for.=C2=A0 And in such a case, shifting into the po= ll to pass
along RDI is perfectly reasonable.

If the above reflects a rough understanding of the use case, the core
content of your draft reduces to:
- RFC 5880 permits state, such as RDI, to be communicated on an Up session<= br> =C2=A0 when in demand mode via a poll sequence in the Diag field.

-- Jeff
--0000000000009cae470582a78065-- From nobody Sun Feb 24 19:24:17 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD02130EC6 for ; Sun, 24 Feb 2019 19:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf1TmO_lqDby for ; Sun, 24 Feb 2019 19:24:14 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0712D4ED for ; Sun, 24 Feb 2019 19:24:14 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id DF13A1E2D8; Sun, 24 Feb 2019 22:23:17 -0500 (EST) Date: Sun, 24 Feb 2019 22:23:17 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190225032316.GA28974@pfrc.org> References: <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 03:24:16 -0000 Greg, On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote: > Hi Jeff, > I'm glad that you feel that our discussion is helpful. I want to point that > the use of the Poll sequence to communicate to the remote BFD system in the > Concatenated Paths section is to relay the failure detected in the > downstream segment of the multi-segment OAM domain. Also, section 6.8.17 > does not specify how the upstream BFD system responds to the situation: > Note that if the BFD session subsequently fails, the diagnostic code will > be overwritten with a code detailing the cause of the failure. It is > up to the interworking agent to perform the above procedure again, > once the BFD session reaches Up state, if the propagation of the > concatenated path failure is to resume. Correct. That is up to the upstream to determine its behavior. > And so far we were discussing RFC 5880 though the scope of the draft is on > the use of Demand mode over MPLS LSP. MPLS does not magically change the behavior of demand mode specified in the core RFC. > And the draft does describe how the > BFD system acts after it receives the control message with Diag field set > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In > that, I consider, the draft is complimentary to RFC 5884 whose scope is on > the Asynchronous mode only. I continue to have problems understanding how the text in your draft is intended to be different than 6.8.4 of RFC 5880. Simply saying "we're allowed to use demand mode" can't be it? It will help clear this conversation if you simply state your changes in behavior vs. 5880 and 5884. > I believe that the draft addresses practical scenario with the technical > and innovative solution. And it was recognized as such by several WG > participants during the WG AP. Much appreciate your consideration. A reminder that we don't vote. C.f. RFC 7282, section 6. -- Jeff From nobody Mon Feb 25 09:10:33 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF9130F16 for ; Mon, 25 Feb 2019 09:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sBoFcJKZgaJ for ; Mon, 25 Feb 2019 09:10:29 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B353D130F00 for ; Mon, 25 Feb 2019 09:10:28 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id a8so1659942lfi.7 for ; Mon, 25 Feb 2019 09:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UFA6KfY102t49WBIicVlurd3Yc+pJVLVEQTEIsXfBwQ=; b=N8O4wJ5d+bcsW0fM+IRMz5E7qH1nVfWlZlUcrE/DDpoytXGoL+8En0994FK1d/Vl69 srv7avDv4WLDo07SO+zpyCqFgRZKFPQJESKwMlqNTfhDXRtIvXlxR/Az0mohnHWAWe06 /oegmPt2FlhI01ckgvYod/Nz35IPgB6td/SZNTkBydFfV1e9upe/pLutRQHo0CN2GPN9 sjcG+7KAFf9cUGffL+6JaPN3KApys1APPINEimuSXScET4ZntzJRLFV7H1cs0DrfXFMs USPLR7FtrtdJYyafysc5U3Kwi64jMGSTgPpa4UYGyE+Ve7LjvL8f54v9dwBSPglEw8u1 KAJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UFA6KfY102t49WBIicVlurd3Yc+pJVLVEQTEIsXfBwQ=; b=RB4/TnofHkVkMtSLy0pfBLaiIY7jeukkkebYetyI7jlyZBp0B6kFId3DG2d0yWqFqY 7jNMBx7pMoJqvEVXjF6BCqbAQylQeJ8t30Df3BORFiwWFM+zsAUwwasYrHaFcuZRVixM y2L1HVSJNKOFA0MTiZX7pnVpiuL9l+FeQYCTzR24pcRPvEzRyLnvphEFKdGXj5fxtTlO J9hB5aBqoZqhbExtgk2V68l9wcRDSSJR8kDkzfvitLP2NDCHXRtTgr3awLY9JuVfBeJV 7Jq96PAcjjfZHvHl5x1XvC4kvKuDlhD2kMY6gJIObDXbNfXlZY4bpG24LYD6fdDhA1LU ZMkQ== X-Gm-Message-State: AHQUAuZ+Bg/ei6LTwGPUKXaFXxveR2pD99Zv+kLDPeNye7X4pWgfGOfI B4zZSctCZrJ5c1rIPE6+wXLrKa+o0vcsmzrB7yw= X-Google-Smtp-Source: AHgI3IahKGA8gFJx7d1hnS2TVxPKc/8uhfjZLYnRiRjSH85yoMmDX+r7nEWQyveJ3xtyjRxPtrU0l54S/Ml7zT9fB8I= X-Received: by 2002:ac2:5603:: with SMTP id v3mr1349845lfd.145.1551114626628; Mon, 25 Feb 2019 09:10:26 -0800 (PST) MIME-Version: 1.0 References: <20190218162350.GH28950@pfrc.org> <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> <20190225032316.GA28974@pfrc.org> In-Reply-To: <20190225032316.GA28974@pfrc.org> From: Greg Mirsky Date: Mon, 25 Feb 2019 09:10:16 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000005384bd0582bb04d8" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:10:32 -0000 --0000000000005384bd0582bb04d8 Content-Type: text/plain; charset="UTF-8" Hi Jeff, please find my answers in-line tagged GIM4>>. Regards, Greg On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas wrote: > Greg, > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote: > > Hi Jeff, > > I'm glad that you feel that our discussion is helpful. I want to point > that > > the use of the Poll sequence to communicate to the remote BFD system in > the > > Concatenated Paths section is to relay the failure detected in the > > downstream segment of the multi-segment OAM domain. Also, section 6.8.17 > > does not specify how the upstream BFD system responds to the situation: > > Note that if the BFD session subsequently fails, the diagnostic code > will > > be overwritten with a code detailing the cause of the failure. It is > > up to the interworking agent to perform the above procedure again, > > once the BFD session reaches Up state, if the propagation of the > > concatenated path failure is to resume. > > Correct. That is up to the upstream to determine its behavior. > > > And so far we were discussing RFC 5880 though the scope of the draft is > on > > the use of Demand mode over MPLS LSP. > > MPLS does not magically change the behavior of demand mode specified in the > core RFC. > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD control message with Diag set to Control Detection Time Expired and the Poll flag set: Reception of such BFD control packet by the ingress LER indicates that the monitored LSP has a failure and sending BFD control packet with the Final flag set to acknowledge failure indication is likely to fail. Instead, the ingress LER transmits the BFD Control packet to the egress LER over the IP network with: o destination IP address MUST be set to the destination IP address of the LSP Ping Echo request message [RFC8029]; o destination UDP port set to 4784 [RFC5883]; o Final (F) flag in BFD control packet MUST be set; o Demand (D) flag in BFD control packet MUST be cleared. The ingress LER changes the state of the BFD session to Down and changes rate of BFD Control packets transmission to one packet per second. The ingress LER in Down mode changes to Asynchronous mode until the BFD session comes to Up state once again. Then the ingress LER switches to the Demand mode. > > And the draft does describe how the > > BFD system acts after it receives the control message with Diag field set > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In > > that, I consider, the draft is complimentary to RFC 5884 whose scope is > on > > the Asynchronous mode only. > > I continue to have problems understanding how the text in your draft is > intended to be different than 6.8.4 of RFC 5880. Simply saying "we're > allowed to use demand mode" can't be it? > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system. > > It will help clear this conversation if you simply state your changes in > behavior vs. 5880 and 5884. > GIM4>> I've never stated or hinted that the draft is to update RFC 5884. The scope of RFC 5884 is the use of BFD in the Asynchronous mode over MPLS LSPs. As stated in section 6 RFC 5884: BFD demand mode is outside the scope of this specification. > > I believe that the draft addresses practical scenario with the technical > > and innovative solution. And it was recognized as such by several WG > > participants during the WG AP. Much appreciate your consideration. > > A reminder that we don't vote. C.f. RFC 7282, section 6. > GIM4>> I'm confused to differentiate when you raise the objection as the individual contributor and evaluate them and the consensus as the WG chair. > > -- Jeff > > --0000000000005384bd0582bb04d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
please find my answers in-line tagged GIM4>>.<= /div>

Regards,
Greg

On Sun, Feb 24, 2019= at 7:24 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> I'm glad that you feel that our discussion is helpful. I want to p= oint that
> the use of the Poll sequence to communicate to the remote BFD system i= n the
> Concatenated Paths section is to relay the failure detected in the
> downstream segment of the multi-segment OAM domain. Also, section 6.8.= 17
> does not specify how the upstream BFD system responds to the situation= :
>=C2=A0 =C2=A0 Note that if the BFD session subsequently fails, the diag= nostic code will
>=C2=A0 =C2=A0 be overwritten with a code detailing the cause of the fai= lure.=C2=A0 It is
>=C2=A0 =C2=A0 up to the interworking agent to perform the above procedu= re again,
>=C2=A0 =C2=A0 once the BFD session reaches Up state, if the propagation= of the
>=C2=A0 =C2=A0 concatenated path failure is to resume.

Correct.=C2=A0 That is up to the upstream to determine its behavior.

> And so far we were discussing RFC 5880 though the scope of the draft i= s on
> the use of Demand mode over MPLS LSP.

MPLS does not magically change the behavior of demand mode specified in the=
core RFC.
GIM4>> The draft defines how the head-= end LER reacts to receiving the BFD control message with Diag set to Contro= l Detection Time Expired and the Poll flag set:
=C2=A0 =C2= =A0Reception of such BFD control packet by the ingress
=C2=A0 =C2= =A0LER indicates that the monitored LSP has a failure and sending BFD
=
=C2=A0 =C2=A0control packet with the Final flag set to acknowledge fai= lure
=C2=A0 =C2=A0indication is likely to fail.=C2=A0 Instead, th= e ingress LER transmits the
=C2=A0 =C2=A0BFD Control packet to th= e egress LER over the IP network with:

=C2=A0 =C2= =A0o=C2=A0 destination IP address MUST be set to the destination IP address=
=C2=A0 =C2=A0 =C2=A0 of the LSP Ping Echo request message [RFC80= 29];

=C2=A0 =C2=A0o=C2=A0 destination UDP port set= to 4784 [RFC5883];

=C2=A0 =C2=A0o=C2=A0 Final (F)= flag in BFD control packet MUST be set;

=C2=A0 = =C2=A0o=C2=A0 Demand (D) flag in BFD control packet MUST be cleared.
<= div>
=C2=A0 =C2=A0The ingress LER changes the state of the BF= D session to Down and
=C2=A0 =C2=A0changes rate of BFD Control pa= ckets transmission to one packet per
=C2=A0 =C2=A0second.=C2=A0 T= he ingress LER in Down mode changes to Asynchronous mode
=C2=A0 = =C2=A0until the BFD session comes to Up state once again.=C2=A0 Then the in= gress
=C2=A0 =C2=A0LER switches to the Demand mode.


> And the draft does describe how the
> BFD system acts after it receives the control message with Diag field = set
> to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. = In
> that, I consider, the draft is complimentary to RFC 5884 whose scope i= s on
> the Asynchronous mode only.

I continue to have problems understanding how the text in your draft is
intended to be different than 6.8.4 of RFC 5880.=C2=A0 Simply saying "= we're
allowed to use demand mode" can't be it?
GIM4= >> Section 6.8.4 does not specify that if the BFD system is in Demand= mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) th= e Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system= .=C2=A0

It will help clear this conversation if you simply state your changes in behavior vs. 5880 and 5884.
GIM4>> I've nev= er stated or hinted that the draft is to update RFC 5884. The scope of RFC = 5884 is the use of BFD in the Asynchronous mode over MPLS LSPs. As stated i= n section 6 RFC 5884:
<= div dir=3D"ltr">
BFD demand mode is out= side the scope of this specification.

> I believe that the draft addresses practical scenario with the technic= al
> and innovative solution. And it was recognized as such by several WG > participants during the WG AP. Much appreciate your consideration.

A reminder that we don't vote.=C2=A0 C.f. RFC 7282, section 6.
GIM4>> I'm confused to differentiate when you raise = the objection as the individual contributor and evaluate them and the conse= nsus as the WG chair.=C2=A0

-- Jeff

--0000000000005384bd0582bb04d8-- From nobody Mon Feb 25 09:26:43 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7918B1277CC for ; Mon, 25 Feb 2019 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxvRwbax9jdb for ; Mon, 25 Feb 2019 09:26:40 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EC32A124408 for ; Mon, 25 Feb 2019 09:26:39 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8AD441E2D8; Mon, 25 Feb 2019 12:25:44 -0500 (EST) Date: Mon, 25 Feb 2019 12:25:44 -0500 From: Jeffrey Haas To: Greg Mirsky Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Message-ID: <20190225172544.GA17563@pfrc.org> References: <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> <20190225032316.GA28974@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 17:26:41 -0000 On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote: > Hi Jeff, > please find my answers in-line tagged GIM4>>. > > Regards, > Greg > > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas wrote: > > > Greg, > > > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote: > > > Hi Jeff, > > > I'm glad that you feel that our discussion is helpful. I want to point > > that > > > the use of the Poll sequence to communicate to the remote BFD system in > > the > > > Concatenated Paths section is to relay the failure detected in the > > > downstream segment of the multi-segment OAM domain. Also, section 6.8.17 > > > does not specify how the upstream BFD system responds to the situation: > > > Note that if the BFD session subsequently fails, the diagnostic code > > will > > > be overwritten with a code detailing the cause of the failure. It is > > > up to the interworking agent to perform the above procedure again, > > > once the BFD session reaches Up state, if the propagation of the > > > concatenated path failure is to resume. > > > > Correct. That is up to the upstream to determine its behavior. > > > > > And so far we were discussing RFC 5880 though the scope of the draft is > > on > > > the use of Demand mode over MPLS LSP. > > > > MPLS does not magically change the behavior of demand mode specified in the > > core RFC. > > > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD > control message with Diag set to Control Detection Time Expired and the > Poll flag set: > Reception of such BFD control packet by the ingress > LER indicates that the monitored LSP has a failure and sending BFD > control packet with the Final flag set to acknowledge failure > indication is likely to fail. Instead, the ingress LER transmits the > BFD Control packet to the egress LER over the IP network with: > > o destination IP address MUST be set to the destination IP address > of the LSP Ping Echo request message [RFC8029]; > > o destination UDP port set to 4784 [RFC5883]; > > o Final (F) flag in BFD control packet MUST be set; > > o Demand (D) flag in BFD control packet MUST be cleared. > > The ingress LER changes the state of the BFD session to Down and > changes rate of BFD Control packets transmission to one packet per > second. The ingress LER in Down mode changes to Asynchronous mode > until the BFD session comes to Up state once again. Then the ingress > LER switches to the Demand mode. > > > > > And the draft does describe how the > > > BFD system acts after it receives the control message with Diag field set > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In > > > that, I consider, the draft is complimentary to RFC 5884 whose scope is > > on > > > the Asynchronous mode only. > > > > I continue to have problems understanding how the text in your draft is > > intended to be different than 6.8.4 of RFC 5880. Simply saying "we're > > allowed to use demand mode" can't be it? > > > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system. I shall paste this one last time: : If Demand mode is active on either or both systems, a Poll Sequence : MUST be initiated whenever the contents of the next BFD Control : packet to be sent would be different than the contents of the : previous packet, with the exception of the Poll (P) and Final (F) : bits. This ensures that parameter changes are transmitted to the : remote system and that the remote system acknowledges these changes. If you've changed diag, you've changed the contents. If you are running in demand mode, you will send a poll. If you're also saying that the ingress is NOT receiving a Down state change from the egress as part of this and that the ingress moves to down just because the Diag changes, that at least is clear, and is worth further discussion. > > It will help clear this conversation if you simply state your changes in > > behavior vs. 5880 and 5884. > > > GIM4>> I've never stated or hinted that the draft is to update RFC 5884. > The scope of RFC 5884 is the use of BFD in the Asynchronous mode over MPLS > LSPs. As stated in section 6 RFC 5884: > > BFD demand mode is outside the scope of this specification. You seem to be confused about how this boilerplate text is used. If there are no changes to procedure, existing procedure applies - it is simply not discussed in this document. If there is changes to procedure (what we are trying to determine), then further discussion is warranted. > > A reminder that we don't vote. C.f. RFC 7282, section 6. > > > GIM4>> I'm confused to differentiate when you raise the objection as the > individual contributor and evaluate them and the consensus as the WG chair. Chairs are not prohibited from offering technical feedback. If you remain confused on this issue, I suggest you discuss this with Martin at the upcoming IETF. -- Jeff From nobody Mon Feb 25 10:39:50 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE68130F13 for ; Mon, 25 Feb 2019 10:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqdN8yJuyDNd for ; Mon, 25 Feb 2019 10:39:45 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39CA130EFE for ; Mon, 25 Feb 2019 10:39:44 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id d24so8067532ljc.12 for ; Mon, 25 Feb 2019 10:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M6bm6kmwxKa6kJFoqv66MTe2/xXtW3gJrIGen7NPxhI=; b=fWd9JJOS5QEPqdEleanGAGv74d8BXVXIE1X4foo6dUTzO//fYVR/SNOtlpreTUlGdW +w+l+l9GSlrrXwcVcdJcJP6m7CU3ZaMnGSt90NN/psIgOk/kTLHQ4YhyuDn825GaJhoI 5aEwOu3udy951z9YjAKBFDRq55a8GhvprF3Sw8rGMK+2Yc8mkxZEEyUZvPCEoW/urs9V j4Mc/FtnQ1GAjJgLPqmsJnKwcndTECc2yAnKJbIPgi3t5Sj2eLfOI6vnzo+swwXG1GdF Sl1bhqTvxVQv+zcueD5Ccqc+EHBCOHCYTcVeDabB5yD9eDDn0i4DWc2xyv3C5dS0DGmR 80vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M6bm6kmwxKa6kJFoqv66MTe2/xXtW3gJrIGen7NPxhI=; b=pc9s+Rvc8qGRPyG5Ag5FUeTHcJzocWsy7C6pl6kjwq/A3q9KfZjO7xzKVcNG11QJll kJQd0lXxkxrPHzCq9qPCKB1JdXOT6/1qauQ3fsJYbugx9JdRY43y9S7jm9gOT+0JKk/p f7brLSTBJWS6MXN6IWoo7tx8nIsc1JnKN+GD9w3PJfhdEeGdak3yTIl8/mw+FxOU6Gi7 soPRPc3iT97oztqIIoAmNvz2N638FB1ihYUk6mF/Xk8CJFWvc2XtuVsSQgFCcI8BrAvT DqYBFvzYS8w3KwGAPiEk37Q+Xn5NXlJybeakuEC1GvY9aJdCm8DRMoP53Szk3BD/y78V 15+A== X-Gm-Message-State: AHQUAubsp8gBIJ93waoy6p+YY1dzAvcKeLomrXUhvdMUkCO7RyAOEchq LSughg4EDZjyUISS1KhepYCLKA78IIsg/2RLOfg= X-Google-Smtp-Source: AHgI3IZRVO9llAE5WCoTCdgpoQSuCn/vxSdBWZ+yhCa+8lYQpSL4pZ9EjebUjX8tbXnjVCdiH+k6ZliCTm5Vsn5r72o= X-Received: by 2002:a2e:20b:: with SMTP id 11mr10814854ljc.41.1551119982840; Mon, 25 Feb 2019 10:39:42 -0800 (PST) MIME-Version: 1.0 References: <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> <20190225032316.GA28974@pfrc.org> <20190225172544.GA17563@pfrc.org> In-Reply-To: <20190225172544.GA17563@pfrc.org> From: Greg Mirsky Date: Mon, 25 Feb 2019 10:39:32 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: Jeffrey Haas Cc: "Reshad Rahman (rrahman)" , Martin Vigoureux , rtg-bfd WG Content-Type: multipart/alternative; boundary="00000000000094cf710582bc43aa" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 18:39:49 -0000 --00000000000094cf710582bc43aa Content-Type: text/plain; charset="UTF-8" Hi Jeff, now with GIM6>>. Regards, Greg On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas wrote: > On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote: > > Hi Jeff, > > please find my answers in-line tagged GIM4>>. > > > > Regards, > > Greg > > > > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas wrote: > > > > > Greg, > > > > > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote: > > > > Hi Jeff, > > > > I'm glad that you feel that our discussion is helpful. I want to > point > > > that > > > > the use of the Poll sequence to communicate to the remote BFD system > in > > > the > > > > Concatenated Paths section is to relay the failure detected in the > > > > downstream segment of the multi-segment OAM domain. Also, section > 6.8.17 > > > > does not specify how the upstream BFD system responds to the > situation: > > > > Note that if the BFD session subsequently fails, the diagnostic > code > > > will > > > > be overwritten with a code detailing the cause of the failure. > It is > > > > up to the interworking agent to perform the above procedure again, > > > > once the BFD session reaches Up state, if the propagation of the > > > > concatenated path failure is to resume. > > > > > > Correct. That is up to the upstream to determine its behavior. > > > > > > > And so far we were discussing RFC 5880 though the scope of the draft > is > > > on > > > > the use of Demand mode over MPLS LSP. > > > > > > MPLS does not magically change the behavior of demand mode specified > in the > > > core RFC. > > > > > GIM4>> The draft defines how the head-end LER reacts to receiving the BFD > > control message with Diag set to Control Detection Time Expired and the > > Poll flag set: > > Reception of such BFD control packet by the ingress > > LER indicates that the monitored LSP has a failure and sending BFD > > control packet with the Final flag set to acknowledge failure > > indication is likely to fail. Instead, the ingress LER transmits the > > BFD Control packet to the egress LER over the IP network with: > > > > o destination IP address MUST be set to the destination IP address > > of the LSP Ping Echo request message [RFC8029]; > > > > o destination UDP port set to 4784 [RFC5883]; > > > > o Final (F) flag in BFD control packet MUST be set; > > > > o Demand (D) flag in BFD control packet MUST be cleared. > > > > The ingress LER changes the state of the BFD session to Down and > > changes rate of BFD Control packets transmission to one packet per > > second. The ingress LER in Down mode changes to Asynchronous mode > > until the BFD session comes to Up state once again. Then the ingress > > LER switches to the Demand mode. > > > > > > > > And the draft does describe how the > > > > BFD system acts after it receives the control message with Diag > field set > > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag > set. In > > > > that, I consider, the draft is complimentary to RFC 5884 whose scope > is > > > on > > > > the Asynchronous mode only. > > > > > > I continue to have problems understanding how the text in your draft is > > > intended to be different than 6.8.4 of RFC 5880. Simply saying "we're > > > allowed to use demand mode" can't be it? > > > > > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand > > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) > the > > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD > system. > > I shall paste this one last time: > > : If Demand mode is active on either or both systems, a Poll Sequence > : MUST be initiated whenever the contents of the next BFD Control > : packet to be sent would be different than the contents of the > : previous packet, with the exception of the Poll (P) and Final (F) > : bits. This ensures that parameter changes are transmitted to the > : remote system and that the remote system acknowledges these changes. > > GIM6>> RFC 5880 uses the term "parameter" in relation to the timers, and most are in section 6.8.3. The Diag field is defined not a parameter of a BFD session but as: A diagnostic code specifying the local system's reason for the last change in session state. If you've changed diag, you've changed the contents. If you are running in > demand mode, you will send a poll. > GIM6>> If the interpretation of RFC 5880 is as you're suggesting, then draft-ietf-bfd-multipoint must be updated to the fact that when a MultipointTail detects that Control Detection Time Expired it MUST initiate the Poll sequence to the MultipointHead. And draft-ietf-bfd-multipoint-active-tail seems unnecessary as the same functionality ensured by the previously mentioned update. > > If you're also saying that the ingress is NOT receiving a Down state change > from the egress as part of this and that the ingress moves to down just > because the Diag changes, that at least is clear, and is worth further > discussion. > GIM6>> Thank you for the suggestion. The draft states: The ingress LER changes the state of the BFD session to Down and changes rate of BFD Control packets transmission to one packet per second. The ingress LER in Down mode changes to Asynchronous mode until the BFD session comes to Up state once again. Can we discuss that? > > > > It will help clear this conversation if you simply state your changes > in > > > behavior vs. 5880 and 5884. > > > > > GIM4>> I've never stated or hinted that the draft is to update RFC 5884. > > The scope of RFC 5884 is the use of BFD in the Asynchronous mode over > MPLS > > LSPs. As stated in section 6 RFC 5884: > > > > BFD demand mode is outside the scope of this specification. > > You seem to be confused about how this boilerplate text is used. > > If there are no changes to procedure, existing procedure applies - it is > simply not discussed in this document. > > If there is changes to procedure (what we are trying to determine), then > further discussion is warranted. > GIM6>> I don't consider the switch to the Demand mode as "change to procedure" defined in RFC 5884 because the Demand mode is explicitly outside the scope of the document. True, the initialization of a BFD session follows the same steps as defined in RFC 5884. But that all changes: Once the BFD session is in Up state the ingress LER that supports this specification MUST switch to the Demand mode by setting Demand (D) bit in its Control packet and initiating a Poll Sequence. If the egress LER supports this specification it MUST respond with the Final (F) bit set in its BFD Control packet sent to the ingress LER and ceases further transmission of periodic BFD control packets to the ingress LER. I haven't viewed these steps as "change to procedure" of RFC 5884 as they lead to the state that is outside the scope for RFC 5884. > > > > A reminder that we don't vote. C.f. RFC 7282, section 6. > > > > > GIM4>> I'm confused to differentiate when you raise the objection as the > > individual contributor and evaluate them and the consensus as the WG > chair. > > Chairs are not prohibited from offering technical feedback. If you remain > confused on this issue, I suggest you discuss this with Martin at the > upcoming IETF. > > -- Jeff > --00000000000094cf710582bc43aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
now with GIM6>&= gt;.

Regards,
Greg

On Mon, Feb 25, = 2019 at 9:26 AM Jeffrey Haas <jhaas@pf= rc.org> wrote:
On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> please find my answers in-line tagged GIM4>>.
>
> Regards,
> Greg
>
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > Greg,
> >
> > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > Hi Jeff,
> > > I'm glad that you feel that our discussion is helpful. I= want to point
> > that
> > > the use of the Poll sequence to communicate to the remote BF= D system in
> > the
> > > Concatenated Paths section is to relay the failure detected = in the
> > > downstream segment of the multi-segment OAM domain. Also, se= ction 6.8.17
> > > does not specify how the upstream BFD system responds to the= situation:
> > >=C2=A0 =C2=A0 Note that if the BFD session subsequently fails= , the diagnostic code
> > will
> > >=C2=A0 =C2=A0 be overwritten with a code detailing the cause = of the failure.=C2=A0 It is
> > >=C2=A0 =C2=A0 up to the interworking agent to perform the abo= ve procedure again,
> > >=C2=A0 =C2=A0 once the BFD session reaches Up state, if the p= ropagation of the
> > >=C2=A0 =C2=A0 concatenated path failure is to resume.
> >
> > Correct.=C2=A0 That is up to the upstream to determine its behavi= or.
> >
> > > And so far we were discussing RFC 5880 though the scope of t= he draft is
> > on
> > > the use of Demand mode over MPLS LSP.
> >
> > MPLS does not magically change the behavior of demand mode specif= ied in the
> > core RFC.
> >
> GIM4>> The draft defines how the head-end LER reacts to receivin= g the BFD
> control message with Diag set to Control Detection Time Expired and th= e
> Poll flag set:
>=C2=A0 =C2=A0 Reception of such BFD control packet by the ingress
>=C2=A0 =C2=A0 LER indicates that the monitored LSP has a failure and se= nding BFD
>=C2=A0 =C2=A0 control packet with the Final flag set to acknowledge fai= lure
>=C2=A0 =C2=A0 indication is likely to fail.=C2=A0 Instead, the ingress = LER transmits the
>=C2=A0 =C2=A0 BFD Control packet to the egress LER over the IP network = with:
>
>=C2=A0 =C2=A0 o=C2=A0 destination IP address MUST be set to the destina= tion IP address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the LSP Ping Echo request message [RFC802= 9];
>
>=C2=A0 =C2=A0 o=C2=A0 destination UDP port set to 4784 [RFC5883];
>
>=C2=A0 =C2=A0 o=C2=A0 Final (F) flag in BFD control packet MUST be set;=
>
>=C2=A0 =C2=A0 o=C2=A0 Demand (D) flag in BFD control packet MUST be cle= ared.
>
>=C2=A0 =C2=A0 The ingress LER changes the state of the BFD session to D= own and
>=C2=A0 =C2=A0 changes rate of BFD Control packets transmission to one p= acket per
>=C2=A0 =C2=A0 second.=C2=A0 The ingress LER in Down mode changes to Asy= nchronous mode
>=C2=A0 =C2=A0 until the BFD session comes to Up state once again.=C2=A0= Then the ingress
>=C2=A0 =C2=A0 LER switches to the Demand mode.
>
>
> > > And the draft does describe how the
> > > BFD system acts after it receives the control message with D= iag field set
> > > to Control Detection Time Expired, a.k.a. RDI, and the Poll = flag set. In
> > > that, I consider, the draft is complimentary to RFC 5884 who= se scope is
> > on
> > > the Asynchronous mode only.
> >
> > I continue to have problems understanding how the text in your dr= aft is
> > intended to be different than 6.8.4 of RFC 5880.=C2=A0 Simply say= ing "we're
> > allowed to use demand mode" can't be it?
> >
> GIM4>> Section 6.8.4 does not specify that if the BFD system is = in Demand
> mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired= ) the
> Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD sys= tem.

I shall paste this one last time:

:=C2=A0 =C2=A0If Demand mode is active on either or both systems, a Poll Se= quence
:=C2=A0 =C2=A0MUST be initiated whenever the contents of the next BFD Contr= ol
:=C2=A0 =C2=A0packet to be sent would be different than the contents of the=
:=C2=A0 =C2=A0previous packet, with the exception of the Poll (P) and Final= (F)
:=C2=A0 =C2=A0bits.=C2=A0 This ensures that parameter changes are transmitt= ed to the
:=C2=A0 =C2=A0remote system and that the remote system acknowledges these c= hanges.

GIM6>> RFC 5880 uses the term "parameter&q= uot; in relation to the timers, and most are in section 6.8.3. The Diag fie= ld is defined not a parameter of a BFD session but as:
=C2=A0 =C2= =A0 =C2=A0 A diagnostic code specifying the local system's reason for t= he
=C2=A0 =C2=A0 =C2=A0 last change in session state.
<= br>
If you've changed diag, you've changed the contents.=C2=A0 If you a= re running in
demand mode, you will send a poll.
GIM6>> If the= interpretation of RFC 5880 is as you're suggesting, then draft-ietf-bf= d-multipoint must be updated to the fact that when a MultipointTail detects= that Control Detection Time Expired it MUST initiate the Poll sequence to = the MultipointHead. And draft-ietf-bfd-multipoint-active-tail seems unneces= sary as the same functionality ensured by the previously mentioned update.= =C2=A0

If you're also saying that the ingress is NOT receiving a Down state ch= ange
from the egress as part of this and that the ingress moves to down just
because the Diag changes, that at least is clear, and is worth further
discussion.
GIM6>> Thank you for the suggestion.= The draft states:
=C2=A0 =C2=A0The ingress LER changes the state= of the BFD session to Down and
=C2=A0 =C2=A0changes rate of BFD = Control packets transmission to one packet per
=C2=A0 =C2=A0secon= d.=C2=A0 The ingress LER in Down mode changes to Asynchronous mode
=C2=A0 =C2=A0until the BFD session comes to Up state once again.
Can we discuss that?=C2=A0

> > It will help clear this conversation if you simply state your cha= nges in
> > behavior vs. 5880 and 5884.
> >
> GIM4>> I've never stated or hinted that the draft is to upda= te RFC 5884.
> The scope of RFC 5884 is the use of BFD in the Asynchronous mode over = MPLS
> LSPs. As stated in section 6 RFC 5884:
>
> BFD demand mode is outside the scope of this specification.

You seem to be confused about how this boilerplate text is used.

If there are no changes to procedure, existing procedure applies - it is simply not discussed in this document.

If there is changes to procedure (what we are trying to determine), then further discussion is warranted.
GIM6>> I don= 9;t consider the switch to the Demand mode as "change to procedure&quo= t; defined in RFC 5884 because the Demand mode is explicitly outside the sc= ope of the document. True, the initialization of a BFD session follows the = same steps as defined in RFC 5884. But that all changes:
=C2= =A0 Once the BFD session is in Up state the ingress LER
=C2=A0 = =C2=A0that supports this specification MUST switch to the Demand mode by
=C2=A0 =C2=A0setting Demand (D) bit in its Control packet and initi= ating a Poll
=C2=A0 =C2=A0Sequence.=C2=A0 If the egress LER suppo= rts this specification it MUST
=C2=A0 =C2=A0respond with the Fina= l (F) bit set in its BFD Control packet sent to
=C2=A0 =C2=A0the = ingress LER and ceases further transmission of periodic BFD
=C2= =A0 =C2=A0control packets to the ingress LER.
I haven't= viewed these steps as "change to procedure" of RFC 5884 as they = lead to the state that is outside the scope for RFC 5884.

> > A reminder that we don't vote.=C2=A0 C.f. RFC 7282, section 6= .
> >
> GIM4>> I'm confused to differentiate when you raise the obje= ction as the
> individual contributor and evaluate them and the consensus as the WG c= hair.

Chairs are not prohibited from offering technical feedback.=C2=A0 If you re= main
confused on this issue, I suggest you discuss this with Martin at the
upcoming IETF.

-- Jeff
--00000000000094cf710582bc43aa-- From nobody Mon Feb 25 19:02:02 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A871130E67 for ; Mon, 25 Feb 2019 19:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WYxIxvrR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ROizH5ie 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 OlmuP6ZQ16gQ for ; Mon, 25 Feb 2019 19:01:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B0C130E66 for ; Mon, 25 Feb 2019 19:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39221; q=dns/txt; s=iport; t=1551150117; x=1552359717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nO6yT4KReriD+eTqUBjkN9WG3x7RoSBU3b31WVt7UOw=; b=WYxIxvrRgcPEq8+mSkS/yntL+JTe38jx2MQME6TI8y4VfJHMvkE7vYk5 GbdLGMFVi9EPsj6qVjDvYGrBfMXOz4GLkLZhGTKtNGGK+hcECg1KNKkbz yK91Igy9H37W1xpWaoXbKAIF6kQVVp1oYfxv4RFB9J4bNPClX9ughzE1c o=; IronPort-PHdr: =?us-ascii?q?9a23=3AZhMiRh+V2qWZbP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdSfAE3+JfjCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAC+q3Rc/5hdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ0jJCwDZ3QECycKg36DRwOEUIsRgle?= =?us-ascii?q?JLY5xgSQDVAsBASUHhEACF4N1IjQJDQEDAQECAQECbRwMhUoBAQEBAgEjChM?= =?us-ascii?q?BATAHAQ8CAQgRAwECASAHAwICAh8RFAkIAgQBDQWDIAGBDkwDDQgBAgygYQK?= =?us-ascii?q?KFHGBL4J4AQEFhQ0NC4ILAwWMSBeBQD+BEScfgkyBKBkBgRVHAQECAYFlBxI?= =?us-ascii?q?NCYJUMYImiXwGgjpggx2BfoUdi1szCQKHP4dogz0ZgXGFW4tHilOBEoRAgS6?= =?us-ascii?q?LEwIEAgQFAg0BAQWBRziBVnAVZQGCQYIcGINWhRSFP3IBgSeNdgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,413,1544486400"; d="scan'208,217";a="524249026" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2019 03:01:55 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x1Q31t0J008559 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Feb 2019 03:01:55 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Feb 2019 21:01:54 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Feb 2019 21:01:54 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 25 Feb 2019 22:01:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nO6yT4KReriD+eTqUBjkN9WG3x7RoSBU3b31WVt7UOw=; b=ROizH5ieBtgx2dWtWdSRgsPNQumhBEBjspKWCveKjKRzFqcyWlFaCzJha6aIoekaW7QIash59NkMesBEVNXUbDoGoB0vn2TFPGU6EWXTxGGEdDG/pbJ+KYtqFvUYXAbKPvv85wrb1f+adnVGux5BatW/i707i8NX5t1hCprrpqA= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB3808.namprd11.prod.outlook.com (20.178.254.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.21; Tue, 26 Feb 2019 03:01:52 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::4d5b:81c5:6ab2:c5d%5]) with mapi id 15.20.1643.019; Tue, 26 Feb 2019 03:01:52 +0000 From: "Reshad Rahman (rrahman)" To: Greg Mirsky , Jeffrey Haas CC: rtg-bfd WG Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Topic: WG Adoption request for draft-mirsky-bfd-mpls-demand Thread-Index: AQHUZmhJfgrcUNAMK02QPg3oNJil7qVbaqmAgAADnACAHdOmgIBaav4AgA+wiICAABKAAIAAErsAgAH1nYCAAPdUAIAAAeQAgAAOVwCAAAbKAIAADMaAgAAH6ICAAFFAgIAAWIGAgADitwCAAGm8AIAAT1IAgAcmAQCAAJ8+gIAA5w4AgAAEUwCAABSeAIAAOIYA Date: Tue, 26 Feb 2019 03:01:51 +0000 Message-ID: <7D93A642-9A84-4ECB-9AE3-1F072C5E5B17@cisco.com> References: <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> <20190225032316.GA28974@pfrc.org> <20190225172544.GA17563@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 x-originating-ip: [173.38.117.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0e7df3d-e3a8-4010-8f23-08d69b96c1e8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3808; x-ms-traffictypediagnostic: MN2PR11MB3808: x-ms-exchange-purlcount: 1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNTjJQUjExTUIzODA4OzIzOm1aa1VQRUI5R3pzNC9OcEwvZWw1dXJwQ3Fs?= =?utf-8?B?cWpGTTFQcXdxbWVidUVmNjl5cDFqbk1qSXU4WW5WclgraWRwSlM3SmVJekU2?= =?utf-8?B?WWc5SXVPeE9SS20zMGxxU2w3cDRDQ01raTJ0NElqT2VqMFlxUlEzYnVidFFR?= =?utf-8?B?THFwMUtySFduMlpPMlEwOGQvdGdiblRlNXA2Zm9mUEVqbHFOQlhjUHF1aHBL?= =?utf-8?B?OTNTdFZCUUhMcWlVK01nOWxSREZJVzJwdE40TGdtbjhkQXh1b29pcUVtazNX?= =?utf-8?B?VjNxZldNcElFMFhFcmlEc083M2RTV013Mi9zUXN6dURiT0JQUXJHQ2duWHdq?= =?utf-8?B?MngrT2Ntc1VZaUJBOGhuYnd1TUh3TWIvVlU3cnd1MEt6alpaa1JmTzBna0JX?= =?utf-8?B?UlFGbU02RjNKNUU4dmsrcGhPK01jVnFhZjZEeE04Tno2QTlQM2ptbFlkbmw2?= =?utf-8?B?YVNBRFVPRVl3Uy82a3hNUnJoRjBxeVpZWjE2OVhHWFAvWFFnNFV3ZkNRNTA3?= =?utf-8?B?OWRGL0VvSStTY0d4S2FjRG03OEN4T3E1YStHakhONVR0YjZXN1pJSUpsQktr?= =?utf-8?B?MWMyTmV6M3JWd0VFb0pzcHd3ZkhDUXExV1lFdzUwaHozZlBNcklFUW5TV0JS?= =?utf-8?B?NUFpNVlXWnlhZWlYcTlkcWtjOXA4WWJkNm94akVlbmpZeStkRGZJUlBXaEli?= =?utf-8?B?YWxOYlg3WGVsNzVINU42UEJxYXI0djFlMVdUSi8rdkdHWndyOExVSDc1TFY5?= =?utf-8?B?dHJVRFhxMmp2NkdWbDNrYU5JbThRUWNaQkg5UEtmSjZzY3EyMnNvOHFsMmw4?= =?utf-8?B?Tk5LbTBJcmJ3KzlOWWxnK1VYTU56RkRQRHZSN1FZSTBoWStLcytxZ3Zqb1VZ?= =?utf-8?B?NEdCUE84eGczNTJyT3k5SkZVVXVEZWwrTzhIRjd4OHI3YXIvQVRkWG1Za29q?= =?utf-8?B?Qnlnbzh2VkhTdWlYS2hmcWtTcDE4SUN6R1pmTlNjZjN5OTIyVlR1L1M2Lzdx?= =?utf-8?B?S0w2WXVBMk9DQVphbms0bnRDMFZyUGlKTTRyelViYXhnSzVIdW5NSHZRZE9m?= =?utf-8?B?UHdUdHpGa0UzVWlDOGJ4MlYxL0ttNm9ETnpMNENHNzFNcGk0S3B1TTRDelov?= =?utf-8?B?Q2x6MnVsdXU0QnBhdHU2V1k5Z25icS9KMUdPS01vWEpCU1hSdEVsd2E1WXJt?= =?utf-8?B?ekFUeG4rVm1lYUJDTXFGV3JUZDRlOGUrcUZFcDJqZjU1VkFzeHhHaCt4MDdN?= =?utf-8?B?MWZDMGJzWTZ4YU1rWUtNNmZjZGk0a0xMU0tYcGZZZXFhUkhwZDZuYjNaeDRD?= =?utf-8?B?d2syblNDWEFnSXl0eWkvanBHb1VuYU85OXJtRVVPQXNDVEJLc0Y1THBNU2lJ?= =?utf-8?B?OXR2NmJHcjliQU1odmZPYmVZa2haS0dENy9VYmtDRDdFSHFVMnIycWNFRVZa?= =?utf-8?B?aTJvSjV0K1dldlQwcU9VWmpCK3NMTkxEOW5RaXE5MVZpWmRDZk85aHhBbDJh?= =?utf-8?B?YmROczcwZ2VwQUlHYk9TaHlsclhRVXVOQ1QxdVVWNHZOL2NXTXZRekxjUUw2?= =?utf-8?B?RVdCbTVDV1psZ3Q2b29qQ0ZsRjlYS1Y0MW5WV0JxZWlQYTVmQlo2UnIvdUVK?= =?utf-8?B?L0VQSTE1SHYxTmZyY2dPNi9wZmVBRUd1VnpJNlJXbjA5NzBaaUU2ZHdNdDU4?= =?utf-8?B?ZVNSbS9Gbjd4elFUVStpMmdhSnJaMWR2dFAvNVovRm1oT2JmUTA2M08zODE0?= =?utf-8?B?S0F3L3pZSW85L2JzRmRicTk1WFcxOHJJeG1nSmIwVnlMSGdBMThnamhWSXNn?= =?utf-8?B?NnJEZGxjdS9FRnJ3ajVuRm1VMGxremM0NW1BRmFXbkZXMjlzU3FNYXppMjBo?= =?utf-8?Q?EZcSf+RaV1o=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 096029FF66 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(136003)(396003)(366004)(189003)(199004)(256004)(93886005)(33656002)(6306002)(6512007)(97736004)(6436002)(54896002)(81166006)(236005)(6486002)(81156014)(8676002)(66066001)(14444005)(53936002)(36756003)(229853002)(606006)(14454004)(71190400001)(71200400001)(83716004)(106356001)(105586002)(7736002)(9326002)(478600001)(6246003)(82746002)(76176011)(186003)(68736007)(99286004)(11346002)(2616005)(486006)(2906002)(476003)(4326008)(5660300002)(102836004)(58126008)(8936002)(25786009)(790700001)(26005)(86362001)(6116002)(316002)(110136005)(3846002)(6506007)(53546011)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3808; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jQb5qsKqu4xNCONXOymJF91xakIqXMr7RVF2gZ//kKkKTmhdnVTVZR1nzSw90iWqYwAJGjK+g6YkWCfbzSAmwReFfYgMs7SEg8OzX1LOxYEPzUuLwueOcMYSEP6V0hTg0ekgCqHNR+nqkPah10JPl6uS2ivhDL8oiSTRZUlFVTnqKjL2KCHp7aWqRWfHMv6XldC2v2ur0m/E+J37UYyNZ871Y4l9BJpzYg7hvT/XSWk22ANeEufZnTssOVi85axSvgF3YMgno3yYy8zv+EKHfm9yUH6g4btiu2oKz9lKEPOhD/0svzTvUyhGMO1t6+2CYmFREjSHUcOHGdORehuKYh9fmgfKjT/+1T1LQ0Jswwd1vho82Taxb9vBrCv4VjDkBwK+OzkDyA4aRo54inoiVJzfvTR8ZaEFO87u+DZRED4= Content-Type: multipart/alternative; boundary="_000_7D93A6429A844ECB9AE31F072C5E5B17ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d0e7df3d-e3a8-4010-8f23-08d69b96c1e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 03:01:51.8245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3808 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 03:02:02 -0000 --_000_7D93A6429A844ECB9AE31F072C5E5B17ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkZyb206IFJ0Zy1iZmQgPHJ0Zy1iZmQt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBn bWFpbC5jb20+DQpEYXRlOiBNb25kYXksIEZlYnJ1YXJ5IDI1LCAyMDE5IGF0IDE6NDAgUE0NClRv OiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPg0KQ2M6ICJSZXNoYWQgUmFobWFuIChycmFo bWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiwgInJ0Zy1iZmRAaWV0Zi5vcmciIDxydGctYmZkQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFdHIEFkb3B0aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LW1pcnNr eS1iZmQtbXBscy1kZW1hbmQNCg0KSGkgSmVmZiwNCm5vdyB3aXRoIEdJTTY+Pi4NCg0KUmVnYXJk cywNCkdyZWcNCg0KT24gTW9uLCBGZWIgMjUsIDIwMTkgYXQgOToyNiBBTSBKZWZmcmV5IEhhYXMg PGpoYWFzQHBmcmMub3JnPG1haWx0bzpqaGFhc0BwZnJjLm9yZz4+IHdyb3RlOg0KT24gTW9uLCBG ZWIgMjUsIDIwMTkgYXQgMDk6MTA6MTZBTSAtMDgwMCwgR3JlZyBNaXJza3kgd3JvdGU6DQo+IEhp IEplZmYsDQo+IHBsZWFzZSBmaW5kIG15IGFuc3dlcnMgaW4tbGluZSB0YWdnZWQgR0lNND4+Lg0K Pg0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+DQo+IE9uIFN1biwgRmViIDI0LCAyMDE5IGF0IDc6MjQg UE0gSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PiB3 cm90ZToNCj4NCj4gPiBHcmVnLA0KPiA+DQo+ID4gT24gU3VuLCBGZWIgMjQsIDIwMTkgYXQgMDk6 NTM6MjBBTSAtMDgwMCwgR3JlZyBNaXJza3kgd3JvdGU6DQo+ID4gPiBIaSBKZWZmLA0KPiA+ID4g SSdtIGdsYWQgdGhhdCB5b3UgZmVlbCB0aGF0IG91ciBkaXNjdXNzaW9uIGlzIGhlbHBmdWwuIEkg d2FudCB0byBwb2ludA0KPiA+IHRoYXQNCj4gPiA+IHRoZSB1c2Ugb2YgdGhlIFBvbGwgc2VxdWVu Y2UgdG8gY29tbXVuaWNhdGUgdG8gdGhlIHJlbW90ZSBCRkQgc3lzdGVtIGluDQo+ID4gdGhlDQo+ ID4gPiBDb25jYXRlbmF0ZWQgUGF0aHMgc2VjdGlvbiBpcyB0byByZWxheSB0aGUgZmFpbHVyZSBk ZXRlY3RlZCBpbiB0aGUNCj4gPiA+IGRvd25zdHJlYW0gc2VnbWVudCBvZiB0aGUgbXVsdGktc2Vn bWVudCBPQU0gZG9tYWluLiBBbHNvLCBzZWN0aW9uIDYuOC4xNw0KPiA+ID4gZG9lcyBub3Qgc3Bl Y2lmeSBob3cgdGhlIHVwc3RyZWFtIEJGRCBzeXN0ZW0gcmVzcG9uZHMgdG8gdGhlIHNpdHVhdGlv bjoNCj4gPiA+ICAgIE5vdGUgdGhhdCBpZiB0aGUgQkZEIHNlc3Npb24gc3Vic2VxdWVudGx5IGZh aWxzLCB0aGUgZGlhZ25vc3RpYyBjb2RlDQo+ID4gd2lsbA0KPiA+ID4gICAgYmUgb3ZlcndyaXR0 ZW4gd2l0aCBhIGNvZGUgZGV0YWlsaW5nIHRoZSBjYXVzZSBvZiB0aGUgZmFpbHVyZS4gIEl0IGlz DQo+ID4gPiAgICB1cCB0byB0aGUgaW50ZXJ3b3JraW5nIGFnZW50IHRvIHBlcmZvcm0gdGhlIGFi b3ZlIHByb2NlZHVyZSBhZ2FpbiwNCj4gPiA+ICAgIG9uY2UgdGhlIEJGRCBzZXNzaW9uIHJlYWNo ZXMgVXAgc3RhdGUsIGlmIHRoZSBwcm9wYWdhdGlvbiBvZiB0aGUNCj4gPiA+ICAgIGNvbmNhdGVu YXRlZCBwYXRoIGZhaWx1cmUgaXMgdG8gcmVzdW1lLg0KPiA+DQo+ID4gQ29ycmVjdC4gIFRoYXQg aXMgdXAgdG8gdGhlIHVwc3RyZWFtIHRvIGRldGVybWluZSBpdHMgYmVoYXZpb3IuDQo+ID4NCj4g PiA+IEFuZCBzbyBmYXIgd2Ugd2VyZSBkaXNjdXNzaW5nIFJGQyA1ODgwIHRob3VnaCB0aGUgc2Nv cGUgb2YgdGhlIGRyYWZ0IGlzDQo+ID4gb24NCj4gPiA+IHRoZSB1c2Ugb2YgRGVtYW5kIG1vZGUg b3ZlciBNUExTIExTUC4NCj4gPg0KPiA+IE1QTFMgZG9lcyBub3QgbWFnaWNhbGx5IGNoYW5nZSB0 aGUgYmVoYXZpb3Igb2YgZGVtYW5kIG1vZGUgc3BlY2lmaWVkIGluIHRoZQ0KPiA+IGNvcmUgUkZD Lg0KPiA+DQo+IEdJTTQ+PiBUaGUgZHJhZnQgZGVmaW5lcyBob3cgdGhlIGhlYWQtZW5kIExFUiBy ZWFjdHMgdG8gcmVjZWl2aW5nIHRoZSBCRkQNCj4gY29udHJvbCBtZXNzYWdlIHdpdGggRGlhZyBz ZXQgdG8gQ29udHJvbCBEZXRlY3Rpb24gVGltZSBFeHBpcmVkIGFuZCB0aGUNCj4gUG9sbCBmbGFn IHNldDoNCj4gICAgUmVjZXB0aW9uIG9mIHN1Y2ggQkZEIGNvbnRyb2wgcGFja2V0IGJ5IHRoZSBp bmdyZXNzDQo+ICAgIExFUiBpbmRpY2F0ZXMgdGhhdCB0aGUgbW9uaXRvcmVkIExTUCBoYXMgYSBm YWlsdXJlIGFuZCBzZW5kaW5nIEJGRA0KPiAgICBjb250cm9sIHBhY2tldCB3aXRoIHRoZSBGaW5h bCBmbGFnIHNldCB0byBhY2tub3dsZWRnZSBmYWlsdXJlDQo+ICAgIGluZGljYXRpb24gaXMgbGlr ZWx5IHRvIGZhaWwuICBJbnN0ZWFkLCB0aGUgaW5ncmVzcyBMRVIgdHJhbnNtaXRzIHRoZQ0KPiAg ICBCRkQgQ29udHJvbCBwYWNrZXQgdG8gdGhlIGVncmVzcyBMRVIgb3ZlciB0aGUgSVAgbmV0d29y ayB3aXRoOg0KPg0KPiAgICBvICBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIE1VU1QgYmUgc2V0IHRv IHRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzDQo+ICAgICAgIG9mIHRoZSBMU1AgUGluZyBFY2hv IHJlcXVlc3QgbWVzc2FnZSBbUkZDODAyOV07DQo+DQo+ICAgIG8gIGRlc3RpbmF0aW9uIFVEUCBw b3J0IHNldCB0byA0Nzg0IFtSRkM1ODgzXTsNCj4NCj4gICAgbyAgRmluYWwgKEYpIGZsYWcgaW4g QkZEIGNvbnRyb2wgcGFja2V0IE1VU1QgYmUgc2V0Ow0KPg0KPiAgICBvICBEZW1hbmQgKEQpIGZs YWcgaW4gQkZEIGNvbnRyb2wgcGFja2V0IE1VU1QgYmUgY2xlYXJlZC4NCj4NCj4gICAgVGhlIGlu Z3Jlc3MgTEVSIGNoYW5nZXMgdGhlIHN0YXRlIG9mIHRoZSBCRkQgc2Vzc2lvbiB0byBEb3duIGFu ZA0KPiAgICBjaGFuZ2VzIHJhdGUgb2YgQkZEIENvbnRyb2wgcGFja2V0cyB0cmFuc21pc3Npb24g dG8gb25lIHBhY2tldCBwZXINCj4gICAgc2Vjb25kLiAgVGhlIGluZ3Jlc3MgTEVSIGluIERvd24g bW9kZSBjaGFuZ2VzIHRvIEFzeW5jaHJvbm91cyBtb2RlDQo+ICAgIHVudGlsIHRoZSBCRkQgc2Vz c2lvbiBjb21lcyB0byBVcCBzdGF0ZSBvbmNlIGFnYWluLiAgVGhlbiB0aGUgaW5ncmVzcw0KPiAg ICBMRVIgc3dpdGNoZXMgdG8gdGhlIERlbWFuZCBtb2RlLg0KPg0KPg0KPiA+ID4gQW5kIHRoZSBk cmFmdCBkb2VzIGRlc2NyaWJlIGhvdyB0aGUNCj4gPiA+IEJGRCBzeXN0ZW0gYWN0cyBhZnRlciBp dCByZWNlaXZlcyB0aGUgY29udHJvbCBtZXNzYWdlIHdpdGggRGlhZyBmaWVsZCBzZXQNCj4gPiA+ IHRvIENvbnRyb2wgRGV0ZWN0aW9uIFRpbWUgRXhwaXJlZCwgYS5rLmEuIFJESSwgYW5kIHRoZSBQ b2xsIGZsYWcgc2V0LiBJbg0KPiA+ID4gdGhhdCwgSSBjb25zaWRlciwgdGhlIGRyYWZ0IGlzIGNv bXBsaW1lbnRhcnkgdG8gUkZDIDU4ODQgd2hvc2Ugc2NvcGUgaXMNCj4gPiBvbg0KPiA+ID4gdGhl IEFzeW5jaHJvbm91cyBtb2RlIG9ubHkuDQo+ID4NCj4gPiBJIGNvbnRpbnVlIHRvIGhhdmUgcHJv YmxlbXMgdW5kZXJzdGFuZGluZyBob3cgdGhlIHRleHQgaW4geW91ciBkcmFmdCBpcw0KPiA+IGlu dGVuZGVkIHRvIGJlIGRpZmZlcmVudCB0aGFuIDYuOC40IG9mIFJGQyA1ODgwLiAgU2ltcGx5IHNh eWluZyAid2UncmUNCj4gPiBhbGxvd2VkIHRvIHVzZSBkZW1hbmQgbW9kZSIgY2FuJ3QgYmUgaXQ/ DQo+ID4NCj4gR0lNND4+IFNlY3Rpb24gNi44LjQgZG9lcyBub3Qgc3BlY2lmeSB0aGF0IGlmIHRo ZSBCRkQgc3lzdGVtIGlzIGluIERlbWFuZA0KPiBtb2RlIGFuZCB0aGUgYmZkLkxvY2FsRGlhZyBp cyBzZXQgdG8gMSAoQ29udHJvbCBEZXRlY3Rpb24gVGltZSBFeHBpcmVkKSB0aGUNCj4gUG9sbCBz ZXF1ZW5jZSBNQVksIFNIT1VMRCBvciBNVVNUIGJlIHVzZWQgdG8gbm90aWZ5IHRoZSByZW1vdGUg QkZEIHN5c3RlbS4NCg0KSSBzaGFsbCBwYXN0ZSB0aGlzIG9uZSBsYXN0IHRpbWU6DQoNCjogICBJ ZiBEZW1hbmQgbW9kZSBpcyBhY3RpdmUgb24gZWl0aGVyIG9yIGJvdGggc3lzdGVtcywgYSBQb2xs IFNlcXVlbmNlDQo6ICAgTVVTVCBiZSBpbml0aWF0ZWQgd2hlbmV2ZXIgdGhlIGNvbnRlbnRzIG9m IHRoZSBuZXh0IEJGRCBDb250cm9sDQo6ICAgcGFja2V0IHRvIGJlIHNlbnQgd291bGQgYmUgZGlm ZmVyZW50IHRoYW4gdGhlIGNvbnRlbnRzIG9mIHRoZQ0KOiAgIHByZXZpb3VzIHBhY2tldCwgd2l0 aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBQb2xsIChQKSBhbmQgRmluYWwgKEYpDQo6ICAgYml0cy4g IFRoaXMgZW5zdXJlcyB0aGF0IHBhcmFtZXRlciBjaGFuZ2VzIGFyZSB0cmFuc21pdHRlZCB0byB0 aGUNCjogICByZW1vdGUgc3lzdGVtIGFuZCB0aGF0IHRoZSByZW1vdGUgc3lzdGVtIGFja25vd2xl ZGdlcyB0aGVzZSBjaGFuZ2VzLg0KR0lNNj4+IFJGQyA1ODgwIHVzZXMgdGhlIHRlcm0gInBhcmFt ZXRlciIgaW4gcmVsYXRpb24gdG8gdGhlIHRpbWVycywgYW5kIG1vc3QgYXJlIGluIHNlY3Rpb24g Ni44LjMuIFRoZSBEaWFnIGZpZWxkIGlzIGRlZmluZWQgbm90IGEgcGFyYW1ldGVyIG9mIGEgQkZE IHNlc3Npb24gYnV0IGFzOg0KICAgICAgQSBkaWFnbm9zdGljIGNvZGUgc3BlY2lmeWluZyB0aGUg bG9jYWwgc3lzdGVtJ3MgcmVhc29uIGZvciB0aGUNCiAgICAgIGxhc3QgY2hhbmdlIGluIHNlc3Np b24gc3RhdGUuDQo8UlI+IFVzZSBvZiB0aGUgdGVybSDigJxwYXJhbWV0ZXLigJ0gaXMgaW5kZWVk IG5vdCB2ZXJ5IGNsZWFyLCBlbHNld2hlcmUgaW4gNTg4MCDigJx0aW1pbmcgcGFyYW1ldGVyc+KA nSBhbmQg4oCcdGltZXIgcGFyYW1ldGVyc+KAnSBhcmUgdXNlZC4gQnV0IHdoYXQgaXMgY2xlYXIg aXMg4oCcd2hlbmV2ZXIgdGhlIGNvbnRlbnRzIG9mIHRoZSBuZXh0IEJGRCBDb250cm9sIHBhY2tl dCB0byBiZSBzZW50IHdvdWxkIGJlIGRpZmZlcmVudCB0aGFuIHRoZSBjb250ZW50cyBvZiB0aGUg cHJldmlvdXMgcGFja2V0LCB3aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIFBvbGwgKFApIGFuZCBG aW5hbCAoRikgYml0c+KAnSwgdGhlIG5leHQgcGFja2V0IHdvdWxkIGJlIGRpZmZlcmVudCBpbiB0 aGlzIGNhc2UgYmVjYXVzZSBvZiBzdGF0ZS9kaWFnIGNoYW5nZS4gU28gYXMgcGVyIG15IHByZXZp b3VzIHJlcGx5LCBteSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IHRoaXMgaXMgaW5kZWVkIGNvdmVy ZWQgYnkgNTg4MC4NCg0KDQpJZiB5b3UndmUgY2hhbmdlZCBkaWFnLCB5b3UndmUgY2hhbmdlZCB0 aGUgY29udGVudHMuICBJZiB5b3UgYXJlIHJ1bm5pbmcgaW4NCmRlbWFuZCBtb2RlLCB5b3Ugd2ls bCBzZW5kIGEgcG9sbC4NCkdJTTY+PiBJZiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgUkZDIDU4ODAg aXMgYXMgeW91J3JlIHN1Z2dlc3RpbmcsIHRoZW4gZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludCBt dXN0IGJlIHVwZGF0ZWQgdG8gdGhlIGZhY3QgdGhhdCB3aGVuIGEgTXVsdGlwb2ludFRhaWwgZGV0 ZWN0cyB0aGF0IENvbnRyb2wgRGV0ZWN0aW9uIFRpbWUgRXhwaXJlZCBpdCBNVVNUIGluaXRpYXRl IHRoZSBQb2xsIHNlcXVlbmNlIHRvIHRoZSBNdWx0aXBvaW50SGVhZC4gQW5kIGRyYWZ0LWlldGYt YmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwgc2VlbXMgdW5uZWNlc3NhcnkgYXMgdGhlIHNhbWUg ZnVuY3Rpb25hbGl0eSBlbnN1cmVkIGJ5IHRoZSBwcmV2aW91c2x5IG1lbnRpb25lZCB1cGRhdGUu DQo8UlI+IEkgZG9u4oCZdCBoYXZlIGFsbCB0aGUgaGlzdG9yeSBvbiB0aGVzZSAyIGRyYWZ0cyBi dXQgdGhpcyB0ZXh0IGZyb20gZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludCBtZW50aW9ucyBubyBy ZXR1cm4gcGF0aCwgc28gdGhpcyB3b3VsZCBleHBsYWluIHdoeSB0YWlsIGRvZXMgbm90IGRvIHBv bGwgc2VxdWVuY2UuDQogICBBcyBtdWx0aXBvaW50IHRyYW5zbWlzc2lvbnMgYXJlIGluaGVyZW50 bHkgdW5pZGlyZWN0aW9uYWwsIHRoaXMNCiAgIG1lY2hhbmlzbSBwdXJwb3J0cyBvbmx5IHRvIHZl cmlmeSB0aGlzIHVuaWRpcmVjdGlvbmFsIGNvbm5lY3Rpdml0eS4NCiAgIEFsdGhvdWdoIHRoaXMg c2VlbXMgaW4gY29uZmxpY3Qgd2l0aCB0aGUgIkJpZGlyZWN0aW9uYWwiIGluIEJGRCwgdGhlDQog ICBwcm90b2NvbCBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgdGhpcyB1c2UgY2FzZS4gIFVzZSBv ZiBCRkQgaW4NCiAgIERlbWFuZCBtb2RlIGVuYWJsZXMgYSB0YWlsIG1vbml0b3IgYXZhaWxhYmls aXR5IG9mIGEgbXVsdGlwb2ludCBwYXRoDQogICBldmVuIHdpdGhvdXQgdGhlIGV4aXN0ZW5jZSBv ZiBzb21lIGtpbmQgb2YgYSByZXR1cm4gcGF0aCB0byB0aGUgaGVhZC4NCiAgIEFzIGFuIG9wdGlv biwgaWYgYSByZXR1cm4gcGF0aCBmcm9tIGEgdGFpbCB0byB0aGUgaGVhZCBleGlzdHMsIHRoZQ0K ICAgdGFpbCBtYXkgbm90aWZ5IHRoZSBoZWFkIG9mIHRoZSBsYWNrIG9mIG11bHRpcG9pbnQgY29u bmVjdGl2aXR5Lg0KICAgRGV0YWlscyBvZiB0YWlsIG5vdGlmaWNhdGlvbiB0byB0aGUgaGVhZCBh cmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YNCiAgIHRoaXMgZG9jdW1lbnQgYW5kIGFyZSBkaXNjdXNz ZWQgaW4NCiAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xOCNyZWYtSS1ELmll dGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWw+XS4NCg0KDQoNCklmIHlvdSdyZSBhbHNvIHNh eWluZyB0aGF0IHRoZSBpbmdyZXNzIGlzIE5PVCByZWNlaXZpbmcgYSBEb3duIHN0YXRlIGNoYW5n ZQ0KZnJvbSB0aGUgZWdyZXNzIGFzIHBhcnQgb2YgdGhpcyBhbmQgdGhhdCB0aGUgaW5ncmVzcyBt b3ZlcyB0byBkb3duIGp1c3QNCmJlY2F1c2UgdGhlIERpYWcgY2hhbmdlcywgdGhhdCBhdCBsZWFz dCBpcyBjbGVhciwgYW5kIGlzIHdvcnRoIGZ1cnRoZXINCmRpc2N1c3Npb24uDQpHSU02Pj4gVGhh bmsgeW91IGZvciB0aGUgc3VnZ2VzdGlvbi4gVGhlIGRyYWZ0IHN0YXRlczoNCiAgIFRoZSBpbmdy ZXNzIExFUiBjaGFuZ2VzIHRoZSBzdGF0ZSBvZiB0aGUgQkZEIHNlc3Npb24gdG8gRG93biBhbmQN CiAgIGNoYW5nZXMgcmF0ZSBvZiBCRkQgQ29udHJvbCBwYWNrZXRzIHRyYW5zbWlzc2lvbiB0byBv bmUgcGFja2V0IHBlcg0KICAgc2Vjb25kLiAgVGhlIGluZ3Jlc3MgTEVSIGluIERvd24gbW9kZSBj aGFuZ2VzIHRvIEFzeW5jaHJvbm91cyBtb2RlDQogICB1bnRpbCB0aGUgQkZEIHNlc3Npb24gY29t ZXMgdG8gVXAgc3RhdGUgb25jZSBhZ2Fpbi4NCkNhbiB3ZSBkaXNjdXNzIHRoYXQ/DQo8UlI+IElz buKAmXQgdGhlIHBhcmFncmFwaCBjb3ZlcmVkIGluIDYuNiBvZiA1ODgwPw0KICAgTm90ZSB0aGF0 DQogICB0aGUgRGVtYW5kIGJpdCBNVVNUIE5PVCBiZSBzZXQgdW5sZXNzIGJvdGggc3lzdGVtcyBw ZXJjZWl2ZSB0aGUNCiAgIHNlc3Npb24gdG8gYmUgVXAgKHRoZSBsb2NhbCBzeXN0ZW0gdGhpbmtz IHRoZSBzZXNzaW9uIGlzIFVwLCBhbmQgdGhlDQogICByZW1vdGUgc3lzdGVtIGxhc3QgcmVwb3J0 ZWQgVXAgc3RhdGUgaW4gdGhlIFN0YXRlIChTdGEpIGZpZWxkIG9mIHRoZQ0KICAgQkZEIENvbnRy b2wgcGFja2V0KS4NCg0KUmVnYXJkcywNClJlc2hhZCAobm8gaGF0KS4NCg0KDQo+ID4gSXQgd2ls bCBoZWxwIGNsZWFyIHRoaXMgY29udmVyc2F0aW9uIGlmIHlvdSBzaW1wbHkgc3RhdGUgeW91ciBj aGFuZ2VzIGluDQo+ID4gYmVoYXZpb3IgdnMuIDU4ODAgYW5kIDU4ODQuDQo+ID4NCj4gR0lNND4+ IEkndmUgbmV2ZXIgc3RhdGVkIG9yIGhpbnRlZCB0aGF0IHRoZSBkcmFmdCBpcyB0byB1cGRhdGUg UkZDIDU4ODQuDQo+IFRoZSBzY29wZSBvZiBSRkMgNTg4NCBpcyB0aGUgdXNlIG9mIEJGRCBpbiB0 aGUgQXN5bmNocm9ub3VzIG1vZGUgb3ZlciBNUExTDQo+IExTUHMuIEFzIHN0YXRlZCBpbiBzZWN0 aW9uIDYgUkZDIDU4ODQ6DQo+DQo+IEJGRCBkZW1hbmQgbW9kZSBpcyBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCllvdSBzZWVtIHRvIGJlIGNvbmZ1c2VkIGFib3V0 IGhvdyB0aGlzIGJvaWxlcnBsYXRlIHRleHQgaXMgdXNlZC4NCg0KSWYgdGhlcmUgYXJlIG5vIGNo YW5nZXMgdG8gcHJvY2VkdXJlLCBleGlzdGluZyBwcm9jZWR1cmUgYXBwbGllcyAtIGl0IGlzDQpz aW1wbHkgbm90IGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQpJZiB0aGVyZSBpcyBjaGFu Z2VzIHRvIHByb2NlZHVyZSAod2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGRldGVybWluZSksIHRoZW4N CmZ1cnRoZXIgZGlzY3Vzc2lvbiBpcyB3YXJyYW50ZWQuDQpHSU02Pj4gSSBkb24ndCBjb25zaWRl ciB0aGUgc3dpdGNoIHRvIHRoZSBEZW1hbmQgbW9kZSBhcyAiY2hhbmdlIHRvIHByb2NlZHVyZSIg ZGVmaW5lZCBpbiBSRkMgNTg4NCBiZWNhdXNlIHRoZSBEZW1hbmQgbW9kZSBpcyBleHBsaWNpdGx5 IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4gVHJ1ZSwgdGhlIGluaXRpYWxpemF0 aW9uIG9mIGEgQkZEIHNlc3Npb24gZm9sbG93cyB0aGUgc2FtZSBzdGVwcyBhcyBkZWZpbmVkIGlu IFJGQyA1ODg0LiBCdXQgdGhhdCBhbGwgY2hhbmdlczoNCiAgT25jZSB0aGUgQkZEIHNlc3Npb24g aXMgaW4gVXAgc3RhdGUgdGhlIGluZ3Jlc3MgTEVSDQogICB0aGF0IHN1cHBvcnRzIHRoaXMgc3Bl Y2lmaWNhdGlvbiBNVVNUIHN3aXRjaCB0byB0aGUgRGVtYW5kIG1vZGUgYnkNCiAgIHNldHRpbmcg RGVtYW5kIChEKSBiaXQgaW4gaXRzIENvbnRyb2wgcGFja2V0IGFuZCBpbml0aWF0aW5nIGEgUG9s bA0KICAgU2VxdWVuY2UuICBJZiB0aGUgZWdyZXNzIExFUiBzdXBwb3J0cyB0aGlzIHNwZWNpZmlj YXRpb24gaXQgTVVTVA0KICAgcmVzcG9uZCB3aXRoIHRoZSBGaW5hbCAoRikgYml0IHNldCBpbiBp dHMgQkZEIENvbnRyb2wgcGFja2V0IHNlbnQgdG8NCiAgIHRoZSBpbmdyZXNzIExFUiBhbmQgY2Vh c2VzIGZ1cnRoZXIgdHJhbnNtaXNzaW9uIG9mIHBlcmlvZGljIEJGRA0KICAgY29udHJvbCBwYWNr ZXRzIHRvIHRoZSBpbmdyZXNzIExFUi4NCkkgaGF2ZW4ndCB2aWV3ZWQgdGhlc2Ugc3RlcHMgYXMg ImNoYW5nZSB0byBwcm9jZWR1cmUiIG9mIFJGQyA1ODg0IGFzIHRoZXkgbGVhZCB0byB0aGUgc3Rh dGUgdGhhdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBmb3IgUkZDIDU4ODQuDQoNCj4gPiBBIHJlbWlu ZGVyIHRoYXQgd2UgZG9uJ3Qgdm90ZS4gIEMuZi4gUkZDIDcyODIsIHNlY3Rpb24gNi4uDQo+ID4N Cj4gR0lNND4+IEknbSBjb25mdXNlZCB0byBkaWZmZXJlbnRpYXRlIHdoZW4geW91IHJhaXNlIHRo ZSBvYmplY3Rpb24gYXMgdGhlDQo+IGluZGl2aWR1YWwgY29udHJpYnV0b3IgYW5kIGV2YWx1YXRl IHRoZW0gYW5kIHRoZSBjb25zZW5zdXMgYXMgdGhlIFdHIGNoYWlyLg0KDQpDaGFpcnMgYXJlIG5v dCBwcm9oaWJpdGVkIGZyb20gb2ZmZXJpbmcgdGVjaG5pY2FsIGZlZWRiYWNrLiAgSWYgeW91IHJl bWFpbg0KY29uZnVzZWQgb24gdGhpcyBpc3N1ZSwgSSBzdWdnZXN0IHlvdSBkaXNjdXNzIHRoaXMg d2l0aCBNYXJ0aW4gYXQgdGhlDQp1cGNvbWluZyBJRVRGLg0KDQotLSBKZWZmDQo= --_000_7D93A6429A844ECB9AE31F072C5E5B17ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <491C516590B86F41B87BC5FC2A243FCC@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgR3Jl Zyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+UnRnLWJmZCAmbHQ7cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg R3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+TW9uZGF5LCBGZWJydWFyeSAyNSwgMjAxOSBhdCAxOjQwIFBNPGJyPg0KPGI+VG86IDwvYj5K ZWZmcmV5IEhhYXMgJmx0O2poYWFzQHBmcmMub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7 UmVzaGFkIFJhaG1hbiAocnJhaG1hbikmcXVvdDsgJmx0O3JyYWhtYW5AY2lzY28uY29tJmd0Oywg JnF1b3Q7cnRnLWJmZEBpZXRmLm9yZyZxdW90OyAmbHQ7cnRnLWJmZEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFdHIEFkb3B0aW9uIHJlcXVlc3QgZm9yIGRyYWZ0LW1pcnNr eS1iZmQtbXBscy1kZW1hbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEplZmYsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPm5vdyB3aXRoIEdJTTYmZ3Q7Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMjUsIDIwMTkgYXQgOToy NiBBTSBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGFhc0BwZnJjLm9yZyI+amhh YXNAcGZyYy5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ T24gTW9uLCBGZWIgMjUsIDIwMTkgYXQgMDk6MTA6MTZBTSAtMDgwMCwgR3JlZyBNaXJza3kgd3Jv dGU6PGJyPg0KJmd0OyBIaSBKZWZmLDxicj4NCiZndDsgcGxlYXNlIGZpbmQgbXkgYW5zd2VycyBp bi1saW5lIHRhZ2dlZCBHSU00Jmd0OyZndDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMs PGJyPg0KJmd0OyBHcmVnPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFN1biwgRmViIDI0LCAyMDE5 IGF0IDc6MjQgUE0gSmVmZnJleSBIYWFzICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5v cmciIHRhcmdldD0iX2JsYW5rIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsgPGJyPg0KJmd0OyAmZ3Q7IEdyZWcsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9u IFN1biwgRmViIDI0LCAyMDE5IGF0IDA5OjUzOjIwQU0gLTA4MDAsIEdyZWcgTWlyc2t5IHdyb3Rl Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IEhpIEplZmYsPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSdtIGds YWQgdGhhdCB5b3UgZmVlbCB0aGF0IG91ciBkaXNjdXNzaW9uIGlzIGhlbHBmdWwuIEkgd2FudCB0 byBwb2ludDxicj4NCiZndDsgJmd0OyB0aGF0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIHVzZSBv ZiB0aGUgUG9sbCBzZXF1ZW5jZSB0byBjb21tdW5pY2F0ZSB0byB0aGUgcmVtb3RlIEJGRCBzeXN0 ZW0gaW48YnI+DQomZ3Q7ICZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ29uY2F0ZW5hdGVk IFBhdGhzIHNlY3Rpb24gaXMgdG8gcmVsYXkgdGhlIGZhaWx1cmUgZGV0ZWN0ZWQgaW4gdGhlPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgZG93bnN0cmVhbSBzZWdtZW50IG9mIHRoZSBtdWx0aS1zZWdtZW50 IE9BTSBkb21haW4uIEFsc28sIHNlY3Rpb24gNi44LjE3PGJyPg0KJmd0OyAmZ3Q7ICZndDsgZG9l cyBub3Qgc3BlY2lmeSBob3cgdGhlIHVwc3RyZWFtIEJGRCBzeXN0ZW0gcmVzcG9uZHMgdG8gdGhl IHNpdHVhdGlvbjo8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgTm90ZSB0aGF0IGlm IHRoZSBCRkQgc2Vzc2lvbiBzdWJzZXF1ZW50bHkgZmFpbHMsIHRoZSBkaWFnbm9zdGljIGNvZGU8 YnI+DQomZ3Q7ICZndDsgd2lsbDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBiZSBv dmVyd3JpdHRlbiB3aXRoIGEgY29kZSBkZXRhaWxpbmcgdGhlIGNhdXNlIG9mIHRoZSBmYWlsdXJl LiZuYnNwOyBJdCBpczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyB1cCB0byB0aGUg aW50ZXJ3b3JraW5nIGFnZW50IHRvIHBlcmZvcm0gdGhlIGFib3ZlIHByb2NlZHVyZSBhZ2Fpbiw8 YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgb25jZSB0aGUgQkZEIHNlc3Npb24gcmVh Y2hlcyBVcCBzdGF0ZSwgaWYgdGhlIHByb3BhZ2F0aW9uIG9mIHRoZTxicj4NCiZndDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBjb25jYXRlbmF0ZWQgcGF0aCBmYWlsdXJlIGlzIHRvIHJlc3VtZS48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ29ycmVjdC4mbmJzcDsgVGhhdCBpcyB1cCB0 byB0aGUgdXBzdHJlYW0gdG8gZGV0ZXJtaW5lIGl0cyBiZWhhdmlvci48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmQgc28gZmFyIHdlIHdlcmUgZGlzY3Vzc2luZyBSRkMgNTg4 MCB0aG91Z2ggdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBpczxicj4NCiZndDsgJmd0OyBvbjxicj4N CiZndDsgJmd0OyAmZ3Q7IHRoZSB1c2Ugb2YgRGVtYW5kIG1vZGUgb3ZlciBNUExTIExTUC48YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTVBMUyBkb2VzIG5vdCBtYWdpY2FsbHkgY2hhbmdl IHRoZSBiZWhhdmlvciBvZiBkZW1hbmQgbW9kZSBzcGVjaWZpZWQgaW4gdGhlPGJyPg0KJmd0OyAm Z3Q7IGNvcmUgUkZDLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgR0lNNCZndDsmZ3Q7IFRoZSBk cmFmdCBkZWZpbmVzIGhvdyB0aGUgaGVhZC1lbmQgTEVSIHJlYWN0cyB0byByZWNlaXZpbmcgdGhl IEJGRDxicj4NCiZndDsgY29udHJvbCBtZXNzYWdlIHdpdGggRGlhZyBzZXQgdG8gQ29udHJvbCBE ZXRlY3Rpb24gVGltZSBFeHBpcmVkIGFuZCB0aGU8YnI+DQomZ3Q7IFBvbGwgZmxhZyBzZXQ6PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgUmVjZXB0aW9uIG9mIHN1Y2ggQkZEIGNvbnRyb2wgcGFja2V0 IGJ5IHRoZSBpbmdyZXNzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgTEVSIGluZGljYXRlcyB0aGF0 IHRoZSBtb25pdG9yZWQgTFNQIGhhcyBhIGZhaWx1cmUgYW5kIHNlbmRpbmcgQkZEPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgY29udHJvbCBwYWNrZXQgd2l0aCB0aGUgRmluYWwgZmxhZyBzZXQgdG8g YWNrbm93bGVkZ2UgZmFpbHVyZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7IGluZGljYXRpb24gaXMg bGlrZWx5IHRvIGZhaWwuJm5ic3A7IEluc3RlYWQsIHRoZSBpbmdyZXNzIExFUiB0cmFuc21pdHMg dGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgQkZEIENvbnRyb2wgcGFja2V0IHRvIHRoZSBlZ3Jl c3MgTEVSIG92ZXIgdGhlIElQIG5ldHdvcmsgd2l0aDo8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsgJm5ic3A7IG8mbmJzcDsgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBNVVNUIGJlIHNldCB0byB0 aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtvZiB0aGUgTFNQIFBpbmcgRWNobyByZXF1ZXN0IG1lc3NhZ2UgW1JGQzgwMjldOzxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyBkZXN0aW5hdGlvbiBVRFAgcG9y dCBzZXQgdG8gNDc4NCBbUkZDNTg4M107PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyBvJm5ic3A7IEZpbmFsIChGKSBmbGFnIGluIEJGRCBjb250cm9sIHBhY2tldCBNVVNUIGJlIHNl dDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG8mbmJzcDsgRGVtYW5kIChEKSBm bGFnIGluIEJGRCBjb250cm9sIHBhY2tldCBNVVNUIGJlIGNsZWFyZWQuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgaW5ncmVzcyBMRVIgY2hhbmdlcyB0aGUgc3RhdGUgb2Yg dGhlIEJGRCBzZXNzaW9uIHRvIERvd24gYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY2hhbmdl cyByYXRlIG9mIEJGRCBDb250cm9sIHBhY2tldHMgdHJhbnNtaXNzaW9uIHRvIG9uZSBwYWNrZXQg cGVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2Vjb25kLiZuYnNwOyBUaGUgaW5ncmVzcyBMRVIg aW4gRG93biBtb2RlIGNoYW5nZXMgdG8gQXN5bmNocm9ub3VzIG1vZGU8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB1bnRpbCB0aGUgQkZEIHNlc3Npb24gY29tZXMgdG8gVXAgc3RhdGUgb25jZSBhZ2Fp bi4mbmJzcDsgVGhlbiB0aGUgaW5ncmVzczxicj4NCiZndDsmbmJzcDsgJm5ic3A7IExFUiBzd2l0 Y2hlcyB0byB0aGUgRGVtYW5kIG1vZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7IEFuZCB0aGUgZHJhZnQgZG9lcyBkZXNjcmliZSBob3cgdGhlPGJyPg0KJmd0OyAm Z3Q7ICZndDsgQkZEIHN5c3RlbSBhY3RzIGFmdGVyIGl0IHJlY2VpdmVzIHRoZSBjb250cm9sIG1l c3NhZ2Ugd2l0aCBEaWFnIGZpZWxkIHNldDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvIENvbnRyb2wg RGV0ZWN0aW9uIFRpbWUgRXhwaXJlZCwgYS5rLmEuIFJESSwgYW5kIHRoZSBQb2xsIGZsYWcgc2V0 LiBJbjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQsIEkgY29uc2lkZXIsIHRoZSBkcmFmdCBpcyBj b21wbGltZW50YXJ5IHRvIFJGQyA1ODg0IHdob3NlIHNjb3BlIGlzPGJyPg0KJmd0OyAmZ3Q7IG9u PGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIEFzeW5jaHJvbm91cyBtb2RlIG9ubHkuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEkgY29udGludWUgdG8gaGF2ZSBwcm9ibGVtcyB1bmRlcnN0 YW5kaW5nIGhvdyB0aGUgdGV4dCBpbiB5b3VyIGRyYWZ0IGlzPGJyPg0KJmd0OyAmZ3Q7IGludGVu ZGVkIHRvIGJlIGRpZmZlcmVudCB0aGFuIDYuOC40IG9mIFJGQyA1ODgwLiZuYnNwOyBTaW1wbHkg c2F5aW5nICZxdW90O3dlJ3JlPGJyPg0KJmd0OyAmZ3Q7IGFsbG93ZWQgdG8gdXNlIGRlbWFuZCBt b2RlJnF1b3Q7IGNhbid0IGJlIGl0Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgR0lNNCZndDsm Z3Q7IFNlY3Rpb24gNi44LjQgZG9lcyBub3Qgc3BlY2lmeSB0aGF0IGlmIHRoZSBCRkQgc3lzdGVt IGlzIGluIERlbWFuZDxicj4NCiZndDsgbW9kZSBhbmQgdGhlIGJmZC5Mb2NhbERpYWcgaXMgc2V0 IHRvIDEgKENvbnRyb2wgRGV0ZWN0aW9uIFRpbWUgRXhwaXJlZCkgdGhlPGJyPg0KJmd0OyBQb2xs IHNlcXVlbmNlIE1BWSwgU0hPVUxEIG9yIE1VU1QgYmUgdXNlZCB0byBub3RpZnkgdGhlIHJlbW90 ZSBCRkQgc3lzdGVtLjxicj4NCjxicj4NCkkgc2hhbGwgcGFzdGUgdGhpcyBvbmUgbGFzdCB0aW1l Ojxicj4NCjxicj4NCjombmJzcDsgJm5ic3A7SWYgRGVtYW5kIG1vZGUgaXMgYWN0aXZlIG9uIGVp dGhlciBvciBib3RoIHN5c3RlbXMsIGEgUG9sbCBTZXF1ZW5jZTxicj4NCjombmJzcDsgJm5ic3A7 TVVTVCBiZSBpbml0aWF0ZWQgd2hlbmV2ZXIgdGhlIGNvbnRlbnRzIG9mIHRoZSBuZXh0IEJGRCBD b250cm9sPGJyPg0KOiZuYnNwOyAmbmJzcDtwYWNrZXQgdG8gYmUgc2VudCB3b3VsZCBiZSBkaWZm ZXJlbnQgdGhhbiB0aGUgY29udGVudHMgb2YgdGhlPGJyPg0KOiZuYnNwOyAmbmJzcDtwcmV2aW91 cyBwYWNrZXQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgUG9sbCAoUCkgYW5kIEZpbmFsIChG KTxicj4NCjombmJzcDsgJm5ic3A7Yml0cy4mbmJzcDsgVGhpcyBlbnN1cmVzIHRoYXQgcGFyYW1l dGVyIGNoYW5nZXMgYXJlIHRyYW5zbWl0dGVkIHRvIHRoZTxicj4NCjombmJzcDsgJm5ic3A7cmVt b3RlIHN5c3RlbSBhbmQgdGhhdCB0aGUgcmVtb3RlIHN5c3RlbSBhY2tub3dsZWRnZXMgdGhlc2Ug Y2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5HSU02Jmd0OyZndDsgUkZDIDU4ODAgdXNlcyB0aGUgdGVybSAmcXVvdDtwYXJh bWV0ZXImcXVvdDsgaW4gcmVsYXRpb24gdG8gdGhlIHRpbWVycywgYW5kIG1vc3QgYXJlIGluIHNl Y3Rpb24gNi44LjMuIFRoZSBEaWFnIGZpZWxkIGlzIGRlZmluZWQgbm90IGEgcGFyYW1ldGVyIG9m IGEgQkZEIHNlc3Npb24gYnV0IGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgQSBkaWFnbm9zdGljIGNvZGUg c3BlY2lmeWluZyB0aGUgbG9jYWwgc3lzdGVtJ3MgcmVhc29uIGZvciB0aGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7IGxhc3QgY2hhbmdlIGluIHNlc3Npb24gc3RhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbHQ7UlImZ3Q7IFVzZSBvZiB0aGUgdGVybSDigJxwYXJhbWV0ZXLigJ0g aXMgaW5kZWVkIG5vdCB2ZXJ5IGNsZWFyLCBlbHNld2hlcmUgaW4gNTg4MCDigJx0aW1pbmcgcGFy YW1ldGVyc+KAnSBhbmQg4oCcdGltZXIgcGFyYW1ldGVyc+KAnSBhcmUgdXNlZC4gQnV0IHdoYXQg aXMgY2xlYXIgaXMg4oCcd2hlbmV2ZXIgdGhlIGNvbnRlbnRzIG9mIHRoZSBuZXh0IEJGRCBDb250 cm9sIHBhY2tldCB0byBiZSBzZW50IHdvdWxkIGJlIGRpZmZlcmVudCB0aGFuDQogdGhlIGNvbnRl bnRzIG9mIHRoZSBwcmV2aW91cyBwYWNrZXQsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiB0aGUgUG9s bCAoUCkgYW5kIEZpbmFsIChGKSBiaXRz4oCdLCB0aGUgbmV4dCBwYWNrZXQgd291bGQgYmUgZGlm ZmVyZW50IGluIHRoaXMgY2FzZSBiZWNhdXNlIG9mIHN0YXRlL2RpYWcgY2hhbmdlLiBTbyBhcyBw ZXIgbXkgcHJldmlvdXMgcmVwbHksIG15IGludGVycHJldGF0aW9uIGlzIHRoYXQgdGhpcyBpcyBp bmRlZWQgY292ZXJlZCBieSA1ODgwLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UndmUgY2hhbmdlZCBk aWFnLCB5b3UndmUgY2hhbmdlZCB0aGUgY29udGVudHMuJm5ic3A7IElmIHlvdSBhcmUgcnVubmlu ZyBpbjxicj4NCmRlbWFuZCBtb2RlLCB5b3Ugd2lsbCBzZW5kIGEgcG9sbC48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HSU02Jmd0OyZn dDsgSWYgdGhlIGludGVycHJldGF0aW9uIG9mIFJGQyA1ODgwIGlzIGFzIHlvdSdyZSBzdWdnZXN0 aW5nLCB0aGVuIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQgbXVzdCBiZSB1cGRhdGVkIHRvIHRo ZSBmYWN0IHRoYXQgd2hlbiBhIE11bHRpcG9pbnRUYWlsIGRldGVjdHMgdGhhdCBDb250cm9sIERl dGVjdGlvbiBUaW1lIEV4cGlyZWQgaXQgTVVTVCBpbml0aWF0ZSB0aGUgUG9sbCBzZXF1ZW5jZSB0 byB0aGUNCiBNdWx0aXBvaW50SGVhZC4gQW5kIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0 aXZlLXRhaWwgc2VlbXMgdW5uZWNlc3NhcnkgYXMgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBlbnN1 cmVkIGJ5IHRoZSBwcmV2aW91c2x5IG1lbnRpb25lZCB1cGRhdGUuJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7UlImZ3Q7IEkgZG9u4oCZdCBoYXZlIGFsbCB0 aGUgaGlzdG9yeSBvbiB0aGVzZSAyIGRyYWZ0cyBidXQgdGhpcyB0ZXh0IGZyb20gZHJhZnQtaWV0 Zi1iZmQtbXVsdGlwb2ludCBtZW50aW9ucyBubyByZXR1cm4gcGF0aCwgc28gdGhpcyB3b3VsZCBl eHBsYWluIHdoeSB0YWlsIGRvZXMgbm90IGRvIHBvbGwgc2VxdWVuY2UuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IEFzIG11bHRpcG9pbnQgdHJhbnNtaXNzaW9ucyBhcmUgaW5oZXJlbnRseSB1bmlkaXJlY3Rpb25h bCwgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIHB1cnBvcnRzIG9ubHkgdG8g dmVyaWZ5IHRoaXMgdW5pZGlyZWN0aW9uYWwgY29ubmVjdGl2aXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgQWx0aG91Z2ggdGhpcyBzZWVtcyBpbiBjb25mbGljdCB3aXRoIHRoZSAmcXVvdDtCaWRp cmVjdGlvbmFsJnF1b3Q7IGluIEJGRCwgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBwcm90b2Nv bCBpcyBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgdGhpcyB1c2UgY2FzZS4mbmJzcDsgVXNlIG9mIEJG RCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRGVtYW5kIG1vZGUgZW5hYmxlcyBhIHRhaWwgbW9u aXRvciBhdmFpbGFiaWxpdHkgb2YgYSBtdWx0aXBvaW50IHBhdGg8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IGV2ZW4gd2l0aG91dCB0aGUgZXhpc3RlbmNlIG9mIHNvbWUga2luZCBvZiBhIHJldHVybiBw YXRoIHRvIHRoZSBoZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQXMgYW4gb3B0aW9uLCBpZiBh IHJldHVybiBwYXRoIGZyb20gYSB0YWlsIHRvIHRoZSBoZWFkIGV4aXN0cywgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyB0YWlsIG1heSBub3RpZnkgdGhlIGhlYWQgb2YgdGhlIGxhY2sgb2YgbXVs dGlwb2ludCBjb25uZWN0aXZpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBEZXRhaWxzIG9mIHRh aWwgbm90aWZpY2F0aW9uIHRvIHRoZSBoZWFkIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgdGhpcyBkb2N1bWVudCBhbmQgYXJlIGRpc2N1c3NlZCBpbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTE4I3JlZi1JLUQuaWV0Zi1iZmQtbXVsdGlwb2ludC1h Y3RpdmUtdGFpbCIgdGl0bGU9IiZxdW90O0JGRCBNdWx0aXBvaW50IEFjdGl2ZSBUYWlscy4mcXVv dDsiPkktRC5pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10YWlsPC9hPl0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQ7bWFyZ2luOjAuLjhleCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJZiB5b3Un cmUgYWxzbyBzYXlpbmcgdGhhdCB0aGUgaW5ncmVzcyBpcyBOT1QgcmVjZWl2aW5nIGEgRG93biBz dGF0ZSBjaGFuZ2U8YnI+DQpmcm9tIHRoZSBlZ3Jlc3MgYXMgcGFydCBvZiB0aGlzIGFuZCB0aGF0 IHRoZSBpbmdyZXNzIG1vdmVzIHRvIGRvd24ganVzdDxicj4NCmJlY2F1c2UgdGhlIERpYWcgY2hh bmdlcywgdGhhdCBhdCBsZWFzdCBpcyBjbGVhciwgYW5kIGlzIHdvcnRoIGZ1cnRoZXI8YnI+DQpk aXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdJTTYmZ3Q7Jmd0OyBUaGFuayB5b3UgZm9yIHRoZSBzdWdnZXN0aW9uLiBU aGUgZHJhZnQgc3RhdGVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO1RoZSBpbmdyZXNzIExFUiBjaGFuZ2VzIHRoZSBzdGF0 ZSBvZiB0aGUgQkZEIHNlc3Npb24gdG8gRG93biBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjaGFuZ2VzIHJhdGUgb2Yg QkZEIENvbnRyb2wgcGFja2V0cyB0cmFuc21pc3Npb24gdG8gb25lIHBhY2tldCBwZXI8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDtzZWNvbmQuJm5ic3A7IFRoZSBpbmdyZXNzIExFUiBpbiBEb3duIG1vZGUgY2hhbmdlcyB0byBB c3luY2hyb25vdXMgbW9kZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3VudGlsIHRoZSBCRkQgc2Vzc2lvbiBjb21lcyB0byBV cCBzdGF0ZSBvbmNlIGFnYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q2FuIHdlIGRpc2N1c3MgdGhhdD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtSUiZndDsgSXNu4oCZdCB0aGUgcGFyYWdyYXBoIGNv dmVyZWQgaW4gNi42IG9mIDU4ODA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IE5vdGUgdGhhdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgdGhlIERlbWFuZCBiaXQgTVVTVCBOT1QgYmUgc2V0IHVubGVzcyBib3RoIHN5 c3RlbXMgcGVyY2VpdmUgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzZXNzaW9uIHRvIGJlIFVw ICh0aGUgbG9jYWwgc3lzdGVtIHRoaW5rcyB0aGUgc2Vzc2lvbiBpcyBVcCwgYW5kIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgcmVtb3RlIHN5c3RlbSBsYXN0IHJlcG9ydGVkIFVwIHN0YXRlIGlu IHRoZSBTdGF0ZSAoU3RhKSBmaWVsZCBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEJGRCBD b250cm9sIHBhY2tldCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVzaGFkIChubyBoYXQpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7ICZndDsg SXQgd2lsbCBoZWxwIGNsZWFyIHRoaXMgY29udmVyc2F0aW9uIGlmIHlvdSBzaW1wbHkgc3RhdGUg eW91ciBjaGFuZ2VzIGluPGJyPg0KJmd0OyAmZ3Q7IGJlaGF2aW9yIHZzLiA1ODgwIGFuZCA1ODg0 Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgR0lNNCZndDsmZ3Q7IEkndmUgbmV2ZXIgc3RhdGVk IG9yIGhpbnRlZCB0aGF0IHRoZSBkcmFmdCBpcyB0byB1cGRhdGUgUkZDIDU4ODQuPGJyPg0KJmd0 OyBUaGUgc2NvcGUgb2YgUkZDIDU4ODQgaXMgdGhlIHVzZSBvZiBCRkQgaW4gdGhlIEFzeW5jaHJv bm91cyBtb2RlIG92ZXIgTVBMUzxicj4NCiZndDsgTFNQcy4gQXMgc3RhdGVkIGluIHNlY3Rpb24g NiBSRkMgNTg4NDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQkZEIGRlbWFuZCBtb2RlIGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48YnI+DQo8YnI+DQpZb3Ugc2VlbSB0 byBiZSBjb25mdXNlZCBhYm91dCBob3cgdGhpcyBib2lsZXJwbGF0ZSB0ZXh0IGlzIHVzZWQuPGJy Pg0KPGJyPg0KSWYgdGhlcmUgYXJlIG5vIGNoYW5nZXMgdG8gcHJvY2VkdXJlLCBleGlzdGluZyBw cm9jZWR1cmUgYXBwbGllcyAtIGl0IGlzPGJyPg0Kc2ltcGx5IG5vdCBkaXNjdXNzZWQgaW4gdGhp cyBkb2N1bWVudC48YnI+DQo8YnI+DQpJZiB0aGVyZSBpcyBjaGFuZ2VzIHRvIHByb2NlZHVyZSAo d2hhdCB3ZSBhcmUgdHJ5aW5nIHRvIGRldGVybWluZSksIHRoZW48YnI+DQpmdXJ0aGVyIGRpc2N1 c3Npb24gaXMgd2FycmFudGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdJTTYmZ3Q7Jmd0OyBJIGRvbid0IGNvbnNpZGVyIHRoZSBz d2l0Y2ggdG8gdGhlIERlbWFuZCBtb2RlIGFzICZxdW90O2NoYW5nZSB0byBwcm9jZWR1cmUmcXVv dDsgZGVmaW5lZCBpbiBSRkMgNTg4NCBiZWNhdXNlIHRoZSBEZW1hbmQgbW9kZSBpcyBleHBsaWNp dGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4gVHJ1ZSwgdGhlIGluaXRpYWxp emF0aW9uIG9mIGEgQkZEIHNlc3Npb24gZm9sbG93cyB0aGUgc2FtZSBzdGVwcw0KIGFzIGRlZmlu ZWQgaW4gUkZDIDU4ODQuIEJ1dCB0aGF0IGFsbCBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBPbmNlIHRoZSBC RkQgc2Vzc2lvbiBpcyBpbiBVcCBzdGF0ZSB0aGUgaW5ncmVzcyBMRVI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0aGF0IHN1 cHBvcnRzIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHN3aXRjaCB0byB0aGUgRGVtYW5kIG1vZGUg Ynk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtzZXR0aW5nIERlbWFuZCAoRCkgYml0IGluIGl0cyBDb250cm9sIHBhY2tldCBh bmQgaW5pdGlhdGluZyBhIFBvbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtTZXF1ZW5jZS4mbmJzcDsgSWYgdGhlIGVncmVz cyBMRVIgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIGl0IE1VU1Q8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtyZXNwb25k IHdpdGggdGhlIEZpbmFsIChGKSBiaXQgc2V0IGluIGl0cyBCRkQgQ29udHJvbCBwYWNrZXQgc2Vu dCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwO3RoZSBpbmdyZXNzIExFUiBhbmQgY2Vhc2VzIGZ1cnRoZXIgdHJhbnNtaXNz aW9uIG9mIHBlcmlvZGljIEJGRDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2NvbnRyb2wgcGFja2V0cyB0byB0aGUgaW5ncmVz cyBMRVIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgaGF2ZW4ndCB2aWV3ZWQgdGhlc2Ugc3RlcHMgYXMgJnF1b3Q7Y2hhbmdlIHRv IHByb2NlZHVyZSZxdW90OyBvZiBSRkMgNTg4NCBhcyB0aGV5IGxlYWQgdG8gdGhlIHN0YXRlIHRo YXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgZm9yIFJGQyA1ODg0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAmZ3Q7IEEg cmVtaW5kZXIgdGhhdCB3ZSBkb24ndCB2b3RlLiZuYnNwOyBDLmYuIFJGQyA3MjgyLCBzZWN0aW9u IDYuLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgR0lNNCZndDsmZ3Q7IEknbSBjb25mdXNlZCB0 byBkaWZmZXJlbnRpYXRlIHdoZW4geW91IHJhaXNlIHRoZSBvYmplY3Rpb24gYXMgdGhlPGJyPg0K Jmd0OyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yIGFuZCBldmFsdWF0ZSB0aGVtIGFuZCB0aGUgY29u c2Vuc3VzIGFzIHRoZSBXRyBjaGFpci48YnI+DQo8YnI+DQpDaGFpcnMgYXJlIG5vdCBwcm9oaWJp dGVkIGZyb20gb2ZmZXJpbmcgdGVjaG5pY2FsIGZlZWRiYWNrLiZuYnNwOyBJZiB5b3UgcmVtYWlu PGJyPg0KY29uZnVzZWQgb24gdGhpcyBpc3N1ZSwgSSBzdWdnZXN0IHlvdSBkaXNjdXNzIHRoaXMg d2l0aCBNYXJ0aW4gYXQgdGhlPGJyPg0KdXBjb21pbmcgSUVURi48YnI+DQo8YnI+DQotLSBKZWZm PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7D93A6429A844ECB9AE31F072C5E5B17ciscocom_-- From nobody Mon Feb 25 20:26:42 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8823129619 for ; Mon, 25 Feb 2019 20:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0Sz7CnYBwQ8 for ; Mon, 25 Feb 2019 20:26:36 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C6A12870E for ; Mon, 25 Feb 2019 20:26:35 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id z7so9333221lji.0 for ; Mon, 25 Feb 2019 20:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=17m79I/bJ4h3RtaiaOLuOfc4u2IQ948WYAoHxVBgg0c=; b=QixYvTEldtro7/GMQ+Y4S+7nMQdS7m4GrBxFtwfBidng5zIQEb0MuUPFbzKeI1/8qA kgrkXD03MOL96ey9hLCMozEFfr5lR31cBw22jfhhjvcOT6nBf6TroRhTPsqgX45mIrIc wU2cRyMsp/5K+R1Dw9dmAJRR+W1cO1CrKScJMSxM45UKe0FpHogScdmMTPQ+F5DkOzd9 YyricNYcYcw9rPUP2E5Ze/zsKmWkFPUhB/LI0AQh4lRtGjKHvhNfJErA/m3Q92kad4kN viZhwVlzALEDrKVRlFtc3Y4TFHGx5noV/bPJhEx2xwr2cedinEeeG0sOjQ+Vrhlqjyv5 Tw4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=17m79I/bJ4h3RtaiaOLuOfc4u2IQ948WYAoHxVBgg0c=; b=UoE/5RvBr29vyKea5OC2U9uDFIoQDQA4uqxHOam7Y8f5X3C8hM2EvU4zilkThTEQqZ bUrqVcWTXV1h/JcZfrvOLWqLAa+s7NXZcuH3oQcclWilnnbyrjXGk4WdjBJIOiQk8t2f ++if490LQQMYiVhz7nuLmzic9np6w3eoOpEtVfT4Tl2Anx6s6pQBvZqrqQDdaHhN97W/ XW2tBEIzssnInIrLN9Or5ic0v/6NJsC6Kv0r3O7UPpFOiIPshnXEwHr06+rFBgvdPDmG d7bO5DggeOIPvqa/ess3v7VFzUHHZKE+HwM7ysIumCgr2lExPyf85zuzNEI2CmKnVlm2 xirQ== X-Gm-Message-State: AHQUAua/EB0wNV939cHxXwnjFiiN3sBtWNHAjduAp91NEfDRMjTFTnE2 5dPcQbV3nPaaAkFdeEzDUE27OSpRh9x7AiP4rXE= X-Google-Smtp-Source: AHgI3IbN5T/2S82d5K0vKFcyYnY5FrsUujpkCNmbJ7t6FBWKfY/OdXIiIcqvKGqnxt795TxcpZqlyoPrzQao6Ba7F0I= X-Received: by 2002:a2e:4c0a:: with SMTP id z10-v6mr11900564lja.85.1551155193607; Mon, 25 Feb 2019 20:26:33 -0800 (PST) MIME-Version: 1.0 References: <20190218173351.GI28950@pfrc.org> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <20190219174109.GN28950@pfrc.org> <20190220044330.GA14326@pfrc.org> <20190225032316.GA28974@pfrc.org> <20190225172544.GA17563@pfrc.org> <7D93A642-9A84-4ECB-9AE3-1F072C5E5B17@cisco.com> In-Reply-To: <7D93A642-9A84-4ECB-9AE3-1F072C5E5B17@cisco.com> From: Greg Mirsky Date: Mon, 25 Feb 2019 20:26:21 -0800 Message-ID: Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand To: "Reshad Rahman (rrahman)" Cc: Jeffrey Haas , rtg-bfd WG Content-Type: multipart/alternative; boundary="0000000000004e7b190582c47646" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 04:26:41 -0000 --0000000000004e7b190582c47646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Reshad, thank you for sharing your views. Please find my notes in-line tagged GIM7>>. Regards, Greg On Mon, Feb 25, 2019 at 7:01 PM Reshad Rahman (rrahman) wrote: > Hi Greg, > > > > Please see inline. > > > > *From: *Rtg-bfd on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Monday, February 25, 2019 at 1:40 PM > *To: *Jeffrey Haas > *Cc: *"Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org> > *Subject: *Re: WG Adoption request for draft-mirsky-bfd-mpls-demand > > > > Hi Jeff, > > now with GIM6>>. > > > > Regards, > > Greg > > > > On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas wrote: > > On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote: > > Hi Jeff, > > please find my answers in-line tagged GIM4>>. > > > > Regards, > > Greg > > > > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas wrote: > > > > > Greg, > > > > > > On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote: > > > > Hi Jeff, > > > > I'm glad that you feel that our discussion is helpful. I want to > point > > > that > > > > the use of the Poll sequence to communicate to the remote BFD syste= m > in > > > the > > > > Concatenated Paths section is to relay the failure detected in the > > > > downstream segment of the multi-segment OAM domain. Also, section > 6.8.17 > > > > does not specify how the upstream BFD system responds to the > situation: > > > > Note that if the BFD session subsequently fails, the diagnostic > code > > > will > > > > be overwritten with a code detailing the cause of the failure. > It is > > > > up to the interworking agent to perform the above procedure agai= n, > > > > once the BFD session reaches Up state, if the propagation of the > > > > concatenated path failure is to resume. > > > > > > Correct. That is up to the upstream to determine its behavior. > > > > > > > And so far we were discussing RFC 5880 though the scope of the draf= t > is > > > on > > > > the use of Demand mode over MPLS LSP. > > > > > > MPLS does not magically change the behavior of demand mode specified > in the > > > core RFC. > > > > > GIM4>> The draft defines how the head-end LER reacts to receiving the B= FD > > control message with Diag set to Control Detection Time Expired and the > > Poll flag set: > > Reception of such BFD control packet by the ingress > > LER indicates that the monitored LSP has a failure and sending BFD > > control packet with the Final flag set to acknowledge failure > > indication is likely to fail. Instead, the ingress LER transmits th= e > > BFD Control packet to the egress LER over the IP network with: > > > > o destination IP address MUST be set to the destination IP address > > of the LSP Ping Echo request message [RFC8029]; > > > > o destination UDP port set to 4784 [RFC5883]; > > > > o Final (F) flag in BFD control packet MUST be set; > > > > o Demand (D) flag in BFD control packet MUST be cleared. > > > > The ingress LER changes the state of the BFD session to Down and > > changes rate of BFD Control packets transmission to one packet per > > second. The ingress LER in Down mode changes to Asynchronous mode > > until the BFD session comes to Up state once again. Then the ingres= s > > LER switches to the Demand mode. > > > > > > > > And the draft does describe how the > > > > BFD system acts after it receives the control message with Diag > field set > > > > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag > set. In > > > > that, I consider, the draft is complimentary to RFC 5884 whose scop= e > is > > > on > > > > the Asynchronous mode only. > > > > > > I continue to have problems understanding how the text in your draft = is > > > intended to be different than 6.8.4 of RFC 5880. Simply saying "we'r= e > > > allowed to use demand mode" can't be it? > > > > > GIM4>> Section 6.8.4 does not specify that if the BFD system is in Dema= nd > > mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) > the > > Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD > system. > > I shall paste this one last time: > > : If Demand mode is active on either or both systems, a Poll Sequence > : MUST be initiated whenever the contents of the next BFD Control > : packet to be sent would be different than the contents of the > : previous packet, with the exception of the Poll (P) and Final (F) > : bits. This ensures that parameter changes are transmitted to the > : remote system and that the remote system acknowledges these changes. > > GIM6>> RFC 5880 uses the term "parameter" in relation to the timers, and > most are in section 6.8.3. The Diag field is defined not a parameter of a > BFD session but as: > > A diagnostic code specifying the local system's reason for the > > last change in session state. > > Use of the term =E2=80=9Cparameter=E2=80=9D is indeed not very clear= , elsewhere in > 5880 =E2=80=9Ctiming parameters=E2=80=9D and =E2=80=9Ctimer parameters=E2= =80=9D are used. But what is clear > is =E2=80=9Cwhenever the contents of the next BFD Control packet to be se= nt would > be different than the contents of the previous packet, with the exception > of the Poll (P) and Final (F) bits=E2=80=9D, the next packet would be dif= ferent in > this case because of state/diag change. So as per my previous reply, my > interpretation is that this is indeed covered by 5880. > GIM7>> I think that the next sentence clarifies the intent of initiating the Poll sequence: This ensures that parameter changes are transmitted to the remote system and that the remote system acknowledges these changes. So, the goal is not to update the peer on the change in state of the session but only to keep parameters in sync. And these are configurable parameters, in my understanding of the text. > > > > If you've changed diag, you've changed the contents. If you are running = in > demand mode, you will send a poll. > > GIM6>> If the interpretation of RFC 5880 is as you're suggesting, then > draft-ietf-bfd-multipoint must be updated to the fact that when a > MultipointTail detects that Control Detection Time Expired it MUST initia= te > the Poll sequence to the MultipointHead. And > draft-ietf-bfd-multipoint-active-tail seems unnecessary as the same > functionality ensured by the previously mentioned update. > > I don=E2=80=99t have all the history on these 2 drafts but this text= from > draft-ietf-bfd-multipoint mentions no return path, so this would explain > why tail does not do poll sequence. > > As multipoint transmissions are inherently unidirectional, this > > mechanism purports only to verify this unidirectional connectivity. > > Although this seems in conflict with the "Bidirectional" in BFD, the > > protocol is capable of supporting this use case. Use of BFD in > > Demand mode enables a tail monitor availability of a multipoint path > > even without the existence of some kind of a return path to the head. > > As an option, if a return path from a tail to the head exists, the > > tail may notify the head of the lack of multipoint connectivity. > > Details of tail notification to the head are outside the scope of > > this document and are discussed in > > [I-D.ietf-bfd-multipoint-active-tail > > ]. > GIM7>> I think that the reference to lack of any return path to the head is to merely illustrate that even in such network this specification provides some value. But this specification, we may refer to it as p2mp BFD base specification, is equally applicable in the network where the return path from a tail to the head exists. And yet, no mention of using the Poll sequence from a tail to the head as the mechanism to notify the head of failure in the multipoint tree. And the same in draft-ietf-bfd-multipoint-active-tail. Very elaborate mechanism combining multicast and unicast Poll sequence initiated by the head and no mention of possibly using the Poll sequence initiated by a tail. I can only explain that as an indication that initiating the Poll sequence by the system in Demand mode was not intended by the authors of BFD specifications. > > > > > > If you're also saying that the ingress is NOT receiving a Down state chan= ge > from the egress as part of this and that the ingress moves to down just > because the Diag changes, that at least is clear, and is worth further > discussion. > > GIM6>> Thank you for the suggestion. The draft states: > > The ingress LER changes the state of the BFD session to Down and > > changes rate of BFD Control packets transmission to one packet per > > second. The ingress LER in Down mode changes to Asynchronous mode > > until the BFD session comes to Up state once again. > > Can we discuss that? > > Isn=E2=80=99t the paragraph covered in 6.6 of 5880? > > Note that > > the Demand bit MUST NOT be set unless both systems perceive the > > session to be Up (the local system thinks the session is Up, and the > > remote system last reported Up state in the State (Sta) field of the > > BFD Control packet). > > > > Regards, > > Reshad (no hat). > > > > > > > It will help clear this conversation if you simply state your changes > in > > > behavior vs. 5880 and 5884. > > > > > GIM4>> I've never stated or hinted that the draft is to update RFC 5884= . > > The scope of RFC 5884 is the use of BFD in the Asynchronous mode over > MPLS > > LSPs. As stated in section 6 RFC 5884: > > > > BFD demand mode is outside the scope of this specification. > > You seem to be confused about how this boilerplate text is used. > > If there are no changes to procedure, existing procedure applies - it is > simply not discussed in this document. > > If there is changes to procedure (what we are trying to determine), then > further discussion is warranted. > > GIM6>> I don't consider the switch to the Demand mode as "change to > procedure" defined in RFC 5884 because the Demand mode is explicitly > outside the scope of the document. True, the initialization of a BFD > session follows the same steps as defined in RFC 5884. But that all chang= es: > > Once the BFD session is in Up state the ingress LER > > that supports this specification MUST switch to the Demand mode by > > setting Demand (D) bit in its Control packet and initiating a Poll > > Sequence. If the egress LER supports this specification it MUST > > respond with the Final (F) bit set in its BFD Control packet sent to > > the ingress LER and ceases further transmission of periodic BFD > > control packets to the ingress LER. > > I haven't viewed these steps as "change to procedure" of RFC 5884 as they > lead to the state that is outside the scope for RFC 5884. > > > > > A reminder that we don't vote. C.f. RFC 7282, section 6.. > > > > > GIM4>> I'm confused to differentiate when you raise the objection as th= e > > individual contributor and evaluate them and the consensus as the WG > chair. > > Chairs are not prohibited from offering technical feedback. If you remai= n > confused on this issue, I suggest you discuss this with Martin at the > upcoming IETF. > > -- Jeff > > --0000000000004e7b190582c47646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Reshad,
thank you= for sharing your views. Please find my notes in-line tagged GIM7>>.<= /div>

Regards,
Greg

On Mon, Feb 25, 2019= at 7:01 PM Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi Greg,

=C2=A0

Please see inline.

=C2=A0

From: = Rtg-bfd <rtg-bfd-bounces@ietf= .org> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Monday, February 25, 2019 at 1:40 PM
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <<= a href=3D"mailto:rtg-bfd@ietf.org" target=3D"_blank">rtg-bfd@ietf.org&g= t;
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand=

=C2=A0

Hi Jeff,

now with GIM6>>.

=C2=A0

Regards,

Greg

=C2=A0

On Mon, Feb 25, 2019 at 9:26 AM Jeffrey Haas <jhaas@pfrc.org> wro= te:

On Mon, Feb 25, 2019 at= 09:10:16AM -0800, Greg Mirsky wrote:
> Hi Jeff,
> please find = my answers in-line tagged GIM4>>.
>
> Regards,
> G= reg
>
> On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas <jhaas@pfrc.org> wrote= :
>
> > Greg,
> >
> > On Sun, Feb 24, 201= 9 at 09:53:20AM -0800, Greg Mirsky wrote:
> > > Hi Jeff,
>= ; > > I'm glad that you feel that our discussion is helpful. I wa= nt to point
> > that
> > > the use of the Poll sequenc= e to communicate to the remote BFD system in
> > the
> > = > Concatenated Paths section is to relay the failure detected in the
= > > > downstream segment of the multi-segment OAM domain. Also, se= ction 6.8.17
> > > does not specify how the upstream BFD system= responds to the situation:
> > >=C2=A0 =C2=A0 Note that if the= BFD session subsequently fails, the diagnostic code
> > will
&= gt; > >=C2=A0 =C2=A0 be overwritten with a code detailing the cause o= f the failure.=C2=A0 It is
> > >=C2=A0 =C2=A0 up to the interwo= rking agent to perform the above procedure again,
> > >=C2=A0 = =C2=A0 once the BFD session reaches Up state, if the propagation of the
= > > >=C2=A0 =C2=A0 concatenated path failure is to resume.
>= >
> > Correct.=C2=A0 That is up to the upstream to determine i= ts behavior.
> >
> > > And so far we were discussing R= FC 5880 though the scope of the draft is
> > on
> > > = the use of Demand mode over MPLS LSP.
> >
> > MPLS does n= ot magically change the behavior of demand mode specified in the
> &g= t; core RFC.
> >
> GIM4>> The draft defines how the he= ad-end LER reacts to receiving the BFD
> control message with Diag se= t to Control Detection Time Expired and the
> Poll flag set:
>= =C2=A0 =C2=A0 Reception of such BFD control packet by the ingress
>= =C2=A0 =C2=A0 LER indicates that the monitored LSP has a failure and sendin= g BFD
>=C2=A0 =C2=A0 control packet with the Final flag set to acknow= ledge failure
>=C2=A0 =C2=A0 indication is likely to fail.=C2=A0 Inst= ead, the ingress LER transmits the
>=C2=A0 =C2=A0 BFD Control packet = to the egress LER over the IP network with:
>
>=C2=A0 =C2=A0 o= =C2=A0 destination IP address MUST be set to the destination IP address
= >=C2=A0 =C2=A0 =C2=A0 =C2=A0of the LSP Ping Echo request message [RFC802= 9];
>
>=C2=A0 =C2=A0 o=C2=A0 destination UDP port set to 4784 = [RFC5883];
>
>=C2=A0 =C2=A0 o=C2=A0 Final (F) flag in BFD cont= rol packet MUST be set;
>
>=C2=A0 =C2=A0 o=C2=A0 Demand (D) fl= ag in BFD control packet MUST be cleared.
>
>=C2=A0 =C2=A0 The= ingress LER changes the state of the BFD session to Down and
>=C2=A0= =C2=A0 changes rate of BFD Control packets transmission to one packet per<= br>>=C2=A0 =C2=A0 second.=C2=A0 The ingress LER in Down mode changes to = Asynchronous mode
>=C2=A0 =C2=A0 until the BFD session comes to Up st= ate once again.=C2=A0 Then the ingress
>=C2=A0 =C2=A0 LER switches to= the Demand mode.
>
>
> > > And the draft does de= scribe how the
> > > BFD system acts after it receives the cont= rol message with Diag field set
> > > to Control Detection Time= Expired, a.k.a. RDI, and the Poll flag set. In
> > > that, I c= onsider, the draft is complimentary to RFC 5884 whose scope is
> >= on
> > > the Asynchronous mode only.
> >
> >= I continue to have problems understanding how the text in your draft is> > intended to be different than 6.8.4 of RFC 5880.=C2=A0 Simply sa= ying "we're
> > allowed to use demand mode" can'= t be it?
> >
> GIM4>> Section 6.8.4 does not specify t= hat if the BFD system is in Demand
> mode and the bfd.LocalDiag is se= t to 1 (Control Detection Time Expired) the
> Poll sequence MAY, SHOU= LD or MUST be used to notify the remote BFD system.

I shall paste this one last time:

:=C2=A0 =C2=A0If Demand mode is active on either or both systems, a Pol= l Sequence
:=C2=A0 =C2=A0MUST be initiated whenever the contents of the = next BFD Control
:=C2=A0 =C2=A0packet to be sent would be different than= the contents of the
:=C2=A0 =C2=A0previous packet, with the exception o= f the Poll (P) and Final (F)
:=C2=A0 =C2=A0bits.=C2=A0 This ensures that= parameter changes are transmitted to the
:=C2=A0 =C2=A0remote system an= d that the remote system acknowledges these changes.

GIM6>> RFC 5880 uses the term "parameter&= quot; in relation to the timers, and most are in section 6.8.3. The Diag fi= eld is defined not a parameter of a BFD session but as:

=C2=A0 =C2=A0 =C2=A0 A diagnostic code specifying th= e local system's reason for the

=C2=A0 =C2=A0 =C2=A0 last change in session state.

<RR> Use of the term =E2=80=9Cparameter=E2=80= =9D is indeed not very clear, elsewhere in 5880 =E2=80=9Ctiming parameters= =E2=80=9D and =E2=80=9Ctimer parameters=E2=80=9D are used. But what is clea= r is =E2=80=9Cwhenever the contents of the next BFD Control packet to be se= nt would be different than the contents of the previous packet, with the ex= ception of the Poll (P) and Final (F) bits=E2=80=9D, the next packet would = be different in this case because of state/diag change. So as per my previo= us reply, my interpretation is that this is indeed covered by 5880.

=
GIM7>> I think that the next sentence clarifies the intent of init= iating the Poll sequence:
=C2=A0 =C2=A0This ensures that paramete= r changes are transmitted to the
=C2=A0 =C2=A0remote system and t= hat the remote system acknowledges these changes.=C2=A0
So, the g= oal is not=C2=A0to update the peer on the change in state of the session bu= t only to keep parameters in sync. And these are configurable parameters, i= n my understanding of the text.


=C2=A0

If you've changed diag, you've changed the c= ontents.=C2=A0 If you are running in
demand mode, you will send a poll.<= u>

GIM6>> If the interpretation of RFC 5880 is as= you're suggesting, then draft-ietf-bfd-multipoint must be updated to t= he fact that when a MultipointTail detects that Control Detection Time Expi= red it MUST initiate the Poll sequence to the MultipointHead. And draft-iet= f-bfd-multipoint-active-tail seems unnecessary as the same functionality en= sured by the previously mentioned update.=C2=A0

<RR> I don=E2=80=99t have all the history on t= hese 2 drafts but this text from draft-ietf-bfd-multipoint mentions no retu= rn path, so this would explain why tail does not do poll sequence.

=C2=A0=C2=A0 As multipoint transmissions are inh= erently unidirectional, this

=C2=A0=C2=A0 mechanism purports only to verify t= his unidirectional connectivity.

=C2=A0=C2=A0 Although this seems in conflict wit= h the "Bidirectional" in BFD, the

=C2=A0=C2=A0 protocol is capable of supporting t= his use case.=C2=A0 Use of BFD in

=C2=A0=C2=A0 Demand mode enables a tail monitor = availability of a multipoint path

=C2=A0=C2=A0 even without the existence of some = kind of a return path to the head.

=C2=A0=C2=A0 As an option, if a return path from= a tail to the head exists, the

=C2=A0=C2=A0 tail may notify the head of the lac= k of multipoint connectivity.

=C2=A0=C2=A0 Details of tail notification to the= head are outside the scope of

=C2=A0=C2=A0 this document and are discussed in<= u>

=C2=A0=C2=A0 [I-D.ie= tf-bfd-multipoint-active-tail].

GIM7>> I think that = the reference to lack of any return path to the head is to merely illustrat= e that even in such network this specification provides some value. But thi= s specification, we may refer to it as p2mp BFD base specification, is equa= lly applicable in the network where the return path from a tail to the head= exists. And yet, no mention of using the Poll sequence from a tail to the = head as the mechanism to notify the head of failure in the multipoint tree.= And the same in draft-ietf-bfd-multipoint-active-tail. Very elaborate mech= anism combining multicast and unicast Poll sequence initiated by the head a= nd no mention of possibly using the Poll sequence initiated by a tail. I ca= n only explain that as an indication that initiating the Poll sequence by t= he system in Demand mode was not intended by the authors of BFD specificati= ons.

<= /p>

=C2=A0

=C2=A0


If you're also saying that the ingress is NO= T receiving a Down state change
from the egress as part of this and that= the ingress moves to down just
because the Diag changes, that at least = is clear, and is worth further
discussion.

GIM6>> Thank you for the suggestion. The draft= states:

=C2=A0 =C2=A0The ingress LER changes the state of th= e BFD session to Down and

=C2=A0 =C2=A0changes rate of BFD Control packets tra= nsmission to one packet per

=C2=A0 =C2=A0second.=C2=A0 The ingress LER in Down m= ode changes to Asynchronous mode

=C2=A0 =C2=A0until the BFD session comes to Up state= once again.

Can we discuss that?=C2=A0

<RR> Isn=E2=80=99t the paragraph covered in 6.= 6 of 5880?

=C2=A0=C2=A0 Note that

=C2=A0=C2=A0 the Demand bit MUST NOT be set unle= ss both systems perceive the

=C2=A0=C2=A0 session to be Up (the local system = thinks the session is Up, and the

=C2=A0=C2=A0 remote system last reported Up stat= e in the State (Sta) field of the

=C2=A0=C2=A0 BFD Control packet).<= /span>

=C2=A0

Regards,

Reshad (no hat).

=C2=A0


> > It will help clear this conversation i= f you simply state your changes in
> > behavior vs. 5880 and 5884.=
> >
> GIM4>> I've never stated or hinted that the= draft is to update RFC 5884.
> The scope of RFC 5884 is the use of B= FD in the Asynchronous mode over MPLS
> LSPs. As stated in section 6 = RFC 5884:
>
> BFD demand mode is outside the scope of this spe= cification.

You seem to be confused about how this boilerplate text is used.

If there are no changes to procedure, existing procedure applies - it i= s
simply not discussed in this document.

If there is changes to procedure (what we are trying to determine), the= n
further discussion is warranted.

GIM6>> I don't consider the switch to the = Demand mode as "change to procedure" defined in RFC 5884 because = the Demand mode is explicitly outside the scope of the document. True, the = initialization of a BFD session follows the same steps as defined in RFC 58= 84. But that all changes:

=C2=A0 Once the BFD session is in Up state the ingre= ss LER

=C2=A0 =C2=A0that supports this specification MUST s= witch to the Demand mode by

=C2=A0 =C2=A0setting Demand (D) bit in its Control p= acket and initiating a Poll

=C2=A0 =C2=A0Sequence.=C2=A0 If the egress LER suppo= rts this specification it MUST

=C2=A0 =C2=A0respond with the Final (F) bit set in i= ts BFD Control packet sent to

=C2=A0 =C2=A0the ingress LER and ceases further tran= smission of periodic BFD

=C2=A0 =C2=A0control packets to the ingress LER.<= /u>

I haven't viewed these steps as "change to = procedure" of RFC 5884 as they lead to the state that is outside the s= cope for RFC 5884.


> > A reminder that we don't vote.=C2= =A0 C.f. RFC 7282, section 6..
> >
> GIM4>> I'm co= nfused to differentiate when you raise the objection as the
> individ= ual contributor and evaluate them and the consensus as the WG chair.

Chairs are not prohibited from offering technical feedback.=C2=A0 If yo= u remain
confused on this issue, I suggest you discuss this with Martin = at the
upcoming IETF.

-- Jeff

--0000000000004e7b190582c47646-- From nobody Tue Feb 26 08:56:14 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC41292F1; Tue, 26 Feb 2019 08:56:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-large-packets-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155120017362.732.3865721993862074495@ietfa.amsl.com> Date: Tue, 26 Feb 2019 08:56:13 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 16:56: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 WG of the IETF. Title : BFD Encapsulated in Large Packets Authors : Jeffrey Haas Albert Fu Filename : draft-ietf-bfd-large-packets-00.txt Pages : 5 Date : 2019-02-26 Abstract: The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-large-packets-00 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 26 13:28:33 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0E212D7F8; Tue, 26 Feb 2019 13:28:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-unsolicited-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155121651113.840.11293380709241740573@ietfa.amsl.com> Date: Tue, 26 Feb 2019 13:28:31 -0800 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 21:28:31 -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 WG of the IETF. Title : Unsolicited BFD for Sessionless Applications Authors : Enke Chen Naiming Shen Robert Raszuk Reshad Rahman Filename : draft-ietf-bfd-unsolicited-00.txt Pages : 11 Date : 2019-02-25 Abstract: For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-unsolicited-00 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/