RE: AW: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt

> Hi Everybody,
> 
> > Hi all.
> > If you have two sources from two different inside interfaces 
> > sending multicast data to the outside interface and both 
> > sources use the same multicast address (G1) then outside 
> > routers, using for example PIM-SM, will consider that there 
> > is only one multicast channel and will send all the traffic. 
> > Also hosts receiving all the traffic need to separate it.
>
> Right. This is from my point of view not the solution you want.
> The reason for SSM is to have different senders (source) using
> the same group and to be able to route based on (S,G) information.
> 
> > One solution is to reserve an IP address range inside SSM range 
> > ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change, 
> > not only the source address of the sender, but also the multicast 
> > address of the sender to be unique in this range. In this way 
> > outside routers ( and receivers ) will consider traffic as coming 
> > from different channels (IP public ,G2) and ( IP public, G3) with 
> > G2 and G3 inside the said range.
>
> The main problem is how to signal either the (S,G) channel or the 
> multicast group if this information is changed by a NAPT device.
> 
> E.g. in a typical IPTV scenario the signalling of the group or
> channel information is done out-bband using servers providing
> information about the IPTV channels. Clients are receiving this 
> information from the server (http/xml) to join the appropriate 
> IPTV channels.
> 
> If a sender (S1) sends multicast traffic to a group (G1) the receiver
> joins (S1,G1) due to the information it got from the server. If the
> NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not
> going to receive any traffic.
> 
> I'm not sure if this problem can be solved without making to many
> assumptions about the applications deploying IP-Multicast.

I agree, and I'll leave such a recommendation out of the -07
revision of this document.  I expect to have -07 ready next week.

-d


>   Regards
> 
>      Nic
> 
> ________________________________
> 
> 	De: Manfredi, Albert E [mailto:[email protected]]
> 	Enviado el: mar 05/06/2007 16:02
> 	Para: [email protected]; [email protected]; [email protected]
> 	Asunto: [magma] RE: [MBONED] FW: WGLC:
> draft-ietf-behave-multicast-06.txt
> 	
> 	
> 
> 	> -----Original Message-----
> 	> From: Dan Wing [mailto:[email protected]]
> 	> Sent: Monday, June 04, 2007 7:38 PM
> 	> To: [email protected]; [email protected]
> 	> Cc: 'Behave WG'
> 	> Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
> 	>
> 	> The BEHAVE working group concluded its WGLC of
> 	> draft-ietf-behave-multicast-06 with no comments received.  I
> 	> would like
> 	> MBONED and MAGMA to please take a look at this draft prior to
> 	> its submission
> 	> to IESG.
> 	>
> 	> Please send replies to [email protected].  Thanks!
> 	
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas
> t-06.txt:
> 	
> 	What if the NAPT or NAT device just passed IGMP queries and
> reports
> 	through, changing only the source address of the reports, and
> let the
> 	multicast router outside do all the hard work? I'm wondering
> whether the
> 	IGMP aggregation function is mandatory in NAT/NATP.
> 	
> 	Bert
> 	
> 	_______________________________________________
> 	magma mailing list
> 	[email protected]
> 	https://www1.ietf.org/mailman/listinfo/magma
> 	
> 
> 
> 
> _______________________________________________
> Behave mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/behave