Subject: Re: [multimob] Commonts on draft-schmidt-multimob-pmipv6-mcast-deployment-02

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 30 Oct 2009 18:42:25 +0100

Hi Imed,

many thanks for your careful review - and sorry for answering late: 
there have been a lot of blocking affairs.

Romdhani, Imed wrote:

> ---- bellow my comments on your draft if. I sent the same message a couple of days ago and I want to make sure you receive it ---
> 
> - In the abstract you mentioned that the LMAs serve as multicast subscription anchor points. It will be much clearer to indicate that LMAs will play the role of multicast designated routers.

This would be clear, but need not be true: the LMAs must be traversed by 
multicast streams, but could as well be another MLD proxy. So nothing 
should be said about their role on the multicast tree that is not 
mandatory, I believe. All we need is that they forward and understand 
MLD downstream.

> - In Section 1 (Introduction): you stated that group management requires a dedicated treatment. It will be appreciated if you clarify briefly this point. What kind of specific treatment or adjustment is needed? Are you considering this treatment as part of your proposed solution?

No, this is the introduction and reference to the requirements document. 
The point made here is simple and abstract: "Since end-to-end 
connectivity is lost in PMIP, MLD does not work as is anymore and 
something additional has to be done." It just motivates the requirement 
for action ... we could add "[requires dedicated treatment] at the 
network side", if this helps. But at this point, we don't want to 
anticipate any details.

> - In Section 1: you highlighted that multicast routing functions need a careful placement within the PMIPv6 domain. This statement is unclear. Do you mean that the LMA should be a boundary router in the PMIP domain?

No, still the same thing: We are at the introductory motivation ... and 
it is stated that things don't work automatically. One needs to 
carefully design a deployment of multicast entities, since it would not 
be successful otherwise.

> - In Section 1, last paragraph: it is preferable to replace ". options for activating multicast listener ." by ". options for implementing or deploying multicast listener .".

Thanks - we will change.

> - Figure 1 is misplaced and I think you should move it to section 3. In addition some terms are not explained (LMAA1, LMAA2, and MN-HNPi)

This is terminology from PMIP, which is referenced in this section. But 
we can move the figure to section 3.

> - In Figure 1, you illustrated two deployment scenarios where a MAG (e.g. MAG1) can be connected to two different LMAs (LMA1 and LMA2). Is this a realistic scenario? I mean, can we have two LMAs within a single PMIP domain? 

No and yes: Figure 1 is just the translation of the reference scenario 
from RFC5213 to multicast traffic. Actually, the aim of this draft is to 
not change the standard PMIP set-up. And yes, in PMIP you may have 
several LMAs - there is  only an n:1 correspondence between MN and LMA, 
a single MN does not use several LMAs.

> - In Section 3 (Overview), add (addresses) in the first paragraph to the following sentence ( thereby using its link-local .. and multicast destination ADDRESSES according to [RFC3810])

Thanks! - changed.

> - In Section 3, second paragraph, change (Thereby, each LMA upstream interface defines an MLD proxy domain at the MAG), by (.. LMA DOWNSTREAM interface) unless I misunderstood your statement. 

Right, this needs rewording: We change to "Thereby, each LMA-to-MAG 
tunnel interface defines an MLD proxy domain at the MAG, ...".

> - In Section 3, second paragraph, it is preferable to change "MLD signalling of the MN will be" by "MLD Report messages will be forwarded under". This is more explicit.

Thanks, yes.

> - You mentioned in Section 3 that aggregated MLD report messages will be tunnelled by the MAG to the LMA with which a particular MN is associated. I wonder here what happens if two MNs that are registered with two different LMAs and that want to subscribe to same multicast group/same sources, does the MAG to which these MNs are attached will send two aggregated MLD reports to each LMA although the pair (S,G) is the same? I think, it will be more optimal if the MAG selects one of the LMAs. This helps to avoid the problem of redundant paths that you mentioned at the end of the same section. Multicast operation does not need necessary to be linked to mobility associations. It can be decoupled.

Yes, you are right. There will be traffic redundancy, if MNs associated 
to different LMAs request the same group. At the moment, I don't see an 
easy way to change this in the PMIP setup. MLD proxy operates on single 
uplinks and if we decouple group traffic from MN <-> LMA association, 
then handover support is stopped.

The alternative approach would be as pursued by 
[draft-zuniga-multimob-smspmip-00 ]: Here *one* dedicated LMA is chosen 
for all multicast traffic - with the result that the default PMIP set-up 
is 'somewhat' changed and that a tunnel avalanche may pile up at this LMA.

> - In Figure 2, I prefer that you use (MLD report) rather than Join(G). Join is a specific multicast routing messages and it is not an MLD terminology.

Yeah, well: "MLD Membership Report" is a bit long for the figure ... and 
everybody understands JOIN ?

> - In Section 4.2 you stated that a "MAG will observe (use detect instead) the arrival of a new MN by receiving a router solicitation message or by an upcoming link". This is not always true as an MN may receive a router advertisement message prior to sending any router solicitation message. The same remark applies to the consequences of an MN departure. The multicast states will not systematically change as it may exist other MNs attached the same MAG that are subscribed to the same multicast groups or channels.

First, you point to the general mechanisms in PMIPv6 (see section 6.6): 
For PMIP to work, it is required that a MAG can reliably detect MN 
attachment & identify the MN. Typically, this is done by a RtrSol 
triggered by link-state changes at the MN. We don't expect any more than 
the basic PMIP mobility mechanisms here. A MAG will also detect the 
departure of a  MN, so it can suppress forwarding - but we might clarify 
this in the next version of the draft.

> - Change (a MN) by (an MN) in Section 4.2.

Thanks.

> - You mentioned in Section 4.2 that MLD timers and robustness variable should be compliant with the specific requirement of PMIP. Do you mean that the Query Interval should be shortened and the robustness variable increased? 

We have been vague on purpose here, as I believe this depends not so 
much on PMIP, but on the L2 technology in use. But this may be subject 
to future discussions and specifications.

> - In Section 4.3 you indicated that a LMA can be either a multicast designated router or an MLD proxy. I think this should be clarified in separate sub-sections.

Why? Actually, the downstream Operations do not depend on it, and the 
upstream operations are out of scope for this document. So it actually 
does not really matter (as a specific multicast routing protocol does 
not), provided the LMA is able to forward the requested group traffic.

So again, thanks for your careful review. Presently, it is cut-off 
period. We will come up with a new version of the document after 
discussions in Hiroshima - probably, more comments / hints will occur.

Cheers & best wishes,

Thomas

> ________________________________________
> From: [email-masked] [[email-masked]] On Behalf Of Thomas C. Schmidt [[email-masked]]
> Sent: 16 October 2009 10:02
> To: [email-masked]
> Subject: [multimob] [Fwd: New Version Notification for  draft-schmidt-multimob-pmipv6-mcast-deployment-02]
> 
> Dear all,
> 
> we have just submitted an update of
> draft-schmidt-multimob-pmipv6-mcast-deployment, please see
> http://www.ietf.org/id/draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt
> 
> This draft was introduced and discussed in and around Stockholm and
> provides guidelines for a minimal deployment of semi-optimized multicast
> on PMIPv6 domains by *using standard protocols only*.
> 
> The current update includes
> 
>   * replacing the dependence on the p-t-p wireless link model (link state
>     trigger) - use Rtr sol instead, which works on arbitrary link models
> 
>   * editorial improvements & minor fixes.
> 
> Please help us with comments to improve the document: We will try to
> include your suggestions in an update prior to Hiroshima, where we have
> asked for a presentation slot to present & discuss the document in detail.
> 
> Best regards & see you in Hiroshima
> 
> Thomas
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-schmidt-multimob-pmipv6-mcast-deployment-02
> Date: Fri, 16 Oct 2009 01:45:55 -0700 (PDT)
> From: IETF I-D Submission Tool <[email-masked]>
> To: [email-masked]
> CC:
> [email-masked],[email-masked],[email-masked],[email-masked]
> 
> 
> A new version of I-D,
> draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt has been
> successfuly submitted by Thomas Schmidt and posted to the IETF repository.
> 
> Filename:        draft-schmidt-multimob-pmipv6-mcast-deployment
> Revision:        02
> Title:           A Minimal Deployment Option for Multicast Listeners in PMIPv6
> Domains
> Creation_date:   2009-10-16
> WG ID:           Independent Submission
> Number_of_pages: 12
> 
> Abstract:
> This document describes deployment options for activating multicast
> listener functions in Proxy Mobile IPv6 domains without modifying
> mobility and multicast protocol standards.  Similar to Home Agents in
> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
> subscription anchor points, while Mobile Access Gateways provide MLD
> proxy functions.  In this scenario, Mobile Nodes remain agnostic of
> multicast mobility operations.
> 
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> --
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
> 
> On 25 February 2009, the University launched its new name, Edinburgh Napier University.  
> 
> For more information please visit our website.
> 
> Edinburgh Napier University is one of the top 10 universities in the UK for graduate employability (HESA 2009)
> 
> This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
> It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.
> 
> Edinburgh Napier University is a registered Scottish charity. Registration number SC018373
> 
> 

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °