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

Dino Farinacci <farinacci@gmail.com> Mon, 07 November 2022 14:39 UTC

Return-Path: <farinacci@gmail.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 C388DC152585; Mon, 7 Nov 2022 06:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Z3StIGLxxajh; Mon, 7 Nov 2022 06:39:51 -0800 (PST)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 6F2E3C152566; Mon, 7 Nov 2022 06:39:51 -0800 (PST)
Received: by mail-pf1-x42d.google.com with SMTP id g62so10782985pfb.10; Mon, 07 Nov 2022 06:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ZI68tX2ebtnxYWqr6XWihthYNmZmPWF9WJDPrZ9x+yU=; b=Xg3OIxCxcJWusUtmw+UoTkIeyH3zKxUvcvoKRRv8dexXnM1lx7yBSllDhGl5CAaAJc fgXjvKggPWdXUaPy3GFK6IvXVQK0g+VS+ss5Jz/Ga8Aq8HowAomcxelQliMn8BK495RV q31KVgwPiHcRSBWNCZLAi+v14thXxAkfDGSdGjmgsKT32RCEkzbUe0BNmfEqx9HdNuBq Kidlhec3e0mdFbN813ELbXPmFecfn1TPeq76KIQoi6egl0Y1uiUBOFOM5MNDphhHSVhE laoVXX2RprAJPmmSxyy7+17hNk+GyGpY84M9r8WtEm8CH9fo2gtGxC7vwFFRJoh9KPbE C3dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZI68tX2ebtnxYWqr6XWihthYNmZmPWF9WJDPrZ9x+yU=; b=clStMYkDEheYm1XBVt6ACL0e8FRSWNYxRt9U7Ggls8e0yAM0BwzrI0VsheqSPRB24b 3C+jvWLdX4WQ/pb/0PeXGv1hMrMmef3RTZKCrRb0FMtjmB5kVCuiPls7qmUjqlyBW2g/ YlGmufGtjalKFMS/S2EJJxsgDHQKZBFYU6wrPndrWK1hCIyf2ZYpWcA2xVJObptFqptd OtUmb3KyQslfGa7yeFGaYGPGKT7zI9RcQrxYqcrQEsI8Do2zczXcHFoLoR2sfRTxmshz fErrsPUVgQiNmEd9ESZPQDVWGgWrqQAo8uC1yuHoKSt2w2fn5ttRmvj3WYQbdeOXWrcz hQtA==
X-Gm-Message-State: ANoB5plg3vqTm50lyPea+uvU8yO2Tn4rkEUkUOVvU7rDlCCLCsoR1fD0 BwtkC/zx7SKFx7XYEr6NoZue4n65/fNVyg==
X-Google-Smtp-Source: AA0mqf69mEC8Cr6ZB9bORzSamgfdzHSzOD9acwGltsGMMsfqPkXfx9X9wLMt5KzYS1AOa5gvS9rJfg==
X-Received: by 2002:a63:da15:0:b0:470:71df:7ea1 with SMTP id c21-20020a63da15000000b0047071df7ea1mr6051120pgh.292.1667831990818; Mon, 07 Nov 2022 06:39:50 -0800 (PST)
Received: from smtpclient.apple ([2001:67c:370:128:f49c:d8e5:d571:4aa5]) by smtp.gmail.com with ESMTPSA id s1-20020a170902ea0100b00174f61a7d09sm5105440plg.247.2022.11.07.06.39.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2022 06:39:50 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <5a9df50e0b024e44bf58437dd1ecec1d@huawei.com>
Date: Mon, 07 Nov 2022 14:39:45 +0000
Cc: Toerless Eckert <tte@cs.fau.de>, "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, Jeffrey Zhang <zzhang@juniper.net>, "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>, BIER WG <bier@ietf.org>, msr6 <msr6@ietf.org>, mboned <mboned@ietf.org>, pim <pim@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7A27395-D1FF-4F77-BD01-D585E6DD8DD0@gmail.com>
References: <1be1822e66ef49a4a3877d008aacf00e@huawei.com> <62151B24-6679-472E-983B-14E416AED45E@gmail.com> <6368de00.170a0220.d9a50.e216SMTPIN_ADDED_BROKEN@mx.google.com> <DC5AACD7-837B-481E-B87E-96D6D5C27512@gmail.com> <5a9df50e0b024e44bf58437dd1ecec1d@huawei.com>
To: Dirk Trossen <dirk.trossen@huawei.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/cGC6NNyY8HAZCQru-CS6rAQbCF0>
Subject: Re: [MBONED] [Msr6] [Bier] 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: Mon, 07 Nov 2022 14:39:53 -0000

> [DOT] Agree. So this may give you lower latency indeed for the tree building operations. This then leads to the aspect of what kind of state is needed (in the network) to make forwarding operations work. Here the difference between source-based methods (like BIER and MSR6) and IP multicast lies in the group dependency of that state IMO. 

I think the important question is what is the cost of state and is the cost much greater having it in the data-plane then in the control-plane. 

And comparing "source-based BIER/MSR6" with "IP multicast" is mis-represented because "IP multicast" is source based. So I don't know what you really mean.

> 
>> Even then, I was under the impression that leave operations have timeouts to avoid frequent join/leave flapping so you might not even get the per request grouping behaviour you may want. 
>> 
>> Dirk
> 
> They do not since IGMPv2 where a Leave message was introduced. 
> [DOT] What I meant is that forwarding on a sub-tree may still continue even after a Leave message was received, unless you configure a 'fast leave' mechanism. 

The existing Leave message is a fast leave message. Meaning when you receive if you remove the interface (OIF) from the outgoing-interface-list. Of course, you have to be aware of the reference count on the interface. Meaning if PIM joined the interface and so did IGMP and the IGMP leave came in, you DO NOT remove the OIF.

> Of course control-plane packet loss and moderate robustness in retransmission of control-message would cause the last resort state timeout, but I feel this is an exception rather than a rule. And arguably this can be improved with a ligher weight transport than TCP, like using QUIC.
> 
> Your ICN experience should convince you how useful and valuable receiver initiated joins and multicast tree merging is.
> [DOT] Well played 😉 It is, in fact, so no convincing required. But the FRRM semantic does advocate explicit receiver initiated joins as well as multicast tree joining. Its realization via IP multicast uses IGMP for the former and in-network 

Of course it does. Because the seminal idea came from Van who built the early designs of both PIM-SM and NDN. He saw the value in explicit-joins (his term) and brought it to NDN, now ICN.

> spanning trees for the latter. For BIER, MSR6, or even the SDN-based work we did some years ago, the explicit joins are the forward requests where the multicast tree joining is done solely at the source, e.g., by binary 'folding' unicast path into 

Right. Just like a PIM (S,G) Join.

> multicast ones. So I'm not objecting to the receiver-driven architecture (on the contrary) but am only trying to understand how newer technologies (such as BIER and MSR6) may fit under a single semantic to capture them all.

If you can learn the receivers at the source, without choking it, and build a bit-string no longer than 32-bits (anything more wastes packet space), then source-routing ala BIER forwarding works. But that's only 32 receivers. The reason BIER works is because the BF routes to BIER edges which won't typically be 10,000 receivers.  ;-)

Note in the simplified version I put above in one sentence, you can make it work for more than 32 receivers. But instead of receivers, they are replication points (router), which can then add a new 32-bits to forwarding further downstream.

In LISP-RE (replication engineering), we have the mapping system (stored in one place) the replication tree. They are overlay encapsulation paths so you can control fan-out radius so typically a source would send to one packet to an LISP-RTR  (which it has to do in 99% of the cases to get through NATs) that would then replicate to other LISP-RTRs (via the LISP-RE specification). Again, the state is in one place and the LISP-RTR can get the state ahead of time or when the packet arrives depending on your initial packet-loss tolerance is.

Dino