[pim] Re: 1 Week short WG LC on draft-ietf-pim-light

"Hooman Bidgoli (Nokia)" <hooman.bidgoli@nokia.com> Thu, 05 September 2024 20:01 UTC

Return-Path: <hooman.bidgoli@nokia.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 3090BC157927; Thu, 5 Sep 2024 13:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.254
X-Spam-Level:
X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=nokia.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 FRQABXq0uqC1; Thu, 5 Sep 2024 13:01:09 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2056.outbound.protection.outlook.com [40.107.220.56]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B26C14EB1E; Thu, 5 Sep 2024 13:01:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=o1uWJmvwmqoxCU/UDIyuzv1LxV4vov2RnUeu7hT8ri8s44RZs9z5fiApoO/C2inQlc27CI6KlqpBnC57a4RPImAxLq5z+8tqzduLIUajm8GHo0JgI8nOL99xCWwkfmTeVdgkc54i0lgb8Zmp8Ro9gDAU7MwJTGFgsZGCQ4cNcVRRgzMRDWSBBj2iOx9m4v25HE7jp9pLMIFnt3lhdETH5njIyOz2KwVNuwXY4VKYqYli9DYcYvx1Y14V9Ue6ZzzbdII5wIxjLyBGbzLlvRi572zNuQhVfmRlPHSD7pmdH6gc4M6yemTv0xZD6J/BTVFLsfRgDVttr9F0Icg6XfsADA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XodkS1leqO5PLa2aNRP+l95lWXkrIJ7ROYxD1B0Kf2U=; b=TBAP/J82h7lBFakZqtexifL9YSE9OaovhFV1RR9aspODBIeVOLqqcVWXaHDzODJB2r1jP91NQTAtPRR0GGWnDob1l0n4TpdAqlZ9HTwxSNUcFJVLrFulG/Nadz55Y+nh7Knb1ubXw2BFfS8YfNPweEo+fhx+MPsCbGQvPZkOA5SlxjiZLghBcsAwalHypMrrXtCU7o22oFEEKfWFDb0QKisAx1dTxw/vTFIsWW3hPBf8WNAjd6iapJruQma+1wSampLdyYTWe6XUpLW/nMfV5nZL9riR20gV+IVZC8TPrcdcaAKVB4aNvsQKlby6WY9JqZK28PRlWtZ2P3h5DpP0Tg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XodkS1leqO5PLa2aNRP+l95lWXkrIJ7ROYxD1B0Kf2U=; b=Gf0PxGxILOKZ4M83GAGxdQuu2+Eg6jVHnxI63yfp8ZxxFZpeUpmLRY3aKVuvuYzt4OR34Gk4BASWCoHRGM2phLqXD7dpk9z/1G40NXjSUrmRmsNTP6LJiTPvXpmdGCfteOYLs3aiihbYs6y/ZZS5519jhrDptdmcGw49yRxOQcasCV4gc8mPFzupcs7PjHJv0u4ucJDQHW5zwldOcg9SmZZwr3rEyV2Mc+CfY8ij96ndm4W0a1swb1WjmpU78OCJ5qwz7K70ykqYRoalOH2f5v3yLwjc0tIa9A1CbhRL8KWJiCUpy6pULHDwly2QSJDWZpor7QGjOrBKOuNWjSdtbA==
Received: from PH0PR08MB6581.namprd08.prod.outlook.com (2603:10b6:510:30::8) by PH0PR08MB6664.namprd08.prod.outlook.com (2603:10b6:510:34::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7918.27; Thu, 5 Sep 2024 20:00:58 +0000
Received: from PH0PR08MB6581.namprd08.prod.outlook.com ([fe80::38ad:add6:9d73:b713]) by PH0PR08MB6581.namprd08.prod.outlook.com ([fe80::38ad:add6:9d73:b713%4]) with mapi id 15.20.7918.024; Thu, 5 Sep 2024 20:00:58 +0000
From: "Hooman Bidgoli (Nokia)" <hooman.bidgoli@nokia.com>
To: Toerless Eckert <tte@cs.fau.de>
Thread-Topic: [pim] Re: 1 Week short WG LC on draft-ietf-pim-light
Thread-Index: AQHa/mA/CanhcoN/lUugsntd8yA6jrJH1IaAgAAhfoCAAE8fQIABSWgAgAAHzRA=
Date: Thu, 05 Sep 2024 20:00:58 +0000
Message-ID: <PH0PR08MB6581BA3D8E3DF149DAD23AEA919D2@PH0PR08MB6581.namprd08.prod.outlook.com>
References: <20240827094719924-FmcaEPThwNgcBhDBoQrF@zte.com.cn> <ZtentCGVaLiiI9nC@faui48e.informatik.uni-erlangen.de> <CAHANBtLcWeych34Jt+vDcy-QU+X91QjRpS_bjsR3tUsa7JwP-Q@mail.gmail.com> <ZtioufuD-Iu22vBL@faui48e.informatik.uni-erlangen.de> <PH0PR08MB6581A5520DA98C1EB07330ED919C2@PH0PR08MB6581.namprd08.prod.outlook.com> <Ztn_bKSSoM7xTlUm@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <Ztn_bKSSoM7xTlUm@faui48e.informatik.uni-erlangen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR08MB6581:EE_|PH0PR08MB6664:EE_
x-ms-office365-filtering-correlation-id: aad8bd17-e1d5-4a81-15ca-08dccde575b5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|4022899009|38070700018;
x-microsoft-antispam-message-info: 3IGJQWPg+BPud2zho81aEE/8xnitFw3J6wMOQdPysSVOuX4wvn0CqfuI9/Vst1sRwSGFRrEeQBfHhOTFlqqy140DaCbwgaZKW1mbhtghe0v1ryD0QDuemBa5gn20PdcmFKhdOeSa56tpIGVFUoT/3Avlris3J5SSMS6YWvTo5aYmPn90XiE+0UZtEfTTTWNywoAFgdzIpovbiNqFGsKE0ZlUNjz5cg97q/OnH+jxVfxTuV1Hor9A5VqF0KN91qhFMMR0fB0vonYxVrEmnPwzuFqooXBmxx44pAa5NZVReK+mIJnzyqKL1MsZlW9mrR3y6JpeZ6icotFNqGydfZmMRrhEryASELym+PA91KOc7oUas23zSIu7mutuxUiHlJIK+4D4pW/fC7cgT54GP9Go3g7+JmBa1R4GYBC0y+wcngKZ0bMLIn7G8XKmQi3l0daG0ttD6+HDtKDQUBEk+1YytHq4YhPr1TBB2L/dqt5xn5xb2ECpfSOe+0GLiX2KtDEK7IUx2J9X/HHG6T3xgGXWdZQoVzKLxnP8mVOBr+mc7fXL2uKzi9m0JREGCrJQnOZx43aMHG/BxGlDAmhPw7YuCaHGiXqwGRQ4VumyWW/U8CpMJyKZFOBWns+4Ws4RYKJR2/MvEISUZ+xENq3pAX+LMBruE6BOz4spzBSKrM3oYhrqpe6V7Tf2hZ7SlBGhs3QPGRP/1yH2EXYiXTLfEVdSVXSkUlAorh/+RQAQvl+VOo5HruCVJX1lrQzn4S4VL9Pw38hd5h8OLPVxr/AH248dcBx1AVOWUF0uEHb5Pp9Ob5Li9v1T4DVA8GJAHBrgo+yUyddk11Jp2+M8SknSlQ7OyBu2bVDUo3sbh2eJFKD94yseuu4gPXsvRxWL59A+7CeQReR5HBd4HtToF/cY/mk2gtVVDZ07ewDf0AwOft+Fd2rP9+cYroaitwwmsadX4DwVu0PRzeTAfjx4qU/dTJyVlzuURUtiolZ1fK84ofwEi661y3AkjwqVD1T2TsD9tk6REIK2NyEul8Z0DsQcGDf3tBXTFHVef1+6u3FBshV8Yn51LdCM3ewMjBQ/U93SFIUCyGP6gSd89sVqYewm9vZH/vRT8EdxF44HZIdbbINBCrf3qKz3xccf9MoEtEFHBVvVLtYn7mNaijFjRLnVNrL+pAKniHpvVRTu9iZ+pyqN4DyMohwrgOj4gy+Y0i44DQMBenY4j/Wc4N1jIMXaU7JIFsncJ8Z/72nILTdrGLA4yHWbyaEE4ZaUi+ScYDV53sCizWF9/2bACqFVngjHSC497Vk0PFucPlcFn9IoL4ohYF7iWkAX9WZ2Le3b6cPyr2iS8bZsyEX8TtvzjuenQ7sB8LI8fsG0lv595HDVup4PLU8=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR08MB6581.namprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(4022899009)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: OzdXhZbi4e7mFjBF3wB1mQaWypacQ9jKIRzyHUS31j+0yr5e1BKvQ8K/n0KvWMVa2T0Zu7FMwqO6X0Z0PMmgd2tw8owHpoDA4bwmSINfp8WQ2IGgxcK/tlNWPRHflz3IkAZj6czFEM9YKqixa/PUUyrCiMQ8MxmkTEEIo2VTLWg/z7LfdjquBsPQiyPHSoH/e8g90RaJnS5tOfm0TPeFwMGFWWqc2mofq4Dlu8bcscUV/d7Ykgde0ohQJzD4bOKlDPse04k781Pb9MkKLnUxTRRc/EUcjjTAWtpPYdBq9lEKddXl3zYWCc8gVStB0CjldsZxdB0Tg1XGrUE6ytVaU7j36rkodUs1k+2YOVKtAVGmj1yBL+/DGw4kEfVof5Dv7UaTdbo1WwiiC3xbc+AUu0PYk36HzAk1UFajWbjVmy8jJ0V9FrHKLscBolBeDHYAOH0yFVERwBy1oeU2ZTO85HJIpDP0dfvbxgP4j2Yc9FA3/yJw4qFJUdTc6H6IhZyffXqcVxaoy6IWONbOIeU/zu3GObdz+3GFZUxklmiElJezv78vWKjyNG3YsClhEIBmfLmNQiACI4x+EEA0GeBhnOSZGs+9i2FmolxKHt4Xs/znBEqcO2C/ATPwWHjk6y3t4VapYjIFCzjuGLAzchv81D/YekvC7c4VfGCO66D7b5Zu/3qd4TVCiYpkHtHnlGPFsCHAc/2J2lR0KkU8VJQl8Btn4b5GOBhbaFRaJdEIJWmcJL2RbvxxCSoeBxQH47BzsKlj4S4Kz386YGfdBDonUoUF5D5a78J06BiAZhCDih94htRjoKEPjGqRKfRttrzr93UYvkumrZuUeuEDUZoZzpOxO3YxozBFDERcXrw1KmSB6ndwQgd4S41Q+oer3obMSeQynvvR7Zk/FFaugTCL8L3/kfIA9vR2IaGsb5iXrqLpOCUk6iFW0tWxCB17mz8yYOdXKc7ThQAdq+meW8n71mW50I0oDYJF5voXNMZVYFL5KVxyKL5wz4XvfmyRCKKEYtlBw7njomNJCzsHKFRIcvXRX7GAXZj2O5sw6PPJtPJzNp6G94n3xGBrbKor/aVkt/6fSClOpYULjeqW0sJAEm7V1Z9RTXxCtKWVMJjIJNvZaKJJd30ywyneVadh6M/oo6sXdz2AAxGKqmcU7oB6lxmEaWX8Xj6vAOUzdURNCV/zc6UNzb4PfdGDqfpy7QBdrC8psvDzWZILPEv1xPQGuNYRQ1A+yoFOkxKBSMEr6eIe8Li0fXnyf07nzLp0OlTJaYlQrP5es8fIMs9+Pk1Tz9xK2tfVn7e/Re1rPyCMCzULWvq/nKoBFNBDxJ98jwjQjM5eC8KgfOvhQnZJNIyhAWmS4KvcoLBjcZ+PJHeeR7DZUizWzI6cqy/VJiTswdbUe9BwLDY4WB6HVYTICGoEh/BcrLfN3oXwtHikzeje0VKVr2WjJnRSsH4kjODESX7nEltabV2hwi0nxSE2saS4g++eFohiFWoczQw9vCnAbBer6Bfx1ny1kJlNHtnrrhtK8z1vIAjhm2avCys5aX8ngJvxo4CKa3BZY/LhG5lrYD+ilAxfIDniwjmCMYvD4Gim
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR08MB6581.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: aad8bd17-e1d5-4a81-15ca-08dccde575b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2024 20:00:58.5261 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: SxrjZSno/obNDL9SVJX1UrmNAktDl7x9tdik1wlwitIQRhkFTKoH7j1C60B3Q3xdrs5yoWa1VmmdEcON+fsSIlJbATbI9X78Vgc9a9u6VII=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR08MB6664
Message-ID-Hash: E6TAN7Y7ZQ6Z4YYBRDCBZYNQXL764EPR
X-Message-ID-Hash: E6TAN7Y7ZQ6Z4YYBRDCBZYNQXL764EPR
X-MailFrom: hooman.bidgoli@nokia.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "pim@ietf.org" <pim@ietf.org>, "pim-chairs@ietf.org" <pim-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Re: 1 Week short WG LC on draft-ietf-pim-light
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/yJqxQYYVRjNuWtU8ey8Dn4uO71M>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>

Hi Toerless

I am confused why all these stuff are popping up now after 3 last calls 😊 should these type of conversations happened in past 4 years where all these decisions were made? We have been presenting this work in every single PIM session in every single IETF for past 2 years or so.

In addition I am not 100% following your comments questions below very convoluted
1.      There was a decision "by WG" to bring "PIM light" out of "pim signaling over bier" so it can be used in other use cases and network types.
2.      every one agreed on this, including yourself.
3.      PIM light is a protocol of its "own" that it so happens uses PIM-SM joins and prunes. It is not an extension. This has been very clear in the WG for the past 3 years. This was the idea.
4.      The use case of "pim signaling over bier" is irrelevant to this conversation. It is just an example to clarify the use case. If this is the issue that you have, you are more then welcome to come up with a text for another use case and it will be added to the draft.
        a.      as per draft pim light is useful where pim can not be deployed.
5.      If you have technical concerns that this draft doesn't work with in the scope that it is written in, by all means please list them clearly and we will address.
6.      if you are just confused about use case that is another issue and you can refer back to the previous ietf logs/history to figure out the use case and read about "pim signling over bier" if you want to be entertained 😊
7.      Reviving of "pim signaling over bier" is not a call for this WG it is a call for bier working group.


Thanks
Hooman



-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de>
Sent: Thursday, September 5, 2024 2:59 PM
To: Hooman Bidgoli (Nokia) <hooman.bidgoli@nokia.com>
Cc: Stig Venaas <stig@venaas.com>; pim@ietf.org; pim-chairs@ietf.org
Subject: Re: [pim] Re: 1 Week short WG LC on draft-ietf-pim-light


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



On Wed, Sep 04, 2024 at 11:53:33PM +0000, Hooman Bidgoli (Nokia) wrote:
> Hi All
>
> Toerless I feel you have forgotten that on the last call of PIM signaling over BIER, the WG director at the time, asked us to yank out the new messages (join/prune) from that draft and come up with a new PIM "LIKE" protocol that can be used every where.

Thanks. Would have been good to capture stuff in changelogs and also have more explanations abou the relationship to PIM BIER in this draft.

> After the draft is completed we will use this draft in the PIM signaling over BIER and rewrite that draft pointing it to this pim light draft.

I really prefer for us (PIM-WG) to have a sufficient understand of a whole solution before committing a component of it. So let's please have a quick discuss about what PIM BIER signaling would need to be about (given how PIM BIER signaling is almost 4 years expired):

1. Q: Are there already running implementations we need to take into account ? [Y/N]

2. Q: I take it (from your above remarks), that we should not want a PIM BIER specific encapsulation
   of PIM-JP messages ? [Y/N] - I think we do not need any PIM BIER specific encap (like past AD seems too).

3. To me, 2. means that PIM Light should discuss generic encapsulations for PIM-J/P with PIM Light.
   Which it currently does not. I have no strong opinions between "non-tunnel" (Unicast PIM), or
   IPinIP (v4/v6) or others. Given how non-tunneling alreasdy allows us to use different unicast destination
   addresses from upstream PIM-Neighbor field, it should be flexible enough. And its easy for e.g.;
   P2 switches to recognize it (IP protocol field) as PIM. In case somebody needs to snoop (e.g.: in EVPN).
   So i'll throw in non-encap unicast PIM-J/P as the default encap. IMHO this should also support
   IPv6  header with IPv4 join/prune address elements.

4. Wrt to PIM BIER - i really don't know why we would need that draft at all. If we take away the encap,
   we're left with the J/P Attributes to carry BIER information. But that seems unnecessary and maybe
   even "layer violation" (gasp ;-). Aka: The PIM-J/P is part of the overlay signaling, and AFAIK our
   past overlay signaling solutions (e.g.: MVPN) did work perfectly fine without having to include
   BIER specific information. In other words: The BFIR (confusingly called EBBR in BIER PIM) should
   be able to perfectly well figure out what BIER bits to set if the IBBR simply sends the PIM-JP
   with its BFR-Prefix as its IP(v6) source address. No need for additional J/P elements - tell me where
   my thinking is wrong if you don't agree.

>  We just wanted a mechanism to signal joins/prunes and it so happened that we chose pim join/prune messages for this signaling. It could have been a new message but we didn't want to reinvent the wheel.

Thats fine, no concerns about it. I am only concerned with unnecessary complexity / wheels.

> With that said Inline HB>

Also inline below. Cutting off unchanged stuff.

>   PIM-SM extensions for light interface signaling (PIM light)
>
> HB> Toerless, there is no extensions here, I feel we had this conversation couple of times now. We are not extending anything, to refresh everyone's memory we wanted a new protocol that works without PIM adjacency and hellos that can signal a join or prune of a multicast route <S,G>  from one end to another end. Since the join and prune message was there already in PIM-SM we chose the same messages for PIM light. Now, it just so happens that this protocol works with PIM-SM and PIM-SSM given the considerations spelled out in the draft. Honestly I don't think we should lock this to PIM-SM or SSM because of this reasoning. We talked about this when we were debating the name at start and also while back in the BIER WG before separating the draft. If you recall in PIM over BIER we just needed 2 messages to signal a <S,G> join and <S,G> prune. This 2 messages could have any format, but it was decided that because the PIM message join and prune has the exact format that we need we just reuse it, also this is why we created the new draft to explain how this new protocol "PIM Light" works with other PIM protocols, PIM SM and PIM SSM for now. In Future we can think about PIM bidirectional etc...

But it is just not true. If we have a PIM-SM domain on the left, and a PIM-SM domain on the right, and we connect them with PIM Light, then it is really up to the configuration of the RPs whether we are really only having a large single PIM-SM domain (same RPs on both sides), or whether we are doing interdomain PIM-SM (different RP sets. Need MSDP then - or similar).

Yes, we can have the same nitpicking discussion about BGP as well. And we saw how much complexity it was/is to duplicate or replace all PIM-SM features in BGP.

It is just the most simple and incremental way to understand this technology as an extension to PIM-SM IMHO.

> HB> again I don't think it is an Extension as per above reasoning. In the draft we have explained this in introduction " PLI is useful in scenarios where multicast state needs to be signaled over networks or media that do not support or require full PIM neighborship between routers."

And section 3.2 already shows how it's a myth to think this is not PIM, just PIM messages (IMHO).

> HB> Of course it explains it you need to read the introduction at the
> HB> beginning
>
> HB> It might be desirable to simplify/upgrade some part of an existing network to BIER technology, removing any legacy multicast protocols like PIM. This simplification should be done with minimum interruption or disruption to the other parts of the network from singling, services and software upgrade point of view. To do so this draft is specifies procedures for signaling multicast join and prune messages over the BIER domain, this draft is not trying to create FULL PIM adjacency over a BIER domain between two PIM nodes. The PIM adjacency is terminated at BIER edge routers and only join/prune signaling messages are transported over the BIER network. It just so happened that this draft chose signaling messages to be in par with PIM join/prune messages. These signaling messages are forwarded upstream toward the BIER edge router on path to the Source or Rendezvous point. These signaling messages are encapsulated in a BIER header.

Again, this is just interpretation, and i think the wrong one - given how one needs to sit down and still figure out what bits and pieces of PIM-SM are needed - and how then to configure them.
Any extension relying on PIM Hellos, RP configuration, Assert, DR, ...

Calling this a PIM-SM extension makes it a lot more logical and IMHO simpler to understand and deal with.

Also, there is no good explanation as to why this is needed in the first place. BIER could perfectly well allow you to multicast PIM-JP/Hello/Asserts, so we really need better justification IMHO.
I can think of some. But it really depends on how we scope its applicability.

> Ok. See discuss above. When reading it i got the impression that it could serve as an almost complete simpler replacement of bier-pim signaling by just use unicast tunneling of those PIM-J/P.
>
> HB> Toerless again to refresh your memory and you were one of the wg members that suggested this with area director at the time. After last call on draft-ietf-bier-pim-signaling the were comments that we need to yank out the join/prune messages that is used in that draft and come up with a new protocol that explains how these join/prunes work, given that they have the same format of the PIM-SM join/prunes. This is how this draft was created, and after creating this draft we will reuse it back in PIM signaling over BIER or any where else needed.

I hope we don't need to go back and nitpick on the exact wording of the 4 year old messages, but i am pretty sure i never meant to propose "Use PIM-SM but don't call it PIM-SM"

> I guess if something like EVPN or WiFi is in scope, where we would not need another unicast encpsulation header, then the destination address would intentionally be unicast (e.g.: same node as JP upstream neighbor but maybe a different unicast address of the same node based on whatever routing information one uses to determine the upstream RPF neighbor).

... No response as to whether or not EVPN LIS are in scope or not...
I think it's crucial to understand whether we're talking about broadcast or NBMA LIS as scope for this work.

Cheers
    Toerless

> > For the  BIER use-case it does not matter much what these fields are
> > set to, but it's good if this can work well also when there is no
> > encap.
> >
> > > But given how even the diagram in this draft where taken from that
> > > pim-signaling draft, and i think the whole concept as well, i
> > > would ask for all the authors of that draft (unless they're also
> > > co-authors of this draft) to be mentioned as contributors to this
> > > draft.
> > >
> > > 10. I think it would be good to whip up a small section with at
> > > least a single "default" (SHOULD support) encapsulation for PLI
> > > traffic , so that we would not need yet-another-spec to know how
> > > to configure the minimum interoperable version of actual PLI deployment.
> > >
> > > Would simple unicasted PIM without any tunnel encpasulation
> > > suffice, or is it more prudent to ask for at least IPinIP with
> > > both inner and outer destination addresses being the PLI destination address ?
> >
> > I don't think encap is needed to do PIM light, so simple unicast PIM
> > can suffice.
>
> See point 9.
>
> Maybe enough discuss points to have a higher speed channel to resolve them. ...
>
> Cheers
>     toerless
> >
> > Regards,
> > Stig
> >
> > > Cheers
> > >     Toerless
> > >
> > >
> > > On Tue, Aug 27, 2024 at 09:47:19AM +0800, zhang.zheng@zte.com.cn wrote:
> > > > Hi,
> > > > Because the update content and suggestion from our AD, today begins a one-week wglc for the newest version of https://datatracker.ietf.org/doc/draft-ietf-pim-light/.
> > > > Please let the wg know if you think the 06 version is ready to progress.
> > > > Thanks,
> > > > Sandy
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Original
> > > >
> > > >
> > > > From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > > > To: i-d-announce@ietf.org <i-d-announce@ietf.org>;
> > > > Cc: pim@ietf.org <pim@ietf.org>;
> > > > Date: 2024年08月26日 20:27
> > > > Subject: [pim] I-D Action: draft-ietf-pim-light-06.txt
> > > >
> > > > Internet-Draft draft-ietf-pim-light-06.txt is now available. It
> > > > is a work item of the Protocols for IP Multicast (PIM) WG of the IETF.
> > > >
> > > >    Title:   PIM Light
> > > >    Authors: Hooman Bidgoli
> > > >             Stig Venaas
> > > >             Mankamana Mishra
> > > >             Zhaohui Zhang
> > > >             Mike McBride
> > > >    Name:    draft-ietf-pim-light-06.txt
> > > >    Pages:   9
> > > >    Dates:   2024-08-26
> > > >
> > > > Abstract:
> > > >
> > > >    This document specifies Protocol Independent Multicast Light (PIM
> > > >    Light) and PIM Light Interface (PLI) which does not need PIM Hello
> > > >    message to accept PIM Join/Prune messages.  PLI can signal multicast
> > > >    states over networks that can not support full PIM neighbor
> > > >    discovery, as an example BIER networks that are connecting two or
> > > >    more PIM domains.  This document outlines the PIM Light protocol and
> > > >    procedures to ensure loop-free multicast traffic between two or more
> > > >    PIM Light routers.
> > > >
> > > > The IETF datatracker status page for this Internet-Draft is:
> > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > 2F
> > > > datatracker.ietf.org%2Fdoc%2Fdraft-ietf-pim-light%2F&data=05%7C0
> > > > 2%
> > > > 7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08dccd108e7b%
> > > > 7C
> > > > 5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638610718244246821%7C
> > > > Un
> > > > known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> > > > Ik
> > > > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=JOEnhZ0VrKhOcc4iF9pNH7M1
> > > > Yt
> > > > oU3YvyzJILiMGFMio%3D&reserved=0
> > > >
> > > > There is also an HTMLized version available at:
> > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > 2F
> > > > datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-pim-light-06&data
> > > > =0
> > > > 5%7C02%7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08dccd
> > > > 10
> > > > 8e7b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C63861071824425
> > > > 15
> > > > 60%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > > > CJ
> > > > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=e3XXbIejFSAznwsE1
> > > > fg
> > > > BI35svzPUNqjhQfPRfpFKRfg%3D&reserved=0
> > > >
> > > > A diff from the previous version is available at:
> > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > > 2F
> > > > author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-pim-light-06&
> > > > da
> > > > ta=05%7C02%7Chooman.bidgoli%40nokia.com%7C11a211766bc54ff8b0cd08
> > > > dc
> > > > cd108e7b%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C6386107182
> > > > 44
> > > > 256028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > > > zI
> > > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=11Trwovn2I4GW
> > > > pe
> > > > i9x3A%2BJSFf9z1lPgJ%2FoXssdVXncU%3D&reserved=0
> > > >
> > > > Internet-Drafts are also available by rsync at:
> > > > rsync.ietf.org::internet-drafts
> > > >
> > > >
> > > > _______________________________________________
> > > > pim mailing list -- pim@ietf.org To unsubscribe send an email to
> > > > pim-leave@ietf.org
> > >
> > >
> > >
> > > --
> > > ---
> > > tte@cs.fau.de
> > >
> > > _______________________________________________
> > > pim mailing list -- pim@ietf.org
> > > To unsubscribe send an email to pim-leave@ietf.org
> >
>
> --
> ---
> tte@cs.fau.de
>
> _______________________________________________
> pim mailing list -- pim@ietf.org
> To unsubscribe send an email to pim-leave@ietf.org
>

--
---
tte@cs.fau.de