Re: Direct BFD over Ethernet?

Jeffrey Haas <jhaas@pfrc.org> Wed, 12 June 2019 17:51 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 2407412016F for <rtg-bfd@ietfa.amsl.com>; Wed, 12 Jun 2019 10:51:44 -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 Q-YQLsW0fqsG for <rtg-bfd@ietfa.amsl.com>; Wed, 12 Jun 2019 10:51:42 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C80A4120144 for <rtg-bfd@ietf.org>; Wed, 12 Jun 2019 10:51:31 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 342A71E2F1; Wed, 12 Jun 2019 13:52:32 -0400 (EDT)
Date: Wed, 12 Jun 2019 13:52:32 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: "Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Direct BFD over Ethernet?
Message-ID: <20190612175232.GC23231@pfrc.org>
References: <AM0PR03MB3828C11241B4118A96BAFB7A9D100@AM0PR03MB3828.eurprd03.prod.outlook.com> <f6450c2f-a436-7127-251d-e09b79ba15f9@gmail.com> <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <AM0PR03MB3828A71E881294059A5BB8829D110@AM0PR03MB3828.eurprd03.prod.outlook.com> <20190611212305.GB12590@pfrc.org> <AM0PR03MB382870144F1E38857FCF247B9DEC0@AM0PR03MB3828.eurprd03.prod.outlook.com> <cef2d3c7fbb443d0b392935193efaf91@etas.com> <48023C71-074E-4C8C-AFF4-CD1706FB0F54@cisco.com> <AM0PR03MB382843A7DC997E241A932B4C9DEC0@AM0PR03MB3828.eurprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM0PR03MB382843A7DC997E241A932B4C9DEC0@AM0PR03MB3828.eurprd03.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/JOYFgp-YDf6wBKi5Yfv61DBi9LU>
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: Wed, 12 Jun 2019 17:51:44 -0000

On Wed, Jun 12, 2019 at 02:45:54PM +0000, Alexander Vainshtein wrote:
> Albrecht, Reshad and all,
> I concur with Reshad - it will work (RFC 7130 never says anything about the number of links in the LAG).

A somewhat perverse use of the feature. Cute. :-)

> Such a session would still use encapsulation in IP/UDP with the UDP destination port set to 6784 and the Destination IP address " that is configured on the peer system and can be reached via the LAG interface ". I.e., some lightweight IP functionality would be still required.

I'd expect there to be two interesting headaches:
1. In some implementations, you're shutting down "the lag" rather than the
link.  You'll effectively stop forwarding traffic, I think, but you may not
get the expected ifDown event on the link, only on the LAG-of-1 virtual
interface.

Clearly this is an implementation detail, but such things are what make LAGs
painful in IP protocols land.

2. The bootstrapping provisions require a bit more than just the
light-weight IP stack.  My employer's developers liked to say that they had
to operate at "layer 2.5" in order to get stuff to work before IP was
actually up.

-- Jeff