Re: Question about proxy implemenation in RFC 4605

This is a multi-part message in MIME format.

--===============0104304652==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CB7AAC.8FA65AE3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB7AAC.8FA65AE3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Kunal

Just something else.

From your last e-mail:  " i.e the state that would exist if all the =
interfaces represented individual hosts on a single LAN"

I think this is not true. Host connected to a proxy are not the same =
that host connected to the same LAN. The difference is that each host is =
connected to the Proxy by a different downstream network interface and =
this makes the rules in the proxy easier that the state machine of the =
IGMPv3 router.=20

Regards

Alvaro


-----Mensaje original-----
De: Kunal Shah [mailto:[email protected]]
Enviado el: lun 01/11/2010 23:49
Para: Alvaro Fernandez
CC: [email protected]
Asunto: RE: [magma] Question about proxy implemenation in RFC 4605
=20
Hi Alvaro,

I dont think you have understood my question. The rules that you are =
suggesting from RFC 3376, are the rules used for aggregating the =
information on an interface with multiple sockets. What I am asking is =
what rules should be followed on a proxy device in order to aggregate =
the state of all the interfaces, after the state of one of the =
interfaces has changed. This is because, on a device doing proxy, the =
state that is created is an aggregate of the state of the interfaces; =
i.e the state that would exist if all the interfaces represented =
individual hosts on a single LAN. Now from RFC 3376, if a host goes away =
on an interface, there are certain rules that the router must follow =
regarding queries that need to be sent in order to arrive to the new =
state on that interface. My concern is, on a proxy device, if the same =
rules are followed, queries will need to be sent out on all the =
interfaces in order to make sure that the new state reflects the state =
of all the interfaces. This might not be efficient/scalable if the proxy =
device has interfaces in the order of hundreds.

Or I have not understood the RFC 4605 correctly...

Kunal

________________________________
From: Alvaro Fernandez [mailto:[email protected]]
Sent: Monday, November 01, 2010 2:19 PM
To: Kunal Shah
Cc: [email protected]
Subject: RE: [magma] Question about proxy implemenation in RFC 4605


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

-----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

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_01CB7AAC.8FA65AE3
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>
Just something else.<BR>
<BR>
From your last e-mail:&nbsp; &quot; i.e the state that would exist if =
all the interfaces represented individual hosts on a single =
LAN&quot;<BR>
<BR>
I think this is not true. Host connected to a proxy are not the same =
that host connected to the same LAN. The difference is that each host is =
connected to the Proxy by a different downstream network interface and =
this makes the rules in the proxy easier that the state machine of the =
IGMPv3 router.<BR>
<BR>
Regards<BR>
<BR>
Alvaro<BR>
<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 23:49<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>
I dont think you have understood my question. The rules that you are =
suggesting from RFC 3376, are the rules used for aggregating the =
information on an interface with multiple sockets. What I am asking is =
what rules should be followed on a proxy device in order to aggregate =
the state of all the interfaces, after the state of one of the =
interfaces has changed. This is because, on a device doing proxy, the =
state that is created is an aggregate of the state of the interfaces; =
i.e the state that would exist if all the interfaces represented =
individual hosts on a single LAN. Now from RFC 3376, if a host goes away =
on an interface, there are certain rules that the router must follow =
regarding queries that need to be sent in order to arrive to the new =
state on that interface. My concern is, on a proxy device, if the same =
rules are followed, queries will need to be sent out on all the =
interfaces in order to make sure that the new state reflects the state =
of all the interfaces. This might not be efficient/scalable if the proxy =
device has interfaces in the order of hundreds.<BR>
<BR>
Or I have not understood the RFC 4605 correctly...<BR>
<BR>
Kunal<BR>
<BR>
________________________________<BR>
From: Alvaro Fernandez [<A =
HREF=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>=

Sent: Monday, November 01, 2010 2:19 PM<BR>
To: Kunal Shah<BR>
Cc: [email protected]<BR>
Subject: RE: [magma] Question about proxy implemenation in RFC 4605<BR>
<BR>
<BR>
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&nbsp; 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 -&gt; I(S1)<BR>
Interface 2 has host reporting Exclude S2 -&gt; E(0,S2)<BR>
Interface 3 has host reporting Exclude nothing -&gt; 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.&nbsp; 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>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CB7AAC.8FA65AE3--

--===============0104304652==
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

--===============0104304652==--