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

[Jacni Qin <[e-mail]>]

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-**
>> 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>
>>>
>>>
>>>
>>