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 wrote: > > Les, > > > From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com > > <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 > <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/ > <https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/> > and > https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ > <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 > <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 > > <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 > <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 > <https://www.ietf.org/mailman/listinfo/lsr>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
