Robert –
I am hoping to bring closure to the question of progressing the OSPF BFD strict
mode draft. To that end I will not address each of your points in detail.
I will say that what you have presented is NOT an accurate history.
Strict-mode behavior has been deployed for many years – first wit
Hi, Ketan:
From: lsr-boun...@ietf.org On Behalf Of Ketan Talaulikar
Sent: Monday, January 31, 2022 1:13 AM
To: Aijun Wang
Cc: lsr ; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee
Lindem (acee) ; Albert Fu
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft
Les,
Please kindly present the facts.
The facts are that equivalent functionality in OSPF which has been approved
for years uses a configurable timer which allows both - to wait for BFD as
well to make sure that BFD stays UP till that timer expires. The point I
even started this discussion was ab
Robert –
I have brought this in the context of the waif-for-bfd OSPF proposal. This is
the first time LSR WG is facing such a requirement so IMO it would be proper to
at least discuss this in the draft.
[LES:] Well – no – that statement isn’t true.
The strict-mode drafts (OSPF and BGP) are sp
Hi Chris
On Sun, Feb 6, 2022 at 5:30 PM Christian Hopps wrote:
>
> Robert Raszuk writes:
>
> > Hi Les,
> >
> >
> >
> > There is nothing in RFC 5880 (nor in, what I consider to be even
> > more relevant, RFC 5882) that requires a BFD implementation to
> > signal UP state to a BFD cli
Hi Chris,
> but I don't see how it is OSPF specific
I have brought this in the context of the waif-for-bfd OSPF proposal. This
is the first time LSR WG is facing such a requirement so IMO it would be
proper to at least discuss this in the draft.
And if so all I merely suggested was to mention th
Hi Les
On Sun, Feb 6, 2022 at 5:05 PM Les Ginsberg (ginsberg) wrote:
> Robert –
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Sunday, February 6, 2022 10:42 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - d
Hi Les,
BFD dampening as per some documentation is applicable or is triggered by
flapping BFD session(s). And indeed it has its own very valid use case. But
IMHO it is only partially a solution for what we need in the light of this
thread.
Here in this context assume I am looking at a new interfa
Robert Raszuk writes:
Hi Les,
There is nothing in RFC 5880 (nor in, what I consider to be even
more relevant, RFC 5882) that requires a BFD implementation to
signal UP state to a BFD client within a specific time following
transition of the BFD state machine to UP . An impl
Robert –
From: Robert Raszuk
Sent: Sunday, February 6, 2022 10:42 AM
To: Les Ginsberg (ginsberg)
Cc: lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Les,
There is nothing in RFC 5880 (nor in, what I consider t
Hi Les,
> There is nothing in RFC 5880 (nor in, what I consider to be even more
> relevant, RFC 5882) that requires a BFD implementation to signal UP state
> to a BFD client within a specific time following transition of the BFD
> state machine to UP . An implementation is free to introduce a del
Hi Robert
See RFC 5880 Section 3 - Operating modes.
BFD can run in async or demand mode and “echo” is an adjunct function to
both modes. The default mode when BFD initializes FSM.
All BFD packets are control packets sent for Async / Demand mode and with
or without Echo function which can be set
Robert –
Part of the reason this discussion is long is because we continue to discuss
things that are out of scope for the draft in question.
There is nothing in RFC 5880 (nor in, what I consider to be even more relevant,
RFC 5882) that requires a BFD implementation to signal UP state to a BFD
Gyan,
Exchanging BFD control packets does not guarantee data path liveness nor it
guarantees that subsequent BFD Echo packets will succeed.
BFD UDP control packets can use a different IP address (src or dst)
than the one used for data path probing. Both UDP ports are also different
(3784 vs 3785)
Hi Robert
Applicable to the congestion scenario most implementations prioritize
routing protocol traffic marking as CS6 or CS7 as well as explicit QOS
routing class can be created to classify and schedule all RE/RP sourced
control plane traffic so that BFD packets are protected and not dropped.
G
Hi Robert
On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk wrote:
> Gyan,
>
> > Overall I believe the goal of the strict mode BFD “wait for BFD” is
> accomplished
> > and solve all problems
>
> I do not agree with this statement.
>
> As currently defined in the posted version of the draft "wait fo
Hello Acee,
I am afraid you completely missed my point. Perhaps this is my fault as in
this way too looong email thread I indeed brought additional testing
requirements - but never said those need to be part of this draft nor
specified in LSR WG. Those were just examples on what can occur in this
Hi Robert,
I think that much of the additional functionality you are proposing is beyond
the scope of the draft and IGP BFD usage today. You could propose all these
additional capabilities (e.g., MTU testing and link quality determination
beyond what is already in BFD) in a separate draft.
Thank
Gyan,
> Overall I believe the goal of the strict mode BFD “wait for BFD” is
accomplished
> and solve all problems
I do not agree with this statement.
As currently defined in the posted version of the draft "wait for BFD"
means wait for BFD control packets to bring the session up.
The session co
19 matches
Mail list logo
