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

Yisong Liu <liuyisong@chinamobile.com> Wed, 19 October 2022 02:21 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 DEA0CC1524BA; Tue, 18 Oct 2022 19:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 5_yljs_9AJM5; Tue, 18 Oct 2022 19:21:48 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 05AAFC1524B1; Tue, 18 Oct 2022 19:21:44 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee7634f5f378ef-2e7c2; Wed, 19 Oct 2022 10:21:43 +0800 (CST)
X-RM-TRANSID: 2ee7634f5f378ef-2e7c2
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCCPC (unknown[10.2.149.107]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee7634f5f330ae-cf24e; Wed, 19 Oct 2022 10:21:43 +0800 (CST)
X-RM-TRANSID: 2ee7634f5f330ae-cf24e
From: Yisong Liu <liuyisong@chinamobile.com>
To: msr6@ietf.org
Cc: pim@ietf.org, 'BIER WG' <bier@ietf.org>, mboned@ietf.org, farinacci@gmail.com, 'Stig Venaas' <stig@venaas.com>, hooman.bidgoli@nokia.com
Date: Wed, 19 Oct 2022 10:21:44 +0800
Message-ID: <011701d8e361$88780710$99681530$@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01D8E3A4.969C5880"
X-Mailer: Microsoft Outlook 16.0
Content-Language: zh-cn
Thread-Index: AdjjXvxGc2R/tJlWStKXIMmVhVp50Q==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/1p4sDRHfe50SRZDekqjq3o3cmMY>
Subject: [MBONED] 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: Wed, 19 Oct 2022 02:21:52 -0000

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.

 

 <https://github.com/MSR6-community/MSR6-Issue-List/issues/8> Too large
scale may request overlay multicast (To be clarified) #8

  <https://github.com/MSR6-community/MSR6-Issue-List/issues/10> 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.

 

  <https://github.com/MSR6-community/MSR6-Issue-List/issues/9> 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.

 

 <https://github.com/MSR6-community/MSR6-Issue-List/issues/11> 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