RE: Direct BFD over Ethernet?

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 11 June 2019 07:29 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 EDD4712024C for <rtg-bfd@ietfa.amsl.com>; Tue, 11 Jun 2019 00:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 uxl0xa8_FYj6 for <rtg-bfd@ietfa.amsl.com>; Tue, 11 Jun 2019 00:29:36 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87BA7120233 for <rtg-bfd@ietf.org>; Tue, 11 Jun 2019 00:29:35 -0700 (PDT)
Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id 88/19-04807-B585FFC5; Tue, 11 Jun 2019 07:29:31 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphl+JIrShJLcpLzFFi42Ixkd5SoRsd8T/ G4EUvr8Wyex4W+w++ZbX4/Gcbo8Wzp4+YLU49SHRg9Zg87QCTx85Zd9k9liz5yeRxuXcrawBL FGtmXlJ+RQJrRndTM3vBli6miomr3RsY37QxdTFycbAIrGWWaFvxnAXEERKYyCTR+/0VK4Rzn 1FiztLjbF2MnBxsArYSm1bfBbNFBLIkDvctYAWxmQVKJVZPegdmCwuoSVw684IVokZd4knDcy YIO1mi5+1JdhCbRUBV4v/kS8wgNq9ArETv652MILaQwG5miR9ng0BsTqBdu18vA9vFKCAm8f3 UGiaIXeISt57MB7MlBAQkluw5zwxhi0q8fPyPFaI+SeL+04WMEHFFiRn35rBD2LISl+Z3Q8V9 JTY9PAj0MQeQrSyx5UUsyL8SAo8ZJQ4e2M4OEdeSmLdQDqJcSuLExaOsEHaOxJSlk6BGqku0f JwHFZeRmHB3OzPEnONsEovebWaC+CtZ4sSczywQRXISq3ofskAUXWCW2HXxJfMERu1ZSH6DsP Mk7v75wDILHEaCEidnPgGyOYDimhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNlUlFmekZ JbmJmjq6hgYGuoaGxromuobGpXmKVbpJeaqlucmpeSVEiUFYvsbxYr7gyNzknRS8vtWQTIzDR pRSytO9g7D/yWu8QoyQHk5Ior1LGvxghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKErzzwv/HCAkWp aanVqRl5gCTLkxagoNHSYR3JUiat7ggMbc4Mx0idYoxkGPCy7mLmDkuX58HJN/9XAwkP65aAi S/g8kLZ0HkkblLFzELseTl56VKifNeBBkkADIoozQPbg0sk1xilJUS5mVkYGAQ4ilILcrNLEG Vf8UozsGoJAxxDk9mXgncNa+ADmUCOjRk9z+QQ0sSEVJSDUwKR+dPjfoU+LJa8+6jqx3Mpw6v OBZ+8dOJaS5LfruFdpSpq9/vYn1puXTn5vUv82PTbDX4ry+R2+k3u/f6tGtXtf0NClv1+mOOG 74zcFu1Q6Vy2r6FAul2bre/rr56+6xZsEHxQc3j30I6VO7NkrXh37R2ctT+R5yfZIp3x7u2zb 0SPeNppPd99bNdX6LaF8jqRVmdnTw53+OGWaLdrv4kZbb1v+a9C9208Pbjk9936T8se88ra/t vy8WQwoxNkgdvLuM1uNCq8tkzfdEGJS3bv9lim2QW+661uvnE4HKd5pkfPHHSGh8ZvPwP/p19 3+31o98hyyqunviQklpms6LK8UXhGeVSR8mnm+urq8stlViKMxINtZiLihMBkW7jQ58EAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-245.messagelabs.com!1560238166!7515240!1
X-Originating-IP: [52.27.180.120]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.31.5; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 14924 invoked from network); 11 Jun 2019 07:29:30 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-12.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 11 Jun 2019 07:29:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2eZgULaImj0VG54Xln9jOaoqpURhwep8zc+VeFF8cZo=; b=tjG/wx3OUQpXSrzLoYgF1nHSTMvP9cau2VPp1MXxfIC8JwveB2Ob5OzV+0pp92wQUWQVok41W7gFpyEcmPFaYFSBabez8jy4t2dGa6jf0D9CtA36SLSi8DZEBog83hZyJZzOkahTJA3gZlPx0dK2odD5o+uPxNwXSFLQOvy1V+E=
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3778.eurprd03.prod.outlook.com (52.135.151.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.17; Tue, 11 Jun 2019 07:29:24 +0000
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Tue, 11 Jun 2019 07:29:24 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "Schwarz Albrecht (ETAS/ESY1)" <Albrecht.Schwarz@etas.com>
CC: Santosh P K <santosh.pallagatti@gmail.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>
Subject: RE: Direct BFD over Ethernet?
Thread-Topic: Direct BFD over Ethernet?
Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5kAi2MYAAAAfqkAAABGw0A=
Date: Tue, 11 Jun 2019 07:29:24 +0000
Message-ID: <AM0PR03MB38283363BD4F738478E650849DED0@AM0PR03MB3828.eurprd03.prod.outlook.com>
References: <e06e6a9189eb4174a6777da720d31294@etas.com> <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> <8e213e313f2c4fcab9fa9481b8cbc7df@etas.com> <B4CBD764-40F4-4206-B9AA-5A8AB0C2AE43@gmail.com>
In-Reply-To: <B4CBD764-40F4-4206-B9AA-5A8AB0C2AE43@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9172bb64-d59c-4b88-4d75-08d6ee3e8721
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB3778;
x-ms-traffictypediagnostic: AM0PR03MB3778:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR03MB3778A95D7241A5D90EB3DC769DED0@AM0PR03MB3778.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(366004)(136003)(199004)(189003)(51444003)(13464003)(7736002)(790700001)(14444005)(316002)(6116002)(11346002)(52536014)(476003)(486006)(446003)(66066001)(71200400001)(3846002)(8936002)(478600001)(81156014)(3480700005)(71190400001)(5660300002)(54906003)(8676002)(2906002)(33656002)(81166006)(74316002)(110136005)(86362001)(14454004)(256004)(102836004)(76176011)(99286004)(186003)(26005)(7696005)(606006)(53546011)(72206003)(6506007)(236005)(9686003)(55016002)(25786009)(68736007)(66946007)(73956011)(66556008)(66476007)(76116006)(229853002)(54896002)(6306002)(66446008)(4326008)(64756008)(6246003)(53936002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3778; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LLO3xbqu+ZR+m+nxSWFyATfDQhrrs1hzpP/11LdBXXJgUe26UmRHbuwx4qrb/NuXtycstFctiuzabXp6HutS+2C5cjPGkbXU7btmaM8p16T/y+m+y3fcg6d63wcuvZEuYVsCu/wHpiwT6WeONah9Z1hopG47SulLspMyvje3AUxADygZdfXsdMHN+R0GFxlxqh5gI0bjBgTK9wdACbq6bTpHKRQK5QgGNkjLkv9uZIoBDwDMAC4I7w1Iniz+wqeVCJrH0D73T6Ns3NeQcM18gUwkbWIAVkndr/kd9hESg5XJCZGtXkr/tV+GraweROvuTOJo8ZM+KIEXP+uMMAll14T36E4DyRlrc5olpQcNoyZ8H7nh/vea67pYdQUZjxEuOp4p6DAmocQjBkzmRKIc1WleNMFklQaOLVUKhhcW610=
Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38283363BD4F738478E650849DED0AM0PR03MB3828eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9172bb64-d59c-4b88-4d75-08d6ee3e8721
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 07:29:24.0754 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3778
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/eJOBWej2Y-wwmf3588udtEIgmIs>
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: Tue, 11 Jun 2019 07:29:41 -0000

It seems there are “20% non-Ethernet at link layer” in the network in question.
Therefore I think that IP-based BFD is the only way to address end-to-end connectivity.
As Stewart has said, you only need some lightweight IP in your devices to do that.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Stewart Bryant <stewart.bryant@gmail.com>
Sent: Tuesday, June 11, 2019 10:19 AM
To: Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; Santosh P K <santosh.pallagatti@gmail.com>om>; rtg-bfd@ietf.org; Jeffrey Haas <jhaas@pfrc.org>
Subject: Re: Direct BFD over Ethernet?

If you have an Ethernet that is not carrying IP, and want to use BFD you could still wrap the BFD in IP, and pull those packets off by recognising the IP Ethertype. No other protocol on the wire can be using that Ethertype, so there is no ambiguity. You no need to send the payload to an IP handler if there is no IP, just treat the IP as opaque data.

If you do have IP on the Ethernet and want to check before the packet gets to the IP handler you could use a well-known IP address and pull those packets off first as a special case.

- Stewart

Sent from my iPad

On 11 Jun 2019, at 08:04, Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com<mailto:Albrecht.Schwarz@etas.com>> wrote:
Thanks Sasha,
understood. There are two different types of served user instances (routing logic versus fault/alarm management of operators).

Santosh,
>    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.

Regards,
Albrecht


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Sent: 08 June 2019 14:46
To: Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com<mailto:Albrecht.Schwarz@etas.com>>
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Subject: Re: Direct BFD over Ethernet?

Albrecht,
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, rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>


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 (https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml ) 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) ; Rtg-bfd@ietf.org<mailto:Rtg-bfd@ietf.org> 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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________