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
Hi Kethan
Thank you for answering all my questions. I am all set.
Responses in-line
Kind Regards
Gyan
On Sun, Jan 30, 2022 at 11:48 PM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Please check inline with KT2.
>
>
> On Mon, Jan 31, 2022 at 1:20 AM Gyan Mishra wrote:
>
>> Hi Ketan
>>
>> Welcome.
Hi Gyan,
Please check inline with KT2.
On Mon, Jan 31, 2022 at 1:20 AM Gyan Mishra wrote:
> Hi Ketan
>
> Welcome. Responses in-line
>
> Kind Regards
>
> On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar
> wrote:
>
>> Hi Gyan,
>>
>> Thanks for your review and your comments/feedback. Please
Hi Les,
I agree with you that mechanisms like dampening and hold-down are best
achieved at the lowest levels (in this case in the monitoring protocol like
BFD) instead of in each routing protocol on the top.
Now whether this means we include/support the signaling of the parameters
for these
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
Hi Ketan
Minor cleanup on my part with normative language SHOULD to MUST. This is
critical as we want to make sure interoperability works and no wiggle room
or loopholes in misinterpretation of the specification.
The main motivation is to fix the problem with OSPF starting before BFD to
be
Hi Les,
> the way to address that is to put a delay either before BFD attempts to
bring up a new session
No this will not work. The BFD session must be fully up and BFD has to have
a chance for normal operation for X units of time. (By normal I mean with
existing or new BFD extensions which is
Hi Ketan
Welcome. Responses in-line
Kind Regards
On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar
wrote:
> Hi Gyan,
>
> Thanks for your review and your comments/feedback. Please check inline
> below for responses.
>
>
> On Sun, Jan 30, 2022 at 12:29 PM Gyan Mishra
> wrote:
>
>>
>> I
Robert –
Here is what you said (emphasis added):
But the timer I am suggesting is not related to BFD operation, but to OSPF
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about
allowing BFD for more testing (with various parameters (for example increasing
test packet
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
Hi Gyan,
Thanks for your review and your comments/feedback. Please check inline
below for responses.
On Sun, Jan 30, 2022 at 12:29 PM Gyan Mishra wrote:
>
> I support WG Adoption of this draft.
>
> This is a real world problem that has existed with BFD that operators have
> to deal with where
Hi Aijun,
There is a need for a BFD session to be established between neighboring
routers which directly forward data between them to ensure reachability
between them. That is my understanding of various implementations and
deployments at operators. This is independent of the strict mode of
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
Hi Robert,
If I've understood correctly, your point is :
a) That there are several other mechanisms for "link" verification that do
various levels of monitoring from basic reachability to more advanced
metrics (BFD is just one of them)
b) That there are several protocols that can leverage (a)
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.
Hi Robert
On Sun, Jan 30, 2022 at 10:13 AM Robert Raszuk wrote:
> Hi Albert,
>
> Thank you for confirming that BFD needs to be kept simple and there is
> already reluctance to add to it. So Les's suggestion to put additional
> logic into BFD is likely not a realistic one.
>
> Your note also
Sorry I meant publication.
I support publication.
Thanks
Gyan
On Sun, Jan 30, 2022 at 1:59 AM Gyan Mishra wrote:
>
> I support WG Adoption of this draft.
>
> This is a real world problem that has existed with BFD that operators have
> to deal with where OSPF adjacency comes up before BFD
Hi Albert,
Thank you for confirming that BFD needs to be kept simple and there is
already reluctance to add to it. So Les's suggestion to put additional
logic into BFD is likely not a realistic one.
Your note also confirms my points that there is likely to be different
holdtime timer
I feel it is better to keep the standard simple and not add timer delay as part
of BFD strict draft, as different customers may have different requirements,
and there may also be vendor/platform dependency.
For example, in the core where there are a lot of link redundancy/diversity, we
could
22 matches
Mail list logo
