Subject: Re: [MBONED] WGLC for draft-ietf-mboned-v4v6-mcast-ps

From: Brian Haberman <[email-masked]>
Date: Wed, 03 Apr 2013 20:46:23 -0400

Hi all,
      I was asked to review this draft and I have a few concerns with 
this draft...

1. I agree with most of the issues raised by Stig.  Yes, many of them 
are nits, but they can cause non-deterministic interpretations of what 
should be done or what the actual problems may be.

2. I am concerned that some of the service requirements are conflating 
application-level requirements with network-level requirements.  This 
document needs to be very careful to identify which layer needs to be 
concerned with which requirements.

3. Does *anyone* in the working group expect to have solutions for every 
use case described in section 3?  Some of them should never be 
considered unless an operator says that is exactly how they want to 
build their network.

4. As a problem statement document, I think this draft goes too far in 
specifying *how* each of the scenarios is addressed.  A problem 
statement should not specify any type of "Adaptation Function", that is 
part of a solution.  It should stick to describing the problem.

Regards,
Brian

On 3/21/13 9:45 AM, Leonard Giuliano wrote:
>
> We would like to begin working group last call for
> draft-ietf-mboned-v4v6-mcast-ps.  Please include the following in your
> consideration:
>
> -Is the document of a sufficient quality for publication?
> -Are all of the use cases and components in the draft reflective of real
> world problems that you think MBONED should attempt to address?
>
> Please post any and all comments supporting/opposing the draft to the
> list by Apr 19.  Most recent version of the draft can be found here:
>
> http://www.ietf.org/id/draft-ietf-mboned-v4v6-mcast-ps-02.txt
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Apr 2013 10:32:13 -0400

I don't think I replied to this yet. I think the draft should go 
forward, assuming Stig's comments are resolved satisfactorily.

---

From: Leonard Giuliano <[email-masked]>
Date: Fri, 19 Apr 2013 10:29:45 -0700

<Co-chair hat off, speaking as an individual>

Overall, I have a great deal of skepticism of the utility, not only of 
this draft, but of the MULTRANS work in general.  My concern is that this 
work is of no interest to production network deployments and that the work 
will generate nothing more than a flood of documents in the WG that don't 
really solve any real world problems.  I base this skepticism on the 
following:

1) No interest outside of this WG:

Personal suspicions aside, when brought up in RIPE, according to the 
meeting report, "The response from the room indicated that this is not 
something people need."  The video was even more revealing and speaks for 
itself: 
https://ripe65.ripe.net/archives/video/182/

When brought up at NANOG, there was again no response: 
http://marc.info/?l=nanog&m=134445649807595&w=4

2) Current deployment status of the technologies being transitioned 
to/from:

Using certain metrics in the best light, IPv4 multicast today encompasses 
1-3% of the global Internet.  Global IPv6 unicast penetration is roughly 
similiar.  The union of these 2, IPv6 multicast, is practically 
nonexistent on the Internet.  Are folks really clamoring to transition 
traffic from the nearly nonexistent (v4 mcast) to the practically 
nonexistent (v6 mcast)?

3) The scope of the solutions

There is apparent widespread agreement that the scope of the problem and 
solutions should be limited to intradomain.  Within domains, there is 
significant flexibility to solve these problems (or avoid them in the 
first place).  One of the apparent motivators for this work is that 
v6-only set-top boxes will want to receive v4 multicast.  v6-only STBs??  
For years now, I've been told that STBs can't possibly be expected to add 
advanced features like IGMPv3 (RFC 3376 came in 2002), so SSM deployment 
has been limited (or hacks like ASM->SSM mapping have been implemented to 
circumvent).  But now v6-only STBs?  Can they at least do dual stack and 
join the v4 mcast streams that apparently cannot possibly be replaced with 
v6 multicast?  If v4 exhaustion is the problem, just give these dual stack 
STBs an RFC 1918 address- it is after all, intradomain, and the v4 is only 
being used to receive these walled-garden v4 mcast streams.
 
4) Just use NAT

<willing suspension of disbelief>

OK, so for whatever reason, SPs must deploy v6-only STBs which must find a 
way to receive v4 mcast streams within a walled-garden that the SP totally 
controls, (and, of course, sending v4 streams to the v4-only receivers and 
v6 streams to the v6-only receivers is out of the question).  Or better 
yet, v4-only STBs must find a way to get all that v6 mcast content.  Why 
not simply throw NAT at this problem and be done?  The solution could be 
characterized in a paragraph or 2.  Do we really need a 19 page 
requirements doc, or the 6 other multrans docs we've seen so far?  Or the 
flood of new drafts that seem likely follow?

</willing suspension of disbelief>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Apr 2013 22:52:33 -0400

I cannot account for the results at RIPE and NANOG, except to say that 
the right people may not have been present. At the IETF, four different 
operators expressed concrete support for aspects of this work. I've 
learned to duck if an operator is discussing requirements, so if an 
operator does so, I will discreetly withdraw from the conversation.

As far as your remarks on IPv6-only receivers are concerned: we agree 
that the simplest way to migrate IPTV to IPv6 is to start by upgrading 
the receivers to dual stack. We even wrote a draft saying so:
draft-tsou-v6ops-multicast-01.txt. But the simplest migration plan may 
interfere with a more general plan for rolling out IPv6, or may require 
capital investment that the operator can't afford for the moment.

Tom Taylor

---

From: Brian Haberman <[email-masked]>
Date: Wed, 24 Apr 2013 12:30:41 -0400

> operator does so, I will discreetly withdraw from the conversation.

I had conversations about v4/v6 multicast transition with network 
architects at two large service providers recently.  Unfortunately, they 
did not want their employers named (due to unannounced plans), but were 
willing to talk about how *they* plan to migrate their multicast clients 
to IPv6.

Their feedback to me is that their cost analyses indicated that it was 
much cheaper to move to dual-stack for multicast services than to 
introduce any kind of translation service.  These costs included opex 
and capex.  When I pointed them to the referenced document, one said it 
had no value to him and the other called it "a theoretical exercise".

In a nutshell, their response to this problem mirrored Lenny's views on 
the subject.

> capital investment that the operator can't afford for the moment.

Could you elaborate on how making multicast receivers dual-stack would 
interfere with "a more general plan for rolling out IPv6"?

Regards,
Brian

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Apr 2013 13:05:34 -0400

> On 4/22/13 10:52 PM, Tom Taylor wrote:
...
> interfere with "a more general plan for rolling out IPv6"?
...
Yeah, that part was a bit unthinking. The capital cost argument still 
holds, but obviously from your conversations the tradeoffs depend on the 
operator.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 24 Apr 2013 13:13:20 -0400

Le 2013-04-24 à 12:30, Brian Haberman <[email-masked]> a écrit :

> I had conversations about v4/v6 multicast transition with network architects at two large service providers recently.  Unfortunately, they did not want their employers named (due to unannounced plans), but were willing to talk about how *they* plan to migrate their multicast clients to IPv6.
> 
> Their feedback to me is that their cost analyses indicated that it was much cheaper to move to dual-stack for multicast services than to introduce any kind of translation service.  These costs included opex and capex.  When I pointed them to the referenced document, one said it had no value to him and the other called it "a theoretical exercise".
> 
> In a nutshell, their response to this problem mirrored Lenny's views on the subject.

I read in the draft three operators as co-authors: Orange, Comcast, China Telecom

So my reading of the situation is that some operators are interested in this, some don't.  To me, that looks pretty similar to a lot of IETF technologies: i.e. some operators prefer IS-IS, others OSPF.

I have a hard time thinking that for 3 major operators, from 3 different continents, the IETF is rejecting this work.  I thought we wanted to listen to operators?

Marc.

> Could you elaborate on how making multicast receivers dual-stack would interfere with "a more general plan for rolling out IPv6"?
> 
> Regards,
> Brian
> 
>> Tom Taylor
>>