[Mobopts] Re: Review of Draft draft-schmidt-mobopts-mmcastv6-ps-00.txt

[Thomas Schmidt <[e-mail]>]

Dear Stig,

many thanks for overlooking the ps-draft. Please see our comments inline:

Stig Venaas wrote:

> 
> I've looked at the presentation and think it's good, although some
> minor things that was not clear. I think perhaps better to discuss
> the draft though. I think the draft is good, but it could be improved
> in some places. Below are my thoughts upon reading the draft. Note
> that the language could be improved in some places too, but not
> commenting on that now.
> 
> Under 2.1 you say
> 
>    Multicast sources in general operate decoupled from their receivers
>    in the following sense: A multicast source submits data to a group of
>    unknown receivers, thus operating without any feedback channel. It
>    neither has means to inquire on properties of its delivery trees, nor
>    will it be able to learn about the state of its receivers. In the
> 
> I suppose this is fine, since this is the general situation. But you
> could perhaps note that many multicast applications use RTP where RTCP
> is often used for feedback. Well, not sure if worth mentioning.
> 
That's true, one can use RTCP or RTP MIB to monitor multicast sessions. 
The problem is, though, that we cannot presuppose applications using 
RTP. There will always possibly be multicast groups not using RTP.

One could probably mention RTP in an Appendix ...

> For SSM there has also been a proposal for a mechanism called MSNIP
> (I can point to draft) that allows a source to know whether there are
> receivers (note that it only says receivers or not, not how many or
> their identity/addresses). This is probably not so useful then.
> 

Yes, MSNIP was meant to inquire a designated router on the presence of 
receivers. But as far as I know work on MSNIP has been terminated more 
than a year ago ... there has been some discussion on ssm mailing list a 
couple weeks ago wether to revitalise MSNIP - but most people were 
negative about it.

Nevertheless, MSNIP won't tell more about the status of receivers ... 
and should be rather slow, as well.

> In 2.3.1 you say:
> 
>    A node submitting data to an ASM group defines the root of either a
>    shared or source specific delivery tree. Beside root location
> 
> This is not really true. The shared tree is always rooted at the RP.
> I know what you mean of course... When forwarding takes care on the
> shared tree, the RP receives data natively (by having built a source
> specific tree rooted at source) or via PIM registers. So I think this
> should be reformulated.
>
This seems to be a matter of formulation: The statement has been done 
openly on purpose to include Mcast routing protocols other than PIM-SM. 
We will change it to be more explicit.

> One perhaps interesting thing to consider, is that for IPv6 you may
> use embedded-RP (IMO the only way to do inter-domain ASM). For some
> type of applications, in particulay the single-source one, the RP
> used with embedded-RP should be close to the source, and may in
> many cases be the HA. So it might be interesting to consider whether
> that may help in any way. Of course in general for ASM, there are
> many sources and at least for IPv6, they may not be in the same
> domain as the RP.
> 
We agree, one should deepen this discussion. We only offered it a side 
remark. In the case of single source identifying RP and HA is an idea 
that has been partly discussed by Rhomdhani. It simplifies a lot. 
However, in the case of mobility it can neither be assumed nor 
guaranteed that HA is (resp. remains) close to the Mobile Node/Source.

> At the end of 2.3.1 you say:
> 
>    In presence of inter- domain multicast routing a change of address
>    must trigger the exchange of a new multicast source record.
> 
> What are you trying to say here? I'm sort of guessing it might be
> something like MSDP Source Active messages. I would say that for
> IPv6 there is nothing special about crossing domains, apart from
> scoping. For IPv4 the situation is very different.
> 
Yes, this was a reference to MSDP Source Active messages. But you are 
right, this only applies to IPv4 ...

> Another possible ASM issue perhaps, is that application may need to
> distinguish between moving source and new source? Although if the
> application always sees the sources HoA (and not CoA) as the source
> of the multicast packets, this should be ok. If I understand MIPv6
> correctly, it should always only see HoA, or?
> 

This is one of the key features of MIPv6 - mobility is application 
transparent by passing HoA to the transport layer. RFC 3775 does briefly 
mention multicast mobility and withstands from applying Binding 
Caches/Mobility Option Headers to it. But as multicast applications 
usually are source address aware, it is IMO one key issue to be changed 
in order to acchieve seamless multicast mobility.

> 2.3.2
> 
> I started to wonder how SSM source filters should work. If it is
> the case that the application only sees the HoA in the API, e.g.
> as source of multicast packets, then it is reasonable that it
> joins the HoA. This means that the address that should be matched
> against the source filter is the HoA, not the CoA (which is the
> source address in header of the multicast packets). However,
> applications should IMO also be able to join a CoA, i.e. using
> source filter with the CoA, but if the HoA is used for checking
> against the source filter, that will fail. So it seems that a
> packet should pass through the source filter if either HoA or
> CoA matches. I'm surprised if source filter implementations on
> operating systems today do this.
> 

Not sure what you mean: Any application can of course subscribe to CoA 
(in case it is known) and HoA, as well. The trouble is, that CoA changes 
under mobility...

A typical approach could be to have the MIP stack translate: the 
application joins to a HoA and the stack identifies current CoA for that 
HoA (from binding cache or external inquiry) and does the subscription 
and source filtering w.r.t CoA.

However, there are open issues remaining on how to operate handovers.

> In solutions you say:
> 
>     o Remote Subscription forces the mobile node to re-initiate
>    multicast distribution subsequent to handover, using its current
>    Care-of Address. This approach of tree discontinuation relies on
> 
> You are trying to say that the mobile node will re-join the multi-
> cast groups through the network it's currently visiting? It's not
> really correct to say that it uses it's CoA. No address is used
> for joining a group, apart from the link-local address for MLD
> reports.
> 

No, this is a misunderstanding: the statement was about sources and the 
source address in use. It was not about clients - but you're right: we 
should distinguish and state that more clearly.

> In security considerations you say something about binding update
> for multicast. I'm not sure what you mean by that and what the
> security problems are.
> 
In MIPv6 a binding cache contains the mappings between HoA and current 
CoA. Tampering with the binding cache is a straight forward way to 
distroy/hijack/modify sessions. These aspects partly extrapolate to 
multicast.

thomas

_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts