Re: Question about proxy implemenation in RFC 4605
"Alvaro Fernandez" <[email protected]> Mon, 1 Nov 2010 22:19:25 +0100
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============1296815355== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7A0A.759A9434" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7A0A.759A9434 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kunai, I thing my previous Mail was wrong. I was thinking in once interface = with m=FAltiple host and this is not your question. The proxy should apply same rules explained inRFC3376 in the funci=F3n = IPMulticastListen when there are different sockets using the same = multicast group. I think there is no need for queries, just apply these rules. Hope this will help =C1lvaro=20 -----Mensaje original----- De: Kunal Shah [mailto:[email protected]] Enviado el: lun 01/11/2010 19:30 Para: Alvaro Fernandez CC: [email protected] Asunto: RE: [magma] Question about proxy implemenation in RFC 4605 =20 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:[email protected]] Sent: Saturday, October 30, 2010 10:36 AM To: Kunal Shah Cc: [email protected] 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 =C1lvaro -----Mensaje original----- De: [email protected] en nombre de Kunal Shah Enviado el: s=E1b 30/10/2010 2:46 Para: [email protected] 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 ------_=_NextPart_001_01CB7A0A.759A9434 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>RE: [magma] Question about proxy implemenation in RFC = 4605</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>Hi Kunai,<BR> <BR> I thing my previous Mail was wrong. I was thinking in once interface = with m=FAltiple host and this is not your question.<BR> <BR> The proxy should apply same rules explained inRFC3376 in the = funci=F3n IPMulticastListen when there are different sockets using the = same multicast group.<BR> <BR> I think there is no need for queries, just apply these rules.<BR> <BR> Hope this will help<BR> <BR> =C1lvaro<BR> <BR> -----Mensaje original-----<BR> De: Kunal Shah [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A= >]<BR> Enviado el: lun 01/11/2010 19:30<BR> Para: Alvaro Fernandez<BR> CC: [email protected]<BR> Asunto: RE: [magma] Question about proxy implemenation in RFC 4605<BR> <BR> Hi Alvaro,<BR> <BR> 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??<BR> <BR> Kunal<BR> <BR> ________________________________<BR> From: Alvaro Fernandez [<A = HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>= Sent: Saturday, October 30, 2010 10:36 AM<BR> To: Kunal Shah<BR> Cc: [email protected]<BR> Subject: RE: [magma] Question about proxy implemenation in RFC 4605<BR> <BR> <BR> Hi Kunal<BR> <BR> 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<BR> <BR> =C1lvaro<BR> <BR> <BR> -----Mensaje original-----<BR> De: [email protected] en nombre de Kunal Shah<BR> Enviado el: s=E1b 30/10/2010 2:46<BR> Para: [email protected]<BR> Asunto: [magma] Question about proxy implemenation in RFC 4605<BR> <BR> Hi all,<BR> <BR> 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:<BR> <BR> Interface 1 has host reporting Include S1 -> I(S1)<BR> Interface 2 has host reporting Exclude S2 -> E(0,S2)<BR> Interface 3 has host reporting Exclude nothing -> E(0,0)<BR> <BR> 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.<BR> Is there a better way to recompute the new membership record??<BR> <BR> <BR> Thanks<BR> Kunal<BR> <BR> <BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CB7A0A.759A9434-- --===============1296815355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ magma mailing list [email protected] https://www.ietf.org/mailman/listinfo/magma --===============1296815355==--