Re: [MBONED] draft-ietf-mboned-64-multicast-address-format

[Stig Venaas <[e-mail]>]

On 8/14/2012 1:05 PM, Behcet Sarikaya wrote:
> On Tue, Aug 14, 2012 at 11:51 AM, Stig Venaas <[e-mail]> wrote:
>> On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
>>>
>>> On Tue, Aug 14, 2012 at 4:09 AM,  <[e-mail]> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I'm initiating this thread in the hope of understanding the
>>>> objections from the 6man WG and hopefully to make some progress for
>>>> this document.  To initiate the discussion, below are provided some
>>>> preliminary Q/A:
>>>>
>>>> What is the scope of this document?
>>>>      The document specifies an algorithmic translation of an IPv6
>>>>      multicast address to a corresponding IPv4 multicast address, and
>>>>      vice versa.  The document reserves two IPv6 multicast prefixes to
>>>>      be used for that purpose.
>>>>
>>>> What are these reserved prefixes?
>>>>      *  ff3x:0:8000::/96 for SSM
>>>>      *  ffxx:8000::/20 for ASM
>>>>
>>>> Does this document update IPv6 addressing architecture?
>>>>      No.
>>>>
>>>> Is there a unicast counterpart of this proposal?
>>>>      Yes, RFC6052.
>>>>
>>>> What is the problem to be solved?
>>>>      There are several use cases as detailed in [I-D.ietf-mboned-v4v6-
>>>>      mcast-ps].  In particular, the following use cases are of
>>>>      interest:
>>>>      1.  An IPv6-only receiver wants to receive multicast content from
>>>>          an IPv4-only source (6-4).
>>>>      2.  An IPv4 receiver wants to join a multicast group in IPv4
>>>>          domain via an IPv6-only network (4-6-4).
>>>>
>>>> Are there solutions for the unicast counterpart of these use cases?
>>>>      Yes; various solutions including:
>>>>      1.  6-4: RFC6146
>>>>      2.  4-6-4: RFC6333, RFC6346, ...
>>>
>>>
>>>
>>> I don't understand why RFC 6333 is included here.
>>> If you take a look at
>>> http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-01
>>> there is no need for this draft.
>>
>>
>> If I understand your draft correctly, it uses unicast for the
>> encapsulation, then there is no need for this.
>>
>> But e.g. draft-ietf-softwire-dslite-multicast-02 needs it. If you are
>> using multicast encapsulation (4 in 6), you need to know which group G
>> or (S,G) to join at the tunnel egress point. And at the ingress, you
>> need to interpret the IPv6 join you receive and extract the IPv4 address
>> to know which IPv4 group is requested. For the latter part you could
>> possibly encapsulate the joins, but I think that is not so good. Anyway,
>> you need it for the first part.
>>
>> Encapsulation is very similar to translation. The only real difference
>> I see, is that when you receive packets at the egress, you can just do
>> decap, you don't need to figure out what the addresses in the new header
>> should be.
>
> First of all as Mboned chair said, multicast can be tunneled, i.e.
> encapsulated. AMT is an example. DS-Lite tunnel as in
> draft-sarikaya-softwire-dslitemulticast-01 is another example.

Yes, and I'm trying to explain why this solution applies to
tunneling. draft-ietf-softwire-dslite-multicast-02 is one example.

> The point here is that draft-ietf-mboned-64-multicast-address-format
> describes part of translation multicast and it should be explained as
> such. Encapsulation or tunneling has nothing to do with it.

And I was trying to explain above why it is also part of encapsulation.

Stig

> Hope this clarifies my point and we don't keep coming back to this again.
>
> Regards,
>
> Behcet
>