Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

From: <[email-masked]>
Date: Fri, 9 Jul 2021 09:00:53 +0000

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Jul 2021 15:00:25 +0000

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 <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, July 9, 2021 2:01 AM
To: [email-masked]; [email-masked]
Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

---

From: <[email-masked]>
Date: Fri, 9 Jul 2021 16:15:12 +0000

Les,

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
[...]
> 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:[email-masked]]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, July 9, 2021 2:01 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2021 09:21:34 -0700

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, [email-masked] wrote:
> 
> Les,
>  
> > From: Les Ginsberg (ginsberg) [mailto:[email-masked] <mailto:[email-masked]>]
> […]
> 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).
> What’s precisely the bar before a call for WG adoption be initiated?
> 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.
> From: Les Ginsberg (ginsberg) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: DECRAENE Bruno INNOV/NET <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 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/>
>  
>  
> From: Lsr <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 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>
>  
> 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.
>  
> 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>
>  
> _______________________________________________
> Lsr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Jul 2021 17:49:10 +0000

Bruno –

Neither of us has presented anything new of substance in the last few IETFs.
There were two presentations recently - one by Arista and one by Huawei – each of which simply demonstrated that it is possible to flood faster - and that in order to do so it is helpful to send acks faster - both points on which there is no disagreement.

To have a productive discussion we both need to present new data - which is why having the discussion as part of the meeting at which the presentations occur makes sense to me.

We removed the example(sic) algorithm from our draft because it was only an example, is not normative, and we did not want the discussion of our approach to be bogged down in a debate on the specifics of the example algorithm.
Based on your response, seems like we were right to remove the algorithm. 😊

Regarding WG adoption, one of the premises of our draft is that faster flooding can be achieved w/o protocol extensions and so there is no need for a draft at all. I am sure we do not yet agree on this - but I do hope that makes clear why adopting either draft at this time is premature.

   Les

From: [email-masked] <[email-masked]>
Sent: Friday, July 9, 2021 9:15 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

[…]

--Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, July 9, 2021 5:00 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

   Les

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 9 Jul 2021 18:01:40 +0000

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 <[email-masked]>
Sent: Friday, July 9, 2021 9:22 AM
To: [email-masked]
Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

Tony

On Jul 9, 2021, at 9:15 AM, [email-masked]<mailto:[email-masked]> wrote:

Les,

[…]

--Bruno

   Les

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.
_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2021 11:25:52 -0700

Les,

I am not seeking consensus at this time. Simply an agreement to collaborate. Work on one draft, with one goal.

Why not?

Tony

> On Jul 9, 2021, at 11:01 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Tony –
>  
> On Jul 9, 2021, at 9:15 AM, [email-masked] <mailto:[email-masked]> wrote:
>  
> Les,
>

---

From: <[email-masked]>
Date: Mon, 12 Jul 2021 08:48:06 +0000

Les,

Faster flooding may be achieved without protocol extension. But if we are at changing flooding, it would be reasonable to try to make it good (rather than just faster than today).
In particular some goals are:
- faster flooding when the receiver has free cycles
- slower flooding when the receiver is busy/congested (either by flooding, or any CPU computation including not coming from IS-IS)
- avoiding/minimizing the parameters that the network operator is been asked to tune
- avoiding/minimizing the loss of LSPs
- robust to a wide variety of conditions (good ones and bad ones)

You seem to agree on changing the flooding behaviour on both the sender and the receiver so that they can better cooperate. That’s protocol extension to me (and IMHO much bigger than the sending of info in one TLV)

Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, July 9, 2021 7:49 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Bruno –

   Les

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 9, 2021 9:15 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

[…]

--Bruno

   Les

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 12 Jul 2021 12:52:36 -0400

> On Jul 9, 2021, at 11:00 AM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 

How about we use the time in the IETF WG meeting to give a high level summary of what would be presented in more depth at the interim, and then we can have discussion to decide what else might should go in the interim. Perhaps others will feel inspired to also present during the interim after hearing the high level summary! :) It shouldn’t be hard to schedule a follow on interim shortly after IETF wraps even if we wait.

Thanks,
Chris (co-chair hat)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 12 Jul 2021 21:00:28 +0000

Chris –

As regards a meeting specifically targeted for the flooding speed topic, here is my personal request/requirement:

The meeting MUST allow at least 50 % of the allocated meeting time for open discussion.
If all we do at the interim meeting is fill the time with presentations, we will not have accomplished much.

However you (as WG chair) go about building an agenda, please ensure that this happens.
Thanx.

    Les

From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: Monday, July 12, 2021 9:53 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] draft-decraene-lsr-isis-flooding-speed & IETF 111

On Jul 9, 2021, at 11:00 AM, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Chris (co-chair hat)

---

From: Christian Hopps <[email-masked]>
Date: Mon, 12 Jul 2021 17:47:32 -0400

"Les Ginsberg (ginsberg)" <[email-masked]> writes:

> Chris –
>
> As regards a meeting specifically targeted for the flooding speed
> topic, here is my personal request/requirement:
>

Oh it MUST, MUST it?

Of course it would include time for discussions. We can all read slides offline.

> If all we do at the interim meeting is fill the time with
> presentations, we will not have accomplished much.

I think this is fairly obvious.

> However you (as WG chair) go about building an agenda, please ensure

Right-o, captain.

Thanks,
Chris.

>     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.
>
>
>
> How about we use the time in the IETF WG meeting to give a high level
> summary of what would be presented in more depth at the interim, and
> then we can have discussion to decide what else might should go in
> the interim. Perhaps others will feel inspired to also present during
> the interim after hearing the high level summary! :) It shouldn’t be
> hard to schedule a follow on interim shortly after IETF wraps even if
> we wait.
>
>
>
> Thanks,
>
> Chris (co-chair hat)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 29 Jul 2021 06:51:58 +0000

Bruno –

Resuming this thread…

I assure you that we have the same goals.
We are not yet in agreement on the best way to achieve those goals.

Looking forward to the WG discussion on Friday.

To get some discussion going in advance – if you have time to do so (which I know is challenging especially during IETF week) – I call your attention to slides 15-18 in the presentation we have prepared:

https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-21-isis-flood-scale-00

I do not intend to present these slides during my portion of the presentation time – but I included them as potential points of discussion during the discussion portion of the meeting (though the WG chairs will decide how best to direct that portion of the time).
I call your attention specifically to Slide 16, which discusses the functional elements in the input path typically seen on router platforms.
Each of these elements has controls associated with it – from queue sizes to punt rates, etc. that play a significant role in delivery of incoming IS-IS PDUs to the protocol running in the control plan.

Your slides – https://datatracker.ietf.org/meeting/111/materials/slides-111-lsr-22-flow-congestion-control-00
 focus only on the direct input queue to IS-IS in the control plane. I do not see how the state of the other staging elements on the path from PDU ingress to IS-IS implementation reading the PDUs in the control plane is known and/or used in determining the flow control state signaled to the transmitting neighbor. If, for example, PDUs were being dropped on ingress and never made it to IS-IS in the control plane, how would your algorithm be aware of this and react to this?

In my experience, the state of these lower level staging elements plays a significant role.

I can imagine that some form of signaling from the dataplane to the control plane about the state of these lower level elements could be possible – and that signaling could be used as input to a receiver based control algorithm. However, given the differences as to how individual platforms implement these lower level elements,  I see it as challenging to get each platform to provide the necessary signaling in real time and to normalize it in a way so that IS-IS flow control logic in the control plane can use the data in a platform independent way. I believe this represents a significant bar to successful deployment of receiver-based flow control.

This is one major reason why we prefer a Tx based flow control mechanism. Tx based flow control simply focuses on the relative rates of LSP transmission and reception of Acknowledgments. Whether slower acks are due to PDU drops at ingress, slow punt path operation, lack of CPU time for IS-IS to process the incoming packets, etc. matters not. Whatever the reason, if acks are not keeping pace with transmission we know we have to slow down.

Please comment on these points as you have time.

Thanx.

   Les

From: [email-masked] <[email-masked]>
Sent: Monday, July 12, 2021 1:48 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: draft-decraene-lsr-isis-flooding-speed & IETF 111

Les,

Bruno

To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Bruno –

   Les

Les,

[…]

--Bruno

   Les

Hi chairs, WG,

Thanks,
Regards,
--Bruno

Thank you.

Thank you.

Thank you.