Re: [Lsr] Working Group Last Call for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

[[e-mail]]

Acee,

Many thanks for your comprehensive and helpful review.
We have just published -05 which include all WG LC comments and private IANA comments.


HTMLized version  https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-05



A diff from the previous version: https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-05


Please see inline [Bruno]



Orange Restricted
From: Acee Lindem <[e-mail]>
Sent: Thursday, August 31, 2023 7:33 PM
To: Acee Lindem <[e-mail]>
Cc: lsr <[e-mail]>; [e-mail]
Subject: Re: Working Group Last Call for "IS-IS Fast Flooding" - draft-ietf-lsr-isis-fast-flooding-04

I support publication.

I've done the shepherds review and have some editorial comments that I think will improve the readability (attached). Some of these are definitely subjective and optional. Others are obvious editorial comments (e.g., correction of minimumLSPTransmission-Interval to not have a hyphen).

[Bruno] Thank you. Should be in -05

I also have the following comments:

   1. In section 6.2.2.1, does the sending rate really increases as the Round Trip Time (RTT) increases? This is counter-intuitive. It seems to me that the rate would increase as the RTT decreases?
[Bruno] Good point. You are correct. Changed
OLD:  Thus, the sending rate roughly increases linearly with the RTT.
NEW: Thus, the sending rate is inversely proportional to the RTT.

   2. I notice you use ":=" for assignment in the algorithm descriptions. Is there a convention for this rather than just using "="? Reminds me of ALGOL-68 ;^)
[Bruno] There was no reason. ":=" changed to "="

   3. The algorithms in section 6 are non-normative, yet there is some normative language, e.g., MUST. Either the algorithm sub-sections need to clearly delineated or if all of section 6 is non-normative, lowercase must be used.
[Bruno] "RFC 9002 QUIC Loss Detection and Congestion Control" is in a similar situation so I would propose to do the same principle and if possible the same text.
https://www.rfc-editor.org/rfc/rfc9002.html#name-congestion-control

RFC 9002 says:
"This document specifies a sender-side congestion controller for QUIC similar to TCP NewReno [RFC6582].The signals QUIC provides for congestion control are generic and are designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use, such as CUBIC [RFC8312].If a sender uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion control guidelines specified in Section 3.1 of [RFC8085]."

Current draft says:
"The following two sections provides examples of Flow and/or Congestion control algorithms as examples that may be implemented by taking advantage of the extensions defined in this document. They are non-normative. The IS-IS extensions defined in Section 4 and Section 5 are generic and are designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use."
I'm open to taking the sentences verbatim from RFC 9002 except that in our case:
*           We are not doing congestion control across the Internet but within the router receiving the LSPs. (I guess we all agree that IS-IS will not congestion the link between adjacent routers). Hence I'm not sure that we need to refer to UDP and Transport Area congestion principles.
*           We describe two algos and not one.
*           Even if the congestion control principles are the same for IS-IS and TCP and hence we could also refer to NewReno or Cubic or BBR, some technical aspects are different as we reuse as much as we can from IS-IS loss detection and recovery algos hence I'm afraid that some people may misunderstand the reference to NewReno.

Given those differences, we amended some sentences of RFC900 and changed to
NEW:
The following two sections provide two Flow and/or Congestion control algorithms that may be implemented by taking advantage of the extensions defined in this document. The signal that these IS-IS extensions defined in Section 4<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding#FloodingTLV> and Section 5<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding#Receiver>provide are generic and are designed to support different sender-side algorithms. A sender can unilaterally choose a different algorithm to use.

Thanks,
--Bruno, on behalf of all authors.



Thanks,
Acee








> On Jul 19, 2023, at 7:06 PM, Acee Lindem <[e-mail]<mailto:[e-mail]>> wrote:
>
> This begins three week LSR Working Group last call for the "IS-IS Fast Flooding". Please express your support or objection prior to Friday, August 11th, 2023. The longer WG last call is to account for the IETF being next week.
>
> Thanks,
> Acee

____________________________________________________________________________________________________________
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.