Re: [manet] Topic for discussion?
Rick Taylor <firstname.lastname@example.org> Mon, 22 July 2019 20:37 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676EC120287 for <email@example.com>; Mon, 22 Jul 2019 13:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([184.108.40.206]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9p9uHrHluU5 for <firstname.lastname@example.org>; Mon, 22 Jul 2019 13:37:00 -0700 (PDT)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [220.127.116.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0DBA1202CE for <email@example.com>; Mon, 22 Jul 2019 13:36:54 -0700 (PDT)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168]) by tss-server1.home.tropicalstormsoftware.com ([fe80::48e4:acbb:6065:8168%16]) with mapi id 14.03.0468.000; Mon, 22 Jul 2019 21:36:48 +0100
From: Rick Taylor <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Thread-Topic: Topic for discussion?
Date: Mon, 22 Jul 2019 20:36:46 +0000
Accept-Language: en-GB, en-US
Content-Type: text/plain; charset="utf-8"
Subject: Re: [manet] Topic for discussion?
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 20:37:07 -0000
Hi Lou, I think this makes sense. I believe multicast is on the charter, and although DLEP has some things to say about multicast, it is intentionally a bit vague in places. If we can work out a few work items of value that the WG wants to work on, then I'm all in favour. I presented some very early ideas about a DLEP data item to indicate the link-layer suitability for being a multicast rendezvous point, not exactly the same topic, but I'm interested in feedback. Cheers, Rick On Mon, 2019-07-22 at 16:25 -0400, Lou Berger wrote: > Hi, > If there is time on the agenda I'd like to raise/have a > discussion on > dlep support for IP multicast. These questions come out of looking > at > the opensource dlep implementation posted at > https://github.com/mit-ll/LL-DLEP and RFC8175. The questions are: > > (a) How does a multicast receiver identify itself (and remove itself) > > (b) how does a (potential) multicast sender know about a multicast > group > and it's related parameters > > (c) how does a (potential) multicast sender know what endpoints are > reachable via a multicast group > > I raised this same question with a number of people including the > RFC8175 authors and we generally agreed that there are answers for > (a) > and (b) that can be traced easily/obviously back to RFC8175, and a > fairly straight forward answer to (c) that we don't think falls > within > the intent of the RFC. (At least the authors of RFC8175 gave the > same > answers that we separately arrived at.) > > I think it would be great if we could review the questions and > ensure > that we all agree on the answers. I can through some slides together > on > this, or we Stan/Rick could do the same. - Or we can start with > Stan's > (if he prefers) email on the topic. > > Thoughts? > > Thanks, > Lou > > >