Sorry for the late response, and thanks for the comments so far.
We have observed the "MTU" issue on Telco WAN circuits (typically, the p2p WAN
links are deployed using MPLS L2VPN service). So the cause is outside of our
control. But when the MTU issue happens, there are no network events/alarm
detect this, and also divert traffic around the link quickly. I feel BFD is a
good method for this purpose.
Thanks
Albert
From: ginsb...@cisco.com At: 10/23/18 10:45:02To: Albert Fu (BLOOMBERG/ 120
PARK ) , rtg-bfd@ietf.org
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets
been established, and without any network alarms.
Thanks
Albert
From: a...@cisco.com At: 10/23/18 12:30:55To: Albert Fu (BLOOMBERG/ 120 PARK )
, rtg-bfd@ietf.org, ginsb...@cisco.com
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Hi Albert, Les,
I tend to agree with
(* Resending smaller message *)
Hi Acee,
Please see comments in-line.
Thanks,
Albert
From: a...@cisco.com At: 10/23/18 13:02:49To: Albert Fu (BLOOMBERG/ 120 PARK )
, rtg-bfd@ietf.org, ginsb...@cisco.com
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Hi Albert
Hi Acee,
Please see comments in-line.
Thanks,
Albert
From: a...@cisco.com At: 10/23/18 13:02:49To: Albert Fu (BLOOMBERG/ 120 PARK )
, rtg-bfd@ietf.org, ginsb...@cisco.com
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Hi Albert,
From: "Albert Fu (BLOO
config error or data plane error due to HW
issues). In our case, most of our links are on WAN circuits - we would like to
use BFD padding to guard against Telco MTU issue.
Thanks
Albert
From: naim...@cisco.com At: 10/23/18 17:04:27To: a...@cisco.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , rtg
can also enable padding on
WAN circuits, and use default for back-back intra-site links.
Thanks
Albert
From: ginsb...@cisco.com At: 10/23/18 19:52:53To: Albert Fu (BLOOMBERG/ 120
PARK ) , rtg-bfd@ietf.org
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets
Albert -
From
Hi Acee,
>> Commenting specifically on the OSPF case, when you have such misconfigured
>> MTUs, this manifests as weird protocol hiccups.B You don't so much detect
>> that there's an MTU issue - you just see OSPF failing to make progress.
>
> However, when implementations start supporting ietf-os
Hi Les,
> [Les:] I have read this draft - not sure how relevant it is.
>
> Naiming had suggested that MTU sized packets need not be sent all the time
> but only occasionally -
> and that a failure might not be used to take the BFD session down -
> rather it would be seen as a "soft-failure" an
(* sorry, resend ING with updated subject *)
Hi Les,
> [Les:] I have read this draft - not sure how relevant it is.
>
> Naiming had suggested that MTU sized packets need not be sent all the time
> but only occasionally -
> and that a failure might not be used to take the BFD session down -
>
Hi Les,
> Jeff/Albert -
>
> Given the MTU issue is associated with a link coming up - and the use of Echo
> would allow the problem to be detected and prevent the BFD session from
> coming up -
> and you are acknowledging that the protocol allows padded Echo packets today
> ...
>
> is there
will help to reduce network churn and
improve stability.
Thanks
Albert
From: ginsb...@cisco.com At: 07/27/19 20:23:21To: gregimir...@gmail.com,
a...@cisco.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , i...@ietf.org, ket...@cisco.com,
l...@ietf.org, rtg-bfd@ietf.org, albert.f...@gmail.c
Hi Reshad,
I am not aware of any applicable IPR for this draft.
Thanks
Albert
From: rrah...@cisco.com At: 08/27/19 17:25:41To:
draft-ietf-bfd-large-pack...@ietf.org, rtg-bfd@ietf.org
Subject: IPR poll for draft-ietf-bfd-large-packets
BFD WG, authors, contributors,
We have started
Hi Carlos,
> Instead of (or in addition to) a lower transmission interval, why not add
> flexibility to not *have* to send large packets every packet, and instead
> send
> every n paks or so?
One of the things I learned since becoming involved with the BFD working group
is a strong desire w
Hi Ketan,
Thanks for the detailed feedback.
> 1. I am aware that this draft originates from practical pain points at a
> specific operator. During the adoption calls, the scenarios were debated in
> detail. It was basically a L2 WAN circuit service over a provider network and
> the challen
Hi Robert,
> Imagine two scenarios which were already highlighted as justification for
> this work:
> *Scenario 1 -* IGP with nodes interconnected with ECMP links
> *Scenario 2 -* IGP nodes interconnected with L2 emulated circuits which in
> turn are riding on telco IP network with ECMPs or LAG
Hi Robert,
>
> Thank you for sharing the experience and your use case.
> However when we make any protocol extension we need to make sure all possible
> deployment cases are covered
> and it must be well understood how the proposed extension will operate in
> basic deployment scenarios I
>
sue.
> Thx,
> Robert.
Thanks.
Albert
On Thu, Oct 3, 2019 at 9:34 PM Jeffrey Haas wrote:
> On Tue, Oct 01, 2019 at 11:11:13PM -, Albert Fu (BLOOMBERG/ 120 PARK)
> wrote:
> > There are well known cases, including those you mentioned, where BFD has
> > limitations
Hi Robert,
> Dear WG,
>
> Thank you Gyan for your note.
>
> It very clearly highlights my primary concern expressed earlier of false
> assumptions on how engineers may try to (mis)use bfd-large in multihop
> cases.
>
> Below note is a brilliant example of how one may not realize that actual
> pa
Hi,
1. Re: New Version Notification for
draft-ietf-bfd-stability-07.txt (Reshad Rahman)
This feature is good to have. As a matter of fact, we have been trying to get
vendors to expose BFD counters as we know links from carriers do drop packets
without any indication of errors, and th
Hi Les,
> On May 21, 2024, at 2:40 AM, Les Ginsberg (ginsberg)
>
> Sooo…this was a real “blast-from-the-past” for me.
> Over four years went by with no public updates – and in looking at the diffs
between the latest version and V2 (which is where the discussion ended for me)
it seems that not
21 matches
Mail list logo
