Re: [Bier] [pim] Q on the congestion awareness of routing protocols

Robert Raszuk <robert@raszuk.net> Wed, 07 December 2022 08:52 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D54C14CE3F for <tsv-area@ietfa.amsl.com>; Wed, 7 Dec 2022 00:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CH-J98OSggF for <tsv-area@ietfa.amsl.com>; Wed, 7 Dec 2022 00:52:28 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E7AC14CE2F for <tsv-area@ietf.org>; Wed, 7 Dec 2022 00:52:13 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id ay8-20020a05600c1e0800b003d0808d2826so2113899wmb.1 for <tsv-area@ietf.org>; Wed, 07 Dec 2022 00:52:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UHLEHgkrUOLBo2RQh9XTNITqWRdqCo7hWuwscONYcCE=; b=Bfy4LezdmTcHIjsQAB0qk9SjDP8YjoYR30fH/bd+JrzYCRiN07ynJAvMYzmNU6vdMc SX9eBPN0Y5bNI67uDprzXr7weIU5Q6KfGDpaxIWP53zeBrmvHi9zWbMvysG07vpvKO7W w8yihd4g4Uq6s3uFwTcw5Hizig2tvQL/embYWRMfFjxrKpGM2vkFVCr8vkAi92LL2jTe j4pGmoqUf7vlQddjCqTEggilmJzpEsb0Vq8ZdDtnYwTCC/UgwbUhaI0KNWU/Lx+kKlZW DTt0EVYe1UccKpDcta5c4DE1JwLLqDWaa0ZaDGd/ATaNl67EnZXXcJbM99lxden0Dwqg wyaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UHLEHgkrUOLBo2RQh9XTNITqWRdqCo7hWuwscONYcCE=; b=M2Qsg9iBCCNfnnJUBGqBbKhm+B/RDE7K714bw6viC1F3tS4J7moJUKtRmQRlVFrk/5 Dj2kp1znMnHPmErYGqwkl4WpFg0oz26/kcKMTHmAM5sYA8QMXKG9djQkHcoB01pmWNLV t0YlGT7JKMRYOpZpLH5pvXF1JuYwt3NWnmFuH1GBnXi1O0+dXtVHOuxquyKJwCel2/NQ lKznxVTuMgnC4exuR1BpWQnxyD5qJ860uc4rrDLTjyR6XbDwRYynwYz9AHye/HwS39hP eD30zIhcClN+jLKq/AoYH8+OadtCqgQpiO3dlPkt1XU7B3gfrJ8U6noqETpOk2HgY08b g/sg==
X-Gm-Message-State: ANoB5pkJe/dp5RSZFzKNazsZuTVXSAMQHKxGtfTNmAOV18H6TN6CTSz0 ekx7Q9Jb1opeoL+p8UDtHw47IMbMaxy2Dwao0Ypoxw==
X-Google-Smtp-Source: AA0mqf60x71cN9TNLKPcqnwvRmSrVasZAbieyNP6kofQmLhHIfVONI5PQtf0UK9xSBx3NoSr8rxhs/wWGO1LIQ8Ru3A=
X-Received: by 2002:a05:600c:46c8:b0:3d1:f0e3:722c with SMTP id q8-20020a05600c46c800b003d1f0e3722cmr2965845wmo.33.1670403131835; Wed, 07 Dec 2022 00:52:11 -0800 (PST)
MIME-Version: 1.0
References: <Y4ovyV074qa3gLSu@faui48e.informatik.uni-erlangen.de> <CAEeTejLa8sdJVU_2OfTo=ZgWRY-kv_7M=xiR-bLyBEXhSDP=Eg@mail.gmail.com> <e2527c9c-c7d1-c6b7-a067-e5ccbdc7e997@necom830.hpcl.titech.ac.jp> <E1p1PaX-009tgu-Hl@mta1.cl.cam.ac.uk> <c86d7ae6-3dad-04be-9c16-0135cc95fe73@necom830.hpcl.titech.ac.jp> <E1p1Rbe-009zgN-1s@mta1.cl.cam.ac.uk> <643e9272-979a-2a0a-d702-2b63cf0de5c4@necom830.hpcl.titech.ac.jp> <CAEeTejJ3yS2fARZNchumfkNyc0cnFfVSW7VdtBaGzhJQ9KmpBg@mail.gmail.com> <85AD093E-05C8-4A6C-8972-9310B8CAE5D5@gmail.com> <d77e4cac-81ff-7a25-73ae-8cb36dc0a8c6@necom830.hpcl.titech.ac.jp> <CA+b+ER=Z6KYt_gcXOV4vty5jr5ADEez_qrB8bSDzuH58nJrbmw@mail.gmail.com> <0455def9-e1fb-2b8a-3090-2683d695e57b@necom830.hpcl.titech.ac.jp>
In-Reply-To: <0455def9-e1fb-2b8a-3090-2683d695e57b@necom830.hpcl.titech.ac.jp>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 07 Dec 2022 09:54:05 +0100
Message-ID: <CAOj+MMEd779oB+p53tN_njE+k1unToanyaOBLzMX+XTgD912dQ@mail.gmail.com>
Subject: Re: [Bier] [pim] Q on the congestion awareness of routing protocols
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: Robert Raszuk <rraszuk@gmail.com>, Dino Farinacci <farinacci@gmail.com>, Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>, bier@ietf.org, routing-discussion@ietf.org, tsv-area@ietf.org, pim@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004e1b5905ef39096f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/VyNzPfuxI6iW1HObYQzskNlBk0c>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Dec 2022 08:52:30 -0000

HI,

> Are you saying that each router receive 999 copies of
> full route (these days, there are 1M routes) information
> for iBGP is not a problem?

If reflectors are configured with ADD-PATHs ALL - yes this is the case.

However those are not *copies* per se. BGP routes consists of two
main parts: net+paths

So each implementation shares nets across all received routes. And when
paths are identical they are also shared.

Some implementations do it better then others (in terms of paths sharing
efficiency), but this is not really 999 times more RAM.

> OTOH, if there are 1000 border routers, configuration
> simplicity means to have some automatic mechanism to
> generate and install configuration files for the routers,
> with which TCP mesh can be maintained automatically
> without any added complexity.

The issue is that while you are absolutely correct in respect to automated
configuration push when you add or delete an ASBR you do not usually want
to push config to all remaining 998 border routers to add or delete a TCP
session
to a new/old node.

Thx,
R.



On Wed, Dec 7, 2022 at 7:08 AM Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> Robert Raszuk wrote:
>
> >> As such, if iBGP by TCP mesh without reflectors is not acceptable,
>
> > See RRs were deployed to address three points:
> > #1 - Configuration simplicity
> > #2 - Path reduction
> > #3 - TCP session reduction
>
>  > In the old days keeping 1000 of TCP connections in custom
>  > kernels were an issue.
>
> Are you saying that each router receive 999 copies of
> full route (these days, there are 1M routes) information
> for iBGP is not a problem?
>
> OTOH, if there are 1000 border routers, configuration
> simplicity means to have some automatic mechanism to
> generate and install configuration files for the routers,
> with which TCP mesh can be maintained automatically
> without any added complexity.
>
>                                         Masataka Ohta
>
> _______________________________________________
> routing-discussion mailing list
> routing-discussion@ietf.org
> https://www.ietf.org/mailman/listinfo/routing-discussion
>