Re: [multimob] Comments on draft-krishnan-multimob-pmip6basicmcast-solution-00

[Stig Venaas <[e-mail]>]

Behcet Sarikaya wrote:
> Hi Luis,
> 
> <with co-author hat on>
> 
> Thanks for providing comments on this and other drafts.
> See below:
> 
> 
> 
> ----- Original Message ----
>> From: Luis M. Contreras <[e-mail]>
>> To: [e-mail]
>> Sent: Mon, October 5, 2009 4:15:11 PM
>> Subject: [multimob] Comments on draft-krishnan-multimob-pmip6basicmcast-solution-00
>>
>> Dear all,
>>
>> I have some doubts/comments on 
>> draft-krishnan-multimob-pmip6basicmcast-solution-00, specifically:
>>
>> 1/ LMA will receive the membership report messages from the MNs with source 
>> address the MN's link-local address. Nevertheless, the MN's link-local addresses 
>> are not part of the binding cache as defined in RFC5213 (sections 5.1 and 6.1). 
>> My question is how the LMA can build the relationship between MN link-local 
>> address and MN-HoA to be able to generate the message stated in figure 2?
>>
>> 2/ If two or more MNs have the same link-local address, how can the LMA 
>> distinguish among MN membership report messages entering the LMA with the same 
>> source addess through the same MAG? Could this situation produce that every new 
>> group suscription query coming from one of such MNs applied for all of them due 
>> to the fact that they have the same source address?
>>
> 
> The draft aims to define a MIPv6-like multicast support for PMIPv6 as already stated in it.
> 
> This problem you noted above has already been recognized in RFC 3775, I quote the text from Section 10.4.2:
> 
>    Note that at this time, even though a link-local source is used on
>    MLD packets, no functionality depends on these addresses being
>    unique, nor do they elicit direct responses.  All MLD messages are
>    sent to multicast destinations.  To avoid ambiguity on the home
>    agent, due to mobile nodes which may choose identical link-local
>    source addresses for their MLD function, it is necessary for the home
>    agent to identify which mobile node was actually the issuer of a
>    particular MLD message.  This may be accomplished by noting which
>    tunnel such an MLD arrived by, which IPsec SA was used, or by other
>    distinguishing means.
> 
> I think link-local source address collision is a problem also for MLD Proxy and in general in MLD for mobile.

I think the problem here is that LMA encapsulates and sends data to each
MN individually. Hence it must have a list of addresses for all the
receivers. These need to be unique for the MAG to determine to which MN
to send the data. Hence it cannot be link-local. You say you will MN-HoA
which would be unique. However, the MLD reports forwarded to the LMA
have link-local source address. I think for this to work, you either
need to rewrite MLD report source addresses from link-local to MN-HoA,
or the MAG needs to encapsulate the MLD reports and use MN-HoA as source
in the outer header.

My other concerns with this draft are:

Additional encap/decap by MAG/LMA. This is new functionality that must
be added.

My main issue is really that the benefit of multicast is lost between
LMA-MAG, since multicast data packets need to be replicated per MN.
This especially means increased bandwidth usage.

Also that the MTU available for multicast is further reduced. In general
I believe one cannot assume PMTUD for IPv6 multicast, so we have a
problem if the MTU gets too small. I guess since one cannot assume PMTUD
to work for IPv6 multicast, the data may be 1280 bytes or less. I think
the bigger MTU we can allow the better. In any case, we need to make
sure that after all encapsulation, we can still accept 1280 byte packets
(unless we also do fragmentation and reassembly).

There is also a performance cost in doing additional encap/decap and
replication of all multicast data. Fragmentation/reassembly would of
course also be expensive.

The main benefit I can see with this proposal is that state is
minimized on MAG (but increased on LMA). It may also be beneficial for
LMA to learn which MNs are trying to join if it needs to perform some
form of AAA. AAA could maybe be done by MAG too though.

Stig

> Regards,
> 
> Behcet
>> Thanks in advance,
>>
>> best regards,
>>
>> Luis
>>
>>
>>
>> _______________________________________________
>> multimob mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/multimob
> 
> 
> 
>       
> _______________________________________________
> multimob mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multimob