Tony – I am not carrying weapons nor making threats. I have voiced concerns in the past regarding the difficulties in implementing a receiver-based solution due to platform dependencies and also the difficulties in achieving adjustments in real time. Nothing that has been presented thus far – either in slideware or in the draft itself – has spoken to these issues. I am hopeful that Bruno’s new presentation will offer some substance in this area – so looking forward to seeing it.
I am also hopeful that now that we have implementations of each approach that it may be easier to achieve consensus. Let’s see. Les From: Tony Li <tony1ath...@gmail.com> Sent: Friday, July 9, 2021 9:22 AM To: bruno.decra...@orange.com Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr-cha...@ietf.org; lsr@ietf.org Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111 What would happen if all parties simply put down the pitchforks and torches and agreed to collaborate? Tony On Jul 9, 2021, at 9:15 AM, bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote: Les, > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] […] > I also think it would be prudent to delay WG adoption For how long exactly would it be “prudent to delay WG adoption”? (in addition to the past two years) Until what condition? It’s been two years now since draft-decraene-lsr-isis-flooding-speed brought this subject to the WG (and even more in private discussions). Two years during which we have presented our work to the WG, discussed your comments/objections, been asked to provide more data and consequently worked harder to implement it and obtain evaluation results. What’s precisely the bar before a call for WG adoption be initiated? We have data proving the benefit, so after those two years, what are your clear and precise _technical_ objections to the mechanism proposed in draft-decraene-lsr-isis-flooding-speed? Coming back to draft-decraene-lsr-isis-flooding-speed, we have a specification and the flow control part is stable. We have an implementation and many evaluations demonstrating that flow control alone is very effective in typical conditions. we have an additional congestion control part which is still been refined but this part is a local behavior which don’t necessarily needs to be standardized and which is mostly useful when the receivers of the LSP is not CPU-bound which does not seem to be the case from what we have seen. (in most of the cases, receivers are CPU bound. In fact, we needed to artificially create I/O congestion in order to evaluate the congestion control part) . Regarding your draft, in the latest version of your draft, published yesterday, you have removed the specification of your proposed congestion control algorithm… Based on this, I don’t see how technical discussion and comparison of the specification can be achieved. You have an implementation. This is good to know and we are ready to evaluate it under the same conditions than our implementation, so that we can compare the data. Could you please send us an image? We may be able to have data for the interim. --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] Sent: Friday, July 9, 2021 5:00 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111 As is well known, there are two drafts in this problem space: https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ and https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ Regarding the latter, we also have a working implementation and we also have requested a presentation slot for IETF 111 LSR WG meeting. I agree with Bruno that the time available in the WG meeting will likely be inadequate to present full updates for both drafts. In addition, I think it is important that the WG have an opportunity to discuss publicly in an interactive way, the merits of each proposal. The likelihood that time will be available in the scheduled WG meeting for that discussion as well seems low. I therefore join w Bruno in suggesting that an interim meeting dedicated to the flooding speed topic be organized. Given the short time available before IETF 111, I would suggest that we look at scheduling an interim meeting after IETF 111 - but I leave it to the WG chairs to decide when to schedule this. I also think it would be prudent to delay WG adoption calls for either draft until after such an interim meeting is held. In that way the WG can make a more informed decision. Les From: Lsr <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> Sent: Friday, July 9, 2021 2:01 AM To: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org> Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111 Hi chairs, WG, Over the last two years, we have presented and the WG discussed draft-decraene-lsr-isis-flooding-speed at IETF 105 and “107” IETF 105: https://datatracker.ietf.org/meeting/105/proceedings#lsr Note: that the presentation is in first slot/video but a large part of the discussion is in the second one. IETF 107/interim: https://datatracker.ietf.org/meeting/interim-2020-lsr-02/materials/agenda-interim-2020-lsr-02-lsr-01-07.html The goal is to improve flooding performance and robustness to make it both faster when the receiver have free cycles, and slower when the receiver is congested. In addition to technical discussions, a feedback was that implementation and tests/evaluation would be good in order to evaluate the proposal. We are reporting that we have an implementation of [1] based on the open source Free Range Routing implementation. We are now ready to report the evaluation to the WG. We have a lot of data so ideally would need around an hour in order to cover the whole picture. We have requested a slot for IETF 111 LSR meeting. If the IETF 111 slot is short, we’d like to request for an interim meeting. In order to keep the context, the sooner/closer to IETF 111 seems the better. Since we have an implementation, we have requested for a code point, in order to avoid squatting on one. This is currently under review by the designed experts. Finally, given the two-years work, the specification, the implementation and extensive evaluation, we’d like to ask for WG adoption. Thanks, Regards, --Bruno [1] https://datatracker.ietf.org/doc/html/draft-decraene-lsr-isis-flooding-speed _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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 Lsr@ietf.org<mailto:Lsr@ietf.org> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
