Re: [pim] I-D Action: draft-asaeda-pim-mldproxy-multif-00.txt

Sérgio Figueiredo <sfigueiredo@av.it.pt> Tue, 06 November 2012 15:48 UTC

Return-Path: <sfigueiredo@av.it.pt>
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 A210021F84A7 for <pim@ietfa.amsl.com>; Tue, 6 Nov 2012 07:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8tw+n4lXjXX for <pim@ietfa.amsl.com>; Tue, 6 Nov 2012 07:48:11 -0800 (PST)
Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80321F853C for <pim@ietf.org>; Tue, 6 Nov 2012 07:48:09 -0800 (PST)
Received: from [193.136.93.29] (account sfigueiredo@av.it.pt [193.136.93.29] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 66932630 for pim@ietf.org; Tue, 06 Nov 2012 15:48:07 +0000
Message-ID: <50993137.9050709@av.it.pt>
Date: Tue, 06 Nov 2012 15:48:07 +0000
From: Sérgio Figueiredo <sfigueiredo@av.it.pt>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: pim@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [pim] I-D Action: draft-asaeda-pim-mldproxy-multif-00.txt
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 06 Nov 2012 15:48:11 -0000

Hi all,

I went through this draft, which I found interesting and a logical step 
for MLD Proxy evolution, as it might be a simple answer to the support 
of several new scenarios. I will try to review the "Extension of the MLD 
proxy functionality to support multiple upstream interfaces" as well 
when I find the time.

For now, please check my comments below:

Abstract:
"an IGMP/MLD proxy device receives multicast packets through multiple 
upstream interfaces, so that it is useful for multihoming support".
P1 => It's interesting that you apply the term multihoming here. This 
mean the proposal could actually be termed as "Multihomed MLD Proxy", right?

Section 1:
"same IGMP/MLD records MUST NOT be transmitted from different upstream 
interfaces simultaneously"
P2 => As it is not the records which are transmitted, I propose writing 
this as: "the multicast traffic pertaining to any IGMP/MLD record MUST 
NOT be transmitted from different upstream interfaces simultaneously".

"On the other hand, there are requirements that an IGMP/MLD proxy device 
allows to use multiple upstream interfaces."
P3 => Should be rewritten as: "On the other hand, there are scenarios 
which require a IGMP/MLD proxy device enabled with multiple upstream 
interfaces".

"For example, a proxy device having more than two interfaces may want to 
access to different networks, such as Internet and Intranet"
P4 => Probably should be corrected to "(...) a proxy device in a machine 
connected to multiple networks, such as (...)"

"This document describes the way of supporting the scenario in which an 
IGMP/MLD proxy device enables to configure "multiple upstream 
interfaces" and receives multicast packets through these interfaces".
P5 => Ok, so this defines the scope of the document. Does it also means 
that scenarios where both the upstream interfaces are used to send 
traffic are excluded? I don't think so, at least after looking to 
section 3.1.

Section 3.1:
"Regarding the case that a proxy device receives multicast packets on 
its downstream interface, it forwards the packets to each downstream 
interface based on the downstream interface's subscriptions. A proxy 
device forwards packets received on any downstream interface to the 
configured upstream interfaces, and to each downstream interface other 
than the incoming interface based upon the downstream interfaces' 
subscriptions."
P6 => The same point is repeated. This should be shortened to: "When a 
proxy device receives multicast packets on its downstream interface, it 
forwards the packets to the configured upstream interface and to each 
downstream interface based on the downstream interfaces' subscriptions."

Section 3.2:
"When the proxy device transmits an IGMP/ MLD report message, it 
examines the source and multicast addresses in the IGMP/MLD records of 
the report message and transmits the appropriate IGMP/MLD report 
message(s) from the selected upstream interface(s) that are configured 
with the range of the supported source and multicast address prefixes."
P7 => Should be corrected to "Before transmitting an IGMP / MLD Report 
(...)".
P8 => Besides, the sentence is too long and a bit confusing. I would 
propose ""Before transmitting IGMP/ MLD Report messages, the MLD Proxy 
examines the source and multicast addresses of each of the IGMP/MLD 
records contained in the received IGMP/MLD Report messages. Based on the 
verified multicast group and source prefixes, It then selects the 
appropriate upstream interface, in a per-record basis.". Moreoever, I 
would add: "The IGMP/MLD Report sent through each upstream interface is 
the aggregation of all downstream group membership fitting the 
designated prefixes."
I.e. The Proxy will build its aggregated Reports based on the G and S 
prefixes of each record in received IGMP/MLD Reports. Or in other words, 
Multicast Address Prefix and Source Prefix will act as filters to select 
the upstream interface to be used for the subscription.

Best regards,
Sérgio