Re: Re: BFD WG adoption for draft-haas-bfd-large-packets

Jeffrey Haas <jhaas@pfrc.org> Mon, 29 October 2018 18:26 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 4582C131060 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 11:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSsJV6fcl5Vy for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 11:26:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CE91B131059 for <rtg-bfd@ietf.org>; Mon, 29 Oct 2018 11:26:54 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AA1391E44B; Mon, 29 Oct 2018 14:26:16 -0400 (EDT)
Date: Mon, 29 Oct 2018 14:26:16 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Albert Fu <afu14@bloomberg.net>, "jhaas@juniper.net" <jhaas@juniper.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Re: BFD WG adoption for draft-haas-bfd-large-packets
Message-ID: <20181029182616.GT12336@pfrc.org>
References: <5BD74598029D054400390770_0_68291@msllnjpmsgsv06> <4cf7076b81ea486c985921eb222c8eba@XCH-ALN-001.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4cf7076b81ea486c985921eb222c8eba@XCH-ALN-001.cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/aNQBHt7D960h80yZ-cNlA6_TMZI>
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: Mon, 29 Oct 2018 18:26:56 -0000

Les,

On Mon, Oct 29, 2018 at 06:13:53PM +0000, Les Ginsberg (ginsberg) wrote:
> The fact that the problem is not detected on protocol adjacency formation
> does not mean the problem gets introduced afterwards. Unless you are
> saying that folks change the link MTU AFTER the link comes up and has been
> used for a while the problem exists as soon as the link comes up. You
> could therefore detect this in a number of ways:

It feels like you're missing part of the issue, Les.  Here's an example
timeline.

1. Customer is delivered a link that is provisioned with 1500 MTU.

2. The link is implemented, e.g., with l2vpn.  It could be frame relay. It
could be whatever, but is likely not a TDM link as of old.

3. The link starts getting used.  Things are fine.

4a. There's a topology change in the l2vpn network.  A result is that another
label gets used and effective path MTU is reduced.  We now start dropping
full sized packets.

4b. The l2vpn traverses an internal ECMP, and one leg of it develops an MTU
issue due to a topology change and additional label usage.  We now start
dropping full sized packets sometimes.

To your points:

> 1)Use IS-IS ☺

Great when you can!

> 2)Enhance other routing protocols to do what IS-IS does
> 3)Send BFD large packets (Echo or async)

3 - see 2. :-)

> 4)Potentially some other OAM mechanism

If you have a list of other mechanisms, please list them.  Minimally,
they're good fodder for the draft.

> In regards to #3, unless you believe link MTUs will change “on the fly”,

Effectively, this happens.

> sending the large packets during initial session bringup would be
> sufficient. If folks are concerned (as I am) that sending large BFD
> packets all the time introduces some risks for scalability/stability of
> BFD sessions, then one strategy would be to send the large packets only on
> session bringup.

The scalability/stability issues are understood to be a potential issue.
Hence doing this as a draft and engaging discussion.

But hopefully you can see above where simply doing MTU probing only at the
beginning is not sufficient.

It's also arguable that doing it for every single packet isn't necessary for
many people's scenarios.  How often is it needed?  By whom?  With what
detection interval?  Again, good points for discussion.

> FYI, some implementations have knobs on IS-IS to do exactly this i.e.,
> send padded hellos until the adjacency is formed – then revert to small
> hellos.

This wouldn't cover Albert's scenario.

> In the case of BFD I think there is a more compelling reason to be
> conservative in how often you send large packets given where it is
> implemented and how often the BFD packets are sent.

You don't need to convince me. :-)

-- Jeff