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

From: Stig Venaas <[email-masked]>
Date: Tue, 01 Jun 2010 01:42:08 -0700

This version looks good to me. I didn't check carefully for typos, but
"looses" should be "loses" I believe.

Stig

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 01 Jun 2010 13:02:07 +0200

Hi all,

after a change on my e-mail server I lost my subscription to the list. 
I was not aware of the new draft versions till yesterday. Sorry for 
coming late to comment the base solution.

Please, find some few comments on 
draft-ietf-multimob-pmipv6-base-solution-02.txt only for clarification.

.- Group membership aggregation from the MAG to the LMA --> it is 
indicated along the document that the MAG will sent aggregated reports 
to the LMA as an intrinsic function of the MLD proxy. I think it is ok 
in an steady state behaviour. However it is somehow strange for me to 
see this highlighted when describing the handover process, as showed in 
figure 2. Let me explain. Once the MN attaches to the new MAG and 
responses the MLD General Query sent by the new MAG, in case there is 
no other MN requesting simultaneously the same content, there is no 
room for aggregation of the MLD report. If the MAG has already an 
active subscription for such content, the MAG will no forward the 
report towards the LMA. On the contrary, if the MAG has not a 
subscription for such content should send an unsolicited Report as soon 
as possible towards the LMA, because membership database changes. The 
aggregated report as depicted in figure 2 has sense as a response of an 
MLD General query coming from the LMA, but, in a general case, I can't 
see it for the Report sent by the MN after handover

.- Sentence about "make-before-break" in multihoming support section 
--> What is the reason for this constraint? I mean, Is it your proposal 
or is it something already agreed? As you explain in other mail, your 
vision is to avoid an smooth handover by changing the interface where 
the content is received before the MN moves. Due that the MN is not 
aware in PMIPv6 of its movement at IP level, I think such smooth 
handover does not apply, and the statement can be removed from the base 
solution document (I think it can be a matter for protocol extension 
issues).

Best regards,

Luis

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 01 Jun 2010 16:34:05 +0300

Dear Luis,

thanks for your feedback. Please see below (marked with [Thomas=>)

On 01.06.2010 14:02, Luis M. Contreras wrote:
> Hi all,
>
> after a change on my e-mail server I lost my subscription to the list. I
> was not aware of the new draft versions till yesterday. Sorry for coming
> late to comment the base solution.
>
> responses the MLD General Query sent by the new MAG, in case there is no
> other MN requesting simultaneously the same content, there is no room
> for aggregation of the MLD report. If the MAG has already an active
> subscription for such content, the MAG will no forward the report
> towards the LMA. On the contrary, if the MAG has not a subscription for
> such content should send an unsolicited Report as soon as possible
> towards the LMA, because membership database changes. The aggregated
> report as depicted in figure 2 has sense as a response of an MLD General
> query coming from the LMA, but, in a general case, I can't see it for
> the Report sent by the MN after handover
>
[Thomas=> I guess we agree on the operations: The MAG sends reports that 
aggregate all MN subscriptions. So in case of a single handover, it 
either sends an immediate report (if the new MN has a unique group 
membership) or it just refreshes periodically, if group states are 
shared among several MNs. Aggregation again plays a "real" role, 
whenever several MNs handover about simultaneously.

You raise the question on the proper presentation in Figure 2. In 
writing "aggregated Join" we tried to combine these different behaviors 
under one name ... otherwise we should need something like a case 
distinction in the graph. So we believe that this summarizing term 
"aggregated Join" helps to keep the flow chart simple and hints to the 
correct mechanisms and intuitions ....

> .- Sentence about "make-before-break" in multihoming support section -->
> What is the reason for this constraint? I mean, Is it your proposal or
> is it something already agreed? As you explain in other mail, your
[Thomas=> This seems like a misunderstanding: The objective of the 
multihoming support section is to clarify the behavior of multihomed 
PMIPv6 nodes that are subscribed to multicast groups. It is just 
explaining the base solution in this context, there are no personal 
opinions in there.

The statement about "make-before-break" just clarifies that multihoming 
in this situation cannot be used for smoothing mobility management. As 
you may have heard, there is an active debate on this 
"make-before-break" based on multihoming and people might be mistakenly 
tempted to believe that this scenario applies here ...

That's all, just clarification, no proposal or new solution here.

Best regards,

Thomas

-- 

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: Behcet Sarikaya <[email-masked]>
Date: Tue, 1 Jun 2010 12:22:47 -0700 (PDT)

Hi Thomas,
  It seems like you have not done almost any of the corrections/comments I posted earlier at:
http://www.ietf.org/mail-archive/web/multimob/current/msg00853.html

Can you please offer an explaination, item by item why?

Thx.

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 02 Jun 2010 16:33:28 +0300

Hi Behcet,

from a thematic point of view, I've picked up the state of the 
discussion. Those not picked up (like the NAT) were already discussed on 
the list.

On the editorial side: I did not pick up the continuous spell out of all 
protocol names as this appears unusual  and makes the document more 
difficult to read. (it should suffice to spell out PMIPv6 in the 
abstract and at its first use, but keep the well-known abbreviation the 
dozen other times) In addition, if there are nits on this level, the 
RFC-editor will take care of this before AUTH48.

Aside, I'm not aware of any open issue.

Best regards,

Thomas

On 01.06.2010 22:22, Behcet Sarikaya wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Jun 2010 12:36:24 -0700 (PDT)

Hi Thomas,
  Only a few issues left, I think we are getting there.
See below.

Regards,

Behcet

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: [email-masked]
> Sent: Wed, June 2, 2010 8:33:28 AM
> Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt
> 
> Hi Behcet,

> discussion. 

Which ones?

For example Section 1 Paragraph 3, you have not picked up and also not offering any explaination why. 
In your new text you are making some statements that may not be correct.

Section 5.1 and 5.2 have not picked up.

About some informative references?

> Those not picked up (like the NAT) were already discussed on the 
> list.

I am not sure if it would be sufficient to only say that IGMP is supported analogously 

because IPv4 is different.

> On the editorial side: I did not pick up the continuous spell out 
> of all protocol names as this appears unusual  and makes the document more 
> difficult to read. (it should suffice to spell out PMIPv6 in the abstract and at 
> its first use, but keep the well-known abbreviation the dozen other times) In 
> addition, if there are nits on this level, the RFC-editor will take care of this 
> before AUTH48.

Are you saying that RFC 3775, 5213, 5844 are difficult to read?

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Jun 2010 16:12:47 -0400

Hi Thomas,

Thank you for the updates, and for addressing our previous comments. Overall the document looks in good shape.  We have the following comments and suggestions for your consideration for any future update:

- Section 1
o	In the 3rd paragraph, the key (background) motivation point of what multicast is supported in PMIPv6 and MIPv6 is mentioned as follows:

   "[RFC5213] does not explicitly address
   multicast communication and thus relies on the minimal multicast
   support provided by MIPv6.  But unfortunately, bi-directional home
   tunneling, the minimal multicast support arranged by MIPv6, cannot be
   applied in network-based management scenarios, since a mobility-
   unaware node will not initiate such a tunnel after movement."

o	However, the second sentence above is very hard to decipher and should be re-worded to make it more understandable.  Also the above two sentences taken together seem to imply that there is a fault in RFC5213 (i.e.  that RFC5213 suggests to use MIPv6 multicast approach but that this is not intrinsically possible by the MN since it is unaware of network mobility).  Was that the intent?

- Figure 2
o	The Rtr Adv reply to the Rtr Sol is missing
o	MN2 moves to MAG2. However it is not clear where the arrow "Movement to MAG2 & PMIP Binding Update" points to.

- Section 3
o	The paragraph talking about IPv4 ("These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Support

- Section 4.5
o	This section on multi-homing is clear on the details of PMIPv6 operation over the multiple interfaces of an MN.  However, what was not clear was how the multicast application would operate and react if it got, for example, the same multicast group subscription over the multiple interfaces?  Could you add some more explanatory description as for example your description in section 3 "It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses ..."]

- Appendix C: 
o	In the Appendix it states:
  "For scenario A it should be also noted that the
   high stream replication requirements at LMAs in setting 1 can be
   attenuated by deploying additional LMAs in a PMIP domain, while
   scenario B does not allow for distributing the LMA-M, as no handover
   management is available at LMA-M."

o	Please note in our latest draft (draft-zuniga-multimob-smspmip-03, section 3.1) we clarify that multiple LMA-M's can be deployed to address the scalability issue.  So the key difference between scenarios A and B is that in scenario B we separate the unicast and multicast paths (and not in the number of LMAs)

o	In the Appendix it states:

    "These considerations of extremal settings show that tunnel
     convergence, i.e., duplicate data arriving at a MAG, does cause much
     smaller problems in scalability than the stream replication at LMAs
     (avalanche problem)"

o	In the previous working group discussions, the terms "tunnel convergence" and "avalanche problem" were used interchangeably.  In this paragraph they now seem to have different meanings.  Also, scenario B does not replicate streams at the LMA.

Sincerely,

Akbar, Juan-Carlos, Guang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas C. Schmidt
Sent: Monday, May 31, 2010 6:13 PM
To: [email-masked]
Subject: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt

Hi all,

following the comments on the list, we just updated the draft. There 
have been a number of editorial changes, but the core content remains 
stable.

Please find the updated version at 
http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-02

and drop us your feedback.

Thanks,

Thomas

On 01.06.2010 01:00, [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-02.txt
> 	Pages           : 20
> 	Date            : 2010-05-31
>
> 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 URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-02.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.
>
>
>

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 04 Jun 2010 00:08:14 +0300

Hi Behcet,

please see below:

On 03.06.2010 22:36, Behcet Sarikaya wrote:
>> From: Thomas C. Schmidt<[email-masked]>
>> To: [email-masked]

?? Unclear to me: what is incorrect? (There was only a clarification 
added about RFC3775 bi-directional tunneling which does not work for 
PMIPv6 as we all know.

> Section 5.1 and 5.2 have not picked up.

5.1/5.2 explain resp. give reference to the use of addressing in MLD. As 
destination addresses depend on the context of the messaging (as 
differently defined in RFCs 2710 and 3810), only the pointer is given in 
this overview.

Regarding IPv4: This document is focused on PMIP*v6* - and there is an 
obvious correspondence between MLD and IGMP. I don't see much value in 
repeating the tables with the obvious changes ... but this is not a 
crucial part. It would just make the text longer.

> because IPv4 is different.

??? Section 4.4. explains the analogy.

> Are you saying that RFC 3775, 5213, 5844 are difficult to read?

No, I was referring to writing "Proxy Mobile IPv6" instead of PMIPv6 
(likewise MLD) after the well-known abbreviations have been introduded 
in the draft. But that's only editorial details and will be guided by 
the RFC-Editor.

Best,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Jun 2010 15:09:20 -0700 (PDT)

Hi Thomas,
  Inline.
...........
snipped

> (There was only a clarification 
added about RFC3775 bi-directional tunneling 
> which does not work for 
PMIPv6 as we all know.

It depends on what you wish to say.
Based on what I could see, I suggested the following:
[behcet] The above paragraph needs to be rewritten to state that PMIPv6 does not explicitly address multicast communication. 
It was a choice to design multicast extension for PMIPv6 similar to MIPv6 but due to the inefficiencies
involved in bi-directional home tunneling a proxy based solution described in this document has
instead been opted for. 
[behcet] please add several sentences on why proxy approach is better (as has been discussed on ML).

The above would solve the problem and make the text much clearer.

> the use of addressing in MLD. As 
destination addresses depend on the context 
> of the messaging (as 
differently defined in RFCs 2710 and 3810), only the 
> pointer is given in 

If that is the case then state the specific values for each, I don't think MLD has a million different messages.

In a section that is about Message Source and Destination Address
we also need multicast data (but v6 and v4) information, this is missing.

> focused on PMIP*v6* - and there is an 
obvious correspondence between MLD and 
> IGMP. I don't see much value in 
repeating the tables with the obvious 
> changes ... but this is not a 
crucial part. It would just make the text 
> longer.

Why not? It is some useful detail.

How do multicast data packets look like is missing as I said above. 

> I am not sure if it 
> would be sufficient to only say that IGMP is supported 
> analogously
>

> Section 4.4. explains the analogy.

Yes this helps.
You should add one paragraph there on RFC 5135.

>
>> On the editorial 
> side: I did not pick up the continuous spell out
>> of all protocol 
> names as this appears unusual  and makes the document more
>> 
> Are 
> you saying that RFC 3775, 5213, 5844 are difficult to read?
>

> No, I 
> was referring to writing "Proxy Mobile IPv6" instead of PMIPv6 
(likewise 
> MLD) after the well-known abbreviations have been introduded 
in the draft. 
> But that's only editorial details and will be guided by 
the 
> RFC-Editor.

It is up to you but I think it is good practive to follow these well known RFCs. Besides it is very easy to do it.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 04 Jun 2010 14:14:05 +0300

Hi Akbar,

thanks for your careful review: please see inline (marked with [Thomas=>).

> o	However, the second sentence above is very hard to decipher and should be re-worded to make it more understandable.  Also the above two sentences taken together seem to imply that there is a faul…

[Thomas=>
:-) ... this sentence is the result of too many change requests. It 
actually explains a trivial observation, but there seems to be 
surprisingly little clearness about "Why PMIP needs a dedicated 
multicast treatment" ...

Here is our replacement:

"
Multicast routing functions need to be placed carefully within the 
PMIPv6 domain to augment unicast transmission with group communication 
services. <xref target="RFC5213" ></xref> does not explicitly address 
multicast communication. Bi-directional home tunneling, the minimal 
multicast support arranged by MIPv6, cannot be directly transfered to 
network-based management scenarios, since a mobility-unaware node will 
not initiate such a tunnel after movement. Consequently, even a minimal 
multicast listener support in PMIPv6 domains requires an explicit 
deployment of additional functions."

> o	The Rtr Adv reply to the Rtr Sol is missing

O.K., we added it.

> o	MN2 moves to MAG2. However it is not clear where the arrow "Movement to MAG2&  PMIP Binding Update" points to.
>

"< Movement to MAG2 & PMIP Binding Update >" does not contain an arrow, 
but is an explanatory comment in a common notation form.

> o	The paragraph talking about IPv4 ("These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Su…

Don't think so: Section 3 is the Overview, so redundant in topic (but of 
reduced details) to section 4. IMHO it is perfectly o.k. to already 
mention IPv4 in the overview (as we mention MAG and LMA ...)

> o	This section on multi-homing is clear on the details of PMIPv6 operation over the multiple interfaces of an MN.  However, what was not clear was how the multicast application would operate and re…

[Thomas=> There are two things to note here, which are completely 
independent of mobility:

  (i) An application can choose (via the socket API), how and where to 
join a multicast group. It does not need to do this explicitly, but it 
is free to do and there is no general rule ...
  (ii) A multicast client application is supposed to be robust with 
respect to packet loss, duplication etc. It is a UDP receiver. There is 
not much more to say about it ...

We included some discussion on multihoming, n-casting, interface 
treatment and transport in RFC 5757, but I don't think we should repeat 
this - it is a very general Multicast/UDP discussion/observation. And 
5757 is referenced ;)

> o	Please note in our latest draft (draft-zuniga-multimob-smspmip-03, section 3.1) we clarify that multiple LMA-M's can be deployed to address the scalability issue.  So the key difference between s…

[Thomas=> From the Diff I see that you added:

"Note that there can multiple LMAs for unicast traffic (not shown in 
Figure 1) in a	
  given PMIPv6 domain. Similarly, more than one multicast dedicated LMA	
  can be deployed by the operator (not shown in Figure 1)."

This is just a claim.

[Thomas=>  As we have discussed several times (in meetings and on the 
list), the core problem with the "Dedicated LMA" solution is that it 
carries the wrong name. This is not an LMA as it has no MN-states, and 
it cannot perform handover management, which would be needed in the case 
of several LMAs serving different groups or MNs.

So this "Dedicated LMA" is actually only a Multicast DR (see Section 4.6 
in draft-ietf-multimob-pmipv6-base-solution-02.txt for a more general 
explanation) - and this has no notion of mobility and consequently 
cannot perform handovers. Thus it needs to be a centralized entity (free 
of handovers) within one PMIP domain.

IMHO, a future discussion on optimizing solutions should actually treat 
the field of "direct multicast access" as a whole, i.e. by considering a 
flat network access (like in draft-seijon), static tunnels like in your 
draft, or dynamic tunneling via AMT.

But that's another story.

> o	In the previous working group discussions, the terms "tunnel convergence" and "avalanche problem" were used interchangeably.  In this paragraph they now seem to have different meanings.  Also, sc…

[Thomas=> The terms "tunnel convergence problem" and "avalanche problem" 
have not been coined by us. Actually, they come from the MIPv4 area 
where you have this FoA etc.

The definition is very simple:

  o An entity that has very many outgoing tunnels (needs to send data to 
many tunnel interfaces) suffers from an "avalanche problem".
  o An entity that has very many incoming tunnel interfaces (needs to 
receive (possibly replicated) data from many tunnel interfaces) has to 
deal with a "tunnel convergence problem".

Aside from this, these are just names. However, one should use the names 
correctly, I suppose.

Best wishes,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 04 Jun 2010 14:53:39 +0300

Hi Behcet,

please see inline.

>    Inline.

[Thomas=> A rewording has been done (see previous mail).

> If that is the case then state the specific values for each, I don't think MLD has a million different messages.

[Thomas=> Unclear: if you (or any reader) wants to know about the 
details of MLD, you should read the corresponding document. There is no 
sense (and for good reasons no practice) to retell the content of 
previous RFCs. This would only be a source of misunderstandings.

> Why not? It is some useful detail.

[Thomas=> I don't see the point. This draft is about deployment and not 
implementation. Readers should get the idea of what is happening in the 
network, but should not be guided to re-implement IGMP or MLD.

However, this seems to turn into a matter of taste. Maybe we should 
follow a third party advise - Stig, what would you consider more 
appropriate: additional IGMP address tables or not?

> You should add one paragraph there on RFC 5135.

[Thomas=> As discussed: this sentence could only be "RFC 5135 plays no 
role here" ...

So I guess we are pretty much through ...

Cheers,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 4 Jun 2010 08:08:03 -0700 (PDT)

Hi Thomas,
  See inline.

>> For example Section 1 Paragraph 
> 3, you have not picked up and also not offering
>> any explaination 
> why.
>> In your new text you are making some statements
>> 
> that may not be correct.
>>
>
>> ?? Unclear to me: what 
> is incorrect?
>> (There was only a clarification
> added about 
> [behcet] The above paragraph needs to be rewritten to state that PMIPv6 does not 
> explicitly address multicast communication.
> It was a choice to design 
> multicast extension for PMIPv6 similar to MIPv6 but due to the 
> inefficiencies

> done (see previous mail).

[behcet]
You mean the current text? Current text in -02 is not correct and unfortunately not acceptable. MIPv6 based solution was proposed as you know. That solution was not worked out in the working group. What gives you freedom to speculate on that proposal without even referencing the draft?
Why are you not then speculating about 3 or 4 other proposals that have not been selected?

Sorry but this is totally inacceptable.

>
>> Section 5.1 and
>> 
> 5.2 have not picked up.
>>
>
>> 5.1/5.2 explain resp. 
> give reference to
>> the use of addressing in MLD. As
> 
>> of the messaging 
> (as
> If that is the 
> case then state the specific values for each, I don't think MLD has a million 
> different messages.
>

>[Thomas=> Unclear: if you (or any reader) 
details of MLD, you should read the corresponding 
> document. There is no 
sense (and for good reasons no practice) to retell the 
> content of 
previous RFCs. This would only be a source of 
> misunderstandings.

[behcet]
By the way, I read those RFCs. Thank you for your advice :-)!

However, I find it strange to give a whole RFC of 61 pages (3810) to figure out what the destination address will be. Plus 22 pages for 2710.

You created this problem you should correct it. See more below.

>
>> Regarding IPv4: This document 
> is
>> focused on PMIP*v6* - and there is an
> obvious 

> [Thomas=> I 
> don't see the point. This draft is about deployment and not 
implementation. 
> Readers should get the idea of what is happening in the 
network, but should 
> not be guided to re-implement IGMP or MLD.

[behcet]
Here you are contradicting yourself.

Why have Sections 5.1 and 5.2 then? It was you who included them, all I am asking is to make it more clear and complete.

> into a matter of taste. Maybe we should 
follow a third party advise - Stig, 
> what would you consider more 
appropriate: additional IGMP address tables or 
> not?

[behcet]
There is no third party here. We are a working group and WG has members. I posted my comments as a member of WG not as chair's comments.

I don't know what you are talking about? Can you explain?

>> ???
>> Section 4.4. explains the 
> analogy.
>
> Yes this helps.

role here" ...

[behcet]
Even that would be useful.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 04 Jun 2010 18:25:18 +0300

Hi Behcet,

only brief, as there is no progress:

> Sorry but this is totally inacceptable.

[Thomas => I guess it is time to re-approach reality:

  1. The text has never been incorrect, but supposedly hard to parse. In 
particular, MIPv6 bi-directional tunneling just does not work in PMIPv6 
- and has never been proposed in a document
  2. We had the text reworded (sent in a previous mail today) as:

"

... and I guess that's about it.

Cheers,

Thomas

--

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 7 Jun 2010 15:40:22 -0400

Hi Thomas,

Thanks for the prompt reply.  Below is my feedback (marked with ****
Akbar =>).

Sincerely,

Akbar

-- snip ---

[Thomas=>

Here is our replacement:

"

**** Akbar => Okay.

O.K., we added it.

**** Akbar => Thanks.

> o	MN2 moves to MAG2. However it is not clear where the arrow
"Movement to MAG2&  PMIP Binding Update" points to.

**** Akbar => Okay, but you may want to consider stretching the comment
to include the whole line as otherwise other readers may have the same
confusion as us.  But we leave that to your good judgment.

>
> - Section 3
> o	The paragraph talking about IPv4 ("These multicast deployment
considerations likewise apply for mobile nodes that operate with their
IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Support

**** Akbar => Okay.

>
> - Section 4.5
> o	This section on multi-homing is clear on the details of PMIPv6
operation over the multiple interfaces of an MN.  However, what was not
clear was how the multicast application would operate and react if it
got, for example, the same multicast group subscription over the
multiple interfaces?  Could you add some more explanatory description as
for example your description in section 3 "It will submit MLD Report and
Done messages, based on application triggers, using its link-local
source address and multicast destination addresses ..."]

**** Akbar => Okay, but perhaps at least you could add the reference to
RFC 5757 in this section.  I found it useful to read (and only went to
re-read it after your comment).  Again, I leave it to your good judgment
to make the final decision.

> o	Please note in our latest draft
(draft-zuniga-multimob-smspmip-03, section 3.1) we clarify that multiple
LMA-M's can be deployed to address the scalability issue.  So the key
difference between scenarios A and B is that in scenario B we separate
the unicast and multicast paths (and not in the number of LMAs)

This is just a claim.

**** Akbar => You are right that we have discussed it several times.
Our proposal is not a simply a Multicast DR (as you also acknowledge in
your Appendix C).  We have mentioned several times that we will have
some PMIP impacts to provide us mobility multicast management.  We will
provide these details in our next draft.

> o	In the previous working group discussions, the terms "tunnel
convergence" and "avalanche problem" were used interchangeably.  In this
paragraph they now seem to have different meanings.  Also, scenario B
does not replicate streams at the LMA.

correctly, I suppose.

**** Akbar => Okay.

--- snip ---

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Jun 2010 10:27:55 -0700

Thomas C. Schmidt wrote:
>>> [behcet] please add several sentences on why proxy approach is better 
>>> (as has
>>> been discussed on ML).
>>>
>> You mean the current text? Current text in -02 is not correct and 
>> unfortunately not acceptable. MIPv6 based solution was proposed as you 
>> know. That solution was not worked out in the working group. What 
>> gives you freedom to speculate on that proposal without even 
>> referencing the draft?

This text looks OK to me, but I may be unaware of some of the MIPv6
considerations.

The main thing is to explain why this basic approach is needed in
PMIPv6. Discussion of other solutions should be minimal, only enough to
explain why this was the choice made.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Jun 2010 10:44:16 -0700

>   See inline.
[...]
> I don't know what you are talking about? Can you explain?

I would, frankly speaking, say that section 5 is pretty useless. Is
there any value in this section? I think all the reader needs to know
is that MLD/IGMP is encapsulated and sent as normal. So maybe remove it?

One should not include more details from other RFCs than is needed to
explain the idea at hand. So talking about exact MLD/IGMP message
formats and addressing should be avoided if it behaves exactly as
normal.

Otherwise one may start to wonder whether it behaves differently in this
specific context.

Just my personal opinion,

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 13 Jun 2010 21:21:32 -0700 (PDT)

Hi Thomas,
Here are my proposals:
1. Section 1. Par. 2:

With these entities in place, the mobile node looses transparent end-to-end connectivity to the static Internet, and in the particular
case of multicast communication, group membership management as
   signaled by the Multicast Listener Discovery protocol [RFC3810],
   [RFC2710] requires dedicated treatment at the network side.

Section 1 Paragraph 3, 
here only state the pros of the proxy approach like avoiding avalanche of packet duplication at the LMA and subsequent delivery from LMA to MAG.

2. IPv4 support section, 
OK, no need for NAT text.
RFC 5135 requires NAT boxes at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe it is out of scope. You may wish to mention something like this though.

3. Section 5.1 
destination address: FF02::1

and 
5.2 destination address FF02::16

Add Section 5.3 Multicast Data
IPv6: outer LMAA - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF

IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- 232.255.255.255

Appendix C. Remove

Appendix B. May be keep, removing is also OK.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 14 Jun 2010 13:02:07 +0200

Hi Stig,

On 08.06.2010 19:44, Stig Venaas wrote:
>>> If that is the case then state the specific values for each, I don't
>>> think MLD has a million different messages.
>>>
>>
>> However, I find it strange to give a whole RFC of 61 pages (3810) to
>> figure out what the destination address will be. Plus 22 pages for 2710.
>>
>> Why have Sections 5.1 and 5.2 then? It was you who included them, all
>> I am asking is to make it more clear and complete.
>>
>> There is no third party here. We are a working group and WG has
>> members. I posted my comments as a member of WG not as chair's comments.
>>

The reason for this section actually is Jouni Korhonen who asked for 
explicitly laying out MLD addressing/encapsulation. I perfectly agree 
with you that there is nothing new or surprising here. Still with Jouni 
asking for it, there seemed to be a need for making this more visible ...

> Otherwise one may start to wonder whether it behaves differently in this

Maybe we should add a sentence that this is just a recap of the standard 
behavior?

Cheers,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 14 Jun 2010 13:39:09 +0200

Hi Behcet,

> here only state the pros of the proxy approach like avoiding avalanche of packet duplication at the LMA and subsequent delivery from LMA to MAG.

Sorry, I don't agree: this section is not on how to avoid avalanches or 
other performance degradations, but on the requirement of defining a 
solution at all.
As Stig wrote in a previous mail, it is very important to make clear why 
an explicit multicast solution is needed in PMIPv6 - this is because the 
"MIPv6 minimal solution", namely bi-directional tunneling, does not work 
in PMIP. This should be clearly stated ... and after several discussions 
and revisions, we should have arrived at a proper formulation (see mail 
to Pierrick), I believe.

> RFC 5135 requires NAT boxes at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe it is out of scope. You may wish to mention something like this though.

RFC 5135 does not require a deployment of NAT boxes! - Section 3 of RFC 
5135 just gives background scenarios on common use of NAT boxes in 
access networks - but this is a scenario for cable modem, completely 
orthogonal to a PMIP deployment.

> 5.2 destination address FF02::16

This is not the full truth: there are different queries and reports 
defined in MLD ... re-pointing to the dialog with Stig: it certainly 
does not make sense to expand the MLD recap ... if it is helpful to 
readers, we should add a warning like "this is just a recap" ... if not, 
we should remove it.

> IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- 232.255.255.255

Multicast data is not a problem here, as routing is explained in detail 
in sections 3 and 4. The somewhat intricate part is the signaling - 
that's why Jouni asked for clarification.

> Appendix B. May be keep, removing is also OK.

I guess we already agreed that the Appendices should be judged according 
to AD review - we can remove any of those if desired, but we should keep 
them for the reviews so that they remain accessible for evaluation.

For the general progress:

  If there are no more comments showing up, we would update the version 
2 of this document and include the various feedbacks from WG last call 
this evening and await further actions ;)

Best regards,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 14 Jun 2010 08:01:11 -0700 (PDT)

Hi Thomas,

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Cc: Behcet Sarikaya <[email-masked]>; [email-masked]
> Sent: Mon, June 14, 2010 6:39:09 AM

On 14.06.2010 06:21, Behcet Sarikaya wrote:

> 
> Section 1 Paragraph 3,
> here only state the pros of the proxy approach 
> like avoiding avalanche of packet duplication at the LMA and subsequent delivery 
> from LMA to MAG.

> Sorry, I don't agree: this section is not on how to 
> avoid avalanches or other performance degradations, but on the requirement of 
> defining a solution at all.

[behcet] Did I say that it is about avoiding avalanches?
I don't know on what you are basing your biased statements :-).

> As Stig wrote in a previous mail, it is very 
> important to make clear why an explicit multicast solution is needed in PMIPv6 - 
> this is because the "MIPv6 minimal solution", namely bi-directional tunneling, 
> does not work in PMIP. 

[behcet] Why not? How do you know?

> This should be clearly stated ... and after several 
> discussions and revisions, we should have arrived at a proper formulation (see 
> mail to Pierrick), 

> I believe.

[behcet] No I don't.

> 2. IPv4 support 
> section,
> RFC 5135 requires NAT boxes 
> at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe 
> it is out of scope. You may wish to mention something like this though.
> 
> 

> RFC 5135 does not require a deployment of NAT boxes! - 

[behcet] What are you talking about?

> Section 3 of RFC 
> 5135 just gives background scenarios on common use of NAT boxes in access 
> networks - but this is a scenario for cable modem, completely orthogonal to a 
> PMIP deployment.

[behcet] May be so.

> This is not the full truth: there are different queries and 
> reports defined in MLD ... re-pointing to the dialog with Stig: it certainly 
> does not make sense to expand the MLD recap ... if it is helpful to readers, we 
> should add a warning like "this is just a recap" ... if not, we should remove 
> it.

[behcet] Yes, MLD allows the destination address to be MAG or LMA address as well but I don't think it is an important "recap" or what ever. If there are other important values please feel free to add.

> IPv6: outer LMAA 
> - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF
> 
> 

> Multicast data is not a problem here, as routing 
> is explained in detail in sections 3 and 4. The somewhat intricate part is the 
> signaling - that's why Jouni asked for clarification.

[behcet] I have not seen this mail on the list but my reaction is please go ahead and make the required changes. Be positive.

[behcet] The point here is that unlike the authors, I went ahead and read the standards and found these values and now proposing them.

> Appendix C. 
> Remove

> to AD review - we can remove any of those if desired, but we should keep them 
> for the reviews so that they remain accessible for evaluation.

[behcet] There are steps. Now we are at the WGLC step. You need to pass this step before going to the next.

As for Annex C, it does not add any value to the draft and it has a reference to an individual draft. It is not a complete analysis of all possible solution approaches.
Should I say more?

> For 
> the general progress:

> If there are no more comments showing up, we would 
> update the version 2 of this document and include the various feedbacks from WG 
> last call this evening and await further actions ;)

[behcet] I don't think the draft authors are to judge on such things. Please concentrate on each step one by one.

[behcet] 
Overall, the authors should be open to make positive improvements on their draft so that WGLC can progress with success.

Regards,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 14 Jun 2010 23:14:49 +0200

Hi Behcet,

On 14.06.2010 17:01, Behcet Sarikaya wrote:
>> To: Behcet Sarikaya<[email-masked]>
>> Cc: Behcet Sarikaya<[email-masked]>; [email-masked]

[Thomas => Well, as you still can see above, you wrote "state the pros 
of the proxy approach like avoiding avalanche" ... so I just thought you 
were talking about "avoiding avalanche" ...

> [behcet] Why not? How do you know?

[thomas => Well, the issue has been debated already when setting up the 
charter ... and thereafter several times on the list and in meetings. 
The core argument is clearly given in this paragraph - there is no 
counter-argument on the table. So I just don't see room for questioning 
the statement.

However, if you actually do have a counter-argument, you should release 
it right now.

>> discussions and revisions, we should have arrived at a proper formulation (see

[thomas => It seems you are the only one. As said, this has been under 
discussion several times.

> [behcet] Yes, MLD allows the destination address to be MAG or LMA address as well but I don't think it is an important "recap" or what ever. If there are other important values please feel free to…

[thomas => I have not seen any mobility-related entities being mentioned 
in any of the MLD RFCs. My pointer was on different query/report types 
as defined in the MLD specs.

> [behcet] I have not seen this mail on the list but my reaction is please go ahead and make the required changes. Be positive.

[thomas => So we did: following the argument of Jouni, we added section 5.

     The status of this section is now as follows:
     * Jouni requested it as is
     * You proposed to copy significant parts from the MLD and IGMP 
specs into it
     * Stig said, the whole section could be removed as it is already 
defined elsewhere and could irritate people
     * We proposed a compromise in adding a statement that clarifies 
that there are no new definitions here, but just the translation of 
(encapsulated) MLD signaling into PMIPv6 language.

> [behcet] The point here is that unlike the authors, I went ahead and read the standards and found these values and now proposing them.

[thomas => I don't understand - but it's good to care for mcast 
addresses: btw - we are not restricted to SSM ...

> [behcet] There are steps. Now we are at the WGLC step. You need to pass this step before going to the next.

[thomas => I'm not sure what you are saying. In WGLC we have received 
quite a number of good comments, have exchanged a set of additional 
arguments, and are about to improve the document accordingly. Your 
comments, as they are not on formal procedures but on content, must be 
treated as individual comments. And if your suggestions are obviously 
incorrect (as all the addresses above), then it is the responsibility of 
the authors (and the WG) to prevent failures from sneaking into the 
document.

I guess that's what you wanted to say, right?

> Overall, the authors should be open to make positive improvements on their draft so that WGLC can progress with success.

[thomas => Exactly! Authors need to take up comments that lead to 
*positive improvements* and update their draft so that WGLC can progress 
with success. That's what we're saying and that's what we are doing. To 
be precise, I was proposing to do this right now.

Best regards,

Thomas

--