Re: IETF-106 agenda?
Jeffrey Haas <firstname.lastname@example.org> Sat, 09 November 2019 19:19 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD24212001A for <email@example.com>; Sat, 9 Nov 2019 11:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XluVadU2n2_S for <firstname.lastname@example.org>; Sat, 9 Nov 2019 11:19:57 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [188.8.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id EE5D212008D for <email@example.com>; Sat, 9 Nov 2019 11:19:56 -0800 (PST)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [184.108.40.206]) by slice.pfrc.org (Postfix) with ESMTPSA id 580781E2F2; Sat, 9 Nov 2019 14:23:43 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B4DB9E-ADDF-4E09-9759-7649AD550980"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: IETF-106 agenda?
From: Jeffrey Haas <firstname.lastname@example.org>
Date: Sat, 9 Nov 2019 14:19:55 -0500
Cc: rtg-bfd WG <email@example.com>, Reshad Rahman <firstname.lastname@example.org>
References: <20191101181535.GA10713@pfrc.org> <CA+RyBmWA_MOzePJUaXRYEUCAvje33ie8ejjom56yDuCFTeSzsA@mail.gmail.com>
To: Greg Mirsky <email@example.com>
X-Mailer: Apple Mail (2.3601.0.10)
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Sat, 09 Nov 2019 19:19:59 -0000
Greg. > On Nov 1, 2019, at 4:27 PM, Greg Mirsky <firstname.lastname@example.org> wrote: > > I think that it will be of interest to the group to get an update on the draft-mirmin-bfd-extended. We've added details on the use of the Padding TLV. As noted previously, we will be deferring this work for next IETF. > Also, would appreciate the opportunity to discuss the status of draft-mirsky-bfd-mpls-demand at the meeting. Our agenda is likely to be light, and a small amount of time can be reserved - say 10 minutes. However, there are strict requirements on the slides since we'd previously discussed this at IETF-105 and on-list: Your slides need to clearly demonstrate what you think is missing from RFC 5880 procedures. In particular, from our prior discussions: - 5880 describes entering and leaving demand mode. - Previous discussion clarified that a change of the status field is a reason to do a poll sequence to notify the remote end of the new status. (See text from concatenated paths mode 6.8.17 describing one such scenario.) We agreed that an errata could potentially be filed to clarify this document wide. So, we will need what exact protocol normative behavior is missing. -- Jeff