Re: [pim] draft-ietf-pim-multicast-lessons-learned-02 & BIDIR-PIM

Dino Farinacci <farinacci@gmail.com> Thu, 07 December 2023 00:43 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B21C090361 for <pim@ietfa.amsl.com>; Wed, 6 Dec 2023 16:43:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 ePCILCVlrS-m for <pim@ietfa.amsl.com>; Wed, 6 Dec 2023 16:43:29 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 AA980C2395EF for <pim@ietf.org>; Wed, 6 Dec 2023 16:43:29 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-5c65ca2e1eeso242693a12.2 for <pim@ietf.org>; Wed, 06 Dec 2023 16:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701909809; x=1702514609; darn=ietf.org; 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=E6P61L45DAMfmGzs36oRkSao8xDampZp5t4qsc5P2wg=; b=jMdIjoT6RE4i7Q7GKEahsKoBze+LN8qxSE64YZhmne0Dny4LKncBYu3hpifZ1wqMTH buW0M/WDG84yzsd59a6Sjz+XWcc5yOowugR76nNvuAyA9QRgSUMJPwUv1p4KcvKWV/dU /5YUHq98RKnMw+n3qEjhNNDXqaxiCAXTWaSvbpes19e4cnOlCvMQ6EJDtWogpCI+gBPY cp1e2BrdcJIpQliuTWlXSZddkShsdIslBVcUdpQcvQrtodJAFe+Qu58O7yKzFNIpXcdP CjeOl0A8y9CDS7vnFh8h7u510f1ePD6uQPEn+ktOJXE2QB5MP5AMWnFKoCapSBCDI2YW t+kA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701909809; x=1702514609; 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=E6P61L45DAMfmGzs36oRkSao8xDampZp5t4qsc5P2wg=; b=qUfrtVLI6ZpD9ttOsNVxFEvrFIuY3qrS9yg3uc1Xc3Xk0pU0qL0eWGWV4dr+1J6nD2 ErR22+sKdTm4O5wqefhY4raG9Qs9YihGwAUCxNHvnDdRDzMzS5HQGcO2On0dNFNGsrpy zlwE4w1a2/83yF4uuFyuCZrywgbEN+37bsRR7zTFX2Bx0BsQ11jEs9M0MeOSf8l4dFmW yUVHQrJncKLAkRaItV5lJPY5Z/ZNXZgPBq+OUZ5NLq2faG5EpcUogSOs+EeTGvBlwfP4 4VlWAT9WqUQ7hExt2+spJ08nlUpdbbQObS1G6b429/j2ls5HPkpdt+XuhZVFM0dk9Hkz RsAA==
X-Gm-Message-State: AOJu0YxrODMq5ttpXFdhWM5pWXeGdvoLIn3my1auqn3SQO1OKtLTn7Z6 ATFzo5LfBM2lKnkeK21XexQ=
X-Google-Smtp-Source: AGHT+IFimmSu1VxTXYMeBBL9S3NZd6qvt0uPsFUgVjlEmSJ8zpLyTjuNiCEH+UXXuCdf5IYWXEszLw==
X-Received: by 2002:a05:6a20:5603:b0:18f:97c:5b98 with SMTP id ir3-20020a056a20560300b0018f097c5b98mr1412792pzc.102.1701909808625; Wed, 06 Dec 2023 16:43:28 -0800 (PST)
Received: from smtpclient.apple (c-24-5-184-219.hsd1.ca.comcast.net. [24.5.184.219]) by smtp.gmail.com with ESMTPSA id m22-20020a638c16000000b005c67a388836sm78250pgd.62.2023.12.06.16.43.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2023 16:43:28 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <5d83ab75-c455-3758-294a-057d1dd16b36@juniper.net>
Date: Wed, 06 Dec 2023 16:43:17 -0800
Cc: Michael McBride <michael.mcbride@futurewei.com>, "James.A.Stevens@collins.com" <James.A.Stevens@collins.com>, "pim@ietf.org" <pim@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D855EF5-2957-4AC6-8C48-AC04B70B7BC8@gmail.com>
References: <mailman.25917.1701459411.4452.pim@ietf.org> <PH1P110MB11484E355D8A8E5748F2AD77B081A@PH1P110MB1148.NAMP110.PROD.OUTLOOK.COM> <4a7068a1-9e96-a23f-9a39-057b8c4889a6@juniper.net> <CY4PR1301MB20715F999EABF27A3203A195F484A@CY4PR1301MB2071.namprd13.prod.outlook.com> <BAE79A85-793A-42FD-A8E8-80F78450C821@gmail.com> <5d83ab75-c455-3758-294a-057d1dd16b36@juniper.net>
To: Lenny Giuliano <lenny@juniper.net>
X-Mailer: Apple Mail (2.3731.700.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/0kLLq6O7He5bM08lpV9BI6HsVJg>
Subject: Re: [pim] draft-ietf-pim-multicast-lessons-learned-02 & BIDIR-PIM
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Dec 2023 00:43:33 -0000

So how does an app do an Internet based expanding ring search on top of multicast routing?

Dino

> On Dec 6, 2023, at 3:13 PM, Leonard Giuliano <lenny@juniper.net> wrote:
> 
> 
> I think the definition of "deprecate" meaning to "discourage the use of" 
> here is applicable (https://www.merriam-webster.com/dictionary/deprecate).  
> And a BCP is basically a formal recommendation.  So I think these things 
> all mean the same thing.  But I think the Abstract for RFC8815 articulates 
> the intention of this doc pretty clearly:
> 
> Abstract
> 
> This document recommends deprecation of the use of Any-Source Multicast 
> (ASM) for interdomain multicast. It recommends the use of Source-Specific 
> Multicast (SSM) for interdomain multicast applications and recommends that 
> hosts and routers in these deployments fully support SSM. The 
> recommendations in this document do not preclude the continued use of ASM 
> within a single organization or domain and are especially easy to adopt in 
> existing deployments of intradomain ASM using PIM Sparse Mode (PIM-SM).
> 
> 
> On Wed, 6 Dec 2023, Dino Farinacci wrote:
> 
> | 
> | The terms "deprecating" and "not deploying" say different things, where the former is stronger than the latter. Does the lessons-learned document want to make a stronger statement or just be compatible with RFC 8815?
> | 
> | And notice the verb "recommending" keeps it light as well. I guess to avoid mandates.
> | 
> | Dino
> | 
> | > On Dec 6, 2023, at 11:56 AM, Michael McBride <michael.mcbride@futurewei.com> wrote:
> | >
> | >> Correct, RFC8815 deprecates Interdomain ASM
> | >
> | > But does it? It certainly recommends doing so. This is what I've been trying to get at. 8815 recommends not deploying interdomain ASM. But is that deprecation? The protocols involved certainly are not deprecated. Maybe it's just semantics. When I think of deprecation I think of formal deprecation like TLS 1.0/1 deprecation in 8996.
> | >
> | > So to be accurate in our future drafts, like lessons-learned, I would rather say RFC8815 recommends deprecating Interdomain ASM.
> | >
> | > mike
> | >
> | >
> | >
> | > -----Original Message-----
> | > From: pim <pim-bounces@ietf.org> On Behalf Of Leonard Giuliano
> | > Sent: Tuesday, December 5, 2023 4:52 PM
> | > To: Stevens, Jim A Collins <James.A.Stevens=40collins.com@dmarc.ietf.org>
> | > Cc: pim@ietf.org
> | > Subject: Re: [pim] draft-ietf-pim-multicast-lessons-learned-02 & BIDIR-PIM
> | >
> | >
> | > On Fri, 1 Dec 2023, Stevens, Jim A Collins wrote:
> | >
> | > <snipped>
> | > |
> | > | RFC 8815 deprecates ASM for interdomain but not for intradomain
> | > |
> | > | However, when providing feedback on the draft RFC 8815 I couldn't come
> | > | up with interdomain ASM examples.  Since then, I've found interdomain
> | > | ASM use cases where multiple national militaries operate together and
> | > | are sharing tactical data using multicast groups - again where many
> | > | nodes can be sources as well as destinations - so need to be ASM.
> | > | These cases typically operate with IPsec and have similar inter-domain
> | > | peering like RFC 8313 section 3.2.  So, if RFC 8815 were still in
> | > | draft, I would argue that ASM shouldn't be deprecated for ASM, but
> | > | instead have a discussion on when interdomain ASM makes sense and when it doesn't.
> | >
> | > Correct, RFC8815 deprecates Interdomain ASM.  The doc is very clear about not applying to Intradomain, in large part to Jim's input.  And indeed, section 4.8 could certainly cover the scenario listed above.
> | >
> | > That said, it's worth remembering that the WG's do not have a police force to enforce BCPs and that these recommendations are just that.  It's also worth remembering the purpose of RFC8815 in the first place.  Namely, to give clear direction to the rest of the industry, and in particular to app devs, to focus on SSM.  Two+ decades after IGMPv3/SSM were specified, we still have many devices like set-top boxes that do not support IGMPv3, and operators had nothing to point to for guidance to those folks.  Does there exist some apps out there that might be better suited to ASM? Certainly, but a solid consensus agreed those were exceptions that were not applicable to interdomain deployments and not worth the cost of supporting from a network ops perspective.  We must always balance tradeoffs, and the motivation behind RFC8815 was that a lack of clear direction from the community on the preferred service model going forward was hindering mcast deployment.  We could have riddled the doc wit
> | > h exceptions, but we felt that would have watered it down and made it meaningless.  So we drew a firm line at interdomain ASM deprecation.
> | >
> | > On another note, thanks @Jim for the observation in this draft about "PIM"
> | > and how Bidir doesn't fit so neatly into the SPT-RPT discussion with regard to PIM-SM.  I know I am guilty of lazily referring to "PIM" when I really mean "PIM-SM."
> | >
> | > _______________________________________________
> | > pim mailing list
> | > pim@ietf.org
> | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Fvdjxb83v2LdetnnWv3ifyy0XcJm1TO2V9A8G-mNucjx6t2cJ5m661EdX6f_7la7H06c6XD4IjPiOkgq$
> | >
> | > _______________________________________________
> | > pim mailing list
> | > pim@ietf.org
> | > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim__;!!NEt6yMaO-gk!Fvdjxb83v2LdetnnWv3ifyy0XcJm1TO2V9A8G-mNucjx6t2cJ5m661EdX6f_7la7H06c6XD4IjPiOkgq$
> | 
> |