IETF Logo Mail Archive

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Robert Raszuk <robert@raszuk.net> Mon, 27 April 2020 17:55 UTC

Return-Path: <robert@raszuk.net>
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 BDA2B3A12DB for <lsr@ietfa.amsl.com>; Mon, 27 Apr 2020 10:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 ns2aeW8veci4 for <lsr@ietfa.amsl.com>; Mon, 27 Apr 2020 10:55:47 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFE73A12C7 for <lsr@ietf.org>; Mon, 27 Apr 2020 10:55:31 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id k22so14183327eds.6 for <lsr@ietf.org>; Mon, 27 Apr 2020 10:55:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mgYfrn0Hw+U79G1haaU3ksYkzwd5KT6klOTN0Ic6GUI=; b=KTxFdJuOpxeG2LOP0Rq/oG1TDM7y2wYv8Rs1yXouY2+sQ+ikVRjzuIhTjyPeTIngEM oC90QuF+lvecA6M2geojKMrLhxFRbiHtgrO8QHlFTnX+Fw/9kBXY8WdTiq2mfyGvaava 7iJrCNF4Aq6Gxvlw3MXXfA9JrjXmK7gSUOVXZ0SLFpHztPJa1+V7E1d87inTcfSGcPES /vMvJQeE/F/aVFNfXCl7Kc4maz+sktOBF7ciEi5XT4NN6MOAUWN+GvVauHpF3vaxAdXH eF3Ac3Rd3T2RZ9fZajTtuMZZBWAMfmOdNgAceq74pDww8yoTyRSgrisTUivAbFl4Anl+ idTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mgYfrn0Hw+U79G1haaU3ksYkzwd5KT6klOTN0Ic6GUI=; b=sNPw13ZBGVL6D4Y7Xwo9z0war4r+YBs0qj90P5HS4TTuYCTezj/aI3kDQjI7i6L8/E JEd24qnde7oMatjrfp533EpRiNcJpIw7/O+amlW8FZpEOYetsX6/uIqSt+FqLQhhQ6h4 IaHXCvACABSjhHojooiwmL2vaWj22BoYEgWffdDLseSeFlHKxdc2tSL+HLgYNsemBlql B5sRBHUYBc2z0eE7M7SRHLOR8uYD1avZl6WuYoIl82D4oYIwFDirAR2JaInX1k54LbHx p/iPUojpHcx4zxpDo3oojIVQQy0mSlfqbU7mlr/oDmYq++5h8TPw68kpfKVsQufyRpWz tRlA==
X-Gm-Message-State: AGi0PuYMpEgmgpMbJwOl3Hnf9Sf1BUJk3NbFqla4L+wv726/veYcNzQ/ pfYRklOcksbWjvnIQDRtZm7WceQ03SjVsV3juSBUuw==
X-Google-Smtp-Source: APiQypJAmOC/y+uGA01yh/C3iA/xJPmiLJ7H63pujRkXfZqPqrq+SFTQAGyMZCJAml0+rY6mbXUbr5YK/fbBt4lsMl8=
X-Received: by 2002:aa7:c5d1:: with SMTP id h17mr19657993eds.109.1588010129915; Mon, 27 Apr 2020 10:55:29 -0700 (PDT)
MIME-Version: 1.0
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> <CA+wi2hN2A3oZcZWngNjBnZ214jiGNfqyTZpytpK0jrxH68SnqQ@mail.gmail.com> <6448_1587578604_5EA086EC_6448_75_1_53C29892C857584299CBF5D05346208A48E26E6F@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CA+wi2hPd0Ccn_RiSf=EMa6BfPVhN5FnnOR2hz1PeWpMNNub-BA@mail.gmail.com> <19631_1587662111_5EA1CD1F_19631_99_1_53C29892C857584299CBF5D05346208A48E28EDE@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CA+wi2hMm=0C9LVy8po2eoYnrTRC6AKawoMJoDoEm5xtbFEvfhw@mail.gmail.com> <4008_1587720323_5EA2B083_4008_332_1_53C29892C857584299CBF5D05346208A48E29FE5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMHJfkP5J_Jk+qpLi-VPwca-qwmezynKkKifqcyOxoZAsA@mail.gmail.com> <12067_1587976445_5EA698FD_12067_293_6_53C29892C857584299CBF5D05346208A48E2E14C@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMH6OZihneJjtH_PfXKfOh1ydTD4hQK3FfDJxjtRowMrRw@mail.gmail.com> <24062_1587989690_5EA6CCBA_24062_69_1_53C29892C857584299CBF5D05346208A48E2E517@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <4DE67B7F-A8E7-4595-8EB6-BED074C38B2F@cisco.com> <27097_1587992566_5EA6D7F6_27097_166_1_53C29892C857584299CBF5D05346208A48E2E687@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAOj+MMGENdGn-FB5GwkhsMZsTm_gQSYYmaGCyLy=5nAnCtvSRA@mail.gmail.com> <242BC3A4-0BD5-4F60-9B2F-3C9D1E7106E2@tony.li>
In-Reply-To: <242BC3A4-0BD5-4F60-9B2F-3C9D1E7106E2@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 27 Apr 2020 19:55:19 +0200
Message-ID: <CAOj+MMF+jpfz0vsXum7eH=VTVzGA0dkbyXeQqnNwZ2uoibZ1hQ@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Bruno Decraene <bruno.decraene@orange.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, Tony Przygienda <tonysietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b19cf005a4496b7e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_5VmOegGsNPucvFzJ4jwf66o8FM>
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: Mon, 27 Apr 2020 17:55:51 -0000

Hi Tony,


> You already have a per-interface flooding ‘queue' through the
> implementation of the SRM bit in the LSDB, which must be managed on a
> per-interface basis.
>

Today from what I see operators (if they even change the default) normally
apply same timer value on all interfaces. If the timer is static what would
be the incentive for any implementation not to group interfaces with
identical transmit delay ?

- - -

While this thread is very interesting I must observe that from my
experience the issue is usually on the receiver. If LSR would publish a one
page draft/rfc mandating that links state packets MUST or SHOULD be
recognized and separated from any other control plane traffic at the
ingress interface level (on their way to local RE/RP) we likely wouldn't be
having such debate.

Slowing senders just due to bad implementation of the receiving router is
IMHO a little suboptimal (not to say wrong) thing to do.

Kind regards,
R.

v2.23.0 | Report a Bug | By Email