Re: [magma] Question about proxy implemenation in RFC 4605

Kunal Shah <kunal.shah@ericsson.com> Mon, 01 November 2010 18:31 UTC

Return-Path: <kunal.shah@ericsson.com>
X-Original-To: magma@core3.amsl.com
Delivered-To: magma@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3456E3A6A43 for <magma@core3.amsl.com>; Mon, 1 Nov 2010 11:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.559
X-Spam-Level:
X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWof5hCDGLpt for <magma@core3.amsl.com>; Mon, 1 Nov 2010 11:31:01 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 2A54E3A6A2C for <magma@ietf.org>; Mon, 1 Nov 2010 11:31:01 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA1IqFp2019461; Mon, 1 Nov 2010 13:52:25 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 1 Nov 2010 14:30:57 -0400
From: Kunal Shah <kunal.shah@ericsson.com>
To: Alvaro Fernandez <Alvaro@soportemv.com>
Date: Mon, 1 Nov 2010 14:30:55 -0400
Thread-Topic: [magma] Question about proxy implemenation in RFC 4605
Thread-Index: Act3y+dEzA46tWwmR6yuBZkXU/iNeAAi/kn8AGaKR0A=
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E73B620D@EUSAACMS0703.eamcs.ericsson.se>
References: <4FD1E7CD248BF84F86BD4814EDDDBCC150E72D61AE@EUSAACMS0703.eamcs.ericsson.se> <D5DC4D51A7E80F46AE952361B9296386C14BAD@PE2800.SOPORTE.local>
In-Reply-To: <D5DC4D51A7E80F46AE952361B9296386C14BAD@PE2800.SOPORTE.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E73B620DEUSAACMS0703e_"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 02 Nov 2010 10:30:00 -0700
Cc: "magma@ietf.org" <magma@ietf.org>
Subject: Re: [magma] Question about proxy implemenation in RFC 4605
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/magma>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Nov 2010 18:31:03 -0000

Hi Alvaro,

For a router to determine that there are no interested hosts on the LAN, it does send out group specific or source-group specific queries. Does this mean, that the proxy device should send out source-group specific queries on other interfaces when deemed required?? How will this scale if there are a large number of interfaces??

Kunal

________________________________
From: Alvaro Fernandez [mailto:Alvaro@soportemv.com]
Sent: Saturday, October 30, 2010 10:36 AM
To: Kunal Shah
Cc: magma@ietf.org
Subject: RE: [magma] Question about proxy implemenation in RFC 4605


Hi Kunal

I read it years ago but I think RFC 4605 explains that the downstream network interface should behave like a router, so the solution is in the state machine explained in RFC3376 for the IGMPv3 router

Álvaro


-----Mensaje original-----
De: magma-bounces@ietf.org en nombre de Kunal Shah
Enviado el: sáb 30/10/2010 2:46
Para: magma@ietf.org
Asunto: [magma] Question about proxy implemenation in RFC 4605

Hi all,

According to RFC 4605, a router creates a membership database after merging the subscriptions on individual interfaces. Lets say that 3 IGMPv3 capable interfaces are as follows:

Interface 1 has host reporting Include S1 -> I(S1)
Interface 2 has host reporting Exclude S2 -> E(0,S2)
Interface 3 has host reporting Exclude nothing -> E(0,0)

For a device doing IGMPv3 proxy, the final membership record for group G is (G, EXCLUDE, NULL). Now lets say the host on interface 3 goes away, because of which the subscription on interface 3 would expire and there wont be any IGMPv3 state on interface 3.  How would the new membership record for PROXY be calculated?? The RFC does not suggest any way to do this. Would IGMP process have to go through each interface again and then recompute the new membership record?? This would be very inefficient especially if there are multiple interfaces.
Is there a better way to recompute the new membership record??


Thanks
Kunal