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
Email: alexander.vainsht...@ecitele.com
-----Original Message-----
From: Reshad Rahman (rrahman) <rrah...@cisco.com>
Sent: Wednesday, June 12, 2019 5:36 PM
To: Schwarz Albrecht (ETAS/ESY1) <albrecht.schw...@etas.com>; Alexander
Vainshtein <alexander.vainsht...@ecitele.com>; Jeffrey Haas <jh...@pfrc.org>
Cc: rtg-bfd@ietf.org
Subject: Re: Direct BFD over Ethernet?
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)"
<rtg-bfd-boun...@ietf.org on behalf of albrecht.schw...@etas.com> wrote:
Thanks again all for recommendations and background information.
With regards to RFC 7130:
> 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 <alexander.vainsht...@ecitele.com>
Sent: 12 June 2019 16:16
To: Jeffrey Haas <jh...@pfrc.org>
Cc: Schwarz Albrecht (ETAS/ESY1) <albrecht.schw...@etas.com>;
rtg-bfd@ietf.org; Stewart Bryant <stewart.bry...@gmail.com>
Subject: RE: Direct BFD over Ethernet?
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
Email: alexander.vainsht...@ecitele.com
-----Original Message-----
From: Jeffrey Haas <jh...@pfrc.org>
Sent: Wednesday, June 12, 2019 12:23 AM
To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
Cc: Schwarz Albrecht (ETAS/ESY1) <albrecht.schw...@etas.com>;
rtg-bfd@ietf.org; Stewart Bryant <stewart.bry...@gmail.com>
Subject: Re: Direct BFD over Ethernet?
On Sat, Jun 08, 2019 at 12:45:50PM +0000, Alexander Vainshtein wrote:
> 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
___________________________________________________________________________
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.
___________________________________________________________________________
