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

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Aug 2012 15:05:01 -0500

On Tue, Aug 14, 2012 at 11:51 AM, Stig Venaas <[email-masked]> wrote:
> On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
>>
>> On Tue, Aug 14, 2012 at 4:09 AM,  <[email-masked]> 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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 14 Aug 2012 13:46:48 -0700

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

> 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

---

From: <[email-masked]>
Date: Thu, 16 Aug 2012 07:59:47 +0200

Re-,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] 
>De la part de Behcet Sarikaya
>Envoyé : mardi 14 août 2012 22:05
>À : Stig Venaas
>Cc : MBONED WG
>Objet : Re: [MBONED] draft-ietf-mboned-64-multicast-address-format
>

Med: this is a unicast-based solution between the CPE and the aftr. You have presented this draft is softwire and the group preferred a solution making use of native multicast capabilities to deliver IPv4 multicast over an IPv6 network.

>such. Encapsulation or tunneling has nothing to do with it.

Med: draft-ietf-mboned-64-multicast-address-format specifies address translation algorithm but it does not assumption on the deployment context. As such, this address translation can be used in scenarios where multicast data is encapsulated or translated. Specific solution design is out of scope of this document.

>_______________________________________________
>MBONED mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 16 Aug 2012 16:47:55 -0500

> tunneling. draft-ietf-softwire-dslite-multicast-02 is one example.

Let that draft explain it not the address format draft.

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

That is hopeless.

Behcet