Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Les Ginsberg (ginsberg)
Henk - Thanx for your thoughtful posts. I have read your later posts on this thread as well - but decided to reply to this one. Top posting for better readability. There is broad agreement that faster flooding is desirable. There are now two proposals as to how to address the issue - neither of

[Lsr] Opsdir last call review of draft-ietf-isis-mpls-elc-12

2020-05-04 Thread Scott Bradner via Datatracker
Reviewer: Scott Bradner Review result: Ready This is an OPS-DIR review of Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS This ID proposes extensions to IS-IS to permit an egress LSR in a MPLS network to signal ingress LSRs in the network that it can process the

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Christian Hopps
> On May 4, 2020, at 5:47 AM, Henk Smit wrote: > > I'm looking forward to seeing (an outline of) your algorithm. I'm not trying to push any particular algorithm, we already have some proposals. My intention was only to suggest that we not disregard solutions too aggressively. The argument

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Henk Smit
Mitchel wrote: IS-IS has two levels of neighbors via hello level 1s (LSAs) and hello level 2s :, so immediate is somewhat relative.. As Tony said, Level-2 neighbors are still directly adjacent. There might be layer-2 switches between them. But there are never layer-3 routers between 2

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

2020-05-04 Thread Alexander Vainshtein
Peter. Again lot of thanks. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com -Original Message- From: Peter Psenak Sent: Monday, May 4, 2020 11:06 AM To: Alexander Vainshtein ; shrad...@juniper.net; cfils...@cisco.com;

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Henk Smit
On Friday I wrote: I still think we'll end up re-implementing a new (and weaker) TCP. Christian Hopps wrote 2020-05-04 01:27: Let's not be too cynical at the start though! :) I wasn't trying to be cynical. Let me explain my line of reasoning two years ago. When reading about the

Re: [Lsr] SRLG usage in the IGP Flexible Algorithm draft

2020-05-04 Thread Peter Psenak
Hi Sasha, On 03/05/2020 09:46, Alexander Vainshtein wrote: Peter, Lots of thanks for a prompt response. My reading of your response is as following: There are two different ways in which SRLG information can be used with Flexible Algorithms: 1.In a context of a single Flexible Algorithm,

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread Mitchell Erblich
Inline… Mitchell Erblich Implementation of IS-IS for Extreme Networks in what seems Eons ago… erbli...@earthlink.net > On May 3, 2020, at 11:12 PM, tony...@tony.li wrote: > > > Mitchell, > >> I think we/you are looking at two different problems: >> 1) a hop count of 1

Re: [Lsr] Why only a congestion-avoidance algorithm on the sender isn't enough

2020-05-04 Thread tony . li
Mitchell, > I think we/you are looking at two different problems: > 1) a hop count of 1 or maybe two between the two end points 2) and the > multiple / many hop count between the two end points. IS-IS adjacencies are always between immediate L3 neighbors, ignoring