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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] 
>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
>
>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.

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.

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

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.


>Hope this clarifies my point and we don't keep coming back to 
>this again.
>
>Regards,
>
>Behcet
>_______________________________________________
>MBONED mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mboned
>