Thank you John, Les, Zahed for helping. In -10 we have added text in the introduction to better introduce the changes brough by this document.
In short, with the following two additions spread in the Intro "IS-IS base specification <xref target="ISO10589"/> does not use flow or congestion control but static flooding rates." " This document improves flooding rate by allowing the signaling of flooding parameters <xref target="FloodingTLV"/>, specifying performance improvement on the receiver <xref target="Receiver"/> and introducing flow and/or congestion control <xref target="Control"/>." I think looking at the diff in the draft would be easier copy/pasting the changes and the context in an txt email --Bruno Orange Restricted -----Original Message----- From: Zaheduzzaman Sarker <[email protected]> Sent: Sunday, April 14, 2024 10:41 PM To: John Scudder <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; DECRAENE Bruno INNOV/NET <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; The IESG <[email protected]> Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-lsr-isis-fast-flooding-08: (with DISCUSS and COMMENT) -------------------------------------------------------------------------------------------------------------- CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. -------------------------------------------------------------------------------------------------------------- Hi, I actually agree here that adding information about cross layer potential might not be helpful here, also the proposed new text does not really the description that I was looking for. My original ask is describe why flow control and congestion control is required / need to be implemented for the IS-IS flooding, and I wanted to see very simple explanation about the motivation/reasoning for implementing flow control + congestion controls. This is not written very clearly in this document. This document says - "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." By the way John, your QUIC document example is not only vague but also wrong here, I don't see why QUIC cannot be run over non-IP L3/L2 :-). //Zahed On Fri, Apr 12, 2024 at 8:01 PM John Scudder <[email protected]> wrote: > I’m with Les on this one — "we should not conflate this document by > discussing such issues.” > > We often have this tension at this stage of reviewing a draft that’s > almost ready for publication. It’s being cross-reviewed by specialists > in other areas, and so it’s helpful for the document to provide enough > background to satisfy them. Sometimes this works, sometimes not, as > seems to have been the case this time, and then as Bruno says, "I have > large freedom to express myself in an email” to try to fill in the > blanks. The question at hand is whether after publication, those > blanks have to be filled in for future readers, or if we are in a > special case situation right now. > > My take is that once the document is published, its primary and most > important audience will be people who are already experts in IS-IS, > either as implementors or operators (or both!), and those people won’t > find a discussion of IS-IS over a standard L4 to be illuminating, but > confusing… even if the discussion ends up saying “here’s why we didn’t > do it over a standard L4”. It’s vaguely analogous to asking a QUIC > document to provide a rationale for why it’s specified over IP and not > over CLNS… sure, you could provide that rationale, but everyone > reading it would end up wondering why you spent your time and theirs on it. > > So while the NEW text Bruno suggested is correct of course, I wouldn’t > encourage adding it to the document, because I think it doesn’t serve > the needs of future readers, it just creates clutter. > > $0.02, > > —John > > On Apr 12, 2024, at 1:03 PM, Les Ginsberg (ginsberg) > <[email protected]> > wrote: > > > Top posting one comment. > > Regarding > > <snip> > [Bruno2] Well, I have large freedom to express myself in an email. > Writing a summary of WG history in an RFC is a little bit more > engaging... Also, although the perspective may be of interest, it’s > less likely of little interest to an IS-IS implementor. > I would propose the below addition in §6.1 “overview” but I’d very > much welcome the opinion of chairs and responsible AD on this text. > (both added in destination of this email) > > OLD: > Ensuring the goodput between two entities is a layer-4 responsibility > as per the OSI model. A typical example is the TCP protocol defined in > [RFC9293] that provides flow control, congestion control, and reliability ____________________________________________________________________________________________________________ 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. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
