> *From: *Robert Raszuk
>>> *Date: *Thursday, February 10, 2022 at 10:57 AM
>>> *To: *Acee Lindem
>>> *Cc: *"lsr@ietf.org" , "
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>>> draft-ietf-lsr-ospf-bfd-strict-m...@ie
;> Acee
>>
>>
>>
>> *From: *Robert Raszuk
>> *Date: *Thursday, February 10, 2022 at 10:57 AM
>> *To: *Acee Lindem
>> *Cc: *"lsr@ietf.org" , "
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-
gt; *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
&
t-m...@ietf.org"
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Acee,
> There was debate regarding making the delay timer described in section 5 a
> normative requirement.
I see added into new ver
of "Acee Lindem (acee)"
>
> *Date: *Thursday, January 27, 2022 at 12:09 PM
> *To: *"lsr@ietf.org"
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *[Lsr] Working Group Last Ca
://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-bfd-strict-mode/
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, January 27, 2022 at 12:09 PM
To: "lsr@ietf.org"
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Subject: [Lsr] Working Group Last Call
gt;> OK, then back to my original question:
>>
>> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
>> the OSPF adjacency(between the DRother and DR/BDR)?
>>
>> If not, then the traffic between these DRothers will be lost; If yes, it
>> see
ail.com At: 02/08/22 09:44:32 UTC-5:00
> To: Albert Fu (BLOOMBERG/ 120 PARK ) ,
> muthu.a...@gmail.com
> Cc: acee=40cisco@dmarc.ietf.org, lsr@ietf.org,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD&q
uot;OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Muthu,
I don't have the data for BFD strict-mode interop over virtual links. However,
p2p unnumbered is commonly deployed and I'll let my co-author clarify on
interop.
Thanks,
Ketan
On Fri, Feb 4, 2022 at 10:52
;> 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-ietf-lsr-ospf-bfd-s
Hi Muthu,
I don't have the data for BFD strict-mode interop over virtual links.
However, p2p unnumbered is commonly deployed and I'll let my co-author
clarify on interop.
Thanks,
Ketan
On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:
> Hi Ketan,
>
>
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-ietf-lsr-ospf-bfd-strict-mode-04
>
>
side of that line.
Les
From: Lsr On Behalf Of Robert Raszuk
Sent: Sunday, February 6, 2022 3:31 PM
To: Les Ginsberg (ginsberg)
Cc: lsr ; Christian Hopps
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Les,
Ple
d-strict-m...@ietf.org> >, 'Albert Fu'
mailto:af...@bloomberg.net> >, Acee Lindem
mailto:a...@cisco.com> >
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi, Ketan:
OK, then back to my original
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
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
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
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
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 Cal
*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,
>
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
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
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
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
bruary 6, 2022 at 6:11 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Acee Lindem mailto:a...@cisco.com>>, Ketan Talaulikar
mailto:ketant.i...@gmail.com>>,
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Working Group Last
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
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.
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
, Ketan Talaulikar <
> ketant.i...@gmail.com>, "lsr@ietf.org"
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Gyan,
>
>
>
> > Overall I believe the
.
Thanks,
Acee
From: Robert Raszuk
Date: Sunday, February 6, 2022 at 6:11 AM
To: Gyan Mishra
Cc: Acee Lindem , Ketan Talaulikar ,
"lsr@ietf.org"
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Gyan,
> Ove
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
tan Talaulikar , "lsr@ietf.org" <
>> lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
>> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem <
>> a...@cisco.com>
>> *Subject: *Re: [Lsr] Working Group Last Call for &q
; *Date: *Friday, February 4, 2022 at 12:48 PM
> *To: *Muthu Arul Mozhi Perumal
> *Cc: *Ketan Talaulikar , "lsr@ietf.org" <
> lsr@ietf.org>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem
.
Thanks,
Acee
From: Robert Raszuk
Date: Friday, February 4, 2022 at 12:48 PM
To: Muthu Arul Mozhi Perumal
Cc: Ketan Talaulikar , "lsr@ietf.org" ,
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Acee Lindem
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode f
Muthu,
If you are using virtual link why is this still multihop BFD ?
Thx,
R.
On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:
> Hi Ketan,
>
> Sure, looking forward to the clarification in the draft on multi-hop BFD..
>
> Just curious, are there
Hi Ketan,
Sure, looking forward to the clarification in the draft on multi-hop BFD..
Just curious, are there interoperable implementations for OSPF multi-hop
BFD strict mode for virtual links or p2p unnumbered interfaces?
Regards,
Muthu
On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar
wrote:
Hi Muthu,
When we say a "link" here, it is in the context of the OSPF interface and
neighbor FSM. My understanding is that this term includes virtual links as
well. As such, we can add some text in the introduction section to clarify
the same and also put a reference to RFC5883 for BFD multi-hop
> lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
Hi Robert,
We were comparing OSPF and BGP and so it was the protocol FSMs. So we are
in sync on that part.
Thanks,
Ketan
On Tue, Feb 1, 2022 at 1:43 PM Robert Raszuk wrote:
> Ketan,
>
>
>> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
>> even though the BFD
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee Lindem
(acee)
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Ketan,
From: Ketan Talaulikar mailto:ketant.i...@gmail.com>>
Date: Thursday, February 3,
ailto:lsr@ietf.org>>,
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
dra
ndem
> *Cc: *"Acee Lindem (acee)" , "
> lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - d
ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>"
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Speak
gt;
>
> *From: *"Acee Lindem (acee)"
> *Date: *Friday, January 28, 2022 at 7:24 AM
> *To: *Acee Lindem , "lsr@ietf.org"
> *Cc: *"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>
> *Subject: *Re:
dem , "lsr@ietf.org"
Cc: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Speaking as WG member:
I support publication of the document. As indicated by
Hi Ketan,
Thanks for your response..
The draft says:
This document defines the B-bit in the LLS Type 1 Extended Options
and Flags field. This bit is defined for the LLS block included in
Hello and Database Description (DD) packets and
*indicates that BFD is enabled on the link* and
Ketan,
> What the OSPF draft discusses in Sec 5 is a "hold-down" wait period where
> even though the BFD session is established the protocol FSM does not
> proceed further until a period of time has passed to ensure the stability
> of the BFD session.
>
Which protocol FSM ? BFD FSM or OSPF FSM
Hi All,
The authors will work on and share the updated text to review with the WG.
Quickly want to point out that the draft does not bring any new
requirements in BFD for link quality monitoring; the stability issues that
we are discussing are related to BFD sessions going down due to
benefit from this. Ad if the link is still
>> unstable, it is more likely that the BFD session will go down during the
>> delay period than it would be for OSPF because the BFD timers are
>> significantly more aggressive.
>>
>> (BTW, this behavior can be done w/o a BFD prot
Les,
> On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg)
> wrote:
> I have not asked for BFD extensions.
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions are
> definitely not in scope of
...@ietf.org,
> ginsb...@cisco.com, ketant.i...@gmail.com, 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 Albert,
>
> On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 12
> I have stated that “IF” additional functionality is required from BFD
No one says so,
[LES:] Good. Can we end this thread then?
[
Les
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
-strict-m...@ietf.org,
ginsb...@cisco.com, ketant.i...@gmail.com, 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 Albert,
On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK)
wrote:
Hi R
:* Jeffrey Haas
> *Sent:* Monday, January 31, 2022 11:28 AM
> *To:* Robert Raszuk
> *Cc:* Ketan Talaulikar ; Les Ginsberg (ginsberg) <
> ginsb...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee
> Lindem (acee) ; Albert Fu ; lsr <
> lsr@ietf.org>
> *Subj
00
> To: Albert Fu (BLOOMBERG/ 120 PARK )
> Cc: ginsb...@cisco.com, ketant.i...@gmail.com, a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode
, January 31, 2022 11:28 AM
To: Robert Raszuk
Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Acee Lindem
(acee) ; Albert Fu ; lsr
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode
t: 01/30/22 14:38:37 UTC-5:00To: rob...@raszuk.net,
ketant.i...@gmail.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-osp
e likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
&
.@ietf.org,
lsr@ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Les & Ketan
Nowadays, it is also common to see the "break-in-middle" failures. we use BFD
to detect this sort of failure within s
mailto:ginsb...@cisco.com>>;
Acee Lindem (acee) mailto:a...@cisco.com>>;
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org<mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>;
Albert Fu mailto:af...@bloomberg.net>>; lsr
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Workin
g (ginsberg) ; ketant.i...@gmail.com;
> rob...@raszuk.net
> *Cc:* Acee Lindem (acee) ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; lsr@ietf.org
> *Subject:* RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
&
...@ietf.org; 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,
Your scenario below is indeed something we have encountered in our production
network in the non-strict scenario, due to "flappin
rt Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Robert –
>
>
>
> Here is what yo
Thanks
Albert
From: ginsb...@cisco.com At: 01/30/22 14:38:37 UTC-5:00To: rob...@raszuk.net,
ketant.i...@gmail.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , a...@cisco.com,
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, lsr@ietf.org
Subject: RE: [Lsr] Working Group Last Call for "OSPF Str
Yes/support
Cheers,
Jeff
> On Jan 27, 2022, at 09:08, Acee Lindem (acee)
> wrote:
>
>
> LSR WG,
>
> This begins a two week last call for the subject draft. Please indicate your
> support or objection on this list prior to 12:00 AM UTC on February 11th,
> 20222. Also, review comments
gt;>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther
>>>> routers
>>>>on a multi-access interface) with a neighbor that also supports
>>>> strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>>
>
/BDR or Full/DROther
>>> routers
>>>on a multi-access interface) with a neighbor that also supports
>>> strict-mode for BFD, then an implementation SHOULD NOT bring this
>>>
>>>
>>>
>>> Section 4.1 OSPFv3 IPv4 address fam
rom:* Robert Raszuk
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr
> *Subjec
Hi Robert,
We can update this text in the Introduction section as follows:
OLD
Note that it is possible
in some failure scenarios for the network to be in a state such that
an OSPF adjacency can be established but a BFD session cannot be
established and maintained. In certain other
Hi Robert,
The draft text refers to dampening and hold-down. The latter can be used
also for the initial session bring-up. The descriptions of those BFD
mechanisms are outside the scope of this document. If this needs to be
standardized at the IETF, then (IMHO) it would be best taken up in the
t;>>B-bit in its subsequent Hello packets. If the adjacency is already
>>>up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther
>>> routers
>>>on a multi-access interface) with a neighbor that also supports
>>>strict-mode
r some reason, then move one layer up – not two layers up.
>
>
>
>Les
>
>
>
>
>
> *From:* Robert Raszuk
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar
> *Cc:* Les Ginsberg (ginsberg) ; Acee Lindem (acee) <
> a...@cisco.com>
we cannot rely on v4
instance for v6 adjacency since it’s separate adjacencies. Also for IPv6
only scenario as well now you have to signal the B bit somehow so that flag
needs to be specified in the specification.
>
> Thanks,
> Ketan
>
>
>>
>> Kind Regards
>>
>>
:05 AM
To: Ketan Talaulikar
Cc: Les Ginsberg (ginsberg) ; Acee Lindem (acee)
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu
; lsr
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Ketan,
I would like to
Hi Ketan,
> It explains the scenario of a noisy link that experiences traffic drops.
The point is that BFD may or may not detect noisy links or links with
"degraded or poor quality". There are many failure scenarios - especially
brownouts - where BFD will continue to run just fine over a link
Hi Ketan,
I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
BFD dampening or hold-time are completely orthogonal to my point. Both have
>> China Telecom
>>
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee) wrote:
>>
>>
>>
>> Speaking as WG member:
>>
>>
>>
>> Hi Aijun,
>>
>> If you want a per-neighbor state and route, you have to use P2MP. This
>> scope of this
Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
> Fu ; Acee Linde
Hi Muthu,
Thanks for your review and your support.
Regarding your question, I would like to clarify that this document doesn't
specify BFD operations with OSPF. That was done by RFC5882. Indeed for
virtual links, there would need to be a BFD multi-hop session and the same
would apply to p-t-p
in the
>>> IGP. If you do not want the BFD session to come back up too quickly after a
>>> failure, the proper place to put timers is either at the interface layer or
>>> in the BFD implementation.
>>>
>>> I am familiar with implementations which apply t
Hi Robert,
Thanks for your review again and your comments/discussions.
This thread is about your second point "timer".
I would like to point out that the draft discusses the BFD "dampening" or
"hold-down" mechanism in Sec 5. We are aware of BFD implementations that
include such mechanisms in a
Hi Robert,
Thanks for your review and comments.
This email is in response to your first point "overpromise".
First, there is no text in the draft that "overpromises" that the strict
mode of operation detects "all forwarding" issues. We are talking about BFD
and its capabilities are well-known.
;> In discussion with the BFD working group on my other MTU draft, there's a
>> keen interest among the WG to keep the BFD simple.
>>
>>
>>
>>
>> From: rob...@raszuk.net At: 01/29/22 15:20:06 UTC-5:00
>> To: ginsb...@cisco.com
>> Cc: Albert Fu (B
uch extra/useless BFD sessions
>>
>> Aijun Wang
>> China Telecom
>>
>> On Jan 30, 2022, at 02:45, Acee Lindem (acee) wrote:
>>
>>
>>
>> Speaking as WG member:
>>
>>
>>
>> Hi Aijun,
>>
>> If you want a per-neigh
) , a...@cisco.com,
> ketant.i...@gmail.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
> 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,
>
> > Discussion of ho
@gmail.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,
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,
> Discussion of how to make BFD failure detection more robust belongs in the
> B
Hi,
I support the draft. A quick question:
Should it describe the applicability of the mechanism over OSPF virtual
links and unnumbered interfaces? With virtual links, one would have to
establish a multi-hop BFD session, so it is slightly different from a BFD
operational standpoint. For e.g,
gt; Aijun Wang
>
> China Telecom
>
>
>
> *From:* lsr-boun...@ietf.org *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
> Fu ; Acee Lindem (acee) 40cis
"lsr@ietf.org" ,
> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
> , 'Albert Fu'
> , Acee Lindem
> Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
> draft-ietf-lsr-ospf-bfd-strict-mode-04
>
> Hi, Ketan:
> OK,
Hi Les,
That timer and its consistency on both ends clearly belongs to OSPF not to
> BFD.
>
> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic
Robert -
From: Robert Raszuk
Sent: Saturday, January 29, 2022 12:20 PM
To: Les Ginsberg (ginsberg)
Cc: Acee Lindem (acee) ; Ketan Talaulikar
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
Fu ; lsr
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
*On Behalf Of * Robert Raszuk
> *Sent:* Saturday, January 29, 2022 11:25 AM
> *To:* Acee Lindem (acee)
> *Cc:* Ketan Talaulikar ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF
)
Cc: Ketan Talaulikar ;
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu ;
lsr
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Acee,
Can you suggest text which with you’d be happy? I’m sure the authors woul
Acee,
> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>
I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem
Cc: Ketan Talaulikar , lsr ,
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-
Hi Acee,
Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>
Actually instead of suggesting any new text I would suggest to delete the
two below sentences and it will be fine:
*"In certain other scenarios, a degraded or poor quality
Speaking as Document Shepherd:
Hi Robert,
From: Robert Raszuk
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar
Cc: lsr , "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
, Albert Fu
, Acee Lindem
Subject: Re: [Lsr] Working Group Last Call for "OSPF Stri
"
, 'Albert Fu'
, Acee Lindem
Subject: RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi, Ketan:
OK, then back to my original question:
If one of the BFD session(between DRothers) is DOWN, will it bring DOWN the
OSPF adjace
Hi Albert,
> [AF] This draft ensures that BFD can be used to detect failure quickly
> when there is a complete path failure between the nodes. You are right that
> there are many other types of failure that BFD cannot detect.
>
> Indeed, but the draft says otherwise. I think that needs to be
: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" -
draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Ketan and all,
I support this draft - it is a useful addition.
There are two elements which I would suggest to adjust in the text before
publication.
#1 Overpromise
Even bel
1 - 100 of 118 matches
Mail list logo
