Re: BFD chair response to presentation on draft-mirmin-bfd-extended

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 22 November 2019 07:59 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 EBB5C120033; Thu, 21 Nov 2019 23:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 16LrA1Ctg5Wj; Thu, 21 Nov 2019 23:59:50 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 6EE4112000F; Thu, 21 Nov 2019 23:59:50 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id r18so2951499pgu.13; Thu, 21 Nov 2019 23:59:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YiXkpnrW9QU+VIQCDhDDv3rCzjlmUbpPswGNv/n7fVs=; b=MzJCXlHUAi34ABN1OEeP+iOfIYOhppE1EAnheSM6S5lojdiGvOyBuC3+y+ru+twzNO 4t4ExR7M2jmrc0EXveStgpi+Xc1tVkhuIYhgl1IrDvtIzURHjmehIXMhEpQzoHVUx37y qOPMe4tci0T4cupcU5wCJHz01EcH0vqDhSx+19pWLfUy3EE/X2WVdBWqeoDBTagoX9ty xl8/2KwvUasSXIofytJv8EahVUBooMk2E2p2Nq1VZQquSjp98DPz73ty8ZYOcQOpKm2R YppSkgHn5BBfRnxcklN8aHwjKuhymazVBghDT4NXXJcr/36QWFqhEZWLESBDGA5zgmTy 3x1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YiXkpnrW9QU+VIQCDhDDv3rCzjlmUbpPswGNv/n7fVs=; b=GcJsXhWENA8hQTsaNbvE4IQVzcT6F8Uw4aMlUr+XIG94N/pdzpz9okJ/jL/SilF78E cU1HgOCphh7Hl7BIOQoF5RBQc8IiUI5IQHnkCLlvCKOSJ7VGWShoe9+gXwLRxXKGVUPD v8wua1qlhs+eOQNjTGtx0lZ6zcHagNkEaDKIaSyqpCqlp1+5blHMneL47ycXu4fum17z v/D2/+PePTIbOsNczPzZqk2JYCys9m1HmDzf2dTYSEaLnUXulPxpII2FAjroHTnesbVK X/t5oIkEDqZY1JWAfTi6XyMTvmQsYh5+vFgoUhLdlUOA9Bz9tiq0v6glRTGRLvqxZS2d vDUA==
X-Gm-Message-State: APjAAAU6MbjFz1XTGVbAHJPVewYMbgjiMZ32dzlDee6mxFiLf8evqNig JgcbNmaVwPSeNuEV15J59zgLtbCK
X-Google-Smtp-Source: APXvYqwtK11XjUdmiEjeFlFxfYIFVyOKOGPQZqxxRcGi6ODgQNExkqc6+j4dVyarzpRKecj/lcp5MA==
X-Received: by 2002:a63:a741:: with SMTP id w1mr14058044pgo.26.1574409589870; Thu, 21 Nov 2019 23:59:49 -0800 (PST)
Received: from [31.133.147.52] (dhcp-9334.meeting.ietf.org. [31.133.147.52]) by smtp.gmail.com with ESMTPSA id w8sm6102704pfi.60.2019.11.21.23.59.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Nov 2019 23:59:49 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Subject: Re: BFD chair response to presentation on draft-mirmin-bfd-extended
Date: Fri, 22 Nov 2019 15:59:47 +0800
Message-Id: <595B700A-EECA-4314-9F13-00B441143EEC@gmail.com>
References: <MWHPR11MB1341FAFAD5169AC6E8843D20C1490@MWHPR11MB1341.namprd11.prod.outlook.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
In-Reply-To: <MWHPR11MB1341FAFAD5169AC6E8843D20C1490@MWHPR11MB1341.namprd11.prod.outlook.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/DCk1Os0PSOXRbf8LDki3rUzTCug>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 07:59:52 -0000

Jeff/Les,

Point taken,  thanks!

Regards,
Jeff

> On Nov 22, 2019, at 15:44, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:
> 
> For the record, I agree with Jeff's summary and comments.
> 
> I was really surprised that Greg did not wait until IETF 107 - which the BFD chairs had already indicated would be the time to resume discussions of this work.
> However well intentioned, both the timing and the WG were inappropriate for this presentation.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Rtg-bfd <rtg-bfd-bounces@ietf.org> On Behalf Of Jeffrey Haas
>> Sent: Thursday, November 21, 2019 6:53 PM
>> To: rtgwg@ietf.org
>> Cc: rtg-bfd@ietf.org
>> Subject: BFD chair response to presentation on draft-mirmin-bfd-extended
>> 
>> In the interest of permitting the presentations to move smoothly at this
>> Friday's rtgwg session, I withheld my comments from microphone.  However,
>> please consider these comments for the record for IETF-106.
>> 
>> Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.  rtgwg is
>> indeed intended to be a general purpose dispatch group for work without a
>> home, but that's not the case for BFD.
>> 
>> Secondly, Reshad and I intentionally did not schedule work on BFD extension
>> work, including Greg's presentation, for this IETF.  This is because there
>> is open charter discussions we're starting with the IESG on this space.
>> 
>> -----
>> 
>> Specific comments on BFD extension work and the charter discussions:
>> 
>> During prior IETFs, and culminating at IETF-105, we've seen regular work to
>> try to stuff BFD with additional features of various forms.  The litmus test
>> generally used for BFD's core use case over the years has been "what do you
>> want to hear every 3.3ms?"  To that end, things that enhance BFD's core
>> continuity verification uses cases have ended up in the protocol.
>> 
>> Somewhat similar to other popular protocols such as DNS and BGP, BFD has
>> nice properties that make it an appealing place to try to extend.  In
>> particular, it's a continuing conversation between two systems.
>> 
>> During IETF-105, the IPPM group members attending explicitly noted that they
>> did not want to see their mechanisms present in BFD and did not consider it
>> a good fit.
>> 
>> As part of that discussion, the chairs noted that one option potentially
>> open is that we permit the "BFDv2" option we have discussed at IETF-105 and
>> previous to permit an option where we do not use the core BFDv1 session used
>> for continuity for these extensions, and use a different protocol version
>> and port set to enable the other use cases.
>> 
>> Thus, the discussion with the IESG is whether BFD hands over the "gift" of a
>> general and mature mechanism for a conversation between two systems that
>> may
>> be generally extended to carry "interesting" information.
>> 
>> This addresses Tony Li's point about "please don't make BFD difficult to
>> implement in hardware".
>> 
>> -----
>> 
>> Specific comments on draft-mirmin-bfd-extended:
>> 
>> The somewhat peculiar extension mechanism shown in Greg's draft was
>> originally seeded by work I started in BFD for draft-ietf-bfd-large-packets.
>> In fairness to history, this was similar to work that was done in OSPF years
>> back for how the authentication mechanism was spliced onto the protocol.
>> The one sentence description of that use case is "make the packet padded to
>> test MTU".  It's a hack, but one that does a reasonable job of its use case.
>> 
>> However, with regard to leveraging this hack for a general purpose extension
>> mechanism, I don't find it a good fit.  BFDv1 does not expect to find
>> information regarding the packet or state machine outside of the main PDU..
>> It is likely a new version number will need to be used to establish future
>> semantics.  (Per prior discussion in the working group.)
>> 
>> The capabilities mechanism will likely require either integration into some
>> form of an updated state machine for the new version header, or a different
>> form.  IMO, I find it likely that a "capability advertisement" mechanism
>> would be necessary rather than negotiation to avoid a wholesale replacement
>> of the BFD state machinery.  And if we replace that much of the machinery,
>> let's just stop calling this BFD at all and move on.
>> 
>> With regard to IPPM style content for the draft, I refer you to the IPPM
>> members comments above from IETF-105.
>> 
>> With regard to authentication, there are two possibilities here:
>> - Faster authentication of BFD style packets is covered by work completing
>>  BFD WGLC draft-ietf-bfd-optimitizing-authentication.  I'd encourage other
>>  working groups in need of a faster per-packet authentication mechanism to
>>  consider whether it's an appropriate fit.
>> - In the case that such a future BFD, or mechanism built on similar
>>  machinery, want a way to autenticate the payload different from the
>>  headers, there will likely need to be discussion about not only what
>>  envelope is used, but also strength vs. periodicity.  (And if you don't need
>>  this stuff periodically, why use something like BFD?)
>> 
>> -- Jeff
>