Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt

From: <[email-masked]>
Date: Tue, 1 Jun 2010 18:24:03 +0200

Hi Thomas,

I've read draft-ietf-multimob-pmipv6-base-solution-02 that I found in very good shape. Actually, I have only very few comments:

On section 3 (overview): 

I think, it would help to remind that the aggregated join is part of the normal operations of an IGMP/MLD proxy.

It is not clear (at least to me :-)) how the MAG manages duplicate traffic. Maybe the issue could be clarified. If I understood correcly, when two MNs, being attached to two different LMAs, subscribe to the same group, two multicast flow of the same group are received at the MAG. 
However, from my understanding, one multicast flow may arrive at the MAG with delay in comparison to the other multicast flow (end-to-end transmission delay from source to MN1 via LMA1 may differ from end-to-end transmission delay from source to MN2 via LMA2). So, to avoid data loss, the MAG must forward the right multicast flow to the corresponding MN. But, thanks to the PMIP model, it is not an issue: the MAG can forward each multicast stream, received via a particular tunnel, to the corresponding MN since the MN-MAG interface is a point-to-point link. Correct?

In 4.2 you wrote:

To learn about multicast groups subscribed by a newly attaching MN, the MAG SHOULD send a General Query to the MN's link. : Is it really a SHOULD? not a MUST? If the MAG does not send a general query, how the MAG learns the group subscribed by the new MN?

Still in 4.2: What do you mean by "Note that the actual observable state depends on the access link model in use." we are considering only point-to-point access link, right?

And few typos:

2.  Terminology:

s/protocols[RFC3376]/protocols [RFC3376]

In last paragraph of section 3:

s/an MAG/a MAG

4. Deployment details:

s/Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define its interaction with the PMIPv6 protocol in the following way:/Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define _their_ interaction with the PMIPv6 protocol in the following way:

Regards,
Pierrick 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Thomas C. Schmidt
Envoyé : mardi 25 mai 2010 21:54
À : [email-masked]
Objet : Re: [multimob]I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt

Hi all,

we just submitted the updated version of draft-ietf-multimob-pmipv6-base-solution as discussed in Anaheim.

 From the change log:

    1.  Added section on multihoming.

    2.  Updated security section.

    3.  Several editorial improvements and minor extensions.

Please have a firm look ;) so that we can finalize the document.

Thanks,

Thomas

On 25.05.2010 21:45, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Multicast Mobility Working Group of the IETF.
>
>
> 	Title           : Base Deployment for Multicast Listener Support in PMIPv6 Domains
> 	Author(s)       : T. Schmidt, et al.
> 	Filename        : draft-ietf-multimob-pmipv6-base-solution-01.txt
> 	Pages           : 19
> 	Date            : 2010-05-25
>
> 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.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-so
> lution-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
>
>
>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

-- 

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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 01 Jun 2010 20:00:44 +0300

Hi Pierrick,

many thanks for your careful review. Please see below marks [Thomas=>:

> I think, it would help to remind that the aggregated join is part of the normal operations of an IGMP/MLD proxy.
[Thomas=> Well, it says "According to
    standard proxy operations, MLD Report messages will be forwarded
    under aggregation up the tunnel interface to its corresponding LMA."

and cites the RFC4605 ... that should be a pretty strong reminder ...

> It is not clear (at least to me :-)) how the MAG manages duplicate traffic. Maybe the issue could be clarified. If I understood correcly, when two MNs, being attached to two different LMAs, subscri…

[Thomas=> Correct.

> However, from my understanding, one multicast flow may arrive at the MAG with delay in comparison to the other multicast flow (end-to-end transmission delay from source to MN1 via LMA1 may differ f…

[Thomas=> Actually, these operations are independent of PMIP, but follow 
from isolated proxy instances. The Proxy instance at the MAG will serve 
its downstream link with whatever group is subscribed and received.

For exactly this reason we stated in 4.2, 2nd para:

"At this stage, it is important to note that
    IGMP/MLD proxy implementations capable of multiple instances are
    expected to closely follow the specifications of section 4.2 in
    [RFC4605], i.e., treat proxy instances in isolation of each other
    while forwarding."

> To learn about multicast groups subscribed by a newly attaching MN, the MAG SHOULD send a General Query to the MN's link. : Is it really a SHOULD? not a MUST? If the MAG does not send a general que…

[Thomas=> Well, the MLD proxy always queries, so the 
(non-proxy-attached) interface is not required to query. Querying will 
occur anyway, but it is faster if done as soon as the link comes up.

> Still in 4.2: What do you mean by "Note that the actual observable state depends on the access link model in use." we are considering only point-to-point access link, right?

[Thomas=> Yes, but at this point it matters ... that's why we stressed it.

> And few typos:

[Thomas=> THANKS!

Best regards,

Thomas

--

---

From: <[email-masked]>
Date: Wed, 2 Jun 2010 09:59:31 +0200

Hi Thomas,

>
> On section 3 (overview):
>
> I think, it would help to remind that the aggregated join is part of
the normal operations of an IGMP/MLD proxy.

[pierrick] your're right. It proves that my review was not so careful
:-)

> It is not clear (at least to me :-)) how the MAG manages duplicate
traffic. Maybe the issue could be clarified. If I understood correcly,
when two MNs, being attached to two different LMAs, subscribe to the
same group, two multicast flow of the same group are received at the
MAG.

[Thomas=> Correct.

> However, from my understanding, one multicast flow may arrive at the
MAG with delay in comparison to the other multicast flow (end-to-end
transmission delay from source to MN1 via LMA1 may differ from
end-to-end transmission delay from source to MN2 via LMA2). So, to avoid
data loss, the MAG must forward the right multicast flow to the
corresponding MN. But, thanks to the PMIP model, it is not an issue: the
MAG can forward each multicast stream, received via a particular tunnel,
to the corresponding MN since the MN-MAG interface is a point-to-point
link. Correct?

[pierrick] I understand. I find your sentence "follow from isolated
proxy instances, the MAG will serve its downstream link with whatever
group is subscribed and received" more clear; it could be added to the
draft. Anyway, it's not a big deal.

>
> In 4.2 you wrote:
>
> To learn about multicast groups subscribed by a newly attaching MN,
the MAG SHOULD send a General Query to the MN's link. : Is it really a
SHOULD? not a MUST? If the MAG does not send a general query, how the
MAG learns the group subscribed by the new MN?

[pierrick] Thanks for clarifications. Your answers address all my
concerns.

BR,
Pierrick

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 02 Jun 2010 11:17:05 +0300

Thanks Pierrick,

we have changed all the points you were pointing at ... it will be part 
of the next update.

Cheers,

Thomas

--