Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

Hi Tina,

Thanks for the comments. With IPv6 source based scenarios, per my understanding, current proposals (embedded bit or flag in PIM/MLD) may not be sufficient (atleast in current state) to build the tree. But as Stig mentioned, we could use some kind of marking (or that sort) in join attribute for IPv4 groups too. 

I agree with your comment that both idea got its own pros and cons. So we would like to put it on table to discuss and understand others view on the same :)

Thanks again for your comments.

Thanks,
Nagendra

-----Original Message-----
From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Tuesday, July 03, 2012 12:04 AM
To: Nagendra Kumar (naikumar); Manfredi, Albert E; Stig Venaas
Cc: mboned@ietf.org
Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-address-format?

Hi Nagendra,
Thank you. I agree with you that the most apt solution for IPv4 transit would be tunneling, AMT or MVPN. As that scenario is not to be considered, do you think complicating the addressing scheme with additional attributes is worth the effort put in implementing it? Though the solution is thoughtful and a good one, I am seeing from the implementation point of view.

Tina

> -----Original Message-----
> From: Nagendra Kumar (naikumar) [mailto:naikumar@cisco.com]
> Sent: Sunday, July 01, 2012 1:58 AM
> To: Tina TSOU; Manfredi, Albert E; Stig Venaas
> Cc: mboned@ietf.org
> Subject: RE: [MBONED] An alternative to 
> draft-ietf-mboned-64-multicast- address-format?
> 
> Hi Tina,
> 
> Thanks for your thoughts. For 6-4-6 scenarios, I think it may not 
> require to signal if or not v4 address is embedded as IPv4 cloud will 
> be transit here. I guess Tunneling, AMT or MVPN kind of solution might be apt here.
> 
> Regarding the attribute in IPv4 only network, even if there is a 
> requirement to transparently transfer attribute via v4 cloud, per my 
> understanding, it still can be done by setting the F bit. So just the 
> ingress and egress devices are required to understand the content of 
> attribute.
> 
> Regards,
> Nagendra
> 
> -----Original Message-----
> From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On 
> Behalf Of Tina TSOU
> Sent: Saturday, June 30, 2012 7:11 AM
> To: Manfredi, Albert E; Stig Venaas
> Cc: mboned@ietf.org
> Subject: Re: [MBONED] An alternative to 
> draft-ietf-mboned-64-multicast- address-format?
> 
> The fixed 96 bits and then 32 bits of the IPv4 address is a simpler 
> and better approach according to me, as described in
> http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-form
> at- 02. However, this 
> http://tools.ietf.org/html/draft-kumar-mboned-64mcast-
> embedded-address-00 document has its advantages of 6-4-6-4 scenario 
> which is missing in the alternative document. The only point I would 
> like to stress upon is if it covers the scenario of 6-4-6, as IPv6 
> multicast address expressed in terms of IPv4 is something I didn't 
> find in the document. I am only concerned about the validity of the 
> attributes in an
> IPv4 only multicast network. Would tunnels be used to route the IPv6 
> packets with the end routers being dual stack?
> 
> Tina
> 
> 
> > -----Original Message-----
> > From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On 
> > Behalf Of Manfredi, Albert E
> > Sent: Friday, June 29, 2012 12:35 PM
> > To: Stig Venaas
> > Cc: mboned@ietf.org
> > Subject: Re: [MBONED] An alternative to
> > draft-ietf-mboned-64-multicast- address-format?
> >
> > > -----Original Message-----
> >
> >
> > > For multicast things are kind of reversed. From say PIM 
> > > perspective, you can start out with someone joining an IPv6 group 
> > > where the last
> > > 32 bits form an IPv4 group address. When this IPv6 join reaches 
> > > say a device on the edge of the IPv4 network, it can based on 
> > > configuration (or hard-coded if a standardized prefix), or a flag 
> > > in the group address, or a join attribute (these are the solutions 
> > > I think we have on the table), know that it should extract those 
> > > 32 bits, and join the IPv4 source. When it receives IPv4 data 
> > > packets, it can based on its PIM state know what IPv6 address to 
> > > translate them to.
> > >
> > > There are other use-cases, this is maybe the easiest one.
> >
> > This seems similar yo what I had described, except that the 96-bit 
> > prefix is configurable (presumably there will be an OOB mechanism to 
> > indicate what the prefix should be), AND it also seems to depend on PIM.
> >
> > What about cases in which PIM isn't used? For example, where proxy 
> > IGMP or proxy MLD is used, to make multicasts traversing a network 
> > available to an egress router? Or are we saying that it's okay to 
> > have incompatible solutions depending on each use case?
> >
> > Bert
> >
> > _______________________________________________
> > MBONED mailing list
> > MBONED@ietf.org
> > https://www.ietf.org/mailman/listinfo/mboned
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
_______________________________________________
MBONED mailing list
MBONED@ietf.org
https://www.ietf.org/mailman/listinfo/mboned