Hi Rajesh,
I’m missing a WG last call declaration from you.
Thanks,
Acee
From: Lsr on behalf of "Acee Lindem (acee)"
Date: Thursday, January 27, 2022 at 12:16 PM
To: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
Cc: "lsr@ietf.org"
Subject: [Lsr] IPR Poll Coinciding with WGLC for "OSPF
The following errata report has been verified for RFC8665,
"OSPF Extensions for Segment Routing".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6838
--
Status: Verified
Type: Editorial
Hi Acee,
I am not aware of any IPR associated with this draft.
Thanks,
Rajesh
From: Acee Lindem (acee)
Sent: Tuesday, February 8, 2022 1:21 AM
To: Rajesh M
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org
Subject: Re: [Lsr] IPR Poll Coinciding with WGLC for "OSPF
HI Albert,
> This is precisely the issue that this draft intends to address,
> making sure that OSPF is not established, until BFD is UP.
What this draft tries to address is obvious. The real issue is however in
the true meaning of what "BFD UP" trigger means.
Some folks, perhaps including
Hi Robert,
This is precisely the issue that this draft intends to address, making sure
that OSPF is not established, until BFD is UP.
This ensures that there is a mechanism to quickly detect BFD failures, and
avoid having to rely on lengthy OSPF protocol timer for failure detection
(where
Designated Experts/WG Chairs -
The authors of draft-ietf-lsr-isis-fast-flooding request early allocation for
the top level TLV codepoint: Flooding Parameters TLV
as specified in
https://www.ietf.org/archive/id/draft-ietf-lsr-isis-fast-flooding-00.html#name-iana-considerations
Thanx.
Les
