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

From: Ronald Bonica <[email-masked]>
Date: Mon, 2 Jul 2012 10:27:27 -0400

Tina,

We should be remember two things wrt address formats:

- the MLTRANS problem will be with us only for a short time (until walled-garden IPTV providers upgrade to IPv6)
- changes that we make to the IPv6 addressing scheme will be with us forever

So, in the interest of keeping the IPv6 addressing scheme simple, we should try our best to limit the number of uses cases that we support and make the smallest possible change to the IPv6 addressing scheme. It doesn't make sense to complicate the IPv6 addressing scheme in order to support a use-case that will rarely or never be deployed.

                                       Ron
                                       /speaking as AD

> Date: Sat, 30 Jun 2012 01:41:22 +0000
> From: Tina TSOU <[email-masked]>
> To: "Manfredi, Albert E" <[email-masked]>, Stig Venaas
> 	<[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 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-
> format-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
> 
> 
**********

---

From: Tina TSOU <[email-masked]>
Date: Mon, 2 Jul 2012 16:25:13 +0000

Dear Ron,
They are simply comments on a new draft, nothing more than this. Sorry for making u thinking about Multrans related to these comments.

The call for 
http://datatracker.ietf.org/doc/draft-tsou-mboned-multrans-addr-acquisition/
has ended in May 29th.

It is July 2nd. 
Can the chairs say what the result of this call is?

Tina

On Jul 2, 2012, at 7:28 AM, "Ronald Bonica" <[email-masked]> wrote:

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Tina TSOU <[email-masked]>
Date: Mon, 2 Jul 2012 18:47:29 +0000

Dear Ron,
I agree with you that if the addressing scheme is kept simple, it is definitely better. However, since the Internet at present is more IPv4 rather than IPv6, should we consider keeping more IPv4 only transit networks in mind? On the other hand, if IPv6 addressing scheme supports more IPv4 only networks, according to me, people will be more reluctant to deploy IPv6 in their IPv4 only network. So, for deployment and adoption of IPv6, the use cases should be limited, right? I look forward hearing from you.

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ronald Bonica
> Sent: Monday, July 02, 2012 7:27 AM
> To: [email-masked]
> Subject: Re: [MBONED] An alternative to draft-ietf-mboned-64-multicast-
> address-format?
> 
> Tina,
> 
> So, in the interest of keeping the IPv6 addressing scheme simple, we
> should try our best to limit the number of uses cases that we support and
> make the smallest possible change to the IPv6 addressing scheme. It
> doesn't make sense to complicate the IPv6 addressing scheme in order to
> support a use-case that will rarely or never be deployed.
> 
>                                        Ron
>                                        /speaking as AD
> 
>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 2 Jul 2012 15:27:58 -0400

Tina (et al),

First, please accept my apologies for the rather confused email that I sent this morning. For the last few days, we have been without electricity in Northern Virginia, recovering from a severe storm. I have only caught up with this email thread in the last hour.

That said, I would like to restate a few architectural principles. The MLTRANS problem will only be with us for a short time (until walled-garden IPTV operators have converted to IPv6). Therefore, we want to minimize our investment in MLTRANS.

In my mind, the best way to do this is to solve only for use-cases that will see significant deployment. One or two deployments isn't enough to justify a solution. Beyond that, we want to limit the scope of our solutions. If we can avoid changing the IPv6 addressing scheme, that would be a win. Also, restricting our solution to a few optional TLVs in routing and signaling protocols would also be a win.

                                                  Ron

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Monday, July 02, 2012 2:47 PM
> To: Ronald Bonica; [email-masked]
> Subject: RE: [MBONED] An alternative to draft-ietf-mboned-64-multicast-
> address-format?
> 
> Dear Ron,
> I agree with you that if the addressing scheme is kept simple, it is
> definitely better. However, since the Internet at present is more IPv4
> rather than IPv6, should we consider keeping more IPv4 only transit
> networks in mind? On the other hand, if IPv6 addressing scheme supports
> more IPv4 only networks, according to me, people will be more reluctant
> to deploy IPv6 in their IPv4 only network. So, for deployment and
> adoption of IPv6, the use cases should be limited, right? I look
> forward hearing from you.
> 
> Tina
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Ronald Bonica
> > draft-ietf-mboned-64-multicast- address-format?
> >
> > Tina,
> >
> > - the MLTRANS problem will be with us only for a short time (until
> > walled- garden IPTV providers upgrade to IPv6)
> > should try our best to limit the number of uses cases that we support
> > and make the smallest possible change to the IPv6 addressing scheme.
> > It doesn't make sense to complicate the IPv6 addressing scheme in
> > order to support a use-case that will rarely or never be deployed.
> >
> >                                        Ron
> >                                        /speaking as AD
> >
> >
> > > The fixed 96 bits and then 32 bits of the IPv4 address is a simpler
> > > and better approach according to me, as described in
> > > format-02. However, this
> > > http://tools.ietf.org/html/draft-kumar-mboned-
> > > 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
> > >
> > >
> > **********