Subject: Re: [multrans] Updated Issues Presentation

From: Tom Taylor <[email-masked]>
Date: Fri, 1 Jul 2011 07:35:26 -0400

Let me counter-offer a view, that the problem statement text should be 
updated to make the roles of translation and tunneling clearer, rather 
than hiding it all under the "interworking" term.

Thinking more about the contents of slide 9, I realize that tunneling of 
multicast signalling between multicast routers will only make sense in 
special situations and is an issue of network design rather than a topic 
within the scope of multicast transition. So the second half of slide 9 
applies primarily to the transport of multicast content. The 
architecture document proposed as a work item could cover the use of 
encapsulation in general, and one of the applicability work items would 
be to describe the application of the architecture to DS-lite.

On 30/06/2011 3:14 AM, Jacni Qin wrote:
> Thanks for the updates,
>
> For page 9 Encapsulation, please check again my previous comments and
> proposed text.
> And I guess the issue currently listed applies not only to encapsulation
> case, but to the translation as well.
>
>
> Cheers,
> Jacni
>
> On Thu, Jun 30, 2011 at 11:39 AM, Tom Taylor<[email-masked]>  wrote:
>
>> Here's an update to our issues slides. We've tried to responsive to the
>> comments. Thanks to Joel, Dan, and Jacni.
>>
>> Tom Taylor
>> Cathy Zhou
>>
>> _______________________________________________
>> multrans mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/multrans
>>
>>
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 2 Jul 2011 20:13:22 +0000

Hi Tom,

Thanks for preparing the slide deck. I have a comment of the following
statement on P.9:

"IP-in-non-IP encapsulation: multicast routing must use the inner
header, which may need translation to make it usable."

This is not always true. Operator can manually build a multicast vpn and
route the traffic based on the outer label. However, this could take a lot
of effort and not automatic.

On P.11, the LHS diagram isn't really a dual-stack network.

Best regards,
Yiu

---

From: Tom Taylor <[email-masked]>
Date: Sat, 2 Jul 2011 16:55:02 -0400

Thanks for taking a look.

> of effort and not automatic.

[PTT] Is it worth qualifying the statement (other than during the oral 
presentation)? I will be updating to say that encapsulation applies only 
to content except in a transit network.
> On P.11, the LHS diagram isn't really a dual-stack network.

[PTT] It might be operating as one for unicast traffic. Should I say it 
is a dual-stack-capable network being operated as (e.g) ...?
                 ^^^^^^^
>
> Best regards,
> Yiu
>
>
> On 6/29/11 11:39 PM, "Tom Taylor"<[email-masked]>  wrote:
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 2 Jul 2011 20:58:42 +0000

Hi Tom,

>to content except in a transit network.

Perhaps, you can soften the tone to "may". I just tried to avoid people
challenging that statement.

>is a dual-stack-capable network being operated as (e.g) ...?

I tried to understand the purpose of that page. My understanding is
whether it is a dual-stack network or not, if we want to optimize the
network to only carry the content once, it would require some effort.

Cheers,
Yiu

---

From: Tom Taylor <[email-masked]>
Date: Sat, 2 Jul 2011 17:03:56 -0400

Below.

> challenging that statement.

[PTT] OK
> network to only carry the content once, it would require some effort.

[PTT] Yes.

---

From: Jacni Qin <[email-masked]>
Date: Mon, 4 Jul 2011 22:22:35 +0800

hi Tom,

On Fri, Jul 1, 2011 at 7:35 PM, Tom Taylor <[email-masked]> wrote:

> updated to make the roles of translation and tunneling clearer, rather than
> hiding it all under the "interworking" term.
>

Jacni>: It's not hiding. And I guess the translation and tunneling share the
same Interworking functions of signaling.

> within the scope of multicast transition.

Jacni>: Yes, it's an issue, and should be avoided, or as stated in the PS
I-D, "forwarding multicast traffic over unicast-only networks is out of the
scope..." ;-)

So the second half of slide 9 applies primarily to the transport of
> multicast content. The architecture document proposed as a work item could
> cover the use of encapsulation in general, and one of the applicability work
> items would be to describe the application of the architecture to DS-lite.

Jacni>: I'm afraid I can not agree. IMHO, the current PS I-D is fair enough
for the architectural or general discussions if you want. The scenarios,
requirements and issues of different use cases (e.g. Mesh, DS-Lite, ..) are
clear, and should be addressed individually, of course in the order of
priority.

Cheers,
Jacni

>>> ______________________________**_________________
>>> multrans mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/multrans<https://www.ietf.org/mailman/listinfo/multrans>
>>>
>>>
>>>
>>