Re: [multrans] Issues charts for presentation at the BoF

[Jacni Qin <[e-mail]>]

Re-,

What I proposed is about how to deal with the encapsulation case, the key
point is to guarantee the efficiency of multicast forwarding.


Cheers,
Jacni

On Thu, Jun 30, 2011 at 3:05 AM, Tom Taylor <[e-mail]> wrote:

> Thanks for the suggestion, but interworking is already dealt with on slide
> 6. I think chart 9 deals with a separate issue.
>
>
> On 28/06/2011 10:42 PM, Jacni Qin wrote:
>
>> hi Tom,
>>
>> On Tue, Jun 28, 2011 at 8:53 PM, Tom Taylor<[e-mail]>
>>  wrote:
>>
>>
>>>  Page 9:
>>>> Jacni>: I do agree with that the original design of DS-Lite or 6rd
>>>> (unicast-based tunnel)
>>>> should not be used for multicast delivery, but that can NOT lead to the
>>>> conclusion stated in the second bullet ("Possible to use encapsulation
>>>> in
>>>> the form of a softwire mesh between multicast routers.").
>>>> Mesh is a different use case, the mesh approaches do not apply to
>>>> DS-Lite
>>>> or
>>>> 6rd cases either.
>>>>
>>>>
>>>
>>> [PTT] I can drop the term "softwire mesh" and say simply that it is
>>> possible to use tunnels between the multicast routers, if you want. But
>>> isn't a mesh required to support the routing of the PIM signalling? I
>>> thought I was using the term in the same sense as
>>> draft-xu-softwire-mesh-**multicast-01.
>>>
>>>
>>>  Jacni>: How about this for Page 9 ?
>>
>> Encapsulation
>>
>> Issue: For different use cases (e.g. DS-Lite, 6rd or Mesh), unicast
>> based encapsulation does not apply to multicast.
>>
>> Possible to form corresponding MDT within the underneath network by
>> implementing interworking function of signalling.
>> ● to guarantee the efficiency of multicast traffic forwarding.
>>
>>
>>
>>
>>>
>>>> Page 10:
>>>> Jacni>: The discussions about dual-stack network are a little confusing.
>>>> The
>>>> network may be dual-stack enabled from the device connected to headends,
>>>> to
>>>> the IGMP/MLD Querier.
>>>> Or the network may be partially dual-stack enabled. The latter one is
>>>> "native transport + translation", and can be simplified as a translation
>>>> case.
>>>> Please refer to the -01 of the PS draft, maybe some text in the Section
>>>> 3.3
>>>> can be reused:
>>>> http://tools.ietf.org/html/****draft-jaclee-behave-v4v6-**<http://tools.ietf.org/html/**draft-jaclee-behave-v4v6-**>
>>>> mcast-ps-01#page-8<http://**tools.ietf.org/html/draft-**
>>>> jaclee-behave-v4v6-mcast-ps-**01#page-8<http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-01#page-8>
>>>> >
>>>>
>>>>
>>>>  [PTT] Page 10 deals with the specific case of a single dual stack
>>>> network
>>>>
>>> between the sources and the receivers. I actually have mixed versions in
>>> mind at both ends, although I know that IPv6 sources have lower priority.
>>> So
>>> the intention is to indicate some strategies for network operations under
>>> those particular assumptions.
>>>
>>> Jacni>: Yes, the IPv6 sources have lower priority, better to state that.
>>>
>>
>>
>>  I think you are saying that this is not the use case that you are
>>> pointing
>>> at in section 3.3 of the problem statement. I did not intend it to be so.
>>> What I should do is expand this page to two charts, giving the
>>> assumptions I
>>> just stated and adding the diagrams Dan suggested.
>>>
>>
>>
>> Jacni>: Ok, I can wait for your updates.
>>
>>
>> Cheers,
>> Jacni
>>
>>
>>>
>>>  Cheers,
>>>> Jacni
>>>>
>>>> On Tue, Jun 28, 2011 at 4:13 AM, Tom Taylor<[e-mail]>
>>>>  wrote:
>>>>
>>>>  Attached are the charts I propose should be presented on the "issues"
>>>>
>>>>> topic
>>>>> at the MULTRANS BoF. Comments in advance are welcome.
>>>>>
>>>>> Tom Taylor
>>>>>
>>>>> ______________________________****_________________
>>>>> multrans mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/****listinfo/multrans<https://www.ietf.org/mailman/**listinfo/multrans>
>>>>> <https://**www.ietf.org/mailman/listinfo/**multrans<https://www.ietf.org/mailman/listinfo/multrans>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>