Re: [MBONED] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

Yisong Liu <liuyisong@chinamobile.com> Fri, 21 October 2022 10:25 UTC

Return-Path: <liuyisong@chinamobile.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AFAC1522AC; Fri, 21 Oct 2022 03:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 TQIy-f3-egsM; Fri, 21 Oct 2022 03:25:06 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6BC1524C7; Fri, 21 Oct 2022 03:25:03 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea6352737c52a-54c87; Fri, 21 Oct 2022 18:25:01 +0800 (CST)
X-RM-TRANSID: 2eea6352737c52a-54c87
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCCPC (unknown[117.136.38.180]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee66352737bdb0-c793e; Fri, 21 Oct 2022 18:25:01 +0800 (CST)
X-RM-TRANSID: 2ee66352737bdb0-c793e
From: Yisong Liu <liuyisong@chinamobile.com>
To: 'Dino Farinacci' <farinacci@gmail.com>
Cc: msr6@ietf.org, pim@ietf.org, 'BIER WG' <bier@ietf.org>, mboned@ietf.org, 'Stig Venaas' <stig@venaas.com>, hooman.bidgoli@nokia.com
References: <011701d8e361$88780710$99681530$@chinamobile.com> <D0BA8841-BA90-4DF5-AAE5-A0113D4F17C7@gmail.com>
In-Reply-To: <D0BA8841-BA90-4DF5-AAE5-A0113D4F17C7@gmail.com>
Date: Fri, 21 Oct 2022 18:24:59 +0800
Message-ID: <02fc01d8e537$6037c7e0$20a757a0$@chinamobile.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AdjlNlu6kZMnAcvmQXKUXlPdpkOGGg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/AO1wXX-SCe1UxmscFDe1paPVe7w>
Subject: Re: [MBONED] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Oct 2022 10:25:11 -0000

Hi Dino,

Thanks for clarifying the question. We think there are 2 aspects for this answer.
1. From the view of existing MSR6 TE document, whether 10000 receivers encoded in a packet is acceptable or not depends on the topology and the encoding method. In my understanding, in a total stateless solution, at least 10000 bit should be used for encoding such a multicast tree in the packet as the header expanse.
2. From the view of MSR6, we think this is valid scenario for the large network with large multicast trees and we can discuss more efficient solutions based on source-routing.

Best Regards
Yisong Liu

-----邮件原件-----
发件人: Msr6 <msr6-bounces@ietf.org> 代表 Dino Farinacci
发送时间: 2022年10月19日 10:59
收件人: Yisong Liu <liuyisong@chinamobile.com>
抄送: msr6@ietf.org; pim@ietf.org; BIER WG <bier@ietf.org>; mboned@ietf.org; Stig Venaas <stig@venaas.com>; hooman.bidgoli@nokia.com
主题: Re: [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

You are not addressing the questions. Whatever you decide to put in the source-route, how many of them are in it? Just answer that question. 

The question more specifically is, are 10,000 receivers encoded in in a data packet?

I just asked one question. I would like a decisive answer please.

Dino

> On Oct 18, 2022, at 7:21 PM, Yisong Liu <liuyisong@chinamobile.com> wrote:
> 
> Hi all,
>  
> Here are the responses for the 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11.
>  
> Too large scale may request overlay multicast (To be clarified) #8  
> Surely you wouldn't put 10000 receivers in the source route. So you 
> will need overlays. #10 [Response]Based on the presentation in IETF 114, “Large scale”, “Host-initiated” and “Overlay multicast” are three separate cases. MSR6 is not intended to address scenarios in which all three characteristics exist simultaneously; “Large scale” is for the case of underlay network, for example 5G transport network or the data center network, not an overlay network. “Large scale” also does not describe the number of receivers (e.g, 10k receivers), but rather the size of the network, i.e., the number of network devices.
>  
>  What the size of tree or number of flows?How many hosts in a flow? 
> Sparse or dense tree? #9 [Response]In our consideration, there are three dimensions of multicast scalability: number of services, multicast tree size, network size; all three exist trade-offs. For example, if MSR6 TE encodes the multicast tree into the packet, it could be decoupled from the number of services and network size, but the header overhead is affected by the size of the multicast tree. So it is suitable for large network & small tree & multiple stream scenarios (sparse mode). Large scale doesn’t refer the number of hosts as these are independent cases as mentioned.
>  
> Should not count hosts. Tree starts at cell-side router. This problem 
> has been solved for centuries. Major providers have multicast for 
> these emergency message problems. #11 [Response] 1."Should not count hosts. tree starts at cell-side router." It is right as it is mentioned above: Large scale doesn’t refer the number of hosts .
> 2.With IPv6 and SRv6 already deployed, we think MSR6 is the 
> appropriate transport network solution, compared to existing solutions 3."Major providers have multicast for these emergency message problems" is not very clear. Is there a mistake in the record or can the issue be further clarified?
>  
> If you have further comments, please let us know.
>  
> Best Regards
> Yisong Liu

--
Msr6 mailing list
Msr6@ietf.org
https://www.ietf.org/mailman/listinfo/msr6