Subject: Direct BFD over Ethernet?

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Fri, 7 Jun 2019 10:51:50 +0000

Dear BFD experts,
just a simple question: which BFD RFC would be applicable for applying BFD over an Ethernet link (no VLAN, no LAG)?
Direct over Ethernet, without IP.

Thanks,
Albrecht

Mit freundlichen Grüßen / Best regards

Dr. Albrecht Schwarz

Systems Engineering (ETAS/ESY1)
Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | [email-masked]<mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 7 Jun 2019 11:13:10 +0000

Albrecht,
AFAIK there is no such thing.

IMHO and FWIW IEEE802.1ag is the closest thing to what you are probably looking for, but it is quite different from BFD.

Thumb typed by Sasha Vainshtein

From: Schwarz Albrecht (ETAS/ESY1)
Sent: Friday, June 7, 13:52
Subject: Direct BFD over Ethernet?
To: [email-masked]

Dear BFD experts,

Thanks,
Albrecht

Dr. Albrecht Schwarz

___________________________________________________________________________

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 7 Jun 2019 12:20:30 +0100

+1

However if you really want BFD, you only need a lightweight IP 
implementation to carry it.

Stewart

On 07/06/2019 12:13, Alexander Vainshtein wrote:
> IMHO and FWIW IEEE802.1ag is the closest thing to what you are probably 
> looking for, but it is quite different from BFD.
> 
> just a simple question: which BFD RFC would be applicable for applying 
> BFD over an Ethernet link (no VLAN, no LAG)?
> *Dr. Albrecht Schwarz*
> Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | 
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 7 Jun 2019 07:56:17 -0400

> 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

---

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Sat, 8 Jun 2019 08:47:07 +0000

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 <[email-masked]> 
Sent: 07 June 2019 13:56
To: Stewart Bryant <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]
Subject: Re: Direct BFD over Ethernet?

> 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

---

From: Santosh P K <[email-masked]>
Date: Sat, 8 Jun 2019 14:34:29 +0530

Schwarz,
    Just curious to know why do you have this use case? I mean why not use
CFM itself?

Thanks
Santosh P K

On Sat, Jun 8, 2019 at 2:17 PM Schwarz Albrecht (ETAS/ESY1) <
[email-masked]> wrote:

> 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
>
> Cc: Alexander Vainshtein <[email-masked]>; Schwarz
> Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 8 Jun 2019 12:45:50 +0000

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.

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, [email-masked]

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) ; [email-masked] 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

---

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Tue, 11 Jun 2019 07:04:44 +0000

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 <[email-masked]>
Sent: 08 June 2019 14:46
To: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>
Cc: [email-masked]; Stewart Bryant <[email-masked]>; Jeffrey Haas <[email-masked]>
Subject: Re: Direct BFD over Ethernet?

Albrecht,

Cc: Alexander Vainshtein, [email-masked]<mailto:[email-masked]>

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) ; [email-masked]<mailto:[email-masked]> 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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 11 Jun 2019 08:18:54 +0100

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) <[email-masked]> wrote:
> 
> Thanks Sasha,

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 11 Jun 2019 07:29:24 +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:   [email-masked]

From: Stewart Bryant <[email-masked]>
Sent: Tuesday, June 11, 2019 10:19 AM
To: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; Santosh P K <[email-masked]>; [email-masked]; Jeffrey Haas <[email-masked]>
Subject: Re: Direct BFD over Ethernet?

- Stewart

Sent from my iPad

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

Santosh,

Regards,
Albrecht

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

Albrecht,

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Jun 2019 17:23:05 -0400

> To the best of my recollection the BFD WG hss tried to cooperate with IEEE 802.1, but these attempts have failed.

I think that's a mis-characterization.

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
https://tools.ietf.org/html/rfc7130

IEEE wasn't really interested in having BFD running native.  Much of this
has to do with the OAM and layering models that IEEE has for Ethernet.

And yet, IETF was getting push to solve at least a problem relating to layer 3
issues for traffic balancing over LAGs.  That was somewhat out of the realm
of IEEE.

So, while it took us a while to frame the problem, we eventually found a
place where we were able to solve our respective problems without stepping
too much on organizational and layer-wise boundaries.

> At the same time I think there is a difference in the overall attitude with regard to OAM between IETF and IEEE 802.1.

I think I would state this as "IETF doesn't have a useful OAM model".  Many
people would prefer us to have one, and see BFD as a useful component for
it.  However, that's bigger work than just BFD.

-- Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 12 Jun 2019 14:16:08 +0000

Jeffrey,
Lots of thanks for a prompt response.

I tend to agree with your statement that " IETF doesn't have a useful OAM model".
But I would add that, in spite of that, IETF has a rich set of OAM tools that are widely deployed and serve the real needs of the IETF community reasonably well, and from time to time adds to this set when new issues are identified.

Whether a useful OAM model is really needed in his situation, or not, is, IMHO, a matter of personal preferences.

"If it is not broken we don't fix it".

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Jeffrey Haas <[email-masked]> 
Sent: Wednesday, June 12, 2019 12:23 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
Subject: Re: Direct BFD over Ethernet?

IEEE wasn't really interested in having BFD running native.  Much of this has to do with the OAM and layering models that IEEE has for Ethernet.

And yet, IETF was getting push to solve at least a problem relating to layer 3 issues for traffic balancing over LAGs.  That was somewhat out of the realm of IEEE.

So, while it took us a while to frame the problem, we eventually found a place where we were able to solve our respective problems without stepping too much on organizational and layer-wise boundaries.

> At the same time I think there is a difference in the overall attitude with regard to OAM between IETF and IEEE 802.1.

I think I would state this as "IETF doesn't have a useful OAM model".  Many people would prefer us to have one, and see BFD as a useful component for it.  However, that's bigger work than just BFD.

-- Jeff

---

From: "Schwarz Albrecht (ETAS/ESY1)" <[email-masked]>
Date: Wed, 12 Jun 2019 14:29:31 +0000

Thanks again all for recommendations and background information.

> Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

Actually, I was thinking about a group size of one ("whereas the normal LAG is > 1") to emulate BFD over a single physical Ethernet link, - something like a dedicated  "BFD-over-LAG protocol profile".
However, didn't investigate so far the overhead.

Regards,
Albrecht

-----Original Message-----
From: Alexander Vainshtein <[email-masked]> 
Sent: 12 June 2019 16:16
To: Jeffrey Haas <[email-masked]>
Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
Subject: RE: Direct BFD over Ethernet?

Jeffrey,

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Jeffrey Haas <[email-masked]>
Sent: Wednesday, June 12, 2019 12:23 AM
To: Alexander Vainshtein <[email-masked]>
Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
Subject: Re: Direct BFD over Ethernet?

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 12 Jun 2019 14:35:41 +0000

Hi,

That should work. Are you referring to the encapsulation overhead?

Regards,
Reshad.

On 2019-06-12, 10:30 AM, "Rtg-bfd on behalf of Schwarz Albrecht (ETAS/ESY1)" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Regards,
    Albrecht

    -----Original Message-----
    From: Alexander Vainshtein <[email-masked]> 
    Sent: 12 June 2019 16:16
    To: Jeffrey Haas <[email-masked]>
    Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
    Subject: RE: Direct BFD over Ethernet?
    
    Jeffrey,

    
    
    My 2c,
    Sasha
    
    Office: +972-39266302
    Cell:      +972-549266302
    
    -----Original Message-----
    From: Jeffrey Haas <[email-masked]>
    Sent: Wednesday, June 12, 2019 12:23 AM
    To: Alexander Vainshtein <[email-masked]>
    Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
    Subject: Re: Direct BFD over Ethernet?

    

    

    
    -- Jeff

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 12 Jun 2019 14:45:54 +0000

Albrecht, Reshad and all,
I concur with Reshad - it will work (RFC 7130 never says anything about the number of links in the LAG).

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.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Reshad Rahman (rrahman) <[email-masked]> 
Sent: Wednesday, June 12, 2019 5:36 PM
To: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Direct BFD over Ethernet?

Hi,

Regards,
Reshad.

    

    Regards,
    Albrecht

    -----Original Message-----
    From: Alexander Vainshtein <[email-masked]> 
    Sent: 12 June 2019 16:16
    To: Jeffrey Haas <[email-masked]>
    Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
    Subject: RE: Direct BFD over Ethernet?
    
    Jeffrey,

    
    
    My 2c,
    Sasha
    
    Office: +972-39266302
    Cell:      +972-549266302
    
    -----Original Message-----
    From: Jeffrey Haas <[email-masked]>
    Sent: Wednesday, June 12, 2019 12:23 AM
    To: Alexander Vainshtein <[email-masked]>
    Cc: Schwarz Albrecht (ETAS/ESY1) <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>
    Subject: Re: Direct BFD over Ethernet?

    

    

    
    -- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jun 2019 13:52:32 -0400

> 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 LA…

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