RE: Direct BFD over Ethernet?

"Schwarz Albrecht (ETAS/ESY1)" <> Tue, 11 June 2019 07:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8751C1200C1 for <>; Tue, 11 Jun 2019 00:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tzNh5O_udDne for <>; Tue, 11 Jun 2019 00:04:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C8F9120047 for <>; Tue, 11 Jun 2019 00:04:48 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPS id 45NLbd0zl5z1XLG79; Tue, 11 Jun 2019 09:04:45 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPS id 45NLbd0ZQnz1Tt; Tue, 11 Jun 2019 09:04:45 +0200 (CEST)
X-AuditID: 0a3aad0c-d19ff700000039d6-07-5cff528c2232
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (SMG Outbound) with SMTP id C6.53.14806.C825FFC5; Tue, 11 Jun 2019 09:04:44 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPS id 45NLbc3nhNz5gT; Tue, 11 Jun 2019 09:04:44 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 11 Jun 2019 09:04:44 +0200
Received: from ([fe80::187:74e0:f8c8:c9b1]) by ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Tue, 11 Jun 2019 09:04:44 +0200
From: "Schwarz Albrecht (ETAS/ESY1)" <>
To: Alexander Vainshtein <>, Santosh P K <>
CC: "" <>, Stewart Bryant <>, Jeffrey Haas <>
Subject: RE: Direct BFD over Ethernet?
Thread-Topic: Direct BFD over Ethernet?
Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBv///ghQCAAAoAgP/+hUYwgAMa5gD/+4vSQA==
Date: Tue, 11 Jun 2019 07:04:44 +0000
Message-ID: <>
References: <> <> <> <>, <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8e213e313f2c4fcab9fa9481b8cbc7dfetascom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA21Tf1AUZRjm2927W45bXZZfL8hVcxZWlJ1a0xXl+EfTMNZM2lBTzjW4xHp3 Ixx0e6DQNB5KhpdMiFEHAYLHOBNzHgZKMlTIJSGIg3EzoQ4XIogoioUmweFduyzI/dE/7zz7 vO/zPu/3ft+SODNBJpAms5WzmNksjVxJKF89rn7+4LtBvbZo+Gldxam/cF1H5x2Z7t58K9KN X7+G63qvsptkqc2BbpTaVuVTpDY0zGKp3tJTsi3ENuVrmVyWKZ+zvLBxu9JY3NWFcsedaHd7 /3cKG/KXITsKJ4F+EUYenleImKErMSiq+UTCLgRjh5R2pBTwXQT3Djlx6eMXBP9+75GJVXJ6 E/T8sU9uRyQZTZtg8PNdIo3TeTDcXUOIOIpOgoG+iYXyaHoNjNluYFL5+zB7LEmkCfopaJ10 4CKm6Jeh7YejcsnqKgZN939d6BNOfwQlrpaFoRGthhMn+nHJKw6ujB3BpMPQ0PCTxAMdAzdH AzIJPwGDvTcIqT4dAjY3IZlFQk/lGFGGYqtCWlWFlFWFlEn8c1DXPi2XcDIcq5/El3DfmVEs lK9DikYUu4PT5mdr17+i1a61ZHB8oXbd2o9zspuRdL2q06irweBBNIk0KiojJahnZGw+X5Dt QS+RmCaG0hgDemZFRk5mgZHljemWvCyO1yRQiRc365moRzSfl5Ft4nlTjtmDgMQ10ZR9RtBR mWxBIWfJkWQetIokNHGUgXxHz9AG1srt5LhczrKUTSFJDVDPCM+NibRwBm73DlOWdSmtUVMo LCyMiQ3NhNpiZLgHbSBVgrdyq9CC4nPZbN5kWJTHS3JmiV2W9iKWLLtZcxQnO7tqhegdFOPU rFOIfzc2CHFGjAxhzjFzCXHUWbE7LfYx5pkfzZeQSDkP+vVMTEhi2eMWGkTChqOo1C2CWCX8 Y8uTAbVKXGbkIrksWu8UNPSXcVDieRNqz3DQcdmLoG7uKwzKSusxaB4+j0Px5J8EzA/7CWh6 OE+Aw/mjDALl9XK4WO2Xg2OkTQHlwZ8V0NH9jwIO3N4fDl+7G8Ph0vgDJbhG9kdAU7AkAspn qiOgtrY9Aib6zqkEhVcFZ71uCg77zq2AucqKldB6cmAltOx10NBXZmPA1WdnYKrdx9wSlo4J S09rFy+ct7LW/1n6Irt8tgQbspycXkP2tKS98dbQk98mbescKL6mLtJ/sDHwadIut8H/dpLO qibtxwvvqqrV+N6UtDu+UsfvFx5cuZQ8uNqxQf3h4/Gj4/dPJ3/h9aTXRgWHyNzbrw+5jmwd a1ZPbfdfuM6PfLPZPf2b7cCefTvdMf2JU5Eqg2/Pe/Hy1cHPHquYu8xoCN7IrnsWt/Dsf8vz 1/j7BAAA
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jun 2019 07:04:52 -0000

Thanks Sasha,
understood. There are two different types of served user instances (routing logic versus fault/alarm management of operators).

>    Just curious to know why do you have this use case? I mean why not use CFM itself?
we are considering a use case of

1.     a private network domain,

2.     with roughly 80% Ethernet and 20% non-Ethernet at link layer, and

3.     a traffic mix of IP-based and IP-less applications,

4.     primarily static routing,
and with the objective of

5.     continuity supervision (at link segments) and

6.     connectivity supervision (end-to-end, at network routes).

IEEE CFM might be then the candidate for (5) and Ethernet, but not the non-Ethernet link layer technologies.
IETF BFD would be the candidate for (6), for IP, but also non-IP-based end-to-end transport connections.

The engineering goal would be preferably a single supervision technology (for 5 and 6, for IP and non-IP, for Ethernet and non-Ethernet link level connections).
And that technology for this networking use case might be BFD, particularily when we could cover the 80% of Ethernet links as well.


From: Alexander Vainshtein <>
Sent: 08 June 2019 14:46
To: Schwarz Albrecht (ETAS/ESY1) <>
Cc:; Stewart Bryant <>om>; Jeffrey Haas <>
Subject: Re: Direct BFD over Ethernet?

I guess you are right and it is indeed mainly the technology ownership issue.
To the best of my recollection the BFD WG hss tried to cooperate with IEEE 802.1, but these attempts have failed.
At the same time I think there is a difference in the overall attitude with regard to OAM between IETF and IEEE 802.1.
The former seems to consider OAM sessions (and, specifically, BFD) as "helpers" for some other protocols (e.g., routing): these sessions are usually set up when the "client protocol" peers establish a peering relationship, and failure of the OAM session is an indication of failure of the peering relationship of the client protocol (see RFC 5882 for details).
The latter seems to treat OAM mainly as providing indications (alarms) to the operator.
My 2c.
Thumb typed by Sasha Vainshtein

From: Schwarz Albrecht (ETAS/ESY1)
Sent: Saturday, June 8, 11:47
Subject: RE: Direct BFD over Ethernet?
To: Jeffrey Haas, Stewart Bryant
Cc: Alexander Vainshtein,<>

Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a technology ownership question (IEEE 802 vs IETF) than a technical issue. Running BFD directly over Ethernet would (at least) require to assign an Ethertype codepoint ( ) for BFD. But BFD-over-Ethernet seems to be then in direct competition with the IEEE 802.1ag defined OAM capabilities (guess the Connectivity Fault Management protocols), i.e., the IEEE Continuity Check protocol. My rough understanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey Haas Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexander Vainshtein ; Schwarz Albrecht (ETAS/ESY1) ;<> Subject: Re: Direct BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: > > +1 > > However if you really want BFD, you only need a lightweight IP > implementation to carry it. During the work for BFD for LAG, IETF already went a bit too close to stepping into IEEE territory. Raw BFD over Ethernet would not be received very well by that organization, I think. (Even if it'd be trivial to specify.) -- Jeff


This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.