[Bier] FW: New Version Notification for draft-trossen-rtgwg-frrm-00.txt

Dirk Trossen <dirk.trossen@huawei.com> Mon, 18 July 2022 07:49 UTC

Return-Path: <dirk.trossen@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DB459C15AD43 for <bier@ietfa.amsl.com>; Mon, 18 Jul 2022 00:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qacklYD2ZlY3 for <bier@ietfa.amsl.com>; Mon, 18 Jul 2022 00:49:17 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40ED7C15A73A for <bier@ietf.org>; Mon, 18 Jul 2022 00:49:17 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LmYw825dTz67jhH for <bier@ietf.org>; Mon, 18 Jul 2022 15:47:36 +0800 (CST)
Received: from lhreml703-chm.china.huawei.com ( by fraeml734-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.24; Mon, 18 Jul 2022 09:49:15 +0200
Received: from lhreml701-chm.china.huawei.com ( by lhreml703-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Mon, 18 Jul 2022 08:49:14 +0100
Received: from lhreml701-chm.china.huawei.com ([]) by lhreml701-chm.china.huawei.com ([]) with mapi id 15.01.2375.024; Mon, 18 Jul 2022 08:49:14 +0100
From: Dirk Trossen <dirk.trossen@huawei.com>
To: "bier@ietf.org" <bier@ietf.org>
Thread-Topic: New Version Notification for draft-trossen-rtgwg-frrm-00.txt
Thread-Index: AQHYj5hjFfBLfIpZmEen09W3gkO/ga1uN8NAgBWdTcA=
Date: Mon, 18 Jul 2022 07:49:14 +0000
Message-ID: <3663edd5b26b43bb93eb1aa886f05680@huawei.com>
References: <165693375896.11656.15246351183611334061@ietfa.amsl.com> <38c96e1e29b54e60a98f47ebfdb8f501@huawei.com>
In-Reply-To: <38c96e1e29b54e60a98f47ebfdb8f501@huawei.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/K8fmLAF3nJn5nChDuHBTs7kGSXM>
Subject: [Bier] FW: New Version Notification for draft-trossen-rtgwg-frrm-00.txt
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 07:49:18 -0000

Dear Bier community,

I've posted an update to the FRRM draft, previously positioned towards the BIER WG, to the RTG WG, now including a placeholder for MSR6 as another possible realization of this communication semantic. Mostly, I am seeking input from the wider community, including the BIER WG, on how to move this work forward, what WGs may be appropriate (e.g., for solution work but also work on the communication semantic itself). 

Please let me know of any insights and comments you may have, either here or on the RTG WG list.



-----Original Message-----
From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Dirk Trossen
Sent: 04 July 2022 15:44
To: RTGWG <rtgwg@ietf.org>
Subject: FW: New Version Notification for draft-trossen-rtgwg-frrm-00.txt

Dear all,

I've uploaded the below draft for consideration in the RTG WG, outlining a communication semantic for multicast where the endpoint selection is based on a 'common characteristic' in the form of, e.g., a URL, while the path selection is realized through a separate (in the two example source routed) identifier. This links to the discussion in evolving communication semantics during the recent interim meeting where the question on " What are the things that are identified by the identifiers?" was asked. 

This draft follows a previously published BIER WG draft but now that the draft aims at including other realizations of the described FRRM communication semantic, I thought that a submission to the RTG WG would make more sense.

Any thoughts and feedback are welcome.



-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 04 July 2022 13:23
To: Dirk Trossen <dirk.trossen@huawei.com>
Subject: New Version Notification for draft-trossen-rtgwg-frrm-00.txt

A new version of I-D, draft-trossen-rtgwg-frrm-00.txt has been successfully submitted by Dirk Trossen and posted to the IETF repository.

Name:		draft-trossen-rtgwg-frrm
Revision:	00
Title:		Forward Requests Return Multicast (FRRM) Communication Semantic
Document date:	2022-07-04
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/archive/id/draft-trossen-rtgwg-frrm-00.txt
Status:         https://datatracker.ietf.org/doc/draft-trossen-rtgwg-frrm/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-trossen-rtgwg-frrm

   This document introduces a communication semantic for multicast that
   is initiated through forward requests, resulting in dynamic return
   multicast to the set of initiating clients.  The key dynamic nature
   here is the return multicast relations being possibly different for
   every transmission.

   We introduce this semantic more formally, present exemplifying use
   cases and then focus on realizing this semantic using two multicast

   Although this document formally introduces the FRRM semantic as a new
   communication semantic, it does not intend to show the realization of
   it through the specific multicast technologies in all details.  This
   is left for separate documents, if desired.


The IETF Secretariat

rtgwg mailing list