Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
Peter Psenak <ppsenak@cisco.com> Thu, 23 April 2020 09:14 UTC
Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEB13A176F for <lsr@ietfa.amsl.com>; Thu, 23 Apr 2020 02:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVLuRjDZkUAB for <lsr@ietfa.amsl.com>; Thu, 23 Apr 2020 02:14:28 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8D23A176B for <lsr@ietf.org>; Thu, 23 Apr 2020 02:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17105; q=dns/txt; s=iport; t=1587633268; x=1588842868; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oRyg0S0RvSM9ZQdjVOyHNcyIGBF1YbE7pMEkML7CVpU=; b=muDnaRC9c3g0YTVEElBzvit4b6oI7a+S6onrm1LTey0UAm3cR0kd7+yo QoSky35s30JuvDaVb46Cvdt20q0gCqxKSa+nr1hQoNU9PU1y89/hBxoJK KB2GyVJ1T/NBU32wGwYlusMGC+t8Orb5KEDGQGFDb7ESUnIMubFBqGqI/ 4=;
X-IronPort-AV: E=Sophos;i="5.73,306,1583193600"; d="scan'208";a="25516235"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Apr 2020 09:14:26 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 03N9EPDC012308; Thu, 23 Apr 2020 09:14:26 GMT
To: bruno.decraene@orange.com, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>
References: <MW3PR11MB46191E81D5B22B454D8184A4C1100@MW3PR11MB4619.namprd11.prod.outlook.com> <MW3PR11MB461942C752F9CCB0A6E6C1BFC1100@MW3PR11MB4619.namprd11.prod.outlook.com> <13222_1587383221_5E9D8BB5_13222_339_1_53C29892C857584299CBF5D05346208A48E22AF0@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB46191D244D51A05F9AA4631DC1D50@MW3PR11MB4619.namprd11.prod.outlook.com> <19183_1587578655_5EA0871F_19183_421_1_53C29892C857584299CBF5D05346208A48E26EA9@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <34a1bd49-417e-af46-758e-24663b77f813@cisco.com> <32451_1587632254_5EA1587E_32451_425_20_53C29892C857584299CBF5D05346208A48E27C99@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <bdf4b5a4-36f1-d018-a684-f4a5cbd3903c@cisco.com>
Date: Thu, 23 Apr 2020 11:14:25 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <32451_1587632254_5EA1587E_32451_425_20_53C29892C857584299CBF5D05346208A48E27C99@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_ya5vhIo9Xak-eUWapR-Oi3HXx0>
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 09:14:31 -0000
Bruno, On 23/04/2020 10:57, bruno.decraene@orange.com wrote: > Peter, > >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> >> Bruno, >> >> On 22/04/2020 20:04, bruno.decraene@orange.com wrote: >>> Les, >>> >>> Pleasesee inline >>> >>> *From:*Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] >>> *Sent:* Tuesday, April 21, 2020 11:48 PM >>> *To:* DECRAENE Bruno TGI/OLN >>> *Cc:* lsr@ietf.org >>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed >>> >>> Bruno – >>> >>> You have made an assumption that historically vendors have tuned LSP >>> transmission rates to a platform specific value. >>> >>> [Bruno] I don’t think so. What makes you think so? >>> >>> In all cases, that is not my assumption, and for multiple reasons. >>> >>> That certainly is not true in the case of my employer (happy to hear >>> what other vendors have been doing for the past 20 years). >>> >>> The default value is based on minimumBroadcastLSPTransmissionInterval >>> specified in ISO10589. >>> >>> A knob is available to allow tuning (faster or slower) in a given >>> deployment – though in my experience this knob is rarely used. >>> >>> *//*[Bruno] I would agree on both. More interestingly is the why: why >>> aren’t those existing sending parameters tuned, while we agree that >>> default configuration are suboptimal? >>> >>> My take is that: >>> >>> -We don’t want to overload the receiver and create loss of LSP (as this >>> will delay the LSDB synchronization and decrease the goodput). Hence >>> this (the parameters) is receiver dependent (e.g., platform type, number >>> of IGP adjacencies, …). >>> >>> -We don’t know which value to configure : difficult for the network >>> operator to evaluate without a significant knowledge of the receiver >>> implementation (in particular QoS parameters for incoming LSP), vendors >>> are not really proposing value or guidance, especially since the sending >>> behavior is not standardized and slightly different between vendors. So >>> everyone stay safe with default 20 years old values. >>> >>> We already discuss in >>> https://tools.ietf.org/html/draft-ginsberg-lsr-isis-flooding-scale-02#section-2 >>> that this common interpretation isn’t the most appropriate, but >>> historically the concern has been to avoid flooding too fast – not to >>> optimize flooding speed. >>> >>> Obviously, we are revisiting that approach and saying it needs to change >>> – which is something I think we have consensus on. >>> >>> I have provided a description in my recent response as to why it is >>> difficult to derive an optimal value on a per platform basis. You may >>> disagree – but please do not claim that we actually have been doing this >>> for years. We haven’t been. >>> >>> *//*[Bruno] I’m not sure how to rephrase my below email so that we could >>> understand each other, have an answer from your side (I mean employer >>> side), and progress. >>> >>> More succinctly: How do network operator correctly configure the >>> flooding parameters value on the implementation of your employer? In >>> particular given the variety of conditions on the LSP receiver side. >> >> the answer is test and see which value fits best in your specific >> environment. > > I don't think that's good enough, or even feasible given the very diverse set of platforms and environments in large networks, and/or the availability of human resources in smaller networks. > Since Les is reporting that virtually nobody is changing the default value -although we now all agree that they are suboptimal- I think that this is an indication that this strategy is not working. > That's why I brought this to the LSR WG. we agree on the problem and the solution, for most part anyway. I responded with the only option that is available today with existing protocol behavior and parameters available today. thanks, Peter > > We need the IS-IS protocol to work adequately without requiring constant or personalized tuning from the network operator. Coming back to TCP, general user/terminals are not been asked to run test per terminal and per destination/server. It just work relatively adequately. > >> One reason to have some sort of feedback mechanism (being it tx or rx >> based) is to avoid the need to tune today's static parameters and flood >> as fast as the receiver is able to consume and slow down if the receiver >> is not able to cope with the rate we flood. > > +1 > > Thanks, > Bruno > >> thanks, >> Peter >> >> >> >> >> >> >>> >>> --Bruno >>> >>> Les >>> >>> *From:*bruno.decraene@orange.com <bruno.decraene@orange.com> >>> *Sent:* Monday, April 20, 2020 4:47 AM >>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> >>> *Cc:* lsr@ietf.org >>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed >>> >>> Les, >>> >>> After nearly 2 months, can we expect an answer from your side? >>> >>> More specifically, the below question >>> >>> [Bruno] _Assuming_ that the parameters are static, the parameters >>> proposed in draft-decraene-lsr-isis-flooding-speed are the same as the >>> one implemented (configured) on multiple implementations, including the >>> one from your employer. >>> >>> Now do you believe that those parameters can be determined? >>> >>> § If yes, how do you do _today_ on your implementation? (this seems to >>> contradict your statement that you have no way to figure out how to find >>> the right value) >>> >>> § If no, why did you implement those parameters, and ask network >>> operator to configure them? >>> >>> Thank you, >>> >>> --Bruno >>> >>> *From:*DECRAENE Bruno TGI/OLN >>> *Sent:* Wednesday, February 26, 2020 8:03 PM >>> *To:* 'Les Ginsberg (ginsberg)' >>> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org> >>> *Subject:* RE: Flow Control Discussion for IS-IS Flooding Speed >>> >>> Les, >>> >>> Please see inline[Bruno] >>> >>> *From:*Lsr [mailto:lsr-bounces@ietf.org] *On Behalf Of *Les Ginsberg >>> (ginsberg) >>> *Sent:* Wednesday, February 19, 2020 3:32 AM >>> *To:* lsr@ietf.org <mailto:lsr@ietf.org> >>> *Subject:* Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed >>> >>> Base protocol operation of the Update process tracks the flooding of >>> >>> LSPs/interface and guarantees timer-based retransmission on P2P interfaces >>> >>> until an acknowledgment is received. >>> >>> Using this base protocol mechanism in combination with exponential >>> backoff of the >>> >>> retransmission timer provides flow control in the event of temporary >>> overload >>> >>> of the receiver. >>> >>> This mechanism works without protocol extensions, is dynamic, operates >>> >>> independent of the reason for delayed acknowledgment (dropped packets, CPU >>> >>> overload), and does not require additional signaling during the overloaded >>> >>> period. >>> >>> This is consistent with the recommendations in RFC 4222 (OSPF). >>> >>> Receiver-based flow control (as proposed in >>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ ) >>> >>> requires protocol extensions and introduces additional signaling during >>> >>> periods of high load. The asserted reason for this is to optimize >>> throughput - >>> >>> but there is no evidence that it will achieve this goal. >>> >>> Mention has been made to TCP-like flow control mechanisms as a model - which >>> >>> are indeed receiver based. However, there are significant differences >>> between >>> >>> TCP sessions and IGP flooding. >>> >>> TCP consists of a single session between two endpoints. Resources >>> >>> (primarily buffer space) for this session are typically allocated in the >>> >>> control plane and current usage is easily measurable.. >>> >>> IGP flooding is point-to-multi-point, resources to support IGP flooding >>> >>> involve both control plane queues and dataplane queues, both of which are >>> >>> typically not per interface - nor even dedicated to a particular protocol >>> >>> instance. What input is required to optimize receiver-based flow control >>> is not fully specified. >>> >>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ >>> suggests (Section 5) that the values >>> >>> to be advertised: >>> >>> "use a formula based on an off line tests of >>> >>> the overall LSPDU processing speed for a particular set of hardware >>> >>> and the number of interfaces configured for IS-IS" >>> >>> implying that the advertised value is intentionally not dynamic. As such, >>> >>> it could just as easily be configured on the transmit side and not require >>> >>> additional signaling. As a static value, it would necessarily be somewhat >>> >>> conservative as it has to account for the worst case under the current >>> >>> configuration - which means it needs to consider concurrent use of the CPU >>> >>> and dataplane by all protocols/features which are enabled on a router - >>> not all of whose >>> >>> use is likely to be synchronized with peak IS-IS flooding load. >>> >>> [Bruno] _/Assuming/_ that the parameters are static, those parameters >>> >>> oare the same as the one implemented (configured) on multiple >>> implementations, including the one from your employer. Now do you >>> believe that those parameters can be determined? >>> >>> §If yes, how do you do _/today/_ on your implementation? (this seems to >>> contradict your statement that you have no way to figure out how to find >>> the right value) >>> >>> §If no, why did you implement those parameters, and ask network operator >>> to configure them? >>> >>> §There is also the option to reply: I don’t know but don’t care as I >>> leave the issue to the network operator. >>> >>> ocan still provide some form of dynamicity, by using the PSNP as dynamic >>> acknowledgement. >>> >>> oare really dependent on the receiver, not the sender. >>> >>> §the sender will never overload itself. >>> >>> §The receiver has more information, knowing its processing power (low >>> end, high end, 80s, 20s (currently we are stuck with 20 years old value >>> assuming the worst possible receiver (and worst there were, including >>> with packet processing partly done in the control plane processor)), its >>> expected IS-IS load (#neighbors), its preference for bursty LSP >>> reception (high delay between IS-IS CPU allocation cycles, memory not an >>> issue up to x kilo-octet…), its expected control plane load if IS-IS >>> traffic has not higher priority over other control plane traffic…), it’s >>> expected level of QoS prioritization [1] >>> >>> · [1] looks for “Extended SPD Headroom”. E.g. “Since IGP and link >>> stability are more tenuous and more crucial than BGP stability, such >>> packets are now given the highest priority and are given extended SPD >>> headroom with a default of 10 packets. This means that these packets are >>> not dropped if the size of the input hold queue is lower than 185 (input >>> queue default size + spd headroom size + spd extended headroom).” >>> >>> oAnd this is for distributed architecture, 15 years ago. So what about >>> using the above number (in the router configuration), applies Tony’s >>> proposal (*oversubscription/number of IS neighbhors), and advertise this >>> value to your LSP sender? >>> >>> [1] >>> https://www.cisco.com/c/en/us/support/docs/routers/12000-series-routers/29920-spd.html >>> >>> >>> - >>> >>> --Bruno >>> >>> Unless a good case can be made as to why transmit-based flow control is >>> not a good >>> >>> fit and why receiver-based flow control is demonstrably better, it seems >>> >>> unnecessary to extend the protocol. >>> >>> Les >>> >>> *From:*Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf..org>> *On >>> Behalf Of *Les Ginsberg (ginsberg) >>> *Sent:* Tuesday, February 18, 2020 6:25 PM >>> *To:* lsr@ietf.org <mailto:lsr@ietf.org> >>> *Subject:* [Lsr] Flow Control Discussion for IS-IS Flooding Speed >>> >>> Two recent drafts advocate for the use of faster LSP flooding speeds in >>> IS-IS: >>> >>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ >>> >>> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ >>> >>> There is strong agreement on two key points: >>> >>> 1)Modern networks require much faster flooding speeds than are commonly >>> in use today >>> >>> 2)To deploy faster flooding speeds safely some form of flow control is >>> needed >>> >>> The key point of contention between the two drafts is how flow control >>> should be implemented. >>> >>> https://datatracker.ietf.org/doc/draft-decraene-lsr-isis-flooding-speed/ >>> advocates for a receiver based flow control where the receiver >>> advertises in hellos the parameters which indicate the rate/burst size >>> which the receiver is capable of supporting on the interface. Senders >>> are required to limit the rate of LSP transmission on that interface in >>> accordance with the values advertised by the receiver. >>> >>> https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-flooding-scale/ >>> advocates for a transmit based flow control where the transmitter >>> monitors the number of unacknowledged LSPs sent on each interface and >>> implements a backoff algorithm to slow the rate of sending LSPs based on >>> the length of the per interface unacknowledged queue. >>> >>> While other differences between the two drafts exist, it is fair to say >>> that if agreement could be reached on the form of flow control then it >>> is likely other issues could be resolved easily. >>> >>> This email starts the discussion regarding the flow control issue. >>> >>> _________________________________________________________________________________________________________________________ >>> >>> 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. >>> >> > > _________________________________________________________________________________________________________________________ > > 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] Flow Control Discussion for IS-IS Flooding … Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Christian Hopps
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Christian Hopps
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Peter Psenak
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Tony Przygienda
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Acee Lindem (acee)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Acee Lindem (acee)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… bruno.decraene
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Les Ginsberg (ginsberg)
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… Robert Raszuk
- Re: [Lsr] Flow Control Discussion for IS-IS Flood… tony.li