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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 07 December 2022 12:22 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 9A448C1527AF for <tsv-area@ietfa.amsl.com>; Wed, 7 Dec 2022 04:22:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
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 RTiRIZkQZ0IV for <tsv-area@ietfa.amsl.com>; Wed, 7 Dec 2022 04:22:07 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id BAAB6C15271D for <tsv-area@ietf.org>; Wed, 7 Dec 2022 04:22:06 -0800 (PST)
Received: (qmail 21435 invoked from network); 7 Dec 2022 12:06:18 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Dec 2022 12:06:18 -0000
Message-ID: <73f67fd0-47b5-af89-801b-073ccd053fb4@necom830.hpcl.titech.ac.jp>
Date: Wed, 07 Dec 2022 21:15:22 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
Subject: Re: [Bier] [pim] Q on the congestion awareness of routing protocols
Content-Language: en-US
To: Robert Raszuk <robert@raszuk.net>
Cc: bier@ietf.org, routing-discussion@ietf.org, tsv-area@ietf.org, pim@ietf.org
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> <CAOj+MMEd779oB+p53tN_njE+k1unToanyaOBLzMX+XTgD912dQ@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
In-Reply-To: <CAOj+MMEd779oB+p53tN_njE+k1unToanyaOBLzMX+XTgD912dQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/QPXjNVcAX-9Azlbqx-NjKFgJb_I>
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 12:22:08 -0000

Robert Raszuk wrote:

>> 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

TCP mesh between 1000 border routers should mean there is no
reflectors, I'm afraid.

>> 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.

As adding or deleting an ASBR for ASes almost always implies policy
changes for the ASes, remaining 999 routers needs policy changes.

							Masataka Ohta