Subject: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-base-solution-04

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 12 Jul 2010 23:51:21 +0200

Hi all,

we just submitted a new version of 
draft-ietf-multimob-pmipv6-base-solution that includes the comments and 
improvements of the latest reviews:

http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-04

Looking forward to your feedback,

Thomas

-------- Original Message --------
Subject: New Version Notification for 
draft-ietf-multimob-pmipv6-base-solution-04
Date: Mon, 12 Jul 2010 14:40:32 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: 
[email-masked],[email-masked],[email-masked]

A new version of I-D, draft-ietf-multimob-pmipv6-base-solution-04.txt 
has been successfully submitted by Thomas Schmidt and posted to the IETF 
repository.

Filename:	 draft-ietf-multimob-pmipv6-base-solution
Revision:	 04
Title:		 Base Deployment for Multicast Listener Support in PMIPv6 Domains
Creation_date:	 2010-07-12
WG ID:		 multimob
Number_of_pages: 20

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, Local Mobility Anchors of Proxy Mobile IPv6 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 support for mobile
multicast senders is outside the scope of this document.

The IETF Secretariat.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 14 Jul 2010 10:08:58 -0400

Hi Thomas,

Overall the draft looks in very good shape.  Just two final comments:

- In Figure 2, suggest that you change from "Movement to MAG2 ..." to
"Movement of MN2 to MAG2 ..." for improved readability.

- In the last sentence of section 3, it states that "multicast traffic
to one MN will always remain unique, i.e., the mobile multicast
distribution system will never cause duplicate packets arriving at an
MN".  However, if the MN is multi-homed (as per section 4.5) is it not
possible that in a simply designed MN implementation that membership to
the same multicast group may be made on multiple interfaces?.   This can
be done without breaking any protocols.  So, in this multicast traffic
to one MN in fact will NOT remain unique (though of course this is not a
fault of the multicast distribution system).  Do you agree?

Sincerely,

Akbar and Juan-Carlos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas C. Schmidt
Sent: Monday, July 12, 2010 5:51 PM
To: [email-masked]
Subject: [multimob] Fwd: New Version Notification
fordraft-ietf-multimob-pmipv6-base-solution-04

Hi all,

Thomas

-------- Original Message --------
[email-masked],[email-masked],suresh.krishnan@ericss
on.com

repository.

Filename:	 draft-ietf-multimob-pmipv6-base-solution
Revision:	 04
Title:		 Base Deployment for Multicast Listener Support in
PMIPv6 Domains
Creation_date:	 2010-07-12
WG ID:		 multimob
Number_of_pages: 20

Abstract:

The IETF Secretariat.

_______________________________________________
multimob mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multimob

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 15 Jul 2010 01:09:56 +0200

Hi Akbar,

thanks for overlooking the draft and your comments. Please see answers 
inline:

> "Movement of MN2 to MAG2 ..." for improved readability.

O.K. - we will try to fit this in.

> fault of the multicast distribution system).  Do you agree?

Yes, that's correct. But if a node (mobile or not) subscribes to the 
same group on multiple interfaces of possibly disjoint paths, it will 
always receive duplicate traffic (on its own will). So this is neither 
specific to (PMIP) mobility nor to the distribution system. Actually, 
this is just the correct behavior (which the multihomed node actively 
asks for). IMHO it would be misleading to stress this in the 
characterization of mobile multicast routing behavior, as this is just a 
transparent reaction for multihomed nodes.

Thanks,

Thomas

> From: IETF I-D Submission Tool<[email-masked]>

-- 

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 °

---

From: <[email-masked]>
Date: Thu, 15 Jul 2010 16:24:53 +0200

Dear Thomas, Matthias, Suresh,
Thanks for the progress! 
As usual ;-) only very minor comments on the document:
P.3, 	3rd section: ... re-initiate such a tunnel ('re-' as it initiates a tunnel already before movement?)
P.5, 	1st section: ... forwarded _after_ aggregation (for me more clear instead of 'under') ?
	2nd section: ... traffic _aimed at/dedicated for_ subscribed groups will arrive (instead of twice 'arriving for ... arrive')
P.8, 	5th section: ...send an aggregated Report _via_ the upstream tunnel to the LMA (insteda of 'to')
P.10, 1st section: ... multicast forwarding information base (MFIB). (add acronym used on p.11)
P.11, 5th section: ... from which network the LMA pulls multicast traffic from. (delete one of both 'from')
  
Best regards

Dirk 
-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Thomas C. Schmidt
Gesendet: Montag, 12. Juli 2010 23:51
An: [email-masked]
Betreff: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04

Hi all,

Thomas

-------- Original Message --------

Abstract:

The IETF Secretariat.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 16 Jul 2010 13:03:49 -0400

Hi Thomas,

Thank you for your replying.   Please see below my one response.  As
usual, I leave it to your best judgment on how to close the issue as I
do not want to hold up the draft at this stage.

--- snip ----

Thanks,

Thomas

----- end snip ----

The point though is that the original text captures two ideas.  The
first is that "multicast traffic to one MN will always remain unique".
This we both agreed above may not be true in simple MN implementations.
The second point in the text is that "... i.e., the mobile multicast
distribution system will never cause duplicate packets arriving at an
MN".  This point is always true.  So my recommendation is that you
delete the first phrase ("multicast traffic to one MN will always remain
unique") and leave only the second phrase in the document (" the mobile
multicast distribution system will never cause duplicate packets
arriving at an MN").  What do you think?

Akbar

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 21 Jul 2010 20:25:21 +0200

Hi Thomas,

two very minor comments, just in case you consider them as relevant:

1/ on page 5, third paragraph, when talking about the Binding Update 
List you provide the reference "section 6 of [RFC5213]", while on page 
8, first paragraph of point 4.2, you provide the reference "section 6.1 
of [RFC5213]" when talking also about the Binding Update List.

2/ on page 6, step 8 of the handover process by the MAG: I would 
suggest to include some wording about the case the MN has no active 
multicast subscription when receiving the MLD Queries from MAG (that 
is, the link of the MN is removed from the MLD proxy instance.)

Regards,

Luis

"Thomas C. Schmidt" <[email-masked]> dijo:

> draft-ietf-multimob-pmipv6-base-solution that includes the comments 
> and improvements of the latest reviews:
>
> has been successfully submitted by Thomas Schmidt and posted to the 
> IETF repository.
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 26 Jul 2010 12:08:26 +0200

Hi Akbar,

thanks for your additional comment, please see below:

> arriving at an MN").  What do you think?

You're right in pointing us to be as precise and correct as possible :-)

There is an important point in clearly stating that traffic remains 
unique as it traverses the distribution system towards the MN, but you 
are right that uniqueness only holds per interface. So we propose to change:

"However, multicast traffic arriving at one interface of the MN will 
always remain unique, i.e., the mobile multicast distribution system 
will never cause duplicate packets arriving at an MN"

Best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 26 Jul 2010 13:06:52 +0200

Hi Dirk,

many thanks for your comments ... and sorry for answering late.

> P.3, 	3rd section: ... re-initiate such a tunnel ('re-' as it initiates a tunnel already before movement?)

?? I'm a bit puzzled by this: on P.3, 3rd section I see:
   "...a mobility-unaware node will not initiate such a tunnel after 
movement"

  ... but no re-initiate ???

> P.5, 	1st section: ... forwarded _after_ aggregation (for me more clear instead of 'under') ?

O.k. ... that's a language question, I'm uncertain. How about
"MLD Report messages will be aggregated and then forwarded up the tunnel 
interface to its corresponding LMA." ?

> 	2nd section: ... traffic _aimed at/dedicated for_ subscribed groups will arrive (instead of twice 'arriving for ... arrive')

Good point: How about "Traffic of the subscribed groups will arrive at 
the LMA" ?

> P.8, 	5th section: ...send an aggregated Report _via_ the upstream tunnel to the LMA (insteda of 'to')

O.K., changed.

> P.10, 1st section: ... multicast forwarding information base (MFIB). (add acronym used on p.11)

Thanks, yes, you're right: it's added now.

> P.11, 5th section: ... from which network the LMA pulls multicast traffic from. (delete one of both 'from')

Yes, deleted.

Thanks & best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 26 Jul 2010 13:44:35 +0200

Hi Luis,

thanks for looking at the details and sorry for answering late.

> of [RFC5213]" when talking also about the Binding Update List.

O.K., you're right: 6.1 is more specific and has been placed on page 5.

> 2/ on page 6, step 8 of the handover process by the MAG: I would suggest
> to include some wording about the case the MN has no active multicast
> subscription when receiving the MLD Queries from MAG (that is, the link
> of the MN is removed from the MLD proxy instance.)
>

Well, if no MLD Report is received, the proxy essentially does nothing 
(that was indicated by "if necessary". Actually, the link to the MN is 
not removed, it remains a regular downstream link of the MLD Proxy jut 
without forwarding entries.

So I don't see a lot content to add except the remark that "no active 
multicast subscriptions will lead to no MLD reports which in turn will 
lead to no reaction at the MAG" - or are you referring to anything I 
might have missed?

Thanks,

Thomas

--

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 26 Jul 2010 09:48:54 -0400

Hi Thomas,

I agree with your proposed text.  Thanks for taking the time to answer all our questions!

Akbar and Juan Carlos.

-----Original Message-----
From: Thomas C. Schmidt [mailto:[email-masked]] 
Sent: Monday, July 26, 2010 6:08 AM
To: Rahman, Akbar
Cc: [email-masked]
Subject: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-base-solution-04

Hi Akbar,

Best regards,

Thomas

--

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 28 Jul 2010 14:11:08 +0200

Thanks Thomas,

regarding my second point:

> Well, if no MLD Report is received, the proxy essentially does 
> nothing (that was indicated by "if necessary". Actually, the link to 
> the MN is not removed, it remains a regular downstream link of the 
> MLD Proxy jut without forwarding entries.
>
> multicast subscriptions will lead to no MLD reports which in turn 
> will lead to no reaction at the MAG" - or are you referring to 
> anything I might have missed?
>

I think I had misunderstood the "Non Listeners Present" state on MLD 
router side according to RFC2710. There, it is stated that no storage 
is needed for those links without multicast activity (the forwarding 
entries that you mention, I guess) but in some way the association 
between downstream intrerface and proxy instance has to be kept (e.g., 
from the BUL).

It is clear now.

The text you propose is good for me, if you consider it relevant to be 
included.

Thanks, regards,

Luis