Re: IETF 108 candidate minutes

Greg Mirsky <gregimirsky@gmail.com> Fri, 31 July 2020 22:57 UTC

Return-Path: <gregimirsky@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 C7EE73A07BE for <rtg-bfd@ietfa.amsl.com>; Fri, 31 Jul 2020 15:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UySkbTfWIs4n for <rtg-bfd@ietfa.amsl.com>; Fri, 31 Jul 2020 15:57:47 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 4C9003A07A9 for <rtg-bfd@ietf.org>; Fri, 31 Jul 2020 15:57:47 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id b30so17647537lfj.12 for <rtg-bfd@ietf.org>; Fri, 31 Jul 2020 15:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AW73a9EhdrPmnEOVHKuW8QaDShtFxiSS1hzqtCq6Vts=; b=VHwJmHu9mOaViMhe+euz1VkiWUHjLvIH0cwWe5mz6TS2Jdaq0fibxoSD6NTMhY9/YO Rm1bRksy7QaIJmsnBAJ0qvA7f06ppuOg4gVBXskPsN9xbvlXLWPA/vrJDaMbcNAkzopl BcJfa41rLM+nRqG6HMkDOeovUGEd7YJhmYVCgk7oOfP7V9Xnf29WDUz+tkCnlTTqMvu6 YDbss4L4mo7g1Fs8EGOrbOsi90HBfbAUz6dOFvV8oALB9c7tw5yrfPwQAN606Xr+OvKR GtE1x1/PzhORxzPAmVCojMRkXV9nZNlrQtw1cTmf4ZtS47/gNU/jo+z4Oh7f1GhS0P6i /WQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AW73a9EhdrPmnEOVHKuW8QaDShtFxiSS1hzqtCq6Vts=; b=SynbIFRQrlSgy+BwWryo3MkdncIhoHG0wGy+Fum9vSUFVCc92jNBdtSEj8r3JOLxSP 6EXGhszjNBBcdIzfD8kfOK69a02G/ma/eeLARoKiw8OvpBOs/hpktpi28tLyW8BixOZS seM/q312Me3Frn38i/jA3PsbyfxyoTHFTcPzAUEYH1dzsg6JLcQUTO+cFE3yZUrIAPE7 soLA/7lWL+NLcN9aYlZyeEUiNHcjOlOGMv7fisNwP5R0m+dR6njYSjq1UZUahz4C8RJH TitOcMSpz+AWG1cSJ4cGLjYyTJJx747zg82bymbogM2wvJnMy2P7h7OyHNul6ygayfbZ n6Kg==
X-Gm-Message-State: AOAM5310zPvt+T0TIJvalURs5/1IgE8IKqMs2mWbpr8SWyfkvpQYeCA/ ELGDoU44UOIRFGVeGJrjkDndxHdE3Bz79Rkz2v5ugg==
X-Google-Smtp-Source: ABdhPJxz23C3knslVaaMjkif6IksxDgKcvlwnzQ4Z+6lOimN3GAmL0dK4lzrcU+lPc8bPcWkVtFWCKp9TNjkOfv73sE=
X-Received: by 2002:a19:1c6:: with SMTP id 189mr3039968lfb.158.1596236265347; Fri, 31 Jul 2020 15:57:45 -0700 (PDT)
MIME-Version: 1.0
References: <2DFF0B9F-7D70-4239-B79A-2B91C3E69896@pfrc.org>
In-Reply-To: <2DFF0B9F-7D70-4239-B79A-2B91C3E69896@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 31 Jul 2020 15:57:34 -0700
Message-ID: <CA+RyBmUZuiksVe6ScV0VnwNi1nZDLwCNxujQcVSfokcm1USKgA@mail.gmail.com>
Subject: Re: IETF 108 candidate minutes
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000092de7205abc4b76e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/eyFigo9VhVq5aCnl_JONDinWSTk>
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, 31 Jul 2020 22:57:50 -0000

Hi Jeff,
I have nothing to change/add in the candidate minutes. Thank you!

Regards,
Greg

On Thu, Jul 30, 2020 at 9:12 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

> https://datatracker.ietf.org/doc/minutes-108-bfd/
>
> The following are the candidate minutes for the IETF 108 BFD session.
> Please provide feedback to the mailing list.
>
> -- Jeff and Reshad
>
> # BFD IETF 108 - July 30, 2020 - 13:00-13:50 UTC
> Chairs: Jeffrey Haas, Reshad Rahman
>
> # Agenda:
>
> ## Chairs update:
>   10 mins - Jeff Haas & Reshad Rahman
>
> **Greg Mirsky** asks about bfd 2.0.
> **Jeff Haas** answers we're likely rechartering to tighten our charter to
> the core continuity check (CC) case.  We're likely to try to spin off the
> other inter-system protocol machinery for other state to another WG or BoF
> depending on interest.  IESG was luke-warm about this option, at best.  WG
> would happily help in such a spin-off.
>
>
> ----
>
> ## BFD for VxLAN:
>   5 minutes - Greg Mirsky
>
> **Matthew Bocci** asks about BFD in Geneve.  Question about testing to
> individual VNIs.  Also questions about issues related to ECMP.
> **Greg Mirsky** notes that we're focusing on management VNI case.
> **Reshad Rahman** asks about MAC assignments for non-management cases.
> **Jeff Haas** WG had discussed the more general case for testing to VNI.
> Decided to leave it out of scope based on IESG discussions on security
> issues.  However, the packet format is likely general enough for the test
> to the VNI case, but is out of scope for our document. These issues also
> applies to BFD for Geneve
>
> Greg and Xiao are working on Geneve, so the Geneve document will pick up
> the relevant changes from WGLC discussion for vxlan document.
>
> ----
>
>
> ## BFD padding alteration (draft-xiao-bfd-padding-alteration):
>   10 minutes - Xiao Min
>
> **Santosh Pallagati**: How does poll and final interact with timers.  How
> long do we do poll/final sequence?
> **Xiao Min**: Should be very quick.
> **Santosh Pallagati**: This is just for negotiating large packets on.
> **Reshad Rahman**: Followup - scheduled packet, large packet sent in next
> interval, verify that you get f-bit back.  Some implementations have
> policers; 1 packet ever X ms, we may see more.  We may see drops of BFD
> packets?  Having reviewed BFD instability draft, this may show up as
> instability.
> **Xiao Min**: Extra padding poll can be sent more than once.
> **Jeff Haas**: Poll continues until the the poller decides it is done.
> **Greg Mirsky**: Poll is one packet per second?
> **Jeff Haas**: Poll actually for the rate that the session is currently
> running. pps is limiting factor for most bfd implementations.  bfd large
> changes bps as well.  That may interact poorly with policers?
> **Reshad Rahman**: Have you considered instead of on top of small packet
> doing poll on just large packet?
> **Xiao Min**: Intent is to keep bfd running when trying to toggle mode.
> **Reshad Rahman**: You could replace a regular packet with a padded
> packet. Concern that it could cause a BFD session to fail?
> **Jeff Haas** (speaking as BFD large packet author): Would you (Xiao)
> consider merging into bfd large?
> **Xiao Min**: Yes.
> **Jeff Haas**: Need to discuss requirements for operators that need the
> large packet feature always on vs. negotiated.
>
> ----
>
> ## BFD unaffiliated echo (draft-cw-bfd-unaffiliated-echo):
>   10 minutes  - Weiqiang Cheng
>
> **Weiqiang Cheng**: Procedural text in BBF document is unclear.
> **Rakesh Gandhi**: We are doing similar things with TWAMP for
> responder/reflector.  Does this means we'll update 5880?
> **Weiqiang Cheng**: Is aware of TWAMP.  Don't have to change BFD solution.
> Don't need to change remote implementation.  It's just configuration.
> **Jeff Haas**: This is different from BBF in that we're talking about a
> BFD implementation on the receiver. This would update 5880 if so.
> **Greg Mirsky**: Clarify on multiplexing on sessions for sender/receiver.
> System assigns discriminator to the session - and it goes into the packet.
> **Jaganbabu Rajamanickam** (Cisco): Is this same as S-BFD?
> **Greg Mirsky**: Reflector (learned via IGP, etc.) has an active role in
> BFD.  This proposal uses transport layer looping.
> **Jaganbabu Rajamanickam**: Could be loopback in data path.
> **Greg Mirsky**: And therefore it's echo mode.
> **Xiao Min**: The BFD echo is actually a control packet.
> **Greg Mirsky**: If you're running multiple sessions, you'll want to demux
> them.  The contents of the packet matters then.
>
> **Jeff Haas**: Hum for adoption. Hum was panissimo - will take this
> further to the mailing list.
>
> -----
>
> ## Actions for after IETF:
> - Submit BFD for vxlan to IESG
> - Submit BFD Unsolicited to IESG
> - Try to get last updates on BFD Authentication documents to respond to
> shepherd reviews.  Submit to IESG.
> - Update BFD Large Packets per WG discussion. Discuss whether we're
> submitting or holding back for further work.
> - Update working group about chartering discussion for bfd v2/extended.
> - Start adoption conversation for BFD unaffiliated.
>