Hi Sami,
you've said:
Sami: 2 points here, the proposal in the draft has 2 aspects, 1) the diag
code via which one node inform the other node that it outlived it, and 2)
the Bitmap presenting the services, we understand that BFD is a *noisy*
protocol this is why the bitmap is only communicated on f
An update to a meeting session request has just been submitted by Reshad
Rahman, a Chair of the bfd working group.
-
Working Group Name: Bidirectional Forwarding Detection
Area Name: Routing Area
Session Requester: Reshad Rahman
Number o
A new meeting session request has just been submitted by Jeffrey Haas, a Chair
of the bfd working group.
-
Working Group Name: Bidirectional Forwarding Detection
Area Name: Routing Area
Session Requester: Jeffrey Haas
Number of Sessions:
This normally happens as part of IETF, but it got away from us.
The BFD wiki has been updated with current status of known documents and
documents utilizing BFD outside of the working group.
https://trac.ietf.org/trac/bfd/wiki
-- Jeff
Hi Jeff,
Thanks for your comments, please see my comments inline Sami:
On 12/19/17, 8:22 AM, "Jeffrey Haas" wrote:
>[Speaking as an individual contributor.]
>
>I'm going to pick this as my response point. I'm not picking on you,
>Ashesh. :-)
>
>I have several concerns about the proposal in
Same logic as authentication. Either both ends run it or neither end runs it.
Additionally, dropped frames don’t impact the math as the exchange is just one
frame forward and reverse. If any packet is lost, the particular exchange
disappears. This missing exchange should have no impact on the
Ashesh,
On Tue, Dec 19, 2017 at 12:30:10PM -0500, Ashesh Mishra wrote:
> It really depends on the use-case and the implementation. This measurement
> may be excessive if running at a 3.3ms or 10ms interval, but you don’t run
> these intervals on anything but the best and most deterministic of li
It really depends on the use-case and the implementation. This measurement may
be excessive if running at a 3.3ms or 10ms interval, but you don’t run these
intervals on anything but the best and most deterministic of links. For links
with higher or unpredictable latency, the typical intervals ar
Ashesh,
I'll take it as a given that there's an implied gripe about a lack of TLVs
for BFD and a push for BFDv2. :-)
The work in here seems reasonable, but does run up against the question I
always must ask: Is this actually useful/usable at high BFD rates?
I understand that a likely scenario (a
Thanks everyone for getting the errata to where it is.
Working through the thread, I tend to agree that we have a few nits that
need to be resolved long-term, but I think the errrata gets us most of the
way there for purposes of clarifying the bulk of the behavior. That said, I
think we're at a p
[Speaking as an individual contributor.]
I'm going to pick this as my response point. I'm not picking on you,
Ashesh. :-)
I have several concerns about the proposal in this document:
1. It's not very clear how services get mapped to BFD sessions. As others
are indirectly noting, p2p BFD ses
[Speaking as an individual contributor.]
On Tue, Dec 19, 2017 at 02:20:11AM +, Carlos Pignataro (cpignata) wrote:
> S-BFD currently specified for p2p but I don't see a reason why S-BFD cannot
> be applied to p2mp cases. So, for a BFD node that supports both RFC 7880 and
> draft-ietf-bfd-mult
Working Group,
This likely could use BFD eyes upon it, especially given our current WGLC on
the multipoint documents.
-- Jeff
- Forwarded message from The IESG -
Date: Mon, 18 Dec 2017 13:56:36 -0800
From: The IESG
To: IETF-Announce
Cc: trill-cha...@ietf.org, draft-ietf-trill-p2mp-..
As a co-author of RFC 7880, I disagree with the report below, and recommend
Rejecting this Erratum.
S-BFD uses the BFD state variables, and “bfd.SessionType” is applicable with
finer granularity than “Not S-BFD”.
Some details at.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/HxHT6Nxhpxot4baDag
14 matches
Mail list logo
