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

[Behcet Sarikaya <[e-mail]>]

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.

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.

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

Regards,

Behcet