Re: [Gen-art] Genart last call review of draft-ietf-lsr-isis-fast-flooding-07

[[e-mail]]

Hi Ines,

Thank you for your review and comments.
Please see inline [Bruno]


> From: Ines Robles via Datatracker <[e-mail]>
> Sent: Wednesday, February 28, 2024 9:41 PM
> Reviewer: Ines Robles
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>
> Document: draft-ietf-lsr-isis-fast-flooding-07
> Reviewer: Ines Robles
> Review Date: 2024-02-28
> IETF LC End Date: 2024-02-29
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This document outlines the limitations of current Link State Protocol Data Unit
> (PDU) flooding rates within the IS-IS protocol and highlights the need for faster flooding to meet the objectives of modern networks. It addresses the challenges associated with this requirement, provides examples, and defines protocol extensions relevant to enhancing flooding speeds.
>
> The document is well-written. My minor comments are detailed below.
>
> Major issues: None
>
> Minor issues:
>
> 1- In Section 6.2.4, the term 'relatively static parameters' is introduced to describe the operational behavior of flooding parameters within the IS-IS protocol. Could you please clarify the criteria or conditions under which these parameters are considered relatively static, I mean which are the criteria or conditions that define these parameters as relatively static?

[Bruno] What about "the values advertised in the Flooding Parameters TLV would only change when additional IS-IS interfaces are configured." ?
If this provides good enough clarification, this text is already present at the end of the paragraph.

>
> 2- How do the pacing and rate-limiting mechanisms affect the IS-IS protocol's efficiency in detecting and responding to lost LSPs, considering the potential for fast loss detection provided by ordered acknowledgments?

[Bruno] I would welcome the context of your comment, such as the section number or the text triggering the comment.
Indeed, such pacing and rate-limiting are both already implemented and introduced by the draft, so it's not clear to me whether you are referring to pre-existing impact or impact introduced by this document.
Note also that ordered acknowledgments has no impact on fast loss reduction: " This MUST NOT be used to alter the retransmission timer for any LSP.". This may only be used to trigger congestion signal.

> Nits/editorial comments:
>
> 3- Should "today" be replaced with something like "at the moment of writing this specification". Or, since "today" is mentioned several times in the text, should a clarification be added at the first instance, example: today --> today (at the moment of writing this specification). ?

[Bruno] Good point, thanks.
There are 3 iterations of "today":

"Historically, flooding rates have been conservative - on the order of 10s of LSPs/second. This is the result of guidance in the base specification [ISO10589] and early deployments when the CPU and interface speeds were much slower and the area scale much smaller than they are today."
It looks to me that the sentence is correct whatever "today" may be. (assuming that the CPU performance do not decrease in the future). So may be this could be kept as-is.

"At typical LSP flooding rates used today (33 LSPs/second)"
What about :s/today/ at the moment of writing this specification

" Implementations today may prioritize the reception of Hellos over LSPs and Sequence Number PDUs (SNPs)"
What about
NEW: Implementations may already prioritize the reception of Hellos over LSPs and Sequence Number PDUs (SNPs)

>
> 4- In Section 6.2.2.1 "...fast rates in short periods of time..." --> it would be nice to add an example, e.g.: "... fast rates in short periods of time (For example, 12 LSPs in 20ms) ". What do you think ?

[Bruno] Well, the preceding sentence already provides the theoretical behavior: cwin(t) = t/RTT + cwin0.
It's not clear to me how providing two specific values would really help. Do you have in mind something like: cwin(t) = t/0.002 + 50 for an RTT of 2ms and a RWIN of 50 ? Another option would be to also pick a value for "t" so that we could compute an effective rate, but IMO that would hide the dynamic and could be misleading.


>
> Thanks for this document,

[Bruno] Thank you again for your review and comments.

--Bruno

> Ines
>
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.