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
- Re: [pim] I-D Action: draft-asaeda-pim-mldproxy-m… Sérgio Figueiredo