Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06
In regards to "operation on a LAN interface", > > > Section 6.2.1.2: > > “f no PSNPs have been generated on the LAN for a suitable period of time, > then an LSP transmitter can safely set the number of un-acknowledged LSPs to > zero. > > Since this suitable period of time is much higher than the fast > acknowledgment of LSPs defined in Section 5.1, the sustainable transmission > rate of LSPs will be much slower on a LAN interface than on a point-to-point > interface.” > > > > What a suitable period of time? Can you be more concrete? > > [Bruno] Good question. But difficult question. > Les, would you have some suggestion? > Otherwise, rather than adding more text for the LAN case, I'd rather remove > some text with the following change > > OLD: > However, an LSP transmitter on a LAN can infer whether any LSP receiver on > the LAN has requested retransmission of LSPs from the DIS by monitoring > PSNPs generated on the LAN. If no PSNPs have been generated on the LAN for > a suitable period of time, then an LSP transmitter can safely set the number > of > un-acknowledged LSPs to zero. Since this suitable period of time is much > higher than the fast acknowledgment of LSPs defined in Section 5.1, the > sustainable transmission rate of LSPs will be much slower on a LAN interface > than on a point-to-point interface. > > NEW: /nothing/ > > As already stated, probably one could do better in the LAN case. E.g., > advertising the delay between periodic CSNP (which would answer your > question), sending in (LSP-ID) order, having the receiver send PSNP on a range > of LSP-ID after a specific delay/LPP. But again, LAN is not seen as the > priority in > this document. > [LES:] As has been noted, we already say in Section 4.7 (which does discuss the LAN issues) "A full discussion of how best to do faster flooding on a LAN interface is therefore out of scope for this document." The problem (as Bruno has indicated) as regards operational practices is that whatever we say will be incomplete and to some extent unsatisfactory as we have not studied this problem. There are no doubt many things that could be said - but no collection results in a sound operational description of how to do fast flooding on a LAN. I think we would be better off (and more honest ) if in Section 6.2.1.2 we simply said: "As operation of fast flooding on a LAN interface is out of scope for this document, this section is intentionally empty." ?? Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06
Mirja - In regards to Section 6.3... > > Sec 6.3 > This section is entirely not clear to me. There is no algorithm described and > I > would not know how to implement this. [LES:] This is intentional. As this approach is NOT dependent on any signaling from the receiver, the transmitter is free to implement in whatever manner it finds effective - there are no interoperability issues. As we state: "Such an algorithm is a local matter and there is no requirement or intent to standardize an algorithm." > Also because you interchangeably > use the > terms congestion control and flow control. [LES:] Good point. I believe we should use the term "congestion control" throughout this section. Will work with Bruno to make that change. > Further you say that no input > signal > from the receiver is needed, however, if you want to send with the rate of > acknowledgement received that is an input from the receiver. [LES:] The use of the neighbor partialSNPInterval sub-TLV (Section 4.5) is optional. It may be useful, but as our intention is to have the algorithm work with legacy neighbors who do not support the additional advertisements defined in this document, it is necessary that the algorithm work well even in the absence of that signaling. If by "rate of acknowledgement ...is an input from the receiver" you think we are contradicting ourselves, I will gently pushback. We have not changed the operation of the Update Process in any way. So the acks we receive and the rate at which they were received is information which is available today from current operation of the Update Process. To date it just hasn’t been used to influence transmission rate of other LSPs - it has only been used to cancel retransmissions on the LSPs already sent. [ >However, the > window based TCP-like algorithms does actually implicitly exactly that: it > only > send new data if an acknowledgement is received. It further also takes the > number of PDUs that are acknowledged into account because that can be > configured. If you don’t do that, you sending rate will get lower and lower. > [LES:] Paragraphs 4, 5, 6 discuss both slowing down the transmission rate and speeding up the transmission rate. The algorithm needs to do both - and does so based on the actual performance i.e., how quickly ACKs have been received. Paragraph 6 highlights that we cannot assume that performance is static. If you think that once we slow down we will never speed up then please reread Paragraph 5. At the risk of repeating myself, I emphasize that lack of dependence on signaling by the receiver is a key element of this approach which enables it to work with both legacy and upgraded nodes. Les ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05
Hi All, I reviewed the diffs from 05 to 06 and the email; looks good to me, thank you. I see that there is an active discussion going on about Mirja Kühlewind’s TSVART review of 06. It seems to me it would probably be better to let that play out before sending the document for IETF Last Call. Seem reasonable? By the way, please ping me when you think the conversation has concluded (or anyway reached a state where I should send the doc for IETF LC). I’m going to put it back in the “revised ID needed” substate for now, on the assumption that version 07 will be required to address the TSVART review; this has the benefit that datatracker will update the substate and flag it to me when you push a new version. If you end up concluding no new version is needed, you can let me know and I can clear the substate. Thanks, —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06
[+Les, Guillaume as we go quite deep in the discussion] Hi Mirja, Thank you for your review and comments. Very useful. Please see inline [Bruno] > From: Mirja Kühlewind via Datatracker > Sent: Friday, February 2, 2024 3:57 PM > > Reviewer: Mirja Kühlewind > Review result: Not Ready > > First of all I have a clarification question: The use the of flags TLV with > the O flag is not clear to me. Is that also meant as a configuration > parameter or is that supposed to be a subTLV that has to be sent together > with the PSNP? If it is a configuration, doesn’t the receiver need to confirm > that the configuration is used and how does that work in the LAN scenario > where multiple configurations are used? If it has to be sent together with > the PSNP, this needs to be clarified and it seem a bit strange to me that it > is part of the same TLV. Or maybe I’m missing something completely about the > flag? [Bruno] The O-flag is advertised by the receiver in the Flags sub-TLV, which may be sent either in PSNP or IIH. That's not a configuration but a capability of the receiver which is signaled to the sender. That's only applicable to the point-to-point scenario, not the LAN scenario. ( as on a LAN there is no explicit acknowledgment of the receipt of LSPs between a given LSP transmitter and a given LSP receiver). > it seem a bit strange to me that it is part of the same TLV [Bruno] All those sub-TLVs, at least the one currently defined, carries (relatively) static parameters and are not required to be sent in all IIH or PSNP. The way IS-IS acknowledges the reception of LSP is not changed They are all grouped in a single TLV called " Flooding Parameters TLV" for grouping purpose and also because IS-IS has a limited TLV space. If the above does not clarify, could you please elaborate on what you feel "strange" about? > Then, generally thank you for considering overload and congestion carefully. > Please see my many comments below, however, I think one important part is to > ensure that the network/link doesn’t get normally overloaded with the > parameter selected. You give some recommendation about parameters to use but > not for all and, more importantly, it would be good to define boundaries for > safe use. > What’s a “safe” min or max value? I know this question is often not easy to > answer, however, if you as the expert don’t give the right recommendations, > how should a regular implementer make the right choice? [Bruno] Very fair points. And thank you for acknowledging that this question is not easy to answer... TL;DR: sorry, I don't know. Two general statements first: - IS-IS is running in the control plane of two adjacent routers, typically in backbone of network operators. There is a single point to point link over fiber with typically latest interfaces speed (e.g. > 100G today). I would not assume that IS-IS would overload, or even significantly load this interface. From a jitter standpoint packet priority/CoS could be discussed but I would assume that I'm assuming that this is a different discussion. - currently IS-IS has no flow control nor congestion control. Given this, current values are very conservative (e.g., one packet every 33ms). At the same time that's a very important signaling for the network: we would prefer not dropping LSP but on the other hand delaying LSP for seconds is not helping. For historically and good reasons IS-IS implementers are very conservative. As of today, I would not assume that they would be too aggressive. - one problem of stating values in RFC is that those values may not age well. That's typically the case with IS-IS with some parameters values which are still 25 years old while CPU and networks have evolved significantly since then. So I'm a bit reluctant to write static values in stone again. Coming back to min and max value: - I'm not an implementor, but I do care about my networks. If I were an implementor, I would play safe and advertise values which are safe for my implementation as receiver. I would rather use those values as a protection from a too aggressive sender, than as a permission to overload (DOS) me. Both sender and receiver are within the same administrative domain (for certain). In case of issue, the network operator will debug both the sender and receiver and blame the one which did not behave. - There are a wide range router size/price/capability/generation. Plus I would expect this value to gradually improve as the implementation improve thanks to the capabilities introduced by this document. - I'm definitely not a transport/TCP expert. Does TCP define such min and max values? We propose some guidance for the LPP (which is somewhat IS-IS specific) in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-5.1 But for other parameters, I'm not sure that indicating values would be useful. > Please see further comments below. > > Section 4.7: > “NOTE: The
