Hi Les,
Thank you for your comments.
OSPF does include the LSDB sync requirement. But OSPF state machine does not
guarantee the two routers attain FULL state at the same time.
R1(restart)--R2--R3
R1 LSDB: R1's new router-LSA, seq 8001
R2 LSDB: R1's old router-LSA, seq 8500
Hi Acee,
Thank you for your review.
The problem described in that draft happens when an OSPF router restarts from
unplanned outage.
Its neighbor has the previous copies of the starting router's LSAs. Since the
starting router will reinitialize LSA sequence numbers, the neighbor thinks its
+1 to what Acee has said.
As historical context, the SA bit was defined in IS-IS precisely because IS-IS
adjacency state machine does NOT include LSPDB sync as a requirement before the
adjacency is usable (unlike OSPF).
OSPF does not need SA bit.
Les
> -Original Message-
> From:
Hi Les,
Thanks for the input. I’ve verified the erratum as editorial/HFDU already under
the doctrine of “doesn’t hurt, might help”. Apart from other considerations,
the existence of the erratum serves as further documentation that the text in
question does *not* mean the protocol (IS-IS).
(At the risks of giving this issue more attention than it merits…)
My interpretation of the filed Errata is that the submitter incorrectly thought
that the text should be referring to the protocol (IS-IS) and that the text had
been inadvertently truncated. Consider that the “Note” says:
Hi Liyan,
I should replied to this Email rather than your request for an IETF 116 slot.
Please reply to this one.
I’m sorry but I don’t get this draft from a quick read. An OSPF router would
not advertise an adjacency until the router is in FULL state. An OSPF router
will not attain FULL
+LSR
I’m sorry but I don’t get this draft from a quick read. An OSPF router would
not advertise an adjacency until the router is in FULL state. An OSPF router
will not attain FULL state until database synchronization is complete.
The following statement from you use case is incorrect:
So,
The following errata report has been held for document update
for RFC9350, "IGP Flexible Algorithm".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7376
--
Status: Held for Document Update
Dear All,
We have posted a new draft
https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/.
This draft describes the extension of OSPF LLS to signal adjacency suppression
which is functionally similar to the SA bit of Restart TLV in IS-IS.
The purpose is to avoid the temporary
> On Mar 6, 2023, at 7:57 AM, John Scudder wrote:
>
> “Hold For Document Update” is exactly for the purpose [1] of making nominal
> but inessential improvements. This one seems roughly on the level of “trivial
> grammar correction” (item 4 of [1]) which is in-scope for HFDU, and
>
“Hold For Document Update” is exactly for the purpose [1] of making nominal but
inessential improvements. This one seems roughly on the level of “trivial
grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently
the lack of expansion confused at least one person, so I’m
Hi Peter,
I agree it is not an errata. We really don’t want to set precedence of having
published RFC text nominally improved via Errata. I’ve copied John for Errata
resolution.
Thanks,
Acee
> On Mar 6, 2023, at 4:14 AM, Peter Psenak wrote:
>
> Acee,
>
> if you ask me, I would not do
Acee,
if you ask me, I would not do anything. "IS" is correct in the text and
it's well known.
my 2c,
Peter
On 05/03/2023 14:32, Acee Lindem wrote:
Hi Tony,
On Mar 4, 2023, at 4:42 PM, Tony Li wrote:
Hi all,
IMHO, this erratum is correct, but the proposed fix is incorrect.
In this
13 matches
Mail list logo
