From nobody Mon Jul 3 12:32:52 2017 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 71E8212ECC1 for ; Mon, 3 Jul 2017 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 OepT2mYldTcp for ; Mon, 3 Jul 2017 12:32:48 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 68B88131741 for ; Mon, 3 Jul 2017 12:32:46 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v143so69336244qkb.0 for ; Mon, 03 Jul 2017 12:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lfP0MGgKracVu75ZqXDHR6nxGkJpDVE0K4CIGf3KWk4=; b=f/d8XCjeGmPlJVuZxrImuFqIS8IxJ4yfbo63h70J8xfaCOv6lxi8cXKd3z8Vcw9xDN T0Ia5wqcnkiKhK7F8TtWujYXJl1+n8Q9T1Q/VNqMDOcq0dpMXEHrCqOYDntvduXkKiLL 6/8jt4Rz7Zd8/GKPxGwSJpDJnstQL/1HV4q0je3aAk5zAYi4vHtWdVOw0sCm5ZQ99wLa QJASn/lE5mIndfqonwQ/Mvm2TpL84BUpmgImRD77aA5T/sxsokRrUjNj45sAF6yDuKv7 NwyDZmWK20bdW5wxcjegm8kauAVOAts0YjOTtMZ6cUPEEaspO2Fzo7iYvRLE/KzeXQxt BJwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lfP0MGgKracVu75ZqXDHR6nxGkJpDVE0K4CIGf3KWk4=; b=r7FX3i3DWf/A6Wc6ysvWdpQhJCE43cjep0Opalcptxbaaqq2RleQVDXGU883PNjzrR wQXkmYTBG5LJKWThTGdsBx8Ilh0s1xHsLD9zUq+36AP8u7Iw+ePF+H6eTb+UfWLiELtt Vn0Fje+Jf+M6sxAJb7SE894cEIP8x8wRzIR1ynjRIuE/uPe81GeiQaKDiqgCXkEtX0jB JemJQc4is2/rFRu9owKr5XYpkUpsut2jRexgat8mxHoJI7BM/n+I2yxHD0ZPpvA/lwpW H+iREqlnXHVchpSDPNxINo6Nhld1zqSI83RqypPD0wBOWnlqEgs3aVe46CXhoZ6XS5O1 KtJw== X-Gm-Message-State: AKS2vOwxHDLadB5y8tAsdW1H2vPOjoMzuyAwxqone82eo4CKpTqKSDvo UbMyOmTFOOMsm2dTCzlc3SrQr+RabWj+ X-Received: by 10.55.39.194 with SMTP id n185mr44755653qkn.139.1499110365440; Mon, 03 Jul 2017 12:32:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Mon, 3 Jul 2017 12:32:44 -0700 (PDT) In-Reply-To: <20170619193929.GE22146@pfrc.org> References: <20170619193929.GE22146@pfrc.org> From: Greg Mirsky Date: Mon, 3 Jul 2017 12:32:44 -0700 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c092da0cfad9305536ed46a" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 19:32:50 -0000 --94eb2c092da0cfad9305536ed46a Content-Type: text/plain; charset="UTF-8" Dear Authors, WG chairs, et. al, please kindly consider my comments to the latest version of the draft as part of WGLC: - Very general - I suggest to add note clarifying that all terms that include "connectivity" in the document are being used as alternative to "continuity", i.e. existence of a path between the sender and the receiver, and should not be interpreted as "connectivity verification in terms of transport network". - Introduction - I find that characterization of BFD and unidirectional continuity verification as "natural fit" bit of stretching. Perhaps "capable of supporting this use case" is acceptable; - Goals - the last statement of non-goal seems little unclear. In fact, if there's only one tail, the BFD for multipoint network does verify connectivity, though unidirectional, between the head and the tail. I think that the intention is to stress that p2p bi-directional connectivity verification is not supported by this document. - Section 4.7 - the last paragraph notes that the discriminator value MUST NOT be changed. Since Your Discriminator MUST be set to 0 this refers to My Discriminator only. I think that explicit reference will make the statement more clear. Thus suggest s/the discriminator values/the My Discriminator value/ - Section 4.8 - I believe that requiring use of IP/UDP encapsulation for BFD in multipoint networks over MPSL LSP is too restrictive. I suggest changing text as following: OLD: For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and IP "127.0.0.0/8" range. NEW If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" and IP "127.0.0.0/8" range. Use of other types of encapsulation for multipoint LSP is outside the scope of this document. - Section 4.10 - I cannot say what bfd.DetectMult packet is. It has not been defined in RFC 5880, nor in this document. What is the scenario described in the second paragraph? Is it when MultipointHead reduces Desired Min TX Interval thus making defect detection more aggressive? - Section 7 - I think it should be plural in the first paragraph, i.e. s/MultipointTail session/MultipointTail sessions/ - I think that we can add another consideration to improve, strengthen security of BFD for multipoint network by suggesting that MultipointTail sessions created only for known combination of MultipointHead and My Discriminator. Such information MAY be learned from out-of-band and mechanisms are outside the scope of this document. Regards, Greg On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: > Working Group, > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > The BFD Multipoint documents have been stable for some time. Prior > discussion at meetings has suggested we have an implementation for the main > protocol component. Also per prior discussions, we split the active-tail > component of the original multipoint document to permit implementors to not > have to worry about implementing active-tail procedures if they weren't > interested in that feature. > > We are starting an extended last call on these documents. The WGLC will > conclude on July 14. This provides ample time for list discussion. If > necessary, the IETF-99 meeting may provide for opportunities to close any > contentious technical points. (BFD is not currently scheduled to meet.) > > One item I would like to kick off is the document status of the active-tail > mechanism. At this time, no one has implemented it that I am aware of. > Discussion with our AD suggests that publishing the document with > Experimental status may be reasonable to preserve the work that went into > the proposal. > > -- Jeff > > --94eb2c092da0cfad9305536ed46a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors, WG chairs, et. al,
please kindly conside= r my comments to the latest version of the draft as part of WGLC:
  • Very general
    • I suggest to add note clarifying that all= terms that include "connectivity" in the document are being used= as alternative to "continuity", i.e. existence of a path between= the sender and the receiver, and should not be interpreted as "connec= tivity verification in terms of transport network".
  • Intro= duction=C2=A0
    • I find that characterization of BFD and unidirect= ional continuity verification as "natural fit" bit of stretching.= Perhaps "capable of supporting this use case" is acceptable;
  • Goals
    • the last statement of non-goal seems little unc= lear. In fact, if there's only one tail, the BFD for multipoint network= does verify connectivity, though unidirectional, between the head and the = tail. I think that the intention is to stress that p2p bi-directional conne= ctivity verification is not supported by this document.
  • Sectio= n 4.7
    • the last paragraph notes that the discriminator value MUS= T NOT be changed. Since Your Discriminator MUST be set to 0 this refers to = My Discriminator only. I think that explicit reference will make the statem= ent more clear. Thus suggest s/the discriminator values/the My Discriminato= r value/
  • Section 4.8
    • I believe that requiring use = of IP/UDP encapsulation for BFD in multipoint networks over MPSL LSP is too= restrictive. I suggest changing text as following:
OLD:= 
For multipoint LSP, Multipoint=
Tail MUST use destination UDP port "3784" and IP "127.0.0.0/8" range.

NEW
=
If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multipoi=
ntTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784=
" and IP "127.0.0.0/8" ra=
nge. 
Use of other types of encapsul=
ation for multipoint LSP is outside the scope of this document.
  • Section 4.10
    • =

    • I cannot say what bfd.DetectMult =
packet is. It has not been defined in RFC 5880, nor in this document. What =
is the scenario described in the second paragraph? Is it when MultipointHea=
d reduces Desired Min TX  Interval thus making defect detection more aggres=
sive?
  • Section 7
    • I think it should be plural in the =
first paragraph, i.e. s/MultipointTail session/MultipointTail sessions/
    • I think that we can add another c=
onsideration to improve, strengthen security of BFD for multipoint network =
by suggesting that MultipointTail sessions created only for known combinati=
on of MultipointHead and My Discriminator. Such information MAY be learned =
from out-of-band and mechanisms are outside the scope of this document.

Regards,
Greg


On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaa= s@pfrc.org> wrote:
Working = Group,

https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.=C2=A0 (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff


--94eb2c092da0cfad9305536ed46a-- From nobody Wed Jul 5 09:11:54 2017 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 EC73B131D6B for ; Wed, 5 Jul 2017 09:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 6quosbDuWjmK for ; Wed, 5 Jul 2017 09:11:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E2032131BBF for ; Wed, 5 Jul 2017 09:11:48 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ED3F91E34A; Wed, 5 Jul 2017 12:21:03 -0400 (EDT) Date: Wed, 5 Jul 2017 12:21:03 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Message-ID: <20170705162103.GQ2289@pfrc.org> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149885255897.4584.3006333522740435620@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 16:11:52 -0000 Thanks authors for the edits on the BFD yang module. This gets us a significant step closer to alignment with the rest of IETF for network instancing. I'd like to encourage the working group to provide feedback on this issue and also the changes in the module. As noted in another thread, we still have to figure out how to deal with accommodating interaction of the BFD yang module with client protocols. For example, the IGPs. In particular, how do you configure the properties of the BFD sessions that may be dynamically instantiated based on control protocol activity? -- Jeff On Fri, Jun 30, 2017 at 12:55:59PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Bidirectional Forwarding Detection of the IETF. > > Title : YANG Data Model for Bidirectional Forwarding Detection (BFD) > Authors : Reshad Rahman > Lianshu Zheng > Mahesh Jethanandani > Santosh Pallagatti > Greg Mirsky > Filename : draft-ietf-bfd-yang-06.txt > Pages : 59 > Date : 2017-06-30 > > Abstract: > This document defines a YANG data model that can be used to configure > and manage Bidirectional Forwarding Detection (BFD). > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-bfd-yang-06 > https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-yang-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 09:15:53 2017 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 01103131D6B for ; Wed, 5 Jul 2017 09:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 a6wF5qF0311q for ; Wed, 5 Jul 2017 09:15:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ABA73131D48 for ; Wed, 5 Jul 2017 09:15:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DA2A21E34A; Wed, 5 Jul 2017 12:25:05 -0400 (EDT) Date: Wed, 5 Jul 2017 12:25:05 -0400 From: Jeffrey Haas To: "Carlos Pignataro (cpignata)" Cc: "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Message-ID: <20170705162505.GR2289@pfrc.org> References: <20170619193929.GE22146@pfrc.org> <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 16:15:53 -0000 Carlos, Thanks for your detailed feedback. Most of this feedback seems to be of the nature of minor edits. Is it your opinion this document is ready to advance after these issues are addressed? -- Jeff On Tue, Jun 27, 2017 at 02:56:22PM +0000, Carlos Pignataro (cpignata) wrote: > Just one comment on these two documents, in regards to the state variables: > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1 > > 4.4.1. New State Variables > > A number of state variables are added to the base specification in > support of Multipoint BFD. > > bfd.SessionType > > The type of this session. Allowable values are: > > CMP: However, this state (bfd.SessionType) variable is already defined in SBFD RFC 7880: > > https://tools.ietf.org/html/rfc7880#section-6.1 > > 6.1. New State Variables > > A new state variable is added to the base specification in support > of S-BFD. > > o bfd.SessionType: This is a new state variable that describes > the type of a particular session. > > > CMP: So, for draft-ietf-bfd-multipoint, I suggest a pointer to RFC 7880 where bfd.SessionType is defined in the addition of new values to the existing variable. > > CMP: Similarly: > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04#section-3.3.1 > > bfd.SessionType > > The type of this session as defined in > [I-D.ietf-bfd-multipoint]. A new value introduced is: > > CMP: The pointer above should be to RFC 7880 also, and: > > bfd.SilentTail > > CMP: But this is defined in draft-ietf-bfd-multipoint > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1 > > bfd.SilentTail > > Thanks! > > — Carlos. > > > On Jun 19, 2017, at 3:39 PM, Jeffrey Haas > wrote: > > Working Group, > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > The BFD Multipoint documents have been stable for some time. Prior > discussion at meetings has suggested we have an implementation for the main > protocol component. Also per prior discussions, we split the active-tail > component of the original multipoint document to permit implementors to not > have to worry about implementing active-tail procedures if they weren't > interested in that feature. > > We are starting an extended last call on these documents. The WGLC will > conclude on July 14. This provides ample time for list discussion. If > necessary, the IETF-99 meeting may provide for opportunities to close any > contentious technical points. (BFD is not currently scheduled to meet.) > > One item I would like to kick off is the document status of the active-tail > mechanism. At this time, no one has implemented it that I am aware of. > Discussion with our AD suggests that publishing the document with > Experimental status may be reasonable to preserve the work that went into > the proposal. > > -- Jeff > > From nobody Wed Jul 5 09:17:31 2017 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 43886131D48 for ; Wed, 5 Jul 2017 09:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 seT6hMa1M29W for ; Wed, 5 Jul 2017 09:17:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3442D131BBF for ; Wed, 5 Jul 2017 09:17:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 654C41E34A; Wed, 5 Jul 2017 12:26:43 -0400 (EDT) Date: Wed, 5 Jul 2017 12:26:43 -0400 From: Jeffrey Haas To: Greg Mirsky Cc: "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Message-ID: <20170705162643.GS2289@pfrc.org> References: <20170619193929.GE22146@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.22 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, 05 Jul 2017 16:17:30 -0000 Greg, Thanks for your detailed feedback. A portion of your feedback seems to be mostly minor editorial changes. A few of these items are discussion points that probably need to be resolved with some amount of WG discussion. What's your opinion about the ability to advance these documents once these issues have been addressed? -- Jeff On Mon, Jul 03, 2017 at 12:32:44PM -0700, Greg Mirsky wrote: > Dear Authors, WG chairs, et. al, > please kindly consider my comments to the latest version of the draft as > part of WGLC: > > - Very general > - I suggest to add note clarifying that all terms that include > "connectivity" in the document are being used as alternative to > "continuity", i.e. existence of a path between the sender and > the receiver, > and should not be interpreted as "connectivity verification in terms of > transport network". > - Introduction > - I find that characterization of BFD and unidirectional continuity > verification as "natural fit" bit of stretching. Perhaps "capable of > supporting this use case" is acceptable; > - Goals > - the last statement of non-goal seems little unclear. In fact, if > there's only one tail, the BFD for multipoint network does verify > connectivity, though unidirectional, between the head and the > tail. I think > that the intention is to stress that p2p bi-directional connectivity > verification is not supported by this document. > - Section 4.7 > - the last paragraph notes that the discriminator value MUST NOT be > changed. Since Your Discriminator MUST be set to 0 this refers to My > Discriminator only. I think that explicit reference will make > the statement > more clear. Thus suggest s/the discriminator values/the My Discriminator > value/ > - Section 4.8 > - I believe that requiring use of IP/UDP encapsulation for BFD in > multipoint networks over MPSL LSP is too restrictive. I suggest changing > text as following: > > OLD: > > For multipoint LSP, MultipointTail MUST use destination UDP port > "3784" and IP "127.0.0.0/8" range. > > > NEW > > If IP/UDP encapsulation used by MultipointHead for multipoint LSP, > MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP > port "3784" and IP "127.0.0.0/8" range. > > Use of other types of encapsulation for multipoint LSP is outside the > scope of this document. > > > - Section 4.10 > - I cannot say what bfd.DetectMult packet is. It has not been > defined in RFC 5880, nor in this document. What is the scenario > described in the second paragraph? Is it when MultipointHead reduces > Desired Min TX Interval thus making defect detection more aggressive? > - Section 7 > - I think it should be plural in the first paragraph, i.e. > s/MultipointTail session/MultipointTail sessions/ > - I think that we can add another consideration to improve, > strengthen security of BFD for multipoint network by suggesting that > MultipointTail sessions created only for known combination of > MultipointHead and My Discriminator. Such information MAY be learned > from out-of-band and mechanisms are outside the scope of this > document. > > > Regards, > > Greg > > > > On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: > > > Working Group, > > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > > > > The BFD Multipoint documents have been stable for some time. Prior > > discussion at meetings has suggested we have an implementation for the main > > protocol component. Also per prior discussions, we split the active-tail > > component of the original multipoint document to permit implementors to not > > have to worry about implementing active-tail procedures if they weren't > > interested in that feature. > > > > We are starting an extended last call on these documents. The WGLC will > > conclude on July 14. This provides ample time for list discussion. If > > necessary, the IETF-99 meeting may provide for opportunities to close any > > contentious technical points. (BFD is not currently scheduled to meet.) > > > > One item I would like to kick off is the document status of the active-tail > > mechanism. At this time, no one has implemented it that I am aware of. > > Discussion with our AD suggests that publishing the document with > > Experimental status may be reasonable to preserve the work that went into > > the proposal. > > > > -- Jeff > > > > From nobody Wed Jul 5 11:02:40 2017 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 E49E6131D94 for ; Wed, 5 Jul 2017 11:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s86NqZjKSKAg for ; Wed, 5 Jul 2017 11:02:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75347131563 for ; Wed, 5 Jul 2017 11:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21550; q=dns/txt; s=iport; t=1499277756; x=1500487356; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e2XkkpWjEynNWJ916dxt6hx3jR13dI48jIWdrQZhHaw=; b=Gn29j4tgDA/Iz++d1KTrn81ZLnceoPhUgY5ZUDMm/cY0qh3v/pOEBTFH f547uei2O1tnCNg3F+i4AfaKNuiOGUziQ0JgLkkKT8Et418548wfm6Hc8 MN0iVVtlYg6HoWcqT6YASfWPbwCNMmG44OzxNgkjrw8uL5DGGZzZ/Lyja g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAADAKF1Z/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm89LWOBEAeOApFFIpBUhSyCES6FbgIagwI/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkGI1YQAgEIDjEDAgICMBQRAgQOBYlLZBCuPIImiz8BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYMng0yBYAErC4JugTyGQTCCEh8FlymHXQKHRYw+kh6VMgEfOIE?= =?us-ascii?q?KdRVJEgGFDIF2dgEBh3SBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,312,1496102400"; d="scan'208,217";a="448509323" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2017 18:02:35 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v65I2YQs015440 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Jul 2017 18:02:35 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Jul 2017 14:02:34 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Wed, 5 Jul 2017 14:02:34 -0400 From: "Carlos Pignataro (cpignata)" To: Jeff Haas CC: "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Topic: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Index: AQHS6TKRH3+h+CPmGE2vggvMdQNmVaI5G70AgAyrcICAABs8gA== Date: Wed, 5 Jul 2017 18:02:34 +0000 Message-ID: References: <20170619193929.GE22146@pfrc.org> <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> <20170705162505.GR2289@pfrc.org> In-Reply-To: <20170705162505.GR2289@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.50.33] Content-Type: multipart/alternative; boundary="_000_A97B765979614B49BB26D93A4A5509E5ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 18:02:39 -0000 --_000_A97B765979614B49BB26D93A4A5509E5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmVmZiwNCg0KVGhhbmtzIGZvciBzZWVraW5nIGNsYXJpZmljYXRpb24gYW5kIGFwb2xvZ2llcyBm b3Igbm90IGJlaW5nIGV4cGxpY2l0IGVub3VnaDogWWVzLCBJIGJlbGlldmUgdGhpcyBkb2N1bWVu dCBpcyByZWFkeSB0byBhZHZhbmNlLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCk9uIEp1 bCA1LCAyMDE3LCBhdCAxMjoyNSBQTSwgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWls dG86amhhYXNAcGZyYy5vcmc+PiB3cm90ZToNCg0KQ2FybG9zLA0KDQpUaGFua3MgZm9yIHlvdXIg ZGV0YWlsZWQgZmVlZGJhY2suICBNb3N0IG9mIHRoaXMgZmVlZGJhY2sgc2VlbXMgdG8gYmUgb2Yg dGhlDQpuYXR1cmUgb2YgbWlub3IgZWRpdHMuICBJcyBpdCB5b3VyIG9waW5pb24gdGhpcyBkb2N1 bWVudCBpcyByZWFkeSB0byBhZHZhbmNlDQphZnRlciB0aGVzZSBpc3N1ZXMgYXJlIGFkZHJlc3Nl ZD8NCg0KLS0gSmVmZg0KDQpPbiBUdWUsIEp1biAyNywgMjAxNyBhdCAwMjo1NjoyMlBNICswMDAw LCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6DQpKdXN0IG9uZSBjb21tZW50IG9u IHRoZXNlIHR3byBkb2N1bWVudHMsIGluIHJlZ2FyZHMgdG8gdGhlIHN0YXRlIHZhcmlhYmxlczoN Cg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQt MTAjc2VjdGlvbi00LjQuMQ0KDQo0LjQuMS4gIE5ldyBTdGF0ZSBWYXJpYWJsZXMNCg0KICBBIG51 bWJlciBvZiBzdGF0ZSB2YXJpYWJsZXMgYXJlIGFkZGVkIHRvIHRoZSBiYXNlIHNwZWNpZmljYXRp b24gaW4NCiAgc3VwcG9ydCBvZiBNdWx0aXBvaW50IEJGRC4NCg0KICAgICBiZmQuU2Vzc2lvblR5 cGUNCg0KICAgICAgICBUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24uICBBbGxvd2FibGUgdmFsdWVz IGFyZToNCg0KQ01QOiBIb3dldmVyLCB0aGlzIHN0YXRlIChiZmQuU2Vzc2lvblR5cGUpIHZhcmlh YmxlIGlzIGFscmVhZHkgZGVmaW5lZCBpbiBTQkZEIFJGQyA3ODgwOg0KDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzg4MCNzZWN0aW9uLTYuMQ0KDQo2LjEuICBOZXcgU3RhdGUgVmFy aWFibGVzDQoNCiAgQSBuZXcgc3RhdGUgdmFyaWFibGUgaXMgYWRkZWQgdG8gdGhlIGJhc2Ugc3Bl Y2lmaWNhdGlvbiBpbiBzdXBwb3J0DQogIG9mIFMtQkZELg0KDQogIG8gIGJmZC5TZXNzaW9uVHlw ZTogVGhpcyBpcyBhIG5ldyBzdGF0ZSB2YXJpYWJsZSB0aGF0IGRlc2NyaWJlcw0KICAgICB0aGUg dHlwZSBvZiBhIHBhcnRpY3VsYXIgc2Vzc2lvbi4NCg0KDQpDTVA6IFNvLCBmb3IgZHJhZnQtaWV0 Zi1iZmQtbXVsdGlwb2ludCwgSSBzdWdnZXN0IGEgcG9pbnRlciB0byBSRkMgNzg4MCB3aGVyZSBi ZmQuU2Vzc2lvblR5cGUgaXMgZGVmaW5lZCBpbiB0aGUgYWRkaXRpb24gb2YgbmV3IHZhbHVlcyB0 byB0aGUgZXhpc3RpbmcgdmFyaWFibGUuDQoNCkNNUDogU2ltaWxhcmx5Og0KDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbC0w NCNzZWN0aW9uLTMuMy4xDQoNCiAgICAgYmZkLlNlc3Npb25UeXBlDQoNCiAgICAgICAgVGhlIHR5 cGUgb2YgdGhpcyBzZXNzaW9uIGFzIGRlZmluZWQgaW4NCiAgICAgICAgW0ktRC5pZXRmLWJmZC1t dWx0aXBvaW50XS4gIEEgbmV3IHZhbHVlIGludHJvZHVjZWQgaXM6DQoNCkNNUDogVGhlIHBvaW50 ZXIgYWJvdmUgc2hvdWxkIGJlIHRvIFJGQyA3ODgwIGFsc28sIGFuZDoNCg0KICAgICBiZmQuU2ls ZW50VGFpbA0KDQpDTVA6IEJ1dCB0aGlzIGlzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1iZmQtbXVs dGlwb2ludA0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVs dGlwb2ludC0xMCNzZWN0aW9uLTQuNC4xDQoNCiAgICAgYmZkLlNpbGVudFRhaWwNCg0KVGhhbmtz IQ0KDQrigJQgQ2FybG9zLg0KDQoNCk9uIEp1biAxOSwgMjAxNywgYXQgMzozOSBQTSwgSmVmZnJl eSBIYWFzIDxqaGFhc0BwZnJjLm9yZzxtYWlsdG86amhhYXNAcGZyYy5vcmc+PG1haWx0bzpqaGFh c0BwZnJjLm9yZz4+IHdyb3RlOg0KDQpXb3JraW5nIEdyb3VwLA0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMA0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDQNCg0K DQpUaGUgQkZEIE11bHRpcG9pbnQgZG9jdW1lbnRzIGhhdmUgYmVlbiBzdGFibGUgZm9yIHNvbWUg dGltZS4gIFByaW9yDQpkaXNjdXNzaW9uIGF0IG1lZXRpbmdzIGhhcyBzdWdnZXN0ZWQgd2UgaGF2 ZSBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgdGhlIG1haW4NCnByb3RvY29sIGNvbXBvbmVudC4gIEFs c28gcGVyIHByaW9yIGRpc2N1c3Npb25zLCB3ZSBzcGxpdCB0aGUgYWN0aXZlLXRhaWwNCmNvbXBv bmVudCBvZiB0aGUgb3JpZ2luYWwgbXVsdGlwb2ludCBkb2N1bWVudCB0byBwZXJtaXQgaW1wbGVt ZW50b3JzIHRvIG5vdA0KaGF2ZSB0byB3b3JyeSBhYm91dCBpbXBsZW1lbnRpbmcgYWN0aXZlLXRh aWwgcHJvY2VkdXJlcyBpZiB0aGV5IHdlcmVuJ3QNCmludGVyZXN0ZWQgaW4gdGhhdCBmZWF0dXJl Lg0KDQpXZSBhcmUgc3RhcnRpbmcgYW4gZXh0ZW5kZWQgbGFzdCBjYWxsIG9uIHRoZXNlIGRvY3Vt ZW50cy4gIFRoZSBXR0xDIHdpbGwNCmNvbmNsdWRlIG9uIEp1bHkgMTQuICBUaGlzIHByb3ZpZGVz IGFtcGxlIHRpbWUgZm9yIGxpc3QgZGlzY3Vzc2lvbi4gIElmDQpuZWNlc3NhcnksIHRoZSBJRVRG LTk5IG1lZXRpbmcgbWF5IHByb3ZpZGUgZm9yIG9wcG9ydHVuaXRpZXMgdG8gY2xvc2UgYW55DQpj b250ZW50aW91cyB0ZWNobmljYWwgcG9pbnRzLiAgKEJGRCBpcyBub3QgY3VycmVudGx5IHNjaGVk dWxlZCB0byBtZWV0LikNCg0KT25lIGl0ZW0gSSB3b3VsZCBsaWtlIHRvIGtpY2sgb2ZmIGlzIHRo ZSBkb2N1bWVudCBzdGF0dXMgb2YgdGhlIGFjdGl2ZS10YWlsDQptZWNoYW5pc20uICBBdCB0aGlz IHRpbWUsIG5vIG9uZSBoYXMgaW1wbGVtZW50ZWQgaXQgdGhhdCBJIGFtIGF3YXJlIG9mLg0KRGlz Y3Vzc2lvbiB3aXRoIG91ciBBRCBzdWdnZXN0cyB0aGF0IHB1Ymxpc2hpbmcgdGhlIGRvY3VtZW50 IHdpdGgNCkV4cGVyaW1lbnRhbCBzdGF0dXMgbWF5IGJlIHJlYXNvbmFibGUgdG8gcHJlc2VydmUg dGhlIHdvcmsgdGhhdCB3ZW50IGludG8NCnRoZSBwcm9wb3NhbC4NCg0KLS0gSmVmZg0KDQrigJQN CkNhcmxvcyBQaWduYXRhcm8sIGNhcmxvc0BjaXNjby5jb208bWFpbHRvOmNhcmxvc0BjaXNjby5j b20+DQoNCuKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxseSB1 bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3JlIHBob3Rvc3ludGhlc2lzLiINCg0K --_000_A97B765979614B49BB26D93A4A5509E5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9476191747896546B969AC95D88904BF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSmVmZiwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3Igc2Vla2luZyBj bGFyaWZpY2F0aW9uIGFuZCBhcG9sb2dpZXMgZm9yIG5vdCBiZWluZyBleHBsaWNpdCBlbm91Z2g6 IFllcywgSSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYWR2YW5jZS48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5r cyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVs IDUsIDIwMTcsIGF0IDEyOjI1IFBNLCBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpq aGFhc0BwZnJjLm9yZyIgY2xhc3M9IiI+amhhYXNAcGZyYy5vcmc8L2E+Jmd0OyB3cm90ZTo8L2Rp dj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5DYXJsb3MsPC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhhbmtzDQog Zm9yIHlvdXIgZGV0YWlsZWQgZmVlZGJhY2suICZuYnNwO01vc3Qgb2YgdGhpcyBmZWVkYmFjayBz ZWVtcyB0byBiZSBvZiB0aGU8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+bmF0dXJlDQogb2YgbWlub3IgZWRpdHMuICZuYnNwO0lzIGl0IHlvdXIgb3Bp bmlvbiB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IHRvIGFkdmFuY2U8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+YWZ0ZXINCiB0aGVzZSBpc3N1ZXMgYXJl IGFkZHJlc3NlZD88L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj4tLQ0KIEplZmY8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5Pbg0KIFR1ZSwgSnVuIDI3LCAyMDE3IGF0IDAyOjU2OjIyUE0gJiM0Mzsw MDAwLCBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgd3JvdGU6PC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQpKdXN0IG9uZSBjb21tZW50IG9uIHRoZXNlIHR3byBkb2N1bWVudHMs IGluIHJlZ2FyZHMgdG8gdGhlIHN0YXRlIHZhcmlhYmxlczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1i ZmQtbXVsdGlwb2ludC0xMCNzZWN0aW9uLTQuNC4xIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC0xMCNzZWN0aW9uLTQuNC4xPC9h PjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjQuNC4xLiAmbmJzcDtOZXcgU3RhdGUgVmFy aWFibGVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7QSBudW1iZXIg b2Ygc3RhdGUgdmFyaWFibGVzIGFyZSBhZGRlZCB0byB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uIGlu PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7c3VwcG9ydCBvZiBNdWx0aXBvaW50IEJGRC48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDti ZmQuU2Vzc2lvblR5cGU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgdHlwZSBvZiB0aGlzIHNlc3Np b24uICZuYnNwO0FsbG93YWJsZSB2YWx1ZXMgYXJlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkNNUDogSG93ZXZlciwgdGhpcyBzdGF0ZSAoYmZkLlNlc3Npb25UeXBlKSB2YXJpYWJsZSBp cyBhbHJlYWR5IGRlZmluZWQgaW4gU0JGRCBSRkMgNzg4MDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg4MCNzZWN0 aW9uLTYuMSIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4ODAjc2Vj dGlvbi02LjE8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KNi4xLiAmbmJzcDtOZXcg U3RhdGUgVmFyaWFibGVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 QSBuZXcgc3RhdGUgdmFyaWFibGUgaXMgYWRkZWQgdG8gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbiBp biBzdXBwb3J0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7b2YgUy1CRkQuPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDtiZmQuU2Vzc2lvblR5cGU6IFRo aXMgaXMgYSBuZXcgc3RhdGUgdmFyaWFibGUgdGhhdCBkZXNjcmliZXM8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgdHlwZSBvZiBhIHBhcnRpY3VsYXIgc2Vz c2lvbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDTVA6IFNv LCBmb3IgZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludCwgSSBzdWdnZXN0IGEgcG9pbnRlciB0byBS RkMgNzg4MCB3aGVyZSBiZmQuU2Vzc2lvblR5cGUgaXMgZGVmaW5lZCBpbiB0aGUgYWRkaXRpb24g b2YgbmV3IHZhbHVlcyB0byB0aGUgZXhpc3RpbmcgdmFyaWFibGUuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQ01QOiBTaW1pbGFybHk6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0 aXZlLXRhaWwtMDQjc2VjdGlvbi0zLjMuMTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2JmZC5TZXNzaW9uVHlwZTxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1RoZSB0eXBlIG9mIHRoaXMgc2Vzc2lvbiBhcyBkZWZpbmVkIGluPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W0ktRC5p ZXRmLWJmZC1tdWx0aXBvaW50XS4gJm5ic3A7QSBuZXcgdmFsdWUgaW50cm9kdWNlZCBpczo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDTVA6IFRoZSBwb2ludGVyIGFib3ZlIHNob3VsZCBi ZSB0byBSRkMgNzg4MCBhbHNvLCBhbmQ6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YmZkLlNpbGVudFRhaWw8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpDTVA6IEJ1dCB0aGlzIGlzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1iZmQt bXVsdGlwb2ludDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTEwI3NlY3Rpb24tNC40LjE8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDti ZmQuU2lsZW50VGFpbDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyE8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrigJQgQ2FybG9zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIEp1biAxOSwgMjAxNywgYXQgMzozOSBQTSwgSmVmZnJl eSBIYWFzICZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIGNsYXNzPSIiPmpoYWFz QHBmcmMub3JnPC9hPiZsdDs8YSBocmVmPSJtYWlsdG86amhhYXNAcGZyYy5vcmciIGNsYXNzPSIi Pm1haWx0bzpqaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpXb3JraW5nIEdyb3VwLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTEw PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZk LW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpUaGUgQkZEIE11bHRpcG9pbnQgZG9jdW1lbnRzIGhhdmUgYmVlbiBzdGFi bGUgZm9yIHNvbWUgdGltZS4gJm5ic3A7UHJpb3I8YnIgY2xhc3M9IiI+DQpkaXNjdXNzaW9uIGF0 IG1lZXRpbmdzIGhhcyBzdWdnZXN0ZWQgd2UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBmb3IgdGhl IG1haW48YnIgY2xhc3M9IiI+DQpwcm90b2NvbCBjb21wb25lbnQuICZuYnNwO0Fsc28gcGVyIHBy aW9yIGRpc2N1c3Npb25zLCB3ZSBzcGxpdCB0aGUgYWN0aXZlLXRhaWw8YnIgY2xhc3M9IiI+DQpj b21wb25lbnQgb2YgdGhlIG9yaWdpbmFsIG11bHRpcG9pbnQgZG9jdW1lbnQgdG8gcGVybWl0IGlt cGxlbWVudG9ycyB0byBub3Q8YnIgY2xhc3M9IiI+DQpoYXZlIHRvIHdvcnJ5IGFib3V0IGltcGxl bWVudGluZyBhY3RpdmUtdGFpbCBwcm9jZWR1cmVzIGlmIHRoZXkgd2VyZW4ndDxiciBjbGFzcz0i Ij4NCmludGVyZXN0ZWQgaW4gdGhhdCBmZWF0dXJlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCldlIGFyZSBzdGFydGluZyBhbiBleHRlbmRlZCBsYXN0IGNhbGwgb24gdGhlc2UgZG9jdW1l bnRzLiAmbmJzcDtUaGUgV0dMQyB3aWxsPGJyIGNsYXNzPSIiPg0KY29uY2x1ZGUgb24gSnVseSAx NC4gJm5ic3A7VGhpcyBwcm92aWRlcyBhbXBsZSB0aW1lIGZvciBsaXN0IGRpc2N1c3Npb24uICZu YnNwO0lmPGJyIGNsYXNzPSIiPg0KbmVjZXNzYXJ5LCB0aGUgSUVURi05OSBtZWV0aW5nIG1heSBw cm92aWRlIGZvciBvcHBvcnR1bml0aWVzIHRvIGNsb3NlIGFueTxiciBjbGFzcz0iIj4NCmNvbnRl bnRpb3VzIHRlY2huaWNhbCBwb2ludHMuICZuYnNwOyhCRkQgaXMgbm90IGN1cnJlbnRseSBzY2hl ZHVsZWQgdG8gbWVldC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT25lIGl0ZW0gSSB3 b3VsZCBsaWtlIHRvIGtpY2sgb2ZmIGlzIHRoZSBkb2N1bWVudCBzdGF0dXMgb2YgdGhlIGFjdGl2 ZS10YWlsPGJyIGNsYXNzPSIiPg0KbWVjaGFuaXNtLiAmbmJzcDtBdCB0aGlzIHRpbWUsIG5vIG9u ZSBoYXMgaW1wbGVtZW50ZWQgaXQgdGhhdCBJIGFtIGF3YXJlIG9mLjxiciBjbGFzcz0iIj4NCkRp c2N1c3Npb24gd2l0aCBvdXIgQUQgc3VnZ2VzdHMgdGhhdCBwdWJsaXNoaW5nIHRoZSBkb2N1bWVu dCB3aXRoPGJyIGNsYXNzPSIiPg0KRXhwZXJpbWVudGFsIHN0YXR1cyBtYXkgYmUgcmVhc29uYWJs ZSB0byBwcmVzZXJ2ZSB0aGUgd29yayB0aGF0IHdlbnQgaW50bzxiciBjbGFzcz0iIj4NCnRoZSBw cm9wb3NhbC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSBKZWZmPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Vi a2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQrigJQ8L2Rpdj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQ2FybG9zIFBpZ25hdGFybywmbmJzcDs8 YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y2FybG9zQGNpc2NvLmNv bTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8aSBjbGFzcz0iIj7igJxTb21ldGlt ZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFr ZSBteXNlbGYgc291bmQgbW9yZSZuYnNwO3Bob3Rvc3ludGhlc2lzLiZxdW90OzwvaT48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A97B765979614B49BB26D93A4A5509E5ciscocom_-- From nobody Wed Jul 5 11:10:41 2017 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 7ED77131D80 for ; Wed, 5 Jul 2017 11:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 YzGnmFqdlEwQ for ; Wed, 5 Jul 2017 11:10:38 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 36F0C12EBF9 for ; Wed, 5 Jul 2017 11:10:38 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d78so195966408qkb.1 for ; Wed, 05 Jul 2017 11:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RSiUPKUMx47nKTspdLBQc76HTZ1bGE23ykz5tjYHB4Y=; b=VlSVlcHg8qq96tP9uI3u0nx9Pv6KQVI9hRrTBAhY7FGuX1tr6xunCCd7+MSciKGfvj O7B6rXPANnsYKbJQyZlGhnC7gfgH6tlia90ex3tXAYo+gi41eD477FiGJvsON/FpdSQ8 VuJ8GcNHBN+otN0h9nNWEE9uiMavzO6fla/sNJ3maVJol9iCF5hiUbAeBE6+oRiSSAwv S+p76Lt1/cxA/mcRi/vz7V5Us9CuBpnoRBlFeJMI5gu/NFAQu5ojerF0XLMePv300RO1 Ixcft+62P/00ar37BFQSPYa4Pe54iNW6Kve5q3LBHz4d56n3gju+iF873wVPkHLzPHXx EOgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RSiUPKUMx47nKTspdLBQc76HTZ1bGE23ykz5tjYHB4Y=; b=i4jSNGcV+VeZPmBjEeETepZracLjBG+C+iR5bhof7CNDW1PYemMxbUVDqGMsfdxVSO de1X7Lv+5yJMtoRx6HvtaCPweYWKc+pcvIvffH8a2KH3rBWXCKFBcZS2cnaDmSj2o3ue 1DekkdK6WjBQQftNcFjox1grPO2loNNOIE/6xvMf7+Ebx5ijQQmDHGaFm9nH0MUZf53j c06tv0/HkCREBZidKgY4J1htQYAw1D+3hXPj7p2CQuYDd/eurqjE/2aUJsGDb13NP0zS 79ARtC7CXi49VrESqfhY290YkSLhVV3zdmqZUwGpNojCwJyRsltzuVUl9uuSuEWFWUPM pjhw== X-Gm-Message-State: AKS2vOzW0tdw90EAtJndGhiQz9R1/7xv9/k5E/qh5zHgwg8TJQiWmTG5 lg2Vz9ezsex+QNcvaOtQiakYaejN2A== X-Received: by 10.55.39.194 with SMTP id n185mr56680822qkn.139.1499278237085; Wed, 05 Jul 2017 11:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Wed, 5 Jul 2017 11:10:36 -0700 (PDT) In-Reply-To: <20170705162643.GS2289@pfrc.org> References: <20170619193929.GE22146@pfrc.org> <20170705162643.GS2289@pfrc.org> From: Greg Mirsky Date: Wed, 5 Jul 2017 11:10:36 -0700 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Jeffrey Haas Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c092da0bdb3f9055395eac0" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 18:10:40 -0000 --94eb2c092da0bdb3f9055395eac0 Content-Type: text/plain; charset="UTF-8" Hi Jeff, thank you for your kind consideration of my comments. Yes, after we agree on how to address the comments, the document shall be advanced. Regards, Greg On Wed, Jul 5, 2017 at 9:26 AM, Jeffrey Haas wrote: > Greg, > > Thanks for your detailed feedback. > > A portion of your feedback seems to be mostly minor editorial changes. A > few of these items are discussion points that probably need to be resolved > with some amount of WG discussion. > > What's your opinion about the ability to advance these documents once these > issues have been addressed? > > -- Jeff > > On Mon, Jul 03, 2017 at 12:32:44PM -0700, Greg Mirsky wrote: > > Dear Authors, WG chairs, et. al, > > please kindly consider my comments to the latest version of the draft as > > part of WGLC: > > > > - Very general > > - I suggest to add note clarifying that all terms that include > > "connectivity" in the document are being used as alternative to > > "continuity", i.e. existence of a path between the sender and > > the receiver, > > and should not be interpreted as "connectivity verification in > terms of > > transport network". > > - Introduction > > - I find that characterization of BFD and unidirectional continuity > > verification as "natural fit" bit of stretching. Perhaps "capable > of > > supporting this use case" is acceptable; > > - Goals > > - the last statement of non-goal seems little unclear. In fact, if > > there's only one tail, the BFD for multipoint network does verify > > connectivity, though unidirectional, between the head and the > > tail. I think > > that the intention is to stress that p2p bi-directional > connectivity > > verification is not supported by this document. > > - Section 4.7 > > - the last paragraph notes that the discriminator value MUST NOT be > > changed. Since Your Discriminator MUST be set to 0 this refers to > My > > Discriminator only. I think that explicit reference will make > > the statement > > more clear. Thus suggest s/the discriminator values/the My > Discriminator > > value/ > > - Section 4.8 > > - I believe that requiring use of IP/UDP encapsulation for BFD in > > multipoint networks over MPSL LSP is too restrictive. I suggest > changing > > text as following: > > > > OLD: > > > > For multipoint LSP, MultipointTail MUST use destination UDP port > > "3784" and IP "127.0.0.0/8" range. > > > > > > NEW > > > > If IP/UDP encapsulation used by MultipointHead for multipoint LSP, > > MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP > > port "3784" and IP "127.0.0.0/8" range. > > > > Use of other types of encapsulation for multipoint LSP is outside the > > scope of this document. > > > > > > - Section 4.10 > > - I cannot say what bfd.DetectMult packet is. It has not been > > defined in RFC 5880, nor in this document. What is the scenario > > described in the second paragraph? Is it when MultipointHead reduces > > Desired Min TX Interval thus making defect detection more aggressive? > > - Section 7 > > - I think it should be plural in the first paragraph, i.e. > > s/MultipointTail session/MultipointTail sessions/ > > - I think that we can add another consideration to improve, > > strengthen security of BFD for multipoint network by suggesting that > > MultipointTail sessions created only for known combination of > > MultipointHead and My Discriminator. Such information MAY be learned > > from out-of-band and mechanisms are outside the scope of this > > document. > > > > > > Regards, > > > > Greg > > > > > > > > On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: > > > > > Working Group, > > > > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > > > > > > > The BFD Multipoint documents have been stable for some time. Prior > > > discussion at meetings has suggested we have an implementation for the > main > > > protocol component. Also per prior discussions, we split the > active-tail > > > component of the original multipoint document to permit implementors > to not > > > have to worry about implementing active-tail procedures if they weren't > > > interested in that feature. > > > > > > We are starting an extended last call on these documents. The WGLC > will > > > conclude on July 14. This provides ample time for list discussion. If > > > necessary, the IETF-99 meeting may provide for opportunities to close > any > > > contentious technical points. (BFD is not currently scheduled to > meet.) > > > > > > One item I would like to kick off is the document status of the > active-tail > > > mechanism. At this time, no one has implemented it that I am aware of. > > > Discussion with our AD suggests that publishing the document with > > > Experimental status may be reasonable to preserve the work that went > into > > > the proposal. > > > > > > -- Jeff > > > > > > > --94eb2c092da0bdb3f9055395eac0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,
thank you for your kind consideration of my c= omments. Yes, after we agree on how to address the comments, the document s= hall be advanced.

Regards,
Greg

On Wed, Jul 5,= 2017 at 9:26 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Greg,

Thanks for your detailed feedback.

A portion of your feedback seems to be mostly minor editorial change= s.=C2=A0 A
few of these items are discussion points that probably need to be resolved<= br> with some amount of WG discussion.

What's your opinion about the ability to advance these documents once t= hese
issues have been addressed?

-- Jeff

On Mon, Jul 03, 2017 at 12:32:44PM -0700, Greg Mirsky wrote:
> Dear Authors, WG chairs, et. al,
> please kindly consider my comments to the latest version of the draft = as
> part of WGLC:
>
>=C2=A0 =C2=A0 - Very general
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I suggest to add note clarifying that all = terms that include
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"connectivity" in= the document are being used as alternative to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"continuity", i.e. existence of a = path between the sender and
> the receiver,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and should not be interpreted as "conne= ctivity verification in terms of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0transport network".
>=C2=A0 =C2=A0 - Introduction
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I find that characterization of BFD and un= idirectional continuity
>=C2=A0 =C2=A0 =C2=A0 =C2=A0verification as "natur= al fit" bit of stretching. Perhaps "capable of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0supporting this use case" is acceptable= ;
>=C2=A0 =C2=A0 - Goals
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- the last statement of non-goal seems littl= e unclear. In fact, if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0there's only one tail, = the BFD for multipoint network does verify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0connectivity, though unidirectional, between= the head and the
> tail. I think
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that the intention is to stress that p2p bi-= directional connectivity
>=C2=A0 =C2=A0 =C2=A0 =C2=A0verification is not supported by this docume= nt.
>=C2=A0 =C2=A0 - Section 4.7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- the last paragraph notes that the discrimi= nator value MUST NOT be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0changed. Since Your Discrim= inator MUST be set to 0 this refers to My
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Discriminator only. I think that explicit re= ference will make
> the statement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more clear. Thus suggest s/the discriminator= values/the My Discriminator
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value/
>=C2=A0 =C2=A0 - Section 4.8
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I believe that requiring use of IP/UDP enc= apsulation for BFD in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0multipoint networks over MP= SL LSP is too restrictive. I suggest changing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0text as following:
>
> OLD:
>
> For multipoint LSP, MultipointTail MUST use destination UDP port
> "3784" and IP "127.0.0.0/8" range.
>
>
> NEW
>
> If IP/UDP encapsulation used by MultipointHead for multipoint LSP,
> MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP > port "3784" and IP "127.0.0.0/8" range.
>
> Use of other types of encapsulation for multipoint LSP is outside the<= br> > scope of this document.
>
>
>=C2=A0 =C2=A0 - Section 4.10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I cannot say what bfd.DetectMult packet is= . It has not been
> defined in RFC 5880, nor in this document. What is th= e scenario
> described in the second paragraph? Is it when MultipointHead reduces > Desired Min TX=C2=A0 Interval thus making defect detection more aggres= sive?
>=C2=A0 =C2=A0 - Section 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I think it should be plural in the first p= aragraph, i.e.
> s/MultipointTail session/MultipointTail sessions/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- I think that we can add another considerat= ion to improve,
> strengthen security of BFD for= multipoint network by suggesting that
> MultipointTail sessions created only for known combination of
> MultipointHead and My Discriminator. Such information MAY be learned > from out-of-band and mechanisms are outside the scope of this
> document.
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
> > Working Group,
> >
> > https://tools.ietf.org/html/d= raft-ietf-bfd-multipoint-10
> > https://tools.ietf.org= /html/draft-ietf-bfd-multipoint-active-tail-04
> >
> >
> > The BFD Multipoint documents have been stable for some time.=C2= =A0 Prior
> > discussion at meetings has suggested we have an implementation fo= r the main
> > protocol component.=C2=A0 Also per prior discussions, we split th= e active-tail
> > component of the original multipoint document to permit implement= ors to not
> > have to worry about implementing active-tail procedures if they w= eren't
> > interested in that feature.
> >
> > We are starting an extended last call on these documents.=C2=A0 T= he WGLC will
> > conclude on July 14.=C2=A0 This provides ample time for list disc= ussion.=C2=A0 If
> > necessary, the IETF-99 meeting may provide for opportunities to c= lose any
> > contentious technical points.=C2=A0 (BFD is not currently schedul= ed to meet.)
> >
> > One item I would like to kick off is the document status of the a= ctive-tail
> > mechanism.=C2=A0 At this time, no one has implemented it that I a= m aware of.
> > Discussion with our AD suggests that publishing the document with=
> > Experimental status may be reasonable to preserve the work that w= ent into
> > the proposal.
> >
> > -- Jeff
> >
> >

--94eb2c092da0bdb3f9055395eac0-- From nobody Thu Jul 6 09:49:30 2017 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 B009413165C for ; Thu, 6 Jul 2017 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 5_kPjtaD95Ca for ; Thu, 6 Jul 2017 09:49:21 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 094E512EC0B for ; Thu, 6 Jul 2017 09:49:21 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id k192so9251902ith.1 for ; Thu, 06 Jul 2017 09:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3tfmVw+bOKtYXnr4skVqyhb6q+bch3/ncXXG6avJrJs=; b=YYv+lnPmZFuXXxR3pv4T//UoccJBPVbXAwfskk5VdMT5K9+ViUhyB8kwZt6dTbd7lH /XJgfksA7eAojSZrCE4UyXxqZI5ZQLvgZ55o7tO6M63MRwTdnITBjZvrYuGa/o1ASQW2 NTVdP9u/XwvDCfRWvOXKMwcn89o7eNSKeACbpIoGFl1jmdBarS52Vz53zkDVNyzYirqc khhOPfcKxndX0ttpQEQw8fxQqLO0Ud9ifr5zkGXqlAEFqT1FZBqHYCI7ksfRvxHKWe1Z Y3b0rWy7LwYsIWVEn4IOBJPtuFFkBtqfOOZsKkB4yNt4soRIntfKez6+Evbc7Jqeti0G WF4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3tfmVw+bOKtYXnr4skVqyhb6q+bch3/ncXXG6avJrJs=; b=ez+J3zr6wo+asGfD/g+s2tuHjtdGqTvnHeqQwaZIPc06uMnK1xW/9C/yn/oS3Io7J5 +QCS3eSeyYCkZZjtuhOCnu6uvh1XSlcpTHmXbSKDhqR+LuRJeUD9mvWa6ja2aywClmGn KON2n/PzxklJDC1OWUo9JTKo8CRTWK2l9al++ugBgkP7B7z5HXhlXlQvrXy/1AApn3e+ bQ1xZxhV5WVMdwnMSJS6m2tRxSJ7XZgpxwi5J7RQlhvmmr9SY7kxF124Mkfgt4H0mLNn ajJdkfrWF356Guor+Y9yXtISqhb87K2rjzp330hDkMpcOtjLjfYPnz7FqPSYmqr4t7Qw Kx4A== X-Gm-Message-State: AIVw111EbSMFiuUrJ3UXJh9dYO907d3VlHqS39xs/5R5pvP31JDwkDGY 4Vu40jUfWvemP0i1Gk9v8RefRuuMVg== X-Received: by 10.36.61.85 with SMTP id n82mr415354itn.2.1499359760323; Thu, 06 Jul 2017 09:49:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.70 with HTTP; Thu, 6 Jul 2017 09:49:19 -0700 (PDT) In-Reply-To: <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> References: <20170619193929.GE22146@pfrc.org> <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> From: Santosh P K Date: Thu, 6 Jul 2017 22:19:19 +0530 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: "Carlos Pignataro (cpignata)" Cc: Jeff Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a113f863ee79b5f0553a8e5d1" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:49:24 -0000 --001a113f863ee79b5f0553a8e5d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Carlos, Thanks for your review comments. Please see inline [SPK]. Thanks Santosh P K On Tue, Jun 27, 2017 at 8:26 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Just one comment on these two documents, in regards to the state > variables: > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1 > > 4.4.1. New State Variables > > A number of state variables are added to the base specification in > support of Multipoint BFD. > > bfd.SessionType > > The type of this session. Allowable values are: > > CMP: However, this state (bfd.SessionType) variable is already defined in > SBFD RFC 7880: > [SPK] Ok we can remove it here and give reference to RFC 7880. This draft can use this state variable and need not say that new state variable. > > https://tools.ietf.org/html/rfc7880#section-6.1 > > 6.1. New State Variables > > A new state variable is added to the base specification in support > of S-BFD. > > o bfd.SessionType: This is a new state variable that describes > the type of a particular session. > > > CMP: So, for draft-ietf-bfd-multipoint, I suggest a pointer to RFC 7880 > where bfd.SessionType is defined in the addition of new values to the > existing variable. > [SPK] Sure. > > CMP: Similarly: > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint- > active-tail-04#section-3.3.1 > > bfd.SessionType > > The type of this session as defined in > [I-D.ietf-bfd-multipoint]. A new value introduced is: > > CMP: The pointer above should be to RFC 7880 also, and: > > bfd.SilentTail > > CMP: But this is defined in draft-ietf-bfd-multipoint > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10#section-4.4.1 > > bfd.SilentTail > > [SPK] I will take care of this. > Thanks! > > =E2=80=94 Carlos. > > > On Jun 19, 2017, at 3:39 PM, Jeffrey Haas wrote: > > Working Group, > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > The BFD Multipoint documents have been stable for some time. Prior > discussion at meetings has suggested we have an implementation for the > main > protocol component. Also per prior discussions, we split the active-tail > component of the original multipoint document to permit implementors to n= ot > have to worry about implementing active-tail procedures if they weren't > interested in that feature. > > We are starting an extended last call on these documents. The WGLC will > conclude on July 14. This provides ample time for list discussion. If > necessary, the IETF-99 meeting may provide for opportunities to close any > contentious technical points. (BFD is not currently scheduled to meet.) > > One item I would like to kick off is the document status of the active-ta= il > mechanism. At this time, no one has implemented it that I am aware of. > Discussion with our AD suggests that publishing the document with > Experimental status may be reasonable to preserve the work that went into > the proposal. > > -- Jeff > > > --001a113f863ee79b5f0553a8e5d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Carlos,
=C2=A0 =C2=A0 =C2=A0Thanks for your revi= ew comments. Please see inline [SPK].

Thanks
=
Santosh P K=C2=A0

On Tue, Jun 27, 2017 at 8:26 PM, Carlos Pignataro (cpignata) <cp= ignata@cisco.com> wrote:
Just one comment on these two documents, in regards to the state variables:


4.4.1.=C2=A0 New State Variables

=C2=A0 =C2=A0A number of state variables are added to the base specifi= cation in
=C2=A0 =C2=A0support of Multipoint BFD.

=C2=A0 =C2=A0 =C2=A0 bfd.SessionType

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The type of this session.=C2=A0 Allo= wable values are:

CMP: However, this state (bfd.SessionType) variable is already defined= in SBFD RFC 7880:

[SPK] Ok we = can remove it here and give reference to RFC 7880. This draft can use this = state variable and need not say that new state variable.=C2=A0
= =C2=A0


6.1.=C2=A0 New State Variables

=C2=A0 =C2=A0A new state variable is added to the base specification i= n support
=C2=A0 =C2=A0of S-BFD.

=C2=A0 =C2=A0o =C2=A0bfd.SessionType: This is a new state variable tha= t describes
=C2=A0 =C2=A0 =C2=A0 the type of a particular session.=C2=A0


CMP: So, for draft-ietf-bfd-multipoint, I suggest a pointer to RFC 788= 0 where=C2=A0bfd.SessionType=C2=A0is defined in the addition of new values = to the existing variable.

[SPK]= Sure.=C2=A0

CMP: Similarly:


=C2=A0 =C2=A0 =C2=A0 bfd.SessionType

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The type of this session as defined = in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-bfd-multipoint].=C2=A0 A n= ew value introduced is:

CMP: The pointer above should be to RFC 7880 also, and:

=C2=A0 =C2=A0 =C2=A0 bfd.SilentTail

CMP: But this is defined in draft-ietf-bfd-multipoint


[SPK] I will take care of this.

=C2=A0
Thanks!

=E2=80=94 Carlos.


On Jun 19, 2017, at 3:39 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-mul= tipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points. =C2=A0(BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff



--001a113f863ee79b5f0553a8e5d1-- From nobody Thu Jul 6 09:55:41 2017 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 E2533131670 for ; Thu, 6 Jul 2017 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXiTEy5HQwTU for ; Thu, 6 Jul 2017 09:55:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FE81317D2 for ; Thu, 6 Jul 2017 09:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18506; q=dns/txt; s=iport; t=1499360137; x=1500569737; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DWYNM1fje316mXfhfoSkw/YRCgspKiX1XwJfAF7OQVg=; b=DNej77fkd2ocLfEXO6Q8l1skY9l0zrUXDVzbD/0vu79J4m5Zg5jEZIRd frM2KaVChWZYEHHpKq0jxLG5aa5AGJuWmyyxmsYTAy/TTO2s2dpP9TRf0 WuhwWMlKyb98eQ4WBAbKVoT73pLMHUKskU8rT2a95K/siHUWP4t4ngFZV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBLal5Z/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywtY4ERB44CkUeIUIgphSyCES6FbgIagxU/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkGI1YQAgEIPwMCAgIfERQRAgQOBYlLTAMVELEjgiaHNQ2DcwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFgyeDTIFgASsLgm6BPIEbhSYwghIfBZcuhyY7AodFh1S?= =?us-ascii?q?Ea4IMhUqKSIt3iUABHziBCnUVSRIBhEdFgXd2AQGHY4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,318,1496102400"; d="scan'208,217";a="264497512" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2017 16:55:36 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v66Gta7G000403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Jul 2017 16:55:36 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Jul 2017 12:55:35 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 6 Jul 2017 12:55:35 -0400 From: "Carlos Pignataro (cpignata)" To: Santosh P K CC: Jeff Haas , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Topic: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Index: AQHS6TKRH3+h+CPmGE2vggvMdQNmVaI5G70AgA5Ei4CAAAG/AA== Date: Thu, 6 Jul 2017 16:55:35 +0000 Message-ID: References: <20170619193929.GE22146@pfrc.org> <0B1CE01B-4FA3-4536-AF41-5DDC6F510C0D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.131] Content-Type: multipart/alternative; boundary="_000_D4331274E9C34382B7E918CE6F45C525ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 16:55:40 -0000 --_000_D4331274E9C34382B7E918CE6F45C525ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBTYW50b3NoIQ0KDQoNCk9uIEp1bCA2LCAyMDE3LCBhdCAxMjo0OSBQTSwgU2FudG9z aCBQIEsgPHNhbnRvc2gucGFsbGFnYXR0aUBnbWFpbC5jb208bWFpbHRvOnNhbnRvc2gucGFsbGFn YXR0aUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8gQ2FybG9zLA0KICAgICBUaGFua3MgZm9y IHlvdXIgcmV2aWV3IGNvbW1lbnRzLiBQbGVhc2Ugc2VlIGlubGluZSBbU1BLXS4NCg0KVGhhbmtz DQpTYW50b3NoIFAgSw0KDQpPbiBUdWUsIEp1biAyNywgMjAxNyBhdCA4OjI2IFBNLCBDYXJsb3Mg UGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFA Y2lzY28uY29tPj4gd3JvdGU6DQpKdXN0IG9uZSBjb21tZW50IG9uIHRoZXNlIHR3byBkb2N1bWVu dHMsIGluIHJlZ2FyZHMgdG8gdGhlIHN0YXRlIHZhcmlhYmxlczoNCg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAjc2VjdGlvbi00LjQuMQ0K DQo0LjQuMS4gIE5ldyBTdGF0ZSBWYXJpYWJsZXMNCg0KICAgQSBudW1iZXIgb2Ygc3RhdGUgdmFy aWFibGVzIGFyZSBhZGRlZCB0byB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uIGluDQogICBzdXBwb3J0 IG9mIE11bHRpcG9pbnQgQkZELg0KDQogICAgICBiZmQuU2Vzc2lvblR5cGUNCg0KICAgICAgICAg VGhlIHR5cGUgb2YgdGhpcyBzZXNzaW9uLiAgQWxsb3dhYmxlIHZhbHVlcyBhcmU6DQoNCkNNUDog SG93ZXZlciwgdGhpcyBzdGF0ZSAoYmZkLlNlc3Npb25UeXBlKSB2YXJpYWJsZSBpcyBhbHJlYWR5 IGRlZmluZWQgaW4gU0JGRCBSRkMgNzg4MDoNCg0KW1NQS10gT2sgd2UgY2FuIHJlbW92ZSBpdCBo ZXJlIGFuZCBnaXZlIHJlZmVyZW5jZSB0byBSRkMgNzg4MC4gVGhpcyBkcmFmdCBjYW4gdXNlIHRo aXMgc3RhdGUgdmFyaWFibGUgYW5kIG5lZWQgbm90IHNheSB0aGF0IG5ldyBzdGF0ZSB2YXJpYWJs ZS4NCg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg4MCNzZWN0aW9uLTYuMQ0K DQo2LjEuICBOZXcgU3RhdGUgVmFyaWFibGVzDQoNCiAgIEEgbmV3IHN0YXRlIHZhcmlhYmxlIGlz IGFkZGVkIHRvIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gaW4gc3VwcG9ydA0KICAgb2YgUy1CRkQu DQoNCiAgIG8gIGJmZC5TZXNzaW9uVHlwZTogVGhpcyBpcyBhIG5ldyBzdGF0ZSB2YXJpYWJsZSB0 aGF0IGRlc2NyaWJlcw0KICAgICAgdGhlIHR5cGUgb2YgYSBwYXJ0aWN1bGFyIHNlc3Npb24uDQoN Cg0KQ01QOiBTbywgZm9yIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQsIEkgc3VnZ2VzdCBhIHBv aW50ZXIgdG8gUkZDIDc4ODAgd2hlcmUgYmZkLlNlc3Npb25UeXBlIGlzIGRlZmluZWQgaW4gdGhl IGFkZGl0aW9uIG9mIG5ldyB2YWx1ZXMgdG8gdGhlIGV4aXN0aW5nIHZhcmlhYmxlLg0KDQpbU1BL XSBTdXJlLg0KDQpDTVA6IFNpbWlsYXJseToNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtYWN0aXZlLXRhaWwtMDQjc2VjdGlvbi0zLjMuMQ0K DQogICAgICBiZmQuU2Vzc2lvblR5cGUNCg0KICAgICAgICAgVGhlIHR5cGUgb2YgdGhpcyBzZXNz aW9uIGFzIGRlZmluZWQgaW4NCiAgICAgICAgIFtJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0uICBB IG5ldyB2YWx1ZSBpbnRyb2R1Y2VkIGlzOg0KDQpDTVA6IFRoZSBwb2ludGVyIGFib3ZlIHNob3Vs ZCBiZSB0byBSRkMgNzg4MCBhbHNvLCBhbmQ6DQoNCiAgICAgIGJmZC5TaWxlbnRUYWlsDQoNCkNN UDogQnV0IHRoaXMgaXMgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50DQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTEwI3Nl Y3Rpb24tNC40LjENCg0KICAgICAgYmZkLlNpbGVudFRhaWwNCg0KW1NQS10gSSB3aWxsIHRha2Ug Y2FyZSBvZiB0aGlzLg0KDQoNClRoYW5rcyENCg0K4oCUIENhcmxvcy4NCg0KDQpPbiBKdW4gMTks IDIwMTcsIGF0IDM6MzkgUE0sIEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpo YWFzQHBmcmMub3JnPj4gd3JvdGU6DQoNCldvcmtpbmcgR3JvdXAsDQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LTEwDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUtdGFpbC0wNA0K DQoNClRoZSBCRkQgTXVsdGlwb2ludCBkb2N1bWVudHMgaGF2ZSBiZWVuIHN0YWJsZSBmb3Igc29t ZSB0aW1lLiAgUHJpb3INCmRpc2N1c3Npb24gYXQgbWVldGluZ3MgaGFzIHN1Z2dlc3RlZCB3ZSBo YXZlIGFuIGltcGxlbWVudGF0aW9uIGZvciB0aGUgbWFpbg0KcHJvdG9jb2wgY29tcG9uZW50LiAg QWxzbyBwZXIgcHJpb3IgZGlzY3Vzc2lvbnMsIHdlIHNwbGl0IHRoZSBhY3RpdmUtdGFpbA0KY29t cG9uZW50IG9mIHRoZSBvcmlnaW5hbCBtdWx0aXBvaW50IGRvY3VtZW50IHRvIHBlcm1pdCBpbXBs ZW1lbnRvcnMgdG8gbm90DQpoYXZlIHRvIHdvcnJ5IGFib3V0IGltcGxlbWVudGluZyBhY3RpdmUt dGFpbCBwcm9jZWR1cmVzIGlmIHRoZXkgd2VyZW4ndA0KaW50ZXJlc3RlZCBpbiB0aGF0IGZlYXR1 cmUuDQoNCldlIGFyZSBzdGFydGluZyBhbiBleHRlbmRlZCBsYXN0IGNhbGwgb24gdGhlc2UgZG9j dW1lbnRzLiAgVGhlIFdHTEMgd2lsbA0KY29uY2x1ZGUgb24gSnVseSAxNC4gIFRoaXMgcHJvdmlk ZXMgYW1wbGUgdGltZSBmb3IgbGlzdCBkaXNjdXNzaW9uLiAgSWYNCm5lY2Vzc2FyeSwgdGhlIElF VEYtOTkgbWVldGluZyBtYXkgcHJvdmlkZSBmb3Igb3Bwb3J0dW5pdGllcyB0byBjbG9zZSBhbnkN CmNvbnRlbnRpb3VzIHRlY2huaWNhbCBwb2ludHMuICAoQkZEIGlzIG5vdCBjdXJyZW50bHkgc2No ZWR1bGVkIHRvIG1lZXQuKQ0KDQpPbmUgaXRlbSBJIHdvdWxkIGxpa2UgdG8ga2ljayBvZmYgaXMg dGhlIGRvY3VtZW50IHN0YXR1cyBvZiB0aGUgYWN0aXZlLXRhaWwNCm1lY2hhbmlzbS4gIEF0IHRo aXMgdGltZSwgbm8gb25lIGhhcyBpbXBsZW1lbnRlZCBpdCB0aGF0IEkgYW0gYXdhcmUgb2YuDQpE aXNjdXNzaW9uIHdpdGggb3VyIEFEIHN1Z2dlc3RzIHRoYXQgcHVibGlzaGluZyB0aGUgZG9jdW1l bnQgd2l0aA0KRXhwZXJpbWVudGFsIHN0YXR1cyBtYXkgYmUgcmVhc29uYWJsZSB0byBwcmVzZXJ2 ZSB0aGUgd29yayB0aGF0IHdlbnQgaW50bw0KdGhlIHByb3Bvc2FsLg0KDQotLSBKZWZmDQoNCg0K DQoNCuKAlA0KQ2FybG9zIFBpZ25hdGFybywgY2FybG9zQGNpc2NvLmNvbTxtYWlsdG86Y2FybG9z QGNpc2NvLmNvbT4NCg0K4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3b3JkcyB0aGF0IEkgZG8gbm90 IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5kIG1vcmUgcGhvdG9zeW50aGVz aXMuIg0KDQo= --_000_D4331274E9C34382B7E918CE6F45C525ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <22615040F6DEA34DB7DA69C91F5792CA@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzLCBTYW50b3NoIQ0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj5PbiBKdWwgNiwgMjAxNywgYXQgMTI6NDkgUE0sIFNhbnRvc2ggUCBLICZsdDs8YSBocmVm PSJtYWlsdG86c2FudG9zaC5wYWxsYWdhdHRpQGdtYWlsLmNvbSIgY2xhc3M9IiI+c2FudG9zaC5w YWxsYWdhdHRpQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBj bGFzcz0iIj5IZWxsbyBDYXJsb3MsDQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 VGhhbmtzIGZvciB5b3VyIHJldmlldyBjb21tZW50cy4gUGxlYXNlIHNlZSBpbmxpbmUgW1NQS10u PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UaGFua3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2FudG9zaCBQIEsmbmJzcDs8YnIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFR1ZSwgSnVuIDI3LCAyMDE3IGF0IDg6MjYgUE0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPiZsdDs8YSBocmVmPSJt YWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25h dGFAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiIGNsYXNzPSIiPkp1c3Qgb25lIGNvbW1lbnQgb24gdGhlc2UgdHdvIGRv Y3VtZW50cywgaW4gcmVnYXJkcyB0byB0aGUgc3RhdGUgdmFyaWFibGVzOg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAjc2VjdGlvbi00 LjQuMSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC88d2JyIGNsYXNzPSIiPmRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAjPHdiciBjbGFzcz0i Ij5zZWN0aW9uLTQuNC4xPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NC40LjEuJm5ic3A7IE5ldyBTdGF0ZSBWYXJpYWJsZXM8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtBIG51 bWJlciBvZiBzdGF0ZSB2YXJpYWJsZXMgYXJlIGFkZGVkIHRvIHRoZSBiYXNlIHNwZWNpZmljYXRp b24gaW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3N1cHBvcnQgb2YgTXVsdGlw b2ludCBCRkQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBiZmQuU2Vzc2lvblR5cGU8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgdHlwZSBvZiB0aGlzIHNlc3Npb24uJm5ic3A7 IEFsbG93YWJsZSB2YWx1ZXMgYXJlOjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IEhvd2V2ZXIsIHRoaXMgc3RhdGUg KGJmZC5TZXNzaW9uVHlwZSkgdmFyaWFibGUgaXMgYWxyZWFkeSBkZWZpbmVkIGluIFNCRkQgUkZD IDc4ODA6PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPltTUEtdIE9rIHdlIGNhbiByZW1vdmUgaXQg aGVyZSBhbmQgZ2l2ZSByZWZlcmVuY2UgdG8gUkZDIDc4ODAuIFRoaXMgZHJhZnQgY2FuIHVzZSB0 aGlzIHN0YXRlIHZhcmlhYmxlIGFuZCBuZWVkIG5vdCBzYXkgdGhhdCBuZXcgc3RhdGUgdmFyaWFi bGUuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUg Y2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6 MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 YnJlYWstd29yZCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj Nzg4MCNzZWN0aW9uLTYuMSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC88d2JyIGNsYXNzPSIiPnJmYzc4ODAjc2VjdGlvbi02LjE8L2E+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj42LjEu Jm5ic3A7IE5ldyBTdGF0ZSBWYXJpYWJsZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtBIG5ldyBzdGF0ZSB2YXJpYWJsZSBpcyBhZGRlZCB0 byB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uIGluIHN1cHBvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Jm5ic3A7ICZuYnNwO29mIFMtQkZELjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7YmZkLlNlc3Npb25U eXBlOiBUaGlzIGlzIGEgbmV3IHN0YXRlIHZhcmlhYmxlIHRoYXQgZGVzY3JpYmVzPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB0eXBlIG9mIGEgcGFydGljdWxh ciBzZXNzaW9uLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Q01QOiBTbywgZm9yIGRyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQsIEkgc3VnZ2VzdCBh IHBvaW50ZXIgdG8gUkZDIDc4ODAgd2hlcmUmbmJzcDtiZmQuU2Vzc2lvblR5cGUmbmJzcDtpcyBk ZWZpbmVkIGluIHRoZSBhZGRpdGlvbiBvZiBuZXcgdmFsdWVzIHRvIHRoZSBleGlzdGluZyB2YXJp YWJsZS48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+W1NQS10gU3VyZS4mbmJzcDs8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBTaW1pbGFybHk6PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC1hY3RpdmUt dGFpbC0wNCNzZWN0aW9uLTMuMy4xIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sLzx3YnIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2lu dC08d2JyIGNsYXNzPSIiPmFjdGl2ZS10YWlsLTA0I3NlY3Rpb24tMy4zLjE8L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYmZkLlNlc3Npb25UeXBlPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHR5cGUgb2YgdGhpcyBzZXNzaW9uIGFzIGRlZmlu ZWQgaW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1tJLUQuaWV0Zi1iZmQtbXVsdGlwb2ludF0uJm5ic3A7IEEgbmV3IHZhbHVlIGludHJvZHVj ZWQgaXM6PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkNNUDogVGhlIHBvaW50ZXIgYWJvdmUgc2hvdWxkIGJlIHRvIFJGQyA3 ODgwIGFsc28sIGFuZDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGJmZC5TaWxlbnRUYWlsPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6 IEJ1dCB0aGlzIGlzIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWJmZC1tdWx0aXBvaW50LTEwI3NlY3Rpb24tNC40LjEiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvPHdiciBjbGFzcz0iIj5kcmFmdC1pZXRmLWJm ZC1tdWx0aXBvaW50LTEwIzx3YnIgY2xhc3M9IiI+c2VjdGlvbi00LjQuMTwvYT48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7IGJmZC5TaWxlbnRUYWlsPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+W1NQS10gSSB3aWxsIHRha2UgY2FyZSBvZiB0aGlzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7PC9kaXY+DQo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRoYW5rcyE8L2Rpdj4NCjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIj ODg4ODg4IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8L2ZvbnQ+PC9zcGFuPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVuIDE5LCAyMDE3 LCBhdCAzOjM5IFBNLCBKZWZmcmV5IEhhYXMgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGFhc0BwZnJj Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpoYWFzQHBmcmMub3JnPC9hPiZndDsgd3Jv dGU6PC9kaXY+DQo8YnIgY2xhc3M9Im1fLTY4OTczNTc0MDU2MjI5OTU1NzVBcHBsZS1pbnRlcmNo YW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPldvcmtpbmcgR3Jv dXAsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLW11bHRpcG9pbnQtMTAiIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvPHdiciBjbGFzcz0iIj5kcmFm dC1pZXRmLWJmZC1tdWx0aXBvaW50LTEwPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC1tdWx0aXBvaW50LWFjdGl2ZS10 YWlsLTA0IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sLzx3YnIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1iZmQtbXVsdGlwb2ludC08d2JyIGNsYXNzPSIi PmFjdGl2ZS10YWlsLTA0PC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NClRoZSBCRkQgTXVsdGlwb2ludCBkb2N1bWVudHMgaGF2ZSBiZWVuIHN0YWJsZSBmb3Ig c29tZSB0aW1lLiZuYnNwOyBQcmlvcjxiciBjbGFzcz0iIj4NCmRpc2N1c3Npb24gYXQgbWVldGlu Z3MgaGFzIHN1Z2dlc3RlZCB3ZSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIGZvciB0aGUgbWFpbiA8 YnIgY2xhc3M9IiI+DQpwcm90b2NvbCBjb21wb25lbnQuJm5ic3A7IEFsc28gcGVyIHByaW9yIGRp c2N1c3Npb25zLCB3ZSBzcGxpdCB0aGUgYWN0aXZlLXRhaWw8YnIgY2xhc3M9IiI+DQpjb21wb25l bnQgb2YgdGhlIG9yaWdpbmFsIG11bHRpcG9pbnQgZG9jdW1lbnQgdG8gcGVybWl0IGltcGxlbWVu dG9ycyB0byBub3Q8YnIgY2xhc3M9IiI+DQpoYXZlIHRvIHdvcnJ5IGFib3V0IGltcGxlbWVudGlu ZyBhY3RpdmUtdGFpbCBwcm9jZWR1cmVzIGlmIHRoZXkgd2VyZW4ndDxiciBjbGFzcz0iIj4NCmlu dGVyZXN0ZWQgaW4gdGhhdCBmZWF0dXJlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldl IGFyZSBzdGFydGluZyBhbiBleHRlbmRlZCBsYXN0IGNhbGwgb24gdGhlc2UgZG9jdW1lbnRzLiZu YnNwOyBUaGUgV0dMQyB3aWxsPGJyIGNsYXNzPSIiPg0KY29uY2x1ZGUgb24gSnVseSAxNC4mbmJz cDsgVGhpcyBwcm92aWRlcyBhbXBsZSB0aW1lIGZvciBsaXN0IGRpc2N1c3Npb24uJm5ic3A7IElm PGJyIGNsYXNzPSIiPg0KbmVjZXNzYXJ5LCB0aGUgSUVURi05OSBtZWV0aW5nIG1heSBwcm92aWRl IGZvciBvcHBvcnR1bml0aWVzIHRvIGNsb3NlIGFueTxiciBjbGFzcz0iIj4NCmNvbnRlbnRpb3Vz IHRlY2huaWNhbCBwb2ludHMuICZuYnNwOyhCRkQgaXMgbm90IGN1cnJlbnRseSBzY2hlZHVsZWQg dG8gbWVldC4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT25lIGl0ZW0gSSB3b3VsZCBs aWtlIHRvIGtpY2sgb2ZmIGlzIHRoZSBkb2N1bWVudCBzdGF0dXMgb2YgdGhlIGFjdGl2ZS10YWls PGJyIGNsYXNzPSIiPg0KbWVjaGFuaXNtLiZuYnNwOyBBdCB0aGlzIHRpbWUsIG5vIG9uZSBoYXMg aW1wbGVtZW50ZWQgaXQgdGhhdCBJIGFtIGF3YXJlIG9mLjxiciBjbGFzcz0iIj4NCkRpc2N1c3Np b24gd2l0aCBvdXIgQUQgc3VnZ2VzdHMgdGhhdCBwdWJsaXNoaW5nIHRoZSBkb2N1bWVudCB3aXRo PGJyIGNsYXNzPSIiPg0KRXhwZXJpbWVudGFsIHN0YXR1cyBtYXkgYmUgcmVhc29uYWJsZSB0byBw cmVzZXJ2ZSB0aGUgd29yayB0aGF0IHdlbnQgaW50bzxiciBjbGFzcz0iIj4NCnRoZSBwcm9wb3Nh bC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSBKZWZmPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0K4oCUPC9kaXY+DQo8ZGl2IHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCkNhcmxvcyBQaWduYXRhcm8sJm5ic3A7PGEgaHJlZj0ibWFpbHRv OmNhcmxvc0BjaXNjby5jb20iIGNsYXNzPSIiPmNhcmxvc0BjaXNjby5jb208L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9IiI+4oCcU29tZXRpbWVzIEkgdXNlIGJpZyB3 b3JkcyB0aGF0IEkgZG8gbm90IGZ1bGx5IHVuZGVyc3RhbmQsIHRvIG1ha2UgbXlzZWxmIHNvdW5k IG1vcmUmbmJzcDtwaG90b3N5bnRoZXNpcy4mcXVvdDs8L2k+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D4331274E9C34382B7E918CE6F45C525ciscocom_-- From nobody Thu Jul 6 10:27:18 2017 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 0009E131851 for ; Thu, 6 Jul 2017 10:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 QPJ10fGz4T8v for ; Thu, 6 Jul 2017 10:27:15 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99A1131557 for ; Thu, 6 Jul 2017 10:27:14 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id k192so10430408ith.1 for ; Thu, 06 Jul 2017 10:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jpIgYDgU2npC7RhTU08RNiTSZbv7q22XJn+h3kL4PkY=; b=SmSmw1t2mjHrDkhT9unQCpyjbj6MX/aFiwIotz8+4SaRHAyzOdQv96OAW2IYDrTHOe YMmv2ICmsDs3fiJEGQFexOykg40rg6K8cunmreZ9oMytR3gZdQu4OrU1o0n0HZu+Y5lV e+uGWjQ/FfT0siAIipMMry66VpZZqMp69ngXUfuMQ46Hyf/POf8DKAN471TvH4yBCZnC OuKfTEROeAL/hoKNhEazbXr0P4PgFCDPfoBIX66e12MtsmtsL3hM1+P8bqcIS2AIFFH8 /OIaSQcUGVESTJvWK+fA/3Ah1jfhokwt69RiO6xCJatZWlXyjojDZ2Brt0rCzCH5Sqw/ rf0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jpIgYDgU2npC7RhTU08RNiTSZbv7q22XJn+h3kL4PkY=; b=OUVdzFfkOD7Iw5rpHN7Xbxudl/EuTOovRt2O3zJ/YKBPed+Ri6BYUmJz+pR8rttyx/ J4qrRhPk6+Q/dJtBoP+iC5F+Qt4f4+6JABKvm+TmYgv2pTlexOUUtEv6GPVbTrKKEgk3 o9yOP1K+Yv5+FYFZFSQi8+vfms01KjIC76WygGsypkw77+R/gini3VOCg1dR4URgqNeI md2L42De5Kyom34QylU/cB2WwAc2Hz3oKtVG2D45ovCFKZMoCGa/ZK6ifsg9L236Q+dZ ni8QkeJuqXjg/yLkGtuqvVlIVEYP3K7WKhhGHLm5PjIcgkfxNNkUNA7rna5NsBLYapWJ G7mA== X-Gm-Message-State: AIVw1113OLveMyCTvFTIk3C4aKmKEK5LGYh+d+ozGcPNOgdv7+WHNnP8 i6ppL39JNXwBP4rNkKio4HD4xzwF6A== X-Received: by 10.36.61.85 with SMTP id n82mr598791itn.2.1499362034289; Thu, 06 Jul 2017 10:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.70 with HTTP; Thu, 6 Jul 2017 10:27:13 -0700 (PDT) In-Reply-To: References: <20170619193929.GE22146@pfrc.org> From: Santosh P K Date: Thu, 6 Jul 2017 22:57:13 +0530 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Greg Mirsky Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a113f863e7199d30553a96d81" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 17:27:18 -0000 --001a113f863e7199d30553a96d81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Greg, Thanks for your comments. Please see my reply inline tagged[ SPK]. Thanks Santosh P K On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky wrote: > Dear Authors, WG chairs, et. al, > please kindly consider my comments to the latest version of the draft as > part of WGLC: > > - Very general > - I suggest to add note clarifying that all terms that include > "connectivity" in the document are being used as alternative to > "continuity", i.e. existence of a path between the sender and the r= eceiver, > and should not be interpreted as "connectivity verification in term= s of > transport network". > - Introduction > - I find that characterization of BFD and unidirectional continuity > verification as "natural fit" bit of stretching. Perhaps "capable o= f > supporting this use case" is acceptable; > > [SPK] Will take care. > > - Goals > - the last statement of non-goal seems little unclear. In fact, if > there's only one tail, the BFD for multipoint network does verify > connectivity, though unidirectional, between the head and the tail.= I think > that the intention is to stress that p2p bi-directional connectivit= y > verification is not supported by this document. > > [SPK] It only says that this document does not support verification of unicast path between head and tail. I can clarify a bit on this. Please let me know if you have a suggestion for this. > > - Section 4.7 > - the last paragraph notes that the discriminator value MUST NOT be > changed. Since Your Discriminator MUST be set to 0 this refers to M= y > Discriminator only. I think that explicit reference will make the s= tatement > more clear. Thus suggest s/the discriminator values/the My Discrimi= nator > value/ > > [SPK] Will take care of this. > > - Section 4.8 > - I believe that requiring use of IP/UDP encapsulation for BFD in > multipoint networks over MPSL LSP is too restrictive. I suggest cha= nging > text as following: > > OLD: > > For multipoint LSP, MultipointTail MUST use destination UDP port "3784" a= nd IP "127.0.0.0/8" range. > > > NEW > > If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multip= ointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" a= nd IP "127.0.0.0/8" range. > > Use of other types of encapsulation for multipoint LSP is outside the sco= pe of this document. > > [SPK] Thanks. I think this make sense for non MPLS tunnels. > > - Section 4.10 > - I cannot say what bfd.DetectMult packet is. It has not been defin= ed in RFC 5880, nor in this document. What is the scenario described in the= second paragraph? Is it when MultipointHead reduces Desired Min TX Interv= al thus making defect detection more aggressive? > - > > [SPK] This section talks about how to handle Poll sequence. In case of Multipoint head we cant afford to send POLL and expect all tail to reply with F bit set. Keeping track and building state at headend will be costly. > > - Section 7 > - I think it should be plural in the first paragraph, i.e. s/Multip= ointTail session/MultipointTail sessions/ > - I think that we can add another consideration to improve, strengt= hen security of BFD for multipoint network by suggesting that MultipointTai= l sessions created only for known combination of MultipointHead and My Disc= riminator. Such information MAY be learned from out-of-band and mechanisms = are outside the scope of this document. > > > Regards, > > Greg > > > > On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: > >> Working Group, >> >> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 >> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 >> >> >> The BFD Multipoint documents have been stable for some time. Prior >> discussion at meetings has suggested we have an implementation for the >> main >> protocol component. Also per prior discussions, we split the active-tai= l >> component of the original multipoint document to permit implementors to >> not >> have to worry about implementing active-tail procedures if they weren't >> interested in that feature. >> >> We are starting an extended last call on these documents. The WGLC will >> conclude on July 14. This provides ample time for list discussion. If >> necessary, the IETF-99 meeting may provide for opportunities to close an= y >> contentious technical points. (BFD is not currently scheduled to meet.) >> >> One item I would like to kick off is the document status of the >> active-tail >> mechanism. At this time, no one has implemented it that I am aware of. >> Discussion with our AD suggests that publishing the document with >> Experimental status may be reasonable to preserve the work that went int= o >> the proposal. >> >> -- Jeff >> >> > --001a113f863e7199d30553a96d81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Greg,
=C2=A0 =C2=A0Thanks for your comments. Ple= ase see my reply inline tagged[ SPK].

Thanks
=
Santosh P K=C2=A0

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <= gregimirsky@gmai= l.com> wrote:
Dear Authors, WG chairs, et. al,
please kindly consider my comments= to the latest version of the draft as part of WGLC:
  • Very= general
    • I suggest to add note clarifying that all terms that i= nclude "connectivity" in the document are being used as alternati= ve to "continuity", i.e. existence of a path between the sender a= nd the receiver, and should not be interpreted as "connectivity verifi= cation in terms of transport network".
  • Introduction=C2=A0=
    • I find that characterization of BFD and unidirectional continu= ity verification as "natural fit" bit of stretching. Perhaps &quo= t;capable of supporting this use case" is acceptable;
[SPK] Will take care.=C2=A0
  • Goals
    • the last s= tatement of non-goal seems little unclear. In fact, if there's only one= tail, the BFD for multipoint network does verify connectivity, though unid= irectional, between the head and the tail. I think that the intention is to= stress that p2p bi-directional connectivity verification is not supported = by this document.
[SPK] It only= says that this document does not support verification of unicast path betw= een head and tail. I can clarify a bit on this. Please let me know if you h= ave a suggestion for this.=C2=A0
=C2=A0
  • Section 4.7
    • the last p= aragraph notes that the discriminator value MUST NOT be changed. Since Your= Discriminator MUST be set to 0 this refers to My Discriminator only. I thi= nk that explicit reference will make the statement more clear. Thus suggest= s/the discriminator values/the My Discriminator value/
[SPK] Will take care of this.=C2=A0
  • Section 4.8
      • I believe that requiring use of IP/UDP encapsulation for BFD in multipoint= networks over MPSL LSP is too restrictive. I suggest changing text as foll= owing:
OLD:
For multipoint LSP, MultipointTail MUST use destinatio=
n UDP port "3784" and IP "127.0.0.0/8" range.

NEW
If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multip=
ointTail MUST use IP/UDP encapsulation of BFD destination UDP port "37=
84" and IP "127.=
0.0.0/8" range. 
Use of other types of encapsulation for multipoint LSP is outsid=
e the scope of this document.

[SPK] Thanks. I think this make sense for non MPLS tunnels= .=C2=A0
  • Section 4.10=

    • I cannot say what bfd.Det=
ectMult packet is. It has not been defined in RFC 5880, nor in this documen=
t. What is the scenario described in the second paragraph? Is it when Multi=
pointHead reduces Desired Min TX  Interval thus making defect detection mor=
e aggressive?
[SPK] This sec= tion talks about how to handle Poll sequence. In case of Multipoint head we= cant afford to send POLL and expect all tail to reply with F bit set. Keep= ing track and building state at headend will be costly. =C2=A0
  • Section 7
      • =

    • I think it should be plural in the first paragra=
ph, i.e. s/MultipointTail session/MultipointTail sessions/
    • I think that we can add another consideration =
to improve, strengthen security of BFD for multipoint network by suggesting=
 that MultipointTail sessions created only for known combination of Multipo=
intHead and My Discriminator. Such information MAY be learned from out-of-b=
and and mechanisms are outside the scope of this document.
<=
span style=3D"font-size:13.3333px">
Regards,
Greg


On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc= .org> wrote:
Working Group,=

https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.=C2=A0 (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff



--001a113f863e7199d30553a96d81-- From nobody Thu Jul 6 11:00:47 2017 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 734FA131882 for ; Thu, 6 Jul 2017 11:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 rYrOyfbja7Bx for ; Thu, 6 Jul 2017 11:00:43 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 E57EE131880 for ; Thu, 6 Jul 2017 11:00:42 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id r30so8925892qtc.0 for ; Thu, 06 Jul 2017 11:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4t8mj1gOzMAM0ULGyzTvp5fe2BNlsh0V3JAXQ3bUiQ4=; b=U8pC9Orf/QdR9OA3k9rzi4PsE4hdy+zAszH/tIMD899hPjz/bpwAH4b8101AfkU1DW SJSngEibuX3GZumNS1NnkyG+fCfL8UVHScPFOVMt1U1RWSky8YzOBbYcoOhpbu6sRXwz 8s+qUcoAqVrNxDqg0qCbZRWSMZHp2/7UIdOu+7763ZFmhJuDeC3uRVz24N9wPr5Dv691 vbpaOjHgG6JxqYElkCVZ3q0jADyexwd0tIe65qveXYX75vA0Vt81TAgCu4ByDF1u7Ul5 eaac3H1nzfWEr1t5FJIAeLaqy6jY+6oEHSnK1cqjOAGOBDc9PbLo/7q/1DKMpuCquvW/ P0bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4t8mj1gOzMAM0ULGyzTvp5fe2BNlsh0V3JAXQ3bUiQ4=; b=lqG7uaPbFKmOv5fovsrd0qYCkoT7UCYQUCoRrthISXFxxbXMqzUPY+RArVL+nRYtaz 0QFyn63j0OdL+UjYI4JsNMj/1KI0v41cYxE+7pfYie2QUJliLam8FUK/TR1Is/iOED4p 1cPf/M2C91F8dMNZat5meH6eh6ekM/eX7ZWShE5Pu8kDGt5BPBT1L9Pr4/3BGpAw2Mdu SLlnVMy6EMuBet/V6BEMa8A4GU2PVjBU6cBSH0onibVY8ZAMQYnswuA7C8CWmw4K7XPB N7wrr0E3NYYmeJjIZFjfniMVMOHskFW/4LxvONMW6940t7FLAMPHT7DSkyr2kbLN+7Fe rRQA== X-Gm-Message-State: AKS2vOwlpoxlY7Qu+lEgLob9YOfCQjWcdpCOK55eXe+chfyf3Yhq23EE beJLIimPqXzJ3Al12HInBPFdYtoPQw== X-Received: by 10.200.40.207 with SMTP id j15mr66920936qtj.186.1499364041867; Thu, 06 Jul 2017 11:00:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Thu, 6 Jul 2017 11:00:41 -0700 (PDT) In-Reply-To: References: <20170619193929.GE22146@pfrc.org> From: Greg Mirsky Date: Thu, 6 Jul 2017 11:00:41 -0700 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Santosh P K Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a114060a01ac46a0553a9e59f" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 18:00:45 -0000 --001a114060a01ac46a0553a9e59f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Santosh, many thanks for your thoughtful consideration of my comments. Please find my answers and couple more notes in-line and tagged GIM>>. Regards, Greg On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K wrote: > Hello Greg, > Thanks for your comments. Please see my reply inline tagged[ SPK]. > > Thanks > Santosh P K > > On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky wrote= : > >> Dear Authors, WG chairs, et. al, >> please kindly consider my comments to the latest version of the draft as >> part of WGLC: >> >> - Very general >> - I suggest to add note clarifying that all terms that include >> "connectivity" in the document are being used as alternative to >> "continuity", i.e. existence of a path between the sender and the = receiver, >> and should not be interpreted as "connectivity verification in ter= ms of >> transport network". >> - Introduction >> - I find that characterization of BFD and unidirectional >> continuity verification as "natural fit" bit of stretching. Perhap= s >> "capable of supporting this use case" is acceptable; >> >> [SPK] Will take care. > GIM>> Thanks > >> - Goals >> - the last statement of non-goal seems little unclear. In fact, if >> there's only one tail, the BFD for multipoint network does verify >> connectivity, though unidirectional, between the head and the tail= . I think >> that the intention is to stress that p2p bi-directional connectivi= ty >> verification is not supported by this document. >> >> [SPK] It only says that this document does not support verification of > unicast path between head and tail. I can clarify a bit on this. Please l= et > me know if you have a suggestion for this. > GIM>> I'd suggest to use unicast in place of point-to-point. Using my earlier example, in case when there's only one tail multipoint becomes point-to-point. > > >> >> - Section 4.7 >> - the last paragraph notes that the discriminator value MUST NOT >> be changed. Since Your Discriminator MUST be set to 0 this refers = to My >> Discriminator only. I think that explicit reference will make the = statement >> more clear. Thus suggest s/the discriminator values/the My Discrim= inator >> value/ >> >> [SPK] Will take care of this. > GIM>> Thanks. > >> - Section 4.8 >> - I believe that requiring use of IP/UDP encapsulation for BFD in >> multipoint networks over MPSL LSP is too restrictive. I suggest ch= anging >> text as following: >> >> OLD: >> >> For multipoint LSP, MultipointTail MUST use destination UDP port "3784" = and IP "127.0.0.0/8" range. >> >> >> NEW >> >> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multi= pointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" = and IP "127.0.0.0/8" range. >> >> Use of other types of encapsulation for multipoint LSP is outside the sc= ope of this document. >> >> > [SPK] Thanks. I think this make sense for non MPLS tunnels. > GIM>> Thanks. As I've looked at the text, I've realized that it misses IPv6 case. Please consider the following as my new proposed change (not sure but I think that quote marks are not required): NEW If IP/UDP encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range for IPv6. Use of other types of encapsulation for multipoint LSP is outside the scope of this document. >> - Section 4.10 >> - I cannot say what bfd.DetectMult packet is. It has not been defi= ned in RFC 5880, nor in this document. What is the scenario described in th= e second paragraph? Is it when MultipointHead reduces Desired Min TX Inter= val thus making defect detection more aggressive? >> - >> >> [SPK] This section talks about how to handle Poll sequence. In case of > Multipoint head we cant afford to send POLL and expect all tail to reply > with F bit set. Keeping track and building state at headend will be costl= y. > > GIM>> Perhaps I wasn't clear in my question. It was to the opening of this sentence: The MultipointHead MUST send bfd.DetectMult packets with P bit set at the old transmit interval before using the higher value in order to avoid false detection timeouts at the tails. I couldn't find reference to "bfd.DetectMult packet" in any document related to BFD. >> - Section 7 >> - I think it should be plural in the first paragraph, i.e. s/Multi= pointTail session/MultipointTail sessions/ >> - I think that we can add another consideration to improve, streng= then security of BFD for multipoint network by suggesting that MultipointTa= il sessions created only for known combination of MultipointHead and My Dis= criminator. Such information MAY be learned from out-of-band and mechanisms= are outside the scope of this document. >> >> >> Regards, >> >> Greg >> >> >> >> On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: >> >>> Working Group, >>> >>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 >>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 >>> >>> >>> The BFD Multipoint documents have been stable for some time. Prior >>> discussion at meetings has suggested we have an implementation for the >>> main >>> protocol component. Also per prior discussions, we split the active-ta= il >>> component of the original multipoint document to permit implementors to >>> not >>> have to worry about implementing active-tail procedures if they weren't >>> interested in that feature. >>> >>> We are starting an extended last call on these documents. The WGLC wil= l >>> conclude on July 14. This provides ample time for list discussion. If >>> necessary, the IETF-99 meeting may provide for opportunities to close a= ny >>> contentious technical points. (BFD is not currently scheduled to meet.= ) >>> >>> One item I would like to kick off is the document status of the >>> active-tail >>> mechanism. At this time, no one has implemented it that I am aware of. >>> Discussion with our AD suggests that publishing the document with >>> Experimental status may be reasonable to preserve the work that went in= to >>> the proposal. >>> >>> -- Jeff >>> >>> >> > --001a114060a01ac46a0553a9e59f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Santosh,
many thanks for your thoughtful considerat= ion of my comments. Please find my answers and couple more notes in-line an= d tagged GIM>>.

Regards,
Greg

On Thu, Jul 6, 2= 017 at 10:27 AM, Santosh P K <santosh.pallagatti@gmail.com&= gt; wrote:
Hello Greg,
=C2=A0 =C2=A0Thanks for your comments. Please = see my reply inline tagged[ SPK].

Thanks
Santosh P K=C2=A0

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Authors, WG chairs, et. al,<= div>please kindly consider my comments to the latest version of the draft a= s part of WGLC:
  • Very general
    • I suggest to add= note clarifying that all terms that include "connectivity" in th= e document are being used as alternative to "continuity", i.e. ex= istence of a path between the sender and the receiver, and should not be in= terpreted as "connectivity verification in terms of transport network&= quot;.
  • Introduction=C2=A0
    • I find that characteriza= tion of BFD and unidirectional continuity verification as "natural fit= " bit of stretching. Perhaps "capable of supporting this use case= " is acceptable;
[S= PK] Will take care.=C2=A0
GI= M>> Thanks=C2=A0
  • Goals
    • the last statement of non= -goal seems little unclear. In fact, if there's only one tail, the BFD = for multipoint network does verify connectivity, though unidirectional, bet= ween the head and the tail. I think that the intention is to stress that p2= p bi-directional connectivity verification is not supported by this documen= t.
[SPK] It only says th= at this document does not support verification of unicast path between head= and tail. I can clarify a bit on this. Please let me know if you have a su= ggestion for this.=C2=A0
GIM= >> I'd suggest to use unicast in place of point-to-point. Using m= y earlier example, in case when there's only one tail multipoint become= s point-to-point.=C2=A0
=C2=A0
  • Section 4.7
    • t= he last paragraph notes that the discriminator value MUST NOT be changed. S= ince Your Discriminator MUST be set to 0 this refers to My Discriminator on= ly. I think that explicit reference will make the statement more clear. Thu= s suggest s/the discriminator values/the My Discriminator value/
    <= /ul>
[SPK] Will take care of this.=C2= =A0
GIM>> Thanks.=C2= =A0
=
  • Section 4.8
    • I believe that requiring use of IP/UDP= encapsulation for BFD in multipoint networks over MPSL LSP is too restrict= ive. I suggest changing text as following:
OLD:
For multipoint LSP, MultipointTail MUST use destination UDP port =
"3784" and IP "127.0.0.0/8" range.

NEW
If IP/UDP encapsulation used by MultipointHead=
 for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD de=
stination UDP port "3784" and IP "127.0.0.0/8" range. 
Use of ot=
her types of encapsulation for multipoint LSP is outside the scope of this =
document.

<= div>[SPK] Thanks. I think this make sense for non MPLS tunnels.=C2=A0=
GIM>> Thanks. As I've l= ooked at the text, I've realized that it misses IPv6 case. Please consi= der the following as my new proposed change (not sure but I think that quot= e marks are not required):
NEW
If IP/UDP = encapsulation used by MultipointHead for multipoint LSP, MultipointTail MUS= T use IP/UDP encapsulation of BFD destination UDP port 3784, and=C2=A0the 127/8 range for = IPv4, and=C2=A0= the 0:0:0:0:0:FFFF:7F00/104 range for IPv6.=C2=A0
Us= e of other types of encapsulation for multipoint LSP is outside the scope o= f this document.

  • Section 4.10
    • I=
 cannot say what bfd.DetectMult packet is. It has not been defined in RFC 5=
880, nor in this document. What is the scenario described in the second par=
agraph? Is it when MultipointHead reduces Desired Min TX  Interval thus mak=
ing defect detection more aggressive?
[SPK] This section talks about how to handle Poll sequence= . In case of Multipoint head we cant afford to send POLL and expect all tai= l to reply with F bit set. Keeping track and building state at headend will= be costly. =C2=A0
GIM>&g= t; Perhaps I wasn't clear in my question.=C2=A0 It was to the opening o= f this sentence:
   The Multipo=
intHead MUST send bfd.DetectMult packets with P bit set at
   the old transmit interval before using the higher value in order to
   avoid false detection timeouts at the tails. =20

I couldn't find reference to "bfd.DetectMult packet"=
 in any document related to BFD.

= 
  • Section 7
    • I think it should be plural in the first pa=
ragraph, i.e. s/MultipointTail session/MultipointTail sessions/
    • I think that we can add another considera=
tion to improve, strengthen security of BFD for multipoint network by sugge=
sting that MultipointTail sessions created only for known combination of Mu=
ltipointHead and My Discriminator. Such information MAY be learned from out=
-of-band and mechanisms are outside the scope of this document.

Regards,
Greg


On Mon, Jun= 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
=
Working Group,

https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.=C2=A0 (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff




--001a114060a01ac46a0553a9e59f-- From nobody Fri Jul 7 18:16:58 2017 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 B343A12EC28 for ; Fri, 7 Jul 2017 18:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 0lX8Km7awcyG for ; Fri, 7 Jul 2017 18:16:55 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86931274D2 for ; Fri, 7 Jul 2017 18:16:54 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id b40so39789983qtb.2 for ; Fri, 07 Jul 2017 18:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NQhj/8jU42QnYq+AKZS5s00gP6VEVQExfqg6umZKmvY=; b=t/chuC5OhZIvIwgtp7QSP2+cUlsTqrq+ZS42+DQo6t+hIXh3ls5EyGwyo92dcxhBU/ 7L9mEx5I4+r3Cc+McuN41kkcAG2rpVEtkL7SOSMtidj7saLcIVjdsy8KV25K+QW9N7hd rKul/bQoRt1IJq3WEZo3c3zO3nAvywnlmLYLfKAMievEWYAvkWbu1ns/GLbBdg6vaMfC 8dce3ziLhCmXggykQuCss2xXWJE0Faw6berL2SExzZwKGlPXfHmGZ+OSXEzTXYK5qwNk o/GGAF/QpK3hg58KGR1HexygOLlfEq+p7O27x2Naa2igb6fsE526dHj0X1y5R7FzOOzm Q1yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NQhj/8jU42QnYq+AKZS5s00gP6VEVQExfqg6umZKmvY=; b=NnUDYKT97vDyHh/b8mTBLfoXsu4hD0eQ8eYsLbrqqY61Hhso/mgRotg+xNgAempXxZ zfuFBmaWVknT9+ykE35g1vQEg8UubFUELa/Wmx5vV1sT2zhkTPh8jxkpjczKWPMSRhZv zORpZ7n+vzQCSxnUil7DyEl9sQY0QoN3YesF9mPFdPQkhG2guELCTRzjo6FMt3NMsXIf /tYnjqxSnP5oCTOx7o6FrDoPWYmxFUaJpYlGuBXKYbcco9G4bFVGeHXlJJRhGAm7vvBx NRPhTM5jin/CuA4/q3VvraFaZvFj1IITHJ3Fi15gcLn1ImRGeSMhCqT3z9+/71n9eNTm P9YQ== X-Gm-Message-State: AIVw110JuoRCVIuJNDDEFDMC+bQJCB7DA5RwZ/GW1Jk0Eh4q7s7ol34a CWiAQJPo8b01uqIW9KGIlEedQtYnFw== X-Received: by 10.237.54.73 with SMTP id e67mr4562996qtb.230.1499476613951; Fri, 07 Jul 2017 18:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Fri, 7 Jul 2017 18:16:53 -0700 (PDT) In-Reply-To: References: <20170619193929.GE22146@pfrc.org> From: Greg Mirsky Date: Fri, 7 Jul 2017 18:16:53 -0700 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Santosh P K Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a1149bda0ec77a50553c41a74" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 01:16:58 -0000 --001a1149bda0ec77a50553c41a74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Santosh, et. al, another note, question on IP/UDP encapsulation of BFD for multipoint networks. The document says nothing about values that may be used for Source UDP port number. Even though MultipointHead will not receive BFD packets from MultipointTail on the UDP port listed, should we recommend to use numbers from dynamic range, i.e. 49152 to 65535? I think that the multipoint document should state, as in RFC 5881: The source port MUST be in the range 49152 through 65535. What do you think? Regards, Greg On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky wrote: > Hi Santosh, > many thanks for your thoughtful consideration of my comments. Please find > my answers and couple more notes in-line and tagged GIM>>. > > Regards, > Greg > > On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K > wrote: > >> Hello Greg, >> Thanks for your comments. Please see my reply inline tagged[ SPK]. >> >> Thanks >> Santosh P K >> >> On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky >> wrote: >> >>> Dear Authors, WG chairs, et. al, >>> please kindly consider my comments to the latest version of the draft a= s >>> part of WGLC: >>> >>> - Very general >>> - I suggest to add note clarifying that all terms that include >>> "connectivity" in the document are being used as alternative to >>> "continuity", i.e. existence of a path between the sender and the= receiver, >>> and should not be interpreted as "connectivity verification in te= rms of >>> transport network". >>> - Introduction >>> - I find that characterization of BFD and unidirectional >>> continuity verification as "natural fit" bit of stretching. Perha= ps >>> "capable of supporting this use case" is acceptable; >>> >>> [SPK] Will take care. >> > GIM>> Thanks > >> >>> - Goals >>> - the last statement of non-goal seems little unclear. In fact, >>> if there's only one tail, the BFD for multipoint network does ver= ify >>> connectivity, though unidirectional, between the head and the tai= l. I think >>> that the intention is to stress that p2p bi-directional connectiv= ity >>> verification is not supported by this document. >>> >>> [SPK] It only says that this document does not support verification of >> unicast path between head and tail. I can clarify a bit on this. Please = let >> me know if you have a suggestion for this. >> > GIM>> I'd suggest to use unicast in place of point-to-point. Using my > earlier example, in case when there's only one tail multipoint becomes > point-to-point. > >> >> >>> >>> - Section 4.7 >>> - the last paragraph notes that the discriminator value MUST NOT >>> be changed. Since Your Discriminator MUST be set to 0 this refers= to My >>> Discriminator only. I think that explicit reference will make the= statement >>> more clear. Thus suggest s/the discriminator values/the My Discri= minator >>> value/ >>> >>> [SPK] Will take care of this. >> > GIM>> Thanks. > >> >>> - Section 4.8 >>> - I believe that requiring use of IP/UDP encapsulation for BFD in >>> multipoint networks over MPSL LSP is too restrictive. I suggest c= hanging >>> text as following: >>> >>> OLD: >>> >>> For multipoint LSP, MultipointTail MUST use destination UDP port "3784"= and IP "127.0.0.0/8" range. >>> >>> >>> NEW >>> >>> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Mult= ipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784"= and IP "127.0.0.0/8" range. >>> >>> Use of other types of encapsulation for multipoint LSP is outside the s= cope of this document. >>> >>> >> [SPK] Thanks. I think this make sense for non MPLS tunnels. >> > GIM>> Thanks. As I've looked at the text, I've realized that it misses > IPv6 case. Please consider the following as my new proposed change (not > sure but I think that quote marks are not required): > NEW > If IP/UDP encapsulation used by MultipointHead for multipoint LSP, > MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port > 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range > for IPv6. > Use of other types of encapsulation for multipoint LSP is outside the > scope of this document. > > >>> - Section 4.10 >>> - I cannot say what bfd.DetectMult packet is. It has not been def= ined in RFC 5880, nor in this document. What is the scenario described in t= he second paragraph? Is it when MultipointHead reduces Desired Min TX Inte= rval thus making defect detection more aggressive? >>> - >>> >>> [SPK] This section talks about how to handle Poll sequence. In case of >> Multipoint head we cant afford to send POLL and expect all tail to reply >> with F bit set. Keeping track and building state at headend will be cost= ly. >> >> > GIM>> Perhaps I wasn't clear in my question. It was to the opening of > this sentence: > > The MultipointHead MUST send bfd.DetectMult packets with P bit set at > the old transmit interval before using the higher value in order to > avoid false detection timeouts at the tails. > > I couldn't find reference to "bfd.DetectMult packet" in any document rela= ted to BFD. > > > >>> - Section 7 >>> - I think it should be plural in the first paragraph, i.e. s/Mult= ipointTail session/MultipointTail sessions/ >>> - I think that we can add another consideration to improve, stren= gthen security of BFD for multipoint network by suggesting that MultipointT= ail sessions created only for known combination of MultipointHead and My Di= scriminator. Such information MAY be learned from out-of-band and mechanism= s are outside the scope of this document. >>> >>> >>> Regards, >>> >>> Greg >>> >>> >>> >>> On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: >>> >>>> Working Group, >>>> >>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 >>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 >>>> >>>> >>>> The BFD Multipoint documents have been stable for some time. Prior >>>> discussion at meetings has suggested we have an implementation for the >>>> main >>>> protocol component. Also per prior discussions, we split the >>>> active-tail >>>> component of the original multipoint document to permit implementors t= o >>>> not >>>> have to worry about implementing active-tail procedures if they weren'= t >>>> interested in that feature. >>>> >>>> We are starting an extended last call on these documents. The WGLC wi= ll >>>> conclude on July 14. This provides ample time for list discussion. I= f >>>> necessary, the IETF-99 meeting may provide for opportunities to close >>>> any >>>> contentious technical points. (BFD is not currently scheduled to meet= .) >>>> >>>> One item I would like to kick off is the document status of the >>>> active-tail >>>> mechanism. At this time, no one has implemented it that I am aware of= . >>>> Discussion with our AD suggests that publishing the document with >>>> Experimental status may be reasonable to preserve the work that went >>>> into >>>> the proposal. >>>> >>>> -- Jeff >>>> >>>> >>> >> > --001a1149bda0ec77a50553c41a74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Santosh, et. al,
another note, question on IP/UDP e= ncapsulation of BFD for multipoint networks. The document says nothing abou= t values that may be used for Source UDP port number. Even though Multipoin= tHead will not receive BFD packets from MultipointTail on the UDP port list= ed, should we recommend to use numbers from dynamic range, i.e.=C2=A049152 to 65535? I think that the mult= ipoint document should state, as in RFC 5881:
The source port MUST=
 be in the range 49152 through 65535.
<= font face=3D"arial, helvetica, sans-serif">What do you think?
<= div>
Regards,
Greg

On Thu, Jul 6, 2017 at 11:00 AM, Gr= eg Mirsky <gregimirsky@gmail.com> wrote:
Hi Santosh,
many thanks for your th= oughtful consideration of my comments. Please find my answers and couple mo= re notes in-line and tagged GIM>>.

Regards,<= /div>
Greg

On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <santosh.pallagatti@gmail.com> wrote:
Hello Greg,
=C2=A0 = =C2=A0Thanks for your comments. Please see my reply inline tagged[ SPK].

Thanks
Santosh P K=C2=A0

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky = <gregimirsky@= gmail.com> wrote:
Dear Authors, WG chairs, et. al,
please kin= dly consider my comments to the latest version of the draft as part of WGLC= :
  • Very general
    • I suggest to add note clarifyi= ng that all terms that include "connectivity" in the document are= being used as alternative to "continuity", i.e. existence of a p= ath between the sender and the receiver, and should not be interpreted as &= quot;connectivity verification in terms of transport network".
    • Introduction=C2=A0
      • I find that characterization of BFD an= d unidirectional continuity verification as "natural fit" bit of = stretching. Perhaps "capable of supporting this use case" is acce= ptable;
[SPK] Will take = care.=C2=A0
GIM>&g= t; Thanks=C2=A0
  • Goals
  • the last statement of non-goal seems little unclear. In fact, if ther= e's only one tail, the BFD for multipoint network does verify connectiv= ity, though unidirectional, between the head and the tail. I think that the= intention is to stress that p2p bi-directional connectivity verification i= s not supported by this document.
[SPK] It only says that this document does not support verificati= on of unicast path between head and tail. I can clarify a bit on this. Plea= se let me know if you have a suggestion for this.=C2=A0
GIM>> I'd suggest to use unica= st in place of point-to-point. Using my earlier example, in case when there= 's only one tail multipoint becomes point-to-point.=C2=A0
=C2=A0
  • Section 4.7
    • = the last paragraph notes that the discriminator value MUST NOT be changed. = Since Your Discriminator MUST be set to 0 this refers to My Discriminator o= nly. I think that explicit reference will make the statement more clear. Th= us suggest s/the discriminator values/the My Discriminator value/
    =
[SPK] Will take care of this.=C2= =A0
GIM>> Thank= s.=C2=A0
  • Section 4.8
  • I believe that requiring use of IP/UDP encapsulation for BFD in multip= oint networks over MPSL LSP is too restrictive. I suggest changing text as = following:
OLD:
=
For multipoint LSP, MultipointTail MUST use destination UDP port "3784=
" and IP "127.0.=
0.0/8" range.

NEW=

If IP/UDP encapsulation used by MultipointHead f=
or multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD dest=
ination UDP port "3784" and IP "127.0.0.0/8" range. 
Use of other types of encapsulation for multipoint LSP is outside=
 the scope of this document.

[SPK] Thanks. I think this make sense for non MPLS t= unnels.=C2=A0
GIM>= > Thanks. As I've looked at the text, I've realized that it miss= es IPv6 case. Please consider the following as my new proposed change (not = sure but I think that quote marks are not required):
NEW
If IP/UDP encapsulation used by MultipointHead for multipoi= nt LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP= port 3784, and=C2=A0the 127/8 range for IPv4, and=C2=A0the 0:0:0:0:0:FFFF:7F00/104 range for IPv6= .=C2=A0<= /div>
Use of other types of encapsulatio= n for multipoint LSP is outside the scope of this document.

  • Section 4.=
10
    • I cannot say what bfd.D=
etectMult packet is. It has not been defined in RFC 5880, nor in this docum=
ent. What is the scenario described in the second paragraph? Is it when Mul=
tipointHead reduces Desired Min TX  Interval thus making defect detection m=
ore aggressive?
[SPK]= This section talks about how to handle Poll sequence. In case of Multipoin= t head we cant afford to send POLL and expect all tail to reply with F bit = set. Keeping track and building state at headend will be costly. =C2=A0
GIM>> Perhaps I wa= sn't clear in my question.=C2=A0 It was to the opening of this sentence= :
   The M=
ultipointHead MUST send bfd.DetectMult packets with P bit set at
   the old transmit interval before using the higher value in order to
   avoid false detection timeouts at the tails. =20

I couldn't find reference to "bfd.De=
tectMult packet" in any document related to BFD.

  • Section 7
    • I think it =
should be plural in the first paragraph, i.e. s/MultipointTail session/Mult=
ipointTail sessions/
    • I think t=
hat we can add another consideration to improve, strengthen security of BFD=
 for multipoint network by suggesting that MultipointTail sessions created =
only for known combination of MultipointHead and My Discriminator. Such inf=
ormation MAY be learned from out-of-band and mechanisms are outside the sco=
pe of this document.
=
Regards,
Greg

On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas = <j= haas@pfrc.org> wrote:
Working Group,

https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.=C2=A0 (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff





--001a1149bda0ec77a50553c41a74-- From nobody Sun Jul 9 10:17:19 2017 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 F1199131605 for ; Sun, 9 Jul 2017 10:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 IpBmZeNl6MNZ for ; Sun, 9 Jul 2017 10:17:14 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 583EA1315FE for ; Sun, 9 Jul 2017 10:17:14 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d78so58283344qkb.1 for ; Sun, 09 Jul 2017 10:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jaHP3Gt/ssDmvq3a9KXoaAuQh/UeAgdB5S8f+2wisj0=; b=YMEN+8iAZBsPGLuC7Y7p5vIk5CXDwQRYH8fWYrJVjhgk3yAx6zEO7wvkEvFg4tsDe/ H6lz7fFA1r73Sk9rchG8CzcXYfpDGrMi98xWmn/cb9cVUTadPZZLsDKlh9OsjbNq+vFH eG2P9p7eRIhS4rKk2zV1IyDC5frZo5JMIszn+1Zh1MivMi/VnoLh2qCLm/cY57Tsk7Gu L1us3idN0SSlyNYw91PkJzpYvrw6HaRsojxDY2Vef6Xkkkg3Ve7REX8vkNly79PfHRV+ 0l0I38JP58K36aiWY5TyELA+1myJ8xY0e14jZgzkr14A/yAs0hl5csvwls9uzJ7cqCFT cBag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jaHP3Gt/ssDmvq3a9KXoaAuQh/UeAgdB5S8f+2wisj0=; b=oMqm3cKDd75aLJvuP2CGwcoZUb1wlfPJda4fsCR5OaCsxXlZ5INXc2O6oUeOV88s4H u2E7OzMxx6iJRRYKuVzowccyZrcXoqvRVBd+wOaqhU02X6CZdCIBlJegy7FY2QMUfn31 t+rxHbvxNy2uNX2lqy63SITbpMPR2fjDfhQDs9zPUcQnFcmyFnpJ3zUMucgKqnsKaDKn VSNwPhyhOTcFQGogZgCbBjNQe1T4JF0ZJuJLTljHbMnkWCZRyXqjxEjI2y//nfsMSWxL k7DId+0etkgzJUPom4/t88zyxvxo1uatv8MyJKR3fJSJxeaiG9AOKzwMpFZ/yrDQyrGT R1eg== X-Gm-Message-State: AIVw111TLdvkOP591eG5V9F2eyvhAzWZz+HaY2/oDlFwayf06mIk+16H CQJeQjEbRDSdWouz6p7ZfVc99lHiiQ== X-Received: by 10.55.10.11 with SMTP id 11mr2529287qkk.251.1499620633330; Sun, 09 Jul 2017 10:17:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Sun, 9 Jul 2017 10:17:12 -0700 (PDT) In-Reply-To: References: <20170619193929.GE22146@pfrc.org> From: Greg Mirsky Date: Sun, 9 Jul 2017 10:17:12 -0700 Message-ID: Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) To: Santosh P K Cc: Jeffrey Haas , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a114c92be25c8f70553e5a3b9" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jul 2017 17:17:17 -0000 --001a114c92be25c8f70553e5a3b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Santosh, et. al, would like us to look closer into the statement in Goals section, the one which stresses non-goal of the BFD for multipoint networks protocol: > >> - Goals >> - the last statement of non-goal seems little unclear. In fact, if >> there's only one tail, the BFD for multipoint network does verify >> connectivity, though unidirectional, between the head and the tail= . I think >> that the intention is to stress that p2p bi-directional connectivi= ty >> verification is not supported by this document. >> >> [SPK] It only says that this document does not support verification of > unicast path between head and tail. I can clarify a bit on this. Please l= et > me know if you have a suggestion for this. > GIM>> I'd suggest to use unicast in place of point-to-point. Using my earlier example, in case when there's only one tail multipoint becomes point-to-point. I think we've missed MPLS network scenario. What would be the difference between p2p LSP and p2mp LSP? Both use labels though with different context. So the only difference is that BFD for multipoint does not monitor bi-directional continuity, i.e. viability of a path, between root and the leaf. I believe such statement already exists in the document and doesn't seem there's need to repeat it again. Perhaps we can remove that last statement altogether? Regards, Greg On Fri, Jul 7, 2017 at 6:16 PM, Greg Mirsky wrote: > Hi Santosh, et. al, > another note, question on IP/UDP encapsulation of BFD for multipoint > networks. The document says nothing about values that may be used for > Source UDP port number. Even though MultipointHead will not receive BFD > packets from MultipointTail on the UDP port listed, should we recommend t= o > use numbers from dynamic range, i.e. 49152 to 65535? I think that the > multipoint document should state, as in RFC 5881: > > The source port MUST be in the range 49152 through 65535. > > What do you think? > > Regards, > Greg > > On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky > wrote: > >> Hi Santosh, >> many thanks for your thoughtful consideration of my comments. Please fin= d >> my answers and couple more notes in-line and tagged GIM>>. >> >> Regards, >> Greg >> >> On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K < >> santosh.pallagatti@gmail.com> wrote: >> >>> Hello Greg, >>> Thanks for your comments. Please see my reply inline tagged[ SPK]. >>> >>> Thanks >>> Santosh P K >>> >>> On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky >>> wrote: >>> >>>> Dear Authors, WG chairs, et. al, >>>> please kindly consider my comments to the latest version of the draft >>>> as part of WGLC: >>>> >>>> - Very general >>>> - I suggest to add note clarifying that all terms that include >>>> "connectivity" in the document are being used as alternative to >>>> "continuity", i.e. existence of a path between the sender and th= e receiver, >>>> and should not be interpreted as "connectivity verification in t= erms of >>>> transport network". >>>> - Introduction >>>> - I find that characterization of BFD and unidirectional >>>> continuity verification as "natural fit" bit of stretching. Perh= aps >>>> "capable of supporting this use case" is acceptable; >>>> >>>> [SPK] Will take care. >>> >> GIM>> Thanks >> >>> >>>> - Goals >>>> - the last statement of non-goal seems little unclear. In fact, >>>> if there's only one tail, the BFD for multipoint network does ve= rify >>>> connectivity, though unidirectional, between the head and the ta= il. I think >>>> that the intention is to stress that p2p bi-directional connecti= vity >>>> verification is not supported by this document. >>>> >>>> [SPK] It only says that this document does not support verification of >>> unicast path between head and tail. I can clarify a bit on this. Please= let >>> me know if you have a suggestion for this. >>> >> GIM>> I'd suggest to use unicast in place of point-to-point. Using my >> earlier example, in case when there's only one tail multipoint becomes >> point-to-point. >> >>> >>> >>>> >>>> - Section 4.7 >>>> - the last paragraph notes that the discriminator value MUST NOT >>>> be changed. Since Your Discriminator MUST be set to 0 this refer= s to My >>>> Discriminator only. I think that explicit reference will make th= e statement >>>> more clear. Thus suggest s/the discriminator values/the My Discr= iminator >>>> value/ >>>> >>>> [SPK] Will take care of this. >>> >> GIM>> Thanks. >> >>> >>>> - Section 4.8 >>>> - I believe that requiring use of IP/UDP encapsulation for BFD >>>> in multipoint networks over MPSL LSP is too restrictive. I sugge= st changing >>>> text as following: >>>> >>>> OLD: >>>> >>>> For multipoint LSP, MultipointTail MUST use destination UDP port "3784= " and IP "127.0.0.0/8" range. >>>> >>>> >>>> NEW >>>> >>>> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Mul= tipointTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784= " and IP "127.0.0.0/8" range. >>>> >>>> Use of other types of encapsulation for multipoint LSP is outside the = scope of this document. >>>> >>>> >>> [SPK] Thanks. I think this make sense for non MPLS tunnels. >>> >> GIM>> Thanks. As I've looked at the text, I've realized that it misses >> IPv6 case. Please consider the following as my new proposed change (not >> sure but I think that quote marks are not required): >> NEW >> If IP/UDP encapsulation used by MultipointHead for multipoint LSP, >> MultipointTail MUST use IP/UDP encapsulation of BFD destination UDP port >> 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 >> range for IPv6. >> Use of other types of encapsulation for multipoint LSP is outside the >> scope of this document. >> >> >>>> - Section 4.10 >>>> - I cannot say what bfd.DetectMult packet is. It has not been de= fined in RFC 5880, nor in this document. What is the scenario described in = the second paragraph? Is it when MultipointHead reduces Desired Min TX Int= erval thus making defect detection more aggressive? >>>> - >>>> >>>> [SPK] This section talks about how to handle Poll sequence. In case of >>> Multipoint head we cant afford to send POLL and expect all tail to repl= y >>> with F bit set. Keeping track and building state at headend will be cos= tly. >>> >>> >> GIM>> Perhaps I wasn't clear in my question. It was to the opening of >> this sentence: >> >> The MultipointHead MUST send bfd.DetectMult packets with P bit set at >> the old transmit interval before using the higher value in order to >> avoid false detection timeouts at the tails. >> >> I couldn't find reference to "bfd.DetectMult packet" in any document rel= ated to BFD. >> >> >> >>>> - Section 7 >>>> - I think it should be plural in the first paragraph, i.e. s/Mul= tipointTail session/MultipointTail sessions/ >>>> - I think that we can add another consideration to improve, stre= ngthen security of BFD for multipoint network by suggesting that Multipoint= Tail sessions created only for known combination of MultipointHead and My D= iscriminator. Such information MAY be learned from out-of-band and mechanis= ms are outside the scope of this document. >>>> >>>> >>>> Regards, >>>> >>>> Greg >>>> >>>> >>>> >>>> On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas wrote: >>>> >>>>> Working Group, >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 >>>>> https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 >>>>> >>>>> >>>>> The BFD Multipoint documents have been stable for some time. Prior >>>>> discussion at meetings has suggested we have an implementation for th= e >>>>> main >>>>> protocol component. Also per prior discussions, we split the >>>>> active-tail >>>>> component of the original multipoint document to permit implementors >>>>> to not >>>>> have to worry about implementing active-tail procedures if they weren= 't >>>>> interested in that feature. >>>>> >>>>> We are starting an extended last call on these documents. The WGLC >>>>> will >>>>> conclude on July 14. This provides ample time for list discussion. = If >>>>> necessary, the IETF-99 meeting may provide for opportunities to close >>>>> any >>>>> contentious technical points. (BFD is not currently scheduled to >>>>> meet.) >>>>> >>>>> One item I would like to kick off is the document status of the >>>>> active-tail >>>>> mechanism. At this time, no one has implemented it that I am aware o= f. >>>>> Discussion with our AD suggests that publishing the document with >>>>> Experimental status may be reasonable to preserve the work that went >>>>> into >>>>> the proposal. >>>>> >>>>> -- Jeff >>>>> >>>>> >>>> >>> >> > --001a114c92be25c8f70553e5a3b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Santosh, et. al,
would like us to look closer into = the statement in Goals section, the one which stresses non-goal of the BFD = for multipoint networks protocol:
  • Goal= s
    • the last statement of non-goal see= ms little unclear. In fact, if there's only one tail, the BFD for multi= point network does verify connectivity, though unidirectional, between the = head and the tail. I think that the intention is to stress that p2p bi-dire= ctional connectivity verification is not supported by this document.
[SPK] It only says that this documen= t does not support verification of unicast path between head and tail. I ca= n clarify a bit on this. Please let me know if you have a suggestion for th= is.=C2=A0
GIM>> I'd suggest to use unicast in place of point-to-p= oint. Using my earlier example, in case when there's only one tail mult= ipoint becomes point-to-point.=C2=A0

I think we've missed MPL= S network scenario. What would be the difference between p2p LSP and p2mp L= SP? Both use labels though with different context. So the only difference i= s that BFD for multipoint does not monitor bi-directional continuity, i.e. = viability of a path, between root and the leaf. I believe such statement al= ready exists in the document and doesn't seem there's need to repea= t it again. Perhaps we can remove that last statement altogether?

Regar= ds,
Greg

On Fri, Jul 7, 2017 at 6:16 PM, Gre= g Mirsky <gregimirsky@gmail.com> wrote:
Hi Santosh, et. al,
another note, qu= estion on IP/UDP encapsulation of BFD for multipoint networks. The document= says nothing about values that may be used for Source UDP port number. Eve= n though MultipointHead will not receive BFD packets from MultipointTail on= the UDP port listed, should we recommend to use numbers from dynamic range= , i.e.=C2=A049152 to 65535? I t= hink that the multipoint document should state, as in RFC 5881:
The source port MUST be in the range 49152 through 6553=
5.
What do you think?

Regards,
G= reg

On Thu, Jul 6, 2017 at 11:00 A= M, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Santosh,
many thanks for yo= ur thoughtful consideration of my comments. Please find my answers and coup= le more notes in-line and tagged GIM>>.

Rega= rds,
Greg

On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K <san= tosh.pallagatti@gmail.com> wrote:
Hello Greg,
=C2=A0 =C2=A0Tha= nks for your comments. Please see my reply inline tagged[ SPK].
<= br>
Thanks
Santosh P K=C2=A0

On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Authors, WG chairs, et. al,please kindly consider my comments to the latest version of the draft as = part of WGLC:
  • Very general
    • I suggest to add n= ote clarifying that all terms that include "connectivity" in the = document are being used as alternative to "continuity", i.e. exis= tence of a path between the sender and the receiver, and should not be inte= rpreted as "connectivity verification in terms of transport network&qu= ot;.
  • Introduction=C2=A0
    • I find that characterizati= on of BFD and unidirectional continuity verification as "natural fit&q= uot; bit of stretching. Perhaps "capable of supporting this use case&q= uot; is acceptable;
[SPK= ] Will take care.=C2=A0
GIM>> Thanks=C2=A0
=
  • Goals
    • the last statement of non-goal seems little = unclear. In fact, if there's only one tail, the BFD for multipoint netw= ork does verify connectivity, though unidirectional, between the head and t= he tail. I think that the intention is to stress that p2p bi-directional co= nnectivity verification is not supported by this document.
[SPK] It only says that this document do= es not support verification of unicast path between head and tail. I can cl= arify a bit on this. Please let me know if you have a suggestion for this.= =C2=A0
GIM>> I&= #39;d suggest to use unicast in place of point-to-point. Using my earlier e= xample, in case when there's only one tail multipoint becomes point-to-= point.=C2=A0
<= div dir=3D"ltr">
=
=C2= =A0
  • Section 4.7
    • the last paragraph notes that the dis= criminator value MUST NOT be changed. Since Your Discriminator MUST be set = to 0 this refers to My Discriminator only. I think that explicit reference = will make the statement more clear. Thus suggest s/the discriminator values= /the My Discriminator value/
=
[SPK] Will take care of this.=C2=A0
GIM>> Thanks.=C2=A0
=
  • Section 4.8
    • I believe that requir= ing use of IP/UDP encapsulation for BFD in multipoint networks over MPSL LS= P is too restrictive. I suggest changing text as following:
<= div>OLD:
For m=
ultipoint LSP, MultipointTail MUST use destination UDP port "3784"=
; and IP "127.0.0.0/8=
" range.
=

NEW
If IP/UDP encapsulation used by Multipo=
intHead for multipoint LSP, MultipointTail MUST use IP/UDP encapsulation of=
 BFD destination UDP port "3784" and IP "127.0.0.0/8" range. 
Use of other types of encapsulatio=
n for multipoint LSP is outside the scope of this document.

[SPK] Thanks. I think= this make sense for non MPLS tunnels.=C2=A0
<= /blockquote>
GIM>> Thanks. As I've looked at the text,= I've realized that it misses IPv6 case. Please consider the following = as my new proposed change (not sure but I think that quote marks are not re= quired):
NEW
If IP/UDP encapsulation used= by MultipointHead for multipoint LSP, MultipointTail MUST use IP/UDP encap= sulation of BFD destination UDP port 3784, and=C2=A0the 127/8 range for IPv4, and=C2=A0the 0:0:0:0:0:FFFF= :7F00/104 range for IPv6.=C2=A0
Use of other t= ypes of encapsulation for multipoint LSP is outside the scope of this docum= ent.

  • Section 4.=
10
    • I cannot say what bfd.D=
etectMult packet is. It has not been defined in RFC 5880, nor in this docum=
ent. What is the scenario described in the second paragraph? Is it when Mul=
tipointHead reduces Desired Min TX  Interval thus making defect detection m=
ore aggressive?
[SPK]= This section talks about how to handle Poll sequence. In case of Multipoin= t head we cant afford to send POLL and expect all tail to reply with F bit = set. Keeping track and building state at headend will be costly. =C2=A0
GIM>> Perhaps I wa= sn't clear in my question.=C2=A0 It was to the opening of this sentence= :
   The MultipointHead MUST send bfd.DetectMult packets with P=
 bit set at
   the old transmit interval before using the higher value in order to
   avoid false detection timeouts at the tails. =20

I couldn't find ref=
erence to "bfd.DetectMult packet" in any document related to BFD.=


  • Section 7
    • <=
font color=3D"#000000" face=3D"arial, helvetica, sans-serif">I think it should be plural in the first paragraph, i=
.e. s/MultipointTail session/MultipointTail sessions/
      • I think that we can add another consideration to i=
mprove, strengthen security of BFD for multipoint network by suggesting tha=
t MultipointTail sessions created only for known combination of MultipointH=
ead and My Discriminator. Such information MAY be learned from out-of-band =
and mechanisms are outside the scope of this document.

Regards,
Greg


O= n Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:
Working Group,<= br>
https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.=C2=A0 Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.=C2=A0 Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't=
interested in that feature.

We are starting an extended last call on these documents.=C2=A0 The WGLC wi= ll
conclude on July 14.=C2=A0 This provides ample time for list discussion.=C2= =A0 If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.=C2=A0 (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.=C2=A0 At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff






--001a114c92be25c8f70553e5a3b9-- From nobody Sun Jul 9 14:30:36 2017 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 0A20A126C7A for ; Sun, 9 Jul 2017 14:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5A1sw0SgFPs for ; Sun, 9 Jul 2017 14:30:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6BA1242F5 for ; Sun, 9 Jul 2017 14:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25092; q=dns/txt; s=iport; t=1499635831; x=1500845431; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gNiH+UI5jhvmF6KVwS6Fjk3YrO2msYysG5HnwQfaRSQ=; b=K3myAACVKferB2slWOYhvZtgXDsQ4GTXiog2AH1Jq8rdztdB8+olsE9W 7PcDvXYfFaLur/tpLpBXk7LCAOd1BNQRJl3nTCVPL4lWIJpzWZY+mNrs+ lKKCa11W2bnsrlpIVq9xxMcseAAUmv8kgZVc16FQUijnIqQjfpwRX0VZg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAACWn2JZ/4kNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+LWSBFI4JlEuFTY1VghEshXACg0k/GAECAQEBAQEBAWsohRkGTC0?= =?us-ascii?q?QAgEIEyUHByEEDRQRAgQOBYlLTAMQBRCseoQOgx4NhAABAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEdgyiDTIFhK4J5gTyBG4IPg0eCEh8FnmM7AodGg0WED4RuggyFS4p?= =?us-ascii?q?Li3kxCYkMAQ8QOIEKdRVJEgGER0WBdgF2AYh6AQEB?= X-IronPort-AV: E=Sophos;i="5.40,336,1496102400"; d="scan'208,217";a="270801914" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2017 21:30:30 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v69LUUgN015244 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 9 Jul 2017 21:30:30 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 9 Jul 2017 17:30:29 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 9 Jul 2017 17:30:29 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Santosh P K , "rtg-bfd@ietf.org" Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Topic: WGLC for BFD Multipoint documents (ending July 14, 2017) Thread-Index: AQHS6TKRH3+h+CPmGE2vggvMdQNmVaJC1vEAgAST7YCAAAlagIACDDSAgAKiW5w= Date: Sun, 9 Jul 2017 21:30:29 +0000 Message-ID: References: <20170619193929.GE22146@pfrc.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_A141706561ED4B319A96C6D0D0F16508ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 09 Jul 2017 21:30:35 -0000 --_000_A141706561ED4B319A96C6D0D0F16508ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, How would that help interoperability? Seems like it would not matter, hence= not mention is appropriate... Sent from my iPad On Jul 7, 2017, at 9:17 PM, Greg Mirsky > wrote: Hi Santosh, et. al, another note, question on IP/UDP encapsulation of BFD for multipoint networ= ks. The document says nothing about values that may be used for Source UDP = port number. Even though MultipointHead will not receive BFD packets from M= ultipointTail on the UDP port listed, should we recommend to use numbers fr= om dynamic range, i.e. 49152 to 65535? I think that the multipoint document= should state, as in RFC 5881: The source port MUST be in the range 49152 through 65535. What do you think? Regards, Greg On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky > wrote: Hi Santosh, many thanks for your thoughtful consideration of my comments. Please find m= y answers and couple more notes in-line and tagged GIM>>. Regards, Greg On Thu, Jul 6, 2017 at 10:27 AM, Santosh P K > wrote: Hello Greg, Thanks for your comments. Please see my reply inline tagged[ SPK]. Thanks Santosh P K On Tue, Jul 4, 2017 at 1:02 AM, Greg Mirsky > wrote: Dear Authors, WG chairs, et. al, please kindly consider my comments to the latest version of the draft as pa= rt of WGLC: * Very general * I suggest to add note clarifying that all terms that include "conn= ectivity" in the document are being used as alternative to "continuity", i.= e. existence of a path between the sender and the receiver, and should not = be interpreted as "connectivity verification in terms of transport network"= . * Introduction * I find that characterization of BFD and unidirectional continuity = verification as "natural fit" bit of stretching. Perhaps "capable of suppor= ting this use case" is acceptable; [SPK] Will take care. GIM>> Thanks * Goals * the last statement of non-goal seems little unclear. In fact, if t= here's only one tail, the BFD for multipoint network does verify connectivi= ty, though unidirectional, between the head and the tail. I think that the = intention is to stress that p2p bi-directional connectivity verification is= not supported by this document. [SPK] It only says that this document does not support verification of unic= ast path between head and tail. I can clarify a bit on this. Please let me = know if you have a suggestion for this. GIM>> I'd suggest to use unicast in place of point-to-point. Using my earli= er example, in case when there's only one tail multipoint becomes point-to-= point. * Section 4.7 * the last paragraph notes that the discriminator value MUST NOT be = changed. Since Your Discriminator MUST be set to 0 this refers to My Discri= minator only. I think that explicit reference will make the statement more = clear. Thus suggest s/the discriminator values/the My Discriminator value/ [SPK] Will take care of this. GIM>> Thanks. * Section 4.8 * I believe that requiring use of IP/UDP encapsulation for BFD in mu= ltipoint networks over MPSL LSP is too restrictive. I suggest changing text= as following: OLD: For multipoint LSP, MultipointTail MUST use destination UDP port "3784" and= IP "127.0.0.0/8" range. NEW If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multipoi= ntTail MUST use IP/UDP encapsulation of BFD destination UDP port "3784" and= IP "127.0.0.0/8" range. Use of other types of encapsulation for multipoint LSP is outside the scope= of this document. [SPK] Thanks. I think this make sense for non MPLS tunnels. GIM>> Thanks. As I've looked at the text, I've realized that it misses IPv6= case. Please consider the following as my new proposed change (not sure bu= t I think that quote marks are not required): NEW If IP/UDP encapsulation used by MultipointHead for multipoint LSP, Multipoi= ntTail MUST use IP/UDP encapsulation of BFD destination UDP port 3784, and = the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range for IPv6. Use of other types of encapsulation for multipoint LSP is outside the scope= of this document. * Section 4.10 * I cannot say what bfd.DetectMult packet is. It has not been define= d in RFC 5880, nor in this document. What is the scenario described in the = second paragraph? Is it when MultipointHead reduces Desired Min TX Interva= l thus making defect detection more aggressive? * [SPK] This section talks about how to handle Poll sequence. In case of Mult= ipoint head we cant afford to send POLL and expect all tail to reply with F= bit set. Keeping track and building state at headend will be costly. GIM>> Perhaps I wasn't clear in my question. It was to the opening of this= sentence: The MultipointHead MUST send bfd.DetectMult packets with P bit set at the old transmit interval before using the higher value in order to avoid false detection timeouts at the tails. I couldn't find reference to "bfd.DetectMult packet" in any document relate= d to BFD. * Section 7 * I think it should be plural in the first paragraph, i.e. s/Multipo= intTail session/MultipointTail sessions/ * I think that we can add another consideration to improve, strength= en security of BFD for multipoint network by suggesting that MultipointTail= sessions created only for known combination of MultipointHead and My Discr= iminator. Such information MAY be learned from out-of-band and mechanisms a= re outside the scope of this document. Regards, Greg On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas > wrote: Working Group, https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 The BFD Multipoint documents have been stable for some time. Prior discussion at meetings has suggested we have an implementation for the main protocol component. Also per prior discussions, we split the active-tail component of the original multipoint document to permit implementors to not have to worry about implementing active-tail procedures if they weren't interested in that feature. We are starting an extended last call on these documents. The WGLC will conclude on July 14. This provides ample time for list discussion. If necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points. (BFD is not currently scheduled to meet.) One item I would like to kick off is the document status of the active-tail mechanism. At this time, no one has implemented it that I am aware of. Discussion with our AD suggests that publishing the document with Experimental status may be reasonable to preserve the work that went into the proposal. -- Jeff --_000_A141706561ED4B319A96C6D0D0F16508ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,

How would that help interoperability? Seems = like it would not matter, hence not mention is appropriate...

Sent from my iPad

On Jul 7, 2017, at 9:17 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Santosh, et. al,
another note, question on IP/UDP encapsulation of BFD for multipoint n= etworks. The document says nothing about values that may be used for Source= UDP port number. Even though MultipointHead will not receive BFD packets f= rom MultipointTail on the UDP port listed, should we recommend to use numbers from dynamic range, i.e. <= font face=3D"arial, helvetica, sans-serif">49152 to 65535? I think that the= multipoint document should state, as in RFC 5881:
The source port MUST be in the range 49152 through 65535.
What do you think?<= /div>

Regards,
Greg

On Thu, Jul 6, 2017 at 11:00 AM, Greg Mirsky <gregimirsky@= gmail.com> wrote:
Hi Santosh,
many thanks for your thoughtful consideration of my comments. Please f= ind my answers and couple more notes in-line and tagged GIM>>.

Regards,
Greg

On Thu, Jul 6, 2017 at 10:27 AM= , Santosh P K <santosh.pallagatti@gmail.com> wrote:
Hello Greg,
   Thanks for your comments. Please see my reply inline tagg= ed[ SPK].

Thanks
Santosh P K 

On T= ue, Jul 4, 2017 at 1:02 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Dear Authors, WG chairs, et. al,
please kindly consider my comments to the latest version of the draft = as part of WGLC:
  • Very general
    • I suggest to add note clarifying that all terms that include "conn= ectivity" in the document are being used as alternative to "conti= nuity", i.e. existence of a path between the sender and the receiver, = and should not be interpreted as "connectivity verification in terms of transport network".
  • Introduction 
    • I find that characterization of BFD and unidirectional continuity verif= ication as "natural fit" bit of stretching. Perhaps "capable= of supporting this use case" is acceptable;
[SPK] Will take care. 
GIM>> Thanks 
  • Goals
    • the last statement of non-goal seems little unclear. In fact, if there'= s only one tail, the BFD for multipoint network does verify connectivity, t= hough unidirectional, between the head and the tail. I think that the inten= tion is to stress that p2p bi-directional connectivity verification is not supported by this document.
[SPK] It only says that this document does not support verification of= unicast path between head and tail. I can clarify a bit on this. Please le= t me know if you have a suggestion for this. 
GIM>> I'd suggest to use unicast in place of point-to-point. Usi= ng my earlier example, in case when there's only one tail multipoint become= s point-to-point. 
 
  • Section 4.7
    • the last paragraph notes that the discriminator value MUST NOT be chang= ed. Since Your Discriminator MUST be set to 0 this refers to My Discriminat= or only. I think that explicit reference will make the statement more clear= . Thus suggest s/the discriminator values/the My Discriminator value/
[SPK] Will take care of this. 
GIM>> Thanks. 
  • Section 4.8
    • I believe that requiring use of IP/UDP encapsulation for BFD in multipo= int networks over MPSL LSP is too restrictive. I suggest changing text as f= ollowing:
OLD:
For multipoint LSP, MultipointTail MUST use de=
stination UDP port "3784" and IP "127.0.0.0/8" range.

NE=
W
If IP/UDP encapsulation used by MultipointHead for mul=
tipoint LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destinatio=
n UDP port "3784" and IP "127.0.0.0/8" range. 
Use of other types of encapsulation for multipoint LSP is outside the s=
cope of this document.
[SPK] Thanks. I think this make sense for non MPLS tunnels. 
GIM>> Thanks. As I've looked at the text, I've realized that it = misses IPv6 case. Please consider the following as my new proposed change (= not sure but I think that quote marks are not required):
NEW
If IP/UDP encapsulation used by MultipointHead for multi= point LSP, MultipointTail MUST use IP/UDP encapsulation of BFD destination = UDP port 3784, and the 127/8 range for IPv4, and the 0:0:0:0:0:FFFF:7F00/104 range for IPv6. 
Use of other types of encapsulation for multipoint LSP i= s outside the scope of this document.

 
  • Section 4.10
    • I c=
annot say what bfd.DetectMult packet is. It has not been defined in RFC 588=
0, nor in this document. What is the scenario described in the second parag=
raph? Is it when MultipointHead reduces Desired Min TX  Interval thus makin=
g defect detection more aggressive?
[SPK] This section talks about how to handle Poll sequence. In case of= Multipoint head we cant afford to send POLL and expect all tail to reply w= ith F bit set. Keeping track and building state at headend will be costly. =  
GIM>> Perhaps I wasn't clear in my question.  It was to the= opening of this sentence:
   The MultipointHea=
d MUST send bfd.DetectMult packets with P bit set at
   the old transmit interval before using the higher value in order to
   avoid false detection timeouts at the tails. =20

I couldn't find reference to "bfd.DetectMult p=
acket" in any document related to BFD.

  • Section 7
    • I thi=
nk it should be plural in the first paragraph, i.e. s/MultipointTail sessio=
n/MultipointTail sessions/
    • I t=
hink that we can add another consideration to improve, strengthen security =
of BFD for multipoint network by suggesting that MultipointTail sessions cr=
eated only for known combination of MultipointHead and My Discriminator. Su=
ch information MAY be learned from out-of-band and mechanisms are outside t=
he scope of this document.

Regards,
=

Greg


On Mon, Jun 19, 2017 at 12:39 PM, Jeffrey Haas <= span dir=3D"ltr"> <jhaas@pfrc.org&= gt; wrote:
Working Group,

https://tools.ietf.org/html/draft-ietf-= bfd-multipoint-10
https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04


The BFD Multipoint documents have been stable for some time.  Prior discussion at meetings has suggested we have an implementation for the main=
protocol component.  Also per prior discussions, we split the active-t= ail
component of the original multipoint document to permit implementors to not=
have to worry about implementing active-tail procedures if they weren't
interested in that feature.

We are starting an extended last call on these documents.  The WGLC wi= ll
conclude on July 14.  This provides ample time for list discussion.&nb= sp; If
necessary, the IETF-99 meeting may provide for opportunities to close any contentious technical points.  (BFD is not currently scheduled to meet= .)

One item I would like to kick off is the document status of the active-tail=
mechanism.  At this time, no one has implemented it that I am aware of= .
Discussion with our AD suggests that publishing the document with
Experimental status may be reasonable to preserve the work that went into the proposal.

-- Jeff





--_000_A141706561ED4B319A96C6D0D0F16508ciscocom_-- From nobody Sun Jul 16 06:58:29 2017 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 A7B3C120227 for ; Sun, 16 Jul 2017 06:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 x31GCRd2pDSG for ; Sun, 16 Jul 2017 06:58:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2129E1200FC for ; Sun, 16 Jul 2017 06:58:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRF68315; Sun, 16 Jul 2017 13:58:24 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 16 Jul 2017 14:58:24 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Sun, 16 Jul 2017 21:58:16 +0800 From: Mach Chen To: "rtg-bfd@ietf.org" Subject: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOw== Date: Sun, 16 Jul 2017 13:58:15 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.64.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.596B7100.0057, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3042c401b0f4dd0e77956bf0c5eff6df Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 13:58:28 -0000 Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, th= e egress LSR can freely to return or not return an Echo reply, and the Ingr= ess LSR should not expect there MUST be an Echo reply, but if there is one,= it should handle it properly. Is my understanding correct?=20 Thanks, Mach From nobody Sun Jul 16 07:25:42 2017 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 86EE712706D for ; Sun, 16 Jul 2017 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 8jSApgusPjpM for ; Sun, 16 Jul 2017 07:25:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000082.outbound.protection.outlook.com [40.92.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D867B126D73 for ; Sun, 16 Jul 2017 07:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HGOKJUR78Lbd4UFsDvFpb1UEv6CBHi72bVCC7wX0Xec=; b=fgpaUQcXhK+YxrbhKckTEH68MGpdWyvHCUUFANoNgpiwm4Bc50FLpQkOkiJ8c/4HT31ysQ+y4B9KR6fWxtkxibVfTocWCgsUe5ByCZMQ+aUTWJ3bPzCsM4Z4/aaoZaEet37BXHOvfl5Z2VzAxSAKREp8ppPTesvT0qsFBNji1yWI9NDT1akLsIOpvO5gvt5zcwLFBB44CvOD5GaKlQuMr2Bw/SIhjHOqBzgXNlihxefM0JgfY+/mOEuMJBp6qpBpal/cQbEATUXvWf+KUowwYmqcdB/MAYjSG+65ZbkV0928wfmytvPJEUEtB9sS68JR7qNovIxr9CSWaQeLZ4BHqQ== Received: from BN3NAM01FT045.eop-nam01.prod.protection.outlook.com (10.152.66.51) by BN3NAM01HT023.eop-nam01.prod.protection.outlook.com (10.152.66.65) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Sun, 16 Jul 2017 14:25:38 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com (10.152.66.54) by BN3NAM01FT045.mail.protection.outlook.com (10.152.66.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.9 via Frontend Transport; Sun, 16 Jul 2017 14:25:38 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) by MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) with mapi id 15.01.1261.022; Sun, 16 Jul 2017 14:25:38 +0000 From: Ashesh Mishra To: Mach Chen CC: "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/L Date: Sun, 16 Jul 2017 14:25:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:16F250106A5CEC79554C18AAF4EC6BFF4BE250BD9A51E74C883795E2B2DBE4B2; UpperCasedChecksum:F33810A44F86AF8209C80924B76D1D668A490910488E9AD723D98398CDE4C26B; SizeAsReceived:7197; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Hm+IJc2K1WS5lcYcr1+sQpi9ql8Tkd7s] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT023; 7:+47LQbqRdEZ4zeBw8u0kAsK89C6+cUBtNt3jhzfkIIVcdkBSmvSDHR/s4BU/hVqoTHi5rGjcXdwvR7gOdDP/5tD4BNV3g7vqcscdVj6P2VAynO4L8YIw10r58NiHAKyb8ujjVtL9c5kfPAqT/vPaX6miRWZKmiIkLJ7E5LFc631MKiuVjTk5uyRgNSx7SduXLqCq2gMc8N2xAGSmDJKUoeQSxQ6nSvzDJ58w/jh4TNrHnPygnumM6FMnet9921osCF+yQGBmfrXMja8oqICavoGRamRwpG7XxD+Uu6tj08Y8ZB53nRcrwvYRzT3Vx27HB+Qaenv9ZMBkVFMZMCPngPo6FtpHf/Wul42yDBiDRb5MFhmiV+FGEOVf5b7I/Fd2wAxqbWDzlJ1XkOGqX5voXlDmWZ11YrXszP+S2uyRS2eTaus8ACHITzdp3t3L6oeeUdhvpzo/fT/AdfMfeXeGJvOTLdYTNfsiZNFIuPcZmn5+3reMY5MApd0pcb4dbLmhGJc3n7mouiNBAwNcCeja0rqpu4Qxf46Bp+KOoxn7QnB6K2WeSTQpXJKHZa7eNlKAs67PqqV26dmLBuvi75xs9I2Lv9TKEOFl6ODldf22BF49dxV+86Q5+cv2p3UMY0/CKTTCY4J6pqtECvL1DdEFudLKUt1L9CvGa0x6XY2waAfu4ACFl3whVDThIBqFS64t/sOTpSOrPcRvXxUGvPWFYC9TV9G3n+T9t1WetJR/+GMYIP08VbQ92qkqSMl7pOxINKFSJSlgknTv+Oli0LZLsQ== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT023; H:MWHPR01MB2768.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: bb144f6b-1054-4620-c210-08d4cc5687f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3NAM01HT023; x-ms-traffictypediagnostic: BN3NAM01HT023: x-exchange-antispam-report-test: UriScan:(236129657087228)(50582790962513)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM01HT023; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM01HT023; x-forefront-prvs: 03706074BC spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2017 14:25:38.5010 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT023 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:25:41 -0000 That's how I read it ... assuming that proper handling of the LSR echo incl= udes gracefully dropping it on rx.=20 Ashesh On Jul 16, 2017, at 3:58 PM, Mach Chen wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." > From the above text, my understanding is that an Echo reply is optional, = the egress LSR can freely to return or not return an Echo reply, and the In= gress LSR should not expect there MUST be an Echo reply, but if there is on= e, it should handle it properly. Is my understanding correct?=20 Thanks, Mach From nobody Sun Jul 16 13:29:20 2017 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 530F21288B8 for ; Sun, 16 Jul 2017 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 Lisw35atAI3j for ; Sun, 16 Jul 2017 13:29:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34C1124D37 for ; Sun, 16 Jul 2017 13:29:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKN91967; Sun, 16 Jul 2017 20:29:14 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 16 Jul 2017 21:29:14 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 04:29:08 +0800 From: Mach Chen To: Ashesh Mishra CC: "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMA= Date: Sun, 16 Jul 2017 20:29:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.64.247] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.596BCC9B.0044, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11537aaad02321908c0cbfce0e48761f Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 20:29:18 -0000 SGkgQXNoZXNoLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlLCB3ZSdyZSBvbiB0 aGUgc2FtZSBwYWdlIQ0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ILeivP7IyzogQXNoZXNoIE1pc2hyYSBbbWFpbHRvOm1pc2hyYS5hc2hlc2hAb3V0bG9v ay5jb21dDQo+ILeiy83KsbzkOiAyMDE3xOo31MIxNsjVIDIyOjI2DQo+IMrVvP7IyzogTWFjaCBD aGVuDQo+ILOty806IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IEEgcXVlc3Rpb24gYWJv dXQgUkZDNTg4NA0KPiANCj4gVGhhdCdzIGhvdyBJIHJlYWQgaXQgLi4uIGFzc3VtaW5nIHRoYXQg cHJvcGVyIGhhbmRsaW5nIG9mIHRoZSBMU1IgZWNobyBpbmNsdWRlcw0KPiBncmFjZWZ1bGx5IGRy b3BwaW5nIGl0IG9uIHJ4Lg0KPiANCj4gQXNoZXNoDQo+IA0KPiBPbiBKdWwgMTYsIDIwMTcsIGF0 IDM6NTggUE0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4g SGkgQkZEZXJzLA0KPiANCj4gV2UgbWV0IGEgbXVsdGktdmVuZG9yIGludGVyb3BlcmF0ZSBpc3N1 ZSByZWNlbnRseSwgaXQncyBhYm91dCB3aGV0aGVyIGFuIEVjaG8NCj4gcmVwbHkgaXMgbmVjZXNz YXJ5Lg0KPiANCj4gSW4gU2VjdGlvbiA2IG9mIFJGQzU4ODQsIDJuZCBwYXJhZ3JhcGgNCj4gDQo+ ICIuLi4gVGhlIGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvDQo+ ICAgcmVwbHkgbWVzc2FnZSB0aGF0IGNhcnJpZXMgdGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgYXNz aWduZWQgYnkgaXQgZm9yDQo+ICAgdGhlIEJGRCBzZXNzaW9uLiINCj4gDQo+ID4gRnJvbSB0aGUg YWJvdmUgdGV4dCwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGFuIEVjaG8gcmVwbHkgaXMgb3B0 aW9uYWwsIHRoZQ0KPiBlZ3Jlc3MgTFNSIGNhbiBmcmVlbHkgdG8gcmV0dXJuIG9yIG5vdCByZXR1 cm4gYW4gRWNobyByZXBseSwgYW5kIHRoZSBJbmdyZXNzIExTUg0KPiBzaG91bGQgbm90IGV4cGVj dCB0aGVyZSBNVVNUIGJlIGFuIEVjaG8gcmVwbHksIGJ1dCBpZiB0aGVyZSBpcyBvbmUsIGl0IHNo b3VsZA0KPiBoYW5kbGUgaXQgcHJvcGVybHkuDQo+IA0KPiBJcyBteSB1bmRlcnN0YW5kaW5nIGNv cnJlY3Q/DQo+IA0KPiBUaGFua3MsDQo+IE1hY2gNCg0K From nobody Sun Jul 16 15:22:03 2017 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 7F543128C81 for ; Sun, 16 Jul 2017 15:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qYrj2eGOjGF for ; Sun, 16 Jul 2017 15:22:00 -0700 (PDT) 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 3E0AA12441E for ; Sun, 16 Jul 2017 15:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2042; q=dns/txt; s=iport; t=1500243720; x=1501453320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zgKkOYjlV/25BdQj5XfTBGmU4jFNOasBhevNdY/ULYU=; b=Nf0txp2jjXlWQ2a3tkqc1WBH0dfzZzrZYz8qn9ORFCJKkjyZnLGMiflv JN08fc78RhtM5QpoviD8RDqqxnQMYwAqhPiqZCjouY4WM+AhJurkGJEVK zUJ/viRslPw+8DQnSosVpbijBFLf8vWmlCKobYpPhKzrsQgW0JgJ+JAjL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAAA35mtZ/4ENJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy8rgXgHjgSRXpYEghGFRwIag1c/GAECAQEBAQEBAWsohRkBBTQzEhA?= =?us-ascii?q?CAQYCGAQjBQICMBQRAQEEAQ0FiAk2gVgDFZBEnV4IgiSLEgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BB4Ihg02BYYMkgTyDRYJ4gmUBBJ80ApQUggyJRYZelVYBHzg?= =?us-ascii?q?TLEt1FYVogXd2h0mBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,371,1496102400"; d="scan'208";a="274376113" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2017 22:21:59 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6GMLwaG032339 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 22:21:58 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 17:21:59 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Sun, 16 Jul 2017 17:21:58 -0500 From: "Reshad Rahman (rrahman)" To: Mach Chen , Ashesh Mishra CC: "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gA== Date: Sun, 16 Jul 2017 22:21:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.250.207] Content-Type: text/plain; charset="gb2312" Content-ID: <45F9758A77019546A2285C148E875DCD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 22:22:01 -0000 SGksDQoNCk15IHRha2UgdG9vIGlzIHRoYXQgdGhlIFJGQyBpcyBwcmV0dHkgY2xlYXIgdGhhdCBF Y2hvIHJlcGx5IGZyb20gZWdyZXNzDQpMU1IgaXMgbm90IG1hbmRhdG9yeS4NCg0KUmVnYXJkcywN ClJlc2hhZC4NCg0KDQoNCk9uIDIwMTctMDctMTYsIDQ6MjkgUE0sICJSdGctYmZkIG9uIGJlaGFs ZiBvZiBNYWNoIENoZW4iDQo8cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBt YWNoLmNoZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBBc2hlc2gsDQo+DQo+VGhhbmtzIGZv ciB5b3VyIHByb21wdCByZXNwb25zZSwgd2UncmUgb24gdGhlIHNhbWUgcGFnZSENCj4NCj5CZXN0 IHJlZ2FyZHMsDQo+TWFjaA0KPg0KPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+PiC3orz+yMs6IEFz aGVzaCBNaXNocmEgW21haWx0bzptaXNocmEuYXNoZXNoQG91dGxvb2suY29tXQ0KPj4gt6LLzcqx vOQ6IDIwMTfE6jfUwjE2yNUgMjI6MjYNCj4+IMrVvP7IyzogTWFjaCBDaGVuDQo+PiCzrcvNOiBy dGctYmZkQGlldGYub3JnDQo+PiDW98ziOiBSZTogQSBxdWVzdGlvbiBhYm91dCBSRkM1ODg0DQo+ PiANCj4+IFRoYXQncyBob3cgSSByZWFkIGl0IC4uLiBhc3N1bWluZyB0aGF0IHByb3BlciBoYW5k bGluZyBvZiB0aGUgTFNSIGVjaG8NCj4+aW5jbHVkZXMNCj4+IGdyYWNlZnVsbHkgZHJvcHBpbmcg aXQgb24gcnguDQo+PiANCj4+IEFzaGVzaA0KPj4gDQo+PiBPbiBKdWwgMTYsIDIwMTcsIGF0IDM6 NTggUE0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gDQo+PiBI aSBCRkRlcnMsDQo+PiANCj4+IFdlIG1ldCBhIG11bHRpLXZlbmRvciBpbnRlcm9wZXJhdGUgaXNz dWUgcmVjZW50bHksIGl0J3MgYWJvdXQgd2hldGhlcg0KPj5hbiBFY2hvDQo+PiByZXBseSBpcyBu ZWNlc3NhcnkuDQo+PiANCj4+IEluIFNlY3Rpb24gNiBvZiBSRkM1ODg0LCAybmQgcGFyYWdyYXBo DQo+PiANCj4+ICIuLi4gVGhlIGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGlu ZyBFY2hvDQo+PiAgIHJlcGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2NhbCBkaXNjcmlt aW5hdG9yIGFzc2lnbmVkIGJ5IGl0IGZvcg0KPj4gICB0aGUgQkZEIHNlc3Npb24uIg0KPj4gDQo+ PiA+IEZyb20gdGhlIGFib3ZlIHRleHQsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhbiBFY2hv IHJlcGx5IGlzDQo+Pm9wdGlvbmFsLCB0aGUNCj4+IGVncmVzcyBMU1IgY2FuIGZyZWVseSB0byBy ZXR1cm4gb3Igbm90IHJldHVybiBhbiBFY2hvIHJlcGx5LCBhbmQgdGhlDQo+PkluZ3Jlc3MgTFNS DQo+PiBzaG91bGQgbm90IGV4cGVjdCB0aGVyZSBNVVNUIGJlIGFuIEVjaG8gcmVwbHksIGJ1dCBp ZiB0aGVyZSBpcyBvbmUsIGl0DQo+PnNob3VsZA0KPj4gaGFuZGxlIGl0IHByb3Blcmx5Lg0KPj4g DQo+PiBJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/DQo+PiANCj4+IFRoYW5rcywNCj4+IE1h Y2gNCj4NCg0K From nobody Sun Jul 16 15:57:56 2017 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 01F14129B61 for ; Sun, 16 Jul 2017 15:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2W_8wJOPkvP for ; Sun, 16 Jul 2017 15:57:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090F712009C for ; Sun, 16 Jul 2017 15:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10434; q=dns/txt; s=iport; t=1500245873; x=1501455473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MPzlz+lbcxj3pgFIxFERKqfGEcm+vUiDVkzsLblNZuk=; b=fgMnf+k2IJ+uO5UNvoQXH7gLBzhzdg1P/RA8nZZ8uTuTqByosqDqvxe7 RMffOQpgTvk5RdQGr0HKLBvbrwnm/M5T4Bp4q0t8DsNfsSfYHmE1Qff1g US924Kt4jOnUS+fcKr38D2SsRkjB9UUW+IXzb9dG3Z52eOsQxcxgmJC8p 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQB27mtZ/5FdJa1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgy8rZIEBE4RViTaRPJB6hSyCESyFGwKDcT8YAQIBAQEBAQEBayiFGQZnEhA?= =?us-ascii?q?CAQg/BzIUEQEBBA4FiAk2gQxMAxUQsD2LEgEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RgFgyiDTYFhKwuCboE8hnGCMQWXQodyAodIjEyCDIlFhl6VVgEfOBMsS3UVWwG?= =?us-ascii?q?FDIF3dgGGGCuCEgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,371,1496102400"; d="scan'208,217";a="454325895" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 22:57:53 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6GMvqlu007617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 22:57:52 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 18:57:51 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sun, 16 Jul 2017 18:57:51 -0400 From: "Carlos Pignataro (cpignata)" To: "Reshad Rahman (rrahman)" CC: Mach Chen , Ashesh Mishra , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK Date: Sun, 16 Jul 2017 22:57:51 +0000 Message-ID: <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_1E6F72A4214142CB932A88FD93EB6B94ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 22:57:56 -0000 --_000_1E6F72A4214142CB932A88FD93EB6B94ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I also agree with the conclusion of this thread in regards to what RFC 5884= says. However, can that be in conflict with RFC 8029's procedures, in whic= h the reply might be expected? https://tools.ietf.org/html/rfc8029#section-4.4 There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. I wonder though if the text of "The egress LSR MAY respond with an LSP Ping= Echo" intended to convey that whether to reply or not depends on the value= of the Reply Mode field in the Echo request. Sent from my iPad On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) > wrote: Hi, My take too is that the RFC is pretty clear that Echo reply from egress LSR is not mandatory. Regards, Reshad. On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen" on behalf of mac= h.chen@huawei.com> wrote: Hi Ashesh, Thanks for your prompt response, we're on the same page! Best regards, Mach -----????----- ???: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] ????: 2017?7?16? 22:26 ???: Mach Chen ??: rtg-bfd@ietf.org ??: Re: A question about RFC5884 That's how I read it ... assuming that proper handling of the LSR echo includes gracefully dropping it on rx. Ashesh On Jul 16, 2017, at 3:58 PM, Mach Chen > wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Echo reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, the egress LSR can freely to return or not return an Echo reply, and the Ingress LSR should not expect there MUST be an Echo reply, but if there is one, it should handle it properly. Is my understanding correct? Thanks, Mach --_000_1E6F72A4214142CB932A88FD93EB6B94ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

I also agree with the conclusion of this thread in regards to what RFC= 5884 says. However, can that be in conflict with RFC 8029's procedures, in= which the reply might be expected?
https://to= ols.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping Echo" intended to convey that whether to reply or not depends on the = value of the Reply Mode field in the Echo request. 

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egre= ss
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.= org on behalf of mach.chen@huawei.com> wrote:=

Hi Ashesh,

Thanks for your prompt response, we're on t= he same page!

Best regards,
Mach

-----邮件原件-----<= /span>
发件人: Ashesh Mishra [mailto:mishra.ashesh@outlook.com= ]
发送时间: 2017ñ= 80;7月16日 22:26
收件人: Mach Chen<= br>
抄送: rtg-bfd@ietf.org
主题: Re: A question about RFC5= 884

That's how I read it ... assuming that prop= er handling of the LSR echo
includes
gracefully dropping it on rx.

Ashesh

On Jul 16, 2017, at 3:58 PM, Mach Chen <= mach.chen@huawei.com> wrote:=

Hi BFDers,

We met a multi-vendor interoperate issue re= cently, it's about whether
an Echo
reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with a= n LSP Ping Echo
 reply message that carries the local = discriminator assigned by it for
 the BFD session."

From the above text, my understanding is th= at an Echo reply is
optional, the
egress LSR can freely to return or not retu= rn an Echo reply, and the
Ingress LSR
should not expect there MUST be an Echo rep= ly, but if there is one, it
should
handle it properly.

Is my understanding correct?

Thanks,
Mach


--_000_1E6F72A4214142CB932A88FD93EB6B94ciscocom_-- From nobody Mon Jul 17 00:34:38 2017 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 B2D82131A64 for ; Mon, 17 Jul 2017 00:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 wDeEnRaiyE3U for ; Mon, 17 Jul 2017 00:34:35 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 4EB53131A86 for ; Mon, 17 Jul 2017 00:34:28 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p73so50481174qka.2 for ; Mon, 17 Jul 2017 00:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EkKyI3fM5NWcdMgC6kBVQwYz4Wz7s6hJ0MzNKLiRrOA=; b=dMlGe70NAnXdpPAKM73CzHoX7JrRL2uUea6Yp+9vSXqLc7vOKU26Wz150YDwUZV81r qYYqo8FnYLnd6LJ1Vdk2ZoaqLrM3Pvy1L3a0JwUvj0lkf0xcWDBvaZY/lyFp/JPG9ru0 3DeM1frq0Om8DDeBxS/LSOQiJFu+9FNdcwcY9wPt3TiRdV7EKpNC8RudDdtb9U3cthor R2CjV1O9d8cn1FOg8v3FS8qg4lU0XjBhnjTyLLXuNAHI/CIprct+gmOurN2YP/3XDpFs BnCubxbYSu76XRodTXpkvXVTdXiEJYdxNch5Ye9KG6HjXWjMoFj9loNum+/cznvj1zo0 Sjzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EkKyI3fM5NWcdMgC6kBVQwYz4Wz7s6hJ0MzNKLiRrOA=; b=Hby36EzalkLlN+AKJD4J0FKu0e5grDuTLOQDnFjvestbEC/IohGKm+4PhlidkT+tVa 6a34fNuFDc71Z6VaW5BYdpm4WypPDO4bbi7gheG9vvlef/U1gSQ1svQQZCHqkaKgIzxd yCZuMwkPxRAoLEQ8oshlxDMyRBlc+x89UtmhFBWKm1+EKodxEXxj7ephpvl339dQNYpw ltUgDsnMe34ix2NwvOyfuhUc3S6JsoHYmufphRw02URR5N1d7BXscr4wt2kj/G7PKrrK 2So6+88QqJAM6Nvk75jQjox7rUpLe4Kfdl5/Hg8d7FI0gM5BGChHsnQhF2sz8v8L6Ncd /bEw== X-Gm-Message-State: AIVw110dhWHaT4wosIrk5Jx4SCqPuU2rp+5FnktA4vWkCYdpHqSdSaq5 Hf6lfGBzAlKIoNF2SIPOy+iLMsPstA== X-Received: by 10.233.235.3 with SMTP id b3mr26451778qkg.138.1500276867311; Mon, 17 Jul 2017 00:34:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Mon, 17 Jul 2017 00:34:26 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Mon, 17 Jul 2017 00:34:26 -0700 Message-ID: Subject: Re: A question about RFC5884 To: Mach Chen Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c09743ebdade205547e6d00" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:34:37 -0000 --94eb2c09743ebdade205547e6d00 Content-Type: text/plain; charset="UTF-8" Hi Mach, et. al, I recall that this question was discussed some time ago and the clarification came from the original authors of the BFD protocol. The Echo Reply is optional if there's no error to report. But if the remote LER, acting as BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message. Regards, Greg On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen wrote: > Hi BFDers, > > We met a multi-vendor interoperate issue recently, it's about whether an > Echo reply is necessary. > > In Section 6 of RFC5884, 2nd paragraph > > "... The egress LSR MAY respond with an LSP Ping Echo > reply message that carries the local discriminator assigned by it for > the BFD session." > > >From the above text, my understanding is that an Echo reply is optional, > the egress LSR can freely to return or not return an Echo reply, and the > Ingress LSR should not expect there MUST be an Echo reply, but if there is > one, it should handle it properly. > > Is my understanding correct? > > Thanks, > Mach > > --94eb2c09743ebdade205547e6d00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mach, et. al,
I recall that this question was discu= ssed some time ago and the clarification came from the original authors of = the BFD protocol. The Echo Reply is optional if there's no error to rep= ort. But if the remote LER, acting as BFD node, does decide to send the Ech= o Reply it MUST send it after is sends the first BFD control message.
=

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach= Chen <mach.chen@huawei.com> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether a= n Echo reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
=C2=A0 =C2=A0reply message that carries the local discriminator assigned by= it for
=C2=A0 =C2=A0the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach


--94eb2c09743ebdade205547e6d00-- From nobody Mon Jul 17 00:58:48 2017 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 C8848131794 for ; Mon, 17 Jul 2017 00:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 ZGeyhAZ_Wfw5 for ; Mon, 17 Jul 2017 00:58:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F94131945 for ; Mon, 17 Jul 2017 00:58:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR07367; Mon, 17 Jul 2017 07:58:41 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 08:58:08 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 15:58:04 +0800 From: Mach Chen To: Greg Mirsky CC: "rtg-bfd@ietf.org" Subject: =?utf-8?B?562U5aSNOiBBIHF1ZXN0aW9uIGFib3V0IFJGQzU4ODQ=?= Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAUHekAABGQ11A= Date: Mon, 17 Jul 2017 07:58:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.67.154] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6Adggeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.596C6E32.0009, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 950f6d34fb8e98ec6810c3ff55445309 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 07:58:48 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6Adggeml508mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KVGhhbmtzIGZvciBzaGFyaW5nIHRoaXMgaW5mb3JtYXRpb24hDQoNCkJlc3Qg cmVnYXJkcywNCk1hY2gNCg0K5Y+R5Lu25Lq6OiBHcmVnIE1pcnNreSBbbWFpbHRvOmdyZWdpbWly c2t5QGdtYWlsLmNvbV0NCuWPkemAgeaXtumXtDogMjAxN+W5tDfmnIgxN+aXpSAxNTozNA0K5pS2 5Lu25Lq6OiBNYWNoIENoZW4NCuaKhOmAgTogcnRnLWJmZEBpZXRmLm9yZw0K5Li76aKYOiBSZTog QSBxdWVzdGlvbiBhYm91dCBSRkM1ODg0DQoNCkhpIE1hY2gsIGV0LiBhbCwNCkkgcmVjYWxsIHRo YXQgdGhpcyBxdWVzdGlvbiB3YXMgZGlzY3Vzc2VkIHNvbWUgdGltZSBhZ28gYW5kIHRoZSBjbGFy aWZpY2F0aW9uIGNhbWUgZnJvbSB0aGUgb3JpZ2luYWwgYXV0aG9ycyBvZiB0aGUgQkZEIHByb3Rv Y29sLiBUaGUgRWNobyBSZXBseSBpcyBvcHRpb25hbCBpZiB0aGVyZSdzIG5vIGVycm9yIHRvIHJl cG9ydC4gQnV0IGlmIHRoZSByZW1vdGUgTEVSLCBhY3RpbmcgYXMgQkZEIG5vZGUsIGRvZXMgZGVj aWRlIHRvIHNlbmQgdGhlIEVjaG8gUmVwbHkgaXQgTVVTVCBzZW5kIGl0IGFmdGVyIGlzIHNlbmRz IHRoZSBmaXJzdCBCRkQgY29udHJvbCBtZXNzYWdlLg0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBT dW4sIEp1bCAxNiwgMjAxNyBhdCA2OjU4IEFNLCBNYWNoIENoZW4gPG1hY2guY2hlbkBodWF3ZWku Y29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkgQkZEZXJzLA0KDQpX ZSBtZXQgYSBtdWx0aS12ZW5kb3IgaW50ZXJvcGVyYXRlIGlzc3VlIHJlY2VudGx5LCBpdCdzIGFi b3V0IHdoZXRoZXIgYW4gRWNobyByZXBseSBpcyBuZWNlc3NhcnkuDQoNCkluIFNlY3Rpb24gNiBv ZiBSRkM1ODg0LCAybmQgcGFyYWdyYXBoDQoNCiIuLi4gVGhlIGVncmVzcyBMU1IgTUFZIHJlc3Bv bmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvDQogICByZXBseSBtZXNzYWdlIHRoYXQgY2FycmllcyB0 aGUgbG9jYWwgZGlzY3JpbWluYXRvciBhc3NpZ25lZCBieSBpdCBmb3INCiAgIHRoZSBCRkQgc2Vz c2lvbi4iDQoNCj5Gcm9tIHRoZSBhYm92ZSB0ZXh0LCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg YW4gRWNobyByZXBseSBpcyBvcHRpb25hbCwgdGhlIGVncmVzcyBMU1IgY2FuIGZyZWVseSB0byBy ZXR1cm4gb3Igbm90IHJldHVybiBhbiBFY2hvIHJlcGx5LCBhbmQgdGhlIEluZ3Jlc3MgTFNSIHNo b3VsZCBub3QgZXhwZWN0IHRoZXJlIE1VU1QgYmUgYW4gRWNobyByZXBseSwgYnV0IGlmIHRoZXJl IGlzIG9uZSwgaXQgc2hvdWxkIGhhbmRsZSBpdCBwcm9wZXJseS4NCg0KSXMgbXkgdW5kZXJzdGFu ZGluZyBjb3JyZWN0Pw0KDQpUaGFua3MsDQpNYWNoDQoNCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6Adggeml508mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBHcmVnLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHNoYXJpbmcgdGhpcyBpbmZvcm1h dGlvbiE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFjaDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBHcmVnIE1pcnNreSBbbWFp bHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAy MDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJF Ti1VUyI+Nzwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTc8L3NwYW4+5pelPHNwYW4gbGFu Zz0iRU4tVVMiPiAxNTozNDxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBNYWNoIENoZW48YnI+DQo8L3NwYW4+ PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT Ij4gcnRnLWJmZEBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1V UyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogQSBxdWVzdGlvbiBhYm91dCBS RkM1ODg0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I aSBNYWNoLCBldC4gYWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHJlY2FsbCB0aGF0IHRoaXMgcXVlc3Rpb24g d2FzIGRpc2N1c3NlZCBzb21lIHRpbWUgYWdvIGFuZCB0aGUgY2xhcmlmaWNhdGlvbiBjYW1lIGZy b20gdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2YgdGhlIEJGRCBwcm90b2NvbC4gVGhlIEVjaG8gUmVw bHkgaXMgb3B0aW9uYWwgaWYgdGhlcmUncyBubyBlcnJvciB0byByZXBvcnQuIEJ1dCBpZiB0aGUg cmVtb3RlIExFUiwgYWN0aW5nDQogYXMgQkZEIG5vZGUsIGRvZXMgZGVjaWRlIHRvIHNlbmQgdGhl IEVjaG8gUmVwbHkgaXQgTVVTVCBzZW5kIGl0IGFmdGVyIGlzIHNlbmRzIHRoZSBmaXJzdCBCRkQg Y29udHJvbCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+R3JlZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gU3VuLCBKdWwgMTYsIDIwMTcg YXQgNjo1OCBBTSwgTWFjaCBDaGVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFjaC5jaGVuQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWNoLmNoZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEJGRGVycyw8YnI+DQo8YnI+ DQpXZSBtZXQgYSBtdWx0aS12ZW5kb3IgaW50ZXJvcGVyYXRlIGlzc3VlIHJlY2VudGx5LCBpdCdz IGFib3V0IHdoZXRoZXIgYW4gRWNobyByZXBseSBpcyBuZWNlc3NhcnkuPGJyPg0KPGJyPg0KSW4g U2VjdGlvbiA2IG9mIFJGQzU4ODQsIDJuZCBwYXJhZ3JhcGg8YnI+DQo8YnI+DQomcXVvdDsuLi4g VGhlIGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvPGJyPg0KJm5i c3A7ICZuYnNwO3JlcGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2NhbCBkaXNjcmltaW5h dG9yIGFzc2lnbmVkIGJ5IGl0IGZvcjxicj4NCiZuYnNwOyAmbmJzcDt0aGUgQkZEIHNlc3Npb24u JnF1b3Q7PGJyPg0KPGJyPg0KJmd0O0Zyb20gdGhlIGFib3ZlIHRleHQsIG15IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCBhbiBFY2hvIHJlcGx5IGlzIG9wdGlvbmFsLCB0aGUgZWdyZXNzIExTUiBjYW4g ZnJlZWx5IHRvIHJldHVybiBvciBub3QgcmV0dXJuIGFuIEVjaG8gcmVwbHksIGFuZCB0aGUgSW5n cmVzcyBMU1Igc2hvdWxkIG5vdCBleHBlY3QgdGhlcmUgTVVTVCBiZSBhbiBFY2hvIHJlcGx5LCBi dXQgaWYgdGhlcmUgaXMgb25lLCBpdCBzaG91bGQgaGFuZGxlIGl0IHByb3Blcmx5Ljxicj4NCjxi cj4NCklzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD88YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K TWFjaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6Adggeml508mbxchi_-- From nobody Mon Jul 17 01:42:55 2017 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 00921131B15 for ; Mon, 17 Jul 2017 01:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 SBInNKHF3xet for ; Mon, 17 Jul 2017 01:42:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E847B131B1E for ; Mon, 17 Jul 2017 01:42:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR16146; Mon, 17 Jul 2017 08:42:41 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 09:42:40 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 16:42:32 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , "Reshad Rahman (rrahman)" CC: Ashesh Mishra , "rtg-bfd@ietf.org" Subject: RE: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8A= Date: Mon, 17 Jul 2017 08:42:31 +0000 Message-ID: References: , <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com> In-Reply-To: <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.67.154] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844EF6dggeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.596C7881.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9dde44dcfc51182f94ddede5fc82bdd4 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:42:53 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844EF6dggeml508mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpUaGFua3MgZm9yIHNoYXJpbmcgeW91ciB0aG91Z2h0cy4NCg0KSU1ITywg aXQgbWF5IG5vdCBiZSBuZWNlc3NhcnkgdG8gY29uc2lkZXIgdGhpcyBMU1AgUGluZyBiYXNlZCBi b290c3RyYXBwaW5nIGFzIG5vcm1hbCBMU1AgcGluZy4gQW5kIHNpbmNlIGJvdGggdGhlIGluZ3Jl c3MgYW5kIGVncmVzcyBMU1IgcHJvY2VzcyB0aGUgZWNobyBtZXNzYWdlcyBpbiB0aGUgY29udGV4 dCBvZiBCRkQgc2Vzc2lvbiBlc3RhYmxpc2htZW50LCBpdCBzaG91bGQgYmUgbm8gcHJvYmxlbSB0 byBwcm9jZXNzIGFzIGRlc2NyaWJlZCBpbiBSRkM1ODg0Lg0KDQpCVFcsIFJGQzU4ODQgZG9lcyBu b3Qgc3BlY2lmeSB3aGljaCByZXBseSBtb2RlIHdpbGwgYmUgdXNlZCA6KQ0KDQpCZXN0IHJlZ2Fy ZHMsDQpNYWNoDQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNw aWduYXRhQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNywgMjAxNyA2OjU4IEFNDQpU bzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikNCkNjOiBNYWNoIENoZW47IEFzaGVzaCBNaXNocmE7 IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBBIHF1ZXN0aW9uIGFib3V0IFJGQzU4ODQN Cg0KSGksDQoNCkkgYWxzbyBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9uIG9mIHRoaXMgdGhyZWFk IGluIHJlZ2FyZHMgdG8gd2hhdCBSRkMgNTg4NCBzYXlzLiBIb3dldmVyLCBjYW4gdGhhdCBiZSBp biBjb25mbGljdCB3aXRoIFJGQyA4MDI5J3MgcHJvY2VkdXJlcywgaW4gd2hpY2ggdGhlIHJlcGx5 IG1pZ2h0IGJlIGV4cGVjdGVkPw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgwMjkj c2VjdGlvbi00LjQNCg0KVGhlcmUgaXMgY2VydGFpbmx5IG5vIG5lZWQgdG8gY2FycnkgYW55IGlu Zm9ybWF0aW9uIGluIGFuIE1QTFMgTFNQIFBpbmcgcmVwbHksIHNpbmNlIGF0IHRoYXQgcG9pbnQg dGhlIGRpc2NyaW1pbmF0b3J5IGFyZSBhbHJlYWR5IGNhcnJpZWQgaW4gQkZELiBUaGUgcmVwbHkg bWlnaHQgYmUgaW1wb3J0YW50IG9ubHkgaWYgRkVDIHZhbGlkYXRpb24gZmFpbHMuDQoNCkkgd29u ZGVyIHRob3VnaCBpZiB0aGUgdGV4dCBvZiAiVGhlIGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0 aCBhbiBMU1AgUGluZyBFY2hvIiBpbnRlbmRlZCB0byBjb252ZXkgdGhhdCB3aGV0aGVyIHRvIHJl cGx5IG9yIG5vdCBkZXBlbmRzIG9uIHRoZSB2YWx1ZSBvZiB0aGUgUmVwbHkgTW9kZSBmaWVsZCBp biB0aGUgRWNobyByZXF1ZXN0Lg0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiBKdWwgMTYsIDIw MTcsIGF0IDY6MjIgUE0sIFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNv bTxtYWlsdG86cnJhaG1hbkBjaXNjby5jb20+PiB3cm90ZToNCkhpLA0KDQpNeSB0YWtlIHRvbyBp cyB0aGF0IHRoZSBSRkMgaXMgcHJldHR5IGNsZWFyIHRoYXQgRWNobyByZXBseSBmcm9tIGVncmVz cw0KTFNSIGlzIG5vdCBtYW5kYXRvcnkuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCg0KDQpPbiAy MDE3LTA3LTE2LCA0OjI5IFBNLCAiUnRnLWJmZCBvbiBiZWhhbGYgb2YgTWFjaCBDaGVuIg0KPHJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPiBv biBiZWhhbGYgb2YgbWFjaC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWku Y29tPj4gd3JvdGU6DQoNCg0KSGkgQXNoZXNoLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJvbXB0IHJl c3BvbnNlLCB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlIQ0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoN Ci0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBc2hlc2ggTWlzaHJhIFttYWlsdG86bWlzaHJh LmFzaGVzaEBvdXRsb29rLmNvbV0NCreiy83KsbzkOiAyMDE3xOo31MIxNsjVIDIyOjI2DQrK1bz+ yMs6IE1hY2ggQ2hlbg0Ks63LzTogcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRm Lm9yZz4NCtb3zOI6IFJlOiBBIHF1ZXN0aW9uIGFib3V0IFJGQzU4ODQNCg0KVGhhdCdzIGhvdyBJ IHJlYWQgaXQgLi4uIGFzc3VtaW5nIHRoYXQgcHJvcGVyIGhhbmRsaW5nIG9mIHRoZSBMU1IgZWNo bw0KaW5jbHVkZXMNCmdyYWNlZnVsbHkgZHJvcHBpbmcgaXQgb24gcnguDQoNCkFzaGVzaA0KDQpP biBKdWwgMTYsIDIwMTcsIGF0IDM6NTggUE0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5j b208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkhpIEJGRGVycywNCg0K V2UgbWV0IGEgbXVsdGktdmVuZG9yIGludGVyb3BlcmF0ZSBpc3N1ZSByZWNlbnRseSwgaXQncyBh Ym91dCB3aGV0aGVyDQphbiBFY2hvDQpyZXBseSBpcyBuZWNlc3NhcnkuDQoNCkluIFNlY3Rpb24g NiBvZiBSRkM1ODg0LCAybmQgcGFyYWdyYXBoDQoNCiIuLi4gVGhlIGVncmVzcyBMU1IgTUFZIHJl c3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvDQogcmVwbHkgbWVzc2FnZSB0aGF0IGNhcnJpZXMg dGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgYXNzaWduZWQgYnkgaXQgZm9yDQogdGhlIEJGRCBzZXNz aW9uLiINCg0KRnJvbSB0aGUgYWJvdmUgdGV4dCwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGFu IEVjaG8gcmVwbHkgaXMNCm9wdGlvbmFsLCB0aGUNCmVncmVzcyBMU1IgY2FuIGZyZWVseSB0byBy ZXR1cm4gb3Igbm90IHJldHVybiBhbiBFY2hvIHJlcGx5LCBhbmQgdGhlDQpJbmdyZXNzIExTUg0K c2hvdWxkIG5vdCBleHBlY3QgdGhlcmUgTVVTVCBiZSBhbiBFY2hvIHJlcGx5LCBidXQgaWYgdGhl cmUgaXMgb25lLCBpdA0Kc2hvdWxkDQpoYW5kbGUgaXQgcHJvcGVybHkuDQoNCklzIG15IHVuZGVy c3RhbmRpbmcgY29ycmVjdD8NCg0KVGhhbmtzLA0KTWFjaA0KDQoNCg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844EF6dggeml508mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

Thanks for= sharing your thoughts.

 = ;

IMHO, it m= ay not be necessary to consider this LSP Ping based bootstrapping as normal= LSP ping. And since both the ingress and egress LSR process the echo messages in the context of BFD session establishment, it should b= e no problem to process as described in RFC5884.

 = ;

BTW, RFC58= 84 does not specify which reply mode will be used J

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi,

 

I also agree with the conclusio= n of this thread in regards to what RFC 5884 says. However, can that be in = conflict with RFC 8029's procedures, in which the reply might be expected?<= o:p>

https://tools.ietf.org/html/rfc8029#section-4.= 4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

 

I wonder though if the text of = "The egress LSR MAY respond with an LSP Ping Echo" intended to co= nvey that whether to reply or not depends on the value of the Reply Mode fi= eld in the Echo request. 

 

Sent from my iPad

=
On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote:=


Hi Ashesh,

 

Thanks for your prompt response= , we're on the same page!

 

Best regards,=

Mach

 

-----=D3=CA=BC=FE=D4=AD= =BC=FE-----

=B7=A2=BC=FE=C8=CB: Ashesh Mish= ra [mailto:mishra.ashesh@outlo= ok.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2017<= /span>=C4=EA7=D4=C216=C8=D5 22:26

=CA=D5=BC=FE=C8=CB: Mach Chen

=B3=AD=CB=CD: rtg-bfd@ietf.org

=D6=F7=CC=E2: Re: A question ab= out RFC5884

 

That's how I read it ... assumi= ng that proper handling of the LSR echo

includes

gracefully dropping it on rx.

 

Ashesh

 

On Jul 16, 2017, at 3:58 PM, Ma= ch Chen <mach.chen@huawei.com> wrote:

 

Hi BFDers,

 

We met a multi-vendor interoper= ate issue recently, it's about whether

an Echo

reply is necessary.<= /span>

 

In Section 6 of RFC5884, 2nd pa= ragraph

 

"... The egress LSR MAY re= spond with an LSP Ping Echo

 reply message that carrie= s the local discriminator assigned by it for

 the BFD session."

 

From the above text, my underst= anding is that an Echo reply is

optional, the=

egress LSR can freely to return= or not return an Echo reply, and the

Ingress LSR

should not expect there MUST be= an Echo reply, but if there is one, it

should

handle it properly.<= /span>

 

Is my understanding correct?

 

Thanks,

Mach

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844EF6dggeml508mbxchi_-- From nobody Mon Jul 17 01:58:19 2017 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 7BE2C12EC36 for ; Mon, 17 Jul 2017 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 aKsjjsigVesi for ; Mon, 17 Jul 2017 01:58:12 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 E280B12EA7C for ; Mon, 17 Jul 2017 01:58:11 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 35so40329440uax.3 for ; Mon, 17 Jul 2017 01:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xyHHFzmmvk/skmhdUMfo3lWHuuq38vMeF031advGgWs=; b=YxpTAey0nFA14kjE2h946GN0BWfZTL8FgM3h86sW4wJY4Lj3tPokgPKapeS6h5/BT9 dXiAQB//9VNZCXxFBlui8RutA7+mzm3RC3PMDgvboBU+rO7jA+UvruQdwj0QRJpkiAMk GNnZY/r7/njhwMXJLoJZrSexhL7YF0jvrta3MACuWxfPN65HZP7xNznxVuBpWWutBwEN BJn5gTOufpiyRAMlcynKF6/V+5zjJ8WLQqkyNXxaNuWcqcev1cLTl6I/WXOBIPvmhZB/ NXhQ2D8DPGjKBfv3jez4yxcU3JBm1RMAzlqjB6QtWCLbNTDWbW41y0meQv92+d4gDh4N 7taQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xyHHFzmmvk/skmhdUMfo3lWHuuq38vMeF031advGgWs=; b=AP2ZM0YCY1+8Mip/GJXN1s3YQ9EFoxCXvtQuSqffu8/6twtrS5FCo7hoz70mGi0KII gPV5NuYJ4JQPDl3hAreAEUyV0fn2XkEr0EySkmIHj5fwizU08numbbRXFPm7TDPHtUbe TYPaq2T21HFxGHn65lG9hh/jkYQynBndJs8MHh0xwssifWcez/Zq9pIziG4GOS/0CUw2 mMJ31t5odxTQww2pVOb2yInoglwGcimk7XjbHdq3yholzClJhsEsXSmPvgR2G2MZ/fYm GCI1XlqORS2LAlJ7t1PfQrzZe6mj+4Mn139TR8VME9B81TtzoMPyhs/smvFB1TUCl+Kc 6blQ== X-Gm-Message-State: AIVw110VLITpNM3TFiFPgx+/9tUx7NHwj3HiCMJ/Q+RmIbG3BsRv0D34 YkgBdwomuaJ8tGYqeO3Tpcc6Vk4Yfg== X-Received: by 10.31.16.22 with SMTP id g22mr12174797vki.46.1500281890992; Mon, 17 Jul 2017 01:58:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.148.27 with HTTP; Mon, 17 Jul 2017 01:58:10 -0700 (PDT) In-Reply-To: References: From: Santosh P K Date: Mon, 17 Jul 2017 14:28:10 +0530 Message-ID: Subject: Re: A question about RFC5884 To: Mach Chen Cc: "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a114362182cf67405547f9922" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:58:13 -0000 --001a114362182cf67405547f9922 Content-Type: text/plain; charset="UTF-8" I read it as Local discriminator assigned for a BDS session is optional in echo reply that is being sent in response to LSP ping echo. I don't think RFC 5884 is not talking about echo reply being optional. Thanks Santosh P K On Sun, Jul 16, 2017 at 7:28 PM, Mach Chen wrote: > Hi BFDers, > > We met a multi-vendor interoperate issue recently, it's about whether an > Echo reply is necessary. > > In Section 6 of RFC5884, 2nd paragraph > > "... The egress LSR MAY respond with an LSP Ping Echo > reply message that carries the local discriminator assigned by it for > the BFD session." > > >From the above text, my understanding is that an Echo reply is optional, > the egress LSR can freely to return or not return an Echo reply, and the > Ingress LSR should not expect there MUST be an Echo reply, but if there is > one, it should handle it properly. > > Is my understanding correct? > > Thanks, > Mach > > --001a114362182cf67405547f9922 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I read it as Local discriminator assigned for a BDS sessio= n is optional in echo reply that is being sent in response to LSP ping echo= . I don't think RFC 5884 is not talking about echo reply being optional= .=C2=A0

Thanks
Santosh P K=C2=A0

On Sun, Jul 16, 201= 7 at 7:28 PM, Mach Chen <mach.chen@huawei.com> wrote:
=
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether a= n Echo reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
=C2=A0 =C2=A0reply message that carries the local discriminator assigned by= it for
=C2=A0 =C2=A0the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach


--001a114362182cf67405547f9922-- From nobody Mon Jul 17 07:55:54 2017 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 7B6F4131C34 for ; Mon, 17 Jul 2017 07:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzYycpgMRovq for ; Mon, 17 Jul 2017 07:55:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C886131C43 for ; Mon, 17 Jul 2017 07:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23858; q=dns/txt; s=iport; t=1500303350; x=1501512950; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sv8LoP2wik5Mi9vMi1jvaapjn/3T+imo9rsttl7BMKg=; b=UQfBna6dwbl0Nm2kbK+YeIYuOw7wd78FqG9eykUhMbaw+1FG0YBslCmF DL6VTngcqdRWBrfMv3AdzYJhA7zKutO1xbKYxqcutHqH5nv3UVQyOKt7u CD7o/d4TlWkzR6Gcgk3H3SSaLJTtCfDTkEzpZvQ0rOn2I2kmKhyDLA+Rh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAADUzmxZ/4ENJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9AK2SBFI4LkV+WBIIRLIUbAoNEPxgBAgEBAQEBAQFrKIUYAQEBAQM?= =?us-ascii?q?tOhIQAgEIEQQBASEHBzIUCQgCBA4FiAk2gQxMAxUQsVuLFgEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyiDTYFhK4J5gTyDZIMNgjEFl0KHcgKHSIxMggyJRYZelVY?= =?us-ascii?q?BHzgTLEt1FVsBhQyBd3YBhk4rghIBAQE?= X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="271058825" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2017 14:55:49 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6HEtmrF020076 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 14:55:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 10:55:48 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 10:55:48 -0400 From: "Carlos Pignataro (cpignata)" To: Mach Chen CC: "Reshad Rahman (rrahman)" , Ashesh Mishra , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8CAAaePmA== Date: Mon, 17 Jul 2017 14:55:48 +0000 Message-ID: <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com> References: , <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_6263E0A6EE0843BBA845BCF5788D2A14ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 14:55:52 -0000 --_000_6263E0A6EE0843BBA845BCF5788D2A14ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, On Jul 17, 2017, at 10:42 AM, Mach Chen > wrote: Hi Carlos, Thanks for sharing your thoughts. IMHO, it may not be necessary to consider this LSP Ping based bootstrapping= as normal LSP ping. Would it be considered an abnormal LSP Ping? :-) If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specifi= ed in 4379, or those processes for LSP Ping be updated. Sent from my iPad And since both the ingress and egress LSR process the echo messages in the = context of BFD session establishment, it should be no problem to process as= described in RFC5884. BTW, RFC5884 does not specify which reply mode will be used :) Best regards, Mach From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Monday, July 17, 2017 6:58 AM To: Reshad Rahman (rrahman) Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org Subject: Re: A question about RFC5884 Hi, I also agree with the conclusion of this thread in regards to what RFC 5884= says. However, can that be in conflict with RFC 8029's procedures, in whic= h the reply might be expected? https://tools.ietf.org/html/rfc8029#section-4.4 There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. I wonder though if the text of "The egress LSR MAY respond with an LSP Ping= Echo" intended to convey that whether to reply or not depends on the value= of the Reply Mode field in the Echo request. Sent from my iPad On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) > wrote: Hi, My take too is that the RFC is pretty clear that Echo reply from egress LSR is not mandatory. Regards, Reshad. On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen" on behalf of mac= h.chen@huawei.com> wrote: Hi Ashesh, Thanks for your prompt response, we're on the same page! Best regards, Mach -----????----- ???: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] ????: 2017?7?16? 22:26 ???: Mach Chen ??: rtg-bfd@ietf.org ??: Re: A question about RFC5884 That's how I read it ... assuming that proper handling of the LSR echo includes gracefully dropping it on rx. Ashesh On Jul 16, 2017, at 3:58 PM, Mach Chen > wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Echo reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, the egress LSR can freely to return or not return an Echo reply, and the Ingress LSR should not expect there MUST be an Echo reply, but if there is one, it should handle it properly. Is my understanding correct? Thanks, Mach --_000_6263E0A6EE0843BBA845BCF5788D2A14ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Carlos,=

 = ;

Thanks for= sharing your thoughts.

 = ;

IMHO, it m= ay not be necessary to consider this LSP Ping based bootstrapping as normal= LSP ping.


Would it be considered an abnormal LSP Ping? :-)

If RFC 5884 references RFC 4379, I'd expect it means an LSP P= ing as specified in 4379, or those processes for LSP Ping be updated. =

Sent from my iPad

And since = both the ingress and egress LSR process the echo messages in the context of= BFD session establishment, it should be no problem to process as described in RFC5884.

 = ;

BTW, RFC58= 84 does not specify which reply mode will be used J

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rt= g-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi,

 

I also agree with the conclusio= n of this thread in regards to what RFC 5884 says. However, can that be in = conflict with RFC 8029's procedures, in which the reply might be expected?<= o:p>

https://tools.ietf.org/html/rfc8029#section-4.= 4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

 

I wonder though if the text of = "The egress LSR MAY respond with an LSP Ping Echo" intended to co= nvey that whether to reply or not depends on the value of the Reply Mode fi= eld in the Echo request. 

 

Sent from my iPad

=
On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote:=


Hi Ashesh,

 

Thanks for your prompt response= , we're on the same page!

 

Best regards,=

Mach

 

-----邮件= 1407;件-----

发件人: Ashes= h Mishra [mailto:mishra.ashesh= @outlook.com]

发送时间: 2017年7月16日 22:26

收件人: Mach = Chen

抄送: rtg-bfd@ietf.org

主题: Re: A questio= n about RFC5884

 

That's how I read it ... assumi= ng that proper handling of the LSR echo

includes

gracefully dropping it on rx.

 

Ashesh

 

On Jul 16, 2017, at 3:58 PM, Ma= ch Chen <mach.chen@huawei.com> wrote:

 

Hi BFDers,

 

We met a multi-vendor interoper= ate issue recently, it's about whether

an Echo

reply is necessary.<= /span>

 

In Section 6 of RFC5884, 2nd pa= ragraph

 

"... The egress LSR MAY re= spond with an LSP Ping Echo

 reply message that carrie= s the local discriminator assigned by it for

 the BFD session."

 

From the above text, my underst= anding is that an Echo reply is

optional, the=

egress LSR can freely to return= or not return an Echo reply, and the

Ingress LSR

should not expect there MUST be= an Echo reply, but if there is one, it

should

handle it properly.<= /span>

 

Is my understanding correct?

 

Thanks,

Mach

 

 

--_000_6263E0A6EE0843BBA845BCF5788D2A14ciscocom_-- From nobody Mon Jul 17 08:02:22 2017 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 B9CC4131C43 for ; Mon, 17 Jul 2017 08:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoIZjM94-_wi for ; Mon, 17 Jul 2017 08:02:19 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459DD130019 for ; Mon, 17 Jul 2017 08:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3818; q=dns/txt; s=iport; t=1500303739; x=1501513339; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cBp7tQYDVwU5YKK4mk2jleV6cUaFJNSz3PQDxwk5lEc=; b=HbyXPRz5kh/RUtbsFHkoruCm5fid//t4L4iPQuKVSaan/qO91kCWjOvy rTmRCsZGuCGmS2qnTPIq4/7s6NhgjF8X627HxUsNjcMJxjM/2Zaqebae1 hlTwIgCTorSyU3StXKYJ8MYwf3XFExiP7jXR0RG2yAK2H+wA7597v5D0G M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAADl0GxZ/4sNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBeI4Lmg2IKoUsghGFRwKDRD8YAQIBAQEBAQEBayiFGQZnEhACAQg?= =?us-ascii?q?EOwchERQRAQEEDgWJS0wDFbFshywNg10BAQEBAQEBAQEBAQEBAQEBAQEBAQEdg?= =?us-ascii?q?yiDTYFhK4J5gTyBG4VWgjEFnnk7Ao8khHCSL4wKiUwBHziBCnUVWwGFDIF3dok?= =?us-ascii?q?MAQEB?= X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="455017973" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2017 15:02:18 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6HF2H40011702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 15:02:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 11:02:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 11:02:17 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Mach Chen , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAtQzYAAAdCXes= Date: Mon, 17 Jul 2017 15:02:17 +0000 Message-ID: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_983DC002121A48FA94A9D0FF68D07393ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:02:21 -0000 --_000_983DC002121A48FA94A9D0FF68D07393ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, Pointer? Thanks, Sent from my iPad On Jul 17, 2017, at 9:34 AM, Greg Mirsky > wrote: Hi Mach, et. al, I recall that this question was discussed some time ago and the clarificati= on came from the original authors of the BFD protocol. The Echo Reply is op= tional if there's no error to report. But if the remote LER, acting as BFD = node, does decide to send the Echo Reply it MUST send it after is sends the= first BFD control message. Regards, Greg On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen > wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, t= he egress LSR can freely to return or not return an Echo reply, and the Ing= ress LSR should not expect there MUST be an Echo reply, but if there is one= , it should handle it properly. Is my understanding correct? Thanks, Mach --_000_983DC002121A48FA94A9D0FF68D07393ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,

Pointer?

Thanks,

Sent from my iPad
Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarif= ication came from the original authors of the BFD protocol. The Echo Reply = is optional if there's no error to report. But if the remote LER, acting as= BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen <mach.chen@hua= wei.com> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by= it for
   the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach


--_000_983DC002121A48FA94A9D0FF68D07393ciscocom_-- From nobody Mon Jul 17 08:14:19 2017 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 A0CC0126D73 for ; Mon, 17 Jul 2017 08:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 MK2TkqeUQcK8 for ; Mon, 17 Jul 2017 08:14:16 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 049BF131C4D for ; Mon, 17 Jul 2017 08:14:07 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 21so33340709qtx.3 for ; Mon, 17 Jul 2017 08:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=haXW2egrPA2VbzSUI6WsMrQGt9A4ZS34ftjR5cR2DJk=; b=ubjTj+LB3IoXHM1bQjZo3mkwaQpg30vW43hJh0349l/Y/HgpsE4dHLrj2u7URe9aO5 L4QM3eE4tpjrdi8yh7W+8Xz7A5vs6X0xFNppnY3b7LgkeDx+T+Hv0QsVG1XzXLz6QBnS 6nL09DWJIcbs1svz0HHDMhFHu5XNgSJWqN/iJ5jCggIDsSpaymIBlfM6QXLGg7hiHYqe 9BFTSeoR5HrNUo/vv40Ru7j7XX1bK596WWb+dXGN8YShuZlxo7aDCKxnE9/+E4gLaisa SfdkevAYJIbw8PX4ZkKIdxzvxhfn1DLxeWFoC8fGGtWSGv+zPbbm04pUQ0FQKFk9cuw+ DPlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=haXW2egrPA2VbzSUI6WsMrQGt9A4ZS34ftjR5cR2DJk=; b=L73FzYtYEciOnu2sVeCPoFlwCQwgr9seDKgto56HPTzJTCWEVY9C9sChgeDm+o+9L8 mntbitr6NUMI4a5qVKed1vMM9PVppm4LQt2v71PoGou1ngbsjr+GC6YDG++Tv64/bVRg LkaDfVIT0gLqnRC8qYrO5DYB6/7uISjZ1Dj7081c//YJCqVzQ8jwoYIg9TlWv2tES7dI b/ywycI+olCO2arUUdT1mX9annripmRPPk4HbvH8ZuG8pog7z3OW7kSDiU1Nc5I3rJoj 1hMZu7jcsGCWkVbtS/2uRh/VJ52ioHltPebxQ84KpwMhNqJwhUhVctVbCXjrBGMJ9KfU BcMw== X-Gm-Message-State: AIVw110kWsAECJI6t04fy7ByHpSp9AG2HPa9kuoqsYTxK7KMJxZ5xO2T bZp596/B04ntiquTOrQx+0F8ktCxlQ== X-Received: by 10.237.45.67 with SMTP id h61mr27170674qtd.246.1500304445931; Mon, 17 Jul 2017 08:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Mon, 17 Jul 2017 08:14:05 -0700 (PDT) In-Reply-To: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> References: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> From: Greg Mirsky Date: Mon, 17 Jul 2017 08:14:05 -0700 Message-ID: Subject: Re: A question about RFC5884 To: "Carlos Pignataro (cpignata)" Cc: Mach Chen , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c124a888e0687055484d905" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:14:18 -0000 --94eb2c124a888e0687055484d905 Content-Type: text/plain; charset="UTF-8" Hi Carlos, it would take me time to dig that old discussion. I strongly believe that the wording and the order of listing actions in this paragraph of Section 6 RFC 5884 supports my interpretation and recollection of the discussion: On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds. This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR. Regards, Greg On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > Pointer? > > Thanks, > > Sent from my iPad > > On Jul 17, 2017, at 9:34 AM, Greg Mirsky wrote: > > Hi Mach, et. al, > I recall that this question was discussed some time ago and the > clarification came from the original authors of the BFD protocol. The Echo > Reply is optional if there's no error to report. But if the remote LER, > acting as BFD node, does decide to send the Echo Reply it MUST send it > after is sends the first BFD control message. > > Regards, > Greg > > On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen wrote: > >> Hi BFDers, >> >> We met a multi-vendor interoperate issue recently, it's about whether an >> Echo reply is necessary. >> >> In Section 6 of RFC5884, 2nd paragraph >> >> "... The egress LSR MAY respond with an LSP Ping Echo >> reply message that carries the local discriminator assigned by it for >> the BFD session." >> >> >From the above text, my understanding is that an Echo reply is optional, >> the egress LSR can freely to return or not return an Echo reply, and the >> Ingress LSR should not expect there MUST be an Echo reply, but if there is >> one, it should handle it properly. >> >> Is my understanding correct? >> >> Thanks, >> Mach >> >> > --94eb2c124a888e0687055484d905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
it would take me time to dig that old discu= ssion. I strongly believe that the wording and the order of listing actions= in this paragraph of Section 6 RFC 5884 supports my interpretation and rec= ollection of the discussion:
=
   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.


Regards,
Greg

On Mon, Ju= l 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarif= ication came from the original authors of the BFD protocol. The Echo Reply = is optional if there's no error to report. But if the remote LER, actin= g as BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen <mach.chen@hua= wei.com> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether a= n Echo reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
=C2=A0 =C2=A0reply message that carries the local discriminator assigned by= it for
=C2=A0 =C2=A0the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach



--94eb2c124a888e0687055484d905-- From nobody Mon Jul 17 08:30:53 2017 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 B21C7131C7D for ; Mon, 17 Jul 2017 08:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEvrx3E_yu90 for ; Mon, 17 Jul 2017 08:30:50 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D73131C80 for ; Mon, 17 Jul 2017 08:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9531; q=dns/txt; s=iport; t=1500305449; x=1501515049; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UVnx+JTbIGkdggRUeRACiYqfNR2jMyZViGPsAE338HM=; b=FTs7jpUyUWxog1mV4Zb/IeDXSerFKxlFmgufP2dE7nILbEDMVZ753JQU eu6u5Tj3QTx+nTwngJABZngojvrleGil3oUektyXenPekvdSGzNUHEX37 4MIsHdE6KYoeL7DUEJ8SI6k7I+jFwocAlPq/hPCbH8LhF5J8XCuONkF2o g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAADa1mxZ/5hdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9rgXiOC5oNiCqFLIIRhUcCg0Q/GAECAQEBAQEBAWsohRkGZxIQAgE?= =?us-ascii?q?IPwchERQRAQEEDgWJS0wDFbFlhy0Ng10BAQEBAQEBAQEBAQEBAQEBAQEBAQEdg?= =?us-ascii?q?yiDTYFhK4J5gTyBG4VWgjEFnnk7AosShBKEcJIvjAqJTAEfOIEKdRVbAYUMgXd?= =?us-ascii?q?2hk8rghIBAQE?= X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="456862888" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 15:30:48 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6HFUm0g025065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 15:30:48 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 11:30:48 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 11:30:48 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Mach Chen , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAtQzYAAAdCXesACMs6gP//wZ16 Date: Mon, 17 Jul 2017 15:30:47 +0000 Message-ID: <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com> References: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_0AC775096F044C6FA6EFEC9098048C84ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 15:30:52 -0000 --_000_0AC775096F044C6FA6EFEC9098048C84ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, I am sorry but I don't see how the paragraph supports what you say. Two iss= ues: 1. LSP Ping is based on the Normative reference's spec, RFC 4379. It cannot= go against it unless it updates its behavior. The following text: "The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." Also has the interpretation that Santosh shared, which is "MAY send a respo= nse including a TLV, but sending it is not optional" 2. You wrote a MUST in your reply with specific ordering of packet response= s. MUSTs are for interoperability. The text does not talk about order of pa= ckets. Where is that coming from? It is unhelpful to mention references without citing them, and in any case,= I do not believe the text supports your conclusion. Sent from my iPad On Jul 17, 2017, at 5:14 PM, Greg Mirsky > wrote: Hi Carlos, it would take me time to dig that old discussion. I strongly believe that t= he wording and the order of listing actions in this paragraph of Section 6 = RFC 5884 supports my interpretation and recollection of the discussion: On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR, if the validation of the FEC in the LSP Ping Echo request message succeeds. This BFD Control packet MUST set the Your Discriminator field to the discriminator received from the ingress LSR in the LSP Ping Echo request message. The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session. The local discriminator assigned by the egress LSR MUST be used as the My Discriminator field in the BFD session packets sent by the egress LSR. Regards, Greg On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) > wrote: Greg, Pointer? Thanks, Sent from my iPad On Jul 17, 2017, at 9:34 AM, Greg Mirsky > wrote: Hi Mach, et. al, I recall that this question was discussed some time ago and the clarificati= on came from the original authors of the BFD protocol. The Echo Reply is op= tional if there's no error to report. But if the remote LER, acting as BFD = node, does decide to send the Echo Reply it MUST send it after is sends the= first BFD control message. Regards, Greg On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen > wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, t= he egress LSR can freely to return or not return an Echo reply, and the Ing= ress LSR should not expect there MUST be an Echo reply, but if there is one= , it should handle it properly. Is my understanding correct? Thanks, Mach --_000_0AC775096F044C6FA6EFEC9098048C84ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,

I am sorry but I don't see how the paragraph= supports what you say. Two issues:

1. LSP Ping is based on the Normative refere= nce's spec, RFC 4379. It cannot go against it unless it updates its behavio= r. The following text:

"The egress LSR MAY respond with an LSP Ping Echo=
reply message that carries the local discriminator assigned b= y it for 
   the BFD session."

Also has the inte= rpretation that Santosh shared, which is "MAY send a response includin= g a TLV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet response= s. MUSTs are for interoperability. The text does not talk about order of pa= ckets. Where is that coming from?

It is unhelpful to mention references withou= t citing them, and in any case, I do not believe the text supports your con= clusion. 

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe t= hat the wording and the order of listing actions in this paragraph of Secti= on 6 RFC 5884 supports my interpretation and recollection of the discussion= :
   On receipt of the LSP Ping Echo reques=
t message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.  This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.


Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarif= ication came from the original authors of the BFD protocol. The Echo Reply = is optional if there's no error to report. But if the remote LER, acting as= BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen <mach.chen@hua= wei.com> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Ec= ho reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by= it for
   the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach



--_000_0AC775096F044C6FA6EFEC9098048C84ciscocom_-- From nobody Mon Jul 17 09:02:19 2017 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 023CA131C95 for ; Mon, 17 Jul 2017 09:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1Eg-TT4_Upy3 for ; Mon, 17 Jul 2017 09:02:16 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 05E44131C91 for ; Mon, 17 Jul 2017 09:02:16 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id b40so109905603qtb.2 for ; Mon, 17 Jul 2017 09:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jyL9MxwGTcMzRxcn3+3au0spB92Wo7Lt8J2bpSumIhE=; b=Vn1zHs9oAewX7AzXR6+0RDAjKKXf4ZU/ZSLzVV5+7tZSPQzYxQc4GrpQKIlPD04ReH D5oTt+K2YAohB44rAPlzPfSe3vIwk+ef1HEImX9my64xJjZmLlIwce6vRXZv6yeLWgDY HNDdnDHv1bWJhXxArhig0nZBCwIlXphRGkWI39en0IssUj3bfNV4JWWm0p/oA3XGwVdD 51ncMYurLMEm8goYXufV3PXkQ0pK37zyT+rtKoPohMQkRt1rkhwlSUxyEWhCs1lX15Pb BkpQU1GgI/9CpvUKtrvmWVnOAUcteUXI+2AUjqvUcAgOR38tpibKYlVwXiVXaKtWN+FE HTdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jyL9MxwGTcMzRxcn3+3au0spB92Wo7Lt8J2bpSumIhE=; b=cOjCj3S3lIEgfcLYmOT483jbeo8sUB7fe182j0DG+IKyA/XInPa6i0DcfrZHrD8RGR O3uinp0XLcO9qc1PoP456V9VThS5wIa/z+NUmpRSNKR8owqJxS/ZscYWfeuUi6q3y0cN sLqqMLqXruAoGW/LRzHBOSlpxROlH1dIL5I8AHSLUcui9DpWXSzneittQqDPqq+4Zsve kSJ79QFZkR6Q4zpyGdDBGaZbAhJnSOkfwqJmWcYD3DhN5pQmjJ1eaG02y3bNZmNwa7xj o6yR5fDF4R4qi4dQwULFmd+7yQxXkiO7VXx1Tjgn1RSfLfIMc/I2oFkpcldjyuXN+NwC y8Gg== X-Gm-Message-State: AIVw11069nAWm4ZhpePzbc0XOPPqIi64sGeOJPV6n9uqwme0JEtPxrI4 g0o+a3GNO8/U6bg4oQ4Rt/Hwsjhhag== X-Received: by 10.237.62.240 with SMTP id o45mr5362103qtf.233.1500307334999; Mon, 17 Jul 2017 09:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.227 with HTTP; Mon, 17 Jul 2017 09:02:14 -0700 (PDT) In-Reply-To: <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com> References: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com> From: Greg Mirsky Date: Mon, 17 Jul 2017 09:02:14 -0700 Message-ID: Subject: Re: A question about RFC5884 To: "Carlos Pignataro (cpignata)" Cc: Mach Chen , "rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="001a1142a4eac1b0960554858574" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:02:18 -0000 --001a1142a4eac1b0960554858574 Content-Type: text/plain; charset="UTF-8" Hi Carlos, please find in-lined interpretation of RFC 5884 paragraph tagged GIM>>. Regards, Greg On Mon, Jul 17, 2017 at 8:30 AM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Greg, > > I am sorry but I don't see how the paragraph supports what you say. Two > issues: > > 1. LSP Ping is based on the Normative reference's spec, RFC 4379. It > cannot go against it unless it updates its behavior. The following text: > > "The egress LSR MAY respond with an LSP Ping Echo > reply message that carries the local discriminator assigned by it for > the BFD session." > > Also has the interpretation that Santosh shared, which is "MAY send a > response including a TLV, but sending it is not optional" > > 2. You wrote a MUST in your reply with specific ordering of packet > responses. MUSTs are for interoperability. The text does not talk about > order of packets. Where is that coming from? > > It is unhelpful to mention references without citing them, and in any > case, I do not believe the text supports your conclusion. > > Sent from my iPad > > On Jul 17, 2017, at 5:14 PM, Greg Mirsky wrote: > > Hi Carlos, > it would take me time to dig that old discussion. I strongly believe that > the wording and the order of listing actions in this paragraph of Section 6 > RFC 5884 supports my interpretation and recollection of the discussion: > > On receipt of the LSP Ping Echo request message, the egress LSR MUST > send a BFD Control packet to the ingress LSR, if the validation of > the FEC in the LSP Ping Echo request message succeeds. > > GIM>> The LSP Ping Echo is validated. If the validation fails, then the LSP Echo Reply MUST be sent with the appropriate Return Code. If the validation succeeds, then the BFD control packet MUST be sent. > This BFD > Control packet MUST set the Your Discriminator field to the > discriminator received from the ingress LSR in the LSP Ping Echo > request message. > > GIM>> This describes how Your Discriminator field of the BFD control packet to be transmitted by the egress LSR MUST be populated as it will be used by the ingress LSR to demultiplex BFD sessions.. > The egress LSR MAY respond with an LSP Ping Echo > reply message that carries the local discriminator assigned by it for > the BFD session. > > GIM>> After the egress LSR is done with sending the first BFD control packet it MAY send LSP Ping Echo reply with already allocated and included in BFD control packet My Discriminator as value of BFD Discriminator TLV. > The local discriminator assigned by the egress LSR > MUST be used as the My Discriminator field in the BFD session packets > sent by the egress LSR. > > > > Regards, > Greg > > On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Greg, >> >> Pointer? >> >> Thanks, >> >> Sent from my iPad >> >> On Jul 17, 2017, at 9:34 AM, Greg Mirsky wrote: >> >> Hi Mach, et. al, >> I recall that this question was discussed some time ago and the >> clarification came from the original authors of the BFD protocol. The Echo >> Reply is optional if there's no error to report. But if the remote LER, >> acting as BFD node, does decide to send the Echo Reply it MUST send it >> after is sends the first BFD control message. >> >> Regards, >> Greg >> >> On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen wrote: >> >>> Hi BFDers, >>> >>> We met a multi-vendor interoperate issue recently, it's about whether an >>> Echo reply is necessary. >>> >>> In Section 6 of RFC5884, 2nd paragraph >>> >>> "... The egress LSR MAY respond with an LSP Ping Echo >>> reply message that carries the local discriminator assigned by it for >>> the BFD session." >>> >>> >From the above text, my understanding is that an Echo reply is >>> optional, the egress LSR can freely to return or not return an Echo reply, >>> and the Ingress LSR should not expect there MUST be an Echo reply, but if >>> there is one, it should handle it properly. >>> >>> Is my understanding correct? >>> >>> Thanks, >>> Mach >>> >>> >> > --001a1142a4eac1b0960554858574 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
please find in-lined interpretation of RFC = 5884 paragraph tagged GIM>>.

Regards,
<= div>Greg

On = Mon, Jul 17, 2017 at 8:30 AM, Carlos Pignataro (cpignata) <cpignata@cisco= .com> wrote:
Greg,

I am sorry but I don= 9;t see how the paragraph supports what you say. Two issues:

1. LSP Ping is based on= the Normative reference's spec, RFC 4379. It cannot go against it unle= ss it updates its behavior. The following text:

"The egress LSR MAY respond with an LSP = Ping Echo
reply message that carries the local discrimi= nator assigned by it for=C2=A0
=C2=A0 =C2=A0the BFD session.&q= uot;

Also has the interpret= ation that Santosh shared, which is "MAY send a response including a T= LV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet response= s. MUSTs are for interoperability. The text does not talk about order of pa= ckets. Where is that coming from?

It is unhelpful to ment= ion references without citing them, and in any case, I do not believe the t= ext supports your conclusion.=C2=A0

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe t= hat the wording and the order of listing actions in this paragraph of Secti= on 6 RFC 5884 supports my interpretation and recollection of the discussion= :
   On receipt of the=
 LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.
GIM>= ;> The LSP Ping Echo is validated. If the validation fails, then the LSP= Echo Reply MUST be sent with the appropriate Return Code. If the validatio= n succeeds, then the BFD control packet MUST be sent.=C2=A0
This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.
<= /div>
GIM>> This describes how Your Discrimina= tor field of the BFD control packet to be transmitted by the egress LSR MUS= T be populated as it will be used by the ingress LSR to demultiplex BFD ses= sions..=C2=A0
<= div>
  The egress LSR=
 MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.
GIM>> After the egress LSR is done wit= h sending the first BFD control packet it MAY send LSP Ping Echo reply with= already allocated and included in BFD control packet My Discriminator as v= alue of BFD Discriminator TLV.=C2=A0
= 
The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.


Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignatar= o (cpignata) <cpignata@cisco.com> wrote:
Greg,
<= br>
P= ointer?
<= br>
T= hanks,
<= br> Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarif= ication came from the original authors of the BFD protocol. The Echo Reply = is optional if there's no error to report. But if the remote LER, actin= g as BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen <mach.chen@hua= wei.com> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether a= n Echo reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

"... The egress LSR MAY respond with an LSP Ping Echo
=C2=A0 =C2=A0reply message that carries the local discriminator assigned by= it for
=C2=A0 =C2=A0the BFD session."

>From the above text, my understanding is that an Echo reply is optional= , the egress LSR can freely to return or not return an Echo reply, and the = Ingress LSR should not expect there MUST be an Echo reply, but if there is = one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach




--001a1142a4eac1b0960554858574-- From nobody Mon Jul 17 09:43:02 2017 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 227F4131B4F for ; Mon, 17 Jul 2017 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 MhHU8SPEhBeS for ; Mon, 17 Jul 2017 09:42:59 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002081.outbound.protection.outlook.com [40.92.2.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08924131B33 for ; Mon, 17 Jul 2017 09:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1yzd+OGfAM1H/jbejr+tr46W3pwgzXkBFF7mMLOxAuc=; b=JF3JZoTHhcXEmCjLENyKBP3Uxog8ay9lw1g3h66ByNCiv7gOW0T+i3Eund7XCPLGwP5XHq0VFzXR1739QfB0Tyc9oH033M/SMQpf3KDjMPviIEQtqDNPSOJDwKrM/br/+MgCPwan3DTkcMbWyeuqaC8njH/n1i7pOTJdYhfJu/ii0suoMfoIxaVPB5UYHD8HObbD+BwYUqMTG7LOLU3ze5/lx3xR+KPdE0nwQMihyrOp2NHMw9bpMVe1ifBwdy6O2t7UQoWpvZ/4AaAw2ML76gjspv328aNswkKVdc6GeivYg24i/Xm4w/6Hc2PI2V1iq0r10qz73lAiV0/ToAit8A== Received: from BN3NAM01FT009.eop-nam01.prod.protection.outlook.com (10.152.66.59) by BN3NAM01HT151.eop-nam01.prod.protection.outlook.com (10.152.67.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Mon, 17 Jul 2017 16:42:57 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com (10.152.66.56) by BN3NAM01FT009.mail.protection.outlook.com (10.152.67.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.9 via Frontend Transport; Mon, 17 Jul 2017 16:42:57 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) by MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 16:42:57 +0000 From: Ashesh Mishra To: Greg Mirsky CC: "Carlos Pignataro (cpignata)" , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAk4XEAAA+kGIAAAGmAgAAAlU+AAAEZLwAAAWv1XA== Date: Mon, 17 Jul 2017 16:42:56 +0000 Message-ID: References: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:5CAD7B12E26243FCC98B7234948686DB99DB022489250325E47641F4880FBE25; UpperCasedChecksum:40223EE44845D52F77C0D04A076CC439FEA9569864EFF5E4E70C008BCCD5C126; SizeAsReceived:7605; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tVPYjT2FBmJ0A1KfqXxARaoOFX/g0Ru6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT151; 7:R9IeFxP/5ehb2HHia9AIebB1VcpmSjGF7AxFdfnXpFeOtdnZo+qex89A9yzOEGrL6GsA8LwbpwrzfvPVuJhq2khgSzCRvyaUiWRB1Xoo8M+qcTC51nq7bZcsJrFqAg629RwcyBq0x7Dllq8Hn2IiyQ8VXKBr9oodWQQXpkj5nkZ78ZQ5NBUAn8eCa9eGWd8vP0CSfZUpt0h61dUQEHQ9tMnsDm0SaOJzxkqqM2dkWHLwmOEsr8E8mndfnkdYBkCUtL1la/0jonUSfX8dlJmeWKYmNXWe3YVvdTFhIXH+MYyhucu+MVs+zEJupaGHxmjukW9xmpy3N2yF+yn5sSa9nzbZXpSEHu5pSFuxrKMUJEJfGeH6EeSOUJc1POnzW6Ip7tnAq/+YrSBC27wn5XaVHi/qu2tX3RFIFkW78jUYmRTmowz5l3D6UaiWEgDqVc+1RO40LWLfqo2Os84L5wAt97DrfeulU/GOvmUetUhTKliv0sNnjFxywwFIjtmW1Yz/uNKTE2G1L3zpPoBayOYWbFJTujXFahTakcCmv7WQQcfnV+4kmOLVSdPk1NxY39lXfpUJCOIaaQQxN3UxQo8q1NF+qnOw9M29sPhUJtcbKKuoC0bkqBOw/vYnlegBcFR0O2Dd1J04MojPZNv/UjSSGr9gNtblslIPM/AsBlSWg0J6uUbR15ZHulfOVnsdwLdVlZQbuDOKJgrRTFDdgWDYuKLtZQQd4mqTpMGjcGzoG4ZL+RvBp7nhYxOgFz4++1iieuj2meC9TtkCvHPw9r/snQ== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT151; H:MWHPR01MB2768.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: ed223f61-1a87-4c73-7899-08d4cd32e0e6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3NAM01HT151; x-ms-traffictypediagnostic: BN3NAM01HT151: x-exchange-antispam-report-test: UriScan:(236129657087228)(50582790962513)(48057245064654)(95692535739014)(50300203121483)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM01HT151; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM01HT151; x-forefront-prvs: 0371762FE7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR01MB276889C67A8EC60475562027FAA00MWHPR01MB2768prod_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 16:42:57.0091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT151 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 16:43:01 -0000 --_000_MWHPR01MB276889C67A8EC60475562027FAA00MWHPR01MB2768prod_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZywNCg0KUmU6IGZvbGxvd2luZyBzZWN0aW9uDQoNCg0KT24gcmVjZWlwdCBvZiB0aGUgTFNQ IFBpbmcgRWNobyByZXF1ZXN0IG1lc3NhZ2UsIHRoZSBlZ3Jlc3MgTFNSIE1VU1QNCiAgIHNlbmQg YSBCRkQgQ29udHJvbCBwYWNrZXQgdG8gdGhlIGluZ3Jlc3MgTFNSLCBpZiB0aGUgdmFsaWRhdGlv biBvZg0KICAgdGhlIEZFQyBpbiB0aGUgTFNQIFBpbmcgRWNobyByZXF1ZXN0IG1lc3NhZ2Ugc3Vj Y2VlZHMuDQoNCkdJTT4+IFRoZSBMU1AgUGluZyBFY2hvIGlzIHZhbGlkYXRlZC4gSWYgdGhlIHZh bGlkYXRpb24gZmFpbHMsIHRoZW4gdGhlIExTUCBFY2hvIFJlcGx5IE1VU1QgYmUgc2VudCB3aXRo IHRoZSBhcHByb3ByaWF0ZSBSZXR1cm4gQ29kZS4gSWYgdGhlIHZhbGlkYXRpb24gc3VjY2VlZHMs IHRoZW4gdGhlIEJGRCBjb250cm9sIHBhY2tldCBNVVNUIGJlIHNlbnQuDQoNClRoZSBNVVNUIGlu IHRoZSBSRkMgaXMgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGEgQkZEIGNvbnRyb2wgcGFja2V0IGFu ZCBub3QgZWNobyByZXBseS4NCg0KQXNoZXNoDQoNCk9uIEp1bCAxNywgMjAxNywgYXQgNjowMiBQ TSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lA Z21haWwuY29tPj4gd3JvdGU6DQoNCkhpIENhcmxvcywNCnBsZWFzZSBmaW5kIGluLWxpbmVkIGlu dGVycHJldGF0aW9uIG9mIFJGQyA1ODg0IHBhcmFncmFwaCB0YWdnZWQgR0lNPj4uDQoNClJlZ2Fy ZHMsDQpHcmVnDQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDg6MzAgQU0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNj by5jb20+PiB3cm90ZToNCkdyZWcsDQoNCkkgYW0gc29ycnkgYnV0IEkgZG9uJ3Qgc2VlIGhvdyB0 aGUgcGFyYWdyYXBoIHN1cHBvcnRzIHdoYXQgeW91IHNheS4gVHdvIGlzc3VlczoNCg0KMS4gTFNQ IFBpbmcgaXMgYmFzZWQgb24gdGhlIE5vcm1hdGl2ZSByZWZlcmVuY2UncyBzcGVjLCBSRkMgNDM3 OS4gSXQgY2Fubm90IGdvIGFnYWluc3QgaXQgdW5sZXNzIGl0IHVwZGF0ZXMgaXRzIGJlaGF2aW9y LiBUaGUgZm9sbG93aW5nIHRleHQ6DQoNCiJUaGUgZWdyZXNzIExTUiBNQVkgcmVzcG9uZCB3aXRo IGFuIExTUCBQaW5nIEVjaG8NCnJlcGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2NhbCBk aXNjcmltaW5hdG9yIGFzc2lnbmVkIGJ5IGl0IGZvcg0KICAgdGhlIEJGRCBzZXNzaW9uLiINCg0K QWxzbyBoYXMgdGhlIGludGVycHJldGF0aW9uIHRoYXQgU2FudG9zaCBzaGFyZWQsIHdoaWNoIGlz ICJNQVkgc2VuZCBhIHJlc3BvbnNlIGluY2x1ZGluZyBhIFRMViwgYnV0IHNlbmRpbmcgaXQgaXMg bm90IG9wdGlvbmFsIg0KDQoyLiBZb3Ugd3JvdGUgYSBNVVNUIGluIHlvdXIgcmVwbHkgd2l0aCBz cGVjaWZpYyBvcmRlcmluZyBvZiBwYWNrZXQgcmVzcG9uc2VzLiBNVVNUcyBhcmUgZm9yIGludGVy b3BlcmFiaWxpdHkuIFRoZSB0ZXh0IGRvZXMgbm90IHRhbGsgYWJvdXQgb3JkZXIgb2YgcGFja2V0 cy4gV2hlcmUgaXMgdGhhdCBjb21pbmcgZnJvbT8NCg0KSXQgaXMgdW5oZWxwZnVsIHRvIG1lbnRp b24gcmVmZXJlbmNlcyB3aXRob3V0IGNpdGluZyB0aGVtLCBhbmQgaW4gYW55IGNhc2UsIEkgZG8g bm90IGJlbGlldmUgdGhlIHRleHQgc3VwcG9ydHMgeW91ciBjb25jbHVzaW9uLg0KDQpTZW50IGZy b20gbXkgaVBhZA0KDQpPbiBKdWwgMTcsIDIwMTcsIGF0IDU6MTQgUE0sIEdyZWcgTWlyc2t5IDxn cmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQpIaSBDYXJsb3MsDQppdCB3b3VsZCB0YWtlIG1lIHRpbWUgdG8gZGlnIHRoYXQgb2xkIGRp c2N1c3Npb24uIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGF0IHRoZSB3b3JkaW5nIGFuZCB0aGUgb3Jk ZXIgb2YgbGlzdGluZyBhY3Rpb25zIGluIHRoaXMgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNiBSRkMg NTg4NCBzdXBwb3J0cyBteSBpbnRlcnByZXRhdGlvbiBhbmQgcmVjb2xsZWN0aW9uIG9mIHRoZSBk aXNjdXNzaW9uOg0KDQogICBPbiByZWNlaXB0IG9mIHRoZSBMU1AgUGluZyBFY2hvIHJlcXVlc3Qg bWVzc2FnZSwgdGhlIGVncmVzcyBMU1IgTVVTVA0KICAgc2VuZCBhIEJGRCBDb250cm9sIHBhY2tl dCB0byB0aGUgaW5ncmVzcyBMU1IsIGlmIHRoZSB2YWxpZGF0aW9uIG9mDQogICB0aGUgRkVDIGlu IHRoZSBMU1AgUGluZyBFY2hvIHJlcXVlc3QgbWVzc2FnZSBzdWNjZWVkcy4NCg0KR0lNPj4gVGhl IExTUCBQaW5nIEVjaG8gaXMgdmFsaWRhdGVkLiBJZiB0aGUgdmFsaWRhdGlvbiBmYWlscywgdGhl biB0aGUgTFNQIEVjaG8gUmVwbHkgTVVTVCBiZSBzZW50IHdpdGggdGhlIGFwcHJvcHJpYXRlIFJl dHVybiBDb2RlLiBJZiB0aGUgdmFsaWRhdGlvbiBzdWNjZWVkcywgdGhlbiB0aGUgQkZEIGNvbnRy b2wgcGFja2V0IE1VU1QgYmUgc2VudC4NCg0KVGhpcyBCRkQNCiAgIENvbnRyb2wgcGFja2V0IE1V U1Qgc2V0IHRoZSBZb3VyIERpc2NyaW1pbmF0b3IgZmllbGQgdG8gdGhlDQogICBkaXNjcmltaW5h dG9yIHJlY2VpdmVkIGZyb20gdGhlIGluZ3Jlc3MgTFNSIGluIHRoZSBMU1AgUGluZyBFY2hvDQog ICByZXF1ZXN0IG1lc3NhZ2UuDQoNCkdJTT4+IFRoaXMgZGVzY3JpYmVzIGhvdyBZb3VyIERpc2Ny aW1pbmF0b3IgZmllbGQgb2YgdGhlIEJGRCBjb250cm9sIHBhY2tldCB0byBiZSB0cmFuc21pdHRl ZCBieSB0aGUgZWdyZXNzIExTUiBNVVNUIGJlIHBvcHVsYXRlZCBhcyBpdCB3aWxsIGJlIHVzZWQg YnkgdGhlIGluZ3Jlc3MgTFNSIHRvIGRlbXVsdGlwbGV4IEJGRCBzZXNzaW9ucy4uDQoNCiAgVGhl IGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvDQogICByZXBseSBt ZXNzYWdlIHRoYXQgY2FycmllcyB0aGUgbG9jYWwgZGlzY3JpbWluYXRvciBhc3NpZ25lZCBieSBp dCBmb3INCiAgIHRoZSBCRkQgc2Vzc2lvbi4NCg0KR0lNPj4gQWZ0ZXIgdGhlIGVncmVzcyBMU1Ig aXMgZG9uZSB3aXRoIHNlbmRpbmcgdGhlIGZpcnN0IEJGRCBjb250cm9sIHBhY2tldCBpdCBNQVkg c2VuZCBMU1AgUGluZyBFY2hvIHJlcGx5IHdpdGggYWxyZWFkeSBhbGxvY2F0ZWQgYW5kIGluY2x1 ZGVkIGluIEJGRCBjb250cm9sIHBhY2tldCBNeSBEaXNjcmltaW5hdG9yIGFzIHZhbHVlIG9mIEJG RCBEaXNjcmltaW5hdG9yIFRMVi4NCg0KVGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgYXNzaWduZWQg YnkgdGhlIGVncmVzcyBMU1INCiAgIE1VU1QgYmUgdXNlZCBhcyB0aGUgTXkgRGlzY3JpbWluYXRv ciBmaWVsZCBpbiB0aGUgQkZEIHNlc3Npb24gcGFja2V0cw0KICAgc2VudCBieSB0aGUgZWdyZXNz IExTUi4NCg0KDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDg6 MDIgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1h aWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCkdyZWcsDQoNClBvaW50ZXI/DQoNClRo YW5rcywNCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gSnVsIDE3LCAyMDE3LCBhdCA5OjM0IEFN LCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBn bWFpbC5jb20+PiB3cm90ZToNCg0KSGkgTWFjaCwgZXQuIGFsLA0KSSByZWNhbGwgdGhhdCB0aGlz IHF1ZXN0aW9uIHdhcyBkaXNjdXNzZWQgc29tZSB0aW1lIGFnbyBhbmQgdGhlIGNsYXJpZmljYXRp b24gY2FtZSBmcm9tIHRoZSBvcmlnaW5hbCBhdXRob3JzIG9mIHRoZSBCRkQgcHJvdG9jb2wuIFRo ZSBFY2hvIFJlcGx5IGlzIG9wdGlvbmFsIGlmIHRoZXJlJ3Mgbm8gZXJyb3IgdG8gcmVwb3J0LiBC dXQgaWYgdGhlIHJlbW90ZSBMRVIsIGFjdGluZyBhcyBCRkQgbm9kZSwgZG9lcyBkZWNpZGUgdG8g c2VuZCB0aGUgRWNobyBSZXBseSBpdCBNVVNUIHNlbmQgaXQgYWZ0ZXIgaXMgc2VuZHMgdGhlIGZp cnN0IEJGRCBjb250cm9sIG1lc3NhZ2UuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIFN1biwgSnVs IDE2LCAyMDE3IGF0IDY6NTggQU0sIE1hY2ggQ2hlbiA8bWFjaC5jaGVuQGh1YXdlaS5jb208bWFp bHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBCRkRlcnMsDQoNCldlIG1ldCBh IG11bHRpLXZlbmRvciBpbnRlcm9wZXJhdGUgaXNzdWUgcmVjZW50bHksIGl0J3MgYWJvdXQgd2hl dGhlciBhbiBFY2hvIHJlcGx5IGlzIG5lY2Vzc2FyeS4NCg0KSW4gU2VjdGlvbiA2IG9mIFJGQzU4 ODQsIDJuZCBwYXJhZ3JhcGgNCg0KIi4uLiBUaGUgZWdyZXNzIExTUiBNQVkgcmVzcG9uZCB3aXRo IGFuIExTUCBQaW5nIEVjaG8NCiAgIHJlcGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2Nh bCBkaXNjcmltaW5hdG9yIGFzc2lnbmVkIGJ5IGl0IGZvcg0KICAgdGhlIEJGRCBzZXNzaW9uLiIN Cg0KPkZyb20gdGhlIGFib3ZlIHRleHQsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBhbiBFY2hv IHJlcGx5IGlzIG9wdGlvbmFsLCB0aGUgZWdyZXNzIExTUiBjYW4gZnJlZWx5IHRvIHJldHVybiBv ciBub3QgcmV0dXJuIGFuIEVjaG8gcmVwbHksIGFuZCB0aGUgSW5ncmVzcyBMU1Igc2hvdWxkIG5v dCBleHBlY3QgdGhlcmUgTVVTVCBiZSBhbiBFY2hvIHJlcGx5LCBidXQgaWYgdGhlcmUgaXMgb25l LCBpdCBzaG91bGQgaGFuZGxlIGl0IHByb3Blcmx5Lg0KDQpJcyBteSB1bmRlcnN0YW5kaW5nIGNv cnJlY3Q/DQoNClRoYW5rcywNCk1hY2gNCg0KDQoNCg0K --_000_MWHPR01MB276889C67A8EC60475562027FAA00MWHPR01MB2768prod_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj5HcmVnLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmU6 IGZvbGxvd2luZyBzZWN0aW9uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQs IDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGNsYXNz PSJoNSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPHByZSBj bGFzcz0ibV8yOTU5NDQyNTg5OTkxNDMyMDM0Z21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyI+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBw eCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRp bmctbGVmdDogMWV4OyI+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPHByZSBjbGFzcz0ibV8yOTU5 NDQyNTg5OTkxNDMyMDM0Z21haWwtbmV3cGFnZSIgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlVJQ1RGb250VGV4 dFN0eWxlQm9keSI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48aT5PbiByZWNlaXB0IG9mIHRoZSBMU1Ag UGluZyBFY2hvIHJlcXVlc3QgbWVzc2FnZSwgdGhlIGVncmVzcyBMU1IgTVVTVA0KICAgc2VuZCBh IEJGRCBDb250cm9sIHBhY2tldCB0byB0aGUgaW5ncmVzcyBMU1IsIGlmIHRoZSB2YWxpZGF0aW9u IG9mDQogICB0aGUgRkVDIGluIHRoZSBMU1AgUGluZyBFY2hvIHJlcXVlc3QgbWVzc2FnZSBzdWNj ZWVkcy4gIDwvaT48L3NwYW4+PC9mb250PjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxpPkdJTSZndDsmZ3Q7IFRoZSBMU1Ag UGluZyBFY2hvIGlzIHZhbGlkYXRlZC4gSWYgdGhlIHZhbGlkYXRpb24gZmFpbHMsIHRoZW4gdGhl IExTUCBFY2hvIFJlcGx5IE1VU1QgYmUgc2VudCB3aXRoIHRoZSBhcHByb3ByaWF0ZSBSZXR1cm4g Q29kZS4gSWYgdGhlIHZhbGlkYXRpb24gc3VjY2VlZHMsIHRoZW4gdGhlIEJGRCBjb250cm9sIHBh Y2tldCBNVVNUDQogYmUgc2VudDwvaT4uJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1 LCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQt Y29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5UaGUgTVVTVCBpbiB0aGUgUkZDIGlzIGZv ciB0aGUgZ2VuZXJhdGlvbiBvZiBhIEJGRCBjb250cm9sIHBhY2tldCBhbmQgbm90IGVjaG8gcmVw bHkuJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNw YW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5Bc2hl c2g8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj48YnI+DQpPbiBKdWwgMTcsIDIwMTcsIGF0IDY6MDIgUE0sIEdyZWcgTWlyc2t5ICZsdDs8 YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIj5ncmVnaW1pcnNreUBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRy Ij5IaSBDYXJsb3MsDQo8ZGl2PnBsZWFzZSBmaW5kIGluLWxpbmVkIGludGVycHJldGF0aW9uIG9m IFJGQyA1ODg0IHBhcmFncmFwaCB0YWdnZWQgR0lNJmd0OyZndDsuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRpdj5HcmVnPC9kaXY+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1vbiwgSnVs IDE3LCAyMDE3IGF0IDg6MzAgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKQ0KPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj48c3Bhbj48L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdj48c3Bhbj48L3NwYW4+ PC9kaXY+DQo8ZGl2Pg0KPGRpdj5HcmVnLDwvZGl2Pg0KPGRpdiBpZD0ibV8yOTU5NDQyNTg5OTkx NDMyMDM0QXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjk1OTQ0 MjU4OTk5MTQzMjAzNEFwcGxlTWFpbFNpZ25hdHVyZSI+SSBhbSBzb3JyeSBidXQgSSBkb24ndCBz ZWUgaG93IHRoZSBwYXJhZ3JhcGggc3VwcG9ydHMgd2hhdCB5b3Ugc2F5LiBUd28gaXNzdWVzOjwv ZGl2Pg0KPGRpdiBpZD0ibV8yOTU5NDQyNTg5OTkxNDMyMDM0QXBwbGVNYWlsU2lnbmF0dXJlIj48 YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNEFwcGxlTWFpbFNpZ25h dHVyZSI+MS4gTFNQIFBpbmcgaXMgYmFzZWQgb24gdGhlIE5vcm1hdGl2ZSByZWZlcmVuY2UncyBz cGVjLCBSRkMgNDM3OS4gSXQgY2Fubm90IGdvIGFnYWluc3QgaXQgdW5sZXNzIGl0IHVwZGF0ZXMg aXRzIGJlaGF2aW9yLiBUaGUgZm9sbG93aW5nIHRleHQ6PC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4N CjxkaXYgaWQ9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNEFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRBcHBsZU1haWxTaWduYXR1cmUi PiZxdW90OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1LDI1NSwyNTUsMCki PlRoZSBlZ3Jlc3MgTFNSIE1BWSByZXNwb25kIHdpdGggYW4gTFNQIFBpbmcgRWNobzwvc3Bhbj48 L2Rpdj4NCjxkaXYgaWQ9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNEFwcGxlTWFpbFNpZ25hdHVyZSI+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSwwKSI+cmVwbHkg bWVzc2FnZSB0aGF0IGNhcnJpZXMgdGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgYXNzaWduZWQgYnkg aXQgZm9yJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBpZD0ibV8yOTU5NDQyNTg5 OTkxNDMyMDM0QXBwbGVNYWlsU2lnbmF0dXJlIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjpyZ2JhKDI1NSwyNTUsMjU1LDApIj4mbmJzcDsgJm5ic3A7dGhlIEJGRCBzZXNzaW9uLjwvc3Bh bj4mcXVvdDs8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1 NSwyNTUsMjU1LDApIj5BbHNvIGhhcyB0aGUgaW50ZXJwcmV0YXRpb24gdGhhdCBTYW50b3NoIHNo YXJlZCwgd2hpY2ggaXMgJnF1b3Q7TUFZIHNlbmQgYSByZXNwb25zZSBpbmNsdWRpbmcgYSBUTFYs IGJ1dCBzZW5kaW5nIGl0IGlzIG5vdCBvcHRpb25hbCZxdW90Ozwvc3Bhbj48YnI+DQo8YnI+DQoy LiBZb3Ugd3JvdGUgYSBNVVNUIGluIHlvdXIgcmVwbHkgd2l0aCBzcGVjaWZpYyBvcmRlcmluZyBv ZiBwYWNrZXQgcmVzcG9uc2VzLiBNVVNUcyBhcmUgZm9yIGludGVyb3BlcmFiaWxpdHkuIFRoZSB0 ZXh0IGRvZXMgbm90IHRhbGsgYWJvdXQgb3JkZXIgb2YgcGFja2V0cy4gV2hlcmUgaXMgdGhhdCBj b21pbmcgZnJvbT88L2Rpdj4NCjxkaXYgaWQ9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNEFwcGxlTWFp bFNpZ25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRB cHBsZU1haWxTaWduYXR1cmUiPkl0IGlzIHVuaGVscGZ1bCB0byBtZW50aW9uIHJlZmVyZW5jZXMg d2l0aG91dCBjaXRpbmcgdGhlbSwgYW5kIGluIGFueSBjYXNlLCBJIGRvIG5vdCBiZWxpZXZlIHRo ZSB0ZXh0IHN1cHBvcnRzIHlvdXIgY29uY2x1c2lvbi4mbmJzcDs8YnI+DQo8YnI+DQpTZW50IGZy b20gbXkgaVBhZDwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KT24g SnVsIDE3LCAyMDE3LCBhdCA1OjE0IFBNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+SGkgQ2FybG9zLA0KPGRpdj5pdCB3b3VsZCB0 YWtlIG1lIHRpbWUgdG8gZGlnIHRoYXQgb2xkIGRpc2N1c3Npb24uIEkgc3Ryb25nbHkgYmVsaWV2 ZSB0aGF0IHRoZSB3b3JkaW5nIGFuZCB0aGUgb3JkZXIgb2YgbGlzdGluZyBhY3Rpb25zIGluIHRo aXMgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNiBSRkMgNTg4NCBzdXBwb3J0cyBteSBpbnRlcnByZXRh dGlvbiBhbmQgcmVjb2xsZWN0aW9uIG9mIHRoZSBkaXNjdXNzaW9uOjwvZGl2Pg0KPGRpdj4NCjxw cmUgY2xhc3M9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNGdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250 LXNpemU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJn YigwLDAsMCkiPiAgIE9uIHJlY2VpcHQgb2YgdGhlIExTUCBQaW5nIEVjaG8gcmVxdWVzdCBtZXNz YWdlLCB0aGUgZWdyZXNzIExTUiBNVVNUDQogICBzZW5kIGEgQkZEIENvbnRyb2wgcGFja2V0IHRv IHRoZSBpbmdyZXNzIExTUiwgaWYgdGhlIHZhbGlkYXRpb24gb2YNCiAgIHRoZSBGRUMgaW4gdGhl IExTUCBQaW5nIEVjaG8gcmVxdWVzdCBtZXNzYWdlIHN1Y2NlZWRzLiAgPC9wcmU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj5HSU0mZ3Q7Jmd0OyBUaGUgTFNQIFBp bmcgRWNobyBpcyB2YWxpZGF0ZWQuIElmIHRoZSB2YWxpZGF0aW9uIGZhaWxzLCB0aGVuIHRoZSBM U1AgRWNobyBSZXBseSBNVVNUIGJlIHNlbnQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgUmV0dXJuIENv ZGUuIElmIHRoZSB2YWxpZGF0aW9uIHN1Y2NlZWRzLCB0aGVuIHRoZSBCRkQgY29udHJvbCBwYWNr ZXQgTVVTVCBiZSBzZW50LiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0iYXV0byI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGNsYXNzPSJoNSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRnbWFp bC1uZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOjEzLjMzMzNweDttYXJnaW4tdG9wOjBweDttYXJn aW4tYm90dG9tOjBweDtjb2xvcjpyZ2IoMCwwLDApIj5UaGlzIEJGRA0KICAgQ29udHJvbCBwYWNr ZXQgTVVTVCBzZXQgdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZCB0byB0aGUNCiAgIGRpc2Ny aW1pbmF0b3IgcmVjZWl2ZWQgZnJvbSB0aGUgaW5ncmVzcyBMU1IgaW4gdGhlIExTUCBQaW5nIEVj aG8NCiAgIHJlcXVlc3QgbWVzc2FnZS48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PkdJTSZndDsmZ3Q7IFRoaXMgZGVzY3JpYmVzIGhvdyBZb3VyIERpc2Ny aW1pbmF0b3IgZmllbGQgb2YgdGhlIEJGRCBjb250cm9sIHBhY2tldCB0byBiZSB0cmFuc21pdHRl ZCBieSB0aGUgZWdyZXNzIExTUiBNVVNUIGJlIHBvcHVsYXRlZCBhcyBpdCB3aWxsIGJlIHVzZWQg YnkgdGhlIGluZ3Jlc3MgTFNSIHRvIGRlbXVsdGlwbGV4IEJGRCBzZXNzaW9ucy4uJm5ic3A7PC9k aXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYg ZGlyPSJhdXRvIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxwcmUg Y2xhc3M9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNGdtYWlsLW5ld3BhZ2UiIHN0eWxlPSJmb250LXNp emU6MTMuMzMzM3B4O21hcmdpbi10b3A6MHB4O21hcmdpbi1ib3R0b206MHB4O2NvbG9yOnJnYigw LDAsMCkiPiAgVGhlIGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hv DQogICByZXBseSBtZXNzYWdlIHRoYXQgY2FycmllcyB0aGUgbG9jYWwgZGlzY3JpbWluYXRvciBh c3NpZ25lZCBieSBpdCBmb3INCiAgIHRoZSBCRkQgc2Vzc2lvbi4gIDwvcHJlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+R0lNJmd0OyZndDsgQWZ0ZXIgdGhlIGVn cmVzcyBMU1IgaXMgZG9uZSB3aXRoIHNlbmRpbmcgdGhlIGZpcnN0IEJGRCBjb250cm9sIHBhY2tl dCBpdCBNQVkgc2VuZCBMU1AgUGluZyBFY2hvIHJlcGx5IHdpdGggYWxyZWFkeSBhbGxvY2F0ZWQg YW5kIGluY2x1ZGVkIGluIEJGRCBjb250cm9sIHBhY2tldCBNeSBEaXNjcmltaW5hdG9yIGFzIHZh bHVlIG9mIEJGRCBEaXNjcmltaW5hdG9yIFRMVi4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPHByZSBjbGFzcz0ibV8yOTU5NDQyNTg5 OTkxNDMyMDM0Z21haWwtbmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZToxMy4zMzMzcHg7bWFyZ2lu LXRvcDowcHg7bWFyZ2luLWJvdHRvbTowcHg7Y29sb3I6cmdiKDAsMCwwKSI+VGhlIGxvY2FsIGRp c2NyaW1pbmF0b3IgYXNzaWduZWQgYnkgdGhlIGVncmVzcyBMU1INCiAgIE1VU1QgYmUgdXNlZCBh cyB0aGUgTXkgRGlzY3JpbWluYXRvciBmaWVsZCBpbiB0aGUgQkZEIHNlc3Npb24gcGFja2V0cw0K ICAgc2VudCBieSB0aGUgZWdyZXNzIExTUi4NCjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+R3JlZzwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIE1vbiwgSnVsIDE3LCAyMDE3IGF0IDg6MDIgQU0sIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKQ0KPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZn dDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5HcmVnLDwvZGl2Pg0KPGRpdiBpZD0i bV8yOTU5NDQyNTg5OTkxNDMyMDM0bV8tMjI0NTg3ODgyNzM3OTcxMzIxMEFwcGxlTWFpbFNpZ25h dHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRtXy0yMjQ1 ODc4ODI3Mzc5NzEzMjEwQXBwbGVNYWlsU2lnbmF0dXJlIj5Qb2ludGVyPzwvZGl2Pg0KPGRpdiBp ZD0ibV8yOTU5NDQyNTg5OTkxNDMyMDM0bV8tMjI0NTg3ODgyNzM3OTcxMzIxMEFwcGxlTWFpbFNp Z25hdHVyZSI+PGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRtXy0y MjQ1ODc4ODI3Mzc5NzEzMjEwQXBwbGVNYWlsU2lnbmF0dXJlIj5UaGFua3MsPC9kaXY+DQo8ZGl2 IGlkPSJtXzI5NTk0NDI1ODk5OTE0MzIwMzRtXy0yMjQ1ODc4ODI3Mzc5NzEzMjEwQXBwbGVNYWls U2lnbmF0dXJlIj48YnI+DQpTZW50IGZyb20gbXkgaVBhZDwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xh c3M9Im1fMjk1OTQ0MjU4OTk5MTQzMjAzNGg1Ij4NCjxkaXY+PGJyPg0KT24gSnVsIDE3LCAyMDE3 LCBhdCA5OjM0IEFNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5 QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+SGkgTWFjaCwgZXQuIGFsLA0KPGRpdj5JIHJlY2FsbCB0aGF0IHRo aXMgcXVlc3Rpb24gd2FzIGRpc2N1c3NlZCBzb21lIHRpbWUgYWdvIGFuZCB0aGUgY2xhcmlmaWNh dGlvbiBjYW1lIGZyb20gdGhlIG9yaWdpbmFsIGF1dGhvcnMgb2YgdGhlIEJGRCBwcm90b2NvbC4g VGhlIEVjaG8gUmVwbHkgaXMgb3B0aW9uYWwgaWYgdGhlcmUncyBubyBlcnJvciB0byByZXBvcnQu IEJ1dCBpZiB0aGUgcmVtb3RlIExFUiwgYWN0aW5nIGFzIEJGRCBub2RlLCBkb2VzIGRlY2lkZSB0 byBzZW5kIHRoZQ0KIEVjaG8gUmVwbHkgaXQgTVVTVCBzZW5kIGl0IGFmdGVyIGlzIHNlbmRzIHRo ZSBmaXJzdCBCRkQgY29udHJvbCBtZXNzYWdlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+R3JlZzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFN1biwgSnVsIDE2 LCAyMDE3IGF0IDY6NTggQU0sIE1hY2ggQ2hlbiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFjaC5jaGVu QGh1YXdlaS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpIaSBCRkRlcnMsPGJyPg0KPGJyPg0KV2UgbWV0 IGEgbXVsdGktdmVuZG9yIGludGVyb3BlcmF0ZSBpc3N1ZSByZWNlbnRseSwgaXQncyBhYm91dCB3 aGV0aGVyIGFuIEVjaG8gcmVwbHkgaXMgbmVjZXNzYXJ5Ljxicj4NCjxicj4NCkluIFNlY3Rpb24g NiBvZiBSRkM1ODg0LCAybmQgcGFyYWdyYXBoPGJyPg0KPGJyPg0KJnF1b3Q7Li4uIFRoZSBlZ3Jl c3MgTFNSIE1BWSByZXNwb25kIHdpdGggYW4gTFNQIFBpbmcgRWNobzxicj4NCiZuYnNwOyAmbmJz cDtyZXBseSBtZXNzYWdlIHRoYXQgY2FycmllcyB0aGUgbG9jYWwgZGlzY3JpbWluYXRvciBhc3Np Z25lZCBieSBpdCBmb3I8YnI+DQombmJzcDsgJm5ic3A7dGhlIEJGRCBzZXNzaW9uLiZxdW90Ozxi cj4NCjxicj4NCiZndDtGcm9tIHRoZSBhYm92ZSB0ZXh0LCBteSB1bmRlcnN0YW5kaW5nIGlzIHRo YXQgYW4gRWNobyByZXBseSBpcyBvcHRpb25hbCwgdGhlIGVncmVzcyBMU1IgY2FuIGZyZWVseSB0 byByZXR1cm4gb3Igbm90IHJldHVybiBhbiBFY2hvIHJlcGx5LCBhbmQgdGhlIEluZ3Jlc3MgTFNS IHNob3VsZCBub3QgZXhwZWN0IHRoZXJlIE1VU1QgYmUgYW4gRWNobyByZXBseSwgYnV0IGlmIHRo ZXJlIGlzIG9uZSwgaXQgc2hvdWxkIGhhbmRsZSBpdCBwcm9wZXJseS48YnI+DQo8YnI+DQpJcyBt eSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCk1hY2g8YnI+ DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR01MB276889C67A8EC60475562027FAA00MWHPR01MB2768prod_-- From nobody Tue Jul 18 00:14:03 2017 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 ADA81131D8F for ; Tue, 18 Jul 2017 00:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 X4XfR7FfiA19 for ; Tue, 18 Jul 2017 00:13:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AF0131D8E for ; Tue, 18 Jul 2017 00:13:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRL30941; Tue, 18 Jul 2017 07:13:56 +0000 (GMT) Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Jul 2017 08:13:55 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Tue, 18 Jul 2017 15:13:52 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" CC: "Reshad Rahman (rrahman)" , Ashesh Mishra , "rtg-bfd@ietf.org" Subject: RE: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8CAAaePmP/+7thA Date: Tue, 18 Jul 2017 07:13:51 +0000 Message-ID: References: , <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>, <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com> In-Reply-To: <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.76.65] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DAdggeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.596DB535.004E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 86e97e8fe3821be016b9856e33b9f8ce Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 07:14:02 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DAdggeml508mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpEbyB5b3Ugc3VnZ2VzdCB0byBkbyBhIDU4ODQtYmlzPw0KDQpCZXN0IHJl Z2FyZHMsDQpNYWNoDQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNywgMjAxNyAxMDo1NiBQ TQ0KVG86IE1hY2ggQ2hlbg0KQ2M6IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pOyBBc2hlc2ggTWlz aHJhOyBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQSBxdWVzdGlvbiBhYm91dCBSRkM1 ODg0DQoNCkhpIE1hY2gsDQoNCk9uIEp1bCAxNywgMjAxNywgYXQgMTA6NDIgQU0sIE1hY2ggQ2hl biA8bWFjaC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3Jv dGU6DQpIaSBDYXJsb3MsDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLg0KDQpJ TUhPLCBpdCBtYXkgbm90IGJlIG5lY2Vzc2FyeSB0byBjb25zaWRlciB0aGlzIExTUCBQaW5nIGJh c2VkIGJvb3RzdHJhcHBpbmcgYXMgbm9ybWFsIExTUCBwaW5nLg0KDQpXb3VsZCBpdCBiZSBjb25z aWRlcmVkIGFuIGFibm9ybWFsIExTUCBQaW5nPyA6LSkNCg0KDQpJZiBSRkMgNTg4NCByZWZlcmVu Y2VzIFJGQyA0Mzc5LCBJJ2QgZXhwZWN0IGl0IG1lYW5zIGFuIExTUCBQaW5nIGFzIHNwZWNpZmll ZCBpbiA0Mzc5LCBvciB0aG9zZSBwcm9jZXNzZXMgZm9yIExTUCBQaW5nIGJlIHVwZGF0ZWQuDQoN ClNlbnQgZnJvbSBteSBpUGFkDQoNCg0KQW5kIHNpbmNlIGJvdGggdGhlIGluZ3Jlc3MgYW5kIGVn cmVzcyBMU1IgcHJvY2VzcyB0aGUgZWNobyBtZXNzYWdlcyBpbiB0aGUgY29udGV4dCBvZiBCRkQg c2Vzc2lvbiBlc3RhYmxpc2htZW50LCBpdCBzaG91bGQgYmUgbm8gcHJvYmxlbSB0byBwcm9jZXNz IGFzIGRlc2NyaWJlZCBpbiBSRkM1ODg0Lg0KDQpCVFcsIFJGQzU4ODQgZG9lcyBub3Qgc3BlY2lm eSB3aGljaCByZXBseSBtb2RlIHdpbGwgYmUgdXNlZCA6KQ0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNo DQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVseSAxNywgMjAxNyA2OjU4IEFNDQpUbzogUmVzaGFk IFJhaG1hbiAocnJhaG1hbikNCkNjOiBNYWNoIENoZW47IEFzaGVzaCBNaXNocmE7IHJ0Zy1iZmRA aWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogQSBxdWVzdGlv biBhYm91dCBSRkM1ODg0DQoNCkhpLA0KDQpJIGFsc28gYWdyZWUgd2l0aCB0aGUgY29uY2x1c2lv biBvZiB0aGlzIHRocmVhZCBpbiByZWdhcmRzIHRvIHdoYXQgUkZDIDU4ODQgc2F5cy4gSG93ZXZl ciwgY2FuIHRoYXQgYmUgaW4gY29uZmxpY3Qgd2l0aCBSRkMgODAyOSdzIHByb2NlZHVyZXMsIGlu IHdoaWNoIHRoZSByZXBseSBtaWdodCBiZSBleHBlY3RlZD8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4MDI5I3NlY3Rpb24tNC40DQoNClRoZXJlIGlzIGNlcnRhaW5seSBubyBuZWVk IHRvIGNhcnJ5IGFueSBpbmZvcm1hdGlvbiBpbiBhbiBNUExTIExTUCBQaW5nIHJlcGx5LCBzaW5j ZSBhdCB0aGF0IHBvaW50IHRoZSBkaXNjcmltaW5hdG9yeSBhcmUgYWxyZWFkeSBjYXJyaWVkIGlu IEJGRC4gVGhlIHJlcGx5IG1pZ2h0IGJlIGltcG9ydGFudCBvbmx5IGlmIEZFQyB2YWxpZGF0aW9u IGZhaWxzLg0KDQpJIHdvbmRlciB0aG91Z2ggaWYgdGhlIHRleHQgb2YgIlRoZSBlZ3Jlc3MgTFNS IE1BWSByZXNwb25kIHdpdGggYW4gTFNQIFBpbmcgRWNobyIgaW50ZW5kZWQgdG8gY29udmV5IHRo YXQgd2hldGhlciB0byByZXBseSBvciBub3QgZGVwZW5kcyBvbiB0aGUgdmFsdWUgb2YgdGhlIFJl cGx5IE1vZGUgZmllbGQgaW4gdGhlIEVjaG8gcmVxdWVzdC4NCg0KU2VudCBmcm9tIG15IGlQYWQN Cg0KT24gSnVsIDE2LCAyMDE3LCBhdCA2OjIyIFBNLCBSZXNoYWQgUmFobWFuIChycmFobWFuKSA8 cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJyYWhtYW5AY2lzY28uY29tPj4gd3JvdGU6DQpIaSwN Cg0KTXkgdGFrZSB0b28gaXMgdGhhdCB0aGUgUkZDIGlzIHByZXR0eSBjbGVhciB0aGF0IEVjaG8g cmVwbHkgZnJvbSBlZ3Jlc3MNCkxTUiBpcyBub3QgbWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KUmVz aGFkLg0KDQoNCg0KT24gMjAxNy0wNy0xNiwgNDoyOSBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9m IE1hY2ggQ2hlbiINCjxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzpt YWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQoNCg0KSGkgQXNoZXNoLA0KDQpUaGFua3Mg Zm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlLCB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlIQ0KDQpCZXN0 IHJlZ2FyZHMsDQpNYWNoDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBc2hlc2ggTWlz aHJhIFttYWlsdG86bWlzaHJhLmFzaGVzaEBvdXRsb29rLmNvbV0NCreiy83KsbzkOiAyMDE3xOo3 1MIxNsjVIDIyOjI2DQrK1bz+yMs6IE1hY2ggQ2hlbg0Ks63LzTogcnRnLWJmZEBpZXRmLm9yZzxt YWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NCtb3zOI6IFJlOiBBIHF1ZXN0aW9uIGFib3V0IFJGQzU4 ODQNCg0KVGhhdCdzIGhvdyBJIHJlYWQgaXQgLi4uIGFzc3VtaW5nIHRoYXQgcHJvcGVyIGhhbmRs aW5nIG9mIHRoZSBMU1IgZWNobw0KaW5jbHVkZXMNCmdyYWNlZnVsbHkgZHJvcHBpbmcgaXQgb24g cnguDQoNCkFzaGVzaA0KDQpPbiBKdWwgMTYsIDIwMTcsIGF0IDM6NTggUE0sIE1hY2ggQ2hlbiA8 bWFjaC5jaGVuQGh1YXdlaS5jb208bWFpbHRvOm1hY2guY2hlbkBodWF3ZWkuY29tPj4gd3JvdGU6 DQoNCkhpIEJGRGVycywNCg0KV2UgbWV0IGEgbXVsdGktdmVuZG9yIGludGVyb3BlcmF0ZSBpc3N1 ZSByZWNlbnRseSwgaXQncyBhYm91dCB3aGV0aGVyDQphbiBFY2hvDQpyZXBseSBpcyBuZWNlc3Nh cnkuDQoNCkluIFNlY3Rpb24gNiBvZiBSRkM1ODg0LCAybmQgcGFyYWdyYXBoDQoNCiIuLi4gVGhl IGVncmVzcyBMU1IgTUFZIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvDQogcmVwbHkgbWVz c2FnZSB0aGF0IGNhcnJpZXMgdGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgYXNzaWduZWQgYnkgaXQg Zm9yDQogdGhlIEJGRCBzZXNzaW9uLiINCg0KRnJvbSB0aGUgYWJvdmUgdGV4dCwgbXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IGFuIEVjaG8gcmVwbHkgaXMNCm9wdGlvbmFsLCB0aGUNCmVncmVzcyBM U1IgY2FuIGZyZWVseSB0byByZXR1cm4gb3Igbm90IHJldHVybiBhbiBFY2hvIHJlcGx5LCBhbmQg dGhlDQpJbmdyZXNzIExTUg0Kc2hvdWxkIG5vdCBleHBlY3QgdGhlcmUgTVVTVCBiZSBhbiBFY2hv IHJlcGx5LCBidXQgaWYgdGhlcmUgaXMgb25lLCBpdA0Kc2hvdWxkDQpoYW5kbGUgaXQgcHJvcGVy bHkuDQoNCklzIG15IHVuZGVyc3RhbmRpbmcgY29ycmVjdD8NCg0KVGhhbmtzLA0KTWFjaA0KDQoN Cg== --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DAdggeml508mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

Do you sug= gest to do a 5884-bis?

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi Mach,

=
On Jul 17, 2017, at 10:42 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Carlos,=

 

Thanks for= sharing your thoughts.

 

IMHO, it m= ay not be necessary to consider this LSP Ping based bootstrapping as normal= LSP ping.

 

Would it be considered an abnormal LSP Ping? :-)



If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as sp= ecified in 4379, or those processes for LSP Ping be updated. 


Sent from my iPad



And since = both the ingress and egress LSR process the echo messages in the context of= BFD session establishment, it should be no problem to process as described in RFC5884.

 

BTW, RFC58= 84 does not specify which reply mode will be used J

 

Best regar= ds,

Mach

 

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rt= g-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi,

 

I also agree with the conclusio= n of this thread in regards to what RFC 5884 says. However, can that be in = conflict with RFC 8029's procedures, in which the reply might be expected?<= o:p>

https://tools.ietf.org/html/rfc8029#section-4.= 4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

 

I wonder though if the text of = "The egress LSR MAY respond with an LSP Ping Echo" intended to co= nvey that whether to reply or not depends on the value of the Reply Mode fi= eld in the Echo request. 

 

Sent from my iPad

=
On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote:=



Hi Ashesh,

 

Thanks for your prompt response= , we're on the same page!

 

Best regards,=

Mach

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-= ----

=B7=A2=BC= =FE=C8=CB: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]

=B7=A2=CB= =CD=CA=B1=BC=E4: 2017=C4=EA7=D4=C216=C8=D5 22:26

=CA=D5=BC= =FE=C8=CB: Mach Chen

=B3=AD=CB= =CD: rtg-bfd@ietf.org

=D6=F7=CC= =E2: Re: A question about RFC5884

 

That's how I read it ... assumi= ng that proper handling of the LSR echo

includes

gracefully dropping it on rx.

 

Ashesh

 

On Jul 16, 2017, at 3:58 PM, Ma= ch Chen <mach.chen@huawei.com> wrote:

 

Hi BFDers,

 

We met a multi-vendor interoper= ate issue recently, it's about whether

an Echo

reply is necessary.<= /span>

 

In Section 6 of RFC5884, 2nd pa= ragraph

 

"... The egress LSR MAY re= spond with an LSP Ping Echo

 reply message that carrie= s the local discriminator assigned by it for

 the BFD session."

 

From the above text, my underst= anding is that an Echo reply is

optional, the=

egress LSR can freely to return= or not return an Echo reply, and the

Ingress LSR

should not expect there MUST be= an Echo reply, but if there is one, it

should

handle it properly.<= /span>

 

Is my understanding correct?

 

Thanks,

Mach

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DAdggeml508mbxchi_-- From nobody Tue Jul 18 03:25:45 2017 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 BE83712EC30 for ; Tue, 18 Jul 2017 03:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wFem3qd8SBh for ; Tue, 18 Jul 2017 03:25:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F80912969E for ; Tue, 18 Jul 2017 03:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29656; q=dns/txt; s=iport; t=1500373541; x=1501583141; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2pbs68as5JN85KmWFElgNH+riZ0qHRlBQTedg0BU14g=; b=Vb8bkkOt5FGcLv0t6MUVlXHxSB1t3Uif4jSPZF7NiB1SjWgJzKL9OHA7 /pmuMUD6NuVqz1bBwlM4e6uNPupku+vAgHqtm7DCUn63/plHyJMj/gzzp pFnHibbWShisQKpUw7w1LZW05geTsFPaGqirsttTLlKrfi9jo3E20sQjg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAM4W1Z/5RdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm9AK2SBFI4LkWSWBIIRLIUbAoNRPxgBAgEBAQEBAQFrKIUYAQEBAQM?= =?us-ascii?q?tOgYMEAIBCBEEAQEhAQYHMhQJCAIEDgWICTaBDEwDFRCwY4sLAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWDKINNgWErgnmBPINkgw2CMQWXQodyAodIjEwMggCJRYZ?= =?us-ascii?q?elVYBHzgTLEt1FVsBhQyBd3YBhhorghIBAQE?= X-IronPort-AV: E=Sophos;i="5.40,377,1496102400"; d="scan'208,217";a="260975199" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 10:25:39 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6IAPdan027734 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 10:25:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Jul 2017 06:25:39 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Tue, 18 Jul 2017 06:25:39 -0400 From: "Carlos Pignataro (cpignata)" To: Mach Chen CC: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8CAAaePmP/+7thAgAJYAnY= Date: Tue, 18 Jul 2017 10:25:38 +0000 Message-ID: References: , <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>, <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_EC7807EAD9EF4B97B956D6131912C0FEciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 10:25:44 -0000 --_000_EC7807EAD9EF4B97B956D6131912C0FEciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mach, I had not suggested it, but I think that idea has merit. If there are enoug= h updates needed to the spec based on additional running-code learning, or = ambiguities that are causing interoperable confusion, the net of a -biz can= be positive. When that same idea crossed my mind, I thought that the question should be = part of a larger consideration from the chairs of maturity, pipeline, and a= dvancement of BFD specs, and not taken in isolation. 5884 seems to require = localized fixes only. Thanks, Sent from my iPad On Jul 18, 2017, at 9:14 AM, Mach Chen > wrote: Hi Carlos, Do you suggest to do a 5884-bis? Best regards, Mach From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Monday, July 17, 2017 10:56 PM To: Mach Chen Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org Subject: Re: A question about RFC5884 Hi Mach, On Jul 17, 2017, at 10:42 AM, Mach Chen > wrote: Hi Carlos, Thanks for sharing your thoughts. IMHO, it may not be necessary to consider this LSP Ping based bootstrapping= as normal LSP ping. Would it be considered an abnormal LSP Ping? :-) If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specifi= ed in 4379, or those processes for LSP Ping be updated. Sent from my iPad And since both the ingress and egress LSR process the echo messages in the = context of BFD session establishment, it should be no problem to process as= described in RFC5884. BTW, RFC5884 does not specify which reply mode will be used :) Best regards, Mach From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Monday, July 17, 2017 6:58 AM To: Reshad Rahman (rrahman) Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org Subject: Re: A question about RFC5884 Hi, I also agree with the conclusion of this thread in regards to what RFC 5884= says. However, can that be in conflict with RFC 8029's procedures, in whic= h the reply might be expected? https://tools.ietf.org/html/rfc8029#section-4.4 There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. I wonder though if the text of "The egress LSR MAY respond with an LSP Ping= Echo" intended to convey that whether to reply or not depends on the value= of the Reply Mode field in the Echo request. Sent from my iPad On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) > wrote: Hi, My take too is that the RFC is pretty clear that Echo reply from egress LSR is not mandatory. Regards, Reshad. On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen" on behalf of mac= h.chen@huawei.com> wrote: Hi Ashesh, Thanks for your prompt response, we're on the same page! Best regards, Mach -----????----- ???: Ashesh Mishra [mailto:mishra.ashesh@outlook.com] ????: 2017?7?16? 22:26 ???: Mach Chen ??: rtg-bfd@ietf.org ??: Re: A question about RFC5884 That's how I read it ... assuming that proper handling of the LSR echo includes gracefully dropping it on rx. Ashesh On Jul 16, 2017, at 3:58 PM, Mach Chen > wrote: Hi BFDers, We met a multi-vendor interoperate issue recently, it's about whether an Echo reply is necessary. In Section 6 of RFC5884, 2nd paragraph "... The egress LSR MAY respond with an LSP Ping Echo reply message that carries the local discriminator assigned by it for the BFD session." >From the above text, my understanding is that an Echo reply is optional, the egress LSR can freely to return or not return an Echo reply, and the Ingress LSR should not expect there MUST be an Echo reply, but if there is one, it should handle it properly. Is my understanding correct? Thanks, Mach --_000_EC7807EAD9EF4B97B956D6131912C0FEciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mach,

I had not suggested it, but I think that ide= a has merit. If there are enough updates needed to the spec based on additi= onal running-code learning, or ambiguities that are causing interoperable c= onfusion, the net of a -biz can be positive. 

When that same idea crossed my mind, I thoug= ht that the question should be part of a larger consideration from the chai= rs of maturity, pipeline, and advancement of BFD specs, and not taken in is= olation. 5884 seems to require localized fixes only. 

Thanks,

Sent from my iPad

Hi Carlos,=

 = ;

Do you sug= gest to do a 5884-bis?

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi Mach,

=
On Jul 17, 2017, at 10:42 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Carlos,=

 

Thanks for= sharing your thoughts.

 

IMHO, it m= ay not be necessary to consider this LSP Ping based bootstrapping as normal= LSP ping.

 

Would it be considered an abnormal LSP Ping? :-)<= /p>



If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as= specified in 4379, or those processes for LSP Ping be updated. <= /o:p>


Sent from my iPad



And since = both the ingress and egress LSR process the echo messages in the context of= BFD session establishment, it should be no problem to process as described in RFC5884.

 

BTW, RFC58= 84 does not specify which reply mode will be used J

 

Best regar= ds,

Mach

 

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rt= g-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi,

 

I also agree with the conclusio= n of this thread in regards to what RFC 5884 says. However, can that be in = conflict with RFC 8029's procedures, in which the reply might be expected?<= o:p>

https://tools.ietf.org/html/rfc8029#section-4.= 4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

 

I wonder though if the text of = "The egress LSR MAY respond with an LSP Ping Echo" intended to co= nvey that whether to reply or not depends on the value of the Reply Mode fi= eld in the Echo request. 

 

Sent from my iPad

=
On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote:=



Hi Ashesh,

 

Thanks for your prompt response= , we're on the same page!

 

Best regards,=

Mach

 

-----邮件原件-----

发= ;件人: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]<= /o:p>

发= ;送时间: 2017年7月16日 22:26

收= ;件人: Mach Chen<= /p>

抄= ;送: rtg-bfd@ietf.org

主= ;题: Re: A question about RFC5884

 

That's how I read it ... assumi= ng that proper handling of the LSR echo

includes

gracefully dropping it on rx.

 

Ashesh

 

On Jul 16, 2017, at 3:58 PM, Ma= ch Chen <mach.chen@huawei.com> wrote:

 

Hi BFDers,

 

We met a multi-vendor interoper= ate issue recently, it's about whether

an Echo

reply is necessary.<= /span>

 

In Section 6 of RFC5884, 2nd pa= ragraph

 

"... The egress LSR MAY re= spond with an LSP Ping Echo

 reply message that carrie= s the local discriminator assigned by it for

 the BFD session."

 

From the above text, my underst= anding is that an Echo reply is

optional, the=

egress LSR can freely to return= or not return an Echo reply, and the

Ingress LSR

should not expect there MUST be= an Echo reply, but if there is one, it

should

handle it properly.<= /span>

 

Is my understanding correct?

 

Thanks,

Mach

 

 

--_000_EC7807EAD9EF4B97B956D6131912C0FEciscocom_-- From nobody Tue Jul 18 05:07:12 2017 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 CA165131B01 for ; Tue, 18 Jul 2017 05:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 gGUrlL8FV_Td for ; Tue, 18 Jul 2017 05:07:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766D6131DF8 for ; Tue, 18 Jul 2017 05:06:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRL89442; Tue, 18 Jul 2017 12:06:52 +0000 (GMT) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Jul 2017 13:06:51 +0100 Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Tue, 18 Jul 2017 20:06:45 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" CC: "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" Subject: RE: A question about RFC5884 Thread-Topic: A question about RFC5884 Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8CAAaePmP/+7thAgAJYAnb//+PRMA== Date: Tue, 18 Jul 2017 12:06:45 +0000 Message-ID: References: , <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>, <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.68.7] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918492D4dggeml508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.596DF9DD.0112, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 86e97e8fe3821be016b9856e33b9f8ce Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 18 Jul 2017 12:07:10 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918492D4dggeml508mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLA0KDQpPSywgdGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiENCg0KQmVzdCBy ZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0 bzpjcGlnbmF0YUBjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDE4LCAyMDE3IDY6MjYg UE0NClRvOiBNYWNoIENoZW4NCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsgcnRnLWJmZEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IEEgcXVlc3Rpb24gYWJvdXQgUkZDNTg4NA0KDQpIaSBNYWNo LA0KDQpJIGhhZCBub3Qgc3VnZ2VzdGVkIGl0LCBidXQgSSB0aGluayB0aGF0IGlkZWEgaGFzIG1l cml0LiBJZiB0aGVyZSBhcmUgZW5vdWdoIHVwZGF0ZXMgbmVlZGVkIHRvIHRoZSBzcGVjIGJhc2Vk IG9uIGFkZGl0aW9uYWwgcnVubmluZy1jb2RlIGxlYXJuaW5nLCBvciBhbWJpZ3VpdGllcyB0aGF0 IGFyZSBjYXVzaW5nIGludGVyb3BlcmFibGUgY29uZnVzaW9uLCB0aGUgbmV0IG9mIGEgLWJpeiBj YW4gYmUgcG9zaXRpdmUuDQoNCldoZW4gdGhhdCBzYW1lIGlkZWEgY3Jvc3NlZCBteSBtaW5kLCBJ IHRob3VnaHQgdGhhdCB0aGUgcXVlc3Rpb24gc2hvdWxkIGJlIHBhcnQgb2YgYSBsYXJnZXIgY29u c2lkZXJhdGlvbiBmcm9tIHRoZSBjaGFpcnMgb2YgbWF0dXJpdHksIHBpcGVsaW5lLCBhbmQgYWR2 YW5jZW1lbnQgb2YgQkZEIHNwZWNzLCBhbmQgbm90IHRha2VuIGluIGlzb2xhdGlvbi4gNTg4NCBz ZWVtcyB0byByZXF1aXJlIGxvY2FsaXplZCBmaXhlcyBvbmx5Lg0KDQpUaGFua3MsDQoNClNlbnQg ZnJvbSBteSBpUGFkDQoNCk9uIEp1bCAxOCwgMjAxNywgYXQgOToxNCBBTSwgTWFjaCBDaGVuIDxt YWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToN CkhpIENhcmxvcywNCg0KRG8geW91IHN1Z2dlc3QgdG8gZG8gYSA1ODg0LWJpcz8NCg0KQmVzdCBy ZWdhcmRzLA0KTWFjaA0KDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgW21haWx0 bzpjcGlnbmF0YUBjaXNjby5jb21dDQpTZW50OiBNb25kYXksIEp1bHkgMTcsIDIwMTcgMTA6NTYg UE0NClRvOiBNYWNoIENoZW4NCkNjOiBSZXNoYWQgUmFobWFuIChycmFobWFuKTsgQXNoZXNoIE1p c2hyYTsgcnRnLWJmZEBpZXRmLm9yZzxtYWlsdG86cnRnLWJmZEBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBBIHF1ZXN0aW9uIGFib3V0IFJGQzU4ODQNCg0KSGkgTWFjaCwNCg0KT24gSnVsIDE3LCAy MDE3LCBhdCAxMDo0MiBBTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86 bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIENhcmxvcywNCg0KVGhhbmtzIGZvciBz aGFyaW5nIHlvdXIgdGhvdWdodHMuDQoNCklNSE8sIGl0IG1heSBub3QgYmUgbmVjZXNzYXJ5IHRv IGNvbnNpZGVyIHRoaXMgTFNQIFBpbmcgYmFzZWQgYm9vdHN0cmFwcGluZyBhcyBub3JtYWwgTFNQ IHBpbmcuDQoNCldvdWxkIGl0IGJlIGNvbnNpZGVyZWQgYW4gYWJub3JtYWwgTFNQIFBpbmc/IDot KQ0KDQoNCg0KSWYgUkZDIDU4ODQgcmVmZXJlbmNlcyBSRkMgNDM3OSwgSSdkIGV4cGVjdCBpdCBt ZWFucyBhbiBMU1AgUGluZyBhcyBzcGVjaWZpZWQgaW4gNDM3OSwgb3IgdGhvc2UgcHJvY2Vzc2Vz IGZvciBMU1AgUGluZyBiZSB1cGRhdGVkLg0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQoNCg0KQW5k IHNpbmNlIGJvdGggdGhlIGluZ3Jlc3MgYW5kIGVncmVzcyBMU1IgcHJvY2VzcyB0aGUgZWNobyBt ZXNzYWdlcyBpbiB0aGUgY29udGV4dCBvZiBCRkQgc2Vzc2lvbiBlc3RhYmxpc2htZW50LCBpdCBz aG91bGQgYmUgbm8gcHJvYmxlbSB0byBwcm9jZXNzIGFzIGRlc2NyaWJlZCBpbiBSRkM1ODg0Lg0K DQpCVFcsIFJGQzU4ODQgZG9lcyBub3Qgc3BlY2lmeSB3aGljaCByZXBseSBtb2RlIHdpbGwgYmUg dXNlZCA6KQ0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8g KGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NClNlbnQ6IE1vbmRheSwgSnVs eSAxNywgMjAxNyA2OjU4IEFNDQpUbzogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikNCkNjOiBNYWNo IENoZW47IEFzaGVzaCBNaXNocmE7IHJ0Zy1iZmRAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmRAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogQSBxdWVzdGlvbiBhYm91dCBSRkM1ODg0DQoNCkhpLA0KDQpJ IGFsc28gYWdyZWUgd2l0aCB0aGUgY29uY2x1c2lvbiBvZiB0aGlzIHRocmVhZCBpbiByZWdhcmRz IHRvIHdoYXQgUkZDIDU4ODQgc2F5cy4gSG93ZXZlciwgY2FuIHRoYXQgYmUgaW4gY29uZmxpY3Qg d2l0aCBSRkMgODAyOSdzIHByb2NlZHVyZXMsIGluIHdoaWNoIHRoZSByZXBseSBtaWdodCBiZSBl eHBlY3RlZD8NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDI5I3NlY3Rpb24tNC40 DQoNClRoZXJlIGlzIGNlcnRhaW5seSBubyBuZWVkIHRvIGNhcnJ5IGFueSBpbmZvcm1hdGlvbiBp biBhbiBNUExTIExTUCBQaW5nIHJlcGx5LCBzaW5jZSBhdCB0aGF0IHBvaW50IHRoZSBkaXNjcmlt aW5hdG9yeSBhcmUgYWxyZWFkeSBjYXJyaWVkIGluIEJGRC4gVGhlIHJlcGx5IG1pZ2h0IGJlIGlt cG9ydGFudCBvbmx5IGlmIEZFQyB2YWxpZGF0aW9uIGZhaWxzLg0KDQpJIHdvbmRlciB0aG91Z2gg aWYgdGhlIHRleHQgb2YgIlRoZSBlZ3Jlc3MgTFNSIE1BWSByZXNwb25kIHdpdGggYW4gTFNQIFBp bmcgRWNobyIgaW50ZW5kZWQgdG8gY29udmV5IHRoYXQgd2hldGhlciB0byByZXBseSBvciBub3Qg ZGVwZW5kcyBvbiB0aGUgdmFsdWUgb2YgdGhlIFJlcGx5IE1vZGUgZmllbGQgaW4gdGhlIEVjaG8g cmVxdWVzdC4NCg0KU2VudCBmcm9tIG15IGlQYWQNCg0KT24gSnVsIDE2LCAyMDE3LCBhdCA2OjIy IFBNLCBSZXNoYWQgUmFobWFuIChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb208bWFpbHRvOnJy YWhtYW5AY2lzY28uY29tPj4gd3JvdGU6DQpIaSwNCg0KTXkgdGFrZSB0b28gaXMgdGhhdCB0aGUg UkZDIGlzIHByZXR0eSBjbGVhciB0aGF0IEVjaG8gcmVwbHkgZnJvbSBlZ3Jlc3MNCkxTUiBpcyBu b3QgbWFuZGF0b3J5Lg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQoNCg0KT24gMjAxNy0wNy0xNiwg NDoyOSBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIE1hY2ggQ2hlbiINCjxydGctYmZkLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IG1hY2guY2hlbkBodWF3ZWkuY29tPG1haWx0bzptYWNoLmNoZW5AaHVhd2VpLmNvbT4+IHdyb3Rl Og0KDQoNCg0KDQpIaSBBc2hlc2gsDQoNClRoYW5rcyBmb3IgeW91ciBwcm9tcHQgcmVzcG9uc2Us IHdlJ3JlIG9uIHRoZSBzYW1lIHBhZ2UhDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KLS0tLS3T yrz+1K28/i0tLS0tDQq3orz+yMs6IEFzaGVzaCBNaXNocmEgW21haWx0bzptaXNocmEuYXNoZXNo QG91dGxvb2suY29tXQ0Kt6LLzcqxvOQ6IDIwMTfE6jfUwjE2yNUgMjI6MjYNCsrVvP7IyzogTWFj aCBDaGVuDQqzrcvNOiBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGctYmZkQGlldGYub3JnPg0K 1vfM4jogUmU6IEEgcXVlc3Rpb24gYWJvdXQgUkZDNTg4NA0KDQpUaGF0J3MgaG93IEkgcmVhZCBp dCAuLi4gYXNzdW1pbmcgdGhhdCBwcm9wZXIgaGFuZGxpbmcgb2YgdGhlIExTUiBlY2hvDQppbmNs dWRlcw0KZ3JhY2VmdWxseSBkcm9wcGluZyBpdCBvbiByeC4NCg0KQXNoZXNoDQoNCk9uIEp1bCAx NiwgMjAxNywgYXQgMzo1OCBQTSwgTWFjaCBDaGVuIDxtYWNoLmNoZW5AaHVhd2VpLmNvbTxtYWls dG86bWFjaC5jaGVuQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQkZEZXJzLA0KDQpXZSBtZXQg YSBtdWx0aS12ZW5kb3IgaW50ZXJvcGVyYXRlIGlzc3VlIHJlY2VudGx5LCBpdCdzIGFib3V0IHdo ZXRoZXINCmFuIEVjaG8NCnJlcGx5IGlzIG5lY2Vzc2FyeS4NCg0KSW4gU2VjdGlvbiA2IG9mIFJG QzU4ODQsIDJuZCBwYXJhZ3JhcGgNCg0KIi4uLiBUaGUgZWdyZXNzIExTUiBNQVkgcmVzcG9uZCB3 aXRoIGFuIExTUCBQaW5nIEVjaG8NCiByZXBseSBtZXNzYWdlIHRoYXQgY2FycmllcyB0aGUgbG9j YWwgZGlzY3JpbWluYXRvciBhc3NpZ25lZCBieSBpdCBmb3INCiB0aGUgQkZEIHNlc3Npb24uIg0K DQpGcm9tIHRoZSBhYm92ZSB0ZXh0LCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYW4gRWNobyBy ZXBseSBpcw0Kb3B0aW9uYWwsIHRoZQ0KZWdyZXNzIExTUiBjYW4gZnJlZWx5IHRvIHJldHVybiBv ciBub3QgcmV0dXJuIGFuIEVjaG8gcmVwbHksIGFuZCB0aGUNCkluZ3Jlc3MgTFNSDQpzaG91bGQg bm90IGV4cGVjdCB0aGVyZSBNVVNUIGJlIGFuIEVjaG8gcmVwbHksIGJ1dCBpZiB0aGVyZSBpcyBv bmUsIGl0DQpzaG91bGQNCmhhbmRsZSBpdCBwcm9wZXJseS4NCg0KSXMgbXkgdW5kZXJzdGFuZGlu ZyBjb3JyZWN0Pw0KDQpUaGFua3MsDQpNYWNoDQoNCg0K --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918492D4dggeml508mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Carlos,=

 = ;

OK, thanks= for the clarification!

 = ;

Best regar= ds,

Mach<= /o:p>

 = ;

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.co= m]
Sent: Tuesday, July 18, 2017 6:26 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi Mach,

 

I had not suggested it, but I t= hink that idea has merit. If there are enough updates needed to the spec ba= sed on additional running-code learning, or ambiguities that are causing in= teroperable confusion, the net of a -biz can be positive. 

 

When that same idea crossed my = mind, I thought that the question should be part of a larger consideration = from the chairs of maturity, pipeline, and advancement of BFD specs, and no= t taken in isolation. 5884 seems to require localized fixes only. 

 

Thanks,

Sent from my iPad

Hi Carlos,=

 

Do you sug= gest to do a 5884-bis?

 

Best regar= ds,

Mach

 

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi Mach,

=
On Jul 17, 2017, at 10:42 AM, Mach Chen <mach.chen@huawei.com> wrote:

Hi Carlos,=

 

Thanks for= sharing your thoughts.

 

IMHO, it m= ay not be necessary to consider this LSP Ping based bootstrapping as normal= LSP ping.

 

Would it be considered an abnormal LSP Ping? :-)




If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as sp= ecified in 4379, or those processes for LSP Ping be updated. 


Sent from my iPad




And since = both the ingress and egress LSR process the echo messages in the context of= BFD session establishment, it should be no problem to process as described in RFC5884.

 

BTW, RFC58= 84 does not specify which reply mode will be used J

 

Best regar= ds,

Mach

 

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rt= g-bfd@ietf.org
Subject: Re: A question about RFC5884

 

Hi,

 

I also agree with the conclusio= n of this thread in regards to what RFC 5884 says. However, can that be in = conflict with RFC 8029's procedures, in which the reply might be expected?<= o:p>

https://tools.ietf.org/html/rfc8029#section-4.= 4

There is certainly no need to carry any information in an MPLS LSP Ping rep= ly, since at that point the discriminatory are already carried in BFD. The = reply might be important only if FEC validation fails. 

 

I wonder though if the text of = "The egress LSR MAY respond with an LSP Ping Echo" intended to co= nvey that whether to reply or not depends on the value of the Reply Mode fi= eld in the Echo request. 

 

Sent from my iPad

=
On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com> wrote:

Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org on behalf of mach.chen@huawei.com> wrote:=




Hi Ashesh,

 

Thanks for your prompt response= , we're on the same page!

 

Best regards,=

Mach

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-= ----

=B7=A2=BC= =FE=C8=CB: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]

=B7=A2=CB= =CD=CA=B1=BC=E4: 2017=C4=EA7=D4=C216=C8=D5 22:26

=CA=D5=BC= =FE=C8=CB: Mach Chen

=B3=AD=CB= =CD: rtg-bfd@ietf.org

=D6=F7=CC= =E2: Re: A question about RFC5884

 

That's how I read it ... assumi= ng that proper handling of the LSR echo

includes

gracefully dropping it on rx.

 

Ashesh

 

On Jul 16, 2017, at 3:58 PM, Ma= ch Chen <mach.chen@huawei.com> wrote:

 

Hi BFDers,

 

We met a multi-vendor interoper= ate issue recently, it's about whether

an Echo

reply is necessary.<= /span>

 

In Section 6 of RFC5884, 2nd pa= ragraph

 

"... The egress LSR MAY re= spond with an LSP Ping Echo

 reply message that carrie= s the local discriminator assigned by it for

 the BFD session."

 

From the above text, my underst= anding is that an Echo reply is

optional, the=

egress LSR can freely to return= or not return an Echo reply, and the

Ingress LSR

should not expect there MUST be= an Echo reply, but if there is one, it

should

handle it properly.<= /span>

 

Is my understanding correct?

 

Thanks,

Mach

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918492D4dggeml508mbxchi_-- From nobody Thu Jul 20 07:18:41 2017 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 206071276AF; Thu, 20 Jul 2017 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2BeCIjJB7jO; Thu, 20 Jul 2017 07:18:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F8112704A; Thu, 20 Jul 2017 07:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2696; q=dns/txt; s=iport; t=1500560318; x=1501769918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vSoVVFxrlp8hvQfYOrw8gTmnnjXyliL9p80BY4EVlSE=; b=S5nGqP4fQ0OcT3JWpGo9DS4R1yeMgSn3SnT0ObWl/+LDNtkq02138I8T PgGwwvZNzzar38TuwfPW9hJxackQ0ZZlELHkV75TdaMBVHSPAHAc2ZJcC p22i59/CZK6Hw2Vm2fIh0gaWIDUTTGzYYE/xAqWpT0wKBZAl8JUSRoD4K 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADdunBZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRaJYFghEshRsCg3Q/GAECAQEBAQEBAWsohRkBBTo?= =?us-ascii?q?/EAIBCA4KHhAyJQIEAQ0Fii8QtBGLIgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DK?= =?us-ascii?q?INNhQWDJoc4BZ8+AodJjE+CDFeEeYpYlV0BHziBCnUVH4c/AXaIbIEOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,384,1496102400"; d="scan'208";a="270569976" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 14:18:37 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v6KEIbKv011366 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 14:18:37 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 09:18:36 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 09:18:36 -0500 From: "Reshad Rahman (rrahman)" To: Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYA= Date: Thu, 20 Jul 2017 14:18:36 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> In-Reply-To: <20170705162103.GQ2289@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.81.238] Content-Type: text/plain; charset="us-ascii" Content-ID: <7428FA4CECDCDE4D9E046C68410AFD9E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 14:18:40 -0000 We (BFD and OSPF YANG authors) had a discussion yesterday. The agreement is that since IGP peers are auto-discovered, we want to add back the basic BFD config (multiplier + intervals) in IGP via a grouping. BFD will provide that grouping in a specific YANG module. IGP BFD YANG will be in a separate module (separate from the main IGP module). Regards, Reshad. On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: >Thanks authors for the edits on the BFD yang module. This gets us a >significant step closer to alignment with the rest of IETF for network >instancing. > >I'd like to encourage the working group to provide feedback on this issue >and also the changes in the module. > >As noted in another thread, we still have to figure out how to deal with >accommodating interaction of the BFD yang module with client protocols. >For >example, the IGPs. In particular, how do you configure the properties of >the BFD sessions that may be dynamically instantiated based on control >protocol activity? > >-- Jeff > >On Fri, Jun 30, 2017 at 12:55:59PM -0700, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Bidirectional Forwarding Detection of >>the IETF. >>=20 >> Title : YANG Data Model for Bidirectional Forwarding >>Detection (BFD) >> Authors : Reshad Rahman >> Lianshu Zheng >> Mahesh Jethanandani >> Santosh Pallagatti >> Greg Mirsky >> Filename : draft-ietf-bfd-yang-06.txt >> Pages : 59 >> Date : 2017-06-30 >>=20 >> Abstract: >> This document defines a YANG data model that can be used to configure >> and manage Bidirectional Forwarding Detection (BFD). >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >>submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > From nobody Fri Jul 21 09:22:16 2017 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 BF08B131AA9; Fri, 21 Jul 2017 09:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 w1NIk0luMTPz; Fri, 21 Jul 2017 09:22:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B764F131A56; Fri, 21 Jul 2017 09:22:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLA25302; Fri, 21 Jul 2017 16:22:09 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Jul 2017 17:22:08 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Fri, 21 Jul 2017 09:22:05 -0700 From: Yingzhen Qu To: "Reshad Rahman (rrahman)" , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwA== Date: Fri, 21 Jul 2017 16:22:04 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.247.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59722A32.0036, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f51b081ef726120ca0b85531009b970e Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 16:22:15 -0000 Hi Reshad, Thanks for the summary. Both ospf and isis models will make corresponding changes when the new BFD = grouping is available. Thanks, Yingzhen -----Original Message----- From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]=20 Sent: Thursday, July 20, 2017 7:19 AM To: Jeffrey Haas ; rtg-bfd@ietf.org Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt We (BFD and OSPF YANG authors) had a discussion yesterday. The agreement is that since IGP peers are auto-discovered, we want to add b= ack the basic BFD config (multiplier + intervals) in IGP via a grouping. BFD will provide that grouping in a specific YANG module. IGP BFD YANG will= be in a separate module (separate from the main IGP module). Regards, Reshad. On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" wrote: >Thanks authors for the edits on the BFD yang module. This gets us a=20 >significant step closer to alignment with the rest of IETF for network=20 >instancing. > >I'd like to encourage the working group to provide feedback on this=20 >issue and also the changes in the module. > >As noted in another thread, we still have to figure out how to deal=20 >with accommodating interaction of the BFD yang module with client protocol= s. >For >example, the IGPs. In particular, how do you configure the properties=20 >of the BFD sessions that may be dynamically instantiated based on=20 >control protocol activity? > >-- Jeff > >On Fri, Jun 30, 2017 at 12:55:59PM -0700, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Bidirectional Forwarding Detection=20 >>of the IETF. >>=20 >> Title : YANG Data Model for Bidirectional Forwarding >>Detection (BFD) >> Authors : Reshad Rahman >> Lianshu Zheng >> Mahesh Jethanandani >> Santosh Pallagatti >> Greg Mirsky >> Filename : draft-ietf-bfd-yang-06.txt >> Pages : 59 >> Date : 2017-06-30 >>=20 >> Abstract: >> This document defines a YANG data model that can be used to configure >> and manage Bidirectional Forwarding Detection (BFD). >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > From nobody Tue Jul 25 11:33:13 2017 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 0A054131EA4; Tue, 25 Jul 2017 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZblNYL8D8DMW; Tue, 25 Jul 2017 11:33:09 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E397B131D0A; Tue, 25 Jul 2017 11:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3548; q=dns/txt; s=iport; t=1501007588; x=1502217188; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cEmmBlVW3A5jiMLwNjNm4+wlZ+TZSO/LUmt6cuNO4B4=; b=CAu9q2/63P4SMZamQBpNd6o3Y7gdovqkwYan9ZbW8oDMkSyO2I0o4shb kyngHbViuq4ffHiDmAj0K05OhrXbsX4XT0IvL1s9fZzQcXoASRQyuHLxp eQ38lFeqHQB2UIa4TTYukLNcFqWHGbBY1uq0JSKTeHO+OWMc4Iqox3FBr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACujXdZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgWRaJYGDoIELoUZAoM4PxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQN5DAQCAQgRBAEBAScHMhQJCAIEAQ0Fii8Qs02LSQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2DKINNhQWDJoEaARIBhhMFkSuOLAKHTYxQggxXhHmKXZVoAR84fwt?= =?us-ascii?q?3FR+HQgF2hwSBIwGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,412,1496102400"; d="scan'208";a="461069985" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2017 18:33:07 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6PIX7dh024597 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 18:33:08 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 13:33:07 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Tue, 25 Jul 2017 13:33:07 -0500 From: "Reshad Rahman (rrahman)" To: Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+A Date: Tue, 25 Jul 2017 18:33:07 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.29] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4146EE365BB7FA4687418C191DA09329@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 18:33:12 -0000 Hi Yingzhen, The grouping is available @ https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd-c lients.yang If you=B9d like changes to the grouping, send me an email. Regards, Reshad. On 2017-07-21, 12:22 PM, "Yingzhen Qu" wrote: >Hi Reshad, > >Thanks for the summary. > >Both ospf and isis models will make corresponding changes when the new >BFD grouping is available. > >Thanks, >Yingzhen > >-----Original Message----- >From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >Sent: Thursday, July 20, 2017 7:19 AM >To: Jeffrey Haas ; rtg-bfd@ietf.org >Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org >Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt > >We (BFD and OSPF YANG authors) had a discussion yesterday. > >The agreement is that since IGP peers are auto-discovered, we want to add >back the basic BFD config (multiplier + intervals) in IGP via a grouping. >BFD will provide that grouping in a specific YANG module. IGP BFD YANG >will be in a separate module (separate from the main IGP module). > > >Regards, >Reshad. > >On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" > wrote: > >>Thanks authors for the edits on the BFD yang module. This gets us a >>significant step closer to alignment with the rest of IETF for network >>instancing. >> >>I'd like to encourage the working group to provide feedback on this >>issue and also the changes in the module. >> >>As noted in another thread, we still have to figure out how to deal >>with accommodating interaction of the BFD yang module with client >>protocols. >>For >>example, the IGPs. In particular, how do you configure the properties >>of the BFD sessions that may be dynamically instantiated based on >>control protocol activity? >> >>-- Jeff >> >>On Fri, Jun 30, 2017 at 12:55:59PM -0700, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Bidirectional Forwarding Detection >>>of the IETF. >>>=20 >>> Title : YANG Data Model for Bidirectional Forwarding >>>Detection (BFD) >>> Authors : Reshad Rahman >>> Lianshu Zheng >>> Mahesh Jethanandani >>> Santosh Pallagatti >>> Greg Mirsky >>> Filename : draft-ietf-bfd-yang-06.txt >>> Pages : 59 >>> Date : 2017-06-30 >>>=20 >>> Abstract: >>> This document defines a YANG data model that can be used to >>>configure >>> and manage Bidirectional Forwarding Detection (BFD). >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>>submission until the htmlized version and diff are available at >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> From nobody Tue Jul 25 13:17:19 2017 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 A1CA0131ECA; Tue, 25 Jul 2017 13:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 ytdO-eNledF1; Tue, 25 Jul 2017 13:17:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309A0131687; Tue, 25 Jul 2017 13:17:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSA11354; Tue, 25 Jul 2017 20:17:11 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 25 Jul 2017 21:17:10 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Tue, 25 Jul 2017 13:17:05 -0700 From: Yingzhen Qu To: "Reshad Rahman (rrahman)" , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAAL3DA= Date: Tue, 25 Jul 2017 20:17:04 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B536D08@dfweml501-mbx> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.93] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.5977A748.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d620cfb2812958a2ecbedbaf8b4840db Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 20:17:17 -0000 Hi Reshad, Thanks for letting me know. I'll work on the ospf part and keep you posted. Thanks, Yingzhen -----Original Message----- From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]=20 Sent: Tuesday, July 25, 2017 11:33 AM To: Yingzhen Qu ; Jeffrey Haas ; rt= g-bfd@ietf.org Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Hi Yingzhen, The grouping is available @ https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd-c lients.yang If you=B9d like changes to the grouping, send me an email. Regards, Reshad. On 2017-07-21, 12:22 PM, "Yingzhen Qu" wrote: >Hi Reshad, > >Thanks for the summary. > >Both ospf and isis models will make corresponding changes when the new=20 >BFD grouping is available. > >Thanks, >Yingzhen > >-----Original Message----- >From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >Sent: Thursday, July 20, 2017 7:19 AM >To: Jeffrey Haas ; rtg-bfd@ietf.org >Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org >Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt > >We (BFD and OSPF YANG authors) had a discussion yesterday. > >The agreement is that since IGP peers are auto-discovered, we want to=20 >add back the basic BFD config (multiplier + intervals) in IGP via a groupi= ng. >BFD will provide that grouping in a specific YANG module. IGP BFD YANG=20 >will be in a separate module (separate from the main IGP module). > > >Regards, >Reshad. > >On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" > wrote: > >>Thanks authors for the edits on the BFD yang module. This gets us a=20 >>significant step closer to alignment with the rest of IETF for network=20 >>instancing. >> >>I'd like to encourage the working group to provide feedback on this=20 >>issue and also the changes in the module. >> >>As noted in another thread, we still have to figure out how to deal=20 >>with accommodating interaction of the BFD yang module with client=20 >>protocols. >>For >>example, the IGPs. In particular, how do you configure the properties=20 >>of the BFD sessions that may be dynamically instantiated based on=20 >>control protocol activity? >> >>-- Jeff >> >>On Fri, Jun 30, 2017 at 12:55:59PM -0700, internet-drafts@ietf.org wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>directories. >>> This draft is a work item of the Bidirectional Forwarding Detection=20 >>>of the IETF. >>>=20 >>> Title : YANG Data Model for Bidirectional Forwarding >>>Detection (BFD) >>> Authors : Reshad Rahman >>> Lianshu Zheng >>> Mahesh Jethanandani >>> Santosh Pallagatti >>> Greg Mirsky >>> Filename : draft-ietf-bfd-yang-06.txt >>> Pages : 59 >>> Date : 2017-06-30 >>>=20 >>> Abstract: >>> This document defines a YANG data model that can be used to=20 >>>configure >>> and manage Bidirectional Forwarding Detection (BFD). >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of=20 >>>submission until the htmlized version and diff are available at=20 >>>tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> From nobody Thu Jul 27 12:07:44 2017 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 5FF661320B8; Thu, 27 Jul 2017 12:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2FNnmI8sxTr; Thu, 27 Jul 2017 12:07:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5366B12EC2B; Thu, 27 Jul 2017 12:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5778; q=dns/txt; s=iport; t=1501182461; x=1502392061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0EV2662T9LlJA7naeaZHFeof2VgwJjO4XTbrsI0fQk8=; b=jovctx43doYs6mTskaUnMuVagaPNEG5rMYbKQlurmoDbP/wG9T355CW7 p8lvtUYxs+k0zmU/+Q92RNR4h442HT/Ly82s8IzGKIwC1okLg2/nz1+ms 2FbOMakQ8Njb9srhpyPOMmH+4cr0uqz32fl/sQxdagLSJnjhuXd1IC7mW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADROHpZ/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0Fii8Qr3KCJos9AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELgh2IUoMmgRoBEgEfF4J8gmEFn2YCh02MVoI?= =?us-ascii?q?MV4R7il6VcQEfOH8LdxUfh0IBdodPgSOBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="462494355" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Jul 2017 19:07:40 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6RJ7eQR017041 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:07:40 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 15:07:39 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 15:07:39 -0400 From: "Acee Lindem (acee)" To: "Reshad Rahman (rrahman)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioA= Date: Thu, 27 Jul 2017 19:07:39 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:07:43 -0000 SGkgUmVzaGFkLCANCldoeSBkbyB3ZSBuZWVkIGEgbmV3IFlBTkcgbW9kZWwgZm9yIGNsaWVudHM/ IFdoeSBjYW7igJl0IHRoZXkganVzdCB1c2UNCmlldGYtYmZkLXR5cGVzLnlhbmc/IEnigJlkIGxp a2UgdG8gYXZvaWQgdGhlIHVubmVjZXNzYXJ5IGxldmVscyBvZg0KaW5kaXJlY3Rpb24uIEluIGZh Y3QsIGl0IGxvb2tzIHdyb25nIHRvIG1lIHNpbmNlIHRoZSBncm91cGluZw0KYmZkLWNsaWVudC1l eHQtY2ZnLXBhcm1zIHVzZXMgdGhlIGdyb3VwaW5nIGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJt cw0Kd2hpY2ggb25seSBjb250YWlucyB0aGUgZW5hYmxlZCBsZWFmLiBJIGJlbGlldmUgeW91IG1l YW50IHRvIHVzZQ0KYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90aGVyIG5l dyBtb2RlbC4gSG93ZXZlciwgSSBkb27igJl0IHNlZQ0KYW55IHJlYXNvbiB3aHkgY2xpZW50IHNo b3VsZG7igJl0IHVzZSB0aGlzIGRpcmVjdGx5Lg0KVGhhbmtzLA0KQWNlZSANCg0KT24gNy8yNS8x NywgMjozMyBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+ IHdyb3RlOg0KDQo+SGkgWWluZ3poZW4sDQo+DQo+VGhlIGdyb3VwaW5nIGlzIGF2YWlsYWJsZSBA DQo+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rl ci9zcmMveWFuZy9pZXRmLWJmZC0NCj5jDQo+bGllbnRzLnlhbmcNCj4NCj5JZiB5b3XCuWQgbGlr ZSBjaGFuZ2VzIHRvIHRoZSBncm91cGluZywgc2VuZCBtZSBhbiBlbWFpbC4NCj4NCj5SZWdhcmRz LA0KPlJlc2hhZC4NCj4NCj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8 eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+DQo+PkhpIFJlc2hhZCwNCj4+DQo+PlRo YW5rcyBmb3IgdGhlIHN1bW1hcnkuDQo+Pg0KPj5Cb3RoIG9zcGYgYW5kIGlzaXMgbW9kZWxzIHdp bGwgbWFrZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgd2hlbiB0aGUgbmV3DQo+PkJGRCBncm91cGlu ZyBpcyBhdmFpbGFibGUuDQo+Pg0KPj5UaGFua3MsDQo+Pllpbmd6aGVuDQo+Pg0KPj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBSZXNoYWQgUmFobWFuIChycmFobWFuKSBbbWFp bHRvOnJyYWhtYW5AY2lzY28uY29tXQ0KPj5TZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyA3 OjE5IEFNDQo+PlRvOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPjsgcnRnLWJmZEBpZXRm Lm9yZw0KPj5DYzogZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vc3Bm LXlhbmdAaWV0Zi5vcmcNCj4+U3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZk LXlhbmctMDYudHh0DQo+Pg0KPj5XZSAoQkZEIGFuZCBPU1BGIFlBTkcgYXV0aG9ycykgaGFkIGEg ZGlzY3Vzc2lvbiB5ZXN0ZXJkYXkuDQo+Pg0KPj5UaGUgYWdyZWVtZW50IGlzIHRoYXQgc2luY2Ug SUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdlIHdhbnQgdG8gYWRkDQo+PmJhY2sgdGhl IGJhc2ljIEJGRCBjb25maWcgKG11bHRpcGxpZXIgKyBpbnRlcnZhbHMpIGluIElHUCB2aWEgYSBn cm91cGluZy4NCj4+QkZEIHdpbGwgcHJvdmlkZSB0aGF0IGdyb3VwaW5nIGluIGEgc3BlY2lmaWMg WUFORyBtb2R1bGUuIElHUCBCRkQgWUFORw0KPj53aWxsIGJlIGluIGEgc2VwYXJhdGUgbW9kdWxl IChzZXBhcmF0ZSBmcm9tIHRoZSBtYWluIElHUCBtb2R1bGUpLg0KPj4NCj4+DQo+PlJlZ2FyZHMs DQo+PlJlc2hhZC4NCj4+DQo+Pk9uIDIwMTctMDctMDUsIDEyOjIxIFBNLCAiUnRnLWJmZCBvbiBi ZWhhbGYgb2YgSmVmZnJleSBIYWFzIg0KPj48cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+Pg0KPj4+VGhhbmtzIGF1dGhvcnMgZm9y IHRoZSBlZGl0cyBvbiB0aGUgQkZEIHlhbmcgbW9kdWxlLiAgVGhpcyBnZXRzIHVzIGENCj4+PnNp Z25pZmljYW50IHN0ZXAgY2xvc2VyIHRvIGFsaWdubWVudCB3aXRoIHRoZSByZXN0IG9mIElFVEYg Zm9yIG5ldHdvcmsNCj4+Pmluc3RhbmNpbmcuDQo+Pj4NCj4+PkknZCBsaWtlIHRvIGVuY291cmFn ZSB0aGUgd29ya2luZyBncm91cCB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHRoaXMNCj4+Pmlzc3Vl IGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4NCj4+PkFzIG5vdGVkIGlu IGFub3RoZXIgdGhyZWFkLCB3ZSBzdGlsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGRlYWwN Cj4+PndpdGggYWNjb21tb2RhdGluZyBpbnRlcmFjdGlvbiBvZiB0aGUgQkZEIHlhbmcgbW9kdWxl IHdpdGggY2xpZW50DQo+Pj5wcm90b2NvbHMuDQo+Pj5Gb3INCj4+PmV4YW1wbGUsIHRoZSBJR1Bz LiAgSW4gcGFydGljdWxhciwgaG93IGRvIHlvdSBjb25maWd1cmUgdGhlIHByb3BlcnRpZXMNCj4+ Pm9mIHRoZSBCRkQgc2Vzc2lvbnMgdGhhdCBtYXkgYmUgZHluYW1pY2FsbHkgaW5zdGFudGlhdGVk IGJhc2VkIG9uDQo+Pj5jb250cm9sIHByb3RvY29sIGFjdGl2aXR5Pw0KPj4+DQo+Pj4tLSBKZWZm DQo+Pj4NCj4+Pk9uIEZyaSwgSnVuIDMwLCAyMDE3IGF0IDEyOjU1OjU5UE0gLTA3MDAsIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4+d3JvdGU6DQo+Pj4+IA0KPj4+PiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ Pj5kaXJlY3Rvcmllcy4NCj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPj4+Pm9mIHRoZSBJRVRGLg0KPj4+PiAN Cj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIEJpZGly ZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+PkRldGVjdGlvbiAoQkZEKQ0KPj4+PiAgICAgICAgIEF1 dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBMaWFuc2h1IFpoZW5nDQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFoZXNo IEpldGhhbmFuZGFuaQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFs bGFnYXR0aQ0KPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcgTWlyc2t5DQo+Pj4+ IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+PiAJUGFn ZXMgICAgICAgICAgIDogNTkNCj4+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDYtMzANCj4+ Pj4gDQo+Pj4+IEFic3RyYWN0Og0KPj4+PiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5H IGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCB0bw0KPj4+PmNvbmZpZ3VyZQ0KPj4+PiAgICBh bmQgbWFuYWdlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWJmZC15YW5nLw0KPj4+PiANCj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4gDQo+Pj4+IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4gDQo+Pj4+ IA0KPj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZg0KPj4+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj50b29scy5pZXRmLm9yZy4NCj4+Pj4g DQo+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pg0KPg0K DQo= From nobody Thu Jul 27 12:19:34 2017 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 00213131DAF; Thu, 27 Jul 2017 12:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTQZib2cIP4t; Thu, 27 Jul 2017 12:19:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAEDB126C0F; Thu, 27 Jul 2017 12:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6786; q=dns/txt; s=iport; t=1501183169; x=1502392769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4rUu/zXseZ42y/n1CJx23CLx8cdRyaJ1Itna2Xus0ag=; b=V7ZKIIoBQRwKii6WUpndP3RSTKDqeLoWAoBIGhNAR2VEbJNKPcz7/f60 qzpH2GLbzjCliGjxU9E7pa4/N0v63p/mU+Tcqwi0INfaWr+6mBKY7tiGF ML/4hI0f+Pc3rBvd3OZO1EH2Lf5nJM8d1aNgAJhRLFNFM5BQ+xy6fT1as A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAABcPHpZ/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDNEUMBAIBCBEEAQEBBCMFAgIwFAkIAgQBDQWKLxCSAp1cBoIoi0ABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQWCI4NNhQWDJoEaARIBHxeCdoJnBZ9mAodNjFa?= =?us-ascii?q?CDFeEe4pelXEBHzh/C3cVH4dCAXaHT4EjAYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="273566186" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:19:28 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6RJJSj2008098 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:19:28 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 14:19:28 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 14:19:27 -0500 From: "Reshad Rahman (rrahman)" To: "Acee Lindem (acee)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAA== Date: Thu, 27 Jul 2017 19:19:27 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.94] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:19:32 -0000 SGkgQWNlZSwNCg0KV2hlbiB3ZSBtZXQgd2UgYWdyZWVkIHRvIGhhdmUgYSBuZXcgbW9kZWwgZm9y IGNsaWVudHMuIEFmdGVyd2FyZHMgSQ0KZGVjaWRlZCB0byBjcmVhdGUgYSBuZXcgdHlwZXMgbW9k dWxlLCBhbmQgc3RpbGwgd2VudCBhaGVhZCB3aXRoIHRoZQ0KY2xpZW50cyBtb2R1bGUuIEkgYW0g ZmluZSB3aXRoIGhhdmluZyBldmVyeXRoaW5nIGluIHRoZSB0eXBlcyBtb2R1bGUgKG5vDQpjbGll bnQgbW9kdWxlKS4NCg0KSSBhbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgeW91ciBjb21t ZW50L3F1ZXN0aW9uIG9uDQpiZmQtY2xpZW50LWV4dC1jZmctcGFybXMvYmZkLWdyb3VwaW5nLWNv bW1vbi1jZmctcGFybXMuIFRoZSByZWFzb24gd2UgaGF2ZQ0KMiBncm91cGluZ3MgaXMgdGhhdCBz b21lIHByb3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgZW5hYmxlIGxlYWYNCmFu ZCBvdGhlcnMgbWF5IGFsc28gd2FudCB0aGUgbXVsdGlwbGllci90aW1lci4NCg0KUmVnYXJkcywN ClJlc2hhZC4NCg0KDQoNCk9uIDIwMTctMDctMjcsIDM6MDcgUE0sICJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBSZXNoYWQsIA0KPldoeSBkbyB3ZSBu ZWVkIGEgbmV3IFlBTkcgbW9kZWwgZm9yIGNsaWVudHM/IFdoeSBjYW6hr3QgdGhleSBqdXN0IHVz ZQ0KPmlldGYtYmZkLXR5cGVzLnlhbmc/IEmhr2QgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3Nh cnkgbGV2ZWxzIG9mDQo+aW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tzIHdyb25nIHRvIG1l IHNpbmNlIHRoZSBncm91cGluZw0KPmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBn cm91cGluZyBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMNCj53aGljaCBvbmx5IGNvbnRhaW5z IHRoZSBlbmFibGVkIGxlYWYuIEkgYmVsaWV2ZSB5b3UgbWVhbnQgdG8gdXNlDQo+YmZkLWdyb3Vw aW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90aGVyIG5ldyBtb2RlbC4gSG93ZXZlciwgSSBk b26hr3Qgc2VlDQo+YW55IHJlYXNvbiB3aHkgY2xpZW50IHNob3VsZG6hr3QgdXNlIHRoaXMgZGly ZWN0bHkuDQo+VGhhbmtzLA0KPkFjZWUgDQo+DQo+T24gNy8yNS8xNywgMjozMyBQTSwgIlJlc2hh ZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5IaSBZ aW5nemhlbiwNCj4+DQo+PlRoZSBncm91cGluZyBpcyBhdmFpbGFibGUgQA0KPj5odHRwczovL2dp dGh1Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2ll dGYtYmZkDQo+Pi0NCj4+Yw0KPj5saWVudHMueWFuZw0KPj4NCj4+SWYgeW91qfZkIGxpa2UgY2hh bmdlcyB0byB0aGUgZ3JvdXBpbmcsIHNlbmQgbWUgYW4gZW1haWwuDQo+Pg0KPj5SZWdhcmRzLA0K Pj5SZXNoYWQuDQo+Pg0KPj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8 eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SGkgUmVzaGFkLA0KPj4+DQo+ Pj5UaGFua3MgZm9yIHRoZSBzdW1tYXJ5Lg0KPj4+DQo+Pj5Cb3RoIG9zcGYgYW5kIGlzaXMgbW9k ZWxzIHdpbGwgbWFrZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgd2hlbiB0aGUgbmV3DQo+Pj5CRkQg Z3JvdXBpbmcgaXMgYXZhaWxhYmxlLg0KPj4+DQo+Pj5UaGFua3MsDQo+Pj5ZaW5nemhlbg0KPj4+ DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogUmVzaGFkIFJhaG1hbiAo cnJhaG1hbikgW21haWx0bzpycmFobWFuQGNpc2NvLmNvbV0NCj4+PlNlbnQ6IFRodXJzZGF5LCBK dWx5IDIwLCAyMDE3IDc6MTkgQU0NCj4+PlRvOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3Jn PjsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+Q2M6IGRyYWZ0LWlldGYtYmZkLXlhbmdAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+Pj5TdWJqZWN0OiBSZTogSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pg0KPj4+V2UgKEJGRCBhbmQgT1NQRiBZ QU5HIGF1dGhvcnMpIGhhZCBhIGRpc2N1c3Npb24geWVzdGVyZGF5Lg0KPj4+DQo+Pj5UaGUgYWdy ZWVtZW50IGlzIHRoYXQgc2luY2UgSUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdlIHdh bnQgdG8NCj4+PmFkZA0KPj4+YmFjayB0aGUgYmFzaWMgQkZEIGNvbmZpZyAobXVsdGlwbGllciAr IGludGVydmFscykgaW4gSUdQIHZpYSBhDQo+Pj5ncm91cGluZy4NCj4+PkJGRCB3aWxsIHByb3Zp ZGUgdGhhdCBncm91cGluZyBpbiBhIHNwZWNpZmljIFlBTkcgbW9kdWxlLiBJR1AgQkZEIFlBTkcN Cj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBtb2R1bGUgKHNlcGFyYXRlIGZyb20gdGhlIG1haW4g SUdQIG1vZHVsZSkuDQo+Pj4NCj4+Pg0KPj4+UmVnYXJkcywNCj4+PlJlc2hhZC4NCj4+Pg0KPj4+ T24gMjAxNy0wNy0wNSwgMTI6MjEgUE0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhh YXMiDQo+Pj48cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqaGFhc0BwZnJj Lm9yZz4gd3JvdGU6DQo+Pj4NCj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRo ZSBCRkQgeWFuZyBtb2R1bGUuICBUaGlzIGdldHMgdXMgYQ0KPj4+PnNpZ25pZmljYW50IHN0ZXAg Y2xvc2VyIHRvIGFsaWdubWVudCB3aXRoIHRoZSByZXN0IG9mIElFVEYgZm9yIG5ldHdvcmsNCj4+ Pj5pbnN0YW5jaW5nLg0KPj4+Pg0KPj4+PkknZCBsaWtlIHRvIGVuY291cmFnZSB0aGUgd29ya2lu ZyBncm91cCB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHRoaXMNCj4+Pj5pc3N1ZSBhbmQgYWxzbyB0 aGUgY2hhbmdlcyBpbiB0aGUgbW9kdWxlLg0KPj4+Pg0KPj4+PkFzIG5vdGVkIGluIGFub3RoZXIg dGhyZWFkLCB3ZSBzdGlsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGRlYWwNCj4+Pj53aXRo IGFjY29tbW9kYXRpbmcgaW50ZXJhY3Rpb24gb2YgdGhlIEJGRCB5YW5nIG1vZHVsZSB3aXRoIGNs aWVudA0KPj4+PnByb3RvY29scy4NCj4+Pj5Gb3INCj4+Pj5leGFtcGxlLCB0aGUgSUdQcy4gIElu IHBhcnRpY3VsYXIsIGhvdyBkbyB5b3UgY29uZmlndXJlIHRoZSBwcm9wZXJ0aWVzDQo+Pj4+b2Yg dGhlIEJGRCBzZXNzaW9ucyB0aGF0IG1heSBiZSBkeW5hbWljYWxseSBpbnN0YW50aWF0ZWQgYmFz ZWQgb24NCj4+Pj5jb250cm9sIHByb3RvY29sIGFjdGl2aXR5Pw0KPj4+Pg0KPj4+Pi0tIEplZmYN Cj4+Pj4NCj4+Pj5PbiBGcmksIEp1biAzMCwgMjAxNyBhdCAxMjo1NTo1OVBNIC0wNzAwLCBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj53cm90ZToNCj4+Pj4+IA0KPj4+Pj4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz DQo+Pj4+PmRpcmVjdG9yaWVzLg0KPj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPj4+Pj5vZiB0aGUgSUVURi4N Cj4+Pj4+IA0KPj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwg Zm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Rm9yd2FyZGluZw0KPj4+Pj5EZXRlY3Rpb24gKEJGRCkN Cj4+Pj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUmVzaGFkIFJhaG1hbg0KPj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBMaWFuc2h1IFpoZW5nDQo+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIEdyZWcgTWlyc2t5DQo+Pj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1iZmQt eWFuZy0wNi50eHQNCj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA1OQ0KPj4+Pj4gCURhdGUgICAg ICAgICAgICA6IDIwMTctMDYtMzANCj4+Pj4+IA0KPj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+PiAgICBU aGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZCB0 bw0KPj4+Pj5jb25maWd1cmUNCj4+Pj4+ICAgIGFuZCBtYW5hZ2UgQmlkaXJlY3Rpb25hbCBGb3J3 YXJkaW5nIERldGVjdGlvbiAoQkZEKS4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQteWFuZy8NCj4+ Pj4+IA0KPj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0 Og0KPj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmct MDYNCj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1iZmQteWFuZy0wNg0KPj4+Pj4gDQo+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+Pj4+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+dG9vbHMuaWV0Zi5vcmcuDQo+Pj4+PiANCj4+Pj4+IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+ Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+DQo+Pg0KPg0KDQo= From nobody Thu Jul 27 12:30:07 2017 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 E2A07131C31; Thu, 27 Jul 2017 12:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2JvXFx7tKv0; Thu, 27 Jul 2017 12:30:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D984129562; Thu, 27 Jul 2017 12:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7846; q=dns/txt; s=iport; t=1501183803; x=1502393403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E+t/rheK4G9qZXIitf7bd0IBZfU46eOiHBPCitLfBpM=; b=Kc/3kLVv9+E0enWlT61HkezDoGx34EerZgXK+kok596WDtgcAyID+t9a Hw66Qg6wHjgH976qNuM6p6q3w3H5FRlUEdQ3YQukHhn5StEiqPcoSHEh8 UH/vqM6o1zQfuoJ5AeH8NW6FGUDDfPpTzdXBaYZ0zXwjl6Gl7g/neAL/e k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAC6PnpZ/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0Fii8Qr3CCJos/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELgh2IUoMmgRoBEgEfF4J8gmEFn2YCh02MVoI?= =?us-ascii?q?MV4R7il6VcQEfOH8LdxUfh0IBdodCDRcHgQWBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="265039222" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:30:02 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6RJU12J021523 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:30:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 15:30:01 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 15:30:00 -0400 From: "Acee Lindem (acee)" To: "Reshad Rahman (rrahman)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkA Date: Thu, 27 Jul 2017 19:30:00 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:30:06 -0000 SGkgUmVzaGFkLCANCg0KT24gNy8yNy8xNywgMzoxOSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWht YW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj4NCj5XaGVuIHdl IG1ldCB3ZSBhZ3JlZWQgdG8gaGF2ZSBhIG5ldyBtb2RlbCBmb3IgY2xpZW50cy4gQWZ0ZXJ3YXJk cyBJDQo+ZGVjaWRlZCB0byBjcmVhdGUgYSBuZXcgdHlwZXMgbW9kdWxlLCBhbmQgc3RpbGwgd2Vu dCBhaGVhZCB3aXRoIHRoZQ0KPmNsaWVudHMgbW9kdWxlLiBJIGFtIGZpbmUgd2l0aCBoYXZpbmcg ZXZlcnl0aGluZyBpbiB0aGUgdHlwZXMgbW9kdWxlIChubw0KPmNsaWVudCBtb2R1bGUpLg0KDQpB bHRob3VnaCBJIGRvbuKAmXQgZmVlbCB0aGF0IHN0cm9uZ2x5IC0gSSBqdXN0IGRvbuKAmXQgc2Vl IHRoYXQgcHV0dGluZyB0aGUNCmNsaWVudCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3Zp ZGVzIGFueSBiZW5lZml0LiBBcyBmb3IgZGV0cmltZW50cywNCml0IHJlcXVpcmVzIG1vcmUgb25l IG1vcmUgbG9jYWwgbW9kdWxlcyBmb3IgdmFsaWRhdGlvbiBhbmQgb25lIG1vcmUgbGV2ZWwNCm9m IGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0IHdlIGFyZSByZWFsbHkgYWxsb3dpbmcgdG8gYmUgY29u ZmlndXJlZC4NCg0KPg0KPkkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29t bWVudC9xdWVzdGlvbiBvbg0KPmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcy9iZmQtZ3JvdXBpbmct Y29tbW9uLWNmZy1wYXJtcy4gVGhlIHJlYXNvbiB3ZSBoYXZlDQo+MiBncm91cGluZ3MgaXMgdGhh dCBzb21lIHByb3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgZW5hYmxlIGxlYWYN Cj5hbmQgb3RoZXJzIG1heSBhbHNvIHdhbnQgdGhlIG11bHRpcGxpZXIvdGltZXIuDQoNClRoZSBi ZmQtY2xpZW50LWV4dC1jZmctcGFybXMgZ3JvdXBpbmcgc2hvdWxkIHVzZQ0KYmZkLXR5cGVzOmJm ZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIHJhdGhlciB0aGFuDQpiZmQtdHlwZXM6YmZkLWNs aWVudC1iYXNlLWNmZy1wYXJtcyAtIG5vPyBUaGlzIHdvdWxkIGJlIG1vcmUgb2J2aW91cyB3L28N CnRoZSBjbGllbnQgbW9kdWxlLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KDQo+DQo+UmVnYXJkcywN Cj5SZXNoYWQuDQo+DQo+DQo+DQo+T24gMjAxNy0wNy0yNywgMzowNyBQTSwgIkFjZWUgTGluZGVt IChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+SGkgUmVzaGFkLCANCj4+V2h5 IGRvIHdlIG5lZWQgYSBuZXcgWUFORyBtb2RlbCBmb3IgY2xpZW50cz8gV2h5IGNhbuKAmXQgdGhl eSBqdXN0IHVzZQ0KPj5pZXRmLWJmZC10eXBlcy55YW5nPyBJ4oCZZCBsaWtlIHRvIGF2b2lkIHRo ZSB1bm5lY2Vzc2FyeSBsZXZlbHMgb2YNCj4+aW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tz IHdyb25nIHRvIG1lIHNpbmNlIHRoZSBncm91cGluZw0KPj5iZmQtY2xpZW50LWV4dC1jZmctcGFy bXMgdXNlcyB0aGUgZ3JvdXBpbmcgYmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+PndoaWNo IG9ubHkgY29udGFpbnMgdGhlIGVuYWJsZWQgbGVhZi4gSSBiZWxpZXZlIHlvdSBtZWFudCB0byB1 c2UNCj4+YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90aGVyIG5ldyBtb2Rl bC4gSG93ZXZlciwgSSBkb27igJl0DQo+PnNlZQ0KPj5hbnkgcmVhc29uIHdoeSBjbGllbnQgc2hv dWxkbuKAmXQgdXNlIHRoaXMgZGlyZWN0bHkuDQo+PlRoYW5rcywNCj4+QWNlZSANCj4+DQo+Pk9u IDcvMjUvMTcsIDI6MzMgUE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lz Y28uY29tPiB3cm90ZToNCj4+DQo+Pj5IaSBZaW5nemhlbiwNCj4+Pg0KPj4+VGhlIGdyb3VwaW5n IGlzIGF2YWlsYWJsZSBADQo+Pj5odHRwczovL2dpdGh1Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJm ZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldGYtYmYNCj4+PmQNCj4+Pi0NCj4+PmMNCj4+ PmxpZW50cy55YW5nDQo+Pj4NCj4+PklmIHlvdcK5ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3Vw aW5nLCBzZW5kIG1lIGFuIGVtYWlsLg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+UmVzaGFkLg0KPj4+ DQo+Pj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8eWluZ3poZW4ucXVA aHVhd2VpLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj5IaSBSZXNoYWQsDQo+Pj4+DQo+Pj4+VGhhbmtz IGZvciB0aGUgc3VtbWFyeS4NCj4+Pj4NCj4+Pj5Cb3RoIG9zcGYgYW5kIGlzaXMgbW9kZWxzIHdp bGwgbWFrZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgd2hlbiB0aGUgbmV3DQo+Pj4+QkZEIGdyb3Vw aW5nIGlzIGF2YWlsYWJsZS4NCj4+Pj4NCj4+Pj5UaGFua3MsDQo+Pj4+WWluZ3poZW4NCj4+Pj4N Cj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PkZyb206IFJlc2hhZCBSYWhtYW4g KHJyYWhtYW4pIFttYWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+U2VudDogVGh1cnNkYXks IEp1bHkgMjAsIDIwMTcgNzoxOSBBTQ0KPj4+PlRvOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMu b3JnPjsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+PkNjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYu b3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KPj4+PlN1YmplY3Q6IFJlOiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pg0KPj4+PldlIChCRkQgYW5k IE9TUEYgWUFORyBhdXRob3JzKSBoYWQgYSBkaXNjdXNzaW9uIHllc3RlcmRheS4NCj4+Pj4NCj4+ Pj5UaGUgYWdyZWVtZW50IGlzIHRoYXQgc2luY2UgSUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVy ZWQsIHdlIHdhbnQgdG8NCj4+Pj5hZGQNCj4+Pj5iYWNrIHRoZSBiYXNpYyBCRkQgY29uZmlnICht dWx0aXBsaWVyICsgaW50ZXJ2YWxzKSBpbiBJR1AgdmlhIGENCj4+Pj5ncm91cGluZy4NCj4+Pj5C RkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4g SUdQIEJGRCBZQU5HDQo+Pj4+d2lsbCBiZSBpbiBhIHNlcGFyYXRlIG1vZHVsZSAoc2VwYXJhdGUg ZnJvbSB0aGUgbWFpbiBJR1AgbW9kdWxlKS4NCj4+Pj4NCj4+Pj4NCj4+Pj5SZWdhcmRzLA0KPj4+ PlJlc2hhZC4NCj4+Pj4NCj4+Pj5PbiAyMDE3LTA3LTA1LCAxMjoyMSBQTSwgIlJ0Zy1iZmQgb24g YmVoYWxmIG9mIEplZmZyZXkgSGFhcyINCj4+Pj48cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+Pj4+DQo+Pj4+PlRoYW5rcyBhdXRo b3JzIGZvciB0aGUgZWRpdHMgb24gdGhlIEJGRCB5YW5nIG1vZHVsZS4gIFRoaXMgZ2V0cyB1cyBh DQo+Pj4+PnNpZ25pZmljYW50IHN0ZXAgY2xvc2VyIHRvIGFsaWdubWVudCB3aXRoIHRoZSByZXN0 IG9mIElFVEYgZm9yIG5ldHdvcmsNCj4+Pj4+aW5zdGFuY2luZy4NCj4+Pj4+DQo+Pj4+PkknZCBs aWtlIHRvIGVuY291cmFnZSB0aGUgd29ya2luZyBncm91cCB0byBwcm92aWRlIGZlZWRiYWNrIG9u IHRoaXMNCj4+Pj4+aXNzdWUgYW5kIGFsc28gdGhlIGNoYW5nZXMgaW4gdGhlIG1vZHVsZS4NCj4+ Pj4+DQo+Pj4+PkFzIG5vdGVkIGluIGFub3RoZXIgdGhyZWFkLCB3ZSBzdGlsbCBoYXZlIHRvIGZp Z3VyZSBvdXQgaG93IHRvIGRlYWwNCj4+Pj4+d2l0aCBhY2NvbW1vZGF0aW5nIGludGVyYWN0aW9u IG9mIHRoZSBCRkQgeWFuZyBtb2R1bGUgd2l0aCBjbGllbnQNCj4+Pj4+cHJvdG9jb2xzLg0KPj4+ Pj5Gb3INCj4+Pj4+ZXhhbXBsZSwgdGhlIElHUHMuICBJbiBwYXJ0aWN1bGFyLCBob3cgZG8geW91 IGNvbmZpZ3VyZSB0aGUgcHJvcGVydGllcw0KPj4+Pj5vZiB0aGUgQkZEIHNlc3Npb25zIHRoYXQg bWF5IGJlIGR5bmFtaWNhbGx5IGluc3RhbnRpYXRlZCBiYXNlZCBvbg0KPj4+Pj5jb250cm9sIHBy b3RvY29sIGFjdGl2aXR5Pw0KPj4+Pj4NCj4+Pj4+LS0gSmVmZg0KPj4+Pj4NCj4+Pj4+T24gRnJp LCBKdW4gMzAsIDIwMTcgYXQgMTI6NTU6NTlQTSAtMDcwMCwgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDQo+Pj4+Pndyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+Pj4+ZGlyZWN0 b3JpZXMuDQo+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQmlkaXJlY3Rp b25hbCBGb3J3YXJkaW5nIERldGVjdGlvbg0KPj4+Pj4+b2YgdGhlIElFVEYuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIEJpZGly ZWN0aW9uYWwNCj4+Pj4+PkZvcndhcmRpbmcNCj4+Pj4+PkRldGVjdGlvbiAoQkZEKQ0KPj4+Pj4+ ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogUmVzaGFkIFJhaG1hbg0KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgTWFoZXNoIEpldGhhbmFuZGFuaQ0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgU2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICBHcmVnIE1pcnNreQ0KPj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC15 YW5nLTA2LnR4dA0KPj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA1OQ0KPj4+Pj4+IAlEYXRlICAg ICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4g ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVz ZWQgdG8NCj4+Pj4+PmNvbmZpZ3VyZQ0KPj4+Pj4+ICAgIGFuZCBtYW5hZ2UgQmlkaXJlY3Rpb25h bCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJm ZC15YW5nLw0KPj4+Pj4+IA0KPj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25z IGF2YWlsYWJsZSBhdDoNCj4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+IA0KPj4+Pj4+IEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+Pj5zdWJtaXNzaW9uICB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4+Pj50b29scy5pZXRm Lm9yZy4NCj4+Pj4+PiANCj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4+Pj4+DQo+Pj4NCj4+DQo+DQoNCg== From nobody Thu Jul 27 12:35:36 2017 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 4D7BA12F290; Thu, 27 Jul 2017 12:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVLGIVIcTL2j; Thu, 27 Jul 2017 12:35:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A921287A5; Thu, 27 Jul 2017 12:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8770; q=dns/txt; s=iport; t=1501184132; x=1502393732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zgaL46eYbPeHkwHIBCRU+4w1q0WNYO4F2d8arcUIEAE=; b=PNxa8Pa+rBIYSyvlWgAU+y/BLNYOB1ogbM+cW3i7HpOpowggSH613eLM Xu1UgfdkJKgGWiEP0bGhQwagFqmD1MJASr0Vm+yiTCn6PrflpaTuNrTn6 UcVMh5RYU4Q0yHxj+KZhvuvnGkjUqoUchhrShVbDiA2MlxN9HHY4CsozJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAACqP3pZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELIUbAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDNEUMBAIBCBEEAQEBBCMFAgIwFAkIAgQBDQWKLxCSFZ1cBoIoiz8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQWCI4NNhQWDJoEaARIBHxeCdoJnBZ9mAodNjFa?= =?us-ascii?q?CDFeEe4pelXEBHzh/C3cVH4dCAXaHQg0XB4EFAYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="273595465" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:35:31 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v6RJZV8u005781 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:35:31 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 14:35:31 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 14:35:30 -0500 From: "Reshad Rahman (rrahman)" To: "Acee Lindem (acee)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgA= Date: Thu, 27 Jul 2017 19:35:30 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.94] Content-Type: text/plain; charset="euc-kr" Content-ID: <1BE4F1D6E2012D428368482425DF945A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:35:35 -0000 SGkgQWNlZSwNCg0KMSkgSaGvbGwgc2VlIGlmIG90aGVycyBjaGltZSBpbiBvbiB0aGlzIGJ1dCBJ IGFtIGZpbmUgd2l0aCBoYXZpbmcgdGhlDQpjbGllbnQgZ3JvdXBpbmcgaW4gaWV0Zi1iZmQtdHlw ZXMueWFuZy4NCjIpIGJmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIGhhcyBtdWNoIG1vcmUg dGhhbiBqdXN0IHRoZQ0KbXVsdGlwbGllci90aW1lcnMgdGhhdCB0aGUgSUdQcyBuZWVkLiBJdCBh bHNvIGhhcyBCRkQgc3BlY2lmaWMgc3R1ZmYNCihkZW1hbmQtbW9kZSwgQkZEIGF1dGgpIHdoaWNo IElNTyBoYXMgbm8gYnVzaW5lc3Mgb3V0c2lkZSBvZiBCRkQuDQpiZmQtZ3JvdXBpbmctYmFzZS1j ZmctcGFybXMgaGFzIG9ubHkgdGhlIG11bHRpcGxpZXIvdGltZXJzLg0KDQpSZWdhcmRzLA0KUmVz aGFkLg0KDQoNCg0KT24gMjAxNy0wNy0yNywgMzozMCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIg PGFjZWVAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIFJlc2hhZCwgDQo+DQo+T24gNy8yNy8xNywg MzoxOSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdy b3RlOg0KPg0KPj5IaSBBY2VlLA0KPj4NCj4+V2hlbiB3ZSBtZXQgd2UgYWdyZWVkIHRvIGhhdmUg YSBuZXcgbW9kZWwgZm9yIGNsaWVudHMuIEFmdGVyd2FyZHMgSQ0KPj5kZWNpZGVkIHRvIGNyZWF0 ZSBhIG5ldyB0eXBlcyBtb2R1bGUsIGFuZCBzdGlsbCB3ZW50IGFoZWFkIHdpdGggdGhlDQo+PmNs aWVudHMgbW9kdWxlLiBJIGFtIGZpbmUgd2l0aCBoYXZpbmcgZXZlcnl0aGluZyBpbiB0aGUgdHlw ZXMgbW9kdWxlIChubw0KPj5jbGllbnQgbW9kdWxlKS4NCj4NCj5BbHRob3VnaCBJIGRvbqGvdCBm ZWVsIHRoYXQgc3Ryb25nbHkgLSBJIGp1c3QgZG9uoa90IHNlZSB0aGF0IHB1dHRpbmcgdGhlDQo+ Y2xpZW50IGNvbmZpZyBwYXJhbXMgaW4gd3JhcHBlcnMgcHJvdmlkZXMgYW55IGJlbmVmaXQuIEFz IGZvciBkZXRyaW1lbnRzLA0KPml0IHJlcXVpcmVzIG1vcmUgb25lIG1vcmUgbG9jYWwgbW9kdWxl cyBmb3IgdmFsaWRhdGlvbiBhbmQgb25lIG1vcmUgbGV2ZWwNCj5vZiBpbmRpcmVjdGlvbiB0byBz ZWUgd2hhdCB3ZSBhcmUgcmVhbGx5IGFsbG93aW5nIHRvIGJlIGNvbmZpZ3VyZWQuDQo+DQo+Pg0K Pj5JIGFtIG5vdCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQvcXVlc3Rpb24g b24NCj4+YmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zL2JmZC1ncm91cGluZy1jb21tb24tY2ZnLXBh cm1zLiBUaGUgcmVhc29uIHdlDQo+PmhhdmUNCj4+MiBncm91cGluZ3MgaXMgdGhhdCBzb21lIHBy b3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgZW5hYmxlDQo+PmxlYWYNCj4+YW5k IG90aGVycyBtYXkgYWxzbyB3YW50IHRoZSBtdWx0aXBsaWVyL3RpbWVyLg0KPg0KPlRoZSBiZmQt Y2xpZW50LWV4dC1jZmctcGFybXMgZ3JvdXBpbmcgc2hvdWxkIHVzZQ0KPmJmZC10eXBlczpiZmQt Z3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPmJmZC10eXBlczpiZmQtY2xp ZW50LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMgd291bGQgYmUgbW9yZSBvYnZpb3VzIHcvbw0K PnRoZSBjbGllbnQgbW9kdWxlLg0KPg0KPlRoYW5rcywNCj5BY2VlIA0KPg0KPg0KPj4NCj4+UmVn YXJkcywNCj4+UmVzaGFkLg0KPj4NCj4+DQo+Pg0KPj5PbiAyMDE3LTA3LTI3LCAzOjA3IFBNLCAi QWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIFJl c2hhZCwgDQo+Pj5XaHkgZG8gd2UgbmVlZCBhIG5ldyBZQU5HIG1vZGVsIGZvciBjbGllbnRzPyBX aHkgY2Fuoa90IHRoZXkganVzdCB1c2UNCj4+PmlldGYtYmZkLXR5cGVzLnlhbmc/IEmhr2QgbGlr ZSB0byBhdm9pZCB0aGUgdW5uZWNlc3NhcnkgbGV2ZWxzIG9mDQo+Pj5pbmRpcmVjdGlvbi4gSW4g ZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUgc2luY2UgdGhlIGdyb3VwaW5nDQo+Pj5iZmQtY2xp ZW50LWV4dC1jZmctcGFybXMgdXNlcyB0aGUgZ3JvdXBpbmcgYmZkLWdyb3VwaW5nLWJhc2UtY2Zn LXBhcm1zDQo+Pj53aGljaCBvbmx5IGNvbnRhaW5zIHRoZSBlbmFibGVkIGxlYWYuIEkgYmVsaWV2 ZSB5b3UgbWVhbnQgdG8gdXNlDQo+Pj5iZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBpbiB0 aGUgb3RoZXIgbmV3IG1vZGVsLiBIb3dldmVyLCBJIGRvbqGvdA0KPj4+c2VlDQo+Pj5hbnkgcmVh c29uIHdoeSBjbGllbnQgc2hvdWxkbqGvdCB1c2UgdGhpcyBkaXJlY3RseS4NCj4+PlRoYW5rcywN Cj4+PkFjZWUgDQo+Pj4NCj4+Pk9uIDcvMjUvMTcsIDI6MzMgUE0sICJSZXNoYWQgUmFobWFuIChy cmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5IaSBZaW5n emhlbiwNCj4+Pj4NCj4+Pj5UaGUgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlIEANCj4+Pj5odHRwczov L2dpdGh1Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5n L2lldGYtYg0KPj4+PmYNCj4+Pj5kDQo+Pj4+LQ0KPj4+PmMNCj4+Pj5saWVudHMueWFuZw0KPj4+ Pg0KPj4+PklmIHlvdan2ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBzZW5kIG1lIGFu IGVtYWlsLg0KPj4+Pg0KPj4+PlJlZ2FyZHMsDQo+Pj4+UmVzaGFkLg0KPj4+Pg0KPj4+Pk9uIDIw MTctMDctMjEsIDEyOjIyIFBNLCAiWWluZ3poZW4gUXUiIDx5aW5nemhlbi5xdUBodWF3ZWkuY29t PiB3cm90ZToNCj4+Pj4NCj4+Pj4+SGkgUmVzaGFkLA0KPj4+Pj4NCj4+Pj4+VGhhbmtzIGZvciB0 aGUgc3VtbWFyeS4NCj4+Pj4+DQo+Pj4+PkJvdGggb3NwZiBhbmQgaXNpcyBtb2RlbHMgd2lsbCBt YWtlIGNvcnJlc3BvbmRpbmcgY2hhbmdlcyB3aGVuIHRoZSBuZXcNCj4+Pj4+QkZEIGdyb3VwaW5n IGlzIGF2YWlsYWJsZS4NCj4+Pj4+DQo+Pj4+PlRoYW5rcywNCj4+Pj4+WWluZ3poZW4NCj4+Pj4+ DQo+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PkZyb206IFJlc2hhZCBSYWht YW4gKHJyYWhtYW4pIFttYWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+PlNlbnQ6IFRodXJz ZGF5LCBKdWx5IDIwLCAyMDE3IDc6MTkgQU0NCj4+Pj4+VG86IEplZmZyZXkgSGFhcyA8amhhYXNA cGZyYy5vcmc+OyBydGctYmZkQGlldGYub3JnDQo+Pj4+PkNjOiBkcmFmdC1pZXRmLWJmZC15YW5n QGlldGYub3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KPj4+Pj5TdWJqZWN0OiBS ZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+DQo+Pj4+Pldl IChCRkQgYW5kIE9TUEYgWUFORyBhdXRob3JzKSBoYWQgYSBkaXNjdXNzaW9uIHllc3RlcmRheS4N Cj4+Pj4+DQo+Pj4+PlRoZSBhZ3JlZW1lbnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1 dG8tZGlzY292ZXJlZCwgd2Ugd2FudCB0bw0KPj4+Pj5hZGQNCj4+Pj4+YmFjayB0aGUgYmFzaWMg QkZEIGNvbmZpZyAobXVsdGlwbGllciArIGludGVydmFscykgaW4gSUdQIHZpYSBhDQo+Pj4+Pmdy b3VwaW5nLg0KPj4+Pj5CRkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZp YyBZQU5HIG1vZHVsZS4gSUdQIEJGRCBZQU5HDQo+Pj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBt b2R1bGUgKHNlcGFyYXRlIGZyb20gdGhlIG1haW4gSUdQIG1vZHVsZSkuDQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+UmVnYXJkcywNCj4+Pj4+UmVzaGFkLg0KPj4+Pj4NCj4+Pj4+T24gMjAxNy0wNy0wNSwg MTI6MjEgUE0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+PjxydGct YmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMub3JnPiB3cm90ZToN Cj4+Pj4+DQo+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRoZSBCRkQgeWFu ZyBtb2R1bGUuICBUaGlzIGdldHMgdXMgYQ0KPj4+Pj4+c2lnbmlmaWNhbnQgc3RlcCBjbG9zZXIg dG8gYWxpZ25tZW50IHdpdGggdGhlIHJlc3Qgb2YgSUVURiBmb3INCj4+Pj4+Pm5ldHdvcmsNCj4+ Pj4+Pmluc3RhbmNpbmcuDQo+Pj4+Pj4NCj4+Pj4+PkknZCBsaWtlIHRvIGVuY291cmFnZSB0aGUg d29ya2luZyBncm91cCB0byBwcm92aWRlIGZlZWRiYWNrIG9uIHRoaXMNCj4+Pj4+Pmlzc3VlIGFu ZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4+Pj4NCj4+Pj4+PkFzIG5vdGVk IGluIGFub3RoZXIgdGhyZWFkLCB3ZSBzdGlsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGRl YWwNCj4+Pj4+PndpdGggYWNjb21tb2RhdGluZyBpbnRlcmFjdGlvbiBvZiB0aGUgQkZEIHlhbmcg bW9kdWxlIHdpdGggY2xpZW50DQo+Pj4+Pj5wcm90b2NvbHMuDQo+Pj4+Pj5Gb3INCj4+Pj4+PmV4 YW1wbGUsIHRoZSBJR1BzLiAgSW4gcGFydGljdWxhciwgaG93IGRvIHlvdSBjb25maWd1cmUgdGhl DQo+Pj4+Pj5wcm9wZXJ0aWVzDQo+Pj4+Pj5vZiB0aGUgQkZEIHNlc3Npb25zIHRoYXQgbWF5IGJl IGR5bmFtaWNhbGx5IGluc3RhbnRpYXRlZCBiYXNlZCBvbg0KPj4+Pj4+Y29udHJvbCBwcm90b2Nv bCBhY3Rpdml0eT8NCj4+Pj4+Pg0KPj4+Pj4+LS0gSmVmZg0KPj4+Pj4+DQo+Pj4+Pj5PbiBGcmks IEp1biAzMCwgMjAxNyBhdCAxMjo1NTo1OVBNIC0wNzAwLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcNCj4+Pj4+Pndyb3RlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj4+Pj4+ZGly ZWN0b3JpZXMuDQo+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGly ZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24NCj4+Pj4+Pj5vZiB0aGUgSUVURi4NCj4+Pj4+ Pj4gDQo+Pj4+Pj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZv ciBCaWRpcmVjdGlvbmFsDQo+Pj4+Pj4+Rm9yd2FyZGluZw0KPj4+Pj4+PkRldGVjdGlvbiAoQkZE KQ0KPj4+Pj4+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBMaWFuc2h1IFpoZW5nDQo+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgTWFoZXNoIEpldGhhbmFuZGFuaQ0KPj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFsbGFnYXR0aQ0KPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgIEdyZWcgTWlyc2t5DQo+Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+PiAJUGFnZXMgICAgICAgICAgIDogNTkN Cj4+Pj4+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDYtMzANCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IEFic3RyYWN0Og0KPj4+Pj4+PiAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEg bW9kZWwgdGhhdCBjYW4gYmUgdXNlZCB0bw0KPj4+Pj4+PmNvbmZpZ3VyZQ0KPj4+Pj4+PiAgICBh bmQgbWFuYWdlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhl cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+PiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmct MDYNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZg0KPj4+Pj4+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+Pj50b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+ Pg0KPj4+Pg0KPj4+DQo+Pg0KPg0KDQo= From nobody Thu Jul 27 12:40:28 2017 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 9F05712EA7C; Thu, 27 Jul 2017 12:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PUgh7uaH9tQ; Thu, 27 Jul 2017 12:40:16 -0700 (PDT) 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 8A27D1287A5; Thu, 27 Jul 2017 12:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9586; q=dns/txt; s=iport; t=1501184416; x=1502394016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E+y2VPm1OSiE8KjU2UBtyqUNmWcQLiuyZWxCtCzCYck=; b=YyTLdFxPK5iXTWLDuA/rZSDSPhoRl/vJg2YT42uE8lSm8FPtkIa6ElMP OGzX9f1ZhmX8Mz6TMaj3GoFhKdZWEyCezAL+CMqP08493fxVf+ZmLLR6E hbGOYCidWTIse9mQCCAKbduT0GPmueJeNxLx7GGupc3LHR7hNPcwibR+s 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAAHQXpZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0Fii8Qr3eCJos/AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELgh2IUoMmgRoBEgE2gnyCYQWfZgKHTYxWggx?= =?us-ascii?q?XhHuKXpVxAR84fwt3FR+HQgF2h0INFweBBYEOAQEB?= X-IronPort-AV: E=Sophos;i="5.40,421,1496102400"; d="scan'208";a="279055754" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jul 2017 19:40:15 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6RJeFEh005235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Jul 2017 19:40:15 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 15:40:14 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 15:40:14 -0400 From: "Acee Lindem (acee)" To: "Reshad Rahman (rrahman)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AA== Date: Thu, 27 Jul 2017 19:40:14 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <5F4F735502F57F48980F9E9B2EC6F7A5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:40:27 -0000 SGkgUmVzaGFkLCANCg0KT24gNy8yNy8xNywgMzozNSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWht YW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj4NCj4xKSBJ4oCZ bGwgc2VlIGlmIG90aGVycyBjaGltZSBpbiBvbiB0aGlzIGJ1dCBJIGFtIGZpbmUgd2l0aCBoYXZp bmcgdGhlDQo+Y2xpZW50IGdyb3VwaW5nIGluIGlldGYtYmZkLXR5cGVzLnlhbmcuDQo+MikgYmZk LWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaGFzIG11Y2ggbW9yZSB0aGFuIGp1c3QgdGhlDQo+ bXVsdGlwbGllci90aW1lcnMgdGhhdCB0aGUgSUdQcyBuZWVkLiBJdCBhbHNvIGhhcyBCRkQgc3Bl Y2lmaWMgc3R1ZmYNCj4oZGVtYW5kLW1vZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1 c2luZXNzIG91dHNpZGUgb2YgQkZELg0KDQpBZ3JlZWQuIA0KDQoNCj5iZmQtZ3JvdXBpbmctYmFz ZS1jZmctcGFybXMgaGFzIG9ubHkgdGhlIG11bHRpcGxpZXIvdGltZXJzLg0KDQpQZXJoYXBzLCB0 aGUgYWRkaXRpb24gb2YgbXVsdGlwbGllci90aW1lcnMgdG8gYmZkLWdyb3VwaW5nLWJhc2UtY2Zn LXBhcm1zDQppc27igJl0IHB1c2hlZCB0byBHaXRIdWIgeWV0LiBUaGlzIHZlcnNpb24NCmh0dHBz Oi8vZ2l0aHViLmNvbS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lh bmcvaWV0Zi1iZmQtdA0KeXBlcy55YW5nIG9ubHkgaGFzIHRoZSBlbmFibGVkIGxlYWYuDQoNCg0K VGhhbmtzLA0KQWNlZSANCg0KDQo+DQo+UmVnYXJkcywNCj5SZXNoYWQuDQo+DQo+DQo+DQo+T24g MjAxNy0wNy0yNywgMzozMCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29t PiB3cm90ZToNCj4NCj4+SGkgUmVzaGFkLCANCj4+DQo+Pk9uIDcvMjcvMTcsIDM6MTkgUE0sICJS ZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiB3cm90ZToNCj4+DQo+ Pj5IaSBBY2VlLA0KPj4+DQo+Pj5XaGVuIHdlIG1ldCB3ZSBhZ3JlZWQgdG8gaGF2ZSBhIG5ldyBt b2RlbCBmb3IgY2xpZW50cy4gQWZ0ZXJ3YXJkcyBJDQo+Pj5kZWNpZGVkIHRvIGNyZWF0ZSBhIG5l dyB0eXBlcyBtb2R1bGUsIGFuZCBzdGlsbCB3ZW50IGFoZWFkIHdpdGggdGhlDQo+Pj5jbGllbnRz IG1vZHVsZS4gSSBhbSBmaW5lIHdpdGggaGF2aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzIG1v ZHVsZSAobm8NCj4+PmNsaWVudCBtb2R1bGUpLg0KPj4NCj4+QWx0aG91Z2ggSSBkb27igJl0IGZl ZWwgdGhhdCBzdHJvbmdseSAtIEkganVzdCBkb27igJl0IHNlZSB0aGF0IHB1dHRpbmcgdGhlDQo+ PmNsaWVudCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3ZpZGVzIGFueSBiZW5lZml0LiBB cyBmb3IgZGV0cmltZW50cywNCj4+aXQgcmVxdWlyZXMgbW9yZSBvbmUgbW9yZSBsb2NhbCBtb2R1 bGVzIGZvciB2YWxpZGF0aW9uIGFuZCBvbmUgbW9yZSBsZXZlbA0KPj5vZiBpbmRpcmVjdGlvbiB0 byBzZWUgd2hhdCB3ZSBhcmUgcmVhbGx5IGFsbG93aW5nIHRvIGJlIGNvbmZpZ3VyZWQuDQo+Pg0K Pj4+DQo+Pj5JIGFtIG5vdCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQvcXVl c3Rpb24gb24NCj4+PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcy9iZmQtZ3JvdXBpbmctY29tbW9u LWNmZy1wYXJtcy4gVGhlIHJlYXNvbiB3ZQ0KPj4+aGF2ZQ0KPj4+MiBncm91cGluZ3MgaXMgdGhh dCBzb21lIHByb3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgZW5hYmxlDQo+Pj5s ZWFmDQo+Pj5hbmQgb3RoZXJzIG1heSBhbHNvIHdhbnQgdGhlIG11bHRpcGxpZXIvdGltZXIuDQo+ Pg0KPj5UaGUgYmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zIGdyb3VwaW5nIHNob3VsZCB1c2UNCj4+ YmZkLXR5cGVzOmJmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIHJhdGhlciB0aGFuDQo+PmJm ZC10eXBlczpiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMgd291bGQgYmUgbW9y ZSBvYnZpb3VzIHcvbw0KPj50aGUgY2xpZW50IG1vZHVsZS4NCj4+DQo+PlRoYW5rcywNCj4+QWNl ZSANCj4+DQo+Pg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+UmVzaGFkLg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+T24gMjAxNy0wNy0yNywgMzowNyBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lz Y28uY29tPiB3cm90ZToNCj4+Pg0KPj4+PkhpIFJlc2hhZCwgDQo+Pj4+V2h5IGRvIHdlIG5lZWQg YSBuZXcgWUFORyBtb2RlbCBmb3IgY2xpZW50cz8gV2h5IGNhbuKAmXQgdGhleSBqdXN0IHVzZQ0K Pj4+PmlldGYtYmZkLXR5cGVzLnlhbmc/IEnigJlkIGxpa2UgdG8gYXZvaWQgdGhlIHVubmVjZXNz YXJ5IGxldmVscyBvZg0KPj4+PmluZGlyZWN0aW9uLiBJbiBmYWN0LCBpdCBsb29rcyB3cm9uZyB0 byBtZSBzaW5jZSB0aGUgZ3JvdXBpbmcNCj4+Pj5iZmQtY2xpZW50LWV4dC1jZmctcGFybXMgdXNl cyB0aGUgZ3JvdXBpbmcgYmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+Pj4+d2hpY2ggb25s eSBjb250YWlucyB0aGUgZW5hYmxlZCBsZWFmLiBJIGJlbGlldmUgeW91IG1lYW50IHRvIHVzZQ0K Pj4+PmJmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIGluIHRoZSBvdGhlciBuZXcgbW9kZWwu IEhvd2V2ZXIsIEkgZG9u4oCZdA0KPj4+PnNlZQ0KPj4+PmFueSByZWFzb24gd2h5IGNsaWVudCBz aG91bGRu4oCZdCB1c2UgdGhpcyBkaXJlY3RseS4NCj4+Pj5UaGFua3MsDQo+Pj4+QWNlZSANCj4+ Pj4NCj4+Pj5PbiA3LzI1LzE3LCAyOjMzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxy cmFobWFuQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+Pj4+SGkgWWluZ3poZW4sDQo+ Pj4+Pg0KPj4+Pj5UaGUgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlIEANCj4+Pj4+aHR0cHM6Ly9naXRo dWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRm LQ0KPj4+Pj5iDQo+Pj4+PmYNCj4+Pj4+ZA0KPj4+Pj4tDQo+Pj4+PmMNCj4+Pj4+bGllbnRzLnlh bmcNCj4+Pj4+DQo+Pj4+PklmIHlvdcK5ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBz ZW5kIG1lIGFuIGVtYWlsLg0KPj4+Pj4NCj4+Pj4+UmVnYXJkcywNCj4+Pj4+UmVzaGFkLg0KPj4+ Pj4NCj4+Pj4+T24gMjAxNy0wNy0yMSwgMTI6MjIgUE0sICJZaW5nemhlbiBRdSIgPHlpbmd6aGVu LnF1QGh1YXdlaS5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PkhpIFJlc2hhZCwNCj4+Pj4+Pg0K Pj4+Pj4+VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4NCj4+Pj4+Pg0KPj4+Pj4+Qm90aCBvc3BmIGFu ZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29ycmVzcG9uZGluZyBjaGFuZ2VzIHdoZW4gdGhlDQo+ Pj4+Pj5uZXcNCj4+Pj4+PkJGRCBncm91cGluZyBpcyBhdmFpbGFibGUuDQo+Pj4+Pj4NCj4+Pj4+ PlRoYW5rcywNCj4+Pj4+Pllpbmd6aGVuDQo+Pj4+Pj4NCj4+Pj4+Pi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+Pj5Gcm9tOiBSZXNoYWQgUmFobWFuIChycmFobWFuKSBbbWFpbHRvOnJy YWhtYW5AY2lzY28uY29tXQ0KPj4+Pj4+U2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNzox OSBBTQ0KPj4+Pj4+VG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+OyBydGctYmZkQGll dGYub3JnDQo+Pj4+Pj5DYzogZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4+Pj4+PlN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+DQo+Pj4+Pj5XZSAoQkZEIGFuZCBPU1BGIFlB TkcgYXV0aG9ycykgaGFkIGEgZGlzY3Vzc2lvbiB5ZXN0ZXJkYXkuDQo+Pj4+Pj4NCj4+Pj4+PlRo ZSBhZ3JlZW1lbnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJlZCwg d2Ugd2FudCB0bw0KPj4+Pj4+YWRkDQo+Pj4+Pj5iYWNrIHRoZSBiYXNpYyBCRkQgY29uZmlnICht dWx0aXBsaWVyICsgaW50ZXJ2YWxzKSBpbiBJR1AgdmlhIGENCj4+Pj4+Pmdyb3VwaW5nLg0KPj4+ Pj4+QkZEIHdpbGwgcHJvdmlkZSB0aGF0IGdyb3VwaW5nIGluIGEgc3BlY2lmaWMgWUFORyBtb2R1 bGUuIElHUCBCRkQNCj4+Pj4+PllBTkcNCj4+Pj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBtb2R1 bGUgKHNlcGFyYXRlIGZyb20gdGhlIG1haW4gSUdQIG1vZHVsZSkuDQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+UmVnYXJkcywNCj4+Pj4+PlJlc2hhZC4NCj4+Pj4+Pg0KPj4+Pj4+T24gMjAxNy0wNy0w NSwgMTI6MjEgUE0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+Pj48 cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3Jv dGU6DQo+Pj4+Pj4NCj4+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRoZSBC RkQgeWFuZyBtb2R1bGUuICBUaGlzIGdldHMgdXMgYQ0KPj4+Pj4+PnNpZ25pZmljYW50IHN0ZXAg Y2xvc2VyIHRvIGFsaWdubWVudCB3aXRoIHRoZSByZXN0IG9mIElFVEYgZm9yDQo+Pj4+Pj4+bmV0 d29yaw0KPj4+Pj4+Pmluc3RhbmNpbmcuDQo+Pj4+Pj4+DQo+Pj4+Pj4+SSdkIGxpa2UgdG8gZW5j b3VyYWdlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sgb24gdGhpcw0KPj4+ Pj4+Pmlzc3VlIGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+QXMgbm90ZWQgaW4gYW5vdGhlciB0aHJlYWQsIHdlIHN0aWxsIGhhdmUgdG8gZmlndXJl IG91dCBob3cgdG8gZGVhbA0KPj4+Pj4+PndpdGggYWNjb21tb2RhdGluZyBpbnRlcmFjdGlvbiBv ZiB0aGUgQkZEIHlhbmcgbW9kdWxlIHdpdGggY2xpZW50DQo+Pj4+Pj4+cHJvdG9jb2xzLg0KPj4+ Pj4+PkZvcg0KPj4+Pj4+PmV4YW1wbGUsIHRoZSBJR1BzLiAgSW4gcGFydGljdWxhciwgaG93IGRv IHlvdSBjb25maWd1cmUgdGhlDQo+Pj4+Pj4+cHJvcGVydGllcw0KPj4+Pj4+Pm9mIHRoZSBCRkQg c2Vzc2lvbnMgdGhhdCBtYXkgYmUgZHluYW1pY2FsbHkgaW5zdGFudGlhdGVkIGJhc2VkIG9uDQo+ Pj4+Pj4+Y29udHJvbCBwcm90b2NvbCBhY3Rpdml0eT8NCj4+Pj4+Pj4NCj4+Pj4+Pj4tLSBKZWZm DQo+Pj4+Pj4+DQo+Pj4+Pj4+T24gRnJpLCBKdW4gMzAsIDIwMTcgYXQgMTI6NTU6NTlQTSAtMDcw MCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cw0KPj4+Pj4+Pj5kaXJlY3Rvcmllcy4NCj4+Pj4+Pj4+IFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+Pj4+ Pj5EZXRlY3Rpb24NCj4+Pj4+Pj4+b2YgdGhlIElFVEYuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAg ICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBCaWRpcmVjdGlvbmFs DQo+Pj4+Pj4+PkZvcndhcmRpbmcNCj4+Pj4+Pj4+RGV0ZWN0aW9uIChCRkQpDQo+Pj4+Pj4+PiAg ICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+Pj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgIFNhbnRvc2ggUGFsbGFnYXR0aQ0KPj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtYmZkLXlhbmctMDYudHh0DQo+Pj4+Pj4+PiAJUGFnZXMgICAgICAgICAgIDogNTkNCj4+Pj4+ Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEFi c3RyYWN0Og0KPj4+Pj4+Pj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1v ZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8NCj4+Pj4+Pj4+Y29uZmlndXJlDQo+Pj4+Pj4+PiAgICBh bmQgbWFuYWdlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXlhbmcvDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4+ Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+ Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt YmZkLXlhbmctMDYNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+Pj4+Pj5zdWJtaXNzaW9uICB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4+Pj4+PnRvb2xzLmlldGYu b3JnLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Thu Jul 27 18:03:06 2017 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 D5B80131ED0; Thu, 27 Jul 2017 18:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAltmPGim1xz; Thu, 27 Jul 2017 18:03:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F79131ECF; Thu, 27 Jul 2017 18:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10728; q=dns/txt; s=iport; t=1501203782; x=1502413382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wtMUGumVvQY9LySfW0XwghkGvbN3Sli00JSYRVtw62Y=; b=BjIdgAMsNdPZvxsj+Tvw6Eu8SL2fAgm6vCxnR+ytil9+CI/O2/tlGjJ0 hhzIqCbjKf2Awokg7DA3BbyE78+xfh0Ze5wdjul9B6FAHkP7XQT06Wci3 cQfSUZv5y0iSlOI6cRPgYfIn2Dv3KZFUus8SjRO7wajMXK+0SGDc7w+nS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAABEjHpZ/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRYpYKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDNEUMBAIBCBEEAQEBBCMFAgIwFAkIAgQBDQWKLxCRdZ1cBoIoi0ABAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEdgQWCI4NNhQWDJoEaARIBHxeCdoJnBZ9mAodNjFa?= =?us-ascii?q?CDFeEe4pelXEBHzh/C3cVH4VAHIFmAXaHQg0XB4EFgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,423,1496102400"; d="scan'208";a="460790931" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 01:03:01 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6S131kj008611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 01:03:01 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 20:03:00 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 20:03:00 -0500 From: "Reshad Rahman (rrahman)" To: "Acee Lindem (acee)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoA Date: Fri, 28 Jul 2017 01:03:00 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.246.31] Content-Type: text/plain; charset="euc-kr" Content-ID: <31E496BB89953A4483CB224E841D6677@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 01:03:05 -0000 SGkgQWNlZSwNCg0KV2hhdCBJIHNlZSBAIA0KaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMv aWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRmLWJmZC10DQp5cGVzLnlhbmc6 DQoxKSBiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIGhhcyBsZWFmIGVuYWJsZWQgb25seS4gQlRX IHRoaXMgZ3JvdXBpbmcgaXMNCmRlZmluZWQgdHdpY2UsIHRoaXMgd2lsbCBiZSBmaXhlZCB3aGVu IEkgZ2V0IHJpZCBvZiBpZXRmLWJmZC1jbGllbnRzLnlhbmcNCjIpIGJmZC1ncm91cGluZy1iYXNl LWNmZy1wYXJtcyBoYXMgbXVsdGlwbGllci90aW1lcnMuDQoNCkxldCBtZSBnZXQgcmlkIG9mIHRo ZSBjbGllbnQgbW9kdWxlIGFuZCBoYXZlIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzDQptb2R1bGUu DQoNCkkgYW0gbm90IHN1cmUgd2h5IHlvdaGvcmUgbm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVy ZW50Lg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQoNCg0KT24gMjAxNy0wNy0yNywgMzo0MCBQTSwg IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCg0KPkhpIFJlc2hh ZCwgDQo+DQo+T24gNy8yNy8xNywgMzozNSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8 cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj5IaSBBY2VlLA0KPj4NCj4+MSkgSaGvbGwg c2VlIGlmIG90aGVycyBjaGltZSBpbiBvbiB0aGlzIGJ1dCBJIGFtIGZpbmUgd2l0aCBoYXZpbmcg dGhlDQo+PmNsaWVudCBncm91cGluZyBpbiBpZXRmLWJmZC10eXBlcy55YW5nLg0KPj4yKSBiZmQt Z3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBoYXMgbXVjaCBtb3JlIHRoYW4ganVzdCB0aGUNCj4+ bXVsdGlwbGllci90aW1lcnMgdGhhdCB0aGUgSUdQcyBuZWVkLiBJdCBhbHNvIGhhcyBCRkQgc3Bl Y2lmaWMgc3R1ZmYNCj4+KGRlbWFuZC1tb2RlLCBCRkQgYXV0aCkgd2hpY2ggSU1PIGhhcyBubyBi dXNpbmVzcyBvdXRzaWRlIG9mIEJGRC4NCj4NCj5BZ3JlZWQuIA0KPg0KPg0KPj5iZmQtZ3JvdXBp bmctYmFzZS1jZmctcGFybXMgaGFzIG9ubHkgdGhlIG11bHRpcGxpZXIvdGltZXJzLg0KPg0KPlBl cmhhcHMsIHRoZSBhZGRpdGlvbiBvZiBtdWx0aXBsaWVyL3RpbWVycyB0byBiZmQtZ3JvdXBpbmct YmFzZS1jZmctcGFybXMNCj5pc26hr3QgcHVzaGVkIHRvIEdpdEh1YiB5ZXQuIFRoaXMgdmVyc2lv bg0KPmh0dHBzOi8vZ2l0aHViLmNvbS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0 ZXIvc3JjL3lhbmcvaWV0Zi1iZmQtDQo+dA0KPnlwZXMueWFuZyBvbmx5IGhhcyB0aGUgZW5hYmxl ZCBsZWFmLg0KPg0KPg0KPlRoYW5rcywNCj5BY2VlIA0KPg0KPg0KPj4NCj4+UmVnYXJkcywNCj4+ UmVzaGFkLg0KPj4NCj4+DQo+Pg0KPj5PbiAyMDE3LTA3LTI3LCAzOjMwIFBNLCAiQWNlZSBMaW5k ZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4NCj4+PkhpIFJlc2hhZCwgDQo+ Pj4NCj4+Pk9uIDcvMjcvMTcsIDM6MTkgUE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJy YWhtYW5AY2lzY28uY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5IaSBBY2VlLA0KPj4+Pg0KPj4+ PldoZW4gd2UgbWV0IHdlIGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiBB ZnRlcndhcmRzIEkNCj4+Pj5kZWNpZGVkIHRvIGNyZWF0ZSBhIG5ldyB0eXBlcyBtb2R1bGUsIGFu ZCBzdGlsbCB3ZW50IGFoZWFkIHdpdGggdGhlDQo+Pj4+Y2xpZW50cyBtb2R1bGUuIEkgYW0gZmlu ZSB3aXRoIGhhdmluZyBldmVyeXRoaW5nIGluIHRoZSB0eXBlcyBtb2R1bGUNCj4+Pj4obm8NCj4+ Pj5jbGllbnQgbW9kdWxlKS4NCj4+Pg0KPj4+QWx0aG91Z2ggSSBkb26hr3QgZmVlbCB0aGF0IHN0 cm9uZ2x5IC0gSSBqdXN0IGRvbqGvdCBzZWUgdGhhdCBwdXR0aW5nIHRoZQ0KPj4+Y2xpZW50IGNv bmZpZyBwYXJhbXMgaW4gd3JhcHBlcnMgcHJvdmlkZXMgYW55IGJlbmVmaXQuIEFzIGZvcg0KPj4+ ZGV0cmltZW50cywNCj4+Pml0IHJlcXVpcmVzIG1vcmUgb25lIG1vcmUgbG9jYWwgbW9kdWxlcyBm b3IgdmFsaWRhdGlvbiBhbmQgb25lIG1vcmUNCj4+PmxldmVsDQo+Pj5vZiBpbmRpcmVjdGlvbiB0 byBzZWUgd2hhdCB3ZSBhcmUgcmVhbGx5IGFsbG93aW5nIHRvIGJlIGNvbmZpZ3VyZWQuDQo+Pj4N Cj4+Pj4NCj4+Pj5JIGFtIG5vdCBzdXJlIEkgZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQv cXVlc3Rpb24gb24NCj4+Pj5iZmQtY2xpZW50LWV4dC1jZmctcGFybXMvYmZkLWdyb3VwaW5nLWNv bW1vbi1jZmctcGFybXMuIFRoZSByZWFzb24gd2UNCj4+Pj5oYXZlDQo+Pj4+MiBncm91cGluZ3Mg aXMgdGhhdCBzb21lIHByb3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgZW5hYmxl DQo+Pj4+bGVhZg0KPj4+PmFuZCBvdGhlcnMgbWF5IGFsc28gd2FudCB0aGUgbXVsdGlwbGllci90 aW1lci4NCj4+Pg0KPj4+VGhlIGJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyBncm91cGluZyBzaG91 bGQgdXNlDQo+Pj5iZmQtdHlwZXM6YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgcmF0aGVy IHRoYW4NCj4+PmJmZC10eXBlczpiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMg d291bGQgYmUgbW9yZSBvYnZpb3VzIHcvbw0KPj4+dGhlIGNsaWVudCBtb2R1bGUuDQo+Pj4NCj4+ PlRoYW5rcywNCj4+PkFjZWUgDQo+Pj4NCj4+Pg0KPj4+Pg0KPj4+PlJlZ2FyZHMsDQo+Pj4+UmVz aGFkLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIDIwMTctMDctMjcsIDM6MDcgUE0sICJBY2Vl IExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+DQo+Pj4+PkhpIFJl c2hhZCwgDQo+Pj4+PldoeSBkbyB3ZSBuZWVkIGEgbmV3IFlBTkcgbW9kZWwgZm9yIGNsaWVudHM/ IFdoeSBjYW6hr3QgdGhleSBqdXN0IHVzZQ0KPj4+Pj5pZXRmLWJmZC10eXBlcy55YW5nPyBJoa9k IGxpa2UgdG8gYXZvaWQgdGhlIHVubmVjZXNzYXJ5IGxldmVscyBvZg0KPj4+Pj5pbmRpcmVjdGlv bi4gSW4gZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUgc2luY2UgdGhlIGdyb3VwaW5nDQo+Pj4+ PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBncm91cGluZyBiZmQtZ3JvdXBpbmct YmFzZS1jZmctcGFybXMNCj4+Pj4+d2hpY2ggb25seSBjb250YWlucyB0aGUgZW5hYmxlZCBsZWFm LiBJIGJlbGlldmUgeW91IG1lYW50IHRvIHVzZQ0KPj4+Pj5iZmQtZ3JvdXBpbmctY29tbW9uLWNm Zy1wYXJtcyBpbiB0aGUgb3RoZXIgbmV3IG1vZGVsLiBIb3dldmVyLCBJIGRvbqGvdA0KPj4+Pj5z ZWUNCj4+Pj4+YW55IHJlYXNvbiB3aHkgY2xpZW50IHNob3VsZG6hr3QgdXNlIHRoaXMgZGlyZWN0 bHkuDQo+Pj4+PlRoYW5rcywNCj4+Pj4+QWNlZSANCj4+Pj4+DQo+Pj4+Pk9uIDcvMjUvMTcsIDI6 MzMgUE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+ Pj53cm90ZToNCj4+Pj4+DQo+Pj4+Pj5IaSBZaW5nemhlbiwNCj4+Pj4+Pg0KPj4+Pj4+VGhlIGdy b3VwaW5nIGlzIGF2YWlsYWJsZSBADQo+Pj4+Pj5odHRwczovL2dpdGh1Yi5jb20vamhhYXMtcGZy Yy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldGYNCj4+Pj4+Pi0NCj4+Pj4+ PmINCj4+Pj4+PmYNCj4+Pj4+PmQNCj4+Pj4+Pi0NCj4+Pj4+PmMNCj4+Pj4+PmxpZW50cy55YW5n DQo+Pj4+Pj4NCj4+Pj4+PklmIHlvdan2ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBz ZW5kIG1lIGFuIGVtYWlsLg0KPj4+Pj4+DQo+Pj4+Pj5SZWdhcmRzLA0KPj4+Pj4+UmVzaGFkLg0K Pj4+Pj4+DQo+Pj4+Pj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8eWlu Z3poZW4ucXVAaHVhd2VpLmNvbT4NCj4+Pj4+Pndyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+SGkgUmVz aGFkLA0KPj4+Pj4+Pg0KPj4+Pj4+PlRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+Qm90aCBvc3BmIGFuZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29ycmVzcG9uZGluZyBj aGFuZ2VzIHdoZW4gdGhlDQo+Pj4+Pj4+bmV3DQo+Pj4+Pj4+QkZEIGdyb3VwaW5nIGlzIGF2YWls YWJsZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj5UaGFua3MsDQo+Pj4+Pj4+WWluZ3poZW4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PkZyb206IFJlc2hhZCBS YWhtYW4gKHJyYWhtYW4pIFttYWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+U2VudDog VGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNzoxOSBBTQ0KPj4+Pj4+PlRvOiBKZWZmcmV5IEhhYXMg PGpoYWFzQHBmcmMub3JnPjsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+Pj4+PkNjOiBkcmFmdC1pZXRm LWJmZC15YW5nQGlldGYub3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KPj4+Pj4+ PlN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+ Pj4+Pg0KPj4+Pj4+PldlIChCRkQgYW5kIE9TUEYgWUFORyBhdXRob3JzKSBoYWQgYSBkaXNjdXNz aW9uIHllc3RlcmRheS4NCj4+Pj4+Pj4NCj4+Pj4+Pj5UaGUgYWdyZWVtZW50IGlzIHRoYXQgc2lu Y2UgSUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdlIHdhbnQNCj4+Pj4+Pj50bw0KPj4+ Pj4+PmFkZA0KPj4+Pj4+PmJhY2sgdGhlIGJhc2ljIEJGRCBjb25maWcgKG11bHRpcGxpZXIgKyBp bnRlcnZhbHMpIGluIElHUCB2aWEgYQ0KPj4+Pj4+Pmdyb3VwaW5nLg0KPj4+Pj4+PkJGRCB3aWxs IHByb3ZpZGUgdGhhdCBncm91cGluZyBpbiBhIHNwZWNpZmljIFlBTkcgbW9kdWxlLiBJR1AgQkZE DQo+Pj4+Pj4+WUFORw0KPj4+Pj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBtb2R1bGUgKHNlcGFy YXRlIGZyb20gdGhlIG1haW4gSUdQIG1vZHVsZSkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ UmVnYXJkcywNCj4+Pj4+Pj5SZXNoYWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+T24gMjAxNy0wNy0wNSwg MTI6MjEgUE0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+Pj4+PHJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhhYXNAcGZyYy5vcmc+IHdyb3Rl Og0KPj4+Pj4+Pg0KPj4+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRoZSBC RkQgeWFuZyBtb2R1bGUuICBUaGlzIGdldHMgdXMNCj4+Pj4+Pj4+YQ0KPj4+Pj4+Pj5zaWduaWZp Y2FudCBzdGVwIGNsb3NlciB0byBhbGlnbm1lbnQgd2l0aCB0aGUgcmVzdCBvZiBJRVRGIGZvcg0K Pj4+Pj4+Pj5uZXR3b3JrDQo+Pj4+Pj4+Pmluc3RhbmNpbmcuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5J J2QgbGlrZSB0byBlbmNvdXJhZ2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHJvdmlkZSBmZWVkYmFj ayBvbiB0aGlzDQo+Pj4+Pj4+Pmlzc3VlIGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1 bGUuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5BcyBub3RlZCBpbiBhbm90aGVyIHRocmVhZCwgd2Ugc3Rp bGwgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyB0byBkZWFsDQo+Pj4+Pj4+PndpdGggYWNjb21tb2Rh dGluZyBpbnRlcmFjdGlvbiBvZiB0aGUgQkZEIHlhbmcgbW9kdWxlIHdpdGggY2xpZW50DQo+Pj4+ Pj4+PnByb3RvY29scy4NCj4+Pj4+Pj4+Rm9yDQo+Pj4+Pj4+PmV4YW1wbGUsIHRoZSBJR1BzLiAg SW4gcGFydGljdWxhciwgaG93IGRvIHlvdSBjb25maWd1cmUgdGhlDQo+Pj4+Pj4+PnByb3BlcnRp ZXMNCj4+Pj4+Pj4+b2YgdGhlIEJGRCBzZXNzaW9ucyB0aGF0IG1heSBiZSBkeW5hbWljYWxseSBp bnN0YW50aWF0ZWQgYmFzZWQgb24NCj4+Pj4+Pj4+Y29udHJvbCBwcm90b2NvbCBhY3Rpdml0eT8N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pi0tIEplZmYNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pk9uIEZyaSwgSnVu IDMwLCAyMDE3IGF0IDEyOjU1OjU5UE0gLTA3MDAsIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K Pj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZQ0KPj4+Pj4+Pj4+SW50ZXJuZXQtRHJhZnRz DQo+Pj4+Pj4+Pj5kaXJlY3Rvcmllcy4NCj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcNCj4+Pj4+Pj4+PkRldGVjdGlvbg0K Pj4+Pj4+Pj4+b2YgdGhlIElFVEYuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Pj4+ PkZvcndhcmRpbmcNCj4+Pj4+Pj4+PkRldGVjdGlvbiAoQkZEKQ0KPj4+Pj4+Pj4+ICAgICAgICAg QXV0aG9ycyAgICAgICAgIDogUmVzaGFkIFJhaG1hbg0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgTWFoZXNoIEpldGhhbmFuZGFuaQ0KPj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgU2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA1OQ0KPj4+Pj4+ Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4g QWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRh IG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8NCj4+Pj4+Pj4+PmNvbmZpZ3VyZQ0KPj4+Pj4+Pj4+ ICAgIGFuZCBtYW5hZ2UgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKS4N Cj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+PiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj4+Pj4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1i ZmQteWFuZy0wNg0KPj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+Pj4+Pj4+Pj5zdWJtaXNz aW9uICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 DQo+Pj4+Pj4+Pj50b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+ Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+DQo+Pj4+DQo+Pj4NCj4+DQo+DQoNCg== From nobody Thu Jul 27 19:35:00 2017 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 68A18131F0F; Thu, 27 Jul 2017 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOf2jAWKaFmb; Thu, 27 Jul 2017 19:34:55 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916DB131F08; Thu, 27 Jul 2017 19:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11500; q=dns/txt; s=iport; t=1501209295; x=1502418895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zrqjxgZ6s7bHAMXa+6Whpn5K9qq27kiCZx+jzDfQwvg=; b=c+yByCV6SZnxvpkB5FXh9ghi/7ZgBeI5su590yXJcYGf0b2bXdxVWrRD o5OMPiLjGQqUtMSr6xrMtA9U7XkUfG0knFNO9wbbWXFkclxjdoeCbVVgg 4SL8Ot7I7BrdyhbmNbujr8ps5KYgmNIjmbBS21IXp5bKN7YB51I+V7mgb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAABaonpZ/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaRY5YKDoIELoUZAhqDSz8YAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQEDIxFFDAQCAQgRBAEBAQICIwMCAgIwFAEICAIEAQ0Fii8Qr1mCJotAAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYELgh2IUoMmgRoBEgEfF4J8gmEFn2YCh02MVoI?= =?us-ascii?q?MV4R7il6VcQEfOH8LdxUfhUAcgWYBdodCDRcHgQWBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,423,1496102400"; d="scan'208";a="460816048" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 02:34:54 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v6S2YrIr016320 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 02:34:54 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 27 Jul 2017 22:34:52 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 27 Jul 2017 22:34:52 -0400 From: "Acee Lindem (acee)" To: "Reshad Rahman (rrahman)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YA= Date: Fri, 28 Jul 2017 02:34:52 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <6C858B8AD2D3DE4C9057E99AD1FE74B2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 02:34:58 -0000 SGkgUmVzaGFkLCANCg0KT2sgLSBJIHNlZSBub3cuIEkgd2FzIGxvb2tpbmcgYXQgdGhlIHdyb25n IHh4eHgtYmFzZS1jZmctcGFybXMgZ3JvdXBpbmdzLg0KRmV3ZXIgc2ltaWxhciBncm91cGluZyBh bmQgbW9kdWxlcyB3aWxsIGJlIGJldHRlciA7XikNCg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA3LzI3 LzE3LCA5OjAzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNv bT4gd3JvdGU6DQoNCj5IaSBBY2VlLA0KPg0KPldoYXQgSSBzZWUgQCANCj5odHRwczovL2dpdGh1 Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldGYt YmZkLQ0KPnQNCj55cGVzLnlhbmc6DQo+MSkgYmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyBoYXMg bGVhZiBlbmFibGVkIG9ubHkuIEJUVyB0aGlzIGdyb3VwaW5nIGlzDQo+ZGVmaW5lZCB0d2ljZSwg dGhpcyB3aWxsIGJlIGZpeGVkIHdoZW4gSSBnZXQgcmlkIG9mIGlldGYtYmZkLWNsaWVudHMueWFu Zw0KPjIpIGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyBoYXMgbXVsdGlwbGllci90aW1lcnMu DQo+DQo+TGV0IG1lIGdldCByaWQgb2YgdGhlIGNsaWVudCBtb2R1bGUgYW5kIGhhdmUgZXZlcnl0 aGluZyBpbiB0aGUgdHlwZXMNCj5tb2R1bGUuDQo+DQo+SSBhbSBub3Qgc3VyZSB3aHkgeW914oCZ cmUgbm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPg0KPlJlZ2FyZHMsDQo+UmVzaGFk Lg0KPg0KPg0KPg0KPk9uIDIwMTctMDctMjcsIDM6NDAgUE0sICJBY2VlIExpbmRlbSAoYWNlZSki IDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+PkhpIFJlc2hhZCwgDQo+Pg0KPj5PbiA3LzI3 LzE3LCAzOjM1IFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNv bT4gd3JvdGU6DQo+Pg0KPj4+SGkgQWNlZSwNCj4+Pg0KPj4+MSkgSeKAmWxsIHNlZSBpZiBvdGhl cnMgY2hpbWUgaW4gb24gdGhpcyBidXQgSSBhbSBmaW5lIHdpdGggaGF2aW5nIHRoZQ0KPj4+Y2xp ZW50IGdyb3VwaW5nIGluIGlldGYtYmZkLXR5cGVzLnlhbmcuDQo+Pj4yKSBiZmQtZ3JvdXBpbmct Y29tbW9uLWNmZy1wYXJtcyBoYXMgbXVjaCBtb3JlIHRoYW4ganVzdCB0aGUNCj4+Pm11bHRpcGxp ZXIvdGltZXJzIHRoYXQgdGhlIElHUHMgbmVlZC4gSXQgYWxzbyBoYXMgQkZEIHNwZWNpZmljIHN0 dWZmDQo+Pj4oZGVtYW5kLW1vZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1c2luZXNz IG91dHNpZGUgb2YgQkZELg0KPj4NCj4+QWdyZWVkLiANCj4+DQo+Pg0KPj4+YmZkLWdyb3VwaW5n LWJhc2UtY2ZnLXBhcm1zIGhhcyBvbmx5IHRoZSBtdWx0aXBsaWVyL3RpbWVycy4NCj4+DQo+PlBl cmhhcHMsIHRoZSBhZGRpdGlvbiBvZiBtdWx0aXBsaWVyL3RpbWVycyB0byBiZmQtZ3JvdXBpbmct YmFzZS1jZmctcGFybXMNCj4+aXNu4oCZdCBwdXNoZWQgdG8gR2l0SHViIHlldC4gVGhpcyB2ZXJz aW9uDQo+Pmh0dHBzOi8vZ2l0aHViLmNvbS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9t YXN0ZXIvc3JjL3lhbmcvaWV0Zi1iZmQNCj4+LQ0KPj50DQo+PnlwZXMueWFuZyBvbmx5IGhhcyB0 aGUgZW5hYmxlZCBsZWFmLg0KPj4NCj4+DQo+PlRoYW5rcywNCj4+QWNlZSANCj4+DQo+Pg0KPj4+ DQo+Pj5SZWdhcmRzLA0KPj4+UmVzaGFkLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+T24gMjAxNy0wNy0y NywgMzozMCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToN Cj4+Pg0KPj4+PkhpIFJlc2hhZCwgDQo+Pj4+DQo+Pj4+T24gNy8yNy8xNywgMzoxOSBQTSwgIlJl c2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+d3JvdGU6DQo+ Pj4+DQo+Pj4+PkhpIEFjZWUsDQo+Pj4+Pg0KPj4+Pj5XaGVuIHdlIG1ldCB3ZSBhZ3JlZWQgdG8g aGF2ZSBhIG5ldyBtb2RlbCBmb3IgY2xpZW50cy4gQWZ0ZXJ3YXJkcyBJDQo+Pj4+PmRlY2lkZWQg dG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwgYW5kIHN0aWxsIHdlbnQgYWhlYWQgd2l0aCB0 aGUNCj4+Pj4+Y2xpZW50cyBtb2R1bGUuIEkgYW0gZmluZSB3aXRoIGhhdmluZyBldmVyeXRoaW5n IGluIHRoZSB0eXBlcyBtb2R1bGUNCj4+Pj4+KG5vDQo+Pj4+PmNsaWVudCBtb2R1bGUpLg0KPj4+ Pg0KPj4+PkFsdGhvdWdoIEkgZG9u4oCZdCBmZWVsIHRoYXQgc3Ryb25nbHkgLSBJIGp1c3QgZG9u 4oCZdCBzZWUgdGhhdCBwdXR0aW5nIHRoZQ0KPj4+PmNsaWVudCBjb25maWcgcGFyYW1zIGluIHdy YXBwZXJzIHByb3ZpZGVzIGFueSBiZW5lZml0LiBBcyBmb3INCj4+Pj5kZXRyaW1lbnRzLA0KPj4+ Pml0IHJlcXVpcmVzIG1vcmUgb25lIG1vcmUgbG9jYWwgbW9kdWxlcyBmb3IgdmFsaWRhdGlvbiBh bmQgb25lIG1vcmUNCj4+Pj5sZXZlbA0KPj4+Pm9mIGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0IHdl IGFyZSByZWFsbHkgYWxsb3dpbmcgdG8gYmUgY29uZmlndXJlZC4NCj4+Pj4NCj4+Pj4+DQo+Pj4+ PkkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudC9xdWVzdGlvbiBv bg0KPj4+Pj5iZmQtY2xpZW50LWV4dC1jZmctcGFybXMvYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmct cGFybXMuIFRoZSByZWFzb24gd2UNCj4+Pj4+aGF2ZQ0KPj4+Pj4yIGdyb3VwaW5ncyBpcyB0aGF0 IHNvbWUgcHJvdG9jb2xzIG1heSBkZWNpZGUgdG8gaGF2ZSBqdXN0IHRoZSBlbmFibGUNCj4+Pj4+ bGVhZg0KPj4+Pj5hbmQgb3RoZXJzIG1heSBhbHNvIHdhbnQgdGhlIG11bHRpcGxpZXIvdGltZXIu DQo+Pj4+DQo+Pj4+VGhlIGJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyBncm91cGluZyBzaG91bGQg dXNlDQo+Pj4+YmZkLXR5cGVzOmJmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIHJhdGhlciB0 aGFuDQo+Pj4+YmZkLXR5cGVzOmJmZC1jbGllbnQtYmFzZS1jZmctcGFybXMgLSBubz8gVGhpcyB3 b3VsZCBiZSBtb3JlIG9idmlvdXMNCj4+Pj53L28NCj4+Pj50aGUgY2xpZW50IG1vZHVsZS4NCj4+ Pj4NCj4+Pj5UaGFua3MsDQo+Pj4+QWNlZSANCj4+Pj4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PlJlZ2Fy ZHMsDQo+Pj4+PlJlc2hhZC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+T24gMjAxNy0wNy0y NywgMzowNyBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToN Cj4+Pj4+DQo+Pj4+Pj5IaSBSZXNoYWQsIA0KPj4+Pj4+V2h5IGRvIHdlIG5lZWQgYSBuZXcgWUFO RyBtb2RlbCBmb3IgY2xpZW50cz8gV2h5IGNhbuKAmXQgdGhleSBqdXN0IHVzZQ0KPj4+Pj4+aWV0 Zi1iZmQtdHlwZXMueWFuZz8gSeKAmWQgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3NhcnkgbGV2 ZWxzIG9mDQo+Pj4+Pj5pbmRpcmVjdGlvbi4gSW4gZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUg c2luY2UgdGhlIGdyb3VwaW5nDQo+Pj4+Pj5iZmQtY2xpZW50LWV4dC1jZmctcGFybXMgdXNlcyB0 aGUgZ3JvdXBpbmcNCj4+Pj4+PmJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcw0KPj4+Pj4+d2hp Y2ggb25seSBjb250YWlucyB0aGUgZW5hYmxlZCBsZWFmLiBJIGJlbGlldmUgeW91IG1lYW50IHRv IHVzZQ0KPj4+Pj4+YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90aGVyIG5l dyBtb2RlbC4gSG93ZXZlciwgSQ0KPj4+Pj4+ZG9u4oCZdA0KPj4+Pj4+c2VlDQo+Pj4+Pj5hbnkg cmVhc29uIHdoeSBjbGllbnQgc2hvdWxkbuKAmXQgdXNlIHRoaXMgZGlyZWN0bHkuDQo+Pj4+Pj5U aGFua3MsDQo+Pj4+Pj5BY2VlIA0KPj4+Pj4+DQo+Pj4+Pj5PbiA3LzI1LzE3LCAyOjMzIFBNLCAi UmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj4+Pndyb3Rl Og0KPj4+Pj4+DQo+Pj4+Pj4+SGkgWWluZ3poZW4sDQo+Pj4+Pj4+DQo+Pj4+Pj4+VGhlIGdyb3Vw aW5nIGlzIGF2YWlsYWJsZSBADQo+Pj4+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMv aWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXQNCj4+Pj4+Pj5mDQo+Pj4+Pj4+ LQ0KPj4+Pj4+PmINCj4+Pj4+Pj5mDQo+Pj4+Pj4+ZA0KPj4+Pj4+Pi0NCj4+Pj4+Pj5jDQo+Pj4+ Pj4+bGllbnRzLnlhbmcNCj4+Pj4+Pj4NCj4+Pj4+Pj5JZiB5b3XCuWQgbGlrZSBjaGFuZ2VzIHRv IHRoZSBncm91cGluZywgc2VuZCBtZSBhbiBlbWFpbC4NCj4+Pj4+Pj4NCj4+Pj4+Pj5SZWdhcmRz LA0KPj4+Pj4+PlJlc2hhZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQ TSwgIllpbmd6aGVuIFF1IiA8eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4NCj4+Pj4+Pj53cm90ZToN Cj4+Pj4+Pj4NCj4+Pj4+Pj4+SGkgUmVzaGFkLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+VGhhbmtzIGZv ciB0aGUgc3VtbWFyeS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PkJvdGggb3NwZiBhbmQgaXNpcyBtb2Rl bHMgd2lsbCBtYWtlIGNvcnJlc3BvbmRpbmcgY2hhbmdlcyB3aGVuIHRoZQ0KPj4+Pj4+Pj5uZXcN Cj4+Pj4+Pj4+QkZEIGdyb3VwaW5nIGlzIGF2YWlsYWJsZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PlRo YW5rcywNCj4+Pj4+Pj4+WWluZ3poZW4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PkZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFttYWls dG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+PlNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAy MDE3IDc6MTkgQU0NCj4+Pj4+Pj4+VG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+OyBy dGctYmZkQGlldGYub3JnDQo+Pj4+Pj4+PkNjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3Jn OyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KPj4+Pj4+Pj5TdWJqZWN0OiBSZTogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pldl IChCRkQgYW5kIE9TUEYgWUFORyBhdXRob3JzKSBoYWQgYSBkaXNjdXNzaW9uIHllc3RlcmRheS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PlRoZSBhZ3JlZW1lbnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMg YXJlIGF1dG8tZGlzY292ZXJlZCwgd2Ugd2FudA0KPj4+Pj4+Pj50bw0KPj4+Pj4+Pj5hZGQNCj4+ Pj4+Pj4+YmFjayB0aGUgYmFzaWMgQkZEIGNvbmZpZyAobXVsdGlwbGllciArIGludGVydmFscykg aW4gSUdQIHZpYSBhDQo+Pj4+Pj4+Pmdyb3VwaW5nLg0KPj4+Pj4+Pj5CRkQgd2lsbCBwcm92aWRl IHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4gSUdQIEJGRA0KPj4+Pj4+ Pj5ZQU5HDQo+Pj4+Pj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBtb2R1bGUgKHNlcGFyYXRlIGZy b20gdGhlIG1haW4gSUdQIG1vZHVsZSkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+UmVn YXJkcywNCj4+Pj4+Pj4+UmVzaGFkLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+T24gMjAxNy0wNy0wNSwg MTI6MjEgUE0sICJSdGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+Pj4+Pjxy dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMub3JnPiB3cm90 ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRo ZSBCRkQgeWFuZyBtb2R1bGUuICBUaGlzIGdldHMgdXMNCj4+Pj4+Pj4+PmENCj4+Pj4+Pj4+PnNp Z25pZmljYW50IHN0ZXAgY2xvc2VyIHRvIGFsaWdubWVudCB3aXRoIHRoZSByZXN0IG9mIElFVEYg Zm9yDQo+Pj4+Pj4+Pj5uZXR3b3JrDQo+Pj4+Pj4+Pj5pbnN0YW5jaW5nLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj5JJ2QgbGlrZSB0byBlbmNvdXJhZ2UgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHJvdmlk ZSBmZWVkYmFjayBvbg0KPj4+Pj4+Pj4+dGhpcw0KPj4+Pj4+Pj4+aXNzdWUgYW5kIGFsc28gdGhl IGNoYW5nZXMgaW4gdGhlIG1vZHVsZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+QXMgbm90ZWQgaW4g YW5vdGhlciB0aHJlYWQsIHdlIHN0aWxsIGhhdmUgdG8gZmlndXJlIG91dCBob3cgdG8NCj4+Pj4+ Pj4+PmRlYWwNCj4+Pj4+Pj4+PndpdGggYWNjb21tb2RhdGluZyBpbnRlcmFjdGlvbiBvZiB0aGUg QkZEIHlhbmcgbW9kdWxlIHdpdGggY2xpZW50DQo+Pj4+Pj4+Pj5wcm90b2NvbHMuDQo+Pj4+Pj4+ Pj5Gb3INCj4+Pj4+Pj4+PmV4YW1wbGUsIHRoZSBJR1BzLiAgSW4gcGFydGljdWxhciwgaG93IGRv IHlvdSBjb25maWd1cmUgdGhlDQo+Pj4+Pj4+Pj5wcm9wZXJ0aWVzDQo+Pj4+Pj4+Pj5vZiB0aGUg QkZEIHNlc3Npb25zIHRoYXQgbWF5IGJlIGR5bmFtaWNhbGx5IGluc3RhbnRpYXRlZCBiYXNlZCBv bg0KPj4+Pj4+Pj4+Y29udHJvbCBwcm90b2NvbCBhY3Rpdml0eT8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+LS0gSmVmZg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5PbiBGcmksIEp1biAzMCwgMjAxNyBhdCAx Mjo1NTo1OVBNIC0wNzAwLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pndyb3Rl Og0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+Pj4+Pj5JbnRlcm5ldC1EcmFmdHMNCj4+Pj4+Pj4+ Pj5kaXJlY3Rvcmllcy4NCj4+Pj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+RGV0ZWN0aW9uDQo+Pj4+Pj4+ Pj4+b2YgdGhlIElFVEYuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAgICAgICAgIFRpdGxlICAg ICAgICAgICA6IFlBTkcgRGF0YSBNb2RlbCBmb3IgQmlkaXJlY3Rpb25hbA0KPj4+Pj4+Pj4+PkZv cndhcmRpbmcNCj4+Pj4+Pj4+Pj5EZXRlY3Rpb24gKEJGRCkNCj4+Pj4+Pj4+Pj4gICAgICAgICBB dXRob3JzICAgICAgICAgOiBSZXNoYWQgUmFobWFuDQo+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBTYW50b3NoIFBhbGxhZ2F0dGkNCj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+Pj4+Pj4gCVBhZ2VzICAgICAgICAgICA6IDU5DQo+ Pj4+Pj4+Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+Pj4+Pj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEg WUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8NCj4+Pj4+Pj4+Pj5jb25maWd1cmUN Cj4+Pj4+Pj4+Pj4gICAgYW5kIG1hbmFnZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uIChCRkQpLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1i ZmQteWFuZy8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6DQo+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUNCj4+Pj4+Pj4+Pj5vZg0KPj4+Pj4+Pj4+PnN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4+Pj4+Pj4+Pj50b29scy5p ZXRmLm9yZy4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+Pj4+Pj4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+ Pg0KPj4+Pg0KPj4+DQo+Pg0KPg0KDQo= From nobody Fri Jul 28 08:08:55 2017 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 3E5BA131C7A; Fri, 28 Jul 2017 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs_vT7wUeKvx; Fri, 28 Jul 2017 08:08:50 -0700 (PDT) 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 96D4C131566; Fri, 28 Jul 2017 08:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12210; q=dns/txt; s=iport; t=1501254530; x=1502464130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=172gH119Ogq04brhHUlQffsfRB2MBPaosgdZwMUquw4=; b=cNbiuXU4S31MKOaXebrwXajEZKS8pvtyywL0+izJUhKPZJDM+gw+8v1t ImRvJDl50ENgDGSgpkjeWk4sw//NK9L++MUN6X1mG2r3KcVuPBZB5awIK JpbUh6g8Dx1ISphabIJzSVypGMy3ocvgCxU5SVIpVyK3PMrtt6ZwXyfEF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQB6UntZ/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaPeoFrlgsOggQuhRkCGoNYPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQM0RQwEAgEIEQQBAQEEIwUCAjAUCQgCBAENBYovEJEPnVwGgiiLPwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BBYIjg02FCIMmgRoBEgE2gnaCZwWfbQKHTYx?= =?us-ascii?q?XggxXhHuKXpVxAR84fwt3FR+FQByBZgF2h0INFweBBQGBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208";a="462280624" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 15:08:49 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v6SF8m3Z019073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 15:08:48 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 10:08:48 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 10:08:48 -0500 From: "Reshad Rahman (rrahman)" To: "Acee Lindem (acee)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAOOAAA== Date: Fri, 28 Jul 2017 15:08:48 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.44] Content-Type: text/plain; charset="euc-kr" Content-ID: <97637216BB0D37458E7C2FD5DA982020@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:08:53 -0000 SGkgQWNlZSwNCg0KR290IHJpZCBvZiBpZXRmLWJmZC1jbGllbnRzLiBJIGhhdmUgYWRkZWQgZXhh bXBsZS1iZmQtY2xpZW50IG1vZHVsZSB0bw0KcHJvdmlkZSBhbiBleGFtcGxlLg0KDQpSZWdhcmRz LA0KUmVzaGFkLg0KDQoNCg0KT24gMjAxNy0wNy0yNywgMTA6MzQgUE0sICJBY2VlIExpbmRlbSAo YWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5IaSBSZXNoYWQsIA0KPg0KPk9rIC0g SSBzZWUgbm93LiBJIHdhcyBsb29raW5nIGF0IHRoZSB3cm9uZyB4eHh4LWJhc2UtY2ZnLXBhcm1z IGdyb3VwaW5ncy4NCj5GZXdlciBzaW1pbGFyIGdyb3VwaW5nIGFuZCBtb2R1bGVzIHdpbGwgYmUg YmV0dGVyIDteKQ0KPg0KPlRoYW5rcywNCj5BY2VlDQo+DQo+T24gNy8yNy8xNywgOTowMyBQTSwg IlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPg0K Pj5IaSBBY2VlLA0KPj4NCj4+V2hhdCBJIHNlZSBAIA0KPj5odHRwczovL2dpdGh1Yi5jb20vamhh YXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldGYtYmZkDQo+Pi0N Cj4+dA0KPj55cGVzLnlhbmc6DQo+PjEpIGJmZC1jbGllbnQtYmFzZS1jZmctcGFybXMgaGFzIGxl YWYgZW5hYmxlZCBvbmx5LiBCVFcgdGhpcyBncm91cGluZyBpcw0KPj5kZWZpbmVkIHR3aWNlLCB0 aGlzIHdpbGwgYmUgZml4ZWQgd2hlbiBJIGdldCByaWQgb2YgaWV0Zi1iZmQtY2xpZW50cy55YW5n DQo+PjIpIGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyBoYXMgbXVsdGlwbGllci90aW1lcnMu DQo+Pg0KPj5MZXQgbWUgZ2V0IHJpZCBvZiB0aGUgY2xpZW50IG1vZHVsZSBhbmQgaGF2ZSBldmVy eXRoaW5nIGluIHRoZSB0eXBlcw0KPj5tb2R1bGUuDQo+Pg0KPj5JIGFtIG5vdCBzdXJlIHdoeSB5 b3Whr3JlIG5vdCBzZWVpbmcgc29tZXRoaW5nIGRpZmZlcmVudC4NCj4+DQo+PlJlZ2FyZHMsDQo+ PlJlc2hhZC4NCj4+DQo+Pg0KPj4NCj4+T24gMjAxNy0wNy0yNywgMzo0MCBQTSwgIkFjZWUgTGlu ZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+DQo+Pj5IaSBSZXNoYWQsIA0K Pj4+DQo+Pj5PbiA3LzI3LzE3LCAzOjM1IFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxy cmFobWFuQGNpc2NvLmNvbT4NCj4+Pndyb3RlOg0KPj4+DQo+Pj4+SGkgQWNlZSwNCj4+Pj4NCj4+ Pj4xKSBJoa9sbCBzZWUgaWYgb3RoZXJzIGNoaW1lIGluIG9uIHRoaXMgYnV0IEkgYW0gZmluZSB3 aXRoIGhhdmluZyB0aGUNCj4+Pj5jbGllbnQgZ3JvdXBpbmcgaW4gaWV0Zi1iZmQtdHlwZXMueWFu Zy4NCj4+Pj4yKSBiZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBoYXMgbXVjaCBtb3JlIHRo YW4ganVzdCB0aGUNCj4+Pj5tdWx0aXBsaWVyL3RpbWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0 IGFsc28gaGFzIEJGRCBzcGVjaWZpYyBzdHVmZg0KPj4+PihkZW1hbmQtbW9kZSwgQkZEIGF1dGgp IHdoaWNoIElNTyBoYXMgbm8gYnVzaW5lc3Mgb3V0c2lkZSBvZiBCRkQuDQo+Pj4NCj4+PkFncmVl ZC4gDQo+Pj4NCj4+Pg0KPj4+PmJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyBoYXMgb25seSB0 aGUgbXVsdGlwbGllci90aW1lcnMuDQo+Pj4NCj4+PlBlcmhhcHMsIHRoZSBhZGRpdGlvbiBvZiBt dWx0aXBsaWVyL3RpbWVycyB0bw0KPj4+YmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+Pj5p c26hr3QgcHVzaGVkIHRvIEdpdEh1YiB5ZXQuIFRoaXMgdmVyc2lvbg0KPj4+aHR0cHM6Ly9naXRo dWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRm LWJmDQo+Pj5kDQo+Pj4tDQo+Pj50DQo+Pj55cGVzLnlhbmcgb25seSBoYXMgdGhlIGVuYWJsZWQg bGVhZi4NCj4+Pg0KPj4+DQo+Pj5UaGFua3MsDQo+Pj5BY2VlIA0KPj4+DQo+Pj4NCj4+Pj4NCj4+ Pj5SZWdhcmRzLA0KPj4+PlJlc2hhZC4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj5PbiAyMDE3LTA3 LTI3LCAzOjMwIFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3Rl Og0KPj4+Pg0KPj4+Pj5IaSBSZXNoYWQsIA0KPj4+Pj4NCj4+Pj4+T24gNy8yNy8xNywgMzoxOSBQ TSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+Pndy b3RlOg0KPj4+Pj4NCj4+Pj4+PkhpIEFjZWUsDQo+Pj4+Pj4NCj4+Pj4+PldoZW4gd2UgbWV0IHdl IGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiBBZnRlcndhcmRzIEkNCj4+ Pj4+PmRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwgYW5kIHN0aWxsIHdlbnQg YWhlYWQgd2l0aCB0aGUNCj4+Pj4+PmNsaWVudHMgbW9kdWxlLiBJIGFtIGZpbmUgd2l0aCBoYXZp bmcgZXZlcnl0aGluZyBpbiB0aGUgdHlwZXMgbW9kdWxlDQo+Pj4+Pj4obm8NCj4+Pj4+PmNsaWVu dCBtb2R1bGUpLg0KPj4+Pj4NCj4+Pj4+QWx0aG91Z2ggSSBkb26hr3QgZmVlbCB0aGF0IHN0cm9u Z2x5IC0gSSBqdXN0IGRvbqGvdCBzZWUgdGhhdCBwdXR0aW5nDQo+Pj4+PnRoZQ0KPj4+Pj5jbGll bnQgY29uZmlnIHBhcmFtcyBpbiB3cmFwcGVycyBwcm92aWRlcyBhbnkgYmVuZWZpdC4gQXMgZm9y DQo+Pj4+PmRldHJpbWVudHMsDQo+Pj4+Pml0IHJlcXVpcmVzIG1vcmUgb25lIG1vcmUgbG9jYWwg bW9kdWxlcyBmb3IgdmFsaWRhdGlvbiBhbmQgb25lIG1vcmUNCj4+Pj4+bGV2ZWwNCj4+Pj4+b2Yg aW5kaXJlY3Rpb24gdG8gc2VlIHdoYXQgd2UgYXJlIHJlYWxseSBhbGxvd2luZyB0byBiZSBjb25m aWd1cmVkLg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+SSBhbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVy c3RhbmQgeW91ciBjb21tZW50L3F1ZXN0aW9uIG9uDQo+Pj4+Pj5iZmQtY2xpZW50LWV4dC1jZmct cGFybXMvYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMuIFRoZSByZWFzb24gd2UNCj4+Pj4+ PmhhdmUNCj4+Pj4+PjIgZ3JvdXBpbmdzIGlzIHRoYXQgc29tZSBwcm90b2NvbHMgbWF5IGRlY2lk ZSB0byBoYXZlIGp1c3QgdGhlIGVuYWJsZQ0KPj4+Pj4+bGVhZg0KPj4+Pj4+YW5kIG90aGVycyBt YXkgYWxzbyB3YW50IHRoZSBtdWx0aXBsaWVyL3RpbWVyLg0KPj4+Pj4NCj4+Pj4+VGhlIGJmZC1j bGllbnQtZXh0LWNmZy1wYXJtcyBncm91cGluZyBzaG91bGQgdXNlDQo+Pj4+PmJmZC10eXBlczpi ZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPj4+Pj5iZmQtdHlwZXM6 YmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyAtIG5vPyBUaGlzIHdvdWxkIGJlIG1vcmUgb2J2aW91 cw0KPj4+Pj53L28NCj4+Pj4+dGhlIGNsaWVudCBtb2R1bGUuDQo+Pj4+Pg0KPj4+Pj5UaGFua3Ms DQo+Pj4+PkFjZWUgDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+UmVnYXJkcywNCj4+Pj4+ PlJlc2hhZC4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pk9uIDIwMTctMDctMjcsIDM6 MDcgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+ Pj4NCj4+Pj4+Pj5IaSBSZXNoYWQsIA0KPj4+Pj4+PldoeSBkbyB3ZSBuZWVkIGEgbmV3IFlBTkcg bW9kZWwgZm9yIGNsaWVudHM/IFdoeSBjYW6hr3QgdGhleSBqdXN0IHVzZQ0KPj4+Pj4+PmlldGYt YmZkLXR5cGVzLnlhbmc/IEmhr2QgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3NhcnkgbGV2ZWxz IG9mDQo+Pj4+Pj4+aW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tzIHdyb25nIHRvIG1lIHNp bmNlIHRoZSBncm91cGluZw0KPj4+Pj4+PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRo ZSBncm91cGluZw0KPj4+Pj4+PmJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcw0KPj4+Pj4+Pndo aWNoIG9ubHkgY29udGFpbnMgdGhlIGVuYWJsZWQgbGVhZi4gSSBiZWxpZXZlIHlvdSBtZWFudCB0 byB1c2UNCj4+Pj4+Pj5iZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBpbiB0aGUgb3RoZXIg bmV3IG1vZGVsLiBIb3dldmVyLCBJDQo+Pj4+Pj4+ZG9uoa90DQo+Pj4+Pj4+c2VlDQo+Pj4+Pj4+ YW55IHJlYXNvbiB3aHkgY2xpZW50IHNob3VsZG6hr3QgdXNlIHRoaXMgZGlyZWN0bHkuDQo+Pj4+ Pj4+VGhhbmtzLA0KPj4+Pj4+PkFjZWUgDQo+Pj4+Pj4+DQo+Pj4+Pj4+T24gNy8yNS8xNywgMjoz MyBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+ Pj4+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+PkhpIFlpbmd6aGVuLA0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+VGhlIGdyb3VwaW5nIGlzIGF2YWlsYWJsZSBADQo+Pj4+Pj4+Pmh0dHBzOi8vZ2l0aHViLmNv bS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbmcvaWUNCj4+Pj4+ Pj4+dA0KPj4+Pj4+Pj5mDQo+Pj4+Pj4+Pi0NCj4+Pj4+Pj4+Yg0KPj4+Pj4+Pj5mDQo+Pj4+Pj4+ PmQNCj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj5jDQo+Pj4+Pj4+PmxpZW50cy55YW5nDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj5JZiB5b3Wp9mQgbGlrZSBjaGFuZ2VzIHRvIHRoZSBncm91cGluZywgc2VuZCBtZSBh biBlbWFpbC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PlJlZ2FyZHMsDQo+Pj4+Pj4+PlJlc2hhZC4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pk9uIDIwMTctMDctMjEsIDEyOjIyIFBNLCAiWWluZ3poZW4gUXUiIDx5 aW5nemhlbi5xdUBodWF3ZWkuY29tPg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj5IaSBSZXNoYWQsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PlRoYW5rcyBmb3IgdGhlIHN1bW1hcnku DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PkJvdGggb3NwZiBhbmQgaXNpcyBtb2RlbHMgd2lsbCBtYWtl IGNvcnJlc3BvbmRpbmcgY2hhbmdlcyB3aGVuIHRoZQ0KPj4+Pj4+Pj4+bmV3DQo+Pj4+Pj4+Pj5C RkQgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5UaGFua3MsDQo+ Pj4+Pj4+Pj5ZaW5nemhlbg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+Pj4+RnJvbTogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgW21haWx0bzpy cmFobWFuQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+PlNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3 IDc6MTkgQU0NCj4+Pj4+Pj4+PlRvOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPjsgcnRn LWJmZEBpZXRmLm9yZw0KPj4+Pj4+Pj4+Q2M6IGRyYWZ0LWlldGYtYmZkLXlhbmdAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+Pj4+Pj4+Pj5TdWJqZWN0OiBSZTogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ V2UgKEJGRCBhbmQgT1NQRiBZQU5HIGF1dGhvcnMpIGhhZCBhIGRpc2N1c3Npb24geWVzdGVyZGF5 Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5UaGUgYWdyZWVtZW50IGlzIHRoYXQgc2luY2UgSUdQIHBl ZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdlIHdhbnQNCj4+Pj4+Pj4+PnRvDQo+Pj4+Pj4+Pj5h ZGQNCj4+Pj4+Pj4+PmJhY2sgdGhlIGJhc2ljIEJGRCBjb25maWcgKG11bHRpcGxpZXIgKyBpbnRl cnZhbHMpIGluIElHUCB2aWEgYQ0KPj4+Pj4+Pj4+Z3JvdXBpbmcuDQo+Pj4+Pj4+Pj5CRkQgd2ls bCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4gSUdQIEJG RA0KPj4+Pj4+Pj4+WUFORw0KPj4+Pj4+Pj4+d2lsbCBiZSBpbiBhIHNlcGFyYXRlIG1vZHVsZSAo c2VwYXJhdGUgZnJvbSB0aGUgbWFpbiBJR1AgbW9kdWxlKS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj5SZWdhcmRzLA0KPj4+Pj4+Pj4+UmVzaGFkLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj5PbiAyMDE3LTA3LTA1LCAxMjoyMSBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIEplZmZyZXkg SGFhcyINCj4+Pj4+Pj4+PjxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpo YWFzQHBmcmMub3JnPiB3cm90ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PlRoYW5rcyBhdXRob3Jz IGZvciB0aGUgZWRpdHMgb24gdGhlIEJGRCB5YW5nIG1vZHVsZS4gIFRoaXMgZ2V0cw0KPj4+Pj4+ Pj4+PnVzDQo+Pj4+Pj4+Pj4+YQ0KPj4+Pj4+Pj4+PnNpZ25pZmljYW50IHN0ZXAgY2xvc2VyIHRv IGFsaWdubWVudCB3aXRoIHRoZSByZXN0IG9mIElFVEYgZm9yDQo+Pj4+Pj4+Pj4+bmV0d29yaw0K Pj4+Pj4+Pj4+Pmluc3RhbmNpbmcuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+SSdkIGxpa2UgdG8g ZW5jb3VyYWdlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sgb24NCj4+Pj4+ Pj4+Pj50aGlzDQo+Pj4+Pj4+Pj4+aXNzdWUgYW5kIGFsc28gdGhlIGNoYW5nZXMgaW4gdGhlIG1v ZHVsZS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5BcyBub3RlZCBpbiBhbm90aGVyIHRocmVhZCwg d2Ugc3RpbGwgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyB0bw0KPj4+Pj4+Pj4+PmRlYWwNCj4+Pj4+ Pj4+Pj53aXRoIGFjY29tbW9kYXRpbmcgaW50ZXJhY3Rpb24gb2YgdGhlIEJGRCB5YW5nIG1vZHVs ZSB3aXRoIGNsaWVudA0KPj4+Pj4+Pj4+PnByb3RvY29scy4NCj4+Pj4+Pj4+Pj5Gb3INCj4+Pj4+ Pj4+Pj5leGFtcGxlLCB0aGUgSUdQcy4gIEluIHBhcnRpY3VsYXIsIGhvdyBkbyB5b3UgY29uZmln dXJlIHRoZQ0KPj4+Pj4+Pj4+PnByb3BlcnRpZXMNCj4+Pj4+Pj4+Pj5vZiB0aGUgQkZEIHNlc3Np b25zIHRoYXQgbWF5IGJlIGR5bmFtaWNhbGx5IGluc3RhbnRpYXRlZCBiYXNlZCBvbg0KPj4+Pj4+ Pj4+PmNvbnRyb2wgcHJvdG9jb2wgYWN0aXZpdHk/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+LS0g SmVmZg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pk9uIEZyaSwgSnVuIDMwLCAyMDE3IGF0IDEyOjU1 OjU5UE0gLTA3MDAsDQo+Pj4+Pj4+Pj4+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+ Pj4+d3JvdGU6DQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+Pj4+Pj4+Pj4+PkludGVybmV0LURyYWZ0 cw0KPj4+Pj4+Pj4+Pj5kaXJlY3Rvcmllcy4NCj4+Pj4+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3 b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+Pj4+Pj4+Pj5EZXRl Y3Rpb24NCj4+Pj4+Pj4+Pj4+b2YgdGhlIElFVEYuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBCaWRpcmVjdGlv bmFsDQo+Pj4+Pj4+Pj4+PkZvcndhcmRpbmcNCj4+Pj4+Pj4+Pj4+RGV0ZWN0aW9uIChCRkQpDQo+ Pj4+Pj4+Pj4+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+Pj4+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFsbGFnYXR0aQ0KPj4+Pj4+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4+Pj4g CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQo+Pj4+Pj4+Pj4+ PiAJUGFnZXMgICAgICAgICAgIDogNTkNCj4+Pj4+Pj4+Pj4+IAlEYXRlICAgICAgICAgICAgOiAy MDE3LTA2LTMwDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+Pj4+ Pj4gICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJl IHVzZWQgdG8NCj4+Pj4+Pj4+Pj4+Y29uZmlndXJlDQo+Pj4+Pj4+Pj4+PiAgICBhbmQgbWFuYWdl IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXlhbmcvDQo+Pj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXlh bmctMDYNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZQ0KPj4+ Pj4+Pj4+Pj5vZg0KPj4+Pj4+Pj4+Pj5zdWJtaXNzaW9uICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+Pj4+Pj4+Pj4+PnRvb2xzLmlldGYub3Jn Lg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pg0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Fri Jul 28 08:55:44 2017 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 21545131CA2; Fri, 28 Jul 2017 08:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbGV-v5fhlme; Fri, 28 Jul 2017 08:55:40 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F89129A96; Fri, 28 Jul 2017 08:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13036; q=dns/txt; s=iport; t=1501257340; x=1502466940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NHY873AGS9hOE3YPoGjlcypaq2C+v0sZpENFB3jvI4g=; b=QdUgSdh1CGX6fwhv9pqBuNU+s/E+CH341Qet+JAeWgfZiMzkBR0lxZLd cJfa4dy2z5i4SU2treL0dO+M/yc/+4LEXHIBNiO1GldSrTm1dWZIB/Quo QaKgiwe/Zj+0PE07jFg1heVcaVPD8A7D3Jh/Rwfw6HEGRI8FT71UQc/qR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQAdXXtZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaPeoFrlgsOggQuhRkCGoNYPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMjEUUMBAIBCBEEAQEBAgIjAwICAjAUAQgIAgQBDQWKLxCvNYImiz8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQuCHYhVgyaBGgESATaCfIJhBZ9tAodNjFe?= =?us-ascii?q?CDFeEe4pelXEBHzh/C3cVH4VAHIFmAXaHQg0XB4EFgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208";a="460831809" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 15:55:38 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6SFtcrZ016068 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 15:55:38 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 11:55:37 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 11:55:37 -0400 From: "Acee Lindem (acee)" To: "Reshad Rahman (rrahman)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAOOAAP///DeA Date: Fri, 28 Jul 2017 15:55:37 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <0210FDD2085C4348A0F68907F43265BB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:55:43 -0000 VGhhbmtzIG11Y2ggUmVzaGFkIC0gWWluZ3poZW4gd2lsbCBiZSBhZGRpbmcgYnV0IHRoZSBpZXRm LW9zcGYtYmZkIG1vZHVsZQ0KdG8gdGhlIE9TUEYgbW9kZWwgYW5kIGRyYWZ0Lg0KDQpBY2VlIA0K DQpPbiA3LzI4LzE3LCAxMTowOCBBTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1h bkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgQWNlZSwNCj4NCj5Hb3QgcmlkIG9mIGlldGYtYmZk LWNsaWVudHMuIEkgaGF2ZSBhZGRlZCBleGFtcGxlLWJmZC1jbGllbnQgbW9kdWxlIHRvDQo+cHJv dmlkZSBhbiBleGFtcGxlLg0KPg0KPlJlZ2FyZHMsDQo+UmVzaGFkLg0KPg0KPg0KPg0KPk9uIDIw MTctMDctMjcsIDEwOjM0IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+ IHdyb3RlOg0KPg0KPj5IaSBSZXNoYWQsIA0KPj4NCj4+T2sgLSBJIHNlZSBub3cuIEkgd2FzIGxv b2tpbmcgYXQgdGhlIHdyb25nIHh4eHgtYmFzZS1jZmctcGFybXMgZ3JvdXBpbmdzLg0KPj5GZXdl ciBzaW1pbGFyIGdyb3VwaW5nIGFuZCBtb2R1bGVzIHdpbGwgYmUgYmV0dGVyIDteKQ0KPj4NCj4+ VGhhbmtzLA0KPj5BY2VlDQo+Pg0KPj5PbiA3LzI3LzE3LCA5OjAzIFBNLCAiUmVzaGFkIFJhaG1h biAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SGkgQWNlZSwN Cj4+Pg0KPj4+V2hhdCBJIHNlZSBAIA0KPj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMv aWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRmLWJmDQo+Pj5kDQo+Pj4tDQo+ Pj50DQo+Pj55cGVzLnlhbmc6DQo+Pj4xKSBiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIGhhcyBs ZWFmIGVuYWJsZWQgb25seS4gQlRXIHRoaXMgZ3JvdXBpbmcgaXMNCj4+PmRlZmluZWQgdHdpY2Us IHRoaXMgd2lsbCBiZSBmaXhlZCB3aGVuIEkgZ2V0IHJpZCBvZg0KPj4+aWV0Zi1iZmQtY2xpZW50 cy55YW5nDQo+Pj4yKSBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG11bHRpcGxpZXIv dGltZXJzLg0KPj4+DQo+Pj5MZXQgbWUgZ2V0IHJpZCBvZiB0aGUgY2xpZW50IG1vZHVsZSBhbmQg aGF2ZSBldmVyeXRoaW5nIGluIHRoZSB0eXBlcw0KPj4+bW9kdWxlLg0KPj4+DQo+Pj5JIGFtIG5v dCBzdXJlIHdoeSB5b3XigJlyZSBub3Qgc2VlaW5nIHNvbWV0aGluZyBkaWZmZXJlbnQuDQo+Pj4N Cj4+PlJlZ2FyZHMsDQo+Pj5SZXNoYWQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj5PbiAyMDE3LTA3LTI3 LCAzOjQwIFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0K Pj4+DQo+Pj4+SGkgUmVzaGFkLCANCj4+Pj4NCj4+Pj5PbiA3LzI3LzE3LCAzOjM1IFBNLCAiUmVz aGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+ Pj4NCj4+Pj4+SGkgQWNlZSwNCj4+Pj4+DQo+Pj4+PjEpIEnigJlsbCBzZWUgaWYgb3RoZXJzIGNo aW1lIGluIG9uIHRoaXMgYnV0IEkgYW0gZmluZSB3aXRoIGhhdmluZyB0aGUNCj4+Pj4+Y2xpZW50 IGdyb3VwaW5nIGluIGlldGYtYmZkLXR5cGVzLnlhbmcuDQo+Pj4+PjIpIGJmZC1ncm91cGluZy1j b21tb24tY2ZnLXBhcm1zIGhhcyBtdWNoIG1vcmUgdGhhbiBqdXN0IHRoZQ0KPj4+Pj5tdWx0aXBs aWVyL3RpbWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYyBz dHVmZg0KPj4+Pj4oZGVtYW5kLW1vZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1c2lu ZXNzIG91dHNpZGUgb2YgQkZELg0KPj4+Pg0KPj4+PkFncmVlZC4gDQo+Pj4+DQo+Pj4+DQo+Pj4+ PmJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyBoYXMgb25seSB0aGUgbXVsdGlwbGllci90aW1l cnMuDQo+Pj4+DQo+Pj4+UGVyaGFwcywgdGhlIGFkZGl0aW9uIG9mIG11bHRpcGxpZXIvdGltZXJz IHRvDQo+Pj4+YmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+Pj4+aXNu4oCZdCBwdXNoZWQg dG8gR2l0SHViIHlldC4gVGhpcyB2ZXJzaW9uDQo+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFz LXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRmLWINCj4+Pj5mDQo+ Pj4+ZA0KPj4+Pi0NCj4+Pj50DQo+Pj4+eXBlcy55YW5nIG9ubHkgaGFzIHRoZSBlbmFibGVkIGxl YWYuDQo+Pj4+DQo+Pj4+DQo+Pj4+VGhhbmtzLA0KPj4+PkFjZWUgDQo+Pj4+DQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj5SZWdhcmRzLA0KPj4+Pj5SZXNoYWQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ Pk9uIDIwMTctMDctMjcsIDM6MzAgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2Nv LmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4+SGkgUmVzaGFkLCANCj4+Pj4+Pg0KPj4+Pj4+T24g Ny8yNy8xNywgMzoxOSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNj by5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+PkhpIEFjZWUsDQo+Pj4+Pj4+DQo+ Pj4+Pj4+V2hlbiB3ZSBtZXQgd2UgYWdyZWVkIHRvIGhhdmUgYSBuZXcgbW9kZWwgZm9yIGNsaWVu dHMuIEFmdGVyd2FyZHMgSQ0KPj4+Pj4+PmRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1v ZHVsZSwgYW5kIHN0aWxsIHdlbnQgYWhlYWQgd2l0aCB0aGUNCj4+Pj4+Pj5jbGllbnRzIG1vZHVs ZS4gSSBhbSBmaW5lIHdpdGggaGF2aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzIG1vZHVsZQ0K Pj4+Pj4+Pihubw0KPj4+Pj4+PmNsaWVudCBtb2R1bGUpLg0KPj4+Pj4+DQo+Pj4+Pj5BbHRob3Vn aCBJIGRvbuKAmXQgZmVlbCB0aGF0IHN0cm9uZ2x5IC0gSSBqdXN0IGRvbuKAmXQgc2VlIHRoYXQg cHV0dGluZw0KPj4+Pj4+dGhlDQo+Pj4+Pj5jbGllbnQgY29uZmlnIHBhcmFtcyBpbiB3cmFwcGVy cyBwcm92aWRlcyBhbnkgYmVuZWZpdC4gQXMgZm9yDQo+Pj4+Pj5kZXRyaW1lbnRzLA0KPj4+Pj4+ aXQgcmVxdWlyZXMgbW9yZSBvbmUgbW9yZSBsb2NhbCBtb2R1bGVzIGZvciB2YWxpZGF0aW9uIGFu ZCBvbmUgbW9yZQ0KPj4+Pj4+bGV2ZWwNCj4+Pj4+Pm9mIGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0 IHdlIGFyZSByZWFsbHkgYWxsb3dpbmcgdG8gYmUgY29uZmlndXJlZC4NCj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+PkkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudC9x dWVzdGlvbiBvbg0KPj4+Pj4+PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcy9iZmQtZ3JvdXBpbmct Y29tbW9uLWNmZy1wYXJtcy4gVGhlIHJlYXNvbg0KPj4+Pj4+PndlDQo+Pj4+Pj4+aGF2ZQ0KPj4+ Pj4+PjIgZ3JvdXBpbmdzIGlzIHRoYXQgc29tZSBwcm90b2NvbHMgbWF5IGRlY2lkZSB0byBoYXZl IGp1c3QgdGhlDQo+Pj4+Pj4+ZW5hYmxlDQo+Pj4+Pj4+bGVhZg0KPj4+Pj4+PmFuZCBvdGhlcnMg bWF5IGFsc28gd2FudCB0aGUgbXVsdGlwbGllci90aW1lci4NCj4+Pj4+Pg0KPj4+Pj4+VGhlIGJm ZC1jbGllbnQtZXh0LWNmZy1wYXJtcyBncm91cGluZyBzaG91bGQgdXNlDQo+Pj4+Pj5iZmQtdHlw ZXM6YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgcmF0aGVyIHRoYW4NCj4+Pj4+PmJmZC10 eXBlczpiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMgd291bGQgYmUgbW9yZSBv YnZpb3VzDQo+Pj4+Pj53L28NCj4+Pj4+PnRoZSBjbGllbnQgbW9kdWxlLg0KPj4+Pj4+DQo+Pj4+ Pj5UaGFua3MsDQo+Pj4+Pj5BY2VlIA0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj5S ZWdhcmRzLA0KPj4+Pj4+PlJlc2hhZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj5PbiAyMDE3LTA3LTI3LCAzOjA3IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNj by5jb20+IHdyb3RlOg0KPj4+Pj4+Pg0KPj4+Pj4+Pj5IaSBSZXNoYWQsIA0KPj4+Pj4+Pj5XaHkg ZG8gd2UgbmVlZCBhIG5ldyBZQU5HIG1vZGVsIGZvciBjbGllbnRzPyBXaHkgY2Fu4oCZdCB0aGV5 IGp1c3QNCj4+Pj4+Pj4+dXNlDQo+Pj4+Pj4+PmlldGYtYmZkLXR5cGVzLnlhbmc/IEnigJlkIGxp a2UgdG8gYXZvaWQgdGhlIHVubmVjZXNzYXJ5IGxldmVscyBvZg0KPj4+Pj4+Pj5pbmRpcmVjdGlv bi4gSW4gZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUgc2luY2UgdGhlIGdyb3VwaW5nDQo+Pj4+ Pj4+PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBncm91cGluZw0KPj4+Pj4+Pj5i ZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMNCj4+Pj4+Pj4+d2hpY2ggb25seSBjb250YWlucyB0 aGUgZW5hYmxlZCBsZWFmLiBJIGJlbGlldmUgeW91IG1lYW50IHRvIHVzZQ0KPj4+Pj4+Pj5iZmQt Z3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBpbiB0aGUgb3RoZXIgbmV3IG1vZGVsLiBIb3dldmVy LCBJDQo+Pj4+Pj4+PmRvbuKAmXQNCj4+Pj4+Pj4+c2VlDQo+Pj4+Pj4+PmFueSByZWFzb24gd2h5 IGNsaWVudCBzaG91bGRu4oCZdCB1c2UgdGhpcyBkaXJlY3RseS4NCj4+Pj4+Pj4+VGhhbmtzLA0K Pj4+Pj4+Pj5BY2VlIA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+T24gNy8yNS8xNywgMjozMyBQTSwgIlJl c2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+Pj4+Pndyb3Rl Og0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PkhpIFlpbmd6aGVuLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5U aGUgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlIEANCj4+Pj4+Pj4+Pmh0dHBzOi8vZ2l0aHViLmNvbS9q aGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbmcvaQ0KPj4+Pj4+Pj4+ ZQ0KPj4+Pj4+Pj4+dA0KPj4+Pj4+Pj4+Zg0KPj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj4+Yg0KPj4+Pj4+ Pj4+Zg0KPj4+Pj4+Pj4+ZA0KPj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj4+Yw0KPj4+Pj4+Pj4+bGllbnRz LnlhbmcNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+SWYgeW91wrlkIGxpa2UgY2hhbmdlcyB0byB0aGUg Z3JvdXBpbmcsIHNlbmQgbWUgYW4gZW1haWwuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PlJlZ2FyZHMs DQo+Pj4+Pj4+Pj5SZXNoYWQuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pk9uIDIwMTctMDctMjEsIDEy OjIyIFBNLCAiWWluZ3poZW4gUXUiIDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPg0KPj4+Pj4+Pj4+ d3JvdGU6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5IaSBSZXNoYWQsDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5Cb3Ro IG9zcGYgYW5kIGlzaXMgbW9kZWxzIHdpbGwgbWFrZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgd2hl bg0KPj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+Pm5ldw0KPj4+Pj4+Pj4+PkJGRCBncm91cGluZyBp cyBhdmFpbGFibGUuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+VGhhbmtzLA0KPj4+Pj4+Pj4+Pllp bmd6aGVuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4+Pj4+Pj5Gcm9tOiBSZXNoYWQgUmFobWFuIChycmFobWFuKSBbbWFpbHRvOnJyYWhtYW5A Y2lzY28uY29tXQ0KPj4+Pj4+Pj4+PlNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDc6MTkg QU0NCj4+Pj4+Pj4+Pj5UbzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz47IHJ0Zy1iZmRA aWV0Zi5vcmcNCj4+Pj4+Pj4+Pj5DYzogZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj5TdWJqZWN0OiBSZTogSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5X ZSAoQkZEIGFuZCBPU1BGIFlBTkcgYXV0aG9ycykgaGFkIGEgZGlzY3Vzc2lvbiB5ZXN0ZXJkYXku DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+VGhlIGFncmVlbWVudCBpcyB0aGF0IHNpbmNlIElHUCBw ZWVycyBhcmUgYXV0by1kaXNjb3ZlcmVkLCB3ZQ0KPj4+Pj4+Pj4+PndhbnQNCj4+Pj4+Pj4+Pj50 bw0KPj4+Pj4+Pj4+PmFkZA0KPj4+Pj4+Pj4+PmJhY2sgdGhlIGJhc2ljIEJGRCBjb25maWcgKG11 bHRpcGxpZXIgKyBpbnRlcnZhbHMpIGluIElHUCB2aWEgYQ0KPj4+Pj4+Pj4+Pmdyb3VwaW5nLg0K Pj4+Pj4+Pj4+PkJGRCB3aWxsIHByb3ZpZGUgdGhhdCBncm91cGluZyBpbiBhIHNwZWNpZmljIFlB TkcgbW9kdWxlLiBJR1AgQkZEDQo+Pj4+Pj4+Pj4+WUFORw0KPj4+Pj4+Pj4+PndpbGwgYmUgaW4g YSBzZXBhcmF0ZSBtb2R1bGUgKHNlcGFyYXRlIGZyb20gdGhlIG1haW4gSUdQIG1vZHVsZSkuDQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pj4+Pj5SZXNo YWQuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+T24gMjAxNy0wNy0wNSwgMTI6MjEgUE0sICJSdGct YmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+Pj4+Pj4+PHJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhhYXNAcGZyYy5vcmc+IHdyb3RlOg0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRoZSBCRkQgeWFu ZyBtb2R1bGUuICBUaGlzIGdldHMNCj4+Pj4+Pj4+Pj4+dXMNCj4+Pj4+Pj4+Pj4+YQ0KPj4+Pj4+ Pj4+Pj5zaWduaWZpY2FudCBzdGVwIGNsb3NlciB0byBhbGlnbm1lbnQgd2l0aCB0aGUgcmVzdCBv ZiBJRVRGIGZvcg0KPj4+Pj4+Pj4+Pj5uZXR3b3JrDQo+Pj4+Pj4+Pj4+Pmluc3RhbmNpbmcuDQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj5JJ2QgbGlrZSB0byBlbmNvdXJhZ2UgdGhlIHdvcmtpbmcg Z3JvdXAgdG8gcHJvdmlkZSBmZWVkYmFjayBvbg0KPj4+Pj4+Pj4+Pj50aGlzDQo+Pj4+Pj4+Pj4+ Pmlzc3VlIGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj5BcyBub3RlZCBpbiBhbm90aGVyIHRocmVhZCwgd2Ugc3RpbGwgaGF2ZSB0byBm aWd1cmUgb3V0IGhvdyB0bw0KPj4+Pj4+Pj4+Pj5kZWFsDQo+Pj4+Pj4+Pj4+PndpdGggYWNjb21t b2RhdGluZyBpbnRlcmFjdGlvbiBvZiB0aGUgQkZEIHlhbmcgbW9kdWxlIHdpdGgNCj4+Pj4+Pj4+ Pj4+Y2xpZW50DQo+Pj4+Pj4+Pj4+PnByb3RvY29scy4NCj4+Pj4+Pj4+Pj4+Rm9yDQo+Pj4+Pj4+ Pj4+PmV4YW1wbGUsIHRoZSBJR1BzLiAgSW4gcGFydGljdWxhciwgaG93IGRvIHlvdSBjb25maWd1 cmUgdGhlDQo+Pj4+Pj4+Pj4+PnByb3BlcnRpZXMNCj4+Pj4+Pj4+Pj4+b2YgdGhlIEJGRCBzZXNz aW9ucyB0aGF0IG1heSBiZSBkeW5hbWljYWxseSBpbnN0YW50aWF0ZWQgYmFzZWQNCj4+Pj4+Pj4+ Pj4+b24NCj4+Pj4+Pj4+Pj4+Y29udHJvbCBwcm90b2NvbCBhY3Rpdml0eT8NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pi0tIEplZmYNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pk9uIEZyaSwgSnVu IDMwLCAyMDE3IGF0IDEyOjU1OjU5UE0gLTA3MDAsDQo+Pj4+Pj4+Pj4+PmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZQ0KPj4+ Pj4+Pj4+Pj4+SW50ZXJuZXQtRHJhZnRzDQo+Pj4+Pj4+Pj4+Pj5kaXJlY3Rvcmllcy4NCj4+Pj4+ Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBCaWRpcmVjdGlvbmFsIEZv cndhcmRpbmcNCj4+Pj4+Pj4+Pj4+PkRldGVjdGlvbg0KPj4+Pj4+Pj4+Pj4+b2YgdGhlIElFVEYu DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZ QU5HIERhdGEgTW9kZWwgZm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Pj4+Pj4+PkZvcndhcmRpbmcN Cj4+Pj4+Pj4+Pj4+PkRldGVjdGlvbiAoQkZEKQ0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgQXV0aG9y cyAgICAgICAgIDogUmVzaGFkIFJhaG1hbg0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgTWFoZXNoIEpldGhhbmFuZGFuaQ0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgU2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAg OiA1OQ0KPj4+Pj4+Pj4+Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4+Pj4gICAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgdG8NCj4+Pj4+ Pj4+Pj4+PmNvbmZpZ3VyZQ0KPj4+Pj4+Pj4+Pj4+ICAgIGFuZCBtYW5hZ2UgQmlkaXJlY3Rpb25h bCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKS4NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0KPj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoN Cj4+Pj4+Pj4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmQt eWFuZy0wNg0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IEEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQteWFu Zy0wNg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lDQo+ Pj4+Pj4+Pj4+Pj5vZg0KPj4+Pj4+Pj4+Pj4+c3VibWlzc2lvbiAgdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZQ0KPj4+Pj4+Pj4+Pj4+YXQNCj4+Pj4+Pj4+ Pj4+PnRvb2xzLmlldGYub3JnLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+Pj4+Pj4+ Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+Pg0KPj4N Cj4NCg0K From nobody Fri Jul 28 09:26:08 2017 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 08297124217; Fri, 28 Jul 2017 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 B05ItrCgHtZL; Fri, 28 Jul 2017 09:26:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D8F13215D; Fri, 28 Jul 2017 09:26:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLM23784; Fri, 28 Jul 2017 16:26:01 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Jul 2017 17:26:00 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Fri, 28 Jul 2017 09:25:55 -0700 From: Yingzhen Qu To: "Acee Lindem (acee)" , "Reshad Rahman (rrahman)" , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAOOAAP///DeAAAEH/JA= Date: Fri, 28 Jul 2017 16:25:54 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B53867F@dfweml501-mbx> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.597B6599.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f51b081ef726120ca0b85531009b970e Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:26:07 -0000 SGkgUmVzaGFkLA0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGUgYW5kIGV4YW1wbGUuIEknbGwgZ2V0 IG9zcGYgcGFydCBkb25lIHRoaXMgd2Vla2VuZC4NCg0KVGhhbmtzLA0KWWluZ3poZW4gDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0 bzphY2VlQGNpc2NvLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgODo1NiBBTQ0K VG86IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIDxycmFobWFuQGNpc2NvLmNvbT47IFlpbmd6aGVu IFF1IDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPjsgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9y Zz47IHJ0Zy1iZmRAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3JnOyBk cmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRy YWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQoNClRoYW5rcyBtdWNoIFJlc2hhZCAtIFlpbmd6aGVu IHdpbGwgYmUgYWRkaW5nIGJ1dCB0aGUgaWV0Zi1vc3BmLWJmZCBtb2R1bGUgdG8gdGhlIE9TUEYg bW9kZWwgYW5kIGRyYWZ0Lg0KDQpBY2VlIA0KDQpPbiA3LzI4LzE3LCAxMTowOCBBTSwgIlJlc2hh ZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgQWNl ZSwNCj4NCj5Hb3QgcmlkIG9mIGlldGYtYmZkLWNsaWVudHMuIEkgaGF2ZSBhZGRlZCBleGFtcGxl LWJmZC1jbGllbnQgbW9kdWxlIHRvIA0KPnByb3ZpZGUgYW4gZXhhbXBsZS4NCj4NCj5SZWdhcmRz LA0KPlJlc2hhZC4NCj4NCj4NCj4NCj5PbiAyMDE3LTA3LTI3LCAxMDozNCBQTSwgIkFjZWUgTGlu ZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4NCj4+SGkgUmVzaGFkLA0KPj4N Cj4+T2sgLSBJIHNlZSBub3cuIEkgd2FzIGxvb2tpbmcgYXQgdGhlIHdyb25nIHh4eHgtYmFzZS1j ZmctcGFybXMgZ3JvdXBpbmdzLg0KPj5GZXdlciBzaW1pbGFyIGdyb3VwaW5nIGFuZCBtb2R1bGVz IHdpbGwgYmUgYmV0dGVyIDteKQ0KPj4NCj4+VGhhbmtzLA0KPj5BY2VlDQo+Pg0KPj5PbiA3LzI3 LzE3LCA5OjAzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNv bT4gd3JvdGU6DQo+Pg0KPj4+SGkgQWNlZSwNCj4+Pg0KPj4+V2hhdCBJIHNlZSBADQo+Pj5odHRw czovL2dpdGh1Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95 YW5nL2lldGYNCj4+Pi1iZg0KPj4+ZA0KPj4+LQ0KPj4+dA0KPj4+eXBlcy55YW5nOg0KPj4+MSkg YmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyBoYXMgbGVhZiBlbmFibGVkIG9ubHkuIEJUVyB0aGlz IGdyb3VwaW5nIA0KPj4+aXMgZGVmaW5lZCB0d2ljZSwgdGhpcyB3aWxsIGJlIGZpeGVkIHdoZW4g SSBnZXQgcmlkIG9mIA0KPj4+aWV0Zi1iZmQtY2xpZW50cy55YW5nDQo+Pj4yKSBiZmQtZ3JvdXBp bmctYmFzZS1jZmctcGFybXMgaGFzIG11bHRpcGxpZXIvdGltZXJzLg0KPj4+DQo+Pj5MZXQgbWUg Z2V0IHJpZCBvZiB0aGUgY2xpZW50IG1vZHVsZSBhbmQgaGF2ZSBldmVyeXRoaW5nIGluIHRoZSB0 eXBlcyANCj4+Pm1vZHVsZS4NCj4+Pg0KPj4+SSBhbSBub3Qgc3VyZSB3aHkgeW914oCZcmUgbm90 IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+UmVzaGFk Lg0KPj4+DQo+Pj4NCj4+Pg0KPj4+T24gMjAxNy0wNy0yNywgMzo0MCBQTSwgIkFjZWUgTGluZGVt IChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pg0KPj4+PkhpIFJlc2hhZCwNCj4+ Pj4NCj4+Pj5PbiA3LzI3LzE3LCAzOjM1IFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxy cmFobWFuQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+Pj4+SGkgQWNlZSwNCj4+Pj4+ DQo+Pj4+PjEpIEnigJlsbCBzZWUgaWYgb3RoZXJzIGNoaW1lIGluIG9uIHRoaXMgYnV0IEkgYW0g ZmluZSB3aXRoIGhhdmluZyANCj4+Pj4+dGhlIGNsaWVudCBncm91cGluZyBpbiBpZXRmLWJmZC10 eXBlcy55YW5nLg0KPj4+Pj4yKSBiZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBoYXMgbXVj aCBtb3JlIHRoYW4ganVzdCB0aGUgDQo+Pj4+Pm11bHRpcGxpZXIvdGltZXJzIHRoYXQgdGhlIElH UHMgbmVlZC4gSXQgYWxzbyBoYXMgQkZEIHNwZWNpZmljIA0KPj4+Pj5zdHVmZiAoZGVtYW5kLW1v ZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1c2luZXNzIG91dHNpZGUgb2YgQkZELg0K Pj4+Pg0KPj4+PkFncmVlZC4gDQo+Pj4+DQo+Pj4+DQo+Pj4+PmJmZC1ncm91cGluZy1iYXNlLWNm Zy1wYXJtcyBoYXMgb25seSB0aGUgbXVsdGlwbGllci90aW1lcnMuDQo+Pj4+DQo+Pj4+UGVyaGFw cywgdGhlIGFkZGl0aW9uIG9mIG11bHRpcGxpZXIvdGltZXJzIHRvIA0KPj4+PmJmZC1ncm91cGlu Zy1iYXNlLWNmZy1wYXJtcyBpc27igJl0IHB1c2hlZCB0byBHaXRIdWIgeWV0LiBUaGlzIHZlcnNp b24gDQo+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9i L21hc3Rlci9zcmMveWFuZy9pZXQNCj4+Pj5mLWINCj4+Pj5mDQo+Pj4+ZA0KPj4+Pi0NCj4+Pj50 DQo+Pj4+eXBlcy55YW5nIG9ubHkgaGFzIHRoZSBlbmFibGVkIGxlYWYuDQo+Pj4+DQo+Pj4+DQo+ Pj4+VGhhbmtzLA0KPj4+PkFjZWUNCj4+Pj4NCj4+Pj4NCj4+Pj4+DQo+Pj4+PlJlZ2FyZHMsDQo+ Pj4+PlJlc2hhZC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+T24gMjAxNy0wNy0yNywgMzoz MCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+ DQo+Pj4+Pj5IaSBSZXNoYWQsDQo+Pj4+Pj4NCj4+Pj4+Pk9uIDcvMjcvMTcsIDM6MTkgUE0sICJS ZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+Pj4+d3JvdGU6 DQo+Pj4+Pj4NCj4+Pj4+Pj5IaSBBY2VlLA0KPj4+Pj4+Pg0KPj4+Pj4+PldoZW4gd2UgbWV0IHdl IGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiBBZnRlcndhcmRzIA0KPj4+ Pj4+PkkgZGVjaWRlZCB0byBjcmVhdGUgYSBuZXcgdHlwZXMgbW9kdWxlLCBhbmQgc3RpbGwgd2Vu dCBhaGVhZCB3aXRoIA0KPj4+Pj4+PnRoZSBjbGllbnRzIG1vZHVsZS4gSSBhbSBmaW5lIHdpdGgg aGF2aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzIA0KPj4+Pj4+Pm1vZHVsZSAobm8gY2xpZW50 IG1vZHVsZSkuDQo+Pj4+Pj4NCj4+Pj4+PkFsdGhvdWdoIEkgZG9u4oCZdCBmZWVsIHRoYXQgc3Ry b25nbHkgLSBJIGp1c3QgZG9u4oCZdCBzZWUgdGhhdCANCj4+Pj4+PnB1dHRpbmcgdGhlIGNsaWVu dCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3ZpZGVzIGFueSBiZW5lZml0LiANCj4+Pj4+ PkFzIGZvciBkZXRyaW1lbnRzLCBpdCByZXF1aXJlcyBtb3JlIG9uZSBtb3JlIGxvY2FsIG1vZHVs ZXMgZm9yIA0KPj4+Pj4+dmFsaWRhdGlvbiBhbmQgb25lIG1vcmUgbGV2ZWwgb2YgaW5kaXJlY3Rp b24gdG8gc2VlIHdoYXQgd2UgYXJlIA0KPj4+Pj4+cmVhbGx5IGFsbG93aW5nIHRvIGJlIGNvbmZp Z3VyZWQuDQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj5JIGFtIG5vdCBzdXJlIEkgZnVsbHkgdW5k ZXJzdGFuZCB5b3VyIGNvbW1lbnQvcXVlc3Rpb24gb24NCj4+Pj4+Pj5iZmQtY2xpZW50LWV4dC1j ZmctcGFybXMvYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMuIFRoZSByZWFzb24NCj4+Pj4+ Pj53ZQ0KPj4+Pj4+PmhhdmUNCj4+Pj4+Pj4yIGdyb3VwaW5ncyBpcyB0aGF0IHNvbWUgcHJvdG9j b2xzIG1heSBkZWNpZGUgdG8gaGF2ZSBqdXN0IHRoZQ0KPj4+Pj4+PmVuYWJsZQ0KPj4+Pj4+Pmxl YWYNCj4+Pj4+Pj5hbmQgb3RoZXJzIG1heSBhbHNvIHdhbnQgdGhlIG11bHRpcGxpZXIvdGltZXIu DQo+Pj4+Pj4NCj4+Pj4+PlRoZSBiZmQtY2xpZW50LWV4dC1jZmctcGFybXMgZ3JvdXBpbmcgc2hv dWxkIHVzZQ0KPj4+Pj4+YmZkLXR5cGVzOmJmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zIHJh dGhlciB0aGFuDQo+Pj4+Pj5iZmQtdHlwZXM6YmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyAtIG5v PyBUaGlzIHdvdWxkIGJlIG1vcmUgb2J2aW91cw0KPj4+Pj4+dy9vDQo+Pj4+Pj50aGUgY2xpZW50 IG1vZHVsZS4NCj4+Pj4+Pg0KPj4+Pj4+VGhhbmtzLA0KPj4+Pj4+QWNlZSANCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pj5SZXNoYWQuDQo+Pj4+Pj4+DQo+ Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+T24gMjAxNy0wNy0yNywgMzowNyBQTSwgIkFjZWUgTGlu ZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+SGkg UmVzaGFkLCANCj4+Pj4+Pj4+V2h5IGRvIHdlIG5lZWQgYSBuZXcgWUFORyBtb2RlbCBmb3IgY2xp ZW50cz8gV2h5IGNhbuKAmXQgdGhleSBqdXN0DQo+Pj4+Pj4+PnVzZQ0KPj4+Pj4+Pj5pZXRmLWJm ZC10eXBlcy55YW5nPyBJ4oCZZCBsaWtlIHRvIGF2b2lkIHRoZSB1bm5lY2Vzc2FyeSBsZXZlbHMg b2YNCj4+Pj4+Pj4+aW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tzIHdyb25nIHRvIG1lIHNp bmNlIHRoZSBncm91cGluZw0KPj4+Pj4+Pj5iZmQtY2xpZW50LWV4dC1jZmctcGFybXMgdXNlcyB0 aGUgZ3JvdXBpbmcNCj4+Pj4+Pj4+YmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+Pj4+Pj4+ PndoaWNoIG9ubHkgY29udGFpbnMgdGhlIGVuYWJsZWQgbGVhZi4gSSBiZWxpZXZlIHlvdSBtZWFu dCB0byB1c2UNCj4+Pj4+Pj4+YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90 aGVyIG5ldyBtb2RlbC4gSG93ZXZlciwgSQ0KPj4+Pj4+Pj5kb27igJl0DQo+Pj4+Pj4+PnNlZQ0K Pj4+Pj4+Pj5hbnkgcmVhc29uIHdoeSBjbGllbnQgc2hvdWxkbuKAmXQgdXNlIHRoaXMgZGlyZWN0 bHkuDQo+Pj4+Pj4+PlRoYW5rcywNCj4+Pj4+Pj4+QWNlZSANCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pk9u IDcvMjUvMTcsIDI6MzMgUE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lz Y28uY29tPg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5IaSBZaW5nemhlbiwN Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+VGhlIGdyb3VwaW5nIGlzIGF2YWlsYWJsZSBADQo+Pj4+Pj4+ Pj5odHRwczovL2dpdGh1Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVy L3NyYy95YW5nL2kNCj4+Pj4+Pj4+PmUNCj4+Pj4+Pj4+PnQNCj4+Pj4+Pj4+PmYNCj4+Pj4+Pj4+ Pi0NCj4+Pj4+Pj4+PmINCj4+Pj4+Pj4+PmYNCj4+Pj4+Pj4+PmQNCj4+Pj4+Pj4+Pi0NCj4+Pj4+ Pj4+PmMNCj4+Pj4+Pj4+PmxpZW50cy55YW5nDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PklmIHlvdcK5 ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBzZW5kIG1lIGFuIGVtYWlsLg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj5SZWdhcmRzLA0KPj4+Pj4+Pj4+UmVzaGFkLg0KPj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj5PbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8eWluZ3poZW4ucXVA aHVhd2VpLmNvbT4NCj4+Pj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+SGkgUmVz aGFkLA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PlRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Qm90aCBvc3BmIGFuZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29y cmVzcG9uZGluZyBjaGFuZ2VzIHdoZW4NCj4+Pj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+Pj5uZXcNCj4+ Pj4+Pj4+Pj5CRkQgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PlRoYW5rcywNCj4+Pj4+Pj4+Pj5ZaW5nemhlbg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+RnJvbTogUmVzaGFkIFJhaG1hbiAocnJh aG1hbikgW21haWx0bzpycmFobWFuQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+Pj5TZW50OiBUaHVyc2Rh eSwgSnVseSAyMCwgMjAxNyA3OjE5IEFNDQo+Pj4+Pj4+Pj4+VG86IEplZmZyZXkgSGFhcyA8amhh YXNAcGZyYy5vcmc+OyBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Q2M6IGRyYWZ0LWlldGYt YmZkLXlhbmdAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+Pj4+Pj4+ Pj4+U3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQo+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+V2UgKEJGRCBhbmQgT1NQRiBZQU5HIGF1dGhvcnMpIGhhZCBh IGRpc2N1c3Npb24geWVzdGVyZGF5Lg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PlRoZSBhZ3JlZW1l bnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJlZCwgd2UNCj4+Pj4+ Pj4+Pj53YW50DQo+Pj4+Pj4+Pj4+dG8NCj4+Pj4+Pj4+Pj5hZGQNCj4+Pj4+Pj4+Pj5iYWNrIHRo ZSBiYXNpYyBCRkQgY29uZmlnIChtdWx0aXBsaWVyICsgaW50ZXJ2YWxzKSBpbiBJR1AgdmlhIGEN Cj4+Pj4+Pj4+Pj5ncm91cGluZy4NCj4+Pj4+Pj4+Pj5CRkQgd2lsbCBwcm92aWRlIHRoYXQgZ3Jv dXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4gSUdQIEJGRA0KPj4+Pj4+Pj4+PllBTkcN Cj4+Pj4+Pj4+Pj53aWxsIGJlIGluIGEgc2VwYXJhdGUgbW9kdWxlIChzZXBhcmF0ZSBmcm9tIHRo ZSBtYWluIElHUCBtb2R1bGUpLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PlJl Z2FyZHMsDQo+Pj4+Pj4+Pj4+UmVzaGFkLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pk9uIDIwMTct MDctMDUsIDEyOjIxIFBNLCAiUnRnLWJmZCBvbiBiZWhhbGYgb2YgSmVmZnJleSBIYWFzIg0KPj4+ Pj4+Pj4+PjxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMu b3JnPiB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+VGhhbmtzIGF1dGhvcnMgZm9yIHRo ZSBlZGl0cyBvbiB0aGUgQkZEIHlhbmcgbW9kdWxlLiAgVGhpcyBnZXRzDQo+Pj4+Pj4+Pj4+PnVz DQo+Pj4+Pj4+Pj4+PmENCj4+Pj4+Pj4+Pj4+c2lnbmlmaWNhbnQgc3RlcCBjbG9zZXIgdG8gYWxp Z25tZW50IHdpdGggdGhlIHJlc3Qgb2YgSUVURiBmb3INCj4+Pj4+Pj4+Pj4+bmV0d29yaw0KPj4+ Pj4+Pj4+Pj5pbnN0YW5jaW5nLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+SSdkIGxpa2UgdG8g ZW5jb3VyYWdlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sgb24NCj4+Pj4+ Pj4+Pj4+dGhpcw0KPj4+Pj4+Pj4+Pj5pc3N1ZSBhbmQgYWxzbyB0aGUgY2hhbmdlcyBpbiB0aGUg bW9kdWxlLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+QXMgbm90ZWQgaW4gYW5vdGhlciB0aHJl YWQsIHdlIHN0aWxsIGhhdmUgdG8gZmlndXJlIG91dCBob3cgdG8NCj4+Pj4+Pj4+Pj4+ZGVhbA0K Pj4+Pj4+Pj4+Pj53aXRoIGFjY29tbW9kYXRpbmcgaW50ZXJhY3Rpb24gb2YgdGhlIEJGRCB5YW5n IG1vZHVsZSB3aXRoDQo+Pj4+Pj4+Pj4+PmNsaWVudA0KPj4+Pj4+Pj4+Pj5wcm90b2NvbHMuDQo+ Pj4+Pj4+Pj4+PkZvcg0KPj4+Pj4+Pj4+Pj5leGFtcGxlLCB0aGUgSUdQcy4gIEluIHBhcnRpY3Vs YXIsIGhvdyBkbyB5b3UgY29uZmlndXJlIHRoZQ0KPj4+Pj4+Pj4+Pj5wcm9wZXJ0aWVzDQo+Pj4+ Pj4+Pj4+Pm9mIHRoZSBCRkQgc2Vzc2lvbnMgdGhhdCBtYXkgYmUgZHluYW1pY2FsbHkgaW5zdGFu dGlhdGVkIGJhc2VkDQo+Pj4+Pj4+Pj4+Pm9uDQo+Pj4+Pj4+Pj4+PmNvbnRyb2wgcHJvdG9jb2wg YWN0aXZpdHk/DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4tLSBKZWZmDQo+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj5PbiBGcmksIEp1biAzMCwgMjAxNyBhdCAxMjo1NTo1OVBNIC0wNzAwLA0KPj4+ Pj4+Pj4+Pj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+d3JvdGU6DQo+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUNCj4+Pj4+Pj4+Pj4+PkludGVybmV0LURyYWZ0cw0KPj4+Pj4+Pj4+ Pj4+ZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+Pj5EZXRlY3Rpb24NCj4+ Pj4+Pj4+Pj4+Pm9mIHRoZSBJRVRGLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBCaWRpcmVjdGlvbmFsDQo+ Pj4+Pj4+Pj4+Pj5Gb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+Pj5EZXRlY3Rpb24gKEJGRCkNCj4+Pj4+ Pj4+Pj4+PiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIExpYW5zaHUgWmhlbmcNCj4+Pj4+Pj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4+Pj4+Pj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFsbGFnYXR0aQ0KPj4+Pj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZyBNaXJza3kNCj4+Pj4+Pj4+Pj4+ PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+Pj4+ Pj4+PiAJUGFnZXMgICAgICAgICAgIDogNTkNCj4+Pj4+Pj4+Pj4+PiAJRGF0ZSAgICAgICAgICAg IDogMjAxNy0wNi0zMA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+ Pj4+Pj4+Pj4+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCB0aGF0 IGNhbiBiZSB1c2VkIHRvDQo+Pj4+Pj4+Pj4+Pj5jb25maWd1cmUNCj4+Pj4+Pj4+Pj4+PiAgICBh bmQgbWFuYWdlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+Pj4+ Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQteWFu Zy8NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZQ0KPj4+Pj4+Pj4+Pj4+b2YNCj4+Pj4+Pj4+Pj4+PnN1Ym1pc3Np b24gIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUNCj4+ Pj4+Pj4+Pj4+PmF0DQo+Pj4+Pj4+Pj4+Pj50b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+DQo+Pj4+DQo+Pj4NCj4+DQo+DQoNCg== From nobody Fri Jul 28 09:28:53 2017 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 EBEEF131CE3; Fri, 28 Jul 2017 09:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNv1AxB6784e; Fri, 28 Jul 2017 09:28:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053DA124217; Fri, 28 Jul 2017 09:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14526; q=dns/txt; s=iport; t=1501259328; x=1502468928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LLbQinjMJNjEz6lbRTtBLaoyL2Mp3UTzZGBVaxM5or4=; b=CheWwv1gpWQZQ3RBa5W0vhCEULLrc1QSDpiS/7g4AZdlv5stHPa5GYfp Xq6AhiNZ19QvYMS5IX3wIr1oS79h35c2tUy3KG5/jaDHApDCu1itGKcYO 4HE2IasaA1gu6rywohV8fleyeLQ7DM5SJaMG/P0yFROHm2mQGxLk+eRoM g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAQAbZXtZ/49dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbScHjgaPeoFrlgsOggQCKoUbAhqDWD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEDNEUMBAIBCBEEAQEBBCMFAgIwFAkIAgQBDQWKLxCSHpwyAYEpBoIoi?= =?us-ascii?q?z8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdMlOCI4NNhQiDJoEaARIBNoJ2gmcFl2C?= =?us-ascii?q?IDQKHTYxXggxXhHuKXolTjB4BHzh/C3cVH4VAHIFmAXaHQg0XB4EFAYENAQEB?= X-IronPort-AV: E=Sophos;i="5.40,425,1496102400"; d="scan'208";a="275867365" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2017 16:28:47 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6SGSlNb027047 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 16:28:47 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 11:28:47 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 11:28:47 -0500 From: "Reshad Rahman (rrahman)" To: Yingzhen Qu , "Acee Lindem (acee)" , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAOOAAP///DeAAAEH/JAAAjwBgA== Date: Fri, 28 Jul 2017 16:28:46 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B53867F@dfweml501-mbx> In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B53867F@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.212.44] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:28:52 -0000 VGhhbmtzIFlpbmd6aGVuLiBGWUkgSSB3aWxsIGJlIG9uIGhvbGlkYXkgZm9yIHRoZSBuZXh0IDIg d2Vla3MuDQoNCkFjZWUsIGNhbiB5b3UgcGxlYXNlIGdldCBpbiB0b3VjaCB3aXRoIElTSVMgWUFO RyBhdXRob3JzPw0KDQpSZWdhcmRzLA0KDQpSZXNoYWQuDQoNCk9uIDIwMTctMDctMjgsIDEyOjI1 IFBNLCAiWWluZ3poZW4gUXUiIDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPiB3cm90ZToNCg0KPkhp IFJlc2hhZCwNCj4NCj5UaGFua3MgZm9yIHRoZSB1cGRhdGUgYW5kIGV4YW1wbGUuIEknbGwgZ2V0 IG9zcGYgcGFydCBkb25lIHRoaXMgd2Vla2VuZC4NCj4NCj5UaGFua3MsDQo+WWluZ3poZW4gDQo+ DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkg W21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj5TZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcgODo1 NiBBTQ0KPlRvOiBSZXNoYWQgUmFobWFuIChycmFobWFuKSA8cnJhaG1hbkBjaXNjby5jb20+OyBZ aW5nemhlbiBRdQ0KPjx5aW5nemhlbi5xdUBodWF3ZWkuY29tPjsgSmVmZnJleSBIYWFzIDxqaGFh c0BwZnJjLm9yZz47IHJ0Zy1iZmRAaWV0Zi5vcmcNCj5DYzogZHJhZnQtaWV0Zi1iZmQteWFuZ0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4NCj5UaGFua3MgbXVjaCBSZXNo YWQgLSBZaW5nemhlbiB3aWxsIGJlIGFkZGluZyBidXQgdGhlIGlldGYtb3NwZi1iZmQgbW9kdWxl DQo+dG8gdGhlIE9TUEYgbW9kZWwgYW5kIGRyYWZ0Lg0KPg0KPkFjZWUgDQo+DQo+T24gNy8yOC8x NywgMTE6MDggQU0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29t PiB3cm90ZToNCj4NCj4+SGkgQWNlZSwNCj4+DQo+PkdvdCByaWQgb2YgaWV0Zi1iZmQtY2xpZW50 cy4gSSBoYXZlIGFkZGVkIGV4YW1wbGUtYmZkLWNsaWVudCBtb2R1bGUgdG8NCj4+cHJvdmlkZSBh biBleGFtcGxlLg0KPj4NCj4+UmVnYXJkcywNCj4+UmVzaGFkLg0KPj4NCj4+DQo+Pg0KPj5PbiAy MDE3LTA3LTI3LCAxMDozNCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29t PiB3cm90ZToNCj4+DQo+Pj5IaSBSZXNoYWQsDQo+Pj4NCj4+Pk9rIC0gSSBzZWUgbm93LiBJIHdh cyBsb29raW5nIGF0IHRoZSB3cm9uZyB4eHh4LWJhc2UtY2ZnLXBhcm1zDQo+Pj5ncm91cGluZ3Mu DQo+Pj5GZXdlciBzaW1pbGFyIGdyb3VwaW5nIGFuZCBtb2R1bGVzIHdpbGwgYmUgYmV0dGVyIDte KQ0KPj4+DQo+Pj5UaGFua3MsDQo+Pj5BY2VlDQo+Pj4NCj4+Pk9uIDcvMjcvMTcsIDk6MDMgUE0s ICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+d3JvdGU6 DQo+Pj4NCj4+Pj5IaSBBY2VlLA0KPj4+Pg0KPj4+PldoYXQgSSBzZWUgQA0KPj4+Pmh0dHBzOi8v Z2l0aHViLmNvbS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbmcv aWV0Zg0KPj4+Pi1iZg0KPj4+PmQNCj4+Pj4tDQo+Pj4+dA0KPj4+PnlwZXMueWFuZzoNCj4+Pj4x KSBiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIGhhcyBsZWFmIGVuYWJsZWQgb25seS4gQlRXIHRo aXMgZ3JvdXBpbmcNCj4+Pj5pcyBkZWZpbmVkIHR3aWNlLCB0aGlzIHdpbGwgYmUgZml4ZWQgd2hl biBJIGdldCByaWQgb2YNCj4+Pj5pZXRmLWJmZC1jbGllbnRzLnlhbmcNCj4+Pj4yKSBiZmQtZ3Jv dXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG11bHRpcGxpZXIvdGltZXJzLg0KPj4+Pg0KPj4+Pkxl dCBtZSBnZXQgcmlkIG9mIHRoZSBjbGllbnQgbW9kdWxlIGFuZCBoYXZlIGV2ZXJ5dGhpbmcgaW4g dGhlIHR5cGVzDQo+Pj4+bW9kdWxlLg0KPj4+Pg0KPj4+PkkgYW0gbm90IHN1cmUgd2h5IHlvdaGv cmUgbm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPj4+Pg0KPj4+PlJlZ2FyZHMsDQo+ Pj4+UmVzaGFkLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIDIwMTctMDctMjcsIDM6NDAgUE0s ICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+DQo+Pj4+ PkhpIFJlc2hhZCwNCj4+Pj4+DQo+Pj4+Pk9uIDcvMjcvMTcsIDM6MzUgUE0sICJSZXNoYWQgUmFo bWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+Pj53cm90ZToNCj4+Pj4+DQo+ Pj4+Pj5IaSBBY2VlLA0KPj4+Pj4+DQo+Pj4+Pj4xKSBJoa9sbCBzZWUgaWYgb3RoZXJzIGNoaW1l IGluIG9uIHRoaXMgYnV0IEkgYW0gZmluZSB3aXRoIGhhdmluZw0KPj4+Pj4+dGhlIGNsaWVudCBn cm91cGluZyBpbiBpZXRmLWJmZC10eXBlcy55YW5nLg0KPj4+Pj4+MikgYmZkLWdyb3VwaW5nLWNv bW1vbi1jZmctcGFybXMgaGFzIG11Y2ggbW9yZSB0aGFuIGp1c3QgdGhlDQo+Pj4+Pj5tdWx0aXBs aWVyL3RpbWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYw0K Pj4+Pj4+c3R1ZmYgKGRlbWFuZC1tb2RlLCBCRkQgYXV0aCkgd2hpY2ggSU1PIGhhcyBubyBidXNp bmVzcyBvdXRzaWRlIG9mDQo+Pj4+Pj5CRkQuDQo+Pj4+Pg0KPj4+Pj5BZ3JlZWQuIA0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pj5iZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG9ubHkgdGhlIG11 bHRpcGxpZXIvdGltZXJzLg0KPj4+Pj4NCj4+Pj4+UGVyaGFwcywgdGhlIGFkZGl0aW9uIG9mIG11 bHRpcGxpZXIvdGltZXJzIHRvDQo+Pj4+PmJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyBpc26h r3QgcHVzaGVkIHRvIEdpdEh1YiB5ZXQuIFRoaXMgdmVyc2lvbg0KPj4+Pj5odHRwczovL2dpdGh1 Yi5jb20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldA0K Pj4+Pj5mLWINCj4+Pj4+Zg0KPj4+Pj5kDQo+Pj4+Pi0NCj4+Pj4+dA0KPj4+Pj55cGVzLnlhbmcg b25seSBoYXMgdGhlIGVuYWJsZWQgbGVhZi4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj5UaGFua3MsDQo+ Pj4+PkFjZWUNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj5SZWdhcmRzLA0KPj4+Pj4+UmVz aGFkLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+T24gMjAxNy0wNy0yNywgMzozMCBQ TSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+Pg0K Pj4+Pj4+PkhpIFJlc2hhZCwNCj4+Pj4+Pj4NCj4+Pj4+Pj5PbiA3LzI3LzE3LCAzOjE5IFBNLCAi UmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj4+Pj53cm90 ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+SGkgQWNlZSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PldoZW4gd2Ug bWV0IHdlIGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiBBZnRlcndhcmRz DQo+Pj4+Pj4+PkkgZGVjaWRlZCB0byBjcmVhdGUgYSBuZXcgdHlwZXMgbW9kdWxlLCBhbmQgc3Rp bGwgd2VudCBhaGVhZCB3aXRoDQo+Pj4+Pj4+PnRoZSBjbGllbnRzIG1vZHVsZS4gSSBhbSBmaW5l IHdpdGggaGF2aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzDQo+Pj4+Pj4+Pm1vZHVsZSAobm8g Y2xpZW50IG1vZHVsZSkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+QWx0aG91Z2ggSSBkb26hr3QgZmVlbCB0 aGF0IHN0cm9uZ2x5IC0gSSBqdXN0IGRvbqGvdCBzZWUgdGhhdA0KPj4+Pj4+PnB1dHRpbmcgdGhl IGNsaWVudCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3ZpZGVzIGFueSBiZW5lZml0Lg0K Pj4+Pj4+PkFzIGZvciBkZXRyaW1lbnRzLCBpdCByZXF1aXJlcyBtb3JlIG9uZSBtb3JlIGxvY2Fs IG1vZHVsZXMgZm9yDQo+Pj4+Pj4+dmFsaWRhdGlvbiBhbmQgb25lIG1vcmUgbGV2ZWwgb2YgaW5k aXJlY3Rpb24gdG8gc2VlIHdoYXQgd2UgYXJlDQo+Pj4+Pj4+cmVhbGx5IGFsbG93aW5nIHRvIGJl IGNvbmZpZ3VyZWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5JIGFtIG5vdCBzdXJlIEkg ZnVsbHkgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQvcXVlc3Rpb24gb24NCj4+Pj4+Pj4+YmZkLWNs aWVudC1leHQtY2ZnLXBhcm1zL2JmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1zLiBUaGUgcmVh c29uDQo+Pj4+Pj4+PndlDQo+Pj4+Pj4+PmhhdmUNCj4+Pj4+Pj4+MiBncm91cGluZ3MgaXMgdGhh dCBzb21lIHByb3RvY29scyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUNCj4+Pj4+Pj4+ZW5h YmxlDQo+Pj4+Pj4+PmxlYWYNCj4+Pj4+Pj4+YW5kIG90aGVycyBtYXkgYWxzbyB3YW50IHRoZSBt dWx0aXBsaWVyL3RpbWVyLg0KPj4+Pj4+Pg0KPj4+Pj4+PlRoZSBiZmQtY2xpZW50LWV4dC1jZmct cGFybXMgZ3JvdXBpbmcgc2hvdWxkIHVzZQ0KPj4+Pj4+PmJmZC10eXBlczpiZmQtZ3JvdXBpbmct Y29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPj4+Pj4+PmJmZC10eXBlczpiZmQtY2xpZW50 LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMgd291bGQgYmUgbW9yZSBvYnZpb3VzDQo+Pj4+Pj4+ dy9vDQo+Pj4+Pj4+dGhlIGNsaWVudCBtb2R1bGUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+VGhhbmtzLA0K Pj4+Pj4+PkFjZWUgDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj5SZWdhcmRz LA0KPj4+Pj4+Pj5SZXNoYWQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pk9uIDIwMTctMDctMjcsIDM6MDcgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2Nv LmNvbT4NCj4+Pj4+Pj4+d3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+SGkgUmVzaGFkLA0KPj4+ Pj4+Pj4+V2h5IGRvIHdlIG5lZWQgYSBuZXcgWUFORyBtb2RlbCBmb3IgY2xpZW50cz8gV2h5IGNh bqGvdCB0aGV5IGp1c3QNCj4+Pj4+Pj4+PnVzZQ0KPj4+Pj4+Pj4+aWV0Zi1iZmQtdHlwZXMueWFu Zz8gSaGvZCBsaWtlIHRvIGF2b2lkIHRoZSB1bm5lY2Vzc2FyeSBsZXZlbHMgb2YNCj4+Pj4+Pj4+ PmluZGlyZWN0aW9uLiBJbiBmYWN0LCBpdCBsb29rcyB3cm9uZyB0byBtZSBzaW5jZSB0aGUgZ3Jv dXBpbmcNCj4+Pj4+Pj4+PmJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBncm91cGlu Zw0KPj4+Pj4+Pj4+YmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zDQo+Pj4+Pj4+Pj53aGljaCBv bmx5IGNvbnRhaW5zIHRoZSBlbmFibGVkIGxlYWYuIEkgYmVsaWV2ZSB5b3UgbWVhbnQgdG8gdXNl DQo+Pj4+Pj4+Pj5iZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyBpbiB0aGUgb3RoZXIgbmV3 IG1vZGVsLiBIb3dldmVyLCBJDQo+Pj4+Pj4+Pj5kb26hr3QNCj4+Pj4+Pj4+PnNlZQ0KPj4+Pj4+ Pj4+YW55IHJlYXNvbiB3aHkgY2xpZW50IHNob3VsZG6hr3QgdXNlIHRoaXMgZGlyZWN0bHkuDQo+ Pj4+Pj4+Pj5UaGFua3MsDQo+Pj4+Pj4+Pj5BY2VlIA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj5PbiA3 LzI1LzE3LCAyOjMzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2Nv LmNvbT4NCj4+Pj4+Pj4+Pndyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+SGkgWWluZ3poZW4s DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+VGhlIGdyb3VwaW5nIGlzIGF2YWlsYWJsZSBADQo+Pj4+ Pj4+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21h c3Rlci9zcmMveWFuZy8NCj4+Pj4+Pj4+Pj5pDQo+Pj4+Pj4+Pj4+ZQ0KPj4+Pj4+Pj4+PnQNCj4+ Pj4+Pj4+Pj5mDQo+Pj4+Pj4+Pj4+LQ0KPj4+Pj4+Pj4+PmINCj4+Pj4+Pj4+Pj5mDQo+Pj4+Pj4+ Pj4+ZA0KPj4+Pj4+Pj4+Pi0NCj4+Pj4+Pj4+Pj5jDQo+Pj4+Pj4+Pj4+bGllbnRzLnlhbmcNCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5JZiB5b3Wp9mQgbGlrZSBjaGFuZ2VzIHRvIHRoZSBncm91cGlu Zywgc2VuZCBtZSBhbiBlbWFpbC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5SZWdhcmRzLA0KPj4+ Pj4+Pj4+PlJlc2hhZC4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj5PbiAyMDE3LTA3LTIxLCAxMjoy MiBQTSwgIllpbmd6aGVuIFF1IiA8eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4NCj4+Pj4+Pj4+Pj53 cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+SGkgUmVzaGFkLA0KPj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PkJvdGggb3NwZiBhbmQgaXNpcyBtb2RlbHMgd2lsbCBtYWtlIGNvcnJlc3BvbmRpbmcgY2hhbmdl cyB3aGVuDQo+Pj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+Pj5uZXcNCj4+Pj4+Pj4+Pj4+QkZEIGdy b3VwaW5nIGlzIGF2YWlsYWJsZS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PlRoYW5rcywNCj4+ Pj4+Pj4+Pj4+WWluZ3poZW4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+PkZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFtt YWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+PlNlbnQ6IFRodXJzZGF5LCBKdWx5 IDIwLCAyMDE3IDc6MTkgQU0NCj4+Pj4+Pj4+Pj4+VG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZy Yy5vcmc+OyBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PkNjOiBkcmFmdC1pZXRmLWJmZC15 YW5nQGlldGYub3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj5T dWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PldlIChCRkQgYW5kIE9TUEYgWUFORyBhdXRob3JzKSBoYWQgYSBk aXNjdXNzaW9uIHllc3RlcmRheS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PlRoZSBhZ3JlZW1l bnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJlZCwgd2UNCj4+Pj4+ Pj4+Pj4+d2FudA0KPj4+Pj4+Pj4+Pj50bw0KPj4+Pj4+Pj4+Pj5hZGQNCj4+Pj4+Pj4+Pj4+YmFj ayB0aGUgYmFzaWMgQkZEIGNvbmZpZyAobXVsdGlwbGllciArIGludGVydmFscykgaW4gSUdQIHZp YSBhDQo+Pj4+Pj4+Pj4+Pmdyb3VwaW5nLg0KPj4+Pj4+Pj4+Pj5CRkQgd2lsbCBwcm92aWRlIHRo YXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4gSUdQDQo+Pj4+Pj4+Pj4+PkJG RA0KPj4+Pj4+Pj4+Pj5ZQU5HDQo+Pj4+Pj4+Pj4+PndpbGwgYmUgaW4gYSBzZXBhcmF0ZSBtb2R1 bGUgKHNlcGFyYXRlIGZyb20gdGhlIG1haW4gSUdQDQo+Pj4+Pj4+Pj4+Pm1vZHVsZSkuDQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+UmVnYXJkcywNCj4+Pj4+Pj4+Pj4+UmVz aGFkLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+T24gMjAxNy0wNy0wNSwgMTI6MjEgUE0sICJS dGctYmZkIG9uIGJlaGFsZiBvZiBKZWZmcmV5IEhhYXMiDQo+Pj4+Pj4+Pj4+PjxydGctYmZkLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMub3JnPiB3cm90ZToNCj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj5UaGFua3MgYXV0aG9ycyBmb3IgdGhlIGVkaXRzIG9uIHRoZSBC RkQgeWFuZyBtb2R1bGUuICBUaGlzIGdldHMNCj4+Pj4+Pj4+Pj4+PnVzDQo+Pj4+Pj4+Pj4+Pj5h DQo+Pj4+Pj4+Pj4+Pj5zaWduaWZpY2FudCBzdGVwIGNsb3NlciB0byBhbGlnbm1lbnQgd2l0aCB0 aGUgcmVzdCBvZiBJRVRGIGZvcg0KPj4+Pj4+Pj4+Pj4+bmV0d29yaw0KPj4+Pj4+Pj4+Pj4+aW5z dGFuY2luZy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+SSdkIGxpa2UgdG8gZW5jb3VyYWdl IHRoZSB3b3JraW5nIGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sgb24NCj4+Pj4+Pj4+Pj4+PnRo aXMNCj4+Pj4+Pj4+Pj4+Pmlzc3VlIGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUu DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PkFzIG5vdGVkIGluIGFub3RoZXIgdGhyZWFkLCB3 ZSBzdGlsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgaG93IHRvDQo+Pj4+Pj4+Pj4+Pj5kZWFsDQo+Pj4+ Pj4+Pj4+Pj53aXRoIGFjY29tbW9kYXRpbmcgaW50ZXJhY3Rpb24gb2YgdGhlIEJGRCB5YW5nIG1v ZHVsZSB3aXRoDQo+Pj4+Pj4+Pj4+Pj5jbGllbnQNCj4+Pj4+Pj4+Pj4+PnByb3RvY29scy4NCj4+ Pj4+Pj4+Pj4+PkZvcg0KPj4+Pj4+Pj4+Pj4+ZXhhbXBsZSwgdGhlIElHUHMuICBJbiBwYXJ0aWN1 bGFyLCBob3cgZG8geW91IGNvbmZpZ3VyZSB0aGUNCj4+Pj4+Pj4+Pj4+PnByb3BlcnRpZXMNCj4+ Pj4+Pj4+Pj4+Pm9mIHRoZSBCRkQgc2Vzc2lvbnMgdGhhdCBtYXkgYmUgZHluYW1pY2FsbHkgaW5z dGFudGlhdGVkIGJhc2VkDQo+Pj4+Pj4+Pj4+Pj5vbg0KPj4+Pj4+Pj4+Pj4+Y29udHJvbCBwcm90 b2NvbCBhY3Rpdml0eT8NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+LS0gSmVmZg0KPj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj5PbiBGcmksIEp1biAzMCwgMjAxNyBhdCAxMjo1NTo1OVBNIC0w NzAwLA0KPj4+Pj4+Pj4+Pj4+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj53 cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+Pj4+Pj4+Pj4+Pj4+SW50ZXJuZXQtRHJh ZnRzDQo+Pj4+Pj4+Pj4+Pj4+ZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+Pj4+Pj4+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+Pj4+Pj4+ Pj4+PkRldGVjdGlvbg0KPj4+Pj4+Pj4+Pj4+Pm9mIHRoZSBJRVRGLg0KPj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwg Zm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Pj4+Pj4+Pj5Gb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+Pj4+ RGV0ZWN0aW9uIChCRkQpDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDog UmVzaGFkIFJhaG1hbg0KPj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIExp YW5zaHUgWmhlbmcNCj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNYWhl c2ggSmV0aGFuYW5kYW5pDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg U2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZyBNaXJza3kNCj4+Pj4+Pj4+Pj4+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtYmZkLXlhbmctMDYudHh0DQo+Pj4+Pj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA1OQ0K Pj4+Pj4+Pj4+Pj4+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNi0zMA0KPj4+Pj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4+Pj4+ICAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCB0aGF0IGNhbiBiZSB1c2VkDQo+Pj4+Pj4+Pj4+ Pj4+dG8NCj4+Pj4+Pj4+Pj4+Pj5jb25maWd1cmUNCj4+Pj4+Pj4+Pj4+Pj4gICAgYW5kIG1hbmFn ZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpLg0KPj4+Pj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+Pj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1iZmQteWFuZy8N Cj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlDQo+Pj4+Pj4+Pj4+Pj4+dGltZQ0KPj4+Pj4+Pj4+Pj4+Pm9m DQo+Pj4+Pj4+Pj4+Pj4+c3VibWlzc2lvbiAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZQ0KPj4+Pj4+Pj4+Pj4+PmF0DQo+Pj4+Pj4+Pj4+Pj4+dG9vbHMu aWV0Zi5vcmcuDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4+Pj4+IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4NCj4+Pj4NCj4+ Pg0KPj4NCj4NCg0K From nobody Fri Jul 28 09:30:59 2017 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 EBE52131CE3; Fri, 28 Jul 2017 09:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 Pxg1IV8Zp--t; Fri, 28 Jul 2017 09:30:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63584124217; Fri, 28 Jul 2017 09:30:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLM24275; Fri, 28 Jul 2017 16:30:52 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Jul 2017 17:30:52 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Fri, 28 Jul 2017 09:30:48 -0700 From: Yingzhen Qu To: "Reshad Rahman (rrahman)" , "Acee Lindem (acee)" , Jeffrey Haas , "rtg-bfd@ietf.org" CC: "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAOOAAP///DeAAAEH/JAAAjwBgAACE8iw Date: Fri, 28 Jul 2017 16:30:46 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B5386A0@dfweml501-mbx> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B53867F@dfweml501-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.597B66BD.001E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f51b081ef726120ca0b85531009b970e Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 16:30:58 -0000 Hi Reshad, I'll also take care of the ISIS part.=20 Enjoy your vocation! Thanks, Yingzhen -----Original Message----- From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com]=20 Sent: Friday, July 28, 2017 9:29 AM To: Yingzhen Qu ; Acee Lindem (acee) ; Jeffrey Haas ; rtg-bfd@ietf.org Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thanks Yingzhen. FYI I will be on holiday for the next 2 weeks. Acee, can you please get in touch with ISIS YANG authors? Regards, Reshad. On 2017-07-28, 12:25 PM, "Yingzhen Qu" wrote: >Hi Reshad, > >Thanks for the update and example. I'll get ospf part done this weekend. > >Thanks, >Yingzhen > >-----Original Message----- >From: Acee Lindem (acee) [mailto:acee@cisco.com] >Sent: Friday, July 28, 2017 8:56 AM >To: Reshad Rahman (rrahman) ; Yingzhen Qu=20 >; Jeffrey Haas ;=20 >rtg-bfd@ietf.org >Cc: draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org >Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt > >Thanks much Reshad - Yingzhen will be adding but the ietf-ospf-bfd=20 >module to the OSPF model and draft. > >Acee > >On 7/28/17, 11:08 AM, "Reshad Rahman (rrahman)" wrote: > >>Hi Acee, >> >>Got rid of ietf-bfd-clients. I have added example-bfd-client module to=20 >>provide an example. >> >>Regards, >>Reshad. >> >> >> >>On 2017-07-27, 10:34 PM, "Acee Lindem (acee)" wrote: >> >>>Hi Reshad, >>> >>>Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms=20 >>>groupings. >>>Fewer similar grouping and modules will be better ;^) >>> >>>Thanks, >>>Acee >>> >>>On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" >>>wrote: >>> >>>>Hi Acee, >>>> >>>>What I see @ >>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet >>>>f >>>>-bf >>>>d >>>>- >>>>t >>>>ypes.yang: >>>>1) bfd-client-base-cfg-parms has leaf enabled only. BTW this=20 >>>>grouping is defined twice, this will be fixed when I get rid of=20 >>>>ietf-bfd-clients.yang >>>>2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>> >>>>Let me get rid of the client module and have everything in the types=20 >>>>module. >>>> >>>>I am not sure why you're not seeing something different. >>>> >>>>Regards, >>>>Reshad. >>>> >>>> >>>> >>>>On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" wrote: >>>> >>>>>Hi Reshad, >>>>> >>>>>On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" >>>>>wrote: >>>>> >>>>>>Hi Acee, >>>>>> >>>>>>1) I'll see if others chime in on this but I am fine with having=20 >>>>>>the client grouping in ietf-bfd-types.yang. >>>>>>2) bfd-grouping-common-cfg-parms has much more than just the=20 >>>>>>multiplier/timers that the IGPs need. It also has BFD specific=20 >>>>>>stuff (demand-mode, BFD auth) which IMO has no business outside of=20 >>>>>>BFD. >>>>> >>>>>Agreed.=20 >>>>> >>>>> >>>>>>bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>> >>>>>Perhaps, the addition of multiplier/timers to=20 >>>>>bfd-grouping-base-cfg-parms isn't pushed to GitHub yet. This=20 >>>>>version=20 >>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ie >>>>>t >>>>>f-b >>>>>f >>>>>d >>>>>- >>>>>t >>>>>ypes.yang only has the enabled leaf. >>>>> >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>>> >>>>>>Regards, >>>>>>Reshad. >>>>>> >>>>>> >>>>>> >>>>>>On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" wrote: >>>>>> >>>>>>>Hi Reshad, >>>>>>> >>>>>>>On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)"=20 >>>>>>> >>>>>>>wrote: >>>>>>> >>>>>>>>Hi Acee, >>>>>>>> >>>>>>>>When we met we agreed to have a new model for clients.=20 >>>>>>>>Afterwards I decided to create a new types module, and still=20 >>>>>>>>went ahead with the clients module. I am fine with having=20 >>>>>>>>everything in the types module (no client module). >>>>>>> >>>>>>>Although I don't feel that strongly - I just don't see that=20 >>>>>>>putting the client config params in wrappers provides any benefit. >>>>>>>As for detriments, it requires more one more local modules for=20 >>>>>>>validation and one more level of indirection to see what we are=20 >>>>>>>really allowing to be configured. >>>>>>> >>>>>>>> >>>>>>>>I am not sure I fully understand your comment/question on=20 >>>>>>>>bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The=20 >>>>>>>>reason we have >>>>>>>>2 groupings is that some protocols may decide to have just the=20 >>>>>>>>enable leaf and others may also want the multiplier/timer. >>>>>>> >>>>>>>The bfd-client-ext-cfg-parms grouping should use=20 >>>>>>>bfd-types:bfd-grouping-common-cfg-parms rather than=20 >>>>>>>bfd-types:bfd-client-base-cfg-parms - no? This would be more=20 >>>>>>>obvious w/o the client module. >>>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>Regards, >>>>>>>>Reshad. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" >>>>>>>>wrote: >>>>>>>> >>>>>>>>>Hi Reshad, >>>>>>>>>Why do we need a new YANG model for clients? Why can't they=20 >>>>>>>>>just use ietf-bfd-types.yang? I'd like to avoid the unnecessary=20 >>>>>>>>>levels of indirection. In fact, it looks wrong to me since the=20 >>>>>>>>>grouping bfd-client-ext-cfg-parms uses the grouping=20 >>>>>>>>>bfd-grouping-base-cfg-parms >>>>>>>>>which only contains the enabled leaf. I believe you meant to=20 >>>>>>>>>use bfd-grouping-common-cfg-parms in the other new model.=20 >>>>>>>>>However, I don't see any reason why client shouldn't use this=20 >>>>>>>>>directly. >>>>>>>>>Thanks, >>>>>>>>>Acee >>>>>>>>> >>>>>>>>>On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)"=20 >>>>>>>>> >>>>>>>>>wrote: >>>>>>>>> >>>>>>>>>>Hi Yingzhen, >>>>>>>>>> >>>>>>>>>>The grouping is available @ >>>>>>>>>>https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/ya >>>>>>>>>>ng/ >>>>>>>>>>i >>>>>>>>>>e >>>>>>>>>>t >>>>>>>>>>f >>>>>>>>>>- >>>>>>>>>>b >>>>>>>>>>f >>>>>>>>>>d >>>>>>>>>>- >>>>>>>>>>c >>>>>>>>>>lients.yang >>>>>>>>>> >>>>>>>>>>If you=B9d like changes to the grouping, send me an email. >>>>>>>>>> >>>>>>>>>>Regards, >>>>>>>>>>Reshad. >>>>>>>>>> >>>>>>>>>>On 2017-07-21, 12:22 PM, "Yingzhen Qu"=20 >>>>>>>>>> >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>>>Hi Reshad, >>>>>>>>>>> >>>>>>>>>>>Thanks for the summary. >>>>>>>>>>> >>>>>>>>>>>Both ospf and isis models will make corresponding changes=20 >>>>>>>>>>>when the new BFD grouping is available. >>>>>>>>>>> >>>>>>>>>>>Thanks, >>>>>>>>>>>Yingzhen >>>>>>>>>>> >>>>>>>>>>>-----Original Message----- >>>>>>>>>>>From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>>>Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>>>To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>>>Cc: draft-ietf-bfd-yang@ietf.org;=20 >>>>>>>>>>>draft-ietf-ospf-yang@ietf.org >>>>>>>>>>>Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>> >>>>>>>>>>>We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>> >>>>>>>>>>>The agreement is that since IGP peers are auto-discovered, we=20 >>>>>>>>>>>want to add back the basic BFD config (multiplier +=20 >>>>>>>>>>>intervals) in IGP via a grouping. >>>>>>>>>>>BFD will provide that grouping in a specific YANG module. IGP=20 >>>>>>>>>>>BFD YANG will be in a separate module (separate from the main=20 >>>>>>>>>>>IGP module). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Regards, >>>>>>>>>>>Reshad. >>>>>>>>>>> >>>>>>>>>>>On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>Thanks authors for the edits on the BFD yang module. This=20 >>>>>>>>>>>>gets us a significant step closer to alignment with the rest=20 >>>>>>>>>>>>of IETF for network instancing. >>>>>>>>>>>> >>>>>>>>>>>>I'd like to encourage the working group to provide feedback=20 >>>>>>>>>>>>on this issue and also the changes in the module. >>>>>>>>>>>> >>>>>>>>>>>>As noted in another thread, we still have to figure out how=20 >>>>>>>>>>>>to deal with accommodating interaction of the BFD yang=20 >>>>>>>>>>>>module with client protocols. >>>>>>>>>>>>For >>>>>>>>>>>>example, the IGPs. In particular, how do you configure the=20 >>>>>>>>>>>>properties of the BFD sessions that may be dynamically=20 >>>>>>>>>>>>instantiated based on control protocol activity? >>>>>>>>>>>> >>>>>>>>>>>>-- Jeff >>>>>>>>>>>> >>>>>>>>>>>>On Fri, Jun 30, 2017 at 12:55:59PM -0700,=20 >>>>>>>>>>>>internet-drafts@ietf.org >>>>>>>>>>>>wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>>>>>>>Internet-Drafts directories. >>>>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding=20 >>>>>>>>>>>>>Detection of the IETF. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>>>Forwarding >>>>>>>>>>>>>Detection (BFD) >>>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>> Pages : 59 >>>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> This document defines a YANG data model that can be=20 >>>>>>>>>>>>>used to configure >>>>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang- >>>>>>>>>>>>> 06 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please note that it may take a couple of minutes from the=20 >>>>>>>>>>>>>time of submission until the htmlized version and diff are=20 >>>>>>>>>>>>>available at tools.ietf.org. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From nobody Fri Jul 28 14:25:23 2017 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 12ED7132199; Fri, 28 Jul 2017 14:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 0rcfZsGsaqi4; Fri, 28 Jul 2017 14:25:16 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 2CB3D132198; Fri, 28 Jul 2017 14:25:16 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id v11so19793560oif.1; Fri, 28 Jul 2017 14:25:16 -0700 (PDT) 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=lPTKFQyjFllgi8vsTVSE66saVjm8zEGN3XR46qLx5cA=; b=utWezermkKUEQicEpDM0AFSvakuxISBrcclfr/Qp8IyAr5jG2ImAqen4EKRX2XbyHe YSyUvK2zEYpCuZG3lEbDhvCQcdqROp7hr/U7M2eot4TzcLPj2lFzd9GicX81P8rD6mCG fnL3R39xkfCXdenFTYg+/ANmdGk3vW3SiDe3LgfeBVoE5RymGYR6geNjj6ePgpxD7Y8N KC6fy0hCsuRiFesFgL2hauU9OnbaEtHbnPsUnlgKn+4SvzrGf5m/6sMlCaOWenBGnhyn vcEGIzXGNrsRle/QB8Bc7QSqadb0lWlMKDphdU69r5Zs+kKCPlpileYJPrMx0o+mqtew M48g== 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=lPTKFQyjFllgi8vsTVSE66saVjm8zEGN3XR46qLx5cA=; b=OANybS/iRpegnZ0KN9Jvd0aZMgQh5TXbHLDtZOEibTkiJutbCEve7ANVwW4/Bs3AOv xrNDAmAjxruaYfkE/nt0EA5wK6zYgf8wrqUAspbomcVeTV2yPImoGHrvCPWxfrIpekAY vK4LPeAcHdh6I9uu2ihziSHghC0lPlB4PT0I4xMT3R0/mKJENE8iYAdMvyFXFuVSgQ+7 eeNNBjGZIG8UVZxV+8BDKACnBAADJ5XHxwbbpxnlxCJ4ouabDI70hSRQyEsOGkdBhYfs U4ijsWL431U+ZuoFvwoxoXaR4zRWMc7Wk393R/VultvdOv6XYmKvcPLAaGntQ2JCEcoq SBhw== X-Gm-Message-State: AIVw113JVTjv/55CIe0x6kChlEuu8LfylyKd13wERHccN2K34ZBFbGki 57TLYyJUNyBQWg== X-Received: by 10.202.77.3 with SMTP id a3mr8512074oib.64.1501277115431; Fri, 28 Jul 2017 14:25:15 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:1142:f772:6d85:788d? ([2001:420:30d:1320:1142:f772:6d85:788d]) by smtp.gmail.com with ESMTPSA id h67sm20473669oic.43.2017.07.28.14.25.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Jul 2017 14:25:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: Date: Fri, 28 Jul 2017 14:25:27 -0700 Cc: Reshad Rahman , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 21:25:19 -0000 Would it not be better to call bfd-grouping-base-cfg-parms something = like bfd-grouping-client-cfg-params or more simply client-cfg-params. We = know it is a grouping and we know it is a bfd grouping. Why repeat? > On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) = wrote: >=20 > Hi Reshad,=20 >=20 > Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms = groupings. > Fewer similar grouping and modules will be better ;^) >=20 > Thanks, > Acee >=20 > On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" = wrote: >=20 >> Hi Acee, >>=20 >> What I see @=20 >> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd-= >> t >> ypes.yang: >> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this grouping = is >> defined twice, this will be fixed when I get rid of = ietf-bfd-clients.yang >> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>=20 >> Let me get rid of the client module and have everything in the types >> module. >>=20 >> I am not sure why you=E2=80=99re not seeing something different. >>=20 >> Regards, >> Reshad. >>=20 >>=20 >>=20 >> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" wrote: >>=20 >>> Hi Reshad,=20 >>>=20 >>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" = wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> 1) I=E2=80=99ll see if others chime in on this but I am fine with = having the >>>> client grouping in ietf-bfd-types.yang. >>>> 2) bfd-grouping-common-cfg-parms has much more than just the >>>> multiplier/timers that the IGPs need. It also has BFD specific = stuff >>>> (demand-mode, BFD auth) which IMO has no business outside of BFD. >>>=20 >>> Agreed.=20 >>>=20 >>>=20 >>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>=20 >>> Perhaps, the addition of multiplier/timers to = bfd-grouping-base-cfg-parms >>> isn=E2=80=99t pushed to GitHub yet. This version >>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bfd >>> - >>> t >>> ypes.yang only has the enabled leaf. >>>=20 >>>=20 >>> Thanks, >>> Acee=20 >>>=20 >>>=20 >>>>=20 >>>> Regards, >>>> Reshad. >>>>=20 >>>>=20 >>>>=20 >>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" = wrote: >>>>=20 >>>>> Hi Reshad,=20 >>>>>=20 >>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" >>>>> wrote: >>>>>=20 >>>>>> Hi Acee, >>>>>>=20 >>>>>> When we met we agreed to have a new model for clients. Afterwards = I >>>>>> decided to create a new types module, and still went ahead with = the >>>>>> clients module. I am fine with having everything in the types = module >>>>>> (no >>>>>> client module). >>>>>=20 >>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99t = see that putting the >>>>> client config params in wrappers provides any benefit. As for >>>>> detriments, >>>>> it requires more one more local modules for validation and one = more >>>>> level >>>>> of indirection to see what we are really allowing to be = configured. >>>>>=20 >>>>>>=20 >>>>>> I am not sure I fully understand your comment/question on >>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The = reason we >>>>>> have >>>>>> 2 groupings is that some protocols may decide to have just the = enable >>>>>> leaf >>>>>> and others may also want the multiplier/timer. >>>>>=20 >>>>> The bfd-client-ext-cfg-parms grouping should use >>>>> bfd-types:bfd-grouping-common-cfg-parms rather than >>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more = obvious >>>>> w/o >>>>> the client module. >>>>>=20 >>>>> Thanks, >>>>> Acee=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Reshad. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" = wrote: >>>>>>=20 >>>>>>> Hi Reshad,=20 >>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t = they just use >>>>>>> ietf-bfd-types.yang? I=E2=80=99d like to avoid the unnecessary = levels of >>>>>>> indirection. In fact, it looks wrong to me since the grouping >>>>>>> bfd-client-ext-cfg-parms uses the grouping >>>>>>> bfd-grouping-base-cfg-parms >>>>>>> which only contains the enabled leaf. I believe you meant to use >>>>>>> bfd-grouping-common-cfg-parms in the other new model. However, I >>>>>>> don=E2=80=99t >>>>>>> see >>>>>>> any reason why client shouldn=E2=80=99t use this directly. >>>>>>> Thanks, >>>>>>> Acee=20 >>>>>>>=20 >>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" = >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Yingzhen, >>>>>>>>=20 >>>>>>>> The grouping is available @ >>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet >>>>>>>> f >>>>>>>> - >>>>>>>> b >>>>>>>> f >>>>>>>> d >>>>>>>> - >>>>>>>> c >>>>>>>> lients.yang >>>>>>>>=20 >>>>>>>> If you=C2=B9d like changes to the grouping, send me an email. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Reshad. >>>>>>>>=20 >>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Reshad, >>>>>>>>>=20 >>>>>>>>> Thanks for the summary. >>>>>>>>>=20 >>>>>>>>> Both ospf and isis models will make corresponding changes when = the >>>>>>>>> new >>>>>>>>> BFD grouping is available. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Yingzhen >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org; = draft-ietf-ospf-yang@ietf.org >>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>=20 >>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>=20 >>>>>>>>> The agreement is that since IGP peers are auto-discovered, we = want >>>>>>>>> to >>>>>>>>> add >>>>>>>>> back the basic BFD config (multiplier + intervals) in IGP via = a >>>>>>>>> grouping. >>>>>>>>> BFD will provide that grouping in a specific YANG module. IGP = BFD >>>>>>>>> YANG >>>>>>>>> will be in a separate module (separate from the main IGP = module). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Reshad. >>>>>>>>>=20 >>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Thanks authors for the edits on the BFD yang module. This = gets us >>>>>>>>>> a >>>>>>>>>> significant step closer to alignment with the rest of IETF = for >>>>>>>>>> network >>>>>>>>>> instancing. >>>>>>>>>>=20 >>>>>>>>>> I'd like to encourage the working group to provide feedback = on >>>>>>>>>> this >>>>>>>>>> issue and also the changes in the module. >>>>>>>>>>=20 >>>>>>>>>> As noted in another thread, we still have to figure out how = to >>>>>>>>>> deal >>>>>>>>>> with accommodating interaction of the BFD yang module with = client >>>>>>>>>> protocols. >>>>>>>>>> For >>>>>>>>>> example, the IGPs. In particular, how do you configure the >>>>>>>>>> properties >>>>>>>>>> of the BFD sessions that may be dynamically instantiated = based on >>>>>>>>>> control protocol activity? >>>>>>>>>>=20 >>>>>>>>>> -- Jeff >>>>>>>>>>=20 >>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700, = internet-drafts@ietf.org >>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>> Internet-Drafts >>>>>>>>>>> directories. >>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding >>>>>>>>>>> Detection >>>>>>>>>>> of the IETF. >>>>>>>>>>>=20 >>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>> Forwarding >>>>>>>>>>> Detection (BFD) >>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>> Lianshu Zheng >>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>> Greg Mirsky >>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>> Pages : 59 >>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>=20 >>>>>>>>>>> Abstract: >>>>>>>>>>> This document defines a YANG data model that can be used = to >>>>>>>>>>> configure >>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>=20 >>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>=20 >>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Please note that it may take a couple of minutes from the = time >>>>>>>>>>> of >>>>>>>>>>> submission until the htmlized version and diff are = available at >>>>>>>>>>> tools.ietf.org. >>>>>>>>>>>=20 >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Jul 28 14:42:29 2017 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 13CBD131537; Fri, 28 Jul 2017 14:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywhCOtTacoxb; Fri, 28 Jul 2017 14:42:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07FD1321A2; Fri, 28 Jul 2017 14:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13536; q=dns/txt; s=iport; t=1501278144; x=1502487744; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FjMUI1KslMQ29AvYOpSArlkBnwGj27SgOig1FJOTAXc=; b=Ig7fxiFpjKrA0XfmB1Z2B7ck90sDhojZBBFXzCCXTvnyy/f0tiFPaohq xdF5GPFyUpvvqwmIv5op3/rWAkByA8gBSOjp1IaF+qcRgNSnfK/wQKj5J Ys15X44fNkFqdoo+y4EFjJqu91Mq8l+RDzaCF/+BRCH4qW9MHcB0X7zVR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAAAtr3tZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgaPeYFriDGNWg6CBC6FGQIag1o/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAzRFDAQCAQgOAwQBAQEEIwUCAh8RFAkIAgQBDQWKFwMVEJF0nVwGg?= =?us-ascii?q?iiHLg2EBAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BBYIjg02FCIJXT4EaARIBHxe?= =?us-ascii?q?CdoJnBZ8xPAKHTYdmhHGCDFeEe4pejBuJVgEfOH8LdxUfhUAcgWYBdodCDRcHg?= =?us-ascii?q?QWBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.40,427,1496102400"; d="scan'208";a="57980801" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jul 2017 21:42:23 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v6SLgNgH007146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jul 2017 21:42:23 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Jul 2017 16:42:22 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1210.000; Fri, 28 Jul 2017 16:42:22 -0500 From: "Reshad Rahman (rrahman)" To: Mahesh Jethanandani , "Acee Lindem (acee)" CC: Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAY+3gP//wcOA Date: Fri, 28 Jul 2017 21:42:22 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.255.171] Content-Type: text/plain; charset="euc-kr" Content-ID: <515A4267771A6E4D94CFEA0EA82BA9B8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 21:42:28 -0000 SSBhbSBmaW5lIHdpdGggdGhpcyBwcm9wb3NhbC4gSXQgd2lsbCBpbXBhY3Qgb3RoZXIgZ3JvdXBp bmdzIGFsc28uDQoNCg0KDQpPbiAyMDE3LTA3LTI4LCA1OjI1IFBNLCAiTWFoZXNoIEpldGhhbmFu ZGFuaSIgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0Kd3JvdGU6DQoNCj5Xb3VsZCBpdCBub3Qg YmUgYmV0dGVyIHRvIGNhbGwgYmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zIHNvbWV0aGluZyBs aWtlDQo+YmZkLWdyb3VwaW5nLWNsaWVudC1jZmctcGFyYW1zIG9yIG1vcmUgc2ltcGx5IGNsaWVu dC1jZmctcGFyYW1zLiBXZSBrbm93DQo+aXQgaXMgYSBncm91cGluZyBhbmQgd2Uga25vdyBpdCBp cyBhIGJmZCBncm91cGluZy4gV2h5IHJlcGVhdD8NCj4NCj4+IE9uIEp1bCAyNywgMjAxNywgYXQg NzozNCBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiAN Cj4+IEhpIFJlc2hhZCwgDQo+PiANCj4+IE9rIC0gSSBzZWUgbm93LiBJIHdhcyBsb29raW5nIGF0 IHRoZSB3cm9uZyB4eHh4LWJhc2UtY2ZnLXBhcm1zDQo+Pmdyb3VwaW5ncy4NCj4+IEZld2VyIHNp bWlsYXIgZ3JvdXBpbmcgYW5kIG1vZHVsZXMgd2lsbCBiZSBiZXR0ZXIgO14pDQo+PiANCj4+IFRo YW5rcywNCj4+IEFjZWUNCj4+IA0KPj4gT24gNy8yNy8xNywgOTowMyBQTSwgIlJlc2hhZCBSYWht YW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pndyb3RlOg0KPj4gDQo+Pj4gSGkg QWNlZSwNCj4+PiANCj4+PiBXaGF0IEkgc2VlIEAgDQo+Pj4gDQo+Pj5odHRwczovL2dpdGh1Yi5j b20vamhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldGYtYmYN Cj4+PmQtDQo+Pj4gdA0KPj4+IHlwZXMueWFuZzoNCj4+PiAxKSBiZmQtY2xpZW50LWJhc2UtY2Zn LXBhcm1zIGhhcyBsZWFmIGVuYWJsZWQgb25seS4gQlRXIHRoaXMgZ3JvdXBpbmcNCj4+PmlzDQo+ Pj4gZGVmaW5lZCB0d2ljZSwgdGhpcyB3aWxsIGJlIGZpeGVkIHdoZW4gSSBnZXQgcmlkIG9mDQo+ Pj5pZXRmLWJmZC1jbGllbnRzLnlhbmcNCj4+PiAyKSBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFy bXMgaGFzIG11bHRpcGxpZXIvdGltZXJzLg0KPj4+IA0KPj4+IExldCBtZSBnZXQgcmlkIG9mIHRo ZSBjbGllbnQgbW9kdWxlIGFuZCBoYXZlIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzDQo+Pj4gbW9k dWxlLg0KPj4+IA0KPj4+IEkgYW0gbm90IHN1cmUgd2h5IHlvdaGvcmUgbm90IHNlZWluZyBzb21l dGhpbmcgZGlmZmVyZW50Lg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4gUmVzaGFkLg0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IE9uIDIwMTctMDctMjcsIDM6NDAgUE0sICJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIFJlc2hhZCwgDQo+Pj4+ IA0KPj4+PiBPbiA3LzI3LzE3LCAzOjM1IFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxy cmFobWFuQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4gDQo+Pj4+PiBIaSBBY2VlLA0KPj4+ Pj4gDQo+Pj4+PiAxKSBJoa9sbCBzZWUgaWYgb3RoZXJzIGNoaW1lIGluIG9uIHRoaXMgYnV0IEkg YW0gZmluZSB3aXRoIGhhdmluZyB0aGUNCj4+Pj4+IGNsaWVudCBncm91cGluZyBpbiBpZXRmLWJm ZC10eXBlcy55YW5nLg0KPj4+Pj4gMikgYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaGFz IG11Y2ggbW9yZSB0aGFuIGp1c3QgdGhlDQo+Pj4+PiBtdWx0aXBsaWVyL3RpbWVycyB0aGF0IHRo ZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYyBzdHVmZg0KPj4+Pj4gKGRlbWFu ZC1tb2RlLCBCRkQgYXV0aCkgd2hpY2ggSU1PIGhhcyBubyBidXNpbmVzcyBvdXRzaWRlIG9mIEJG RC4NCj4+Pj4gDQo+Pj4+IEFncmVlZC4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4+IGJmZC1ncm91cGlu Zy1iYXNlLWNmZy1wYXJtcyBoYXMgb25seSB0aGUgbXVsdGlwbGllci90aW1lcnMuDQo+Pj4+IA0K Pj4+PiBQZXJoYXBzLCB0aGUgYWRkaXRpb24gb2YgbXVsdGlwbGllci90aW1lcnMgdG8NCj4+Pj5i ZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMNCj4+Pj4gaXNuoa90IHB1c2hlZCB0byBHaXRIdWIg eWV0LiBUaGlzIHZlcnNpb24NCj4+Pj4gDQo+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBm cmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRmLWINCj4+Pj5mZA0KPj4+ PiAtDQo+Pj4+IHQNCj4+Pj4geXBlcy55YW5nIG9ubHkgaGFzIHRoZSBlbmFibGVkIGxlYWYuDQo+ Pj4+IA0KPj4+PiANCj4+Pj4gVGhhbmtzLA0KPj4+PiBBY2VlIA0KPj4+PiANCj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBSZXNoYWQuDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiBPbiAyMDE3LTA3LTI3LCAzOjMwIFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNl ZUBjaXNjby5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gSGkgUmVzaGFkLCANCj4+Pj4+PiAN Cj4+Pj4+PiBPbiA3LzI3LzE3LCAzOjE5IFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxy cmFobWFuQGNpc2NvLmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+Pj4gSGkgQWNl ZSwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFdoZW4gd2UgbWV0IHdlIGFncmVlZCB0byBoYXZlIGEgbmV3 IG1vZGVsIGZvciBjbGllbnRzLiBBZnRlcndhcmRzIEkNCj4+Pj4+Pj4gZGVjaWRlZCB0byBjcmVh dGUgYSBuZXcgdHlwZXMgbW9kdWxlLCBhbmQgc3RpbGwgd2VudCBhaGVhZCB3aXRoIHRoZQ0KPj4+ Pj4+PiBjbGllbnRzIG1vZHVsZS4gSSBhbSBmaW5lIHdpdGggaGF2aW5nIGV2ZXJ5dGhpbmcgaW4g dGhlIHR5cGVzDQo+Pj4+Pj4+bW9kdWxlDQo+Pj4+Pj4+IChubw0KPj4+Pj4+PiBjbGllbnQgbW9k dWxlKS4NCj4+Pj4+PiANCj4+Pj4+PiBBbHRob3VnaCBJIGRvbqGvdCBmZWVsIHRoYXQgc3Ryb25n bHkgLSBJIGp1c3QgZG9uoa90IHNlZSB0aGF0IHB1dHRpbmcNCj4+Pj4+PnRoZQ0KPj4+Pj4+IGNs aWVudCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3ZpZGVzIGFueSBiZW5lZml0LiBBcyBm b3INCj4+Pj4+PiBkZXRyaW1lbnRzLA0KPj4+Pj4+IGl0IHJlcXVpcmVzIG1vcmUgb25lIG1vcmUg bG9jYWwgbW9kdWxlcyBmb3IgdmFsaWRhdGlvbiBhbmQgb25lIG1vcmUNCj4+Pj4+PiBsZXZlbA0K Pj4+Pj4+IG9mIGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0IHdlIGFyZSByZWFsbHkgYWxsb3dpbmcg dG8gYmUgY29uZmlndXJlZC4NCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgYW0gbm90IHN1 cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudC9xdWVzdGlvbiBvbg0KPj4+Pj4+PiBi ZmQtY2xpZW50LWV4dC1jZmctcGFybXMvYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMuIFRo ZSByZWFzb24NCj4+Pj4+Pj53ZQ0KPj4+Pj4+PiBoYXZlDQo+Pj4+Pj4+IDIgZ3JvdXBpbmdzIGlz IHRoYXQgc29tZSBwcm90b2NvbHMgbWF5IGRlY2lkZSB0byBoYXZlIGp1c3QgdGhlDQo+Pj4+Pj4+ ZW5hYmxlDQo+Pj4+Pj4+IGxlYWYNCj4+Pj4+Pj4gYW5kIG90aGVycyBtYXkgYWxzbyB3YW50IHRo ZSBtdWx0aXBsaWVyL3RpbWVyLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBiZmQtY2xpZW50LWV4dC1j ZmctcGFybXMgZ3JvdXBpbmcgc2hvdWxkIHVzZQ0KPj4+Pj4+IGJmZC10eXBlczpiZmQtZ3JvdXBp bmctY29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPj4+Pj4+IGJmZC10eXBlczpiZmQtY2xp ZW50LWJhc2UtY2ZnLXBhcm1zIC0gbm8/IFRoaXMgd291bGQgYmUgbW9yZSBvYnZpb3VzDQo+Pj4+ Pj4gdy9vDQo+Pj4+Pj4gdGhlIGNsaWVudCBtb2R1bGUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhbmtz LA0KPj4+Pj4+IEFjZWUgDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBSZWdh cmRzLA0KPj4+Pj4+PiBSZXNoYWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+ Pj4+IE9uIDIwMTctMDctMjcsIDM6MDcgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNp c2NvLmNvbT4NCj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBIaSBSZXNoYWQsDQo+ Pj4+Pj4+PiBXaHkgZG8gd2UgbmVlZCBhIG5ldyBZQU5HIG1vZGVsIGZvciBjbGllbnRzPyBXaHkg Y2Fuoa90IHRoZXkganVzdA0KPj4+Pj4+Pj51c2UNCj4+Pj4+Pj4+IGlldGYtYmZkLXR5cGVzLnlh bmc/IEmhr2QgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3NhcnkgbGV2ZWxzIG9mDQo+Pj4+Pj4+ PiBpbmRpcmVjdGlvbi4gSW4gZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUgc2luY2UgdGhlIGdy b3VwaW5nDQo+Pj4+Pj4+PiBiZmQtY2xpZW50LWV4dC1jZmctcGFybXMgdXNlcyB0aGUgZ3JvdXBp bmcNCj4+Pj4+Pj4+IGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcw0KPj4+Pj4+Pj4gd2hpY2gg b25seSBjb250YWlucyB0aGUgZW5hYmxlZCBsZWFmLiBJIGJlbGlldmUgeW91IG1lYW50IHRvIHVz ZQ0KPj4+Pj4+Pj4gYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaW4gdGhlIG90aGVyIG5l dyBtb2RlbC4gSG93ZXZlciwgSQ0KPj4+Pj4+Pj4gZG9uoa90DQo+Pj4+Pj4+PiBzZWUNCj4+Pj4+ Pj4+IGFueSByZWFzb24gd2h5IGNsaWVudCBzaG91bGRuoa90IHVzZSB0aGlzIGRpcmVjdGx5Lg0K Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gQWNlZSANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24g Ny8yNS8xNywgMjozMyBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNj by5jb20+DQo+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhpIFlpbmd6aGVu LA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoZSBncm91cGluZyBpcyBhdmFpbGFibGUgQA0KPj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+aHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQt eWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pDQo+Pj4+Pj4+Pj5ldA0KPj4+Pj4+Pj4+IGYNCj4+ Pj4+Pj4+PiAtDQo+Pj4+Pj4+Pj4gYg0KPj4+Pj4+Pj4+IGYNCj4+Pj4+Pj4+PiBkDQo+Pj4+Pj4+ Pj4gLQ0KPj4+Pj4+Pj4+IGMNCj4+Pj4+Pj4+PiBsaWVudHMueWFuZw0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IElmIHlvdan2ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBzZW5kIG1lIGFu IGVtYWlsLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4gUmVzaGFk Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIDIwMTctMDctMjEsIDEyOjIyIFBNLCAiWWluZ3po ZW4gUXUiIDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPg0KPj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+PiBIaSBSZXNoYWQsDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGFu a3MgZm9yIHRoZSBzdW1tYXJ5Lg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gQm90aCBvc3BmIGFu ZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29ycmVzcG9uZGluZyBjaGFuZ2VzIHdoZW4NCj4+Pj4+ Pj4+Pj50aGUNCj4+Pj4+Pj4+Pj4gbmV3DQo+Pj4+Pj4+Pj4+IEJGRCBncm91cGluZyBpcyBhdmFp bGFibGUuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+Pj4+IFlpbmd6 aGVuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+Pj4+Pj4+PiBGcm9tOiBSZXNoYWQgUmFobWFuIChycmFobWFuKSBbbWFpbHRvOnJyYWhtYW5A Y2lzY28uY29tXQ0KPj4+Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAxNyA3OjE5 IEFNDQo+Pj4+Pj4+Pj4+IFRvOiBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPjsgcnRnLWJm ZEBpZXRmLm9yZw0KPj4+Pj4+Pj4+PiBDYzogZHJhZnQtaWV0Zi1iZmQteWFuZ0BpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+PiBXZSAoQkZEIGFuZCBPU1BGIFlBTkcgYXV0aG9ycykgaGFkIGEgZGlzY3Vzc2lvbiB5ZXN0 ZXJkYXkuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGUgYWdyZWVtZW50IGlzIHRoYXQgc2lu Y2UgSUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdlDQo+Pj4+Pj4+Pj4+d2FudA0KPj4+ Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4+PiBhZGQNCj4+Pj4+Pj4+Pj4gYmFjayB0aGUgYmFzaWMgQkZE IGNvbmZpZyAobXVsdGlwbGllciArIGludGVydmFscykgaW4gSUdQIHZpYSBhDQo+Pj4+Pj4+Pj4+ IGdyb3VwaW5nLg0KPj4+Pj4+Pj4+PiBCRkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4g YSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4gSUdQDQo+Pj4+Pj4+Pj4+QkZEDQo+Pj4+Pj4+Pj4+IFlB TkcNCj4+Pj4+Pj4+Pj4gd2lsbCBiZSBpbiBhIHNlcGFyYXRlIG1vZHVsZSAoc2VwYXJhdGUgZnJv bSB0aGUgbWFpbiBJR1ANCj4+Pj4+Pj4+Pj5tb2R1bGUpLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+IFJlc2hhZC4NCj4+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4+IE9uIDIwMTctMDctMDUsIDEyOjIxIFBNLCAiUnRnLWJmZCBvbiBiZWhhbGYg b2YgSmVmZnJleSBIYWFzIg0KPj4+Pj4+Pj4+PiA8cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4gVGhhbmtzIGF1dGhvcnMgZm9yIHRoZSBlZGl0cyBvbiB0aGUgQkZEIHlhbmcgbW9kdWxlLiAg VGhpcw0KPj4+Pj4+Pj4+Pj5nZXRzIHVzDQo+Pj4+Pj4+Pj4+PiBhDQo+Pj4+Pj4+Pj4+PiBzaWdu aWZpY2FudCBzdGVwIGNsb3NlciB0byBhbGlnbm1lbnQgd2l0aCB0aGUgcmVzdCBvZiBJRVRGIGZv cg0KPj4+Pj4+Pj4+Pj4gbmV0d29yaw0KPj4+Pj4+Pj4+Pj4gaW5zdGFuY2luZy4NCj4+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+Pj4gSSdkIGxpa2UgdG8gZW5jb3VyYWdlIHRoZSB3b3JraW5nIGdyb3Vw IHRvIHByb3ZpZGUgZmVlZGJhY2sgb24NCj4+Pj4+Pj4+Pj4+IHRoaXMNCj4+Pj4+Pj4+Pj4+IGlz c3VlIGFuZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+IEFzIG5vdGVkIGluIGFub3RoZXIgdGhyZWFkLCB3ZSBzdGlsbCBoYXZlIHRvIGZp Z3VyZSBvdXQgaG93IHRvDQo+Pj4+Pj4+Pj4+PiBkZWFsDQo+Pj4+Pj4+Pj4+PiB3aXRoIGFjY29t bW9kYXRpbmcgaW50ZXJhY3Rpb24gb2YgdGhlIEJGRCB5YW5nIG1vZHVsZSB3aXRoDQo+Pj4+Pj4+ Pj4+PmNsaWVudA0KPj4+Pj4+Pj4+Pj4gcHJvdG9jb2xzLg0KPj4+Pj4+Pj4+Pj4gRm9yDQo+Pj4+ Pj4+Pj4+PiBleGFtcGxlLCB0aGUgSUdQcy4gIEluIHBhcnRpY3VsYXIsIGhvdyBkbyB5b3UgY29u ZmlndXJlIHRoZQ0KPj4+Pj4+Pj4+Pj4gcHJvcGVydGllcw0KPj4+Pj4+Pj4+Pj4gb2YgdGhlIEJG RCBzZXNzaW9ucyB0aGF0IG1heSBiZSBkeW5hbWljYWxseSBpbnN0YW50aWF0ZWQgYmFzZWQNCj4+ Pj4+Pj4+Pj4+b24NCj4+Pj4+Pj4+Pj4+IGNvbnRyb2wgcHJvdG9jb2wgYWN0aXZpdHk/DQo+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IC0tIEplZmYNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4g T24gRnJpLCBKdW4gMzAsIDIwMTcgYXQgMTI6NTU6NTlQTSAtMDcwMCwNCj4+Pj4+Pj4+Pj4+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+Pj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZQ0KPj4+Pj4+Pj4+Pj4+IEludGVybmV0LURyYWZ0cw0KPj4+Pj4+Pj4+Pj4+IGRpcmVj dG9yaWVzLg0KPj4+Pj4+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEJp ZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+Pj4+Pj4+Pj4+IERldGVjdGlvbg0KPj4+Pj4+Pj4+ Pj4+IG9mIHRoZSBJRVRGLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ICAgICAgICBUaXRs ZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Pj4+ Pj4+PiBGb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+Pj4gRGV0ZWN0aW9uIChCRkQpDQo+Pj4+Pj4+Pj4+ Pj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWhtYW4NCj4+Pj4+Pj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0KPj4+Pj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+Pj4+Pj4+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFsbGFnYXR0aQ0KPj4+Pj4+Pj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+Pj4+Pj4+IAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+Pj4+Pj4+IAlQYWdl cyAgICAgICAgICAgOiA1OQ0KPj4+Pj4+Pj4+Pj4+IAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA2 LTMwDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gQWJzdHJhY3Q6DQo+Pj4+Pj4+Pj4+Pj4g ICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNl ZCB0bw0KPj4+Pj4+Pj4+Pj4+IGNvbmZpZ3VyZQ0KPj4+Pj4+Pj4+Pj4+ICAgYW5kIG1hbmFnZSBC aWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpLg0KPj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+Pj4+Pj4+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZkLXlhbmcvDQo+Pj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUNCj4+Pj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4+IHN1Ym1pc3Npb24gIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUNCj4+Pj4+Pj4+Pj4+ PmF0DQo+Pj4+Pj4+Pj4+Pj4gdG9vbHMuaWV0Zi5vcmcuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPj4+Pj4+Pj4+Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+PiANCj4+ Pj4+IA0KPj4+PiANCj4+PiANCj4+IA0KPg0KPk1haGVzaCBKZXRoYW5hbmRhbmkNCj5tamV0aGFu YW5kYW5pQGdtYWlsLmNvbQ0KPg0KPg0KPg0KDQo= From nobody Fri Jul 28 14:43:55 2017 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 3AF53131DA7; Fri, 28 Jul 2017 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 BSTJreQexZC0; Fri, 28 Jul 2017 14:43:51 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (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 32E47129B10; Fri, 28 Jul 2017 14:43:51 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id b130so2884711oii.3; Fri, 28 Jul 2017 14:43:51 -0700 (PDT) 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=7knKbmzmfL3wPJK5FG3+2jyvHzBJmyi7Mwby32zqmAc=; b=awIW5F4X21puPDAYtzgcyqEcdGes0KEn8BJGzURWhGde1g5brIzcRkRO3DveunespD Oz+QSbwkxv74CaBKqAP4URArNZrONmP3PuH2wwcU/uwq7SfaAPjBG5wkjn7hNEIs4T7Y aSDrRkydnQULURLGTGSVYCYGVpxkMNmgcsShqh6f0zTqta6JWylMBZb0GF6fY9skdr17 4NjCnfHGatrZt6o4NtvqRfqRTwpUXAA1ZNKZlBvO0GU6JDh4e95SqMmkTNGgmNU4ZnaR SH3G4DlDBZLa25KjB84f4ZyLaGSQIdANT/MLJY9BXDpGdhCQb4b3gwXrcCrRrvlZKDop Y0YA== 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=7knKbmzmfL3wPJK5FG3+2jyvHzBJmyi7Mwby32zqmAc=; b=mdhvoPRAj+RvBwXFeEUYTxIYJ+8qOrkGGVMMm27bymPZLZD84pvLImFF1zfVwyuFws 7O40L4Hqd6SVwD1MVV0VbS+iBhaUe5Zz5YrY+YTXNlRfJNdfASlttLIQ45Ca5Hfm0eYV pmhSL1fMNR9Md9t+CV/duXQCaLJCd9b4LNCO3S8ouOaqipqXb472UjZOBcXevQw/5gVU u+r/E3bIp9Hl5St8TbJT0hKpJ7B3DKMsKgwQFq+6T2s9r4QzSOohZ9+1qBLndg03aOs3 ELn4w2J6qLjHQwboa5f8kqhKam2JuGW0vmmLTP/3ZYCzM3HKmAL34d6oXL3gzoOLnDDQ rxhw== X-Gm-Message-State: AIVw110L9oEFxwoxZhqEnPyh4BA0+/BOhnArxgsr4JRPVwE8KL2kQw0Y 7+o+gp9NWwYcRQ== X-Received: by 10.202.90.193 with SMTP id o184mr8895010oib.208.1501278230486; Fri, 28 Jul 2017 14:43:50 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:1142:f772:6d85:788d? ([2001:420:30d:1320:1142:f772:6d85:788d]) by smtp.gmail.com with ESMTPSA id n189sm19786085oih.0.2017.07.28.14.43.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Jul 2017 14:43:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: Date: Fri, 28 Jul 2017 14:44:02 -0700 Cc: "Acee Lindem (acee)" , Yingzhen Qu , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> To: Reshad Rahman X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 21:43:54 -0000 But do those groupings impact IGP models? I can take a stab at making the changes before the weekend. > On Jul 28, 2017, at 2:42 PM, Reshad Rahman (rrahman) = wrote: >=20 > I am fine with this proposal. It will impact other groupings also. >=20 >=20 >=20 > On 2017-07-28, 5:25 PM, "Mahesh Jethanandani" = > wrote: >=20 >> Would it not be better to call bfd-grouping-base-cfg-parms something = like >> bfd-grouping-client-cfg-params or more simply client-cfg-params. We = know >> it is a grouping and we know it is a bfd grouping. Why repeat? >>=20 >>> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) = wrote: >>>=20 >>> Hi Reshad,=20 >>>=20 >>> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms >>> groupings. >>> Fewer similar grouping and modules will be better ;^) >>>=20 >>> Thanks, >>> Acee >>>=20 >>> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" >>> wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> What I see @=20 >>>>=20 >>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bf >>>> d- >>>> t >>>> ypes.yang: >>>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this = grouping >>>> is >>>> defined twice, this will be fixed when I get rid of >>>> ietf-bfd-clients.yang >>>> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>>=20 >>>> Let me get rid of the client module and have everything in the = types >>>> module. >>>>=20 >>>> I am not sure why you=E2=80=99re not seeing something different. >>>>=20 >>>> Regards, >>>> Reshad. >>>>=20 >>>>=20 >>>>=20 >>>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" = wrote: >>>>=20 >>>>> Hi Reshad,=20 >>>>>=20 >>>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" >>>>> wrote: >>>>>=20 >>>>>> Hi Acee, >>>>>>=20 >>>>>> 1) I=E2=80=99ll see if others chime in on this but I am fine with = having the >>>>>> client grouping in ietf-bfd-types.yang. >>>>>> 2) bfd-grouping-common-cfg-parms has much more than just the >>>>>> multiplier/timers that the IGPs need. It also has BFD specific = stuff >>>>>> (demand-mode, BFD auth) which IMO has no business outside of BFD. >>>>>=20 >>>>> Agreed.=20 >>>>>=20 >>>>>=20 >>>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>>=20 >>>>> Perhaps, the addition of multiplier/timers to >>>>> bfd-grouping-base-cfg-parms >>>>> isn=E2=80=99t pushed to GitHub yet. This version >>>>>=20 >>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-b >>>>> fd >>>>> - >>>>> t >>>>> ypes.yang only has the enabled leaf. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Acee=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Reshad. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" = wrote: >>>>>>=20 >>>>>>> Hi Reshad,=20 >>>>>>>=20 >>>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" = >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Acee, >>>>>>>>=20 >>>>>>>> When we met we agreed to have a new model for clients. = Afterwards I >>>>>>>> decided to create a new types module, and still went ahead with = the >>>>>>>> clients module. I am fine with having everything in the types >>>>>>>> module >>>>>>>> (no >>>>>>>> client module). >>>>>>>=20 >>>>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99t= see that putting >>>>>>> the >>>>>>> client config params in wrappers provides any benefit. As for >>>>>>> detriments, >>>>>>> it requires more one more local modules for validation and one = more >>>>>>> level >>>>>>> of indirection to see what we are really allowing to be = configured. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am not sure I fully understand your comment/question on >>>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The = reason >>>>>>>> we >>>>>>>> have >>>>>>>> 2 groupings is that some protocols may decide to have just the >>>>>>>> enable >>>>>>>> leaf >>>>>>>> and others may also want the multiplier/timer. >>>>>>>=20 >>>>>>> The bfd-client-ext-cfg-parms grouping should use >>>>>>> bfd-types:bfd-grouping-common-cfg-parms rather than >>>>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more = obvious >>>>>>> w/o >>>>>>> the client module. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Acee=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Reshad. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Reshad, >>>>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t = they just >>>>>>>>> use >>>>>>>>> ietf-bfd-types.yang? I=E2=80=99d like to avoid the unnecessary = levels of >>>>>>>>> indirection. In fact, it looks wrong to me since the grouping >>>>>>>>> bfd-client-ext-cfg-parms uses the grouping >>>>>>>>> bfd-grouping-base-cfg-parms >>>>>>>>> which only contains the enabled leaf. I believe you meant to = use >>>>>>>>> bfd-grouping-common-cfg-parms in the other new model. However, = I >>>>>>>>> don=E2=80=99t >>>>>>>>> see >>>>>>>>> any reason why client shouldn=E2=80=99t use this directly. >>>>>>>>> Thanks, >>>>>>>>> Acee=20 >>>>>>>>>=20 >>>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" = >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Yingzhen, >>>>>>>>>>=20 >>>>>>>>>> The grouping is available @ >>>>>>>>>>=20 >>>>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/i >>>>>>>>>> et >>>>>>>>>> f >>>>>>>>>> - >>>>>>>>>> b >>>>>>>>>> f >>>>>>>>>> d >>>>>>>>>> - >>>>>>>>>> c >>>>>>>>>> lients.yang >>>>>>>>>>=20 >>>>>>>>>> If you=C2=B9d like changes to the grouping, send me an email. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Reshad. >>>>>>>>>>=20 >>>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Reshad, >>>>>>>>>>>=20 >>>>>>>>>>> Thanks for the summary. >>>>>>>>>>>=20 >>>>>>>>>>> Both ospf and isis models will make corresponding changes = when >>>>>>>>>>> the >>>>>>>>>>> new >>>>>>>>>>> BFD grouping is available. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Yingzhen >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org; = draft-ietf-ospf-yang@ietf.org >>>>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>>=20 >>>>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>>=20 >>>>>>>>>>> The agreement is that since IGP peers are auto-discovered, = we >>>>>>>>>>> want >>>>>>>>>>> to >>>>>>>>>>> add >>>>>>>>>>> back the basic BFD config (multiplier + intervals) in IGP = via a >>>>>>>>>>> grouping. >>>>>>>>>>> BFD will provide that grouping in a specific YANG module. = IGP >>>>>>>>>>> BFD >>>>>>>>>>> YANG >>>>>>>>>>> will be in a separate module (separate from the main IGP >>>>>>>>>>> module). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Reshad. >>>>>>>>>>>=20 >>>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" >>>>>>>>>>> = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Thanks authors for the edits on the BFD yang module. This >>>>>>>>>>>> gets us >>>>>>>>>>>> a >>>>>>>>>>>> significant step closer to alignment with the rest of IETF = for >>>>>>>>>>>> network >>>>>>>>>>>> instancing. >>>>>>>>>>>>=20 >>>>>>>>>>>> I'd like to encourage the working group to provide feedback = on >>>>>>>>>>>> this >>>>>>>>>>>> issue and also the changes in the module. >>>>>>>>>>>>=20 >>>>>>>>>>>> As noted in another thread, we still have to figure out how = to >>>>>>>>>>>> deal >>>>>>>>>>>> with accommodating interaction of the BFD yang module with >>>>>>>>>>>> client >>>>>>>>>>>> protocols. >>>>>>>>>>>> For >>>>>>>>>>>> example, the IGPs. In particular, how do you configure the >>>>>>>>>>>> properties >>>>>>>>>>>> of the BFD sessions that may be dynamically instantiated = based >>>>>>>>>>>> on >>>>>>>>>>>> control protocol activity? >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Jeff >>>>>>>>>>>>=20 >>>>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700, >>>>>>>>>>>> internet-drafts@ietf.org >>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>>>> Internet-Drafts >>>>>>>>>>>>> directories. >>>>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding >>>>>>>>>>>>> Detection >>>>>>>>>>>>> of the IETF. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>>> Forwarding >>>>>>>>>>>>> Detection (BFD) >>>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>> Pages : 59 >>>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> This document defines a YANG data model that can be used = to >>>>>>>>>>>>> configure >>>>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please note that it may take a couple of minutes from the = time >>>>>>>>>>>>> of >>>>>>>>>>>>> submission until the htmlized version and diff are = available >>>>>>>>>>>>> at >>>>>>>>>>>>> tools.ietf.org. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Fri Jul 28 15:58:00 2017 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 438B8131461; Fri, 28 Jul 2017 15:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 oNOTlj6IlGe0; Fri, 28 Jul 2017 15:57:55 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 F2884131E77; Fri, 28 Jul 2017 15:57:54 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id x3so140525066oia.1; Fri, 28 Jul 2017 15:57:54 -0700 (PDT) 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=h9aElpnNyDtCz2R+kTgEx2xdOEl0+aqymRK4OWs6gLE=; b=egY0/FVc39epVgaiuvwoYjbllTmgBLovPrTGCjRBlgYbuKT0y/Jpgz7cSIT6CMHfYO Q6UhzcGe/0JFSWYLk1tva5b3jYQkMvu4K7uAenp6IHzXdZbLr+pYD1h8o4V6atZU4452 PjGpvMq2Iw34Q54ApPSlNj/PO9swWyvDb+gx347jmo9CR5hvJL4NNy7hrOLQUxizQadF +/CRMQF1srIg8iZL0+/tRU3q/3foiSlcIISRNICTNR6JlEiWxsihf4gjpmuTcwgqLZzG 835qdIY7TpdVON4mTf+alWTATDHHfjiUULajpEMTeUpXUTL0zZEmwl8QhPbSjb1PAXmF iiMQ== 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=h9aElpnNyDtCz2R+kTgEx2xdOEl0+aqymRK4OWs6gLE=; b=kVcLHWcRLKmgj0TO2OT3AEkyO7qmXlTG3HCKaotlgqm+zuccZVRT1Y8PbPOoBS8auH MwmeFv4AC+ifefs5XQyyRxq7L+i2WS90OTNLUBPzV5lCXq6Jw9MykRxQn6HZFfinR4Wo lPOt75EXnL02QE/ikwHMAk79lysj1z2ukkZiPVmsRB5Z4m+pDr84NEty+A7VngkRkCGl DWaWTCldaIURC/uvsCOkAUvHfOz2/H96cG9AQ66lCferWYqPA8cBQ9YJZ3YPh4MvEtKr RQYypQZsSI1p3h5aeJqy7heZlp2dDOaKBWHeM5U+ze+T8rfoUuZ047Q7/tbNZzCcojtE 9o7w== X-Gm-Message-State: AIVw111QsvhzloKAhVhAgrqO442CbUNuwFltmOMJzL5dBRvI+8OBWAlC yWPirMpmpw4iaw== X-Received: by 10.202.73.20 with SMTP id w20mr8655475oia.27.1501282674311; Fri, 28 Jul 2017 15:57:54 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:1142:f772:6d85:788d? ([2001:420:30d:1320:1142:f772:6d85:788d]) by smtp.gmail.com with ESMTPSA id s186sm19761038oia.6.2017.07.28.15.57.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 28 Jul 2017 15:57:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: Date: Fri, 28 Jul 2017 15:58:06 -0700 Cc: Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , Reshad Rahman Content-Transfer-Encoding: quoted-printable Message-Id: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> To: Yingzhen Qu , "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 22:57:58 -0000 The changes are done and pushed to GitHub. Use the grouping = client-cfg-parms. > On Jul 28, 2017, at 2:44 PM, Mahesh Jethanandani = wrote: >=20 > But do those groupings impact IGP models? >=20 > I can take a stab at making the changes before the weekend. >=20 >> On Jul 28, 2017, at 2:42 PM, Reshad Rahman (rrahman) = wrote: >>=20 >> I am fine with this proposal. It will impact other groupings also. >>=20 >>=20 >>=20 >> On 2017-07-28, 5:25 PM, "Mahesh Jethanandani" = >> wrote: >>=20 >>> Would it not be better to call bfd-grouping-base-cfg-parms something = like >>> bfd-grouping-client-cfg-params or more simply client-cfg-params. We = know >>> it is a grouping and we know it is a bfd grouping. Why repeat? >>>=20 >>>> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) = wrote: >>>>=20 >>>> Hi Reshad,=20 >>>>=20 >>>> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms >>>> groupings. >>>> Fewer similar grouping and modules will be better ;^) >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" >>>> wrote: >>>>=20 >>>>> Hi Acee, >>>>>=20 >>>>> What I see @=20 >>>>>=20 >>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-bf >>>>> d- >>>>> t >>>>> ypes.yang: >>>>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this = grouping >>>>> is >>>>> defined twice, this will be fixed when I get rid of >>>>> ietf-bfd-clients.yang >>>>> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>>>=20 >>>>> Let me get rid of the client module and have everything in the = types >>>>> module. >>>>>=20 >>>>> I am not sure why you=E2=80=99re not seeing something different. >>>>>=20 >>>>> Regards, >>>>> Reshad. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" = wrote: >>>>>=20 >>>>>> Hi Reshad,=20 >>>>>>=20 >>>>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" = >>>>>> wrote: >>>>>>=20 >>>>>>> Hi Acee, >>>>>>>=20 >>>>>>> 1) I=E2=80=99ll see if others chime in on this but I am fine = with having the >>>>>>> client grouping in ietf-bfd-types.yang. >>>>>>> 2) bfd-grouping-common-cfg-parms has much more than just the >>>>>>> multiplier/timers that the IGPs need. It also has BFD specific = stuff >>>>>>> (demand-mode, BFD auth) which IMO has no business outside of = BFD. >>>>>>=20 >>>>>> Agreed.=20 >>>>>>=20 >>>>>>=20 >>>>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>>>=20 >>>>>> Perhaps, the addition of multiplier/timers to >>>>>> bfd-grouping-base-cfg-parms >>>>>> isn=E2=80=99t pushed to GitHub yet. This version >>>>>>=20 >>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf-b >>>>>> fd >>>>>> - >>>>>> t >>>>>> ypes.yang only has the enabled leaf. >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Acee=20 >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Reshad. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" = wrote: >>>>>>>=20 >>>>>>>> Hi Reshad,=20 >>>>>>>>=20 >>>>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" = >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Acee, >>>>>>>>>=20 >>>>>>>>> When we met we agreed to have a new model for clients. = Afterwards I >>>>>>>>> decided to create a new types module, and still went ahead = with the >>>>>>>>> clients module. I am fine with having everything in the types >>>>>>>>> module >>>>>>>>> (no >>>>>>>>> client module). >>>>>>>>=20 >>>>>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99= t see that putting >>>>>>>> the >>>>>>>> client config params in wrappers provides any benefit. As for >>>>>>>> detriments, >>>>>>>> it requires more one more local modules for validation and one = more >>>>>>>> level >>>>>>>> of indirection to see what we are really allowing to be = configured. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I am not sure I fully understand your comment/question on >>>>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The = reason >>>>>>>>> we >>>>>>>>> have >>>>>>>>> 2 groupings is that some protocols may decide to have just the >>>>>>>>> enable >>>>>>>>> leaf >>>>>>>>> and others may also want the multiplier/timer. >>>>>>>>=20 >>>>>>>> The bfd-client-ext-cfg-parms grouping should use >>>>>>>> bfd-types:bfd-grouping-common-cfg-parms rather than >>>>>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more = obvious >>>>>>>> w/o >>>>>>>> the client module. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Acee=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Reshad. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Reshad, >>>>>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t = they just >>>>>>>>>> use >>>>>>>>>> ietf-bfd-types.yang? I=E2=80=99d like to avoid the = unnecessary levels of >>>>>>>>>> indirection. In fact, it looks wrong to me since the grouping >>>>>>>>>> bfd-client-ext-cfg-parms uses the grouping >>>>>>>>>> bfd-grouping-base-cfg-parms >>>>>>>>>> which only contains the enabled leaf. I believe you meant to = use >>>>>>>>>> bfd-grouping-common-cfg-parms in the other new model. = However, I >>>>>>>>>> don=E2=80=99t >>>>>>>>>> see >>>>>>>>>> any reason why client shouldn=E2=80=99t use this directly. >>>>>>>>>> Thanks, >>>>>>>>>> Acee=20 >>>>>>>>>>=20 >>>>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" = >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Yingzhen, >>>>>>>>>>>=20 >>>>>>>>>>> The grouping is available @ >>>>>>>>>>>=20 >>>>>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/i >>>>>>>>>>> et >>>>>>>>>>> f >>>>>>>>>>> - >>>>>>>>>>> b >>>>>>>>>>> f >>>>>>>>>>> d >>>>>>>>>>> - >>>>>>>>>>> c >>>>>>>>>>> lients.yang >>>>>>>>>>>=20 >>>>>>>>>>> If you=C2=B9d like changes to the grouping, send me an = email. >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Reshad. >>>>>>>>>>>=20 >>>>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" = >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi Reshad, >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks for the summary. >>>>>>>>>>>>=20 >>>>>>>>>>>> Both ospf and isis models will make corresponding changes = when >>>>>>>>>>>> the >>>>>>>>>>>> new >>>>>>>>>>>> BFD grouping is available. >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Yingzhen >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org; = draft-ietf-ospf-yang@ietf.org >>>>>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>=20 >>>>>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>>>=20 >>>>>>>>>>>> The agreement is that since IGP peers are auto-discovered, = we >>>>>>>>>>>> want >>>>>>>>>>>> to >>>>>>>>>>>> add >>>>>>>>>>>> back the basic BFD config (multiplier + intervals) in IGP = via a >>>>>>>>>>>> grouping. >>>>>>>>>>>> BFD will provide that grouping in a specific YANG module. = IGP >>>>>>>>>>>> BFD >>>>>>>>>>>> YANG >>>>>>>>>>>> will be in a separate module (separate from the main IGP >>>>>>>>>>>> module). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Reshad. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey = Haas" >>>>>>>>>>>> = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks authors for the edits on the BFD yang module. This >>>>>>>>>>>>> gets us >>>>>>>>>>>>> a >>>>>>>>>>>>> significant step closer to alignment with the rest of IETF = for >>>>>>>>>>>>> network >>>>>>>>>>>>> instancing. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I'd like to encourage the working group to provide = feedback on >>>>>>>>>>>>> this >>>>>>>>>>>>> issue and also the changes in the module. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As noted in another thread, we still have to figure out = how to >>>>>>>>>>>>> deal >>>>>>>>>>>>> with accommodating interaction of the BFD yang module with >>>>>>>>>>>>> client >>>>>>>>>>>>> protocols. >>>>>>>>>>>>> For >>>>>>>>>>>>> example, the IGPs. In particular, how do you configure = the >>>>>>>>>>>>> properties >>>>>>>>>>>>> of the BFD sessions that may be dynamically instantiated = based >>>>>>>>>>>>> on >>>>>>>>>>>>> control protocol activity? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Jeff >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700, >>>>>>>>>>>>> internet-drafts@ietf.org >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>>>>> Internet-Drafts >>>>>>>>>>>>>> directories. >>>>>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding >>>>>>>>>>>>>> Detection >>>>>>>>>>>>>> of the IETF. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>>>> Forwarding >>>>>>>>>>>>>> Detection (BFD) >>>>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>>> Pages : 59 >>>>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>> This document defines a YANG data model that can be used = to >>>>>>>>>>>>>> configure >>>>>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Please note that it may take a couple of minutes from the = time >>>>>>>>>>>>>> of >>>>>>>>>>>>>> submission until the htmlized version and diff are = available >>>>>>>>>>>>>> at >>>>>>>>>>>>>> tools.ietf.org. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >>>=20 >>>=20 >>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Sat Jul 29 16:39:18 2017 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 BD3481317A4; Sat, 29 Jul 2017 16:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 GfoVr-rYCjKI; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 22F59131C2E; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id q85so107918887pfq.1; Sat, 29 Jul 2017 16:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MNQoSQ6oMmR9bLHI6/diM7OIY7Rms8k2sEorYUsGsXs=; b=nyMXznL+J8KzBBWj+74A/Ysm04aDX0UUdeaulnE9A5kwSHC9I7f8nWmA2LByV0TB3f ZxeLFiqglkdBMBLCYQmoF6R4136+H5z6EYRYPhW7ibLtB0Z++JTCuRSEjG7X+GWsXIM5 dbheonAHEvkOa35mVmExB9jba7eT0/XxDpl9V+qYbFoUjz5jcmJuiS9+SlC/XYW0NTiT KLt3fGcFYMkCBeu98p5wiWGGuUL3RMCgoVESvySl2YawLHvU4AgoVkcAxQ9L0lVL0Wze WbMRMT5UOZUG4d+WeC6UYsB2TX4Bz3s43m6aT9cEcs266emmq0B3xZy7VKXDTxP3XiZH p6FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MNQoSQ6oMmR9bLHI6/diM7OIY7Rms8k2sEorYUsGsXs=; b=KWBh82LeFQrBSdyKVuZhB2FRolE01dXTkBsEpzjKacqfAZoFfWekjoorjzog2q/kfY 5KV6Kh+qjCmTj4K80WvTCeaihKDDgBdqqx8ISuhQgXNXHo27f7HQuqfvEvbc1vNsj1Vx QHpuur68hr3bnvy/FMyj9XNqJ/hTlOgCcfObh8w2b09rJImf83N3whPmnYm/rfZ3UThg O2ChZtps9ycXpsxIEID7PIXrFJgr2aWIAnAvSXFyWeCYUmM4R/2K9oxL1LzXSe7MS9VM vWKfJq9Db/5giMqHL/RG46Aj79Z2aOV3F++/csHc658GphYmGJ+/MA1FmSdZSahzhX20 788A== X-Gm-Message-State: AIVw1125opc2If4ud8Fq/3/muH3Be/hJwGtlFaNRplG4JMbZjQ3fzy6E X1DmUSUljRVqWlEW68NwItJcgoTxZg== X-Received: by 10.101.77.6 with SMTP id i6mr11245228pgt.181.1501371554150; Sat, 29 Jul 2017 16:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.68 with HTTP; Sat, 29 Jul 2017 16:39:13 -0700 (PDT) From: Greg Mirsky Date: Sat, 29 Jul 2017 16:39:13 -0700 Message-ID: Subject: New draft on use of BFD Demand mode over MPLS p2p LSP To: "rtg-bfd@ietf.org" , "mpls@ietf.org" , spring@ietf.org Content-Type: multipart/alternative; boundary="089e08238004293d1105557d4efa" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 23:39:17 -0000 --089e08238004293d1105557d4efa Content-Type: text/plain; charset="UTF-8" Dear All, the new draft, draft-mirsky-bfd-mpls-demand , was presented at MPLS WG meeting in Prague. The draft proposes how the BFD Demand mode can be used over MPLS p2p LSP. One of use cases that likely benefit from the described procedures, in my opinion, is when multiple BFD sessions established for the same FEC between the same pair of BFD nodes, e.g. ECMP scenario, as described in RFC 7726. Greatly appreciate your reviews, comments, questions and suggestions. Regards, Greg --089e08238004293d1105557d4efa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the new draft,=C2=A0draft-= mirsky-bfd-mpls-demand, was CC: Reshad Rahman , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAbE+gIACaDNQ Date: Sun, 30 Jul 2017 17:14:28 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.81] Content-Type: multipart/mixed; boundary="_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.597E13FD.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d620cfb2812958a2ecbedbaf8b4840db Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 17:14:43 -0000 --_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpQbGVhc2Ugc2VlIGF0dGFjaGVkIG9zcGYgYmZkIG1vZHVsZS4gQmFzZSBvc3Bm IG1vZHVsZSBhbHNvIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gcmVtb3ZlIHRoZSBiZmQgZW5hYmxl IGxlYWYuIElTSVMgbW9kZWwgbmVlZCB0byBkbyB0aGUgc2FtZSBjaGFuZ2UsIGlldGYtaXNpcy1i ZmQueWFuZyB3aWxsIGxvb2sgdGhlIHNhbWUgYXMgaWV0Zi1vc3BmLWJmZC55YW5nLg0KDQpQbGVh c2UgbGV0IG1lIGtub3cgeW91ciBjb21tZXRucy4NCg0KVGhhbmtzLA0KWWluZ3poZW4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0 bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjgsIDIwMTcg MjoyNSBQTQ0KVG86IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQpDYzogUmVz aGFkIFJhaG1hbiA8cnJhaG1hbkBjaXNjby5jb20+OyBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVA aHVhd2VpLmNvbT47IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+OyBydGctYmZkQGlldGYu b3JnOyBkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYu dHh0DQoNCldvdWxkIGl0IG5vdCBiZSBiZXR0ZXIgdG8gY2FsbCBiZmQtZ3JvdXBpbmctYmFzZS1j ZmctcGFybXMgc29tZXRoaW5nIGxpa2UgYmZkLWdyb3VwaW5nLWNsaWVudC1jZmctcGFyYW1zIG9y IG1vcmUgc2ltcGx5IGNsaWVudC1jZmctcGFyYW1zLiBXZSBrbm93IGl0IGlzIGEgZ3JvdXBpbmcg YW5kIHdlIGtub3cgaXQgaXMgYSBiZmQgZ3JvdXBpbmcuIFdoeSByZXBlYXQ/DQoNCj4gT24gSnVs IDI3LCAyMDE3LCBhdCA3OjM0IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29t PiB3cm90ZToNCj4gDQo+IEhpIFJlc2hhZCwNCj4gDQo+IE9rIC0gSSBzZWUgbm93LiBJIHdhcyBs b29raW5nIGF0IHRoZSB3cm9uZyB4eHh4LWJhc2UtY2ZnLXBhcm1zIGdyb3VwaW5ncy4NCj4gRmV3 ZXIgc2ltaWxhciBncm91cGluZyBhbmQgbW9kdWxlcyB3aWxsIGJlIGJldHRlciA7XikNCj4gDQo+ IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gT24gNy8yNy8xNywgOTowMyBQTSwgIlJlc2hhZCBSYWht YW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4+IEhpIEFjZWUs DQo+PiANCj4+IFdoYXQgSSBzZWUgQA0KPj4gaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMv aWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZXRmDQo+PiAtYmZkLQ0KPj4gdA0K Pj4geXBlcy55YW5nOg0KPj4gMSkgYmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyBoYXMgbGVhZiBl bmFibGVkIG9ubHkuIEJUVyB0aGlzIGdyb3VwaW5nIA0KPj4gaXMgZGVmaW5lZCB0d2ljZSwgdGhp cyB3aWxsIGJlIGZpeGVkIHdoZW4gSSBnZXQgcmlkIG9mIA0KPj4gaWV0Zi1iZmQtY2xpZW50cy55 YW5nDQo+PiAyKSBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG11bHRpcGxpZXIvdGlt ZXJzLg0KPj4gDQo+PiBMZXQgbWUgZ2V0IHJpZCBvZiB0aGUgY2xpZW50IG1vZHVsZSBhbmQgaGF2 ZSBldmVyeXRoaW5nIGluIHRoZSB0eXBlcyANCj4+IG1vZHVsZS4NCj4+IA0KPj4gSSBhbSBub3Qg c3VyZSB3aHkgeW914oCZcmUgbm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPj4gDQo+ PiBSZWdhcmRzLA0KPj4gUmVzaGFkLg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMjAxNy0wNy0yNywg Mzo0MCBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+ IA0KPj4+IEhpIFJlc2hhZCwNCj4+PiANCj4+PiBPbiA3LzI3LzE3LCAzOjM1IFBNLCAiUmVzaGFk IFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+ IEhpIEFjZWUsDQo+Pj4+IA0KPj4+PiAxKSBJ4oCZbGwgc2VlIGlmIG90aGVycyBjaGltZSBpbiBv biB0aGlzIGJ1dCBJIGFtIGZpbmUgd2l0aCBoYXZpbmcgDQo+Pj4+IHRoZSBjbGllbnQgZ3JvdXBp bmcgaW4gaWV0Zi1iZmQtdHlwZXMueWFuZy4NCj4+Pj4gMikgYmZkLWdyb3VwaW5nLWNvbW1vbi1j ZmctcGFybXMgaGFzIG11Y2ggbW9yZSB0aGFuIGp1c3QgdGhlIA0KPj4+PiBtdWx0aXBsaWVyL3Rp bWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYyANCj4+Pj4g c3R1ZmYgKGRlbWFuZC1tb2RlLCBCRkQgYXV0aCkgd2hpY2ggSU1PIGhhcyBubyBidXNpbmVzcyBv dXRzaWRlIG9mIEJGRC4NCj4+PiANCj4+PiBBZ3JlZWQuIA0KPj4+IA0KPj4+IA0KPj4+PiBiZmQt Z3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG9ubHkgdGhlIG11bHRpcGxpZXIvdGltZXJzLg0K Pj4+IA0KPj4+IFBlcmhhcHMsIHRoZSBhZGRpdGlvbiBvZiBtdWx0aXBsaWVyL3RpbWVycyB0byAN Cj4+PiBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaXNu4oCZdCBwdXNoZWQgdG8gR2l0SHVi IHlldC4gVGhpcyB2ZXJzaW9uIA0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9qaGFhcy1wZnJjL2ll dGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbmcvaWV0DQo+Pj4gZi1iZmQNCj4+PiAtDQo+ Pj4gdA0KPj4+IHlwZXMueWFuZyBvbmx5IGhhcyB0aGUgZW5hYmxlZCBsZWFmLg0KPj4+IA0KPj4+ IA0KPj4+IFRoYW5rcywNCj4+PiBBY2VlDQo+Pj4gDQo+Pj4gDQo+Pj4+IA0KPj4+PiBSZWdhcmRz LA0KPj4+PiBSZXNoYWQuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9uIDIwMTctMDctMjcs IDM6MzAgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4+IA0KPj4+Pj4gSGkgUmVzaGFkLA0KPj4+Pj4gDQo+Pj4+PiBPbiA3LzI3LzE3LCAzOjE5IFBN LCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj4+IHdy b3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gSGkgQWNlZSwNCj4+Pj4+PiANCj4+Pj4+PiBXaGVuIHdlIG1l dCB3ZSBhZ3JlZWQgdG8gaGF2ZSBhIG5ldyBtb2RlbCBmb3IgY2xpZW50cy4gQWZ0ZXJ3YXJkcyAN Cj4+Pj4+PiBJIGRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwgYW5kIHN0aWxs IHdlbnQgYWhlYWQgd2l0aCANCj4+Pj4+PiB0aGUgY2xpZW50cyBtb2R1bGUuIEkgYW0gZmluZSB3 aXRoIGhhdmluZyBldmVyeXRoaW5nIGluIHRoZSB0eXBlcyANCj4+Pj4+PiBtb2R1bGUgKG5vIGNs aWVudCBtb2R1bGUpLg0KPj4+Pj4gDQo+Pj4+PiBBbHRob3VnaCBJIGRvbuKAmXQgZmVlbCB0aGF0 IHN0cm9uZ2x5IC0gSSBqdXN0IGRvbuKAmXQgc2VlIHRoYXQgDQo+Pj4+PiBwdXR0aW5nIHRoZSBj bGllbnQgY29uZmlnIHBhcmFtcyBpbiB3cmFwcGVycyBwcm92aWRlcyBhbnkgYmVuZWZpdC4gDQo+ Pj4+PiBBcyBmb3IgZGV0cmltZW50cywgaXQgcmVxdWlyZXMgbW9yZSBvbmUgbW9yZSBsb2NhbCBt b2R1bGVzIGZvciANCj4+Pj4+IHZhbGlkYXRpb24gYW5kIG9uZSBtb3JlIGxldmVsIG9mIGluZGly ZWN0aW9uIHRvIHNlZSB3aGF0IHdlIGFyZSANCj4+Pj4+IHJlYWxseSBhbGxvd2luZyB0byBiZSBj b25maWd1cmVkLg0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBhbSBub3Qgc3VyZSBJIGZ1bGx5 IHVuZGVyc3RhbmQgeW91ciBjb21tZW50L3F1ZXN0aW9uIG9uIA0KPj4+Pj4+IGJmZC1jbGllbnQt ZXh0LWNmZy1wYXJtcy9iZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcy4gVGhlIA0KPj4+Pj4+ IHJlYXNvbiB3ZSBoYXZlDQo+Pj4+Pj4gMiBncm91cGluZ3MgaXMgdGhhdCBzb21lIHByb3RvY29s cyBtYXkgZGVjaWRlIHRvIGhhdmUganVzdCB0aGUgDQo+Pj4+Pj4gZW5hYmxlIGxlYWYgYW5kIG90 aGVycyBtYXkgYWxzbyB3YW50IHRoZSBtdWx0aXBsaWVyL3RpbWVyLg0KPj4+Pj4gDQo+Pj4+PiBU aGUgYmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zIGdyb3VwaW5nIHNob3VsZCB1c2UgDQo+Pj4+PiBi ZmQtdHlwZXM6YmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgcmF0aGVyIHRoYW4gDQo+Pj4+ PiBiZmQtdHlwZXM6YmZkLWNsaWVudC1iYXNlLWNmZy1wYXJtcyAtIG5vPyBUaGlzIHdvdWxkIGJl IG1vcmUgDQo+Pj4+PiBvYnZpb3VzIHcvbyB0aGUgY2xpZW50IG1vZHVsZS4NCj4+Pj4+IA0KPj4+ Pj4gVGhhbmtzLA0KPj4+Pj4gQWNlZQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4+IFJlc2hhZC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+ PiBPbiAyMDE3LTA3LTI3LCAzOjA3IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNj by5jb20+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+PiBIaSBSZXNoYWQsDQo+Pj4+Pj4+IFdoeSBk byB3ZSBuZWVkIGEgbmV3IFlBTkcgbW9kZWwgZm9yIGNsaWVudHM/IFdoeSBjYW7igJl0IHRoZXkg anVzdCANCj4+Pj4+Pj4gdXNlIGlldGYtYmZkLXR5cGVzLnlhbmc/IEnigJlkIGxpa2UgdG8gYXZv aWQgdGhlIHVubmVjZXNzYXJ5IA0KPj4+Pj4+PiBsZXZlbHMgb2YgaW5kaXJlY3Rpb24uIEluIGZh Y3QsIGl0IGxvb2tzIHdyb25nIHRvIG1lIHNpbmNlIHRoZSANCj4+Pj4+Pj4gZ3JvdXBpbmcgYmZk LWNsaWVudC1leHQtY2ZnLXBhcm1zIHVzZXMgdGhlIGdyb3VwaW5nIA0KPj4+Pj4+PiBiZmQtZ3Jv dXBpbmctYmFzZS1jZmctcGFybXMgd2hpY2ggb25seSBjb250YWlucyB0aGUgZW5hYmxlZCANCj4+ Pj4+Pj4gbGVhZi4gSSBiZWxpZXZlIHlvdSBtZWFudCB0byB1c2UgYmZkLWdyb3VwaW5nLWNvbW1v bi1jZmctcGFybXMgDQo+Pj4+Pj4+IGluIHRoZSBvdGhlciBuZXcgbW9kZWwuIEhvd2V2ZXIsIEkg ZG9u4oCZdCBzZWUgYW55IHJlYXNvbiB3aHkgDQo+Pj4+Pj4+IGNsaWVudCBzaG91bGRu4oCZdCB1 c2UgdGhpcyBkaXJlY3RseS4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBBY2VlDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBPbiA3LzI1LzE3LCAyOjMzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbiki IA0KPj4+Pj4+PiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+PiAN Cj4+Pj4+Pj4+IEhpIFlpbmd6aGVuLA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgZ3JvdXBpbmcg aXMgYXZhaWxhYmxlIEANCj4+Pj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9qaGFhcy1wZnJjL2ll dGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbg0KPj4+Pj4+Pj4gZy9pZXQNCj4+Pj4+Pj4+ IGYNCj4+Pj4+Pj4+IC0NCj4+Pj4+Pj4+IGINCj4+Pj4+Pj4+IGYNCj4+Pj4+Pj4+IGQNCj4+Pj4+ Pj4+IC0NCj4+Pj4+Pj4+IGMNCj4+Pj4+Pj4+IGxpZW50cy55YW5nDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IElmIHlvdcK5ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBzZW5kIG1lIGFuIGVt YWlsLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4gUmVzaGFkLg0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBPbiAyMDE3LTA3LTIxLCAxMjoyMiBQTSwgIllpbmd6aGVuIFF1IiA8 eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4NCj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4gSGkgUmVzaGFkLA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHN1 bW1hcnkuDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gQm90aCBvc3BmIGFuZCBpc2lzIG1vZGVscyB3 aWxsIG1ha2UgY29ycmVzcG9uZGluZyBjaGFuZ2VzIHdoZW4gDQo+Pj4+Pj4+Pj4gdGhlIG5ldyBC RkQgZ3JvdXBpbmcgaXMgYXZhaWxhYmxlLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoYW5rcywN Cj4+Pj4+Pj4+PiBZaW5nemhlbg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogUmVzaGFkIFJhaG1hbiAocnJhaG1hbikgW21h aWx0bzpycmFobWFuQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAy MCwgMjAxNyA3OjE5IEFNDQo+Pj4+Pj4+Pj4gVG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5v cmc+OyBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4+Pj4gQ2M6IGRyYWZ0LWlldGYtYmZkLXlhbmdA aWV0Zi5vcmc7IA0KPj4+Pj4+Pj4+IGRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+Pj4+ Pj4+Pj4gU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0 DQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gV2UgKEJGRCBhbmQgT1NQRiBZQU5HIGF1dGhvcnMpIGhh ZCBhIGRpc2N1c3Npb24geWVzdGVyZGF5Lg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFRoZSBhZ3Jl ZW1lbnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJlZCwgd2UgDQo+ Pj4+Pj4+Pj4gd2FudCB0byBhZGQgYmFjayB0aGUgYmFzaWMgQkZEIGNvbmZpZyAobXVsdGlwbGll ciArIGludGVydmFscykgDQo+Pj4+Pj4+Pj4gaW4gSUdQIHZpYSBhIGdyb3VwaW5nLg0KPj4+Pj4+ Pj4+IEJGRCB3aWxsIHByb3ZpZGUgdGhhdCBncm91cGluZyBpbiBhIHNwZWNpZmljIFlBTkcgbW9k dWxlLiBJR1AgDQo+Pj4+Pj4+Pj4gQkZEIFlBTkcgd2lsbCBiZSBpbiBhIHNlcGFyYXRlIG1vZHVs ZSAoc2VwYXJhdGUgZnJvbSB0aGUgbWFpbiANCj4+Pj4+Pj4+PiBJR1AgbW9kdWxlKS4NCj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+IFJlc2hhZC4N Cj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBPbiAyMDE3LTA3LTA1LCAxMjoyMSBQTSwgIlJ0Zy1iZmQg b24gYmVoYWxmIG9mIEplZmZyZXkgSGFhcyINCj4+Pj4+Pj4+PiA8cnRnLWJmZC1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBqaGFhc0BwZnJjLm9yZz4gd3JvdGU6DQo+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IFRoYW5rcyBhdXRob3JzIGZvciB0aGUgZWRpdHMgb24gdGhlIEJGRCB5YW5nIG1v ZHVsZS4gIFRoaXMgDQo+Pj4+Pj4+Pj4+IGdldHMgdXMgYSBzaWduaWZpY2FudCBzdGVwIGNsb3Nl ciB0byBhbGlnbm1lbnQgd2l0aCB0aGUgcmVzdCANCj4+Pj4+Pj4+Pj4gb2YgSUVURiBmb3IgbmV0 d29yayBpbnN0YW5jaW5nLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSSdkIGxpa2UgdG8gZW5j b3VyYWdlIHRoZSB3b3JraW5nIGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sgDQo+Pj4+Pj4+Pj4+ IG9uIHRoaXMgaXNzdWUgYW5kIGFsc28gdGhlIGNoYW5nZXMgaW4gdGhlIG1vZHVsZS4NCj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IEFzIG5vdGVkIGluIGFub3RoZXIgdGhyZWFkLCB3ZSBzdGlsbCBo YXZlIHRvIGZpZ3VyZSBvdXQgaG93IA0KPj4+Pj4+Pj4+PiB0byBkZWFsIHdpdGggYWNjb21tb2Rh dGluZyBpbnRlcmFjdGlvbiBvZiB0aGUgQkZEIHlhbmcgbW9kdWxlIA0KPj4+Pj4+Pj4+PiB3aXRo IGNsaWVudCBwcm90b2NvbHMuDQo+Pj4+Pj4+Pj4+IEZvcg0KPj4+Pj4+Pj4+PiBleGFtcGxlLCB0 aGUgSUdQcy4gIEluIHBhcnRpY3VsYXIsIGhvdyBkbyB5b3UgY29uZmlndXJlIHRoZSANCj4+Pj4+ Pj4+Pj4gcHJvcGVydGllcyBvZiB0aGUgQkZEIHNlc3Npb25zIHRoYXQgbWF5IGJlIGR5bmFtaWNh bGx5IA0KPj4+Pj4+Pj4+PiBpbnN0YW50aWF0ZWQgYmFzZWQgb24gY29udHJvbCBwcm90b2NvbCBh Y3Rpdml0eT8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IC0tIEplZmYNCj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IE9uIEZyaSwgSnVuIDMwLCAyMDE3IGF0IDEyOjU1OjU5UE0gLTA3MDAsIA0KPj4+ Pj4+Pj4+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIA0KPj4+Pj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz Lg0KPj4+Pj4+Pj4+Pj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQmlkaXJlY3Rp b25hbCBGb3J3YXJkaW5nIA0KPj4+Pj4+Pj4+Pj4gRGV0ZWN0aW9uIG9mIHRoZSBJRVRGLg0KPj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRh IE1vZGVsIGZvciBCaWRpcmVjdGlvbmFsDQo+Pj4+Pj4+Pj4+PiBGb3J3YXJkaW5nDQo+Pj4+Pj4+ Pj4+PiBEZXRlY3Rpb24gKEJGRCkNCj4+Pj4+Pj4+Pj4+ICAgICAgICBBdXRob3JzICAgICAgICAg OiBSZXNoYWQgUmFobWFuDQo+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgTGlh bnNodSBaaGVuZw0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIE1haGVzaCBK ZXRoYW5hbmRhbmkNCj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBTYW50b3No IFBhbGxhZ2F0dGkNCj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE1p cnNreQ0KPj4+Pj4+Pj4+Pj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYmZkLXlhbmct MDYudHh0DQo+Pj4+Pj4+Pj4+PiAJUGFnZXMgICAgICAgICAgIDogNTkNCj4+Pj4+Pj4+Pj4+IAlE YXRlICAgICAgICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEFi c3RyYWN0Og0KPj4+Pj4+Pj4+Pj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEg bW9kZWwgdGhhdCBjYW4gYmUgdXNlZCANCj4+Pj4+Pj4+Pj4+IHRvIGNvbmZpZ3VyZQ0KPj4+Pj4+ Pj4+Pj4gICBhbmQgbWFuYWdlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJG RCkuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+ Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZk LXlhbmcvDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVk IHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgDQo+Pj4+Pj4+Pj4+PiB0aW1lIG9mIHN1Ym1pc3Npb24gIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSANCj4+Pj4+Pj4+Pj4+IGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+Pj4+Pj4+Pj4gZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4gDQo+Pj4gDQo+PiANCj4gDQoNCk1haGVzaCBK ZXRoYW5hbmRhbmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQoNCg0KDQo= --_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_ Content-Type: application/octet-stream; name="ietf-ospf-bfd.tree" Content-Description: ietf-ospf-bfd.tree Content-Disposition: attachment; filename="ietf-ospf-bfd.tree"; size=552; creation-date="Sun, 30 Jul 2017 17:10:12 GMT"; modification-date="Sun, 30 Jul 2017 17:10:12 GMT" Content-Transfer-Encoding: base64 bW9kdWxlOiBpZXRmLW9zcGYtYmZkCiAgYXVnbWVudCAvcnQ6cm91dGluZy9ydDpjb250cm9sLXBs YW5lLXByb3RvY29scy9ydDpjb250cm9sLXBsYW5lLXByb3RvY29sL29zcGY6b3NwZi9vc3BmOmlu c3RhbmNlL29zcGY6YXJlYXMvb3NwZjphcmVhL29zcGY6aW50ZXJmYWNlcy9vc3BmOmludGVyZmFj ZToKICAgICstLXJ3IGJmZAogICAgICAgKy0tcncgZW5hYmxlPyAgICAgICAgICAgICAgICAgICAg IGJvb2xlYW4KICAgICAgICstLXJ3IGxvY2FsLW11bHRpcGxpZXI/ICAgICAgICAgICBtdWx0aXBs aWVyCiAgICAgICArLS1ydyAoaW50ZXJ2YWwtY29uZmlnLXR5cGUpPwogICAgICAgICAgKy0tOih0 eC1yeC1pbnRlcnZhbHMpCiAgICAgICAgICB8ICArLS1ydyBkZXNpcmVkLW1pbi10eC1pbnRlcnZh bCAgICAgdWludDMyCiAgICAgICAgICB8ICArLS1ydyByZXF1aXJlZC1taW4tcngtaW50ZXJ2YWwg ICAgdWludDMyCiAgICAgICAgICArLS06KHNpbmdsZS1pbnRlcnZhbCkKICAgICAgICAgICAgICst LXJ3IG1pbi1pbnRlcnZhbCAgICAgICAgICAgICAgICB1aW50MzIK --_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_ Content-Type: application/octet-stream; name="ietf-ospf-bfd.yang" Content-Description: ietf-ospf-bfd.yang Content-Disposition: attachment; filename="ietf-ospf-bfd.yang"; size=2413; creation-date="Sun, 30 Jul 2017 17:10:12 GMT"; modification-date="Sun, 30 Jul 2017 17:10:12 GMT" Content-Transfer-Encoding: base64 bW9kdWxlIGlldGYtb3NwZi1iZmQgewogIG5hbWVzcGFjZSAidXJuOmlldGY6cGFyYW1zOnhtbDpu czp5YW5nOmlldGYtb3NwZi1iZmQiOwoKICBwcmVmaXggb3NwZi1iZmQ7CgogIGltcG9ydCBpZXRm LXJvdXRpbmcgewogICAgcHJlZml4ICJydCI7CiAgfQogIGltcG9ydCBpZXRmLW9zcGYgewogICAg cHJlZml4ICJvc3BmIjsKICB9CgogIGltcG9ydCBpZXRmLWJmZC10eXBlcyB7CiAgICBwcmVmaXgg ImJmZC10eXBlcyI7CiAgfQoKICBvcmdhbml6YXRpb24KICAgICAgIklFVEYgT1NQRiAtIE9TUEYg V29ya2luZyBHcm91cCI7CgogIGNvbnRhY3QKICAgICAiV0cgV2ViOiAgIDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvd2cvb3NwZi8+CiAgICAgIFdHIExpc3Q6ICA8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+ CgogICAgICBFZGl0b3I6ICAgRGVyZWsgWWV1bmcKICAgICAgICAgICAgICAgIDxtYWlsdG86ZGVy ZWtAYXJyY3VzLmNvbT4KICAgICAgQXV0aG9yOiAgIERlcmVrIFlldW5nCiAgICAgICAgICAgICAg ICA8bWFpbHRvOmRlcmVrQGFycmN1cy5jb20+CiAgICAgIEF1dGhvcjogICBZaW5nemhlbiBRdQog ICAgICAgICAgICAgICAgPG1haWx0bzp5aXF1QGNpc2NvLmNvbT4KICAgICAgQXV0aG9yOiAgIEFj ZWUgTGluZGVtCiAgICAgICAgICAgICAgICA8bWFpbHRvOmFjZWVAY2lzY28uY29tPgogICAgICBB dXRob3I6ICAgSmVmZnJleSBaaGFuZwogICAgICAgICAgICAgICAgPG1haWx0bzp6emhhbmdAanVu aXBlci5uZXQ+CiAgICAgIEF1dGhvcjogICBJbmctV2hlciBDaGVuCiAgICAgICAgICAgICAgICA8 bWFpbHRvOmljaGVuQGt1YXRyb3RlY2guY29tPiI7CgoKICBkZXNjcmlwdGlvbgogICAgIlRoaXMg WUFORyBtb2R1bGUgZGVmaW5lcyB0aGUgZ2VuZXJpYyBjb25maWd1cmF0aW9uCiAgICAgYW5kIG9w ZXJhdGlvbmFsIHN0YXRlIGZvciBPU1BGIEJGRCwgd2hpY2ggaXMgY29tbW9uCiAgICAgYWNyb3Nz IGFsbCBvZiB0aGUgdmVuZG9yIGltcGxlbWVudGF0aW9ucy4gSXQgaXMKICAgICBpbnRlbmRlZCB0 aGF0IHRoZSBtb2R1bGUgd2lsbCBiZSBleHRlbmRlZCBieSB2ZW5kb3JzIHRvCiAgICAgZGVmaW5l IHZlbmRvci1zcGVjaWZpYyBPU1BGIEJGRCBjb25maWd1cmF0aW9uCiAgICAgYW5kIG9wZXJhdGlv bmFsIHBhcmFtZXRlcnMgYW5kIHBvbGljaWVzLgoKICAgICBUZXJtcyBhbmQgQWNyb255bXMKCiAg ICAgT1NQRiAob3NwZik6IE9wZW4gU2hvcnRlc3QgUGF0aCBGaXJzdAoKICAgICBJUCAoaXApOiBJ bnRlcm5ldCBQcm90b2NvbAoKICAgICBJUHY0IChpcHY0KTpJbnRlcm5ldCBQcm90b2NvbCBWZXJz aW9uIDQKCiAgICAgSVB2NiAoaXB2Nik6IEludGVybmV0IFByb3RvY29sIFZlcnNpb24gNgogICAg IjsKCiAgcmV2aXNpb24gMjAxNy0wNy0zMCB7CiAgICBkZXNjcmlwdGlvbgogICAgICAiSW5pdGlh bCByZXZpc2lvbi4iOwogICAgcmVmZXJlbmNlCiAgICAgICJSRkMgWFhYWDogQSBZQU5HIERhdGEg TW9kZWwgZm9yIE9TUEYgQkZELiI7ICAKICB9CgogIGZlYXR1cmUgYmZkLXByb3RvY29sLXBhcm1z IHsKICAgIGRlc2NyaXB0aW9uCiAgICAgICJPU1BGIEJGRCBwcm90b2NvbCBzcGVjaWZpYyBwYXJh bWV0ZXJzIHN1cHBvcnQuIjsKICB9CgogIC8qIENvbmZpZ3VyYXRpb24gKi8KCiAgYXVnbWVudCAi L3J0OnJvdXRpbmcvcnQ6Y29udHJvbC1wbGFuZS1wcm90b2NvbHMvIgogICAgICAgICsgInJ0OmNv bnRyb2wtcGxhbmUtcHJvdG9jb2wvb3NwZjpvc3BmL29zcGY6aW5zdGFuY2UvIgogICAgICAgICsg Im9zcGY6YXJlYXMvb3NwZjphcmVhL29zcGY6aW50ZXJmYWNlcy9vc3BmOmludGVyZmFjZSIgewog ICAgd2hlbiAiLi4vLi4vLi4vLi4vLi4vLi4vcnQ6dHlwZSA9ICdvc3BmOm9zcGZ2Micgb3IgIgog ICAgICAgKyAiLi4vLi4vLi4vLi4vLi4vLi4vcnQ6dHlwZSA9ICdvc3BmOm9zcGZ2MyciIHsKICAg ICAgZGVzY3JpcHRpb24KICAgICAgIlRoaXMgYXVnbWVudHMgdGhlIE9TUEYgcm91dGluZyBwcm90 b2NvbCB3aGVuIHVzZWQiOwogICAgfQogICAgZGVzY3JpcHRpb24KICAgICAiVGhpcyBhdWdtZW50 cyBPU1BGIHByb3RvY29sIGNvbmZpZ3VyYXRpb24KICAgICAgd2l0aCBCRkQuIjsKCiAgICBjb250 YWluZXIgYmZkIHsKICAgICAgZGVzY3JpcHRpb24gIkJGRCBjb25maWd1cmF0aW9uLiI7CiAgICAg IGxlYWYgZW5hYmxlIHsKICAgICAgICB0eXBlIGJvb2xlYW47CiAgICAgICAgZGVmYXVsdCBmYWxz ZTsKICAgICAgICBkZXNjcmlwdGlvbgogICAgICAgICAgIlRydWUgaWYgQkZEIGlzIGVuYWJsZWQg Zm9yIHRoZSBPU1BGIGludGVyZmFjZS4iOwogICAgICB9CiAgICAgIHVzZXMgYmZkLXR5cGVzOmNs aWVudC1jZmctcGFybXMgewogICAgICAgIGlmLWZlYXR1cmUgYmZkLXByb3RvY29sLXBhcm1zOwog ICAgICB9CiAgICB9CiAgfQp9Cg== --_003_594D005A3CB0724DB547CF3E9A9E810B5388E1dfweml501mbx_-- From nobody Sun Jul 30 19:35:22 2017 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 8512A131D24 for ; Sun, 30 Jul 2017 19:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kt42kjLShHPR for ; Sun, 30 Jul 2017 19:35:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAB4131D1E for ; Sun, 30 Jul 2017 19:35:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2017; q=dns/txt; s=iport; t=1501468517; x=1502678117; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2DUesQaoE8hRE6vDelbb2afpaIWTQILoa3lYEFvaC5M=; b=egHVuDnTFbJTCvrdBs0rI4jDRD9FpZ++uPrh/My1QXHSWsf3p7D9KlvY 7qMbmWueqFs1YBuwBU8sZkminIVFrlPJAou3l+YZG1H6wP2dgnEMaxQKl JqDJeuWIMJ9KeepkBSeLrcMEdJvzY3IFvfMrKsbl6M4vHQp574UFBOGmp M=; X-IronPort-AV: E=Sophos;i="5.40,439,1496102400"; d="scan'208";a="276570027" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2017 02:35:17 +0000 Received: from [10.24.106.186] ([10.24.106.186]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v6V2ZGEE022885; Mon, 31 Jul 2017 02:35:16 GMT Subject: Fwd: I-D Action: draft-chen-bfd-unsolicited-01.txt References: <150146797084.17672.9122177940139456062@ietfa.amsl.com> To: rtg-bfd@ietf.org Cc: Enke Chen , Naiming Shen , Robert Raszuk From: Enke Chen X-Forwarded-Message-Id: <150146797084.17672.9122177940139456062@ietfa.amsl.com> Message-ID: <74377bb1-9c94-2a7b-a4a0-b1b75db99038@cisco.com> Date: Sun, 30 Jul 2017 19:35:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <150146797084.17672.9122177940139456062@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 02:35:19 -0000 Hi, Folks: Please let us know if you have any comments on the draft. Thanks. -- Enke -------- Forwarded Message -------- Subject: I-D Action: draft-chen-bfd-unsolicited-01.txt Date: Sun, 30 Jul 2017 19:26:10 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unsolicited BFD for Sessionless Applications Authors : Enke Chen Naiming Shen Robert Raszuk Filename : draft-chen-bfd-unsolicited-01.txt Pages : 6 Date : 2017-07-30 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-chen-bfd-unsolicited/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-chen-bfd-unsolicited-01 https://datatracker.ietf.org/doc/html/draft-chen-bfd-unsolicited-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-chen-bfd-unsolicited-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Jul 30 21:42:47 2017 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 E0512128C81; Sun, 30 Jul 2017 21:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 AvGBPL9xG5qB; Sun, 30 Jul 2017 21:42:44 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 DFD72120724; Sun, 30 Jul 2017 21:42:43 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id y192so1038178pgd.1; Sun, 30 Jul 2017 21:42:43 -0700 (PDT) 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=SdrefsHuyOsMKBDWplwYonAM0Kpf1EgbouiUvRHshfY=; b=RlBVFJPYCfw+/XYC6+K1xT4ypJHuGQOlsGACwQnfJ7lFKWxzrLhoojTA8XacjbcbOz CrAHU/uwcnWD1SklhoE5tr0LlygymgRRoILrBWSzOc/jcGL9788nnkQ7rvJ+gQxoOni4 p32JLmK/S5KVUNoeuQDNSqizE6DQmVIcBz0FfzCLFIk9Fls5dK+fGqjlz2BcE7ziGAet 50GWxjWEkCqa+cs45LUodkKIoZrKCYkYvtowWru7jFhOpp4CYInJ0CDvDDBOO+M3Wh71 HWRd0v71/9JVxqKG+c7IfuaEO+sNQJ3Y3F8/S893CkCcLz01FM5zIaQ5RUOop245qJbb Fxng== 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=SdrefsHuyOsMKBDWplwYonAM0Kpf1EgbouiUvRHshfY=; b=SL5MhWmfnJt/1VzYbjhEGi+gvSP5uYPB0JcH5vk2SfpkKbQ+EbF/UfRTCU8v8BstVZ IbcAEABLeJyQsjk78xCrwIXyhOzBC/EFACHMzfBD2AxripGLZltpLquyKwumS6YURifF hLY99uzuP1Unfzty03GE/vFAQzeTvIMdKexGmbOTwSI7JLTqn53VxGjMyXwopU97qryS dNiSfhboYBzJ6f1mBcFbYpD6yPHU0N8ygX7OzmdY+hN6mamYyV8bQyP82ozD4hbLuozC syKH34n7JOKrf5adIe3mi2ZkI102+2cKXDWWNDu1PV2o2hJK38YS/VgpaKlP0ANWDORq 59Pg== X-Gm-Message-State: AIVw111lhlLbMzrB0Hbl619cyzMRbxdBsTEhHsQYNmW8zaEmwnACt4f9 APVWilVE4/sRLg== X-Received: by 10.84.241.207 with SMTP id t15mr16249647plm.347.1501476163284; Sun, 30 Jul 2017 21:42:43 -0700 (PDT) Received: from ?IPv6:2602:306:cf77:df90:e4b7:a49c:e1e5:4052? ([2602:306:cf77:df90:e4b7:a49c:e1e5:4052]) by smtp.gmail.com with ESMTPSA id r207sm50270728pfr.106.2017.07.30.21.42.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 30 Jul 2017 21:42:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> Date: Sun, 30 Jul 2017 21:42:41 -0700 Cc: "Acee Lindem (acee)" , Reshad Rahman , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> To: Yingzhen Qu X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 04:42:46 -0000 Yingzhen, Overall the model looks good to me. I notice that you decided to (re)define the enable flag in the model. Is = that intentional? You are aware that there is another grouping called = client-base-cfg-parms that defines the enabled flag. I am not a = particular fan of this split, but I am told that some client protocols = just need the enable flag without the rest of the parameters of = client-cfg-parms. If the split is confusing, we can collapse the enabled = flag into client-cfg-parms. Thanks. > On Jul 30, 2017, at 10:14 AM, Yingzhen Qu = wrote: >=20 > Hi all, >=20 > Please see attached ospf bfd module. Base ospf module also needs to be = updated to remove the bfd enable leaf. ISIS model need to do the same = change, ietf-isis-bfd.yang will look the same as ietf-ospf-bfd.yang. >=20 > Please let me know your commetns. >=20 > Thanks, > Yingzhen >=20 > -----Original Message----- > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 > Sent: Friday, July 28, 2017 2:25 PM > To: Acee Lindem (acee) > Cc: Reshad Rahman ; Yingzhen Qu = ; Jeffrey Haas ; = rtg-bfd@ietf.org; draft-ietf-bfd-yang@ietf.org; = draft-ietf-ospf-yang@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >=20 > Would it not be better to call bfd-grouping-base-cfg-parms something = like bfd-grouping-client-cfg-params or more simply client-cfg-params. We = know it is a grouping and we know it is a bfd grouping. Why repeat? >=20 >> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) = wrote: >>=20 >> Hi Reshad, >>=20 >> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms = groupings. >> Fewer similar grouping and modules will be better ;^) >>=20 >> Thanks, >> Acee >>=20 >> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" = wrote: >>=20 >>> Hi Acee, >>>=20 >>> What I see @ >>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf >>> -bfd- >>> t >>> ypes.yang: >>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this = grouping=20 >>> is defined twice, this will be fixed when I get rid of=20 >>> ietf-bfd-clients.yang >>> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>=20 >>> Let me get rid of the client module and have everything in the types=20= >>> module. >>>=20 >>> I am not sure why you=E2=80=99re not seeing something different. >>>=20 >>> Regards, >>> Reshad. >>>=20 >>>=20 >>>=20 >>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" wrote: >>>=20 >>>> Hi Reshad, >>>>=20 >>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" = wrote: >>>>=20 >>>>> Hi Acee, >>>>>=20 >>>>> 1) I=E2=80=99ll see if others chime in on this but I am fine with = having=20 >>>>> the client grouping in ietf-bfd-types.yang. >>>>> 2) bfd-grouping-common-cfg-parms has much more than just the=20 >>>>> multiplier/timers that the IGPs need. It also has BFD specific=20 >>>>> stuff (demand-mode, BFD auth) which IMO has no business outside of = BFD. >>>>=20 >>>> Agreed.=20 >>>>=20 >>>>=20 >>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>=20 >>>> Perhaps, the addition of multiplier/timers to=20 >>>> bfd-grouping-base-cfg-parms isn=E2=80=99t pushed to GitHub yet. = This version=20 >>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet >>>> f-bfd >>>> - >>>> t >>>> ypes.yang only has the enabled leaf. >>>>=20 >>>>=20 >>>> Thanks, >>>> Acee >>>>=20 >>>>=20 >>>>>=20 >>>>> Regards, >>>>> Reshad. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" = wrote: >>>>>=20 >>>>>> Hi Reshad, >>>>>>=20 >>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" = >>>>>> wrote: >>>>>>=20 >>>>>>> Hi Acee, >>>>>>>=20 >>>>>>> When we met we agreed to have a new model for clients. = Afterwards=20 >>>>>>> I decided to create a new types module, and still went ahead = with=20 >>>>>>> the clients module. I am fine with having everything in the = types=20 >>>>>>> module (no client module). >>>>>>=20 >>>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99t = see that=20 >>>>>> putting the client config params in wrappers provides any = benefit.=20 >>>>>> As for detriments, it requires more one more local modules for=20 >>>>>> validation and one more level of indirection to see what we are=20= >>>>>> really allowing to be configured. >>>>>>=20 >>>>>>>=20 >>>>>>> I am not sure I fully understand your comment/question on=20 >>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The=20 >>>>>>> reason we have >>>>>>> 2 groupings is that some protocols may decide to have just the=20= >>>>>>> enable leaf and others may also want the multiplier/timer. >>>>>>=20 >>>>>> The bfd-client-ext-cfg-parms grouping should use=20 >>>>>> bfd-types:bfd-grouping-common-cfg-parms rather than=20 >>>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more=20 >>>>>> obvious w/o the client module. >>>>>>=20 >>>>>> Thanks, >>>>>> Acee >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Reshad. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" = wrote: >>>>>>>=20 >>>>>>>> Hi Reshad, >>>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t = they just=20 >>>>>>>> use ietf-bfd-types.yang? I=E2=80=99d like to avoid the = unnecessary=20 >>>>>>>> levels of indirection. In fact, it looks wrong to me since the=20= >>>>>>>> grouping bfd-client-ext-cfg-parms uses the grouping=20 >>>>>>>> bfd-grouping-base-cfg-parms which only contains the enabled=20 >>>>>>>> leaf. I believe you meant to use bfd-grouping-common-cfg-parms=20= >>>>>>>> in the other new model. However, I don=E2=80=99t see any reason = why=20 >>>>>>>> client shouldn=E2=80=99t use this directly. >>>>>>>> Thanks, >>>>>>>> Acee >>>>>>>>=20 >>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)"=20 >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Yingzhen, >>>>>>>>>=20 >>>>>>>>> The grouping is available @ >>>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yan >>>>>>>>> g/iet >>>>>>>>> f >>>>>>>>> - >>>>>>>>> b >>>>>>>>> f >>>>>>>>> d >>>>>>>>> - >>>>>>>>> c >>>>>>>>> lients.yang >>>>>>>>>=20 >>>>>>>>> If you=C2=B9d like changes to the grouping, send me an email. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Reshad. >>>>>>>>>=20 >>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" = >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Reshad, >>>>>>>>>>=20 >>>>>>>>>> Thanks for the summary. >>>>>>>>>>=20 >>>>>>>>>> Both ospf and isis models will make corresponding changes = when=20 >>>>>>>>>> the new BFD grouping is available. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Yingzhen >>>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org;=20 >>>>>>>>>> draft-ietf-ospf-yang@ietf.org >>>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>=20 >>>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>=20 >>>>>>>>>> The agreement is that since IGP peers are auto-discovered, we=20= >>>>>>>>>> want to add back the basic BFD config (multiplier + = intervals)=20 >>>>>>>>>> in IGP via a grouping. >>>>>>>>>> BFD will provide that grouping in a specific YANG module. IGP=20= >>>>>>>>>> BFD YANG will be in a separate module (separate from the main=20= >>>>>>>>>> IGP module). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Reshad. >>>>>>>>>>=20 >>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Thanks authors for the edits on the BFD yang module. This=20= >>>>>>>>>>> gets us a significant step closer to alignment with the rest=20= >>>>>>>>>>> of IETF for network instancing. >>>>>>>>>>>=20 >>>>>>>>>>> I'd like to encourage the working group to provide feedback=20= >>>>>>>>>>> on this issue and also the changes in the module. >>>>>>>>>>>=20 >>>>>>>>>>> As noted in another thread, we still have to figure out how=20= >>>>>>>>>>> to deal with accommodating interaction of the BFD yang = module=20 >>>>>>>>>>> with client protocols. >>>>>>>>>>> For >>>>>>>>>>> example, the IGPs. In particular, how do you configure the=20= >>>>>>>>>>> properties of the BFD sessions that may be dynamically=20 >>>>>>>>>>> instantiated based on control protocol activity? >>>>>>>>>>>=20 >>>>>>>>>>> -- Jeff >>>>>>>>>>>=20 >>>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700,=20 >>>>>>>>>>> internet-drafts@ietf.org >>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>>>>>> Internet-Drafts directories. >>>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding=20= >>>>>>>>>>>> Detection of the IETF. >>>>>>>>>>>>=20 >>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>> Forwarding >>>>>>>>>>>> Detection (BFD) >>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>> Pages : 59 >>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>=20 >>>>>>>>>>>> Abstract: >>>>>>>>>>>> This document defines a YANG data model that can be used=20= >>>>>>>>>>>> to configure >>>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>=20 >>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>=20 >>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Please note that it may take a couple of minutes from the=20= >>>>>>>>>>>> time of submission until the htmlized version and diff are=20= >>>>>>>>>>>> available at tools.ietf.org. >>>>>>>>>>>>=20 >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 > Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jul 31 10:05:51 2017 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 6D7B61326C7; Mon, 31 Jul 2017 10:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 F6Ndun2nY78Q; Mon, 31 Jul 2017 10:05:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5171326D4; Mon, 31 Jul 2017 10:05:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 274881E380; Mon, 31 Jul 2017 13:05:51 -0400 (EDT) Date: Mon, 31 Jul 2017 13:05:50 -0400 From: Jeffrey Haas To: Mahesh Jethanandani Cc: Yingzhen Qu , "Acee Lindem (acee)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , Reshad Rahman Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Message-ID: <20170731170550.GO24942@pfrc.org> References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 17:05:49 -0000 On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: > The changes are done and pushed to GitHub. Use the grouping client-cfg-parms. Question: For implementations that use Echo mode, is that something the protocol client configuration impacts or is it chosen by the system automatically? -- jeff From nobody Mon Jul 31 10:06:47 2017 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 66E541326AE; Mon, 31 Jul 2017 10:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 NQwv2l9YqQNY; Mon, 31 Jul 2017 10:06:45 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E8ACA1326D7; Mon, 31 Jul 2017 10:06:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6DFDC1E380; Mon, 31 Jul 2017 13:06:54 -0400 (EDT) Date: Mon, 31 Jul 2017 13:06:54 -0400 From: Jeffrey Haas To: Yingzhen Qu Cc: Mahesh Jethanandani , "Acee Lindem (acee)" , Reshad Rahman , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Message-ID: <20170731170654.GP24942@pfrc.org> References: <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 17:06:46 -0000 On Sun, Jul 30, 2017 at 05:14:28PM +0000, Yingzhen Qu wrote: > Please see attached ospf bfd module. Base ospf module also needs to be updated to remove the bfd enable leaf. ISIS model need to do the same change, ietf-isis-bfd.yang will look the same as ietf-ospf-bfd.yang. > > Please let me know your commetns. This looks fine to me. I'm even fine with an enable leaf, although disable is semantically equivalent to removing the configuration. -- Jeff From nobody Mon Jul 31 10:12:55 2017 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 91E221326E5 for ; Mon, 31 Jul 2017 10:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 EGeRjLpBgALA for ; Mon, 31 Jul 2017 10:12:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 976B41326C3 for ; Mon, 31 Jul 2017 10:12:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1C7661E380; Mon, 31 Jul 2017 13:13:06 -0400 (EDT) Date: Mon, 31 Jul 2017 13:13:06 -0400 From: Jeffrey Haas To: "Carlos Pignataro (cpignata)" Cc: Mach Chen , "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" Subject: Re: A question about RFC5884 Message-ID: <20170731171305.GQ24942@pfrc.org> References: <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com> <6263E0A6-EE08-43BB-A845-BCF5788D2A14@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.22 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, 31 Jul 2017 17:12:54 -0000 On Tue, Jul 18, 2017 at 10:25:38AM +0000, Carlos Pignataro (cpignata) wrote: > I had not suggested it, but I think that idea has merit. If there are enough updates needed to the spec based on additional running-code learning, or ambiguities that are causing interoperable confusion, the net of a -biz can be positive. > > When that same idea crossed my mind, I thought that the question should be part of a larger consideration from the chairs of maturity, pipeline, and advancement of BFD specs, and not taken in isolation. 5884 seems to require localized fixes only. > Thus far my reading of the thread is that when you pedantically consider each of the involved specs, we're not to the point where we'd need to update the procedures in 5884. The issues seem to occur if you're willing to "read between the lines". As a reminder, when the RFCs appear to be broken or unclear, the Errata feature available in the datatracker can allow issues to be filed. These issues are considered when it's time to update the RFC. -- Jeff From nobody Mon Jul 31 10:15:25 2017 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 9969F1326EC for ; Mon, 31 Jul 2017 10:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 6uzwAP0Kk7PX for ; Mon, 31 Jul 2017 10:15:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 061C31326D7 for ; Mon, 31 Jul 2017 10:15:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8FCF81E380; Mon, 31 Jul 2017 13:15:34 -0400 (EDT) Date: Mon, 31 Jul 2017 13:15:34 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: WGLC for BFD Multipoint documents (ending July 14, 2017) Message-ID: <20170731171534.GR24942@pfrc.org> References: <20170619193929.GE22146@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170619193929.GE22146@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 17:15:23 -0000 Working Group, We've received some good feedback for Santosh to include in the next revision of the documents and likely have enough discussion to move them forward in the publication process. At this point, we are waiting for targeted review from ALU/Nokia who actually has an implementation of the base multipoint spec. Once we've received that review, we can continue in our deliberations. -- Jeff On Mon, Jun 19, 2017 at 03:39:29PM -0400, Jeffrey Haas wrote: > Working Group, > > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-10 > https://tools.ietf.org/html/draft-ietf-bfd-multipoint-active-tail-04 > > > The BFD Multipoint documents have been stable for some time. Prior > discussion at meetings has suggested we have an implementation for the main > protocol component. Also per prior discussions, we split the active-tail > component of the original multipoint document to permit implementors to not > have to worry about implementing active-tail procedures if they weren't > interested in that feature. > > We are starting an extended last call on these documents. The WGLC will > conclude on July 14. This provides ample time for list discussion. If > necessary, the IETF-99 meeting may provide for opportunities to close any > contentious technical points. (BFD is not currently scheduled to meet.) > > One item I would like to kick off is the document status of the active-tail > mechanism. At this time, no one has implemented it that I am aware of. > Discussion with our AD suggests that publishing the document with > Experimental status may be reasonable to preserve the work that went into > the proposal. > > -- Jeff From nobody Mon Jul 31 10:27:06 2017 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 1B548132703; Mon, 31 Jul 2017 10:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 b_cuXafRC8Mg; Mon, 31 Jul 2017 10:26:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6CC13270E; Mon, 31 Jul 2017 10:26:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLQ59289; Mon, 31 Jul 2017 17:26:47 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 31 Jul 2017 18:26:45 +0100 Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Mon, 31 Jul 2017 10:26:44 -0700 From: Yingzhen Qu To: Mahesh Jethanandani CC: "Acee Lindem (acee)" , Reshad Rahman , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: RE: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAbE+gIACaDNQgAE2oID//4wLQA== Date: Mon, 31 Jul 2017 17:26:43 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B538BE7@dfweml501-mbx> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> In-Reply-To: <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.597F6858.02D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f51b081ef726120ca0b85531009b970e Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 17:26:54 -0000 SGkgTWFoZXNoLA0KDQpGb3IgdGhlIGVuYWJsZSBmbGFnLCBJJ2QgcHJlZmVyIHRvIGhhdmUgaXQg ZGVmaW5lZCBkaXJlY3RseSBpbiBvc3BmIGluc3RlYWQgb2YgdXNpbmcgYSBncm91cGluZyBmcm9t IEJGRC4gSSdtIG5vdCBzdXJlIGhvdyB1c2VmdWwgdGhpcyBncm91cGluZyBpcywgYW0gSSBtaXNz aW5nIHNvbWV0aGluZz8NCg0KVGhhbmtzLA0KWWluZ3poZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IE1haGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5kYW5p QGdtYWlsLmNvbV0gDQpTZW50OiBTdW5kYXksIEp1bHkgMzAsIDIwMTcgOTo0MyBQTQ0KVG86IFlp bmd6aGVuIFF1IDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPg0KQ2M6IEFjZWUgTGluZGVtIChhY2Vl KSA8YWNlZUBjaXNjby5jb20+OyBSZXNoYWQgUmFobWFuIDxycmFobWFuQGNpc2NvLmNvbT47IEpl ZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+OyBydGctYmZkQGlldGYub3JnOyBkcmFmdC1pZXRm LWJmZC15YW5nQGlldGYub3JnOyBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQoNCllpbmd6aGVu LA0KDQpPdmVyYWxsIHRoZSBtb2RlbCBsb29rcyBnb29kIHRvIG1lLg0KDQpJIG5vdGljZSB0aGF0 IHlvdSBkZWNpZGVkIHRvIChyZSlkZWZpbmUgdGhlIGVuYWJsZSBmbGFnIGluIHRoZSBtb2RlbC4g SXMgdGhhdCBpbnRlbnRpb25hbD8NCg0KWW91IGFyZSBhd2FyZSB0aGF0IHRoZXJlIGlzIGFub3Ro ZXIgZ3JvdXBpbmcgY2FsbGVkIGNsaWVudC1iYXNlLWNmZy1wYXJtcyB0aGF0IGRlZmluZXMgdGhl IGVuYWJsZWQgZmxhZy4gSSBhbSBub3QgYSBwYXJ0aWN1bGFyIGZhbiBvZiB0aGlzIHNwbGl0LCBi dXQgSSBhbSB0b2xkIHRoYXQgc29tZSBjbGllbnQgcHJvdG9jb2xzIGp1c3QgbmVlZCB0aGUgZW5h YmxlIGZsYWcgd2l0aG91dCB0aGUgcmVzdCBvZiB0aGUgcGFyYW1ldGVycyBvZiBjbGllbnQtY2Zn LXBhcm1zLiBJZiB0aGUgc3BsaXQgaXMgY29uZnVzaW5nLCB3ZSBjYW4gY29sbGFwc2UgdGhlIGVu YWJsZWQgZmxhZyBpbnRvIGNsaWVudC1jZmctcGFybXMuDQoNClRoYW5rcy4NCg0KPiBPbiBKdWwg MzAsIDIwMTcsIGF0IDEwOjE0IEFNLCBZaW5nemhlbiBRdSA8eWluZ3poZW4ucXVAaHVhd2VpLmNv bT4gd3JvdGU6DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBQbGVhc2Ugc2VlIGF0dGFjaGVkIG9zcGYg YmZkIG1vZHVsZS4gQmFzZSBvc3BmIG1vZHVsZSBhbHNvIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8g cmVtb3ZlIHRoZSBiZmQgZW5hYmxlIGxlYWYuIElTSVMgbW9kZWwgbmVlZCB0byBkbyB0aGUgc2Ft ZSBjaGFuZ2UsIGlldGYtaXNpcy1iZmQueWFuZyB3aWxsIGxvb2sgdGhlIHNhbWUgYXMgaWV0Zi1v c3BmLWJmZC55YW5nLg0KPiANCj4gUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgY29tbWV0bnMuDQo+ IA0KPiBUaGFua3MsDQo+IFlpbmd6aGVuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBNYWhlc2ggSmV0aGFuYW5kYW5pIFttYWlsdG86bWpldGhhbmFuZGFuaUBnbWFp bC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAyOjI1IFBNDQo+IFRvOiBBY2Vl IExpbmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPg0KPiBDYzogUmVzaGFkIFJhaG1hbiA8cnJh aG1hbkBjaXNjby5jb20+OyBZaW5nemhlbiBRdSANCj4gPHlpbmd6aGVuLnF1QGh1YXdlaS5jb20+ OyBKZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPjsgDQo+IHJ0Zy1iZmRAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtYmZkLXlhbmdAaWV0Zi5vcmc7IA0KPiBkcmFmdC1pZXRmLW9zcGYteWFuZ0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50 eHQNCj4gDQo+IFdvdWxkIGl0IG5vdCBiZSBiZXR0ZXIgdG8gY2FsbCBiZmQtZ3JvdXBpbmctYmFz ZS1jZmctcGFybXMgc29tZXRoaW5nIGxpa2UgYmZkLWdyb3VwaW5nLWNsaWVudC1jZmctcGFyYW1z IG9yIG1vcmUgc2ltcGx5IGNsaWVudC1jZmctcGFyYW1zLiBXZSBrbm93IGl0IGlzIGEgZ3JvdXBp bmcgYW5kIHdlIGtub3cgaXQgaXMgYSBiZmQgZ3JvdXBpbmcuIFdoeSByZXBlYXQ/DQo+IA0KPj4g T24gSnVsIDI3LCAyMDE3LCBhdCA3OjM0IFBNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz Y28uY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgUmVzaGFkLA0KPj4gDQo+PiBPayAtIEkgc2VlIG5v dy4gSSB3YXMgbG9va2luZyBhdCB0aGUgd3JvbmcgeHh4eC1iYXNlLWNmZy1wYXJtcyBncm91cGlu Z3MuDQo+PiBGZXdlciBzaW1pbGFyIGdyb3VwaW5nIGFuZCBtb2R1bGVzIHdpbGwgYmUgYmV0dGVy IDteKQ0KPj4gDQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+PiANCj4+IE9uIDcvMjcvMTcsIDk6MDMg UE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiB3cm90ZToN Cj4+IA0KPj4+IEhpIEFjZWUsDQo+Pj4gDQo+Pj4gV2hhdCBJIHNlZSBADQo+Pj4gaHR0cHM6Ly9n aXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9p ZXQNCj4+PiBmDQo+Pj4gLWJmZC0NCj4+PiB0DQo+Pj4geXBlcy55YW5nOg0KPj4+IDEpIGJmZC1j bGllbnQtYmFzZS1jZmctcGFybXMgaGFzIGxlYWYgZW5hYmxlZCBvbmx5LiBCVFcgdGhpcyANCj4+ PiBncm91cGluZyBpcyBkZWZpbmVkIHR3aWNlLCB0aGlzIHdpbGwgYmUgZml4ZWQgd2hlbiBJIGdl dCByaWQgb2YgDQo+Pj4gaWV0Zi1iZmQtY2xpZW50cy55YW5nDQo+Pj4gMikgYmZkLWdyb3VwaW5n LWJhc2UtY2ZnLXBhcm1zIGhhcyBtdWx0aXBsaWVyL3RpbWVycy4NCj4+PiANCj4+PiBMZXQgbWUg Z2V0IHJpZCBvZiB0aGUgY2xpZW50IG1vZHVsZSBhbmQgaGF2ZSBldmVyeXRoaW5nIGluIHRoZSB0 eXBlcyANCj4+PiBtb2R1bGUuDQo+Pj4gDQo+Pj4gSSBhbSBub3Qgc3VyZSB3aHkgeW914oCZcmUg bm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0KPj4+IA0KPj4+IFJlZ2FyZHMsDQo+Pj4g UmVzaGFkLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDIwMTctMDctMjcsIDM6NDAgUE0sICJB Y2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEhp IFJlc2hhZCwNCj4+Pj4gDQo+Pj4+IE9uIDcvMjcvMTcsIDM6MzUgUE0sICJSZXNoYWQgUmFobWFu IChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28uY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiBIaSBB Y2VlLA0KPj4+Pj4gDQo+Pj4+PiAxKSBJ4oCZbGwgc2VlIGlmIG90aGVycyBjaGltZSBpbiBvbiB0 aGlzIGJ1dCBJIGFtIGZpbmUgd2l0aCBoYXZpbmcgDQo+Pj4+PiB0aGUgY2xpZW50IGdyb3VwaW5n IGluIGlldGYtYmZkLXR5cGVzLnlhbmcuDQo+Pj4+PiAyKSBiZmQtZ3JvdXBpbmctY29tbW9uLWNm Zy1wYXJtcyBoYXMgbXVjaCBtb3JlIHRoYW4ganVzdCB0aGUgDQo+Pj4+PiBtdWx0aXBsaWVyL3Rp bWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYyANCj4+Pj4+ IHN0dWZmIChkZW1hbmQtbW9kZSwgQkZEIGF1dGgpIHdoaWNoIElNTyBoYXMgbm8gYnVzaW5lc3Mg b3V0c2lkZSBvZiBCRkQuDQo+Pj4+IA0KPj4+PiBBZ3JlZWQuIA0KPj4+PiANCj4+Pj4gDQo+Pj4+ PiBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG9ubHkgdGhlIG11bHRpcGxpZXIvdGlt ZXJzLg0KPj4+PiANCj4+Pj4gUGVyaGFwcywgdGhlIGFkZGl0aW9uIG9mIG11bHRpcGxpZXIvdGlt ZXJzIHRvIA0KPj4+PiBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaXNu4oCZdCBwdXNoZWQg dG8gR2l0SHViIHlldC4gVGhpcyANCj4+Pj4gdmVyc2lvbiANCj4+Pj4gaHR0cHM6Ly9naXRodWIu Y29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rlci9zcmMveWFuZy9pZQ0KPj4+ PiB0DQo+Pj4+IGYtYmZkDQo+Pj4+IC0NCj4+Pj4gdA0KPj4+PiB5cGVzLnlhbmcgb25seSBoYXMg dGhlIGVuYWJsZWQgbGVhZi4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IEFjZWUN Cj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gUmVzaGFkLg0KPj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gMjAxNy0wNy0yNywgMzozMCBQTSwgIkFjZWUg TGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IEhp IFJlc2hhZCwNCj4+Pj4+PiANCj4+Pj4+PiBPbiA3LzI3LzE3LCAzOjE5IFBNLCAiUmVzaGFkIFJh aG1hbiAocnJhaG1hbikiIA0KPj4+Pj4+IDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj4+PiB3cm90 ZToNCj4+Pj4+PiANCj4+Pj4+Pj4gSGkgQWNlZSwNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFdoZW4gd2Ug bWV0IHdlIGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiANCj4+Pj4+Pj4g QWZ0ZXJ3YXJkcyBJIGRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwgYW5kIHN0 aWxsIA0KPj4+Pj4+PiB3ZW50IGFoZWFkIHdpdGggdGhlIGNsaWVudHMgbW9kdWxlLiBJIGFtIGZp bmUgd2l0aCBoYXZpbmcgDQo+Pj4+Pj4+IGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzIG1vZHVsZSAo bm8gY2xpZW50IG1vZHVsZSkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWx0aG91Z2ggSSBkb27igJl0IGZl ZWwgdGhhdCBzdHJvbmdseSAtIEkganVzdCBkb27igJl0IHNlZSB0aGF0IA0KPj4+Pj4+IHB1dHRp bmcgdGhlIGNsaWVudCBjb25maWcgcGFyYW1zIGluIHdyYXBwZXJzIHByb3ZpZGVzIGFueSBiZW5l Zml0Lg0KPj4+Pj4+IEFzIGZvciBkZXRyaW1lbnRzLCBpdCByZXF1aXJlcyBtb3JlIG9uZSBtb3Jl IGxvY2FsIG1vZHVsZXMgZm9yIA0KPj4+Pj4+IHZhbGlkYXRpb24gYW5kIG9uZSBtb3JlIGxldmVs IG9mIGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0IHdlIGFyZSANCj4+Pj4+PiByZWFsbHkgYWxsb3dp bmcgdG8gYmUgY29uZmlndXJlZC4NCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgYW0gbm90 IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudC9xdWVzdGlvbiBvbiANCj4+Pj4+ Pj4gYmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zL2JmZC1ncm91cGluZy1jb21tb24tY2ZnLXBhcm1z LiBUaGUgDQo+Pj4+Pj4+IHJlYXNvbiB3ZSBoYXZlDQo+Pj4+Pj4+IDIgZ3JvdXBpbmdzIGlzIHRo YXQgc29tZSBwcm90b2NvbHMgbWF5IGRlY2lkZSB0byBoYXZlIGp1c3QgdGhlIA0KPj4+Pj4+PiBl bmFibGUgbGVhZiBhbmQgb3RoZXJzIG1heSBhbHNvIHdhbnQgdGhlIG11bHRpcGxpZXIvdGltZXIu DQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIGJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyBncm91cGluZyBz aG91bGQgdXNlIA0KPj4+Pj4+IGJmZC10eXBlczpiZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJt cyByYXRoZXIgdGhhbiANCj4+Pj4+PiBiZmQtdHlwZXM6YmZkLWNsaWVudC1iYXNlLWNmZy1wYXJt cyAtIG5vPyBUaGlzIHdvdWxkIGJlIG1vcmUgDQo+Pj4+Pj4gb2J2aW91cyB3L28gdGhlIGNsaWVu dCBtb2R1bGUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IEFjZWUNCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+IFJlc2hhZC4NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gMjAxNy0wNy0yNywgMzowNyBQ TSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+Pj4g DQo+Pj4+Pj4+PiBIaSBSZXNoYWQsDQo+Pj4+Pj4+PiBXaHkgZG8gd2UgbmVlZCBhIG5ldyBZQU5H IG1vZGVsIGZvciBjbGllbnRzPyBXaHkgY2Fu4oCZdCB0aGV5IA0KPj4+Pj4+Pj4ganVzdCB1c2Ug aWV0Zi1iZmQtdHlwZXMueWFuZz8gSeKAmWQgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3Nhcnkg DQo+Pj4+Pj4+PiBsZXZlbHMgb2YgaW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tzIHdyb25n IHRvIG1lIHNpbmNlIHRoZSANCj4+Pj4+Pj4+IGdyb3VwaW5nIGJmZC1jbGllbnQtZXh0LWNmZy1w YXJtcyB1c2VzIHRoZSBncm91cGluZyANCj4+Pj4+Pj4+IGJmZC1ncm91cGluZy1iYXNlLWNmZy1w YXJtcyB3aGljaCBvbmx5IGNvbnRhaW5zIHRoZSBlbmFibGVkIA0KPj4+Pj4+Pj4gbGVhZi4gSSBi ZWxpZXZlIHlvdSBtZWFudCB0byB1c2UgYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgDQo+ Pj4+Pj4+PiBpbiB0aGUgb3RoZXIgbmV3IG1vZGVsLiBIb3dldmVyLCBJIGRvbuKAmXQgc2VlIGFu eSByZWFzb24gd2h5IA0KPj4+Pj4+Pj4gY2xpZW50IHNob3VsZG7igJl0IHVzZSB0aGlzIGRpcmVj dGx5Lg0KPj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gQWNlZQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBPbiA3LzI1LzE3LCAyOjMzIFBNLCAiUmVzaGFkIFJhaG1hbiAocnJhaG1hbikiIA0KPj4+Pj4+ Pj4gPHJyYWhtYW5AY2lzY28uY29tPg0KPj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+PiBIaSBZaW5nemhlbiwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBUaGUgZ3JvdXBpbmcgaXMg YXZhaWxhYmxlIEANCj4+Pj4+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20vamhhYXMtcGZyYy9pZXRm LWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YQ0KPj4+Pj4+Pj4+IG4NCj4+Pj4+Pj4+PiBnL2ll dA0KPj4+Pj4+Pj4+IGYNCj4+Pj4+Pj4+PiAtDQo+Pj4+Pj4+Pj4gYg0KPj4+Pj4+Pj4+IGYNCj4+ Pj4+Pj4+PiBkDQo+Pj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4+IGMNCj4+Pj4+Pj4+PiBsaWVudHMueWFu Zw0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IElmIHlvdcK5ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdy b3VwaW5nLCBzZW5kIG1lIGFuIGVtYWlsLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IFJlZ2FyZHMs DQo+Pj4+Pj4+Pj4gUmVzaGFkLg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IE9uIDIwMTctMDctMjEs IDEyOjIyIFBNLCAiWWluZ3poZW4gUXUiIA0KPj4+Pj4+Pj4+IDx5aW5nemhlbi5xdUBodWF3ZWku Y29tPg0KPj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIaSBSZXNoYWQs DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGFua3MgZm9yIHRoZSBzdW1tYXJ5Lg0KPj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4gQm90aCBvc3BmIGFuZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29y cmVzcG9uZGluZyBjaGFuZ2VzIA0KPj4+Pj4+Pj4+PiB3aGVuIHRoZSBuZXcgQkZEIGdyb3VwaW5n IGlzIGF2YWlsYWJsZS4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+ Pj4gWWluZ3poZW4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4+Pj4+IEZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFttYWlsdG86 cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDIwLCAy MDE3IDc6MTkgQU0NCj4+Pj4+Pj4+Pj4gVG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+ OyBydGctYmZkQGlldGYub3JnDQo+Pj4+Pj4+Pj4+IENjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGll dGYub3JnOyANCj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4+Pj4+ Pj4+Pj4gU3ViamVjdDogUmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0 DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBXZSAoQkZEIGFuZCBPU1BGIFlBTkcgYXV0aG9ycykg aGFkIGEgZGlzY3Vzc2lvbiB5ZXN0ZXJkYXkuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGUg YWdyZWVtZW50IGlzIHRoYXQgc2luY2UgSUdQIHBlZXJzIGFyZSBhdXRvLWRpc2NvdmVyZWQsIHdl IA0KPj4+Pj4+Pj4+PiB3YW50IHRvIGFkZCBiYWNrIHRoZSBiYXNpYyBCRkQgY29uZmlnIChtdWx0 aXBsaWVyICsgDQo+Pj4+Pj4+Pj4+IGludGVydmFscykgaW4gSUdQIHZpYSBhIGdyb3VwaW5nLg0K Pj4+Pj4+Pj4+PiBCRkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZ QU5HIG1vZHVsZS4gSUdQIA0KPj4+Pj4+Pj4+PiBCRkQgWUFORyB3aWxsIGJlIGluIGEgc2VwYXJh dGUgbW9kdWxlIChzZXBhcmF0ZSBmcm9tIHRoZSBtYWluIA0KPj4+Pj4+Pj4+PiBJR1AgbW9kdWxl KS4NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+ Pj4+PiBSZXNoYWQuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBPbiAyMDE3LTA3LTA1LCAxMjoy MSBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIEplZmZyZXkgSGFhcyINCj4+Pj4+Pj4+Pj4gPHJ0 Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamhhYXNAcGZyYy5vcmc+IHdyb3Rl Og0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFRoYW5rcyBhdXRob3JzIGZvciB0aGUgZWRpdHMg b24gdGhlIEJGRCB5YW5nIG1vZHVsZS4gIFRoaXMgDQo+Pj4+Pj4+Pj4+PiBnZXRzIHVzIGEgc2ln bmlmaWNhbnQgc3RlcCBjbG9zZXIgdG8gYWxpZ25tZW50IHdpdGggdGhlIHJlc3QgDQo+Pj4+Pj4+ Pj4+PiBvZiBJRVRGIGZvciBuZXR3b3JrIGluc3RhbmNpbmcuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4+IEknZCBsaWtlIHRvIGVuY291cmFnZSB0aGUgd29ya2luZyBncm91cCB0byBwcm92aWRl IGZlZWRiYWNrIA0KPj4+Pj4+Pj4+Pj4gb24gdGhpcyBpc3N1ZSBhbmQgYWxzbyB0aGUgY2hhbmdl cyBpbiB0aGUgbW9kdWxlLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBBcyBub3RlZCBpbiBh bm90aGVyIHRocmVhZCwgd2Ugc3RpbGwgaGF2ZSB0byBmaWd1cmUgb3V0IGhvdyANCj4+Pj4+Pj4+ Pj4+IHRvIGRlYWwgd2l0aCBhY2NvbW1vZGF0aW5nIGludGVyYWN0aW9uIG9mIHRoZSBCRkQgeWFu ZyANCj4+Pj4+Pj4+Pj4+IG1vZHVsZSB3aXRoIGNsaWVudCBwcm90b2NvbHMuDQo+Pj4+Pj4+Pj4+ PiBGb3INCj4+Pj4+Pj4+Pj4+IGV4YW1wbGUsIHRoZSBJR1BzLiAgSW4gcGFydGljdWxhciwgaG93 IGRvIHlvdSBjb25maWd1cmUgdGhlIA0KPj4+Pj4+Pj4+Pj4gcHJvcGVydGllcyBvZiB0aGUgQkZE IHNlc3Npb25zIHRoYXQgbWF5IGJlIGR5bmFtaWNhbGx5IA0KPj4+Pj4+Pj4+Pj4gaW5zdGFudGlh dGVkIGJhc2VkIG9uIGNvbnRyb2wgcHJvdG9jb2wgYWN0aXZpdHk/DQo+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+IC0tIEplZmYNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gT24gRnJpLCBKdW4g MzAsIDIwMTcgYXQgMTI6NTU6NTlQTSAtMDcwMCwgDQo+Pj4+Pj4+Pj4+PiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIA0K Pj4+Pj4+Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+Pj4+Pj4+Pj4+PiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcg DQo+Pj4+Pj4+Pj4+Pj4gRGV0ZWN0aW9uIG9mIHRoZSBJRVRGLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4+ICAgICAgIFRpdGxlICAgICAgICAgICA6IFlBTkcgRGF0YSBNb2RlbCBmb3IgQmlk aXJlY3Rpb25hbA0KPj4+Pj4+Pj4+Pj4+IEZvcndhcmRpbmcNCj4+Pj4+Pj4+Pj4+PiBEZXRlY3Rp b24gKEJGRCkNCj4+Pj4+Pj4+Pj4+PiAgICAgICBBdXRob3JzICAgICAgICAgOiBSZXNoYWQgUmFo bWFuDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgTGlhbnNodSBaaGVuZw0K Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkN Cj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBTYW50b3NoIFBhbGxhZ2F0dGkN Cj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE1pcnNreQ0KPj4+Pj4+ Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+ Pj4+Pj4+Pj4+IAlQYWdlcyAgICAgICAgICAgOiA1OQ0KPj4+Pj4+Pj4+Pj4+IAlEYXRlICAgICAg ICAgICAgOiAyMDE3LTA2LTMwDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gQWJzdHJhY3Q6 DQo+Pj4+Pj4+Pj4+Pj4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCB0 aGF0IGNhbiBiZSB1c2VkIA0KPj4+Pj4+Pj4+Pj4+IHRvIGNvbmZpZ3VyZSAgYW5kIG1hbmFnZSBC aWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIA0KPj4+Pj4+Pj4+Pj4+IChCRkQpLg0K Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+ Pj4+Pj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmZk LXlhbmcvDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6 ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTANCj4+Pj4+ Pj4+Pj4+PiA2DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIA0KPj4+Pj4+Pj4+Pj4+IHRpbWUgb2Yg c3VibWlzc2lvbiAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIA0KPj4+ Pj4+Pj4+Pj4+IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+Pj4+Pj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy8NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+IA0KPj4gDQo+IA0KPiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+ IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IA0KPiANCj4gDQo+IDxpZXRmLW9zcGYtYmZkLnRy ZWU+PGlldGYtb3NwZi1iZmQueWFuZz4NCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFu ZGFuaUBnbWFpbC5jb20NCg0K From nobody Mon Jul 31 10:30:37 2017 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 4135613271D for ; Mon, 31 Jul 2017 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 bvOsBBfiF3ne for ; Mon, 31 Jul 2017 10:30:34 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2713271C for ; Mon, 31 Jul 2017 10:30:34 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 349FD1E380; Mon, 31 Jul 2017 13:30:46 -0400 (EDT) Date: Mon, 31 Jul 2017 13:30:46 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org, Enke Chen Subject: Re: Fwd: I-D Action: draft-chen-bfd-unsolicited-01.txt Message-ID: <20170731173046.GT24942@pfrc.org> References: <150146797084.17672.9122177940139456062@ietfa.amsl.com> <74377bb1-9c94-2a7b-a4a0-b1b75db99038@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74377bb1-9c94-2a7b-a4a0-b1b75db99038@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 17:30:36 -0000 Working Group, This draft was briefly mentioned as part of the IDR WG presentation on RS-BFD that I am a co-author on. That presentation is supposed to be linked here, but is not coming up. Hopefully it's a transient error: https://datatracker.ietf.org/meeting/99/materials/slides-99-idr-03-idr-rs-bfd-ietf99 A simplified version of the discussion is roughly: - In Internet Exchange Point environments, monitoring BGP next-hop reachability via BFD is desirable. - Since these next-hops may not be symmetrically distributed in BGP between the two end systems via the route server, additional help is needed to permit both sides of a normal RFC 5881 session bootstrap itself. The draft mentioned below attempts to resolve this scenario by permitting a "wildcard" single-hop BFD session be created for interfaces in environments such as a this IXP environment. It may be useful outside of the IXP use case. -- Jeff On Sun, Jul 30, 2017 at 07:35:31PM -0700, Enke Chen wrote: > Hi, Folks: > > Please let us know if you have any comments on the draft. > > Thanks. -- Enke > > -------- Forwarded Message -------- > Subject: I-D Action: draft-chen-bfd-unsolicited-01.txt > Date: Sun, 30 Jul 2017 19:26:10 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Unsolicited BFD for Sessionless Applications > Authors : Enke Chen > Naiming Shen > Robert Raszuk > Filename : draft-chen-bfd-unsolicited-01.txt > Pages : 6 > Date : 2017-07-30 > > 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-chen-bfd-unsolicited/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-chen-bfd-unsolicited-01 > https://datatracker.ietf.org/doc/html/draft-chen-bfd-unsolicited-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-chen-bfd-unsolicited-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 31 11:57:01 2017 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 4501C13278E; Mon, 31 Jul 2017 11:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaF7F6mnbV3T; Mon, 31 Jul 2017 11:56:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7CB131C2A; Mon, 31 Jul 2017 11:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15564; q=dns/txt; s=iport; t=1501527413; x=1502737013; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jxcD8zW7a5tr9sQqSSUnQg0hOaM3MTdqYYVZC8+mHu8=; b=DhunR2CtH1DVVE+VdtB+sp9MqwlEUnDn6Cq/Q61ijcN1TpXkDccsNArD OiNmQ5kL9lRc6nl9gpEsc3BGbzjr9AiuDYoO+MhbSZVcAcd2z3jaJnsc8 t6L3W7MrGJ8ggwvoDaLtbSpCNYj3CPAvo6eoW5PQc+1KTara6ILXA4rKz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAADlfH9Z/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgaPeYFriDGNWg6CBCyFGwIag24/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAyMRRQwEAgEIDgMEAQEBAgIjAwICAh8RFAEICAIEAQ0FihcDFRCuH?= =?us-ascii?q?YImhy4NhAkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuCHYhVgldQgRoBEgE2gny?= =?us-ascii?q?CYQWJfpU1PAKHTYcbTIRxggwZPoR7il+MG4lWAR84fwt3FR+FQByBZgF2h3ENF?= =?us-ascii?q?weBBYEOAQEB?= X-IronPort-AV: E=Sophos;i="5.41,304,1498521600"; d="scan'208";a="275055159" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2017 18:56:52 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6VIuqIc023650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Jul 2017 18:56:52 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Jul 2017 14:56:51 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 31 Jul 2017 14:56:51 -0400 From: "Acee Lindem (acee)" To: Mahesh Jethanandani , Yingzhen Qu CC: "Reshad Rahman (rrahman)" , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAX70gIAC3ooAgADASYCAAH0vAA== Date: Mon, 31 Jul 2017 18:56:51 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> In-Reply-To: <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.24.214] Content-Type: text/plain; charset="utf-8" Content-ID: <18BBAB27C88236438F5D6145AEF5B540@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 18:57:00 -0000 SGkgTWFoZXNoLCANCg0KT24gNy8zMS8xNywgMTI6NDIgQU0sICJNYWhlc2ggSmV0aGFuYW5kYW5p IiA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQp3cm90ZToNCg0KPllpbmd6aGVuLA0KPg0KPk92 ZXJhbGwgdGhlIG1vZGVsIGxvb2tzIGdvb2QgdG8gbWUuDQo+DQo+SSBub3RpY2UgdGhhdCB5b3Ug ZGVjaWRlZCB0byAocmUpZGVmaW5lIHRoZSBlbmFibGUgZmxhZyBpbiB0aGUgbW9kZWwuIElzDQo+ dGhhdCBpbnRlbnRpb25hbD8NCj4NCj5Zb3UgYXJlIGF3YXJlIHRoYXQgdGhlcmUgaXMgYW5vdGhl ciBncm91cGluZyBjYWxsZWQgY2xpZW50LWJhc2UtY2ZnLXBhcm1zDQo+dGhhdCBkZWZpbmVzIHRo ZSBlbmFibGVkIGZsYWcuIEkgYW0gbm90IGEgcGFydGljdWxhciBmYW4gb2YgdGhpcyBzcGxpdCwN Cj5idXQgSSBhbSB0b2xkIHRoYXQgc29tZSBjbGllbnQgcHJvdG9jb2xzIGp1c3QgbmVlZCB0aGUg ZW5hYmxlIGZsYWcNCj53aXRob3V0IHRoZSByZXN0IG9mIHRoZSBwYXJhbWV0ZXJzIG9mIGNsaWVu dC1jZmctcGFybXMuIElmIHRoZSBzcGxpdCBpcw0KPmNvbmZ1c2luZywgd2UgY2FuIGNvbGxhcHNl IHRoZSBlbmFibGVkIGZsYWcgaW50byBjbGllbnQtY2ZnLXBhcm1zLg0KDQpJIGRvbuKAmXQgYWRk IOKAmGVuYWJsZWTigJkgdG8gdGhlIGNsaWVudC1jZmctcGFybXM/IFRoZW4gYSBjbGllbnQgd291 bGQgb25seQ0KbmVlZCBhIHNpbmdsZSBncm91cGluZy4NCg0KVGhhbmtzLA0KQWNlZSANCg0KPg0K PlRoYW5rcy4NCj4NCj4+IE9uIEp1bCAzMCwgMjAxNywgYXQgMTA6MTQgQU0sIFlpbmd6aGVuIFF1 IDx5aW5nemhlbi5xdUBodWF3ZWkuY29tPg0KPj53cm90ZToNCj4+IA0KPj4gSGkgYWxsLA0KPj4g DQo+PiBQbGVhc2Ugc2VlIGF0dGFjaGVkIG9zcGYgYmZkIG1vZHVsZS4gQmFzZSBvc3BmIG1vZHVs ZSBhbHNvIG5lZWRzIHRvIGJlDQo+PnVwZGF0ZWQgdG8gcmVtb3ZlIHRoZSBiZmQgZW5hYmxlIGxl YWYuIElTSVMgbW9kZWwgbmVlZCB0byBkbyB0aGUgc2FtZQ0KPj5jaGFuZ2UsIGlldGYtaXNpcy1i ZmQueWFuZyB3aWxsIGxvb2sgdGhlIHNhbWUgYXMgaWV0Zi1vc3BmLWJmZC55YW5nLg0KPj4gDQo+ PiBQbGVhc2UgbGV0IG1lIGtub3cgeW91ciBjb21tZXRucy4NCj4+IA0KPj4gVGhhbmtzLA0KPj4g WWluZ3poZW4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IE1h aGVzaCBKZXRoYW5hbmRhbmkgW21haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbV0NCj4+IFNl bnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAyOjI1IFBNDQo+PiBUbzogQWNlZSBMaW5kZW0gKGFj ZWUpIDxhY2VlQGNpc2NvLmNvbT4NCj4+IENjOiBSZXNoYWQgUmFobWFuIDxycmFobWFuQGNpc2Nv LmNvbT47IFlpbmd6aGVuIFF1DQo+Pjx5aW5nemhlbi5xdUBodWF3ZWkuY29tPjsgSmVmZnJleSBI YWFzIDxqaGFhc0BwZnJjLm9yZz47DQo+PnJ0Zy1iZmRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYmZk LXlhbmdAaWV0Zi5vcmc7DQo+PmRyYWZ0LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+PiBTdWJq ZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQNCj4+IA0KPj4g V291bGQgaXQgbm90IGJlIGJldHRlciB0byBjYWxsIGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJt cyBzb21ldGhpbmcNCj4+bGlrZSBiZmQtZ3JvdXBpbmctY2xpZW50LWNmZy1wYXJhbXMgb3IgbW9y ZSBzaW1wbHkgY2xpZW50LWNmZy1wYXJhbXMuIFdlDQo+Pmtub3cgaXQgaXMgYSBncm91cGluZyBh bmQgd2Uga25vdyBpdCBpcyBhIGJmZCBncm91cGluZy4gV2h5IHJlcGVhdD8NCj4+IA0KPj4+IE9u IEp1bCAyNywgMjAxNywgYXQgNzozNCBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2Nv LmNvbT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgUmVzaGFkLA0KPj4+IA0KPj4+IE9rIC0gSSBzZWUg bm93LiBJIHdhcyBsb29raW5nIGF0IHRoZSB3cm9uZyB4eHh4LWJhc2UtY2ZnLXBhcm1zDQo+Pj5n cm91cGluZ3MuDQo+Pj4gRmV3ZXIgc2ltaWxhciBncm91cGluZyBhbmQgbW9kdWxlcyB3aWxsIGJl IGJldHRlciA7XikNCj4+PiANCj4+PiBUaGFua3MsDQo+Pj4gQWNlZQ0KPj4+IA0KPj4+IE9uIDcv MjcvMTcsIDk6MDMgUE0sICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5AY2lzY28u Y29tPg0KPj4+d3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIEFjZWUsDQo+Pj4+IA0KPj4+PiBXaGF0IEkg c2VlIEANCj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9i bG9iL21hc3Rlci9zcmMveWFuZy9pZXRmDQo+Pj4+IC1iZmQtDQo+Pj4+IHQNCj4+Pj4geXBlcy55 YW5nOg0KPj4+PiAxKSBiZmQtY2xpZW50LWJhc2UtY2ZnLXBhcm1zIGhhcyBsZWFmIGVuYWJsZWQg b25seS4gQlRXIHRoaXMgZ3JvdXBpbmcNCj4+Pj4gaXMgZGVmaW5lZCB0d2ljZSwgdGhpcyB3aWxs IGJlIGZpeGVkIHdoZW4gSSBnZXQgcmlkIG9mDQo+Pj4+IGlldGYtYmZkLWNsaWVudHMueWFuZw0K Pj4+PiAyKSBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaGFzIG11bHRpcGxpZXIvdGltZXJz Lg0KPj4+PiANCj4+Pj4gTGV0IG1lIGdldCByaWQgb2YgdGhlIGNsaWVudCBtb2R1bGUgYW5kIGhh dmUgZXZlcnl0aGluZyBpbiB0aGUgdHlwZXMNCj4+Pj4gbW9kdWxlLg0KPj4+PiANCj4+Pj4gSSBh bSBub3Qgc3VyZSB3aHkgeW914oCZcmUgbm90IHNlZWluZyBzb21ldGhpbmcgZGlmZmVyZW50Lg0K Pj4+PiANCj4+Pj4gUmVnYXJkcywNCj4+Pj4gUmVzaGFkLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0K Pj4+PiBPbiAyMDE3LTA3LTI3LCAzOjQwIFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBj aXNjby5jb20+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEhpIFJlc2hhZCwNCj4+Pj4+IA0KPj4+Pj4g T24gNy8yNy8xNywgMzozNSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBj aXNjby5jb20+DQo+Pj4+Pndyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4gSGkgQWNlZSwNCj4+Pj4+PiAN Cj4+Pj4+PiAxKSBJ4oCZbGwgc2VlIGlmIG90aGVycyBjaGltZSBpbiBvbiB0aGlzIGJ1dCBJIGFt IGZpbmUgd2l0aCBoYXZpbmcNCj4+Pj4+PiB0aGUgY2xpZW50IGdyb3VwaW5nIGluIGlldGYtYmZk LXR5cGVzLnlhbmcuDQo+Pj4+Pj4gMikgYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMgaGFz IG11Y2ggbW9yZSB0aGFuIGp1c3QgdGhlDQo+Pj4+Pj4gbXVsdGlwbGllci90aW1lcnMgdGhhdCB0 aGUgSUdQcyBuZWVkLiBJdCBhbHNvIGhhcyBCRkQgc3BlY2lmaWMNCj4+Pj4+PiBzdHVmZiAoZGVt YW5kLW1vZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1c2luZXNzIG91dHNpZGUgb2YN Cj4+Pj4+PkJGRC4NCj4+Pj4+IA0KPj4+Pj4gQWdyZWVkLiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ Pj4gYmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zIGhhcyBvbmx5IHRoZSBtdWx0aXBsaWVyL3Rp bWVycy4NCj4+Pj4+IA0KPj4+Pj4gUGVyaGFwcywgdGhlIGFkZGl0aW9uIG9mIG11bHRpcGxpZXIv dGltZXJzIHRvDQo+Pj4+PiBiZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgaXNu4oCZdCBwdXNo ZWQgdG8gR2l0SHViIHlldC4gVGhpcyB2ZXJzaW9uDQo+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20v amhhYXMtcGZyYy9pZXRmLWJmZC15YW5nL2Jsb2IvbWFzdGVyL3NyYy95YW5nL2lldA0KPj4+Pj4g Zi1iZmQNCj4+Pj4+IC0NCj4+Pj4+IHQNCj4+Pj4+IHlwZXMueWFuZyBvbmx5IGhhcyB0aGUgZW5h YmxlZCBsZWFmLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IEFjZWUNCj4+ Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+PiBSZXNoYWQuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMjAxNy0wNy0yNywgMzozMCBQTSwg IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+PiANCj4+ Pj4+Pj4gSGkgUmVzaGFkLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gNy8yNy8xNywgMzoxOSBQTSwg IlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+Pj4+IHdy b3RlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4+IEhpIEFjZWUsDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFdo ZW4gd2UgbWV0IHdlIGFncmVlZCB0byBoYXZlIGEgbmV3IG1vZGVsIGZvciBjbGllbnRzLiBBZnRl cndhcmRzDQo+Pj4+Pj4+PiBJIGRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwg YW5kIHN0aWxsIHdlbnQgYWhlYWQgd2l0aA0KPj4+Pj4+Pj4gdGhlIGNsaWVudHMgbW9kdWxlLiBJ IGFtIGZpbmUgd2l0aCBoYXZpbmcgZXZlcnl0aGluZyBpbiB0aGUgdHlwZXMNCj4+Pj4+Pj4+IG1v ZHVsZSAobm8gY2xpZW50IG1vZHVsZSkuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBbHRob3VnaCBJIGRv buKAmXQgZmVlbCB0aGF0IHN0cm9uZ2x5IC0gSSBqdXN0IGRvbuKAmXQgc2VlIHRoYXQNCj4+Pj4+ Pj4gcHV0dGluZyB0aGUgY2xpZW50IGNvbmZpZyBwYXJhbXMgaW4gd3JhcHBlcnMgcHJvdmlkZXMg YW55IGJlbmVmaXQuDQo+Pj4+Pj4+IEFzIGZvciBkZXRyaW1lbnRzLCBpdCByZXF1aXJlcyBtb3Jl IG9uZSBtb3JlIGxvY2FsIG1vZHVsZXMgZm9yDQo+Pj4+Pj4+IHZhbGlkYXRpb24gYW5kIG9uZSBt b3JlIGxldmVsIG9mIGluZGlyZWN0aW9uIHRvIHNlZSB3aGF0IHdlIGFyZQ0KPj4+Pj4+PiByZWFs bHkgYWxsb3dpbmcgdG8gYmUgY29uZmlndXJlZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IEkgYW0gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHlvdXIgY29tbWVudC9xdWVzdGlv biBvbg0KPj4+Pj4+Pj4gYmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zL2JmZC1ncm91cGluZy1jb21t b24tY2ZnLXBhcm1zLiBUaGUNCj4+Pj4+Pj4+IHJlYXNvbiB3ZSBoYXZlDQo+Pj4+Pj4+PiAyIGdy b3VwaW5ncyBpcyB0aGF0IHNvbWUgcHJvdG9jb2xzIG1heSBkZWNpZGUgdG8gaGF2ZSBqdXN0IHRo ZQ0KPj4+Pj4+Pj4gZW5hYmxlIGxlYWYgYW5kIG90aGVycyBtYXkgYWxzbyB3YW50IHRoZSBtdWx0 aXBsaWVyL3RpbWVyLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlIGJmZC1jbGllbnQtZXh0LWNmZy1w YXJtcyBncm91cGluZyBzaG91bGQgdXNlDQo+Pj4+Pj4+IGJmZC10eXBlczpiZmQtZ3JvdXBpbmct Y29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPj4+Pj4+PiBiZmQtdHlwZXM6YmZkLWNsaWVu dC1iYXNlLWNmZy1wYXJtcyAtIG5vPyBUaGlzIHdvdWxkIGJlIG1vcmUNCj4+Pj4+Pj4gb2J2aW91 cyB3L28gdGhlIGNsaWVudCBtb2R1bGUuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGFua3MsDQo+Pj4+ Pj4+IEFjZWUNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBSZWdhcmRz LA0KPj4+Pj4+Pj4gUmVzaGFkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gT24gMjAxNy0wNy0yNywgMzowNyBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVA Y2lzY28uY29tPg0KPj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhpIFJlc2hh ZCwNCj4+Pj4+Pj4+PiBXaHkgZG8gd2UgbmVlZCBhIG5ldyBZQU5HIG1vZGVsIGZvciBjbGllbnRz PyBXaHkgY2Fu4oCZdCB0aGV5IGp1c3QNCj4+Pj4+Pj4+PiB1c2UgaWV0Zi1iZmQtdHlwZXMueWFu Zz8gSeKAmWQgbGlrZSB0byBhdm9pZCB0aGUgdW5uZWNlc3NhcnkNCj4+Pj4+Pj4+PiBsZXZlbHMg b2YgaW5kaXJlY3Rpb24uIEluIGZhY3QsIGl0IGxvb2tzIHdyb25nIHRvIG1lIHNpbmNlIHRoZQ0K Pj4+Pj4+Pj4+IGdyb3VwaW5nIGJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBncm91 cGluZw0KPj4+Pj4+Pj4+IGJmZC1ncm91cGluZy1iYXNlLWNmZy1wYXJtcyB3aGljaCBvbmx5IGNv bnRhaW5zIHRoZSBlbmFibGVkDQo+Pj4+Pj4+Pj4gbGVhZi4gSSBiZWxpZXZlIHlvdSBtZWFudCB0 byB1c2UgYmZkLWdyb3VwaW5nLWNvbW1vbi1jZmctcGFybXMNCj4+Pj4+Pj4+PiBpbiB0aGUgb3Ro ZXIgbmV3IG1vZGVsLiBIb3dldmVyLCBJIGRvbuKAmXQgc2VlIGFueSByZWFzb24gd2h5DQo+Pj4+ Pj4+Pj4gY2xpZW50IHNob3VsZG7igJl0IHVzZSB0aGlzIGRpcmVjdGx5Lg0KPj4+Pj4+Pj4+IFRo YW5rcywNCj4+Pj4+Pj4+PiBBY2VlDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gT24gNy8yNS8xNywg MjozMyBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIg0KPj4+Pj4+Pj4+IDxycmFobWFuQGNp c2NvLmNvbT4NCj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSGkgWWlu Z3poZW4sDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBUaGUgZ3JvdXBpbmcgaXMgYXZhaWxhYmxl IEANCj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFu Zy9ibG9iL21hc3Rlci9zcmMveWFuDQo+Pj4+Pj4+Pj4+IGcvaWV0DQo+Pj4+Pj4+Pj4+IGYNCj4+ Pj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4+PiBiDQo+Pj4+Pj4+Pj4+IGYNCj4+Pj4+Pj4+Pj4gZA0KPj4+ Pj4+Pj4+PiAtDQo+Pj4+Pj4+Pj4+IGMNCj4+Pj4+Pj4+Pj4gbGllbnRzLnlhbmcNCj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+IElmIHlvdcK5ZCBsaWtlIGNoYW5nZXMgdG8gdGhlIGdyb3VwaW5nLCBz ZW5kIG1lIGFuIGVtYWlsLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+ Pj4+Pj4gUmVzaGFkLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gT24gMjAxNy0wNy0yMSwgMTI6 MjIgUE0sICJZaW5nemhlbiBRdSIgPHlpbmd6aGVuLnF1QGh1YXdlaS5jb20+DQo+Pj4+Pj4+Pj4+ IHdyb3RlOg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IEhpIFJlc2hhZCwNCj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgc3VtbWFyeS4NCj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4gQm90aCBvc3BmIGFuZCBpc2lzIG1vZGVscyB3aWxsIG1ha2UgY29ycmVzcG9uZGlu ZyBjaGFuZ2VzIHdoZW4NCj4+Pj4+Pj4+Pj4+IHRoZSBuZXcgQkZEIGdyb3VwaW5nIGlzIGF2YWls YWJsZS4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4+Pj4gWWlu Z3poZW4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4+Pj4+Pj4+IEZyb206IFJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIFttYWlsdG86cnJh aG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAyMCwgMjAx NyA3OjE5IEFNDQo+Pj4+Pj4+Pj4+PiBUbzogSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz47 IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IENjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGll dGYub3JnOw0KPj4+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcNCj4+Pj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4 dA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBXZSAoQkZEIGFuZCBPU1BGIFlBTkcgYXV0aG9y cykgaGFkIGEgZGlzY3Vzc2lvbiB5ZXN0ZXJkYXkuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ IFRoZSBhZ3JlZW1lbnQgaXMgdGhhdCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJl ZCwgd2UNCj4+Pj4+Pj4+Pj4+IHdhbnQgdG8gYWRkIGJhY2sgdGhlIGJhc2ljIEJGRCBjb25maWcg KG11bHRpcGxpZXIgKyBpbnRlcnZhbHMpDQo+Pj4+Pj4+Pj4+PiBpbiBJR1AgdmlhIGEgZ3JvdXBp bmcuDQo+Pj4+Pj4+Pj4+PiBCRkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVj aWZpYyBZQU5HIG1vZHVsZS4gSUdQDQo+Pj4+Pj4+Pj4+PiBCRkQgWUFORyB3aWxsIGJlIGluIGEg c2VwYXJhdGUgbW9kdWxlIChzZXBhcmF0ZSBmcm9tIHRoZSBtYWluDQo+Pj4+Pj4+Pj4+PiBJR1Ag bW9kdWxlKS4NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBSZWdhcmRz LA0KPj4+Pj4+Pj4+Pj4gUmVzaGFkLg0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+PiBPbiAyMDE3 LTA3LTA1LCAxMjoyMSBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIEplZmZyZXkgSGFhcyINCj4+ Pj4+Pj4+Pj4+IDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBm cmMub3JnPiB3cm90ZToNCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFRoYW5rcyBhdXRob3Jz IGZvciB0aGUgZWRpdHMgb24gdGhlIEJGRCB5YW5nIG1vZHVsZS4gIFRoaXMNCj4+Pj4+Pj4+Pj4+ PiBnZXRzIHVzIGEgc2lnbmlmaWNhbnQgc3RlcCBjbG9zZXIgdG8gYWxpZ25tZW50IHdpdGggdGhl IHJlc3QNCj4+Pj4+Pj4+Pj4+PiBvZiBJRVRGIGZvciBuZXR3b3JrIGluc3RhbmNpbmcuDQo+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gSSdkIGxpa2UgdG8gZW5jb3VyYWdlIHRoZSB3b3JraW5n IGdyb3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sNCj4+Pj4+Pj4+Pj4+PiBvbiB0aGlzIGlzc3VlIGFu ZCBhbHNvIHRoZSBjaGFuZ2VzIGluIHRoZSBtb2R1bGUuDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4gQXMgbm90ZWQgaW4gYW5vdGhlciB0aHJlYWQsIHdlIHN0aWxsIGhhdmUgdG8gZmlndXJl IG91dCBob3cNCj4+Pj4+Pj4+Pj4+PiB0byBkZWFsIHdpdGggYWNjb21tb2RhdGluZyBpbnRlcmFj dGlvbiBvZiB0aGUgQkZEIHlhbmcgbW9kdWxlDQo+Pj4+Pj4+Pj4+Pj4gd2l0aCBjbGllbnQgcHJv dG9jb2xzLg0KPj4+Pj4+Pj4+Pj4+IEZvcg0KPj4+Pj4+Pj4+Pj4+IGV4YW1wbGUsIHRoZSBJR1Bz LiAgSW4gcGFydGljdWxhciwgaG93IGRvIHlvdSBjb25maWd1cmUgdGhlDQo+Pj4+Pj4+Pj4+Pj4g cHJvcGVydGllcyBvZiB0aGUgQkZEIHNlc3Npb25zIHRoYXQgbWF5IGJlIGR5bmFtaWNhbGx5DQo+ Pj4+Pj4+Pj4+Pj4gaW5zdGFudGlhdGVkIGJhc2VkIG9uIGNvbnRyb2wgcHJvdG9jb2wgYWN0aXZp dHk/DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gLS0gSmVmZg0KPj4+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+Pj4+IE9uIEZyaSwgSnVuIDMwLCAyMDE3IGF0IDEyOjU1OjU5UE0gLTA3MDAsDQo+ Pj4+Pj4+Pj4+Pj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4gd3JvdGU6 DQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZQ0KPj4+Pj4+Pj4+Pj4+PiBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+Pj4+Pj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZw0KPj4+Pj4+Pj4+Pj4+PiBEZXRlY3Rpb24gb2Yg dGhlIElFVEYuDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiAgICAgICBUaXRsZSAgICAg ICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIEJpZGlyZWN0aW9uYWwNCj4+Pj4+Pj4+Pj4+Pj4g Rm9yd2FyZGluZw0KPj4+Pj4+Pj4+Pj4+PiBEZXRlY3Rpb24gKEJGRCkNCj4+Pj4+Pj4+Pj4+Pj4g ICAgICAgQXV0aG9ycyAgICAgICAgIDogUmVzaGFkIFJhaG1hbg0KPj4+Pj4+Pj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICBMaWFuc2h1IFpoZW5nDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgIE1haGVzaCBKZXRoYW5hbmRhbmkNCj4+Pj4+Pj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgU2FudG9zaCBQYWxsYWdhdHRpDQo+Pj4+Pj4+Pj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgIEdyZWcgTWlyc2t5DQo+Pj4+Pj4+Pj4+Pj4+IAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2LnR4dA0KPj4+Pj4+Pj4+Pj4+PiAJUGFnZXMg ICAgICAgICAgIDogNTkNCj4+Pj4+Pj4+Pj4+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTctMDYt MzANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IEFic3RyYWN0Og0KPj4+Pj4+Pj4+Pj4+ PiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVz ZWQNCj4+Pj4+Pj4+Pj4+Pj4gdG8gY29uZmlndXJlDQo+Pj4+Pj4+Pj4+Pj4+ICBhbmQgbWFuYWdl IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkuDQo+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+Pj4+Pj4+Pj4+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0K Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVy c2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+Pj4+Pj4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1iZmQteWFuZy0wNg0KPj4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtYmZkLXlhbmctMDYNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUNCj4+Pj4+Pj4+Pj4+Pj4gdGltZSBvZiBzdWJtaXNzaW9uICB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUNCj4+Pj4+Pj4+Pj4+Pj4gYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4g SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K Pj4+Pj4+Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+ Pj4+PiANCj4+Pj4+IA0KPj4+PiANCj4+PiANCj4+IA0KPj4gTWFoZXNoIEpldGhhbmFuZGFuaQ0K Pj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4+IA0KPj4gDQo+PiANCj4+IDxpZXRmLW9zcGYt YmZkLnRyZWU+PGlldGYtb3NwZi1iZmQueWFuZz4NCj4NCj5NYWhlc2ggSmV0aGFuYW5kYW5pDQo+ bWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4NCg0K From nobody Mon Jul 31 12:05:45 2017 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 0B0EF132779; Mon, 31 Jul 2017 12:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MACB_yMB0zH; Mon, 31 Jul 2017 12:05:41 -0700 (PDT) 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 DD583132792; Mon, 31 Jul 2017 12:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16216; q=dns/txt; s=iport; t=1501527941; x=1502737541; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JKXMQRBdfybXW3ux9kPy2vseGAm3jLcVMh75/5S4wqQ=; b=QTGD+oBWmVBdcL6CS67t3CoPiyryhXTKXdbVTm/oZQKFfDF2kJIm/dfF O8aMbg1FudCF0HD2QUdo05MXxIDIDcVQ3AdU+sQZ/k/0ID9wxvKWpUqEv wqdZf+OMvaNeBQQVzkPj9iNuoQ+4vy9JSdZC0hSOrcMtXoaOhFxJOjN72 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNAAAHf39Z/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgQISB44Gj3mBa4gxjVoOggQshRsCGoNuPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQMjEUUMBAIBBgIRBAEBAQICIwMCAgIfERQBCAgCBAENBYoXAxUQk?= =?us-ascii?q?D2dZIImhy4NhAkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuCHYhVgldQgRoBEgE?= =?us-ascii?q?fF4J8gmEBBIl+lTU8AodNhxtMhHGCDBk+hHuKX4wbiVYBHzh/C3cVH4VAHIFmA?= =?us-ascii?q?XaHcQ0XB4EFgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.41,304,1498521600"; d="scan'208";a="463734437" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jul 2017 19:05:38 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6VJ5bGD032001 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Jul 2017 19:05:38 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Jul 2017 15:05:37 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 31 Jul 2017 15:05:36 -0400 From: "Acee Lindem (acee)" To: "Acee Lindem (acee)" , Mahesh Jethanandani , Yingzhen Qu CC: "Reshad Rahman (rrahman)" , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drqXiPB9yzw8Uyz6SEnSzAzYaJFxYCAgBeSvYCAAT4qwIAGf4+AgAMdioCAABQjAP//8hkAgAASYgD///B3AIAAawoAgAAI1YCAAX70gIAC3ooAgADASYCAAH0vAIAAMM8A Date: Mon, 31 Jul 2017 19:05:36 +0000 Message-ID: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.24.214] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 19:05:44 -0000 U2lnaCwgSSBtZWFuIOKAnHdoeSBkb27igJl0IHlvdSBhZGQg4oCYZW5hYmxlZOKAmeKApiINCg0K T24gNy8zMS8xNywgMjo1NiBQTSwgIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29t PiB3cm90ZToNCg0KPkhpIE1haGVzaCwgDQo+DQo+T24gNy8zMS8xNywgMTI6NDIgQU0sICJNYWhl c2ggSmV0aGFuYW5kYW5pIiA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQo+d3JvdGU6DQo+DQo+ Pllpbmd6aGVuLA0KPj4NCj4+T3ZlcmFsbCB0aGUgbW9kZWwgbG9va3MgZ29vZCB0byBtZS4NCj4+ DQo+Pkkgbm90aWNlIHRoYXQgeW91IGRlY2lkZWQgdG8gKHJlKWRlZmluZSB0aGUgZW5hYmxlIGZs YWcgaW4gdGhlIG1vZGVsLiBJcw0KPj50aGF0IGludGVudGlvbmFsPw0KPj4NCj4+WW91IGFyZSBh d2FyZSB0aGF0IHRoZXJlIGlzIGFub3RoZXIgZ3JvdXBpbmcgY2FsbGVkIGNsaWVudC1iYXNlLWNm Zy1wYXJtcw0KPj50aGF0IGRlZmluZXMgdGhlIGVuYWJsZWQgZmxhZy4gSSBhbSBub3QgYSBwYXJ0 aWN1bGFyIGZhbiBvZiB0aGlzIHNwbGl0LA0KPj5idXQgSSBhbSB0b2xkIHRoYXQgc29tZSBjbGll bnQgcHJvdG9jb2xzIGp1c3QgbmVlZCB0aGUgZW5hYmxlIGZsYWcNCj4+d2l0aG91dCB0aGUgcmVz dCBvZiB0aGUgcGFyYW1ldGVycyBvZiBjbGllbnQtY2ZnLXBhcm1zLiBJZiB0aGUgc3BsaXQgaXMN Cj4+Y29uZnVzaW5nLCB3ZSBjYW4gY29sbGFwc2UgdGhlIGVuYWJsZWQgZmxhZyBpbnRvIGNsaWVu dC1jZmctcGFybXMuDQo+DQo+SSBkb27igJl0IGFkZCDigJhlbmFibGVk4oCZIHRvIHRoZSBjbGll bnQtY2ZnLXBhcm1zPyBUaGVuIGEgY2xpZW50IHdvdWxkIG9ubHkNCj5uZWVkIGEgc2luZ2xlIGdy b3VwaW5nLg0KDQoNCj4NCj5UaGFua3MsDQo+QWNlZSANCj4NCj4+DQo+PlRoYW5rcy4NCj4+DQo+ Pj4gT24gSnVsIDMwLCAyMDE3LCBhdCAxMDoxNCBBTSwgWWluZ3poZW4gUXUgPHlpbmd6aGVuLnF1 QGh1YXdlaS5jb20+DQo+Pj53cm90ZToNCj4+PiANCj4+PiBIaSBhbGwsDQo+Pj4gDQo+Pj4gUGxl YXNlIHNlZSBhdHRhY2hlZCBvc3BmIGJmZCBtb2R1bGUuIEJhc2Ugb3NwZiBtb2R1bGUgYWxzbyBu ZWVkcyB0byBiZQ0KPj4+dXBkYXRlZCB0byByZW1vdmUgdGhlIGJmZCBlbmFibGUgbGVhZi4gSVNJ UyBtb2RlbCBuZWVkIHRvIGRvIHRoZSBzYW1lDQo+Pj5jaGFuZ2UsIGlldGYtaXNpcy1iZmQueWFu ZyB3aWxsIGxvb2sgdGhlIHNhbWUgYXMgaWV0Zi1vc3BmLWJmZC55YW5nLg0KPj4+IA0KPj4+IFBs ZWFzZSBsZXQgbWUga25vdyB5b3VyIGNvbW1ldG5zLg0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiBZ aW5nemhlbg0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTog TWFoZXNoIEpldGhhbmFuZGFuaSBbbWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tXQ0KPj4+ IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAyOjI1IFBNDQo+Pj4gVG86IEFjZWUgTGluZGVt IChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQo+Pj4gQ2M6IFJlc2hhZCBSYWhtYW4gPHJyYWhtYW5A Y2lzY28uY29tPjsgWWluZ3poZW4gUXUNCj4+Pjx5aW5nemhlbi5xdUBodWF3ZWkuY29tPjsgSmVm ZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz47DQo+Pj5ydGctYmZkQGlldGYub3JnOyBkcmFmdC1p ZXRmLWJmZC15YW5nQGlldGYub3JnOw0KPj4+ZHJhZnQtaWV0Zi1vc3BmLXlhbmdAaWV0Zi5vcmcN Cj4+PiBTdWJqZWN0OiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1iZmQteWFuZy0wNi50eHQN Cj4+PiANCj4+PiBXb3VsZCBpdCBub3QgYmUgYmV0dGVyIHRvIGNhbGwgYmZkLWdyb3VwaW5nLWJh c2UtY2ZnLXBhcm1zIHNvbWV0aGluZw0KPj4+bGlrZSBiZmQtZ3JvdXBpbmctY2xpZW50LWNmZy1w YXJhbXMgb3IgbW9yZSBzaW1wbHkgY2xpZW50LWNmZy1wYXJhbXMuIFdlDQo+Pj5rbm93IGl0IGlz IGEgZ3JvdXBpbmcgYW5kIHdlIGtub3cgaXQgaXMgYSBiZmQgZ3JvdXBpbmcuIFdoeSByZXBlYXQ/ DQo+Pj4gDQo+Pj4+IE9uIEp1bCAyNywgMjAxNywgYXQgNzozNCBQTSwgQWNlZSBMaW5kZW0gKGFj ZWUpIDxhY2VlQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4gDQo+Pj4+IEhpIFJlc2hhZCwN Cj4+Pj4gDQo+Pj4+IE9rIC0gSSBzZWUgbm93LiBJIHdhcyBsb29raW5nIGF0IHRoZSB3cm9uZyB4 eHh4LWJhc2UtY2ZnLXBhcm1zDQo+Pj4+Z3JvdXBpbmdzLg0KPj4+PiBGZXdlciBzaW1pbGFyIGdy b3VwaW5nIGFuZCBtb2R1bGVzIHdpbGwgYmUgYmV0dGVyIDteKQ0KPj4+PiANCj4+Pj4gVGhhbmtz LA0KPj4+PiBBY2VlDQo+Pj4+IA0KPj4+PiBPbiA3LzI3LzE3LCA5OjAzIFBNLCAiUmVzaGFkIFJh aG1hbiAocnJhaG1hbikiIDxycmFobWFuQGNpc2NvLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4gDQo+ Pj4+PiBIaSBBY2VlLA0KPj4+Pj4gDQo+Pj4+PiBXaGF0IEkgc2VlIEANCj4+Pj4+IGh0dHBzOi8v Z2l0aHViLmNvbS9qaGFhcy1wZnJjL2lldGYtYmZkLXlhbmcvYmxvYi9tYXN0ZXIvc3JjL3lhbmcv aWV0Zg0KPj4+Pj4gLWJmZC0NCj4+Pj4+IHQNCj4+Pj4+IHlwZXMueWFuZzoNCj4+Pj4+IDEpIGJm ZC1jbGllbnQtYmFzZS1jZmctcGFybXMgaGFzIGxlYWYgZW5hYmxlZCBvbmx5LiBCVFcgdGhpcyBn cm91cGluZw0KPj4+Pj4gaXMgZGVmaW5lZCB0d2ljZSwgdGhpcyB3aWxsIGJlIGZpeGVkIHdoZW4g SSBnZXQgcmlkIG9mDQo+Pj4+PiBpZXRmLWJmZC1jbGllbnRzLnlhbmcNCj4+Pj4+IDIpIGJmZC1n cm91cGluZy1iYXNlLWNmZy1wYXJtcyBoYXMgbXVsdGlwbGllci90aW1lcnMuDQo+Pj4+PiANCj4+ Pj4+IExldCBtZSBnZXQgcmlkIG9mIHRoZSBjbGllbnQgbW9kdWxlIGFuZCBoYXZlIGV2ZXJ5dGhp bmcgaW4gdGhlIHR5cGVzDQo+Pj4+PiBtb2R1bGUuDQo+Pj4+PiANCj4+Pj4+IEkgYW0gbm90IHN1 cmUgd2h5IHlvdeKAmXJlIG5vdCBzZWVpbmcgc29tZXRoaW5nIGRpZmZlcmVudC4NCj4+Pj4+IA0K Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+IFJlc2hhZC4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IE9uIDIwMTctMDctMjcsIDM6NDAgUE0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNp c2NvLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiBIaSBSZXNoYWQsDQo+Pj4+Pj4gDQo+Pj4+ Pj4gT24gNy8yNy8xNywgMzozNSBQTSwgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1h bkBjaXNjby5jb20+DQo+Pj4+Pj53cm90ZToNCj4+Pj4+PiANCj4+Pj4+Pj4gSGkgQWNlZSwNCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IDEpIEnigJlsbCBzZWUgaWYgb3RoZXJzIGNoaW1lIGluIG9uIHRoaXMg YnV0IEkgYW0gZmluZSB3aXRoIGhhdmluZw0KPj4+Pj4+PiB0aGUgY2xpZW50IGdyb3VwaW5nIGlu IGlldGYtYmZkLXR5cGVzLnlhbmcuDQo+Pj4+Pj4+IDIpIGJmZC1ncm91cGluZy1jb21tb24tY2Zn LXBhcm1zIGhhcyBtdWNoIG1vcmUgdGhhbiBqdXN0IHRoZQ0KPj4+Pj4+PiBtdWx0aXBsaWVyL3Rp bWVycyB0aGF0IHRoZSBJR1BzIG5lZWQuIEl0IGFsc28gaGFzIEJGRCBzcGVjaWZpYw0KPj4+Pj4+ PiBzdHVmZiAoZGVtYW5kLW1vZGUsIEJGRCBhdXRoKSB3aGljaCBJTU8gaGFzIG5vIGJ1c2luZXNz IG91dHNpZGUgb2YNCj4+Pj4+Pj5CRkQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQWdyZWVkLiANCj4+Pj4+ PiANCj4+Pj4+PiANCj4+Pj4+Pj4gYmZkLWdyb3VwaW5nLWJhc2UtY2ZnLXBhcm1zIGhhcyBvbmx5 IHRoZSBtdWx0aXBsaWVyL3RpbWVycy4NCj4+Pj4+PiANCj4+Pj4+PiBQZXJoYXBzLCB0aGUgYWRk aXRpb24gb2YgbXVsdGlwbGllci90aW1lcnMgdG8NCj4+Pj4+PiBiZmQtZ3JvdXBpbmctYmFzZS1j ZmctcGFybXMgaXNu4oCZdCBwdXNoZWQgdG8gR2l0SHViIHlldC4gVGhpcyB2ZXJzaW9uDQo+Pj4+ Pj4gaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9ibG9iL21hc3Rl ci9zcmMveWFuZy9pZXQNCj4+Pj4+PiBmLWJmZA0KPj4+Pj4+IC0NCj4+Pj4+PiB0DQo+Pj4+Pj4g eXBlcy55YW5nIG9ubHkgaGFzIHRoZSBlbmFibGVkIGxlYWYuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+ Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IEFjZWUNCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+IFJlc2hhZC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiANCj4+Pj4+Pj4gT24gMjAxNy0wNy0yNywgMzozMCBQTSwgIkFjZWUgTGluZGVtIChhY2Vl KSIgPGFjZWVAY2lzY28uY29tPg0KPj4+Pj4+Pndyb3RlOg0KPj4+Pj4+PiANCj4+Pj4+Pj4+IEhp IFJlc2hhZCwNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gT24gNy8yNy8xNywgMzoxOSBQTSwgIlJlc2hh ZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+DQo+Pj4+Pj4+PiB3cm90ZToN Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IEhpIEFjZWUsDQo+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4gV2hl biB3ZSBtZXQgd2UgYWdyZWVkIHRvIGhhdmUgYSBuZXcgbW9kZWwgZm9yIGNsaWVudHMuIEFmdGVy d2FyZHMNCj4+Pj4+Pj4+PiBJIGRlY2lkZWQgdG8gY3JlYXRlIGEgbmV3IHR5cGVzIG1vZHVsZSwg YW5kIHN0aWxsIHdlbnQgYWhlYWQgd2l0aA0KPj4+Pj4+Pj4+IHRoZSBjbGllbnRzIG1vZHVsZS4g SSBhbSBmaW5lIHdpdGggaGF2aW5nIGV2ZXJ5dGhpbmcgaW4gdGhlIHR5cGVzDQo+Pj4+Pj4+Pj4g bW9kdWxlIChubyBjbGllbnQgbW9kdWxlKS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gQWx0aG91Z2gg SSBkb27igJl0IGZlZWwgdGhhdCBzdHJvbmdseSAtIEkganVzdCBkb27igJl0IHNlZSB0aGF0DQo+ Pj4+Pj4+PiBwdXR0aW5nIHRoZSBjbGllbnQgY29uZmlnIHBhcmFtcyBpbiB3cmFwcGVycyBwcm92 aWRlcyBhbnkgYmVuZWZpdC4NCj4+Pj4+Pj4+IEFzIGZvciBkZXRyaW1lbnRzLCBpdCByZXF1aXJl cyBtb3JlIG9uZSBtb3JlIGxvY2FsIG1vZHVsZXMgZm9yDQo+Pj4+Pj4+PiB2YWxpZGF0aW9uIGFu ZCBvbmUgbW9yZSBsZXZlbCBvZiBpbmRpcmVjdGlvbiB0byBzZWUgd2hhdCB3ZSBhcmUNCj4+Pj4+ Pj4+IHJlYWxseSBhbGxvd2luZyB0byBiZSBjb25maWd1cmVkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4gSSBhbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgeW91ciBjb21t ZW50L3F1ZXN0aW9uIG9uDQo+Pj4+Pj4+Pj4gYmZkLWNsaWVudC1leHQtY2ZnLXBhcm1zL2JmZC1n cm91cGluZy1jb21tb24tY2ZnLXBhcm1zLiBUaGUNCj4+Pj4+Pj4+PiByZWFzb24gd2UgaGF2ZQ0K Pj4+Pj4+Pj4+IDIgZ3JvdXBpbmdzIGlzIHRoYXQgc29tZSBwcm90b2NvbHMgbWF5IGRlY2lkZSB0 byBoYXZlIGp1c3QgdGhlDQo+Pj4+Pj4+Pj4gZW5hYmxlIGxlYWYgYW5kIG90aGVycyBtYXkgYWxz byB3YW50IHRoZSBtdWx0aXBsaWVyL3RpbWVyLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgYmZk LWNsaWVudC1leHQtY2ZnLXBhcm1zIGdyb3VwaW5nIHNob3VsZCB1c2UNCj4+Pj4+Pj4+IGJmZC10 eXBlczpiZmQtZ3JvdXBpbmctY29tbW9uLWNmZy1wYXJtcyByYXRoZXIgdGhhbg0KPj4+Pj4+Pj4g YmZkLXR5cGVzOmJmZC1jbGllbnQtYmFzZS1jZmctcGFybXMgLSBubz8gVGhpcyB3b3VsZCBiZSBt b3JlDQo+Pj4+Pj4+PiBvYnZpb3VzIHcvbyB0aGUgY2xpZW50IG1vZHVsZS4NCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gQWNlZQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+Pj4+IFJlc2hhZC4NCj4+Pj4+Pj4+ PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBPbiAyMDE3LTA3LTI3LCAzOjA3 IFBNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+DQo+Pj4+Pj4+Pj53cm90 ZToNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSGkgUmVzaGFkLA0KPj4+Pj4+Pj4+PiBXaHkgZG8g d2UgbmVlZCBhIG5ldyBZQU5HIG1vZGVsIGZvciBjbGllbnRzPyBXaHkgY2Fu4oCZdCB0aGV5IGp1 c3QNCj4+Pj4+Pj4+Pj4gdXNlIGlldGYtYmZkLXR5cGVzLnlhbmc/IEnigJlkIGxpa2UgdG8gYXZv aWQgdGhlIHVubmVjZXNzYXJ5DQo+Pj4+Pj4+Pj4+IGxldmVscyBvZiBpbmRpcmVjdGlvbi4gSW4g ZmFjdCwgaXQgbG9va3Mgd3JvbmcgdG8gbWUgc2luY2UgdGhlDQo+Pj4+Pj4+Pj4+IGdyb3VwaW5n IGJmZC1jbGllbnQtZXh0LWNmZy1wYXJtcyB1c2VzIHRoZSBncm91cGluZw0KPj4+Pj4+Pj4+PiBi ZmQtZ3JvdXBpbmctYmFzZS1jZmctcGFybXMgd2hpY2ggb25seSBjb250YWlucyB0aGUgZW5hYmxl ZA0KPj4+Pj4+Pj4+PiBsZWFmLiBJIGJlbGlldmUgeW91IG1lYW50IHRvIHVzZSBiZmQtZ3JvdXBp bmctY29tbW9uLWNmZy1wYXJtcw0KPj4+Pj4+Pj4+PiBpbiB0aGUgb3RoZXIgbmV3IG1vZGVsLiBI b3dldmVyLCBJIGRvbuKAmXQgc2VlIGFueSByZWFzb24gd2h5DQo+Pj4+Pj4+Pj4+IGNsaWVudCBz aG91bGRu4oCZdCB1c2UgdGhpcyBkaXJlY3RseS4NCj4+Pj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+ Pj4+PiBBY2VlDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBPbiA3LzI1LzE3LCAyOjMzIFBNLCAi UmVzaGFkIFJhaG1hbiAocnJhaG1hbikiDQo+Pj4+Pj4+Pj4+IDxycmFobWFuQGNpc2NvLmNvbT4N Cj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gSGkgWWluZ3poZW4s DQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFRoZSBncm91cGluZyBpcyBhdmFpbGFibGUgQA0K Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2poYWFzLXBmcmMvaWV0Zi1iZmQteWFuZy9i bG9iL21hc3Rlci9zcmMveWFuDQo+Pj4+Pj4+Pj4+PiBnL2lldA0KPj4+Pj4+Pj4+Pj4gZg0KPj4+ Pj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4+Pj4gYg0KPj4+Pj4+Pj4+Pj4gZg0KPj4+Pj4+Pj4+Pj4gZA0K Pj4+Pj4+Pj4+Pj4gLQ0KPj4+Pj4+Pj4+Pj4gYw0KPj4+Pj4+Pj4+Pj4gbGllbnRzLnlhbmcNCj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gSWYgeW91wrlkIGxpa2UgY2hhbmdlcyB0byB0aGUgZ3Jv dXBpbmcsIHNlbmQgbWUgYW4gZW1haWwuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IFJlZ2Fy ZHMsDQo+Pj4+Pj4+Pj4+PiBSZXNoYWQuDQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IE9uIDIw MTctMDctMjEsIDEyOjIyIFBNLCAiWWluZ3poZW4gUXUiIDx5aW5nemhlbi5xdUBodWF3ZWkuY29t Pg0KPj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBIaSBSZXNo YWQsDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgc3VtbWFyeS4N Cj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBCb3RoIG9zcGYgYW5kIGlzaXMgbW9kZWxzIHdp bGwgbWFrZSBjb3JyZXNwb25kaW5nIGNoYW5nZXMgd2hlbg0KPj4+Pj4+Pj4+Pj4+IHRoZSBuZXcg QkZEIGdyb3VwaW5nIGlzIGF2YWlsYWJsZS4NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBU aGFua3MsDQo+Pj4+Pj4+Pj4+Pj4gWWluZ3poZW4NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+IEZyb206IFJlc2hhZCBS YWhtYW4gKHJyYWhtYW4pIFttYWlsdG86cnJhaG1hbkBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+Pj4g U2VudDogVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgNzoxOSBBTQ0KPj4+Pj4+Pj4+Pj4+IFRvOiBK ZWZmcmV5IEhhYXMgPGpoYWFzQHBmcmMub3JnPjsgcnRnLWJmZEBpZXRmLm9yZw0KPj4+Pj4+Pj4+ Pj4+IENjOiBkcmFmdC1pZXRmLWJmZC15YW5nQGlldGYub3JnOw0KPj4+Pj4+Pj4+Pj4+IGRyYWZ0 LWlldGYtb3NwZi15YW5nQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtYmZkLXlhbmctMDYudHh0DQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4gV2UgKEJGRCBhbmQgT1NQRiBZQU5HIGF1dGhvcnMpIGhhZCBhIGRpc2N1c3Npb24geWVz dGVyZGF5Lg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFRoZSBhZ3JlZW1lbnQgaXMgdGhh dCBzaW5jZSBJR1AgcGVlcnMgYXJlIGF1dG8tZGlzY292ZXJlZCwgd2UNCj4+Pj4+Pj4+Pj4+PiB3 YW50IHRvIGFkZCBiYWNrIHRoZSBiYXNpYyBCRkQgY29uZmlnIChtdWx0aXBsaWVyICsgaW50ZXJ2 YWxzKQ0KPj4+Pj4+Pj4+Pj4+IGluIElHUCB2aWEgYSBncm91cGluZy4NCj4+Pj4+Pj4+Pj4+PiBC RkQgd2lsbCBwcm92aWRlIHRoYXQgZ3JvdXBpbmcgaW4gYSBzcGVjaWZpYyBZQU5HIG1vZHVsZS4g SUdQDQo+Pj4+Pj4+Pj4+Pj4gQkZEIFlBTkcgd2lsbCBiZSBpbiBhIHNlcGFyYXRlIG1vZHVsZSAo c2VwYXJhdGUgZnJvbSB0aGUgbWFpbg0KPj4+Pj4+Pj4+Pj4+IElHUCBtb2R1bGUpLg0KPj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+Pj4+ Pj4gUmVzaGFkLg0KPj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IE9uIDIwMTctMDctMDUsIDEy OjIxIFBNLCAiUnRnLWJmZCBvbiBiZWhhbGYgb2YgSmVmZnJleSBIYWFzIg0KPj4+Pj4+Pj4+Pj4+ IDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpoYWFzQHBmcmMub3JnPiB3 cm90ZToNCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gVGhhbmtzIGF1dGhvcnMgZm9yIHRo ZSBlZGl0cyBvbiB0aGUgQkZEIHlhbmcgbW9kdWxlLiAgVGhpcw0KPj4+Pj4+Pj4+Pj4+PiBnZXRz IHVzIGEgc2lnbmlmaWNhbnQgc3RlcCBjbG9zZXIgdG8gYWxpZ25tZW50IHdpdGggdGhlIHJlc3QN Cj4+Pj4+Pj4+Pj4+Pj4gb2YgSUVURiBmb3IgbmV0d29yayBpbnN0YW5jaW5nLg0KPj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gSSdkIGxpa2UgdG8gZW5jb3VyYWdlIHRoZSB3b3JraW5nIGdy b3VwIHRvIHByb3ZpZGUgZmVlZGJhY2sNCj4+Pj4+Pj4+Pj4+Pj4gb24gdGhpcyBpc3N1ZSBhbmQg YWxzbyB0aGUgY2hhbmdlcyBpbiB0aGUgbW9kdWxlLg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4+Pj4gQXMgbm90ZWQgaW4gYW5vdGhlciB0aHJlYWQsIHdlIHN0aWxsIGhhdmUgdG8gZmlndXJl IG91dCBob3cNCj4+Pj4+Pj4+Pj4+Pj4gdG8gZGVhbCB3aXRoIGFjY29tbW9kYXRpbmcgaW50ZXJh Y3Rpb24gb2YgdGhlIEJGRCB5YW5nIG1vZHVsZQ0KPj4+Pj4+Pj4+Pj4+PiB3aXRoIGNsaWVudCBw cm90b2NvbHMuDQo+Pj4+Pj4+Pj4+Pj4+IEZvcg0KPj4+Pj4+Pj4+Pj4+PiBleGFtcGxlLCB0aGUg SUdQcy4gIEluIHBhcnRpY3VsYXIsIGhvdyBkbyB5b3UgY29uZmlndXJlIHRoZQ0KPj4+Pj4+Pj4+ Pj4+PiBwcm9wZXJ0aWVzIG9mIHRoZSBCRkQgc2Vzc2lvbnMgdGhhdCBtYXkgYmUgZHluYW1pY2Fs bHkNCj4+Pj4+Pj4+Pj4+Pj4gaW5zdGFudGlhdGVkIGJhc2VkIG9uIGNvbnRyb2wgcHJvdG9jb2wg YWN0aXZpdHk/DQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiAtLSBKZWZmDQo+Pj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+PiBPbiBGcmksIEp1biAzMCwgMjAxNyBhdCAxMjo1NTo1OVBN IC0wNzAwLA0KPj4+Pj4+Pj4+Pj4+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+Pj4+Pj4+ Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lDQo+Pj4+Pj4+Pj4+Pj4+PiBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+Pj4+Pj4+Pj4+Pj4+PiBUaGlzIGRyYWZ0IGlz IGEgd29yayBpdGVtIG9mIHRoZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcNCj4+Pj4+Pj4+Pj4+ Pj4+IERldGVjdGlvbiBvZiB0aGUgSUVURi4NCj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4gICAgICAgVGl0bGUgICAgICAgICAgIDogWUFORyBEYXRhIE1vZGVsIGZvciBCaWRpcmVjdGlv bmFsDQo+Pj4+Pj4+Pj4+Pj4+PiBGb3J3YXJkaW5nDQo+Pj4+Pj4+Pj4+Pj4+PiBEZXRlY3Rpb24g KEJGRCkNCj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJlc2hhZCBSYWht YW4NCj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIExpYW5zaHUgWmhlbmcN Cj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIE1haGVzaCBKZXRoYW5hbmRh bmkNCj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIFNhbnRvc2ggUGFsbGFn YXR0aQ0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgR3JlZyBNaXJza3kN Cj4+Pj4+Pj4+Pj4+Pj4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWJmZC15YW5nLTA2 LnR4dA0KPj4+Pj4+Pj4+Pj4+Pj4gCVBhZ2VzICAgICAgICAgICA6IDU5DQo+Pj4+Pj4+Pj4+Pj4+ PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0wNi0zMA0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+Pj4+Pj4+Pj4+ICBUaGlzIGRvY3VtZW50IGRlZmluZXMg YSBZQU5HIGRhdGEgbW9kZWwgdGhhdCBjYW4gYmUgdXNlZA0KPj4+Pj4+Pj4+Pj4+Pj4gdG8gY29u ZmlndXJlDQo+Pj4+Pj4+Pj4+Pj4+PiAgYW5kIG1hbmFnZSBCaWRpcmVjdGlvbmFsIEZvcndhcmRp bmcgRGV0ZWN0aW9uIChCRkQpLg0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+ Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJmZC15YW5nLw0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUg YXQ6DQo+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1iZmQteWFuZy0wNg0KPj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4+Pj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDoNCj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWJmZC15YW5nLTA2DQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+Pj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlDQo+Pj4+Pj4+Pj4+Pj4+PiB0aW1lIG9mIHN1Ym1pc3Npb24gIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZQ0KPj4+Pj4+Pj4+Pj4+Pj4gYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+ Pj4+Pj4+Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+Pj4+Pj4+ Pj4+PiANCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0K Pj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+PiANCj4+PiANCj4+PiBNYWhlc2ggSmV0aGFu YW5kYW5pDQo+Pj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4+PiANCj4+PiANCj4+PiANCj4+ PiA8aWV0Zi1vc3BmLWJmZC50cmVlPjxpZXRmLW9zcGYtYmZkLnlhbmc+DQo+Pg0KPj5NYWhlc2gg SmV0aGFuYW5kYW5pDQo+Pm1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+Pg0KPg0KDQo= From nobody Mon Jul 31 13:06:15 2017 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 A2C19131C8E; Mon, 31 Jul 2017 13:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 CJrimBlRDbsc; Mon, 31 Jul 2017 13:06:10 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 6A00B124B0A; Mon, 31 Jul 2017 13:06:10 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id q70so21816785oic.2; Mon, 31 Jul 2017 13:06:10 -0700 (PDT) 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=YCmIIyLCGgL8WAtgzWfXX/ArRjI9d5/z1+4JYLEEO8o=; b=AbsJ2cQFW7WSZBoObbB7u+n3hab2xVlEhHccLgChEiAR0VkQFsA1yK6k+7/FwDPW0X MRKMbl9liwp2ZKnjqvkelL4/RJ5xbTAAvKDCCnY6u/tx+k2gYLdm5OtALo+PkpZv0jMy DFWgHFgghC6nwY1WLlCl7obcutAo2LamMw6L6qOY9KeZaz771m8adtBehw7uaY60iygl b6TtpbDR7SBczZ07bWFS/2KjIh+ngNMPu+6mTtmIdySEjT24SPTIjT8uTA66f+VOWMSz WcgUASpIuHu7wp3lCOek9Xqb/r0d/27DtX+YkahzwPtgCzYRY/eINIuKofQgN+QlrBjg bsqQ== 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=YCmIIyLCGgL8WAtgzWfXX/ArRjI9d5/z1+4JYLEEO8o=; b=Sks/9LMFcRf5AVLsxh69YVEpt0oBWlN++XnRf8gbr/iX7S3STeZWHIMSj6A4rEBl+7 1fFPA563bHgd8ROcKHoIr0WXBSUC9CWeEv7pTOaVCUUK4hCvBH2hhgsZpcCzeZcSgHyr CBL2YlvJf19xM0g4C3yFV2l7JOJmxey5zoUeN0Y9PvOECNeaevDcuhPf708PJqfF0N0s MycsE0YJRebYRhLWM5QJ5HwpV4s4oSWg29fmJ82A1UJVsC3oHPrGeZLD14udHX8e2gAo xn50eM5xaHV5bNqa0HhdPp/OqsrkFgpMeXuFYFZHjf/GoKh/GzkUCIzP2zo7oTWD+PAP dhKA== X-Gm-Message-State: AIVw111vJ1ed4hSmaovFw19f1Y6skh5hhv4kHGA+cyWms7ObVZCpobiG jzk/IHywLqCOjQ== X-Received: by 10.202.204.216 with SMTP id c207mr16926075oig.211.1501531569550; Mon, 31 Jul 2017 13:06:09 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:a4d9:8b58:f92c:ca51? ([2001:420:30d:1320:a4d9:8b58:f92c:ca51]) by smtp.gmail.com with ESMTPSA id x23sm29794937oix.51.2017.07.31.13.06.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Jul 2017 13:06:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: <594D005A3CB0724DB547CF3E9A9E810B538BE7@dfweml501-mbx> Date: Mon, 31 Jul 2017 13:06:32 -0700 Cc: "Acee Lindem (acee)" , Reshad Rahman , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8B853093-0558-44B2-916A-F181D47D433B@gmail.com> References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> <594D005A3CB0724DB547CF3E9A9E810B538BE7@dfweml501-mbx> To: Yingzhen Qu X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 20:06:13 -0000 Yingzhen, How do you plan to indicate to the BFD engine that the session is = enabled? > On Jul 31, 2017, at 10:26 AM, Yingzhen Qu = wrote: >=20 > Hi Mahesh, >=20 > For the enable flag, I'd prefer to have it defined directly in ospf = instead of using a grouping from BFD. I'm not sure how useful this = grouping is, am I missing something? >=20 > Thanks, > Yingzhen >=20 > -----Original Message----- > From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]=20 > Sent: Sunday, July 30, 2017 9:43 PM > To: Yingzhen Qu > Cc: Acee Lindem (acee) ; Reshad Rahman = ; Jeffrey Haas ; rtg-bfd@ietf.org; = draft-ietf-bfd-yang@ietf.org; draft-ietf-ospf-yang@ietf.org > Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >=20 > Yingzhen, >=20 > Overall the model looks good to me. >=20 > I notice that you decided to (re)define the enable flag in the model. = Is that intentional? >=20 > You are aware that there is another grouping called = client-base-cfg-parms that defines the enabled flag. I am not a = particular fan of this split, but I am told that some client protocols = just need the enable flag without the rest of the parameters of = client-cfg-parms. If the split is confusing, we can collapse the enabled = flag into client-cfg-parms. >=20 > Thanks. >=20 >> On Jul 30, 2017, at 10:14 AM, Yingzhen Qu = wrote: >>=20 >> Hi all, >>=20 >> Please see attached ospf bfd module. Base ospf module also needs to = be updated to remove the bfd enable leaf. ISIS model need to do the same = change, ietf-isis-bfd.yang will look the same as ietf-ospf-bfd.yang. >>=20 >> Please let me know your commetns. >>=20 >> Thanks, >> Yingzhen >>=20 >> -----Original Message----- >> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >> Sent: Friday, July 28, 2017 2:25 PM >> To: Acee Lindem (acee) >> Cc: Reshad Rahman ; Yingzhen Qu=20 >> ; Jeffrey Haas ;=20 >> rtg-bfd@ietf.org; draft-ietf-bfd-yang@ietf.org;=20 >> draft-ietf-ospf-yang@ietf.org >> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>=20 >> Would it not be better to call bfd-grouping-base-cfg-parms something = like bfd-grouping-client-cfg-params or more simply client-cfg-params. We = know it is a grouping and we know it is a bfd grouping. Why repeat? >>=20 >>> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) = wrote: >>>=20 >>> Hi Reshad, >>>=20 >>> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms = groupings. >>> Fewer similar grouping and modules will be better ;^) >>>=20 >>> Thanks, >>> Acee >>>=20 >>> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" = wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> What I see @ >>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet >>>> f >>>> -bfd- >>>> t >>>> ypes.yang: >>>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this=20 >>>> grouping is defined twice, this will be fixed when I get rid of=20 >>>> ietf-bfd-clients.yang >>>> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>>=20 >>>> Let me get rid of the client module and have everything in the = types=20 >>>> module. >>>>=20 >>>> I am not sure why you=E2=80=99re not seeing something different. >>>>=20 >>>> Regards, >>>> Reshad. >>>>=20 >>>>=20 >>>>=20 >>>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" = wrote: >>>>=20 >>>>> Hi Reshad, >>>>>=20 >>>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" = wrote: >>>>>=20 >>>>>> Hi Acee, >>>>>>=20 >>>>>> 1) I=E2=80=99ll see if others chime in on this but I am fine with = having=20 >>>>>> the client grouping in ietf-bfd-types.yang. >>>>>> 2) bfd-grouping-common-cfg-parms has much more than just the=20 >>>>>> multiplier/timers that the IGPs need. It also has BFD specific=20 >>>>>> stuff (demand-mode, BFD auth) which IMO has no business outside = of BFD. >>>>>=20 >>>>> Agreed.=20 >>>>>=20 >>>>>=20 >>>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>>=20 >>>>> Perhaps, the addition of multiplier/timers to=20 >>>>> bfd-grouping-base-cfg-parms isn=E2=80=99t pushed to GitHub yet. = This=20 >>>>> version=20 >>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ie >>>>> t >>>>> f-bfd >>>>> - >>>>> t >>>>> ypes.yang only has the enabled leaf. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Reshad. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" = wrote: >>>>>>=20 >>>>>>> Hi Reshad, >>>>>>>=20 >>>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)"=20 >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Acee, >>>>>>>>=20 >>>>>>>> When we met we agreed to have a new model for clients.=20 >>>>>>>> Afterwards I decided to create a new types module, and still=20 >>>>>>>> went ahead with the clients module. I am fine with having=20 >>>>>>>> everything in the types module (no client module). >>>>>>>=20 >>>>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99t= see that=20 >>>>>>> putting the client config params in wrappers provides any = benefit. >>>>>>> As for detriments, it requires more one more local modules for=20= >>>>>>> validation and one more level of indirection to see what we are=20= >>>>>>> really allowing to be configured. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am not sure I fully understand your comment/question on=20 >>>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The=20 >>>>>>>> reason we have >>>>>>>> 2 groupings is that some protocols may decide to have just the=20= >>>>>>>> enable leaf and others may also want the multiplier/timer. >>>>>>>=20 >>>>>>> The bfd-client-ext-cfg-parms grouping should use=20 >>>>>>> bfd-types:bfd-grouping-common-cfg-parms rather than=20 >>>>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more=20 >>>>>>> obvious w/o the client module. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Acee >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Reshad. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" = wrote: >>>>>>>>=20 >>>>>>>>> Hi Reshad, >>>>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t = they=20 >>>>>>>>> just use ietf-bfd-types.yang? I=E2=80=99d like to avoid the = unnecessary=20 >>>>>>>>> levels of indirection. In fact, it looks wrong to me since the=20= >>>>>>>>> grouping bfd-client-ext-cfg-parms uses the grouping=20 >>>>>>>>> bfd-grouping-base-cfg-parms which only contains the enabled=20 >>>>>>>>> leaf. I believe you meant to use bfd-grouping-common-cfg-parms=20= >>>>>>>>> in the other new model. However, I don=E2=80=99t see any = reason why=20 >>>>>>>>> client shouldn=E2=80=99t use this directly. >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>>>>=20 >>>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)"=20 >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Yingzhen, >>>>>>>>>>=20 >>>>>>>>>> The grouping is available @ >>>>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/ya >>>>>>>>>> n >>>>>>>>>> g/iet >>>>>>>>>> f >>>>>>>>>> - >>>>>>>>>> b >>>>>>>>>> f >>>>>>>>>> d >>>>>>>>>> - >>>>>>>>>> c >>>>>>>>>> lients.yang >>>>>>>>>>=20 >>>>>>>>>> If you=C2=B9d like changes to the grouping, send me an email. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Reshad. >>>>>>>>>>=20 >>>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu"=20 >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Reshad, >>>>>>>>>>>=20 >>>>>>>>>>> Thanks for the summary. >>>>>>>>>>>=20 >>>>>>>>>>> Both ospf and isis models will make corresponding changes=20 >>>>>>>>>>> when the new BFD grouping is available. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, >>>>>>>>>>> Yingzhen >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org;=20 >>>>>>>>>>> draft-ietf-ospf-yang@ietf.org >>>>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>>=20 >>>>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>>=20 >>>>>>>>>>> The agreement is that since IGP peers are auto-discovered, = we=20 >>>>>>>>>>> want to add back the basic BFD config (multiplier +=20 >>>>>>>>>>> intervals) in IGP via a grouping. >>>>>>>>>>> BFD will provide that grouping in a specific YANG module. = IGP=20 >>>>>>>>>>> BFD YANG will be in a separate module (separate from the = main=20 >>>>>>>>>>> IGP module). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Reshad. >>>>>>>>>>>=20 >>>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey Haas" >>>>>>>>>>> = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Thanks authors for the edits on the BFD yang module. This=20= >>>>>>>>>>>> gets us a significant step closer to alignment with the = rest=20 >>>>>>>>>>>> of IETF for network instancing. >>>>>>>>>>>>=20 >>>>>>>>>>>> I'd like to encourage the working group to provide feedback=20= >>>>>>>>>>>> on this issue and also the changes in the module. >>>>>>>>>>>>=20 >>>>>>>>>>>> As noted in another thread, we still have to figure out how=20= >>>>>>>>>>>> to deal with accommodating interaction of the BFD yang=20 >>>>>>>>>>>> module with client protocols. >>>>>>>>>>>> For >>>>>>>>>>>> example, the IGPs. In particular, how do you configure the=20= >>>>>>>>>>>> properties of the BFD sessions that may be dynamically=20 >>>>>>>>>>>> instantiated based on control protocol activity? >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Jeff >>>>>>>>>>>>=20 >>>>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700,=20 >>>>>>>>>>>> internet-drafts@ietf.org >>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A New Internet-Draft is available from the on-line=20 >>>>>>>>>>>>> Internet-Drafts directories. >>>>>>>>>>>>> This draft is a work item of the Bidirectional Forwarding=20= >>>>>>>>>>>>> Detection of the IETF. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>>> Forwarding >>>>>>>>>>>>> Detection (BFD) >>>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>> Pages : 59 >>>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> This document defines a YANG data model that can be used=20= >>>>>>>>>>>>> to configure and manage Bidirectional Forwarding = Detection=20 >>>>>>>>>>>>> (BFD). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-0 >>>>>>>>>>>>> 6 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Please note that it may take a couple of minutes from the=20= >>>>>>>>>>>>> time of submission until the htmlized version and diff = are=20 >>>>>>>>>>>>> available at tools.ietf.org. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >> >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jul 31 13:06:36 2017 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 E0E66131C9C; Mon, 31 Jul 2017 13:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TcdvzY7gm83W; Mon, 31 Jul 2017 13:06:32 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 997DF124B0A; Mon, 31 Jul 2017 13:06:25 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id j194so19706731oib.4; Mon, 31 Jul 2017 13:06:25 -0700 (PDT) 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=Fk8EKHsIZi5aqBBDu36xFzYbpggJgzZJPSKSY33AF1w=; b=GQrivQom7+n/3mkbhOHyAqsCoTNs0ponzrcUQ+njSg0MeHtMjuaes/Gmvq9qX2UyJ2 iHRGydvR3fMFXZw3i+9cRkkcYhiavfnFxTPMWuoIFwS/jRMkHzby9PwK89PYQbh9XA8F OHVxzhf+AXwBpHqjTYeSl6xHG4qv0gw5nGM6aLLCzSM7swS8KNq+Q0LoRVzYRt8QVakw RcHHn95/YL/3PzTPLgA3uqNlEWLyH0PSR9V0dbH3ITOBWE8Bm6F9pajyRUiu2DspDhyb B3Slg+Uh8klZowIbmtTJGceVT5NJu3LGRVAeSv8SNUiTYWqgsQ8TZrge6qku0TnM5WCH Igzw== 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=Fk8EKHsIZi5aqBBDu36xFzYbpggJgzZJPSKSY33AF1w=; b=dY3ucGV/Wc6fp2NJsuADrqUn1asUwBBwQjIosppkkP2JtpfVKFAW+pv/wYAB45JkDa jPXEQjAg7mKasLvkyatW4WcJuencalBseHbx3RxRjg5XEmRITrU5SO1o9md/B0hd0rFY +0C3uLncHWWjpnmXlNbHhjTZM+WUfwBWmaHfy6gF/GvGWQp+WaU/Q+T7JxWMKGgYR1xm 8Jy2IkSYrh9awVjvyN6sQ04gONaQF0ax0+5xWbLv9Yhs2zgT8A1s9/YtZ2eXfBSTZFh4 Vpb7pMlgm2yeHQsNzXqw7hN56c2ZdmVxE8UIASwI6CguWW03oNrvP1EOPzWLVj8tPfA6 T5Rg== X-Gm-Message-State: AIVw113yM/JjcK4OPK/ZO7jXklPDWVqjg2YRSz+olQAo8XwH8Ly9qdgT If8rvMP0IDreMw== X-Received: by 10.202.198.23 with SMTP id w23mr14281925oif.168.1501531584878; Mon, 31 Jul 2017 13:06:24 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:a4d9:8b58:f92c:ca51? ([2001:420:30d:1320:a4d9:8b58:f92c:ca51]) by smtp.gmail.com with ESMTPSA id x23sm29794937oix.51.2017.07.31.13.06.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Jul 2017 13:06:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: Date: Mon, 31 Jul 2017 13:06:49 -0700 Cc: Yingzhen Qu , Reshad Rahman , Jeffrey Haas , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <149885255897.4584.3006333522740435620@ietfa.amsl.com> <20170705162103.GQ2289@pfrc.org> <594D005A3CB0724DB547CF3E9A9E810B5227CF@dfweml501-mbb> <594D005A3CB0724DB547CF3E9A9E810B5388E1@dfweml501-mbx> <0CF89DCC-4DC1-414C-8D13-51106B10D6F7@gmail.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 20:06:35 -0000 Ok. Will do. > On Jul 31, 2017, at 12:05 PM, Acee Lindem (acee) = wrote: >=20 > Sigh, I mean =E2=80=9Cwhy don=E2=80=99t you add =E2=80=98enabled=E2=80=99= =E2=80=A6" >=20 > On 7/31/17, 2:56 PM, "Acee Lindem (acee)" wrote: >=20 >> Hi Mahesh,=20 >>=20 >> On 7/31/17, 12:42 AM, "Mahesh Jethanandani" >> wrote: >>=20 >>> Yingzhen, >>>=20 >>> Overall the model looks good to me. >>>=20 >>> I notice that you decided to (re)define the enable flag in the = model. Is >>> that intentional? >>>=20 >>> You are aware that there is another grouping called = client-base-cfg-parms >>> that defines the enabled flag. I am not a particular fan of this = split, >>> but I am told that some client protocols just need the enable flag >>> without the rest of the parameters of client-cfg-parms. If the split = is >>> confusing, we can collapse the enabled flag into client-cfg-parms. >>=20 >> I don=E2=80=99t add =E2=80=98enabled=E2=80=99 to the = client-cfg-parms? Then a client would only >> need a single grouping. >=20 >=20 >>=20 >> Thanks, >> Acee=20 >>=20 >>>=20 >>> Thanks. >>>=20 >>>> On Jul 30, 2017, at 10:14 AM, Yingzhen Qu >>>> wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> Please see attached ospf bfd module. Base ospf module also needs to = be >>>> updated to remove the bfd enable leaf. ISIS model need to do the = same >>>> change, ietf-isis-bfd.yang will look the same as = ietf-ospf-bfd.yang. >>>>=20 >>>> Please let me know your commetns. >>>>=20 >>>> Thanks, >>>> Yingzhen >>>>=20 >>>> -----Original Message----- >>>> From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] >>>> Sent: Friday, July 28, 2017 2:25 PM >>>> To: Acee Lindem (acee) >>>> Cc: Reshad Rahman ; Yingzhen Qu >>>> ; Jeffrey Haas ; >>>> rtg-bfd@ietf.org; draft-ietf-bfd-yang@ietf.org; >>>> draft-ietf-ospf-yang@ietf.org >>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>=20 >>>> Would it not be better to call bfd-grouping-base-cfg-parms = something >>>> like bfd-grouping-client-cfg-params or more simply = client-cfg-params. We >>>> know it is a grouping and we know it is a bfd grouping. Why repeat? >>>>=20 >>>>> On Jul 27, 2017, at 7:34 PM, Acee Lindem (acee) >>>>> wrote: >>>>>=20 >>>>> Hi Reshad, >>>>>=20 >>>>> Ok - I see now. I was looking at the wrong xxxx-base-cfg-parms >>>>> groupings. >>>>> Fewer similar grouping and modules will be better ;^) >>>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>> On 7/27/17, 9:03 PM, "Reshad Rahman (rrahman)" >>>>> wrote: >>>>>=20 >>>>>> Hi Acee, >>>>>>=20 >>>>>> What I see @ >>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/ietf >>>>>> -bfd- >>>>>> t >>>>>> ypes.yang: >>>>>> 1) bfd-client-base-cfg-parms has leaf enabled only. BTW this = grouping >>>>>> is defined twice, this will be fixed when I get rid of >>>>>> ietf-bfd-clients.yang >>>>>> 2) bfd-grouping-base-cfg-parms has multiplier/timers. >>>>>>=20 >>>>>> Let me get rid of the client module and have everything in the = types >>>>>> module. >>>>>>=20 >>>>>> I am not sure why you=E2=80=99re not seeing something different. >>>>>>=20 >>>>>> Regards, >>>>>> Reshad. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 2017-07-27, 3:40 PM, "Acee Lindem (acee)" = wrote: >>>>>>=20 >>>>>>> Hi Reshad, >>>>>>>=20 >>>>>>> On 7/27/17, 3:35 PM, "Reshad Rahman (rrahman)" = >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi Acee, >>>>>>>>=20 >>>>>>>> 1) I=E2=80=99ll see if others chime in on this but I am fine = with having >>>>>>>> the client grouping in ietf-bfd-types.yang. >>>>>>>> 2) bfd-grouping-common-cfg-parms has much more than just the >>>>>>>> multiplier/timers that the IGPs need. It also has BFD specific >>>>>>>> stuff (demand-mode, BFD auth) which IMO has no business outside = of >>>>>>>> BFD. >>>>>>>=20 >>>>>>> Agreed.=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> bfd-grouping-base-cfg-parms has only the multiplier/timers. >>>>>>>=20 >>>>>>> Perhaps, the addition of multiplier/timers to >>>>>>> bfd-grouping-base-cfg-parms isn=E2=80=99t pushed to GitHub yet. = This version >>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yang/iet >>>>>>> f-bfd >>>>>>> - >>>>>>> t >>>>>>> ypes.yang only has the enabled leaf. >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Acee >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Reshad. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 2017-07-27, 3:30 PM, "Acee Lindem (acee)" >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Reshad, >>>>>>>>>=20 >>>>>>>>> On 7/27/17, 3:19 PM, "Reshad Rahman (rrahman)" = >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Acee, >>>>>>>>>>=20 >>>>>>>>>> When we met we agreed to have a new model for clients. = Afterwards >>>>>>>>>> I decided to create a new types module, and still went ahead = with >>>>>>>>>> the clients module. I am fine with having everything in the = types >>>>>>>>>> module (no client module). >>>>>>>>>=20 >>>>>>>>> Although I don=E2=80=99t feel that strongly - I just don=E2=80=99= t see that >>>>>>>>> putting the client config params in wrappers provides any = benefit. >>>>>>>>> As for detriments, it requires more one more local modules for >>>>>>>>> validation and one more level of indirection to see what we = are >>>>>>>>> really allowing to be configured. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I am not sure I fully understand your comment/question on >>>>>>>>>> bfd-client-ext-cfg-parms/bfd-grouping-common-cfg-parms. The >>>>>>>>>> reason we have >>>>>>>>>> 2 groupings is that some protocols may decide to have just = the >>>>>>>>>> enable leaf and others may also want the multiplier/timer. >>>>>>>>>=20 >>>>>>>>> The bfd-client-ext-cfg-parms grouping should use >>>>>>>>> bfd-types:bfd-grouping-common-cfg-parms rather than >>>>>>>>> bfd-types:bfd-client-base-cfg-parms - no? This would be more >>>>>>>>> obvious w/o the client module. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Acee >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Reshad. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 2017-07-27, 3:07 PM, "Acee Lindem (acee)" >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Reshad, >>>>>>>>>>> Why do we need a new YANG model for clients? Why can=E2=80=99t= they just >>>>>>>>>>> use ietf-bfd-types.yang? I=E2=80=99d like to avoid the = unnecessary >>>>>>>>>>> levels of indirection. In fact, it looks wrong to me since = the >>>>>>>>>>> grouping bfd-client-ext-cfg-parms uses the grouping >>>>>>>>>>> bfd-grouping-base-cfg-parms which only contains the enabled >>>>>>>>>>> leaf. I believe you meant to use = bfd-grouping-common-cfg-parms >>>>>>>>>>> in the other new model. However, I don=E2=80=99t see any = reason why >>>>>>>>>>> client shouldn=E2=80=99t use this directly. >>>>>>>>>>> Thanks, >>>>>>>>>>> Acee >>>>>>>>>>>=20 >>>>>>>>>>> On 7/25/17, 2:33 PM, "Reshad Rahman (rrahman)" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi Yingzhen, >>>>>>>>>>>>=20 >>>>>>>>>>>> The grouping is available @ >>>>>>>>>>>> = https://github.com/jhaas-pfrc/ietf-bfd-yang/blob/master/src/yan >>>>>>>>>>>> g/iet >>>>>>>>>>>> f >>>>>>>>>>>> - >>>>>>>>>>>> b >>>>>>>>>>>> f >>>>>>>>>>>> d >>>>>>>>>>>> - >>>>>>>>>>>> c >>>>>>>>>>>> lients.yang >>>>>>>>>>>>=20 >>>>>>>>>>>> If you=C2=B9d like changes to the grouping, send me an = email. >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>> Reshad. >>>>>>>>>>>>=20 >>>>>>>>>>>> On 2017-07-21, 12:22 PM, "Yingzhen Qu" = >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Reshad, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks for the summary. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Both ospf and isis models will make corresponding changes = when >>>>>>>>>>>>> the new BFD grouping is available. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Yingzhen >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Reshad Rahman (rrahman) [mailto:rrahman@cisco.com] >>>>>>>>>>>>> Sent: Thursday, July 20, 2017 7:19 AM >>>>>>>>>>>>> To: Jeffrey Haas ; rtg-bfd@ietf.org >>>>>>>>>>>>> Cc: draft-ietf-bfd-yang@ietf.org; >>>>>>>>>>>>> draft-ietf-ospf-yang@ietf.org >>>>>>>>>>>>> Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>>=20 >>>>>>>>>>>>> We (BFD and OSPF YANG authors) had a discussion yesterday. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The agreement is that since IGP peers are auto-discovered, = we >>>>>>>>>>>>> want to add back the basic BFD config (multiplier + = intervals) >>>>>>>>>>>>> in IGP via a grouping. >>>>>>>>>>>>> BFD will provide that grouping in a specific YANG module. = IGP >>>>>>>>>>>>> BFD YANG will be in a separate module (separate from the = main >>>>>>>>>>>>> IGP module). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Reshad. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 2017-07-05, 12:21 PM, "Rtg-bfd on behalf of Jeffrey = Haas" >>>>>>>>>>>>> = wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks authors for the edits on the BFD yang module. = This >>>>>>>>>>>>>> gets us a significant step closer to alignment with the = rest >>>>>>>>>>>>>> of IETF for network instancing. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I'd like to encourage the working group to provide = feedback >>>>>>>>>>>>>> on this issue and also the changes in the module. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As noted in another thread, we still have to figure out = how >>>>>>>>>>>>>> to deal with accommodating interaction of the BFD yang = module >>>>>>>>>>>>>> with client protocols. >>>>>>>>>>>>>> For >>>>>>>>>>>>>> example, the IGPs. In particular, how do you configure = the >>>>>>>>>>>>>> properties of the BFD sessions that may be dynamically >>>>>>>>>>>>>> instantiated based on control protocol activity? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- Jeff >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Fri, Jun 30, 2017 at 12:55:59PM -0700, >>>>>>>>>>>>>> internet-drafts@ietf.org >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>>>>>> Internet-Drafts directories. >>>>>>>>>>>>>>> This draft is a work item of the Bidirectional = Forwarding >>>>>>>>>>>>>>> Detection of the IETF. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Title : YANG Data Model for Bidirectional >>>>>>>>>>>>>>> Forwarding >>>>>>>>>>>>>>> Detection (BFD) >>>>>>>>>>>>>>> Authors : Reshad Rahman >>>>>>>>>>>>>>> Lianshu Zheng >>>>>>>>>>>>>>> Mahesh Jethanandani >>>>>>>>>>>>>>> Santosh Pallagatti >>>>>>>>>>>>>>> Greg Mirsky >>>>>>>>>>>>>>> Filename : draft-ietf-bfd-yang-06.txt >>>>>>>>>>>>>>> Pages : 59 >>>>>>>>>>>>>>> Date : 2017-06-30 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>>> This document defines a YANG data model that can be used >>>>>>>>>>>>>>> to configure >>>>>>>>>>>>>>> and manage Bidirectional Forwarding Detection (BFD). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> There are also htmlized versions available at: >>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-bfd-yang-06 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-yang-06= >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Please note that it may take a couple of minutes from = the >>>>>>>>>>>>>>> time of submission until the htmlized version and diff = are >>>>>>>>>>>>>>> available at tools.ietf.org. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>>=20 >>>>=20 >>>>=20 >>>> >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >>=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jul 31 13:26:27 2017 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 C3251129B43; Mon, 31 Jul 2017 13:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4Kzy6XmwBc9R; Mon, 31 Jul 2017 13:26:24 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 86AAF1318A2; Mon, 31 Jul 2017 13:26:24 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id e124so24557667oig.0; Mon, 31 Jul 2017 13:26:24 -0700 (PDT) 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=bw2jitfn4GNU4rrkCbqH5HF5GkNkMJGzOdECRvehTuk=; b=pu8ivDqWxz5IJknfLUANlLYvTyQl9mLjFyluP1lxf8KwDtGZDA34YaNr+zWEbsfK/l kL2rG7U01YgYsM+fidIUbZnxZJ9MkhKf0Kvw6l5yiALtr98AEPw0LAUAnM+nCVITtZId /PIdWTUYAGOR8n1VpGwdrgNiMqk2+1hGcyOU2HGBMIreaBzHyLZpZ5UbEYTDcQeeLSw9 Ozb8N9x7ToTg23WRGmaExPL2J/jdEtETj47rNiyLOluERKaGbt5BW/TZ3wNjx7t5q0PW RCMNrBOYVimyAZT2e4vYTxAOHI4KschWqUi64sgY/Q6dpoc4ak9dXW0wpM9dXk35q3Fs v9nA== 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=bw2jitfn4GNU4rrkCbqH5HF5GkNkMJGzOdECRvehTuk=; b=LlfHELslw4yHo7WG2ypFdD+7VVFS1Yxqpj3+9GUQ+fhcgGnizh5VQ+jbLFeWbick/y JHZ9hB3llwUA1PGEjDGzeMOCDeLO5ONpx/hkVJoRIBa0/9GyFuNo8yhJUW28wQmLnxGQ 5eEDziBmjRGOaBrujef7v5HId9KADbbXPfGi76NkCfDA0UyA0t/naEdMNKLe3R7uiW/p ZL0rQSZ4qy2uPi9W4QRtKkxPDNWzN8LlxRa/9iPS5yiNVOpQZWJmQsQTXok/fWUQvwNu JP/Pd1tqPUhTtLLZH8H+nW/WvmimKnzq2qrDAXyQudiC6C+rTXjppVJWcAEZTJvZETKI h5CA== X-Gm-Message-State: AIVw112QJJM1GIHhfHm2+WfwxB0Y1kG+mkvRBGja3FjkYGKp0U4R+gNm nSDO0J3NPo9dY1NNx14F6Q== X-Received: by 10.202.184.8 with SMTP id i8mr10964724oif.266.1501532783964; Mon, 31 Jul 2017 13:26:23 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1320:a4d9:8b58:f92c:ca51? ([2001:420:30d:1320:a4d9:8b58:f92c:ca51]) by smtp.gmail.com with ESMTPSA id u77sm785183oie.0.2017.07.31.13.26.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Jul 2017 13:26:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: <20170731170550.GO24942@pfrc.org> Date: Mon, 31 Jul 2017 13:26:48 -0700 Cc: Yingzhen Qu , "Acee Lindem (acee)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , Reshad Rahman Content-Transfer-Encoding: quoted-printable Message-Id: References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 20:26:26 -0000 Jeff, > On Jul 31, 2017, at 10:05 AM, Jeffrey Haas wrote: >=20 > On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: >> The changes are done and pushed to GitHub. Use the grouping = client-cfg-parms. >=20 > Question: For implementations that use Echo mode, is that something = the > protocol client configuration impacts or is it chosen by the system > automatically? I am not sure I understand.=20 For Echo mode, there is a separate grouping called echo-cfg-parms that = allows clients to specify the desired-min-echo-tx-interval and = required-min-echo-rx-interval.=20 That is somehow different from desired-min-tx-interval and = required-min-rx-interval that one can specify for a normal BFD session. = For the life of me, I do not understand why the two need to be different = :-(. I must be getting amnesia. Maybe one of the co-authors will jog my = memory. Cheers. >=20 > -- jeff Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jul 31 13:55:52 2017 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 A4B5A1327C1; Mon, 31 Jul 2017 13:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 TB13y_enL3vi; Mon, 31 Jul 2017 13:55:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EC3AE1327C0; Mon, 31 Jul 2017 13:55:47 -0700 (PDT) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 1E66F1E37F; Mon, 31 Jul 2017 16:56:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Jeffrey Haas In-Reply-To: Date: Mon, 31 Jul 2017 16:55:46 -0400 Cc: Yingzhen Qu , "Acee Lindem (acee)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , Reshad Rahman Content-Transfer-Encoding: quoted-printable Message-Id: <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 20:55:51 -0000 Mahesh, > On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani = wrote: >=20 > Jeff, >=20 >> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas wrote: >>=20 >> On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: >>> The changes are done and pushed to GitHub. Use the grouping = client-cfg-parms. >>=20 >> Question: For implementations that use Echo mode, is that something = the >> protocol client configuration impacts or is it chosen by the system >> automatically? >=20 > I am not sure I understand.=20 >=20 > For Echo mode, there is a separate grouping called echo-cfg-parms that = allows clients to specify the desired-min-echo-tx-interval and = required-min-echo-rx-interval.=20 >=20 > That is somehow different from desired-min-tx-interval and = required-min-rx-interval that one can specify for a normal BFD session. = For the life of me, I do not understand why the two need to be different = :-(. I must be getting amnesia. Maybe one of the co-authors will jog my = memory. The protocol permits those values to be distinct from the async ones. = They should be in a separate set of params. My point, unless my very quick glance at the module mislead me, is that = you can't configure to use echo mode - if it's supported - in the = grouping imported by the IGPs. My implementation doesn't support echo, so I don't have any opinion = about where configuration of those belongs or not. -- Jeff >=20 > Cheers. >=20 >>=20 >> -- jeff >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 From nobody Mon Jul 31 14:40:01 2017 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 74E9D1327D7; Mon, 31 Jul 2017 14:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 YailkIxebRja; Mon, 31 Jul 2017 14:39:59 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010080.outbound.protection.outlook.com [40.92.10.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232341327D4; Mon, 31 Jul 2017 14:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gRC/vj5/1lZnT6xQF2Z0HSrF7gReXpFvYmwjQ8859aY=; b=XKUNhtJUi10SejJNeW6+7pURTQtjoT6ZzLzQj68AfssnCr2pyDRu1KoaYcfldqK6DzlkiQyAZyGUXSlJejGPXXvYw78ue+q6fAtb4w0+2oaOQYjM5bZnFW0KTfsJ1FluSMgL4IP9NNQ+C4Ll72KH+ZXCxzUPBL5rVFNCVHICuetxvPvq7UrTDEnf9j7MxFSxPuSI2G+wAOob3XMO3Wsp5CBtps59FExaquqUEG5Qfm73I35ACX5rr4ezZXaaIwFKZ6aw75M3Asw9sSEXw4Hlo1NJdo8i7pCpRLU/3kerX22GRJ+I15MqEPn8j/5o09o3yO2YZSOqzLuW7AQ1r3ZXIA== Received: from BN3NAM04FT048.eop-NAM04.prod.protection.outlook.com (10.152.92.60) by BN3NAM04HT044.eop-NAM04.prod.protection.outlook.com (10.152.92.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Mon, 31 Jul 2017 21:39:57 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com (10.152.92.56) by BN3NAM04FT048.mail.protection.outlook.com (10.152.92.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.16 via Frontend Transport; Mon, 31 Jul 2017 21:39:57 +0000 Received: from MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) by MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) with mapi id 15.01.1304.022; Mon, 31 Jul 2017 21:39:57 +0000 From: Ashesh Mishra To: Jeffrey Haas CC: Mahesh Jethanandani , Yingzhen Qu , Reshad Rahman , "draft-ietf-ospf-yang@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Topic: I-D Action: draft-ietf-bfd-yang-06.txt Thread-Index: AQHS8drr2gudd7mjA0mJsRZ0nBZEe6JFca6AgBdwwgCAAbTUAIAGbfGAgAMuT4CAAANMgIAAAvMAgAABiQCAAAFTAIAAWi4AgAAZqwCAATvhgIAABLoAgAAAeACAABSxAIAEVJMAgAA4JgCAAAgYAIAADFf7 Date: Mon, 31 Jul 2017 21:39:57 +0000 Message-ID: References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> , <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> In-Reply-To: <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:8FF838398BD7769D83C5FE0865D937965E494D9FBAB140F4C62D82EF11FA01CC; UpperCasedChecksum:0093C280E5F7895FC5F9E78C273610D73D44FE7129F80AD36136FEC99EE61066; SizeAsReceived:8006; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [eNofNZ9cmUyjvf3YjNDPyW78TplRZhZq] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM04HT044; 7:trPUIAESxWE6byIdRBLA4CtYensrbONFVMe/D5SXVAhLbRuesBrROspUN+i3VVrdRA6QhY5/2hjU3PPf7LMP9ftSC4tsA95AReOsmG/zKMesROu84qXSWZxq2lDZJQysj4WplDHJMr8fu65mcrwt0/qQ7D4Homx0sWrCSabC5LjtlRjQuiVG5jvQ0tTZfkvTx0uppwKQPrxyHn+JOqGTnFU9d9XXGVcxOxNq0suGnaFhAd3PQCEY64FaNciCrGlJTYu0AHsXwfb6APiuyVWpB9WlUd4mQaXskPSdMxlM0g8O3jpUFi/PRYf6hETEdcpeG0yV4Gf/pesmW3fCH19CJWUH4EqwdLWn5jjaAYcxPlPuHh73aL+tHoCmINW8Gm2jsgnQepkKy7T69sKZ0Iuzgln/V/SU2dKPrRWtho1z6uQbY11MerWG0P1+md6okWmD9gX9m8VobARDaiAzByV0OavXPP1TBdp9e7xm3djm83b1JWNBIay8exJaxB8gfdoUSUcbTnTU23QfNr1rKvpBS1mhJ8vmfijcmsxzn1nqWSeDqglbPE3/8MgsQwZqyccjjSBdCQ793Ctbq0OnEpAHQ5p8cI3abuBx92Hshy3E6E8bOif5PgQdcB6mMWI3NXw+atT4naJg4rzoY7T3YO6x0qhm89VM2TYFkUI5mu5PF2SkPqTJHeeu6iSS1Wmp02c6+SzREZQCo2eExHEtb9jpouFfLzlLJZZCnSP5IX/w2vEEmlAkHKymysYeT9tINPYz9OuGjsUpT33daw+m/rwINw== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM04HT044; H:MWHPR01MB2768.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: d51b0ecd-e627-4093-00a8-08d4d85cb04c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322377)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3NAM04HT044; x-ms-traffictypediagnostic: BN3NAM04HT044: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM04HT044; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM04HT044; x-forefront-prvs: 03853D523D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2017 21:39:57.1038 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT044 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 21:40:00 -0000 >From what I understand, the echo intervals have an inverse relationship wit= h their control interval counterparts. Faster echo allows for slower contro= l frame rate. So they are necessarily different values. That said, having n= ever implemented echo mode, I can't comment how they should get grouped in = the model. =20 Ashesh On Jul 31, 2017, at 4:56 PM, Jeffrey Haas wrote: Mahesh, > On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani wrote: >=20 > Jeff, >=20 >> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas wrote: >>=20 >> On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: >>> The changes are done and pushed to GitHub. Use the grouping client-cfg-= parms. >>=20 >> Question: For implementations that use Echo mode, is that something the >> protocol client configuration impacts or is it chosen by the system >> automatically? >=20 > I am not sure I understand.=20 >=20 > For Echo mode, there is a separate grouping called echo-cfg-parms that al= lows clients to specify the desired-min-echo-tx-interval and required-min-e= cho-rx-interval.=20 >=20 > That is somehow different from desired-min-tx-interval and required-min-r= x-interval that one can specify for a normal BFD session. For the life of m= e, I do not understand why the two need to be different :-(. I must be gett= ing amnesia. Maybe one of the co-authors will jog my memory. The protocol permits those values to be distinct from the async ones. They= should be in a separate set of params. My point, unless my very quick glance at the module mislead me, is that you= can't configure to use echo mode - if it's supported - in the grouping imp= orted by the IGPs. My implementation doesn't support echo, so I don't have any opinion about w= here configuration of those belongs or not. -- Jeff >=20 > Cheers. >=20 >>=20 >> -- jeff >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 From nobody Mon Jul 31 17:17:13 2017 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 87BAB12EC32; Mon, 31 Jul 2017 17:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sxkuXBKW1GvN; Mon, 31 Jul 2017 17:17:11 -0700 (PDT) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 EC63612EB99; Mon, 31 Jul 2017 17:17:10 -0700 (PDT) Received: by mail-pf0-x242.google.com with SMTP id t86so173754pfe.1; Mon, 31 Jul 2017 17:17:10 -0700 (PDT) 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:message-id:references :to; bh=OtEblL1GepQl+x4mZ3UGRx9DTrGwxh1WsJGzRg7jPNE=; b=oM2QS4qomYTB4hVRdKH6nUA0RgvoVh23rA8hndzgr2c68krICLokwP4Oe5q611/yPf Nk+H48B5d8okEVR4O4kFMF4nRYX3RqeN+g4diO4svbMNfEO2LViRXmCQm2dvTpzYBNJb R5wZJd5yMllIFlJWg6UwC2N00AOWqrsN/OA/p1q3bAiypbdA6bQSHOQdi9/ACFunpu/x 7S55fgha8z6EqdIqVL8UE1EpPzthhC/HDYz9B+KmSN4Xhey+ElzFkon491YrJpWk1dpu d4olX9e4nUIp0mu/fdnfC1hE7Ueqe5Xcor3fOQQ+pCQ7Ps5RJKCWypXEwlrlC9O9FKWn SzIg== 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 :message-id:references:to; bh=OtEblL1GepQl+x4mZ3UGRx9DTrGwxh1WsJGzRg7jPNE=; b=Kh7D1bJ3Zmw+PRcv7lpremg7gUJODFiF6ChPnIukt/iTky7ADR2Yk9fKSBC5e5lqyz 4t9/kJF1IizIK0thhjIa17hhFSEUzAx2HGjTAh12ssH1rHsOYSU/hBhyjeewGwVW+rHU JXEWg3i4L7ajUCkmv+E1MaZQguqPWA/1rq8EwJsfturcNenY+J7rdw/DOjoT3IRbZfnP 6m7CGrQldkj6QF4q3zNgc/BOEtP9VsaJCOGiRZRK/LWN7X8YfU1U/lkShcWttwXNA1p0 Hev+84+jbNbgaz4kP/mlagGLLwnweapCOahpsy4aRCjq9NZFBSlNeotEYP3Wc5uPhW60 e4gQ== X-Gm-Message-State: AIVw113cZCShhOA2xPAosBiiB5mwnnmT7YeBhOj4vzPu1VS4D8NXmUJw F5O7Sx1GSGAvTQ== X-Received: by 10.98.91.71 with SMTP id p68mr17400768pfb.209.1501546630487; Mon, 31 Jul 2017 17:17:10 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1254:d0c:e1af:5a13:d5a5? ([2001:420:30d:1254:d0c:e1af:5a13:d5a5]) by smtp.gmail.com with ESMTPSA id a87sm5997075pfg.18.2017.07.31.17.17.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 31 Jul 2017 17:17:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_42E005B0-01A5-4BBB-9D55-92DBCE085788" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt From: Mahesh Jethanandani In-Reply-To: <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> Date: Mon, 31 Jul 2017 17:17:34 -0700 Cc: Yingzhen Qu , "Acee Lindem (acee)" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-yang@ietf.org" , "draft-ietf-ospf-yang@ietf.org" , Reshad Rahman Message-Id: References: <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3124) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.22 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, 01 Aug 2017 00:17:13 -0000 --Apple-Mail=_42E005B0-01A5-4BBB-9D55-92DBCE085788 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2017, at 1:55 PM, Jeffrey Haas wrote: >=20 > Mahesh, >=20 >> On Jul 31, 2017, at 4:26 PM, Mahesh Jethanandani = wrote: >>=20 >> Jeff, >>=20 >>> On Jul 31, 2017, at 10:05 AM, Jeffrey Haas wrote: >>>=20 >>> On Fri, Jul 28, 2017 at 03:58:06PM -0700, Mahesh Jethanandani wrote: >>>> The changes are done and pushed to GitHub. Use the grouping = client-cfg-parms. >>>=20 >>> Question: For implementations that use Echo mode, is that something = the >>> protocol client configuration impacts or is it chosen by the system >>> automatically? >>=20 >> I am not sure I understand.=20 >>=20 >> For Echo mode, there is a separate grouping called echo-cfg-parms = that allows clients to specify the desired-min-echo-tx-interval and = required-min-echo-rx-interval.=20 >>=20 >> That is somehow different from desired-min-tx-interval and = required-min-rx-interval that one can specify for a normal BFD session. = For the life of me, I do not understand why the two need to be different = :-(. I must be getting amnesia. Maybe one of the co-authors will jog my = memory. >=20 > The protocol permits those values to be distinct from the async ones. = They should be in a separate set of params. Agree.=20 >=20 > My point, unless my very quick glance at the module mislead me, is = that you can't configure to use echo mode - if it's supported - in the = grouping imported by the IGPs. In the current model, it is modeled as a separate grouping with its own = set of parameters. The expectation is that implementations that want to = define echo mode would use the grouping. Defining the parameters also = implicitly defines that echo-mode is enabled. Are you saying that using = the echo grouping is not enough?=20 But I do think that the parameters needs to be further protected by an = if-feature statement that says grouping echo-cfg-parms { if-feature echo-mode; description=20 "BFD grouping for echo config parameters=E2=80=9D; >=20 > My implementation doesn't support echo, so I don't have any opinion = about where configuration of those belongs or not. With the feature statement, these echo parameters can exist inside of = client-cfg-parms, instead as a separate grouping and will be included by = the platform only if the feature is defined. And this would be my = preference. Is that what folks would also prefer? >=20 > -- Jeff >=20 >=20 >=20 >>=20 >> Cheers. >>=20 >>>=20 >>> -- jeff >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_42E005B0-01A5-4BBB-9D55-92DBCE085788 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 31, 2017, at 1:55 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Mahesh,

On Jul = 31, 2017, at 4:26 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Jeff,

On Jul 31, 2017, at 10:05 AM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

On Fri, Jul 28, 2017 at 03:58:06PM = -0700, Mahesh Jethanandani wrote:
The changes are done and pushed to GitHub. Use the grouping = client-cfg-parms.

Question: = For implementations that use Echo mode, is that something the
protocol client configuration impacts or is it chosen by the = system
automatically?

I am not sure I understand. 

For Echo mode, there is a separate grouping called = echo-cfg-parms that allows clients to specify the = desired-min-echo-tx-interval and required-min-echo-rx-interval. 

That is somehow different from desired-min-tx-interval and = required-min-rx-interval that one can specify for a normal BFD session. = For the life of me, I do not understand why the two need to be different = :-(. I must be getting amnesia. Maybe one of the co-authors will jog my = memory.

The protocol permits those values to be = distinct from the async ones.  They should be in a separate set of = params.

Agree. 


My point, unless my very quick glance at = the module mislead me, is that you can't configure to use echo mode - if = it's supported - in the grouping imported by the IGPs.

In the current model, it is modeled as a separate = grouping with its own set of parameters. The expectation is that = implementations that want to define echo mode would use the grouping. = Defining the parameters also implicitly defines that echo-mode is = enabled. Are you saying that using the echo grouping is not = enough? 

But I do think that = the parameters needs to be further protected by an if-feature statement = that says

  grouping echo-cfg-parms {
    if-feature echo-mode;
  =   description 
    =   "BFD grouping for echo config parameters=E2=80=9D;


My implementation doesn't support echo, = so I don't have any opinion about where configuration of those belongs = or not.

With the feature = statement, these echo parameters can exist inside of client-cfg-parms, = instead as a separate grouping and will be included by the platform only = if the feature is defined. And this would be my preference. Is that what = folks would also prefer?


-- Jeff




Cheers.


-- = jeff

Mahesh Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_42E005B0-01A5-4BBB-9D55-92DBCE085788--