Re: Question about proxy implemenation in RFC 4605

--===============0399099468==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E73B63F6EUSAACMS0703e_"

--_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E73B63F6EUSAACMS0703e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Alvaro,

I dont think you have understood my question. The rules that you are sugges=
ting from RFC 3376, are the rules used for aggregating the information on a=
n 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 inte=
rfaces, after the state of one of the interfaces has changed. This is becau=
se, on a device doing proxy, the state that is created is an aggregate of t=
he state of the interfaces; i.e the state that would exist if all the inter=
faces 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 mu=
st 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 inte=
rfaces. This might not be efficient/scalable if the proxy device has interf=
aces 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 IPM=
ulticastListen when there are different sockets using the same multicast gr=
oup.

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 m=
ean, 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 netwo=
rk interface should behave like a router, so the solution is in the state m=
achine 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, becaus=
e of which the subscription on interface 3 would expire and there wont be a=
ny IGMPv3 state on interface 3.  How would the new membership record for PR=
OXY 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





--_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E73B63F6EUSAACMS0703e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [magma] Question about proxy implemenation in RFC 46=
05</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"=
>
<META content=3D"MSHTML 6.00.6001.18527" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Hi Alvaro,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>I dont think you have understood my question.&nbsp=
;The=20
rules that&nbsp;you are suggesting from RFC 3376, are the rules used for=20
aggregating the information on&nbsp;an interface with multiple sockets. Wha=
t I=20
am asking is what rules should be followed on a proxy device in order to=20
aggregate the state of all the interfaces, after the state of one of the=20
interfaces has changed. </FONT></SPAN><SPAN class=3D534413422-01112010><FON=
T=20
face=3DArial color=3D#0000ff size=3D2>This is because, on a device doing&nb=
sp;proxy,=20
the state that is created is an aggregate of the state of the interfaces;=20
i.e&nbsp;the state that would exist&nbsp;if all the interfaces represented=
=20
individual hosts on a single LAN. Now from RFC 3376, if a host goes away on=
 an=20
interface, there are certain rules that the router must follow regarding qu=
eries=20
that need to be&nbsp;sent in order&nbsp;to arrive to the new state on that=
=20
interface. My&nbsp;concern is, on a proxy device, if the same rules are=20
followed, queries will need to be sent out on all the interfaces in order t=
o=20
make sure that the new state reflects the state of all the interfaces. This=
=20
might not be efficient/scalable if the proxy device has interfaces in the o=
rder=20
of hundreds. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Or I have not understood the RFC 4605=20
correctly...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Kunal</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D534413422-01112010><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DTahoma size=3D2><B>From:</B> Alvar=
o Fernandez=20
[mailto:[email protected]] <BR><B>Sent:</B> Monday, November 01, 2010 2:=
19=20
PM<BR><B>To:</B> Kunal Shah<BR><B>Cc:</B> [email protected]<BR><B>Subject:</B>=
 RE:=20
[magma] Question about proxy implemenation in RFC 4605<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=3D2>Hi Kunai,<BR><BR>I thing my previous Mail was wrong. I wa=
s=20
thinking in once interface with m=FAltiple host and this is not your=20
question.<BR><BR>The proxy should apply same rules&nbsp; explained inRFC337=
6 in=20
the funci=F3n IPMulticastListen when there are different sockets using the =
same=20
multicast group.<BR><BR>I think there is no need for queries, just apply th=
ese=20
rules.<BR><BR>Hope this will help<BR><BR>=C1lvaro<BR><BR>-----Mensaje=20
original-----<BR>De: Kunal Shah [<A=20
href=3D"mailto:[email protected]">mailto:[email protected]</A>]=
<BR>Enviado=20
el: lun 01/11/2010 19:30<BR>Para: Alvaro Fernandez<BR>CC:=20
[email protected]<BR>Asunto: RE: [magma] Question about proxy implemenation in=
 RFC=20
4605<BR><BR>Hi Alvaro,<BR><BR>For a router to determine that there are no=20
interested hosts on the LAN, it does send out group specific or source-grou=
p=20
specific queries. Does this mean, that the proxy device should send out=20
source-group specific queries on other interfaces when deemed required?? Ho=
w=20
will this scale if there are a large number of=20
interfaces??<BR><BR>Kunal<BR><BR>________________________________<BR>From:=
=20
Alvaro Fernandez [<A=20
href=3D"mailto:[email protected]">mailto:[email protected]</A>]<BR>Se=
nt:=20
Saturday, October 30, 2010 10:36 AM<BR>To: Kunal Shah<BR>Cc:=20
[email protected]<BR>Subject: RE: [magma] Question about proxy implemenation i=
n RFC=20
4605<BR><BR><BR>Hi Kunal<BR><BR>I read it years ago but I think RFC 4605=20
explains that the downstream network interface should behave like a router,=
 so=20
the solution is in the state machine explained in RFC3376 for the IGMPv3=20
router<BR><BR>=C1lvaro<BR><BR><BR>-----Mensaje original-----<BR>De:=20
[email protected] en nombre de Kunal Shah<BR>Enviado el: s=E1b 30/10/2=
010=20
2:46<BR>Para: [email protected]<BR>Asunto: [magma] Question about proxy=20
implemenation in RFC 4605<BR><BR>Hi all,<BR><BR>According to RFC 4605, a ro=
uter=20
creates a membership database after merging the subscriptions on individual=
=20
interfaces. Lets say that 3 IGMPv3 capable interfaces are as=20
follows:<BR><BR>Interface 1 has host reporting Include S1 -&gt;=20
I(S1)<BR>Interface 2 has host reporting Exclude S2 -&gt; E(0,S2)<BR>Interfa=
ce 3=20
has host reporting Exclude nothing -&gt; E(0,0)<BR><BR>For a device doing I=
GMPv3=20
proxy, the final membership record for group G is (G, EXCLUDE, NULL). Now l=
ets=20
say the host on interface 3 goes away, because of which the subscription on=
=20
interface 3 would expire and there wont be any IGMPv3 state on interface=20
3.&nbsp; How would the new membership record for PROXY be calculated?? The =
RFC=20
does not suggest any way to do this. Would IGMP process have to go through =
each=20
interface again and then recompute the new membership record?? This would b=
e=20
very inefficient especially if there are multiple interfaces.<BR>Is there a=
=20
better way to recompute the new membership=20
record??<BR><BR><BR>Thanks<BR>Kunal<BR><BR><BR><BR><BR></FONT></P></BODY></=
HTML>

--_000_4FD1E7CD248BF84F86BD4814EDDDBCC150E73B63F6EUSAACMS0703e_--

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

--===============0399099468==--