Re: Question about proxy implemenation in RFC 4605
"Alvaro Fernandez" <[email protected]> Sat, 30 Oct 2010 19:36:20 +0200
| Newsgroups | gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0112047837== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7858.F6BF7B75" This is a multi-part message in MIME format. ------_=_NextPart_001_01CB7858.F6BF7B75 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 =20 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_01CB7858.F6BF7B75 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 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> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01CB7858.F6BF7B75-- --===============0112047837== 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 --===============0112047837==--