From sfigueiredo@av.it.pt Tue Aug 6 13:34:36 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5FC21E809B for ; Tue, 6 Aug 2013 13:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVQEugcIHS3A for ; Tue, 6 Aug 2013 13:34:31 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3816B21E809E for ; Tue, 6 Aug 2013 13:34:27 -0700 (PDT) Received: from [217.129.27.134] (account sfigueiredo@av.it.pt HELO [192.168.2.104]) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 70474317 for multimob@ietf.org; Tue, 06 Aug 2013 21:34:25 +0100 Message-ID: <52015DD1.8080204@av.it.pt> Date: Tue, 06 Aug 2013 21:34:25 +0100 From: =?ISO-8859-1?Q?S=E9rgio?= User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: multimob@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090705090900010901090408" Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:34:36 -0000 This is a multi-part message in MIME format. --------------090705090900010901090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear all, I went through the I-D and it appears to me it is in a sufficiently mature state, thus I support its advance as Experimental. Besides, I have the following editorial suggestions: ### Section 1 ### 1) The first sentence repeats the use of "describe" verb. I propose improving it to: "The base solution for providing continuous multicast service delivery in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]." 2) "referred to"" --> "referring to" / "regarding" / "which refer to"" 3) In the motivation, two actions are referred for minimizing the "gap" in content reception. The buffering at the pMAG, which as stated could be achieved by adapting RFC5949, and the rapid transfer of subscription information to the new MAG. For the sake of completeness, should it also be indicated that this could be achieved by adapting RFC4067? E.g. as proposed in draft-vonhugo-multimob-dmm-context-00 ? 5) The solution must optimise the handover performance respect to the" --> "with respect to the (...)" 6) Regarding the sentence: "The solution should minimize the number and extent of additional support required in the network, aiming at an easier deployment." Should the meaning of "additional support" be further explained? Best regards, Sérgio On 07/15/2013 05:34 PM, Behcet Sarikaya wrote: > Folks, > > This message starts a four week > Multimob Working Group last call > on advancing: > Title : PMIPv6 multicast handover optimization by the > Subscription Information Acquisition through the LMA (SIAL) > Author(s) : Luis M. Contreras Carlos J. Bernardos > Ignacio Soto Filename : > draft-ietf-multimob-handover-optimization-03.txt Pages > : 37 Date : 2013-07-08 > > as Experimental. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on August 9, 2013. > Regards, > Behcet > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --------------090705090900010901090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I went through the I-D and it appears to me it is in a sufficiently mature state, thus I support its advance as Experimental. Besides, I have the following editorial suggestions:

### Section 1 ###

1) The first sentence repeats the use of "describe" verb. I propose improving it to:
"The base solution for providing continuous multicast service delivery in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]."

2) "referred to"" --> "referring to" / "regarding" / "which refer to""

3) In the motivation, two actions are referred for minimizing the "gap" in content reception. The buffering at the pMAG, which as stated could be achieved by adapting RFC5949, and the rapid transfer of subscription information to the new MAG. For the sake of completeness, should it also be indicated that this could be achieved by adapting RFC4067? E.g. as proposed in

draft-vonhugo-multimob-dmm-context-00

?

5) The solution must optimise the handover performance respect to the" --> "with respect to the (...)"

6) Regarding the sentence: "The solution should minimize the number and extent of additional support required in the network, aiming at an easier deployment."
Should the meaning of "additional support" be further explained?

Best regards,
Sérgio



On 07/15/2013 05:34 PM, Behcet Sarikaya wrote:
Folks,

This message starts a four week 
Multimob Working Group last call
on advancing:
      Title           : PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)
        Author(s)       : Luis M. Contreras                          Carlos J. Bernardos                          Ignacio Soto        Filename        : draft-ietf-multimob-handover-optimization-03.txt        Pages           : 37        Date            : 2013-07-08

as Experimental.  Substantive comments and statements of support
for advancing this document should be directed to the mailing list.
Editorial suggestions can be sent to the authors.  This last call will
end on August 9, 2013.
Regards,
Behcet


_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--------------090705090900010901090408-- From lmcm@tid.es Thu Aug 8 15:17:58 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A3B11E823E for ; Thu, 8 Aug 2013 15:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.648 X-Spam-Level: X-Spam-Status: No, score=-4.648 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDmqwy1XUm3t for ; Thu, 8 Aug 2013 15:17:54 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6BB11E8238 for ; Thu, 8 Aug 2013 15:17:53 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MR800H8GGLQ6F@tid.hi.inet> for multimob@ietf.org; Fri, 09 Aug 2013 00:17:50 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id D4.93.24502.E0914025; Fri, 09 Aug 2013 00:17:50 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MR800H8BGLP6F@tid.hi.inet> for multimob@ietf.org; Fri, 09 Aug 2013 00:17:50 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.81]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Fri, 09 Aug 2013 00:17:49 +0200 Date: Thu, 08 Aug 2013 22:17:48 +0000 From: LUIS MIGUEL CONTRERAS MURILLO In-reply-to: <52015DD1.8080204@av.it.pt> X-Originating-IP: [10.95.64.115] To: =?iso-8859-1?Q?S=E9rgio?= , "multimob@ietf.org" Message-id: <823234EF5C7C334998D973D822FF801B44FD511F@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_RCeHWGEXzg0AkiFyjFy8nw)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: [multimob] draft-ietf-multimob-handover-optimization-03 Thread-index: AQHOgXj9ao7D4m0ZIkGHk1UOXHDq15mIpDSAgANiPDA= X-AuditID: 0a5f4068-b7fab8e000005fb6-4c-5204190ec2ae X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhinfg0uWTZAkymH+Iz2LGxz4WB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBl7P78kLngfmTFianb2BsYj/p0MXJySAiYSPyafIoNwhaTuHBv PZDNxSEksJFRouHybFYI5zejxKbL8xghnGmMEu3vFrGCtLAIqEpsmrkcrJ1NwFBi1s5JYHFh AReJn713GUFsTgENiXmX7zJBrFCQ+HPuMUsXIweHiEC8ROvlcJAws0CaxKRZe9lBbF4Bb4m5 D/ewQtiCEj8m32OBqMmVeLLjPBuELS4x59dEsBpGAVmJledPg60SEXCV6JixjxnCtpLYtvcR 1GcCEkv2nGeGsEUlXj7+B9YrJFAg8a9pL9sERrFZSNbNQrJuFpJ1ELaexI2pU6Di2hLLFr5m hrB1JWb8O8SCLL6AkX0Vo1hxUlFmekZJbmJmTrqBoV5Gpl5mXmrJJkZI3GXsYFy+U+UQowAH oxIP781DzEFCrIllxZW5hxglOJiVRHhfZAGFeFMSK6tSi/Lji0pzUosPMTJxcEo1MK5f0GiT 72/e3Ktz+bFcc+NRDjM3hm8p/wMWz99iUhKddKt6h8vVBuZHR2rPH1X6kuNRyro+bL+DbcYx hge3mYNLuirylP1yl3Q7+M/q6W/d9KpkM3t3o8T+5qmZe99pfWTe8TgkwuBslgl3nbN9bUzA +bx+04blWorfI10bt858++YqZ2u0EktxRqKhFnNRcSIAO2KeIZkCAAA= References: <52015DD1.8080204@av.it.pt> Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:17:58 -0000 --Boundary_(ID_RCeHWGEXzg0AkiFyjFy8nw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Hi S=E9rgio, Thanks a lot for your review and your suggestions. We will produce a new ve= rsion covering all the points raised during the WGLC. Best regards, Luis De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre = de S=E9rgio Enviado el: martes, 06 de agosto de 2013 22:34 Para: multimob@ietf.org Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-03 Dear all, I went through the I-D and it appears to me it is in a sufficiently mature = state, thus I support its advance as Experimental. Besides, I have the foll= owing editorial suggestions: ### Section 1 ### 1) The first sentence repeats the use of "describe" verb. I propose improvi= ng it to: "The base solution for providing continuous multicast service delivery in P= roxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]." 2) "referred to"" --> "referring to" / "regarding" / "which refer to"" 3) In the motivation, two actions are referred for minimizing the "gap" in = content reception. The buffering at the pMAG, which as stated could be achi= eved by adapting RFC5949, and the rapid transfer of subscription informatio= n to the new MAG. For the sake of completeness, should it also be indicated= that this could be achieved by adapting RFC4067? E.g. as proposed in draft-vonhugo-multimob-dmm-context-00 ? 5) The solution must optimise the handover performance respect to the" --> = "with respect to the (...)" 6) Regarding the sentence: "The solution should minimize the number and ext= ent of additional support required in the network, aiming at an easier depl= oyment." Should the meaning of "additional support" be further explained? Best regards, S=E9rgio On 07/15/2013 05:34 PM, Behcet Sarikaya wrote: Folks, This message starts a four week Multimob Working Group last call on advancing: Title : PMIPv6 multicast handover optimization by the Subsc= ription Information Acquisition through the LMA (SIAL) Author(s) : Luis M. Contreras Carlos= J. Bernardos Ignacio Soto Filename = : draft-ietf-multimob-handover-optimization-03.txt Pages := 37 Date : 2013-07-08 as Experimental. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on August 9, 2013. Regards, Behcet _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_RCeHWGEXzg0AkiFyjFy8nw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Hi S=E9rgio,

 

Thanks a lot for your r= eview and your suggestions. We will produce a new version covering all the = points raised during the WGLC.

 

Best regards,

 

Luis

 

De: multimob-bounces@ietf.o= rg [mailto:multimob-bounces@ietf.org] En nombre de S=E9rgio
Enviado el: martes, 06 de agosto de 2013 22:34
Para: multimob@ietf.org
Asunto: Re: [multimob] draft-ietf-multimob-handover-optimization-03<= /span>

 

Dear all,

I went through the I-D and it appears to me it is in a sufficiently mature = state, thus I support its advance as Experimental. Besides, I have the foll= owing editorial suggestions:

### Section 1 ###

1) The first sentence repeats the use of "describe" verb. I propo= se improving it to:
"The base solution for providing continuous multicast service delivery= in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]."

2) "referred to"" --> "referring to" / "re= garding" / "which refer to""

3) In the motivation, two actions are referred for minimizing the "gap= " in content reception. The buffering at the pMAG, which as stated cou= ld be achieved by adapting RFC5949, and the rapid transfer of subscription = information to the new MAG. For the sake of completeness, should it also be indicated that this could be achieved by a= dapting RFC4067? E.g. as proposed in <= /span>

       =  

draft-vonhugo-multimob-dmm-context-00

 

      ?

5) The solution must optimise the handover performance respect to the"= --> "with respect to the (...)"

6) Regarding the sentence: "The solution should minimize the number an= d extent of additional support required in the network, aiming at an easier= deployment."
Should the meaning of "additional support" be further explained?<= br>
Best regards,
S=E9rgio



On 07/15/2013 05:34 PM, Behcet Sarikaya wrote:

Folks,
 
This message starts a four week 
Multimob Working Group last call
on advancing:

      Title       &nbs= p;   : PMIPv6 multicast handover optimization by the Subscription Info= rmation Acquisition through the LMA (SIAL)
        Author(s)       : Luis M. Contre= ras                    &n= bsp;     Carlos J. Bernardos          &n= bsp;               Ignacio Soto  &n= bsp;     Filename        : draft-ietf-multimo= b-handover-optimization-03.txt        Pages   &nbs= p;       : 37        Date     =        : 2013-07-08

 

as Experimental.  Substantive comments and statements of support<=
/pre>

for advancing this document should be directed to the mailing list.

Editorial suggestions can be sent to the authors.  This last call=
 will


end on August 9, 2013.


Regards,


Behcet






_______________________________________________
multimob mailing list
multimob@ietf.org
https://www=
.ietf.org/mailman/listinfo/multimob

 



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_RCeHWGEXzg0AkiFyjFy8nw)-- From william.atwood@concordia.ca Tue Aug 13 15:52:31 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C652021E8188; Tue, 13 Aug 2013 15:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPnx+JNYqERa; Tue, 13 Aug 2013 15:52:27 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8821E8180; Tue, 13 Aug 2013 15:52:22 -0700 (PDT) Received: from [127.0.0.1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id r7DMqHls020604; Tue, 13 Aug 2013 18:52:17 -0400 Message-ID: <520AB8B1.1000709@concordia.ca> Date: Tue, 13 Aug 2013 18:52:33 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: adrian@olddog.co.uk, pim@ietf.org, IESG , draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org, multimob@ietf.org References: <00ed01ce833e$8de48da0$a9ada8e0$@olddog.co.uk> In-Reply-To: <00ed01ce833e$8de48da0$a9ada8e0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2013/08/13 18:52:19 EDT Subject: Re: [multimob] [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:52:32 -0000 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.) 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.) 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.) Line 6. "latter" -> "second" Page 4, para 4, line 1. "such" -> "the" Para 5, line 4. "associated to" -> "associated with" (This change needs to be made _throughout_ the document.) Page 5, Section 3, para 1, line 4. "each one" -> "each" ("each" implies "one"; it is not necessary to "double up" here.) 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.) Page 10, para 1, line 6. "which" -> "that" (See discussion of which/that at the end of this email.) Para 3, line 4. "temporariliy" -> "temporarily" Page 11, para 1, line 11. "which" -> "that" 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.) Page 20, Appendix A.1, para 1, line 1. "approach basically" -> "approach" Appendix A.2, para 1, line 1. "approach basically" -> "approach" Line 3. "which" -> "that" Page 21, para 1, line 1. "The Figure" -> "Figure" Page 22, para 1, line 1. "traffic which" -> "traffic, which" (See discussion of which/that at the end of this email.) Line 4. "are being served" -> "are served" Appendix A.3, para 1, line 3. "which" -> "that" Appendix A.4, para 1, line 1. "which" -> "that" Line 5. "The Figure" -> "Figure" 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. 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 > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From cjbc@it.uc3m.es Tue Aug 13 20:12:21 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B3B11E8105; Tue, 13 Aug 2013 20:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTOkgvWxdRlh; Tue, 13 Aug 2013 20:12:17 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id A97EB11E8111; Tue, 13 Aug 2013 20:12:16 -0700 (PDT) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4AF6BBFB0E3; Wed, 14 Aug 2013 05:12:14 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [192.168.0.101] (modemcable143.234-81-70.mc.videotron.ca [70.81.234.143]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id EF7D5C35EB2; Wed, 14 Aug 2013 05:12:12 +0200 (CEST) Message-ID: <1376449931.4168.52.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: William Atwood Date: Wed, 14 Aug 2013 05:12:11 +0200 In-Reply-To: <520AB8B1.1000709@concordia.ca> References: <00ed01ce833e$8de48da0$a9ada8e0$@olddog.co.uk> <520AB8B1.1000709@concordia.ca> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20080.004 Cc: adrian@olddog.co.uk, multimob@ietf.org, IESG , pim@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org Subject: Re: [multimob] [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 03:12:22 -0000 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 > > > From sarikaya2012@gmail.com Wed Aug 14 07:56:56 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EF721F9A40; Wed, 14 Aug 2013 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xngFUv7PjVeE; Wed, 14 Aug 2013 07:56:48 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 89D3221F9C7D; Wed, 14 Aug 2013 07:56:44 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ev20so6745799lab.8 for ; Wed, 14 Aug 2013 07:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/iaz3wgARuxI11cvS8APfCEd1NAqCSsKuoyROgeKXBE=; b=Zexj6Ek7xZzxy8SXMbJTtStbkQ8unI6a925KoHXXaZWWQl/nvUV9XpXsLab6TlNWiq bl0+bF+77cpf1QJOVNttBTvwNKJXGGhVRpKgIKsc8USPGaRHcYmh4N3qS2H7nRGWRKA9 9R594fCxCpeObTFSe+8jOnQnUX9M/GCRI3bwMmhvQiagPmqIDYCOB65kjzyCKXhZ4+Sw P8XMBGPervXmkktwrRHpa+ZjNSUaWVQZFInqI6pvzsBxibcDXpJrZNsnQ/XAcwuIpUdd E6FnAuOHB1yp+ow5TMUQnYKUoK2FUePJBN03BqWwlZVmxDMHLxPB8Pwsb7qA9y8Qe9iF UggA== MIME-Version: 1.0 X-Received: by 10.112.33.231 with SMTP id u7mr759318lbi.49.1376492203239; Wed, 14 Aug 2013 07:56:43 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Wed, 14 Aug 2013 07:56:43 -0700 (PDT) In-Reply-To: <520AB8B1.1000709@concordia.ca> References: <00ed01ce833e$8de48da0$a9ada8e0$@olddog.co.uk> <520AB8B1.1000709@concordia.ca> Date: Wed, 14 Aug 2013 09:56:43 -0500 Message-ID: From: Behcet Sarikaya To: William Atwood Content-Type: multipart/alternative; boundary=14dae947376bcf6ea004e3e990ac Cc: Adrian Farrel , "multimob@ietf.org" , IESG , pim@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org Subject: Re: [multimob] [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:56:56 -0000 --14dae947376bcf6ea004e3e990ac Content-Type: text/plain; charset=ISO-8859-1 Hi Bill, Thanks for your review. On Tue, Aug 13, 2013 at 5:52 PM, William Atwood wrote: > Adrian, authors, > > As a member of the PIM Working Group, Multimob too :-) In fact we have been soliciting reviews from our WG members since long time. 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.) > > 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.) > > 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.) > > Line 6. "latter" -> "second" > > Page 4, para 4, line 1. "such" -> "the" > > Para 5, line 4. "associated to" -> "associated with" (This change > needs to be made _throughout_ the document.) > > Page 5, Section 3, para 1, line 4. "each one" -> "each" ("each" > implies "one"; it is not necessary to "double up" here.) > > 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.) > > Page 10, para 1, line 6. "which" -> "that" (See discussion of > which/that at the end of this email.) > > Para 3, line 4. "temporariliy" -> "temporarily" > > Page 11, para 1, line 11. "which" -> "that" > > 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.) > > Page 20, Appendix A.1, para 1, line 1. "approach basically" -> "approach" > > Appendix A.2, para 1, line 1. "approach basically" -> "approach" > > Line 3. "which" -> "that" > > Page 21, para 1, line 1. "The Figure" -> "Figure" > > Page 22, para 1, line 1. "traffic which" -> "traffic, which" (See > discussion of which/that at the end of this email.) > > Line 4. "are being served" -> "are served" > > Appendix A.3, para 1, line 3. "which" -> "that" > > Appendix A.4, para 1, line 1. "which" -> "that" > > Line 5. "The Figure" -> "Figure" > > > 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". > > Wow. I had to recall my grammar classes from high school. > 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. > > Yes, e.g. is for example and i.e. is that is. Thank you for giving the corresponding Latin phrases. Regards, Behcet > > > > 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 > > > > -- > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email:william.atwood@concordia.ca > 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > --14dae947376bcf6ea004e3e990ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bill,

Thanks for your review.

On Tue, Aug 13, 2013 at 5:52 PM, William = Atwood <william.atwood@concordia.ca> wrote:
Adrian, authors,

As a member of the PIM Working Group,

Multi= mob too :-)
=A0
In fact we have been soliciting reviews fr= om our WG members since long time.

I have read the Internet Draft
draft-ietf-multimob-pmipv6-ropt. =A0It is very clear. =A0The solution is well explained; I had no difficulty following what the authors were
trying to do. =A0I 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. =A0I finally came to understand when I read Section 8 more
carefully. =A0I 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. =A0Add a sentence at the end: =A0"Although the interac= tion
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. =A0See Section 8 for details."

(You may wish to re-word this to be more precise. =A0You may wish to point<= br> 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.) =A0(I believe that it has something to do with the path between the<= br> proxy and the other architectural components being confined to IPv4, but I leave this to your expertise to find the right wording.)

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

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

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

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

Para 5, line 4. =A0"associated to" -> "associated with&qu= ot; =A0(This change
needs to be made _throughout_ the document.)

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

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

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

Para 3, line 4. =A0"temporariliy" -> "temporarily"
Page 11, para 1, line 11. =A0"which" -> "that"

Page 16, section 8, para 1, line 7. =A0"i.e. =A0IPv6" -> "= ;i.e., IPv6" =A0(Add
comma, delete space. =A0See discussion of "i.e." at the end of th= is email.)

Page 20, Appendix A.1, para 1, line 1. =A0"approach basically" -&= gt; "approach"

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

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

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

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

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

Appendix A.3, para 1, line 3. =A0"which" -> "that"
Appendix A.4, para 1, line 1. =A0"which" -> "that"
Line 5. =A0"The Figure" -> "Figure"

=A0
NOTE on use of "which" and "that". =A0"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 int= roduce
supplementary information. =A0Some 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. =A0In the second case, the house is completely
identified by its colour, and the information about the need to be
painted is supplementary information. =A0This information is set off with commas, and introduced with "which".


Wow. I had to recall my grammar classe= s from high school.

=A0
NOTES on the use of "i.e." and "e.g.".
"i.e." is an abbreviation for "id est", a Latin phrase = meaning "that
is". =A0As 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". =A0It should also be punctuated as if the full phr= ase were
present. =A0Unless 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.


Yes, e.g. is for example and i.e. is t= hat is.
Thank you for giving the corresponding Latin phrases.=
=A0
Regards,

Behcet



=A0 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 Rout= ing
> Optimizations for Proxy Mobile IPv6"
> https://datatracker.ietf.org/doc/draft-ietf-multi= mob-pmipv6-ropt/
>
> This document made it through IETF last call and arrived at the IESG w= ithout
> having been shown to the PIM working group. I have deferred the docume= nt to give
> a little time for me to get your input. Please send comments to me dir= ect or
> copying the IESG and the draft authors.
>
> Thanks,
> Adrian
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>

--
Dr. J.W. Atwood, Eng. =A0 =A0 =A0 =A0 =A0 =A0 tel: =A0 +1 (514) 848-2424 x3= 046
Distinguished Professor Emeritus =A0fax: =A0 +1 (514) 848-2830
Department of Computer Science
=A0 =A0and Software Engineering
Concordia University EV 3.185 =A0 =A0 email:william.atwood@concordia.ca
1455 de Maisonneuve Blvd. West =A0 =A0http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--14dae947376bcf6ea004e3e990ac-- From internet-drafts@ietf.org Thu Aug 15 16:05:24 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D24621F9C47; Thu, 15 Aug 2013 16:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eqPfch6DpJf; Thu, 15 Aug 2013 16:05:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618D21F9344; Thu, 15 Aug 2013 16:04:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815230457.20050.65751.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 16:04:57 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-ropt-08.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 23:05:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Multicast Mobility Routing Optimizations for Proxy Mobil= e IPv6 Author(s) : Juan Carlos Zuniga Luis M. Contreras Carlos J. Bernardos Seil Jeon Younghan Kim Filename : draft-ietf-multimob-pmipv6-ropt-08.txt Pages : 29 Date : 2013-08-15 Abstract: This document proposes some experimental enhancements to the base solution to support IP multicasting in a PMIPv6 domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile Access Gateway can provide access to multicast content in the local network. The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-ropt-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-ropt-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Aug 19 09:24:01 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292B011E8113; Mon, 19 Aug 2013 09:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.46 X-Spam-Level: X-Spam-Status: No, score=-102.46 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6QHxtMecygN; Mon, 19 Aug 2013 09:24:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E61D11E8298; Mon, 19 Aug 2013 09:24:00 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819162400.16435.23313.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 09:24:00 -0700 Cc: multimob mailing list , multimob chair , RFC Editor Subject: [multimob] Document Action: 'Multicast Mobility Routing Optimizations for Proxy Mobile IPv6' to Experimental RFC (draft-ietf-multimob-pmipv6-ropt-08.txt) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:24:01 -0000 The IESG has approved the following document: - 'Multicast Mobility Routing Optimizations for Proxy Mobile IPv6' (draft-ietf-multimob-pmipv6-ropt-08.txt) as Experimental RFC This document is the product of the Multicast Mobility Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt/ Technical Summary In this document, some enhancements to the base solution described in RFC 6224 are described. These enhancements include the use of a multicast tree mobility anchor (MTMA) as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobility Access Gateway can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. Working Group Summary The WG review process exhibited no anomalous deviations. Document Quality There are currently no existing implementations of the protocol described in this document. During the review process, the reviewers (including the document shepherd) expressed concerns on having multiple MTMAs instead of one and at the same time avoiding the tunnel convergence problem, e.g. the review posted on February 11, 2013. This issue was later on resolved by moving the relevant text into an informative annex, e.g. the review posted on May 6, 2013. Personnel Document Shepherd is Behcet Sarikaya Responsible Area Director is Brian Haberman From Dirk.von-Hugo@telekom.de Mon Aug 26 09:30:05 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A690321F9C54 for ; Mon, 26 Aug 2013 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm9gA5fjEZo0 for ; Mon, 26 Aug 2013 09:30:01 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id D5A9B11E81BB for ; Mon, 26 Aug 2013 09:30:00 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 26 Aug 2013 18:29:58 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 26 Aug 2013 18:29:58 +0200 From: To: , Date: Mon, 26 Aug 2013 18:29:56 +0200 Thread-Topic: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt Thread-Index: Ac5/UjIbZXHzndw2RT24KhtCMb8ezgfIHxSg Message-ID: <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> In-Reply-To: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:30:05 -0000 Dear all, As promised at IETF-87 I did a review of the source multicast mobility draf= t and think the document is in quite good shape. Being not the distinct expert in details of multicast protocols I am not su= re to have understood everything in detail, so please correct me and forgiv= e misunderstandings ... =20 The three scenarios described are=20 1) the base solution with MLD proxies at MAGs (and optionally also at LMAs)= (sect.3) 2) direct routing with or without MLD proxies at MAGs and with native Multi= cast support at MAG level or above via different established Multicast prot= ocols (sect.4) 3) Routing optimization for direct routing with MLD proxies at MAGs (sect. = 5) Right? IMHO from the abstract this is not easily to see. I have some comments and suggestions to increase readability, in addition t= o some nits found, given in the following: Fig. 1, fig.3 to be placed on single pages to simplify readability. Consistently use re-attach and re-distribute _or_ reattach and redistribute= , respectively, throughout document. Is there any implicit meaning of Proxy with respect to proxy? Also MLD Prox= y and MLD proxy are both used throughout the document ... p.1 optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies defined.=20 =3D> optimizations for synchronizing PMIPv6 with PIM, as well as a peerin= g function for MLD Proxies are defined. p.3 Such approaches (partially) follow the business model of providing multicast data services in parallel to PMIPv6 unicast routing. =3D=3D> shouldn't one or more references be added here such as to [I-D.ietf= -multimob-pmipv6-ropt], draft-ietf-multimob-fmipv6-pfmipv6-multicast, draft= -ietf-multimob-handover-optimization ...? needs of receptive use cases=20 =3D> needs of applications for mobile multicast reception of content from f= ew and mainly fixed content sources p.5 A multicast unaware MAG would simply discard these packets in the absence of a multicast routing information base (MRIB). =3D=3D> shouldn't one add more information about MRIBs introduced here for = non-multicast aware readers such as: Such tables similar to MFIBs mentioned= in RFC 6224 ensure that the router is able to correctly route/forward pack= ets with multicast addresses as destinations . In case of a handover, the MN (unaware of IP mobility) =3D> In case of a handover, the MN (being unaware of IP mobility) as soon as network connectivity is reconfigured=20 =3D> as soon as network connectivity is re-established p.7 multicast data is =3D> multicast data are p.8 In addition, an LMA serving as PIM Designated Router is connected =3D> In addition, an LMA serving as PIM Designated Router (DR) is connecte= d incoming interface validation is only performed by RPF checks =3D> incoming interface validation is only performed by RPF (Reverse Path F= orwarding) checks Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with respect to source location and does not require special configurations or state management for sources. =3D=3D> Wouldn't it make sense to add a reason for this, e.g.=20 ... since BIDIR PIM automatically builds trees to allow multicast data to b= e natively forwarded from sources to receivers without requiring source-spe= cific information ... On the other hand a reference to sect. 4.4 might be perhaps misleading here= since this section is not on direct multicast routing?! an IGMP proxy function needs to be deployed at MAGs in exactly the same way as for IPv6.=20 =3D> an IGMP proxy function needs to be deployed at MAGs in exactly the same way as is done= for an MLD proxy for IPv6. p.9 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances =3D> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances (i.= e. IPMP/MLD proxy functions) In the following, efficiency-related issues remain. =3D> In the following, efficiency-related issues which remain unsolved with= in the above defined base PMIPv6 multicast source support are described. p.11 upstream will lead traffic into the multicast infrastructure =3D> upstream will transfer traffic into the multicast infrastructure p.12 configurations have completed =3D> configurations have been completed traffic from the mobile source continues to be transmitted via the same next-hop router using the same source address =3D> traffic from the mobile source continues to be transmitted via the same next-hop multicast router using the same source address by aggregating proxies on a lower layer. =3D=3D> please clarify: what layer exactly is proposed? PIM DR at MAGs? in the access network for providing multicast services in parallel to unicast routes. =3D> in the access network for providing multicast services in parallel to unicast routes ( see Fig. 3(b)). p.13 The following information is needed for all phases of PIM. =3D> The following information is needed for all three phases of PIM as ou= tlined in [RFC4601]. P.14 configured to not initiated (S,G) shortest path tress for mobile =3D> configured to not initiated (S,G) shortest path trees for mobile mobile source. This tree can be of lesser routing efficiency than =3D> mobile source. This tree can be of lower routing efficiency than In response, the PIM RP will recognize the known source at a new (tunnel) interface immediately responds with a register stop. =3D> In response, the PIM RP will recognize the known source at a new (tunnel) interface and thus (?) immediately respond with a register stop= . As the RP had joined the shortest path tree to receive from the source via the LMA, =3D>As the RP has joined the shortest path tree to receive data from the source via the LMA, the LMA, it will see an RPF change when data arrives at a new =3D> the LMA, it will see an RPF change when data arrive at a new In response to an exceeded threshold of packet transmission, DRs of receivers eventually will initiated a source-specific Join for =3D> In response to an exceeded threshold of packet transmission, DRs of receivers eventually will initiate a source-specific Join for this (S,G) tree will range from the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the mobile source =3D> this (S,G) tree will range from the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the servi= ng MAG to the mobile source (described from leave to root?) This tree is of higher routing efficiency than established in the previous phase two =3D> This tree is of higher routing efficiency than that established in the previous phase two p.15 via the source register tunnel. Tree mainenance eventually triggered =3D> via the source register tunnel. Tree maintenance eventually triggered p.16 BIDIR-PIM MAY be deployed in the access network =3D> BIDIR-PIM [RFC5015]= MAY be deployed in the access network remain uneffected by node mobility =3D> remain unaffected by node mobility spanning group tree =3D> spanning tree for the multicast group /multicast s= panning tree p.17 document. To overcome these deficits, an optimized approach to =3D=3D> AFAIU it does mainly cover deficits mentioned in sect. 4, if also t= hose inefficiencies described in 3.2.5 are tackled this should be explained Following different techniques, these requirements are met in the following solutions. =3D=3D> to me it seems to be one solution only (peering between MLD proxies= ) adapted to several multicast protocol implementations for ASM and SSM but provide superior performance in the presence of source- specific signaling (IGMPv3/MLDv2).=20 =3D=3D> Wouldn't a reference to RFC 4604 ("Using Internet Group Management = Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Versi= on 2 (MLDv2) for Source-Specific Multicast") make sense or be helpful here? p.18 This filter base Must be updated, if and =3D> This filter base MUST be upda= ted, if and In addition, local multicast packets are transferred=20 =3D> In addition, multicast packets from locally attached sources are transferre= d or: In addition, such locally arriving multicast packets are transferred p.19 6. IANA Considerations TODO. =3D=3D> to me there seem to be no IANA activities arising from the proposed= protocol modifications, right? p.20 the PMIPv6 domain will not actively terminate group membership prior to departure. =3D> the PMIPv6 domain will in general not actively terminate group membership p= rior to departure. p.22 but alternate configuriations =3D> but alternate configurations a state decomposition , if needed =3D> a state decomposition, if needed... Hope this helps.=20 Thanks! Best regards Dirk -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of internet-drafts@ietf.org Sent: Samstag, 13. Juli 2013 00:50 To: i-d-announce@ietf.org Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PM= IPv6) Domains Author(s) : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-04.txt Pages : 24 Date : 2013-07-12 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD Proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies defined. Mobile sources always remain agnostic of multicast mobility operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From prvs=9434ed086=schmidt@informatik.haw-hamburg.de Mon Aug 26 13:29:20 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97EF21F9D3A for ; Mon, 26 Aug 2013 13:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zFKgUaopdj9 for ; Mon, 26 Aug 2013 13:29:16 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4AACD21F999C for ; Mon, 26 Aug 2013 13:29:14 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 26 Aug 2013 22:29:11 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 544B31066B09; Mon, 26 Aug 2013 22:29:11 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31980-07; Mon, 26 Aug 2013 22:29:09 +0200 (CEST) Received: from [192.168.178.33] (g231107191.adsl.alicedsl.de [92.231.107.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 79B191068726; Mon, 26 Aug 2013 22:29:09 +0200 (CEST) Message-ID: <521BBA92.9070002@informatik.haw-hamburg.de> Date: Mon, 26 Aug 2013 22:29:06 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Cc: multimob@ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 20:29:21 -0000 Hi Dirk, thanks for your thorough review. I'll come back to this in detail a few days. Best regards, Thomas On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote: > Dear all, > As promised at IETF-87 I did a review of the source multicast mobility draft and think the document is in quite good shape. > > Being not the distinct expert in details of multicast protocols I am not sure to have understood everything in detail, so please correct me and forgive misunderstandings ... > > The three scenarios described are > 1) the base solution with MLD proxies at MAGs (and optionally also at LMAs) (sect.3) > 2) direct routing with or without MLD proxies at MAGs and with native Multicast support at MAG level or above via different established Multicast protocols (sect.4) > 3) Routing optimization for direct routing with MLD proxies at MAGs (sect. 5) > Right? > IMHO from the abstract this is not easily to see. > > I have some comments and suggestions to increase readability, in addition to some nits found, given in the following: > > Fig. 1, fig.3 to be placed on single pages to simplify readability. > Consistently use re-attach and re-distribute _or_ reattach and redistribute, respectively, throughout document. > Is there any implicit meaning of Proxy with respect to proxy? Also MLD Proxy and MLD proxy are both used throughout the document ... > > p.1 > optimizations for synchronizing PMIPv6 with PIM, as well as a peering > function for MLD Proxies defined. > => optimizations for synchronizing PMIPv6 with PIM, as well as a peering > function for MLD Proxies are defined. > > p.3 > Such approaches (partially) follow the > business model of providing multicast data services in parallel to > PMIPv6 unicast routing. > ==> shouldn't one or more references be added here such as to [I-D.ietf-multimob-pmipv6-ropt], draft-ietf-multimob-fmipv6-pfmipv6-multicast, draft-ietf-multimob-handover-optimization ...? > > needs of receptive use cases > => needs of applications for mobile multicast reception of content from few and mainly fixed content sources > > p.5 > > A multicast unaware MAG would simply discard these packets in > the absence of a multicast routing information base (MRIB). > ==> shouldn't one add more information about MRIBs introduced here for non-multicast aware readers such as: Such tables similar to MFIBs mentioned in RFC 6224 ensure that the router is able to correctly route/forward packets with multicast addresses as destinations . > > In case of a handover, the MN (unaware of IP mobility) > => In case of a handover, the MN (being unaware of IP mobility) > > as soon as network connectivity is > reconfigured > => as soon as network connectivity is > re-established > > p.7 > multicast data is => multicast data are > > p.8 > In addition, an LMA serving as PIM Designated Router is connected > => In addition, an LMA serving as PIM Designated Router (DR) is connected > > incoming interface validation is only performed by RPF > checks > => incoming interface validation is only performed by RPF (Reverse Path Forwarding) > checks > > Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with > respect to source location and does not require special > configurations or state management for sources. > ==> Wouldn't it make sense to add a reason for this, e.g. > ... since BIDIR PIM automatically builds trees to allow multicast data to be natively forwarded from sources to receivers without requiring source-specific information ... > On the other hand a reference to sect. 4.4 might be perhaps misleading here since this section is not on direct multicast routing?! > > an IGMP proxy > function needs to be deployed at MAGs in exactly the same way as for > IPv6. > => an IGMP proxy > function needs to be deployed at MAGs in exactly the same way as is done for an MLD proxy for > IPv6. > > p.9 > For a dual-stack IPv4/IPv6 access network, the MAG proxy instances > => For a dual-stack IPv4/IPv6 access network, the MAG proxy instances (i.e. IPMP/MLD proxy functions) > > In the following, efficiency-related issues remain. > => In the following, efficiency-related issues which remain unsolved within the above defined base PMIPv6 multicast source support are described. > > p.11 > upstream will lead traffic into the multicast infrastructure > => upstream will transfer traffic into the multicast infrastructure > > p.12 > configurations have completed => configurations have been completed > > traffic from the mobile source continues to be transmitted via the > same next-hop router using the same source address > => traffic from the mobile source continues to be transmitted via the > same next-hop multicast router using the same source address > > by aggregating proxies on a lower layer. > ==> please clarify: what layer exactly is proposed? PIM DR at MAGs? > > in the access network for providing multicast services in parallel to > unicast routes. > => in the access network for providing multicast services in parallel to > unicast routes ( see Fig. 3(b)). > > p.13 > The following information is needed for all phases of PIM. > => The following information is needed for all three phases of PIM as outlined in [RFC4601]. > > P.14 > configured to not initiated (S,G) shortest path tress for mobile > => configured to not initiated (S,G) shortest path trees for mobile > > mobile source. This tree can be of lesser routing efficiency than > => mobile source. This tree can be of lower routing efficiency than > > In > response, the PIM RP will recognize the known source at a new > (tunnel) interface immediately responds with a register stop. > => In > response, the PIM RP will recognize the known source at a new > (tunnel) interface and thus (?) immediately respond with a register stop. > > As the > RP had joined the shortest path tree to receive from the source via > the LMA, > =>As the > RP has joined the shortest path tree to receive data from the source via > the LMA, > > the LMA, it will see an RPF change when data arrives at a new > => the LMA, it will see an RPF change when data arrive at a new > > In response to an exceeded threshold of packet transmission, DRs of > receivers eventually will initiated a source-specific Join for > => In response to an exceeded threshold of packet transmission, DRs of > receivers eventually will initiate a source-specific Join for > > this (S,G) tree will range from > the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the > mobile source > => > this (S,G) tree will range from > the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the serving MAG to the > mobile source (described from leave to root?) > > This tree is of higher routing efficiency than > established in the previous phase two > => > This tree is of higher routing efficiency than > that established in the previous phase two > > p.15 > via the source register tunnel. Tree mainenance eventually triggered > => via the source register tunnel. Tree maintenance eventually triggered > > p.16 > BIDIR-PIM MAY be deployed in the access network => BIDIR-PIM [RFC5015] MAY be deployed in the access network > > remain uneffected by node mobility => remain unaffected by node mobility > > spanning group tree => spanning tree for the multicast group /multicast spanning tree > > p.17 > document. To overcome these deficits, an optimized approach to > ==> AFAIU it does mainly cover deficits mentioned in sect. 4, if also those inefficiencies described in 3.2.5 are tackled this should be explained > > Following different techniques, these requirements are met in the > following solutions. > ==> to me it seems to be one solution only (peering between MLD proxies) adapted to several multicast protocol implementations for ASM and SSM > > but provide superior performance in the presence of source- > specific signaling (IGMPv3/MLDv2). > ==> Wouldn't a reference to RFC 4604 ("Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast") make sense or be helpful here? > > p.18 > This filter base Must be updated, if and => This filter base MUST be updated, if and > > In > addition, local multicast packets are transferred > => > In > addition, multicast packets from locally attached sources are transferred > or: > In addition, such locally arriving multicast packets are transferred > > p.19 > 6. IANA Considerations > TODO. > ==> to me there seem to be no IANA activities arising from the proposed protocol modifications, right? > > p.20 > the PMIPv6 domain will not actively terminate group membership prior > to departure. > => > the PMIPv6 domain will in general not actively terminate group membership prior > to departure. > > p.22 > but alternate configuriations => but alternate configurations > > a state decomposition , if needed => a state decomposition, if needed... > > Hope this helps. > Thanks! > > Best regards > Dirk > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Samstag, 13. Juli 2013 00:50 > To: i-d-announce@ietf.org > Cc: multimob@ietf.org > Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt > > > 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 : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains > Author(s) : Thomas C. Schmidt > Shuai Gao > Hong-Ke Zhang > Matthias Waehlisch > Filename : draft-ietf-multimob-pmipv6-source-04.txt > Pages : 24 > Date : 2013-07-12 > > Abstract: > Multicast communication can be enabled in Proxy Mobile IPv6 domains > via the Local Mobility Anchors by deploying MLD Proxy functions at > Mobile Access Gateways, via a direct traffic distribution within an > ISP's access network, or by selective route optimization schemes. > This document describes the support of mobile multicast senders in > Proxy Mobile IPv6 domains for all three scenarios. Protocol > optimizations for synchronizing PMIPv6 with PIM, as well as a peering > function for MLD Proxies defined. Mobile sources always remain > agnostic of multicast mobility operations. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ > multimob mailing list > multimob@ietf.org > 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 °