Re: [Int-area] Multicast draft (fwd)

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 28 March 2017 13:09 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891FB1299AF for <int-area@ietfa.amsl.com>; Tue, 28 Mar 2017 06:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWUM_lcKQXbD for <int-area@ietfa.amsl.com>; Tue, 28 Mar 2017 06:08:59 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CBC128990 for <int-area@ietf.org>; Tue, 28 Mar 2017 06:08:59 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 58487AA; Tue, 28 Mar 2017 15:08:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1490706537; bh=yhGzUb90sbSe0jJQ0e/ZtMzI5JwizN0N9rYh2TnIDxY=; h=Date:From:To:Subject:From; b=jX+9R6rGq0D4U5A1vmtQfoUApU10k6PBR97SiTS8AmPJvUJPb+z5G+C+4I01bn9rZ kye9alIPJdalFkWBJ+5uTPdaSAFetQV09G7d3ETGsbZCtEqsfcQ9VH6L8UXXxIPZnX J+Xz1yX7vgGshbpGjXD+C3LOQLyiV4JmrCeDCJv4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 55858A9 for <int-area@ietf.org>; Tue, 28 Mar 2017 15:08:57 +0200 (CEST)
Date: Tue, 28 Mar 2017 15:08:57 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: int-area@ietf.org
Message-ID: <alpine.DEB.2.02.1703281508150.30226@uplift.swm.pp.se>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/KmQDGIVxa02IeACuctI8ZJ9XjYg>
Subject: Re: [Int-area] Multicast draft (fwd)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 13:09:03 -0000

Sending to list as well

---------- Forwarded message ----------
Date: Fri, 24 Mar 2017 10:26:11 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Juan Carlos Zuniga <j.c.zuniga@ieee.org>
Cc: "Stanley, Dorothy" <dorothy.stanley@hpe.com>
Subject: Re: Multicast draft

On Wed, 22 Mar 2017, Juan Carlos Zuniga wrote:

> Hello Mikael,
> 
> I wanted to call your attention to a new version
> of draft-perkins-intarea-multicast-ieee802. After a long time we got back
> to it. At the moment it is only a reordering of the same information, but
> we believe this new structure will allow us advancing more the draft.
> 
> Any comments either off-line or in the list would be appreciated.
> 
> Note that we are planning to present at IntArea, and there is another
> presentation about a multicast testbed that will reference the draft.

Hi,

commenting while reading through:

typo:
"work primarily over *wilress*"

"to ameliorate the effects of multicast traffic."
I had to look up what ameliorate means.

A reader of 3.1.1 without background knowledge of 802.11 might infer that 
multicast packets are acknowledged by design. From what I understood, this is 
not the case and basic 802.11 operation is that multicast packets can indeed be 
"lost", as in not properly received by STA?

3.1.2 "slow rate". Wouldn't it be better to use "low data rate"?

3.2.1 Not all those protocols use multicast, some are broadcast (right?)

3.2.4 mixes IPv4 and IPv6 terms (not inherently wrong, but might be confusing?)

4.1. How does the AP know the address/mac mapping? DHCP snooping?

4.3. first sentence seems truncated, should be "instead of ARP" or something 
along those lines? Can NDP really be used to negotiate MTU? I wish this were 
true, but as far as I know this is only available in RA?

4.4. Is there a reference to what this function is called in 802-land? Isn't 
this same topic as 4.5 and 4.6?

4.6. Should there be a note on how common GCR is in currently shipping 
products?

5.1. "the core routers which we are using do not support this" We?

I'd also be happier if stateful firewall came before NAT in this section.

5.1 doesn't have any IPv6 measures? It talks about neighbour discovery, but 
then only uses IPv4 terms?


General comment:

I'd like to see IPv4 and IPv6 used throughout the document when it's in a 
section that talks IPv4 or IPv6 specifics, and only use "IP" when it's talking 
about both.


Good document, I think it's valuable to publish a document like this to spread 
awareness of the issues at hand!



-- 
Mikael Abrahamsson    email: swmike@swm.pp.se