Re: [multimob] [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt

Hi William,

Thanks a lot for the very detailed review. Please see some comments
inline below.

On Tue, 2013-08-13 at 18:52 -0400, William Atwood wrote:
> Adrian, authors,
> 
> As a member of the PIM Working Group, I have read the Internet Draft
> draft-ietf-multimob-pmipv6-ropt.  It is very clear.  The solution is
> well explained; I had no difficulty following what the authors were
> trying to do.  I see no issues that would trouble the PIM WG.
> 
> I had one hiccup---I initially could not understand why there was any
> reference at all to IGMP in a document describing an IPv6 mobility
> protocol.  I finally came to understand when I read Section 8 more
> carefully.  I believe that a simple addition to the information in
> section 1 (about IGMP and MLD) will cure this.
> 
> The following are my suggestions for improvement.
> 
> Page 3, para 2.  Add a sentence at the end:  "Although the interaction
> of a host in a Proxy Mobile IPv6 environment will be with MLD, there are
> certain situations where IGMP may be used by the proxy.  See Section 8
> for details."
> 
> (You may wish to re-word this to be more precise.  You may wish to point
> out specifically in Section 8 the precise area of applicability of RFC
> 5844, rather than relying on the reader to read the RFC to discover
> this.)  (I believe that it has something to do with the path between the
> proxy and the other architectural components being confined to IPv4, but
> I leave this to your expertise to find the right wording.)

[Authors] OK, we'll add some clarifying text to make more clear why the
document deals with IGMP and MLD. Thanks for your suggested text.
RFC5844 adds the following to Proxy Mobile IPv6: i) support for IPv4
home address assignment to mobile nodes, and ii) support for IPv4
transport between MAG and LMA entities. In order to address your comment
we propose to modify a couple of paragraph in Section 1 in the -08
version (please note that there are also some additional changes due to
other comments received during the IESG review):

  "A base solution to support both IPv4 and IPv6 multicast listener
   mobility in a PMIPv6 domain is specified in [RFC6224], which
   describes deployment options without modifying mobility and multicast
   protocol standards.  PMIPv6 allows a MAG to establish multiple PMIPv6
   tunnels with different LMAs, e.g., up to one per MN.  In the presence
   of multicast traffic, multiple instances of the same traffic can
   converge to the same MAG.  Hence, when IP multicasting is applied
   into PMIPv6, it leads to redundant traffic at a MAG.  This is the
   tunnel convergence problem.

   In order to address this issue, this document proposes an
   experimental solution, consisting of two complementary enhancements:
   multicast anchor and direct routing.  The former enhancements makes
   use of a multicast tree mobility anchor (MTMA) as the topological
   anchor point for remotely delivering multicast traffic, while the
   latter enhancement uses direct routing taking advantage of local
   multicast source availability, allowing a MAG to connect directly to
   a multicast router for simple access to local content.  Neither of
   the two schemes has any impact on the MN to support IPv4 and IPv6
   multicast listener mobility, nor on the wider Internet, as they only
   affect the PMIPv6 domains where they are deployed.  Although
   references to "MLD proxy" are used in the document, it should be
   understood to also include "IGMP/MLD proxy" functionality (see
   Section 8 for details).  The status of this proposal is Experimental.
   The status of this proposal may be reconsidered in the future, once
   more implementation feedback and deployment experience is gathered,
   reporting on the performance of the two proposed schemes as well as
   operational feedback on scheme selection."

> 
> Para 3, lines 7-8.  "it leads to" -> "it may lead to"  (I believe that
> redundant traffic will only occur if there are two or more MNs
> subscribed to the same multicast group.)

[Authors] Agree, good point. Fixed in -08.

> 
> Para 4, line 1.  "former enhancements" -> "first enhancement"  ("former"
> and "latter" are only used after the individual enhancements have been
> named/described.  In this case, they have not yet been described, so
> "former" and "latter" are inappropriate.)

[Authors] OK, fixed in -08.

> 
> Line 6.  "latter" -> "second"

[Authors] OK, fixed in -08.

> 
> Page 4, para 4, line 1.  "such" -> "the"

[Authors] OK, fixed in -08.

> 
> Para 5, line 4.  "associated to" -> "associated with"  (This change
> needs to be made _throughout_ the document.)

[Authors] OK, fixed in -08.

> 
> Page 5, Section 3, para 1, line 4.  "each one" -> "each"  ("each"
> implies "one"; it is not necessary to "double up" here.)

[Authors] OK, fixed in -08.

> 
> Section 3.1, para 2, line 5.  "a MLD" -> "an MLD".  (The form of the
> indefinite article is based on the _sound_ of what follows.  Since "MLD"
> is pronounced "em-el-dee", the initial sound is the vowel "e", so the
> article is spelled "an".  In contrast, earlier in the same line, the
> acronym "MAG" is pronounced "mag", and the initial sound is "m", so the
> indefinite article is spelled "a".)  (This correction needs to be made
> throughout the document, wherever it is wrong.)

[Authors] OK, fixed in -08.

> 
> Page 10, para 1, line 6.  "which" -> "that"  (See discussion of
> which/that at the end of this email.)

[Authors] OK, fixed in -08.

> 
> Para 3, line 4.  "temporariliy" -> "temporarily"

[Authors] OK, fixed in -08.

> 
> Page 11, para 1, line 11.  "which" -> "that"

[Authors] OK, fixed in -08.

> 
> Page 16, section 8, para 1, line 7.  "i.e.  IPv6" -> "i.e., IPv6"  (Add
> comma, delete space.  See discussion of "i.e." at the end of this email.)

[Authors] OK, fixed in -08.

> 
> Page 20, Appendix A.1, para 1, line 1.  "approach basically" -> "approach"

[Authors] OK, fixed in -08.

> 
> Appendix A.2, para 1, line 1.  "approach basically" -> "approach"

[Authors] OK, fixed in -08.

> 
> Line 3.  "which" -> "that"

[Authors] OK, fixed in -08.

> 
> Page 21, para 1, line 1.  "The Figure" -> "Figure"

[Authors] OK, fixed in -08.

> 
> Page 22, para 1, line 1.  "traffic which" -> "traffic, which"  (See
> discussion of which/that at the end of this email.)

[Authors] OK, fixed in -08.

> 
> Line 4.  "are being served" -> "are served"

[Authors] OK, fixed in -08.

> 
> Appendix A.3, para 1, line 3.  "which" -> "that"

[Authors] OK, fixed in -08.

> 
> Appendix A.4, para 1, line 1.  "which" -> "that"

[Authors] OK, fixed in -08.

> 
> Line 5.  "The Figure" -> "Figure"

[Authors] OK, fixed in -08.

> 
> NOTE on use of "which" and "that".  "that" is used when the phrase
> following it is _required_ if we are going to be able to completely
> identify what is being talked about, while "which" is used to introduce
> supplementary information.  Some examples:
> 
> 1) If there are three houses on the street, and only one of them is at
> the corner, then you say:
> "The house that is on the corner needs to be painted."
> 2) If there are three houses on the street, and only one of them is
> yellow, then you say:
> "The yellow house, which needs to be painted, is for sale."
> 
> In the first case, the observer cannot identify the exact house until
> its position is given.  In the second case, the house is completely
> identified by its colour, and the information about the need to be
> painted is supplementary information.  This information is set off with
> commas, and introduced with "which".
> 
> NOTES on the use of "i.e." and "e.g.".
> "i.e." is an abbreviation for "id est", a Latin phrase meaning "that
> is".  As such, it should be punctuated as if it were the full phrase.
> Unless there is a parenthesis on one side or the other, it is always
> preceded by a comma and a space, and always followed by a comma and a space.
> "e.g." is an abbreviation for "exempli gratia", a Latin phrase meaning
> "for example".  It should also be punctuated as if the full phrase were
> present.  Unless there is a parenthesis on one side or the other, it is
> always preceded by a comma and a space, and always followed by a comma
> and a space.

[Authors] Thanks a lot for these clarifications.

Again, thanks for the great comments.

Kind Regards,

Carlos

> 
> 
> 
> 
>   Bill
> 
> 
> On 17/07/2013 6:39 PM, Adrian Farrel wrote:
> > Hi PIM working group,
> > 
> > Can I ask for some volunteers to look at "Multicast Mobility Routing
> > Optimizations for Proxy Mobile IPv6"
> > https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt/
> > 
> > This document made it through IETF last call and arrived at the IESG without
> > having been shown to the PIM working group. I have deferred the document to give
> > a little time for me to get your input. Please send comments to me direct or
> > copying the IESG and the draft authors. 
> > 
> > Thanks,
> > Adrian
> > 
> > _______________________________________________
> > pim mailing list
> > pim@ietf.org
> > https://www.ietf.org/mailman/listinfo/pim
> > 
> 