From william.atwood@concordia.ca Tue Aug 13 15:52:31 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@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: [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast 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: pim@ietfa.amsl.com Delivered-To: pim@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: multimob@ietf.org, IESG , pim@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org Subject: Re: [pim] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Protocol Independent Multicast 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: pim@ietfa.amsl.com Delivered-To: pim@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 X-Mailman-Approved-At: Thu, 15 Aug 2013 13:26:53 -0700 Cc: "multimob@ietf.org" , IESG , pim@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org Subject: Re: [pim] [multimob] Calling for review of draft-ietf-multimob-pmipv6-ropt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Protocol Independent Multicast 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 jasghar@cisco.com Fri Aug 16 17:22:16 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3511E819F for ; Fri, 16 Aug 2013 17:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_HI=-8] 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 n5xdgtehiYLB for ; Fri, 16 Aug 2013 17:21:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 141BF21F9F8F for ; Fri, 16 Aug 2013 17:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20551; q=dns/txt; s=iport; t=1376698916; x=1377908516; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1GsAStUHU+dWXOh6LDjGPfE6eA/eImsIue91JhQ9cbU=; b=BG7nBaCBFiLl9qU1dh0xTn2QRk5XW2ZVXhwlDuaQBSPb+LDrMA9wNPIf J1bVQCAuUNbrbeHBwhyMxV7Sr5W8bw2mFTbUrIuWSdBidu85GdgJLCRs4 Tt79yd77tZvHTMOTG8hqyM1uWYOd4IvU709ZetIIpf3Wj4vu47fBAbqMW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMfADlKrRDoG/2dsb2JhbABbgwY1v3OBKRZ0gh0HAQEBBAEBASQRFiAGBBELEQMBAQEBCQMBEggHCQMCAQIBFQoVCQgTBgIBAQUSAgSFKAeCPw25LI8DEIE4DAaEDAOJLY43himLLIM8HIE1 X-IronPort-AV: E=Sophos;i="4.89,898,1367971200"; d="scan'208";a="89298020" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 17 Aug 2013 00:21:54 +0000 Received: from [10.154.145.161] (dhcp-10-154-145-161.cisco.com [10.154.145.161]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7H0Lr95025814 for ; Sat, 17 Aug 2013 00:21:53 GMT Message-ID: <520EC202.9030707@cisco.com> Date: Fri, 16 Aug 2013 17:21:22 -0700 From: Javed Asghar User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: pim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [pim] pim Digest, Vol 111, Issue 13 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 00:22:16 -0000 Hi Bharat, Thanks, we'll proceed to the next stage. Please comments inline. Cheers, -Javed. On 7/23/2013 4:55 AM, pim-request@ietf.org wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/pim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send pim mailing list submissions to > pim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/pim > or, via email, send a message with subject or body 'help' to > pim-request@ietf.org > > You can reach the person managing the list at > pim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pim digest..." > > > Today's Topics: > > 1. Draft 'Explicit RPF Vector' (Bharat Joshi) > 2. Re: Draft submission on MLD with multiple upstreams > (LUIS MIGUEL CONTRERAS MURILLO) > 3. Re: Draft submission on MLD with multiple upstreams (Bharat Joshi) > 4. Re: Draft submission on MLD with multiple upstreams > (LUIS MIGUEL CONTRERAS MURILLO) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Jul 2013 10:09:43 +0000 > From: Bharat Joshi > To: "pim@ietf.org" > Subject: [pim] Draft 'Explicit RPF Vector' > Message-ID: > <35347FBF2796F94E936EE76C0E6047ED32EA31F7@BLRKECMBX13.ad.infosys.com> > Content-Type: text/plain; charset="Windows-1252" > > Hi Authors, > > I read through this draft. I think its ready to more to the next stage. However I have some small questions/suggestions below. > > Regards, > Bharat > > ? In Introduction, last para, "that the Explicit RPF Vector join may" -> "that the PIM join may" JA>>> ok. > > ? In section 8, as mentioned before, metric may not be zero. Even then do we not want to use metric here? BTW, I wanted to understand why do you want to give special mention for this here. Even if metric is zero, PIM assert uses preference and IP address as well so whether we use metric or not, the outcome will remain same. Or am I missing something here? JA>>> This is standard behavior and nothing different. This was not so necessary at all but we added this "only" based on your insistence for completeness, I'll correct the wording to avoid confusing interpretation if any. > > ? In section 8, in following sentence: > > There is minor behavioral difference, the routing protocol's Metric that is included in the PIM Assert should be taken from the first Explicit vector in the list. > > Did you mean 'route metric' instead of routing protocol's Metric here. Also, sentence seems to suggest that routing protocol metric is available in the Explicit vector in the list. Can you please reword it accordingly? > > ? How does PIM prune override works? If override is supported, will all PIM routers that have joined a group will override this prune. I checked RFC 5384 and that does not mention this. > > ? Section 10, in title, 'Explicit Vector' -> 'Explicit RPF Vector'. Please fix this in the text of this section as well. JA>>> ok > > ? Please read through Section 10 once. There is some conflict coming the way third sentence is framed. The second sentence using 'will not be able to remove' does not look correct. JA>>> No, I really disagree. Its looks fine to me in the context. Your comments are inconsistent. We had changed this very early based on your comments and then there was no more issue raised after the change by you. Its coming back again after long time. As the author I feel the WGLC adoption is getting stalled unfairly. > > ? In section 12, "the RPF Vector attribute" -> "the Explicit RPF Vector attribute" JA>>> ok. > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents to any other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has taken > every reasonable precaution to minimize this risk, but is not liable for any damage > you may sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > > ------------------------------ > > Message: 2 > Date: Tue, 23 Jul 2013 10:46:28 +0000 > From: LUIS MIGUEL CONTRERAS MURILLO > To: Bharat Joshi , "pim@ietf.org" > > Cc: "Zuniga, Juan Carlos \(JuanCarlos.Zuniga@InterDigital.com\)" > > Subject: Re: [pim] Draft submission on MLD with multiple upstreams > Message-ID: > <823234EF5C7C334998D973D822FF801B44F91315@EX10-MB2-MAD.hi.inet> > Content-Type: text/plain; charset=iso-8859-1 > > Hi Bharat, > > Sorry for my late response. Regarding your two questions on the topic: > >> 1. Something similar already exist and being used by the operators. Are we trying to standardize this? > Having more than one upstream interface for IGMP/MLD proxy is not standard today. As you mention, if this feature is something being used today through some proprietary mechanism, this reveals the interest on the topic. Network operators definitely support standard solutions rather that proprietary mechanism. So, in my opinion, it is worthy to work on an standard solution for this. In draft-contreras-pim-multiple-upstreams-00 there are a number of potential scenarios of usage for this feature. Probably some others can be identified and added. > >> 2. As this is device specific, won't a simple configuration is enough? The configuration could be vendor specific as there is no protocol interaction required. As far as I know, this is exactly what some of the vendors that implement this, used. > There are existing proposal for automating the upstream selection process, as described in section 5.1 of draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also susceptible of such dynamic selection. > > Best regards, > > Luis > > > -----Mensaje original----- > De: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Enviado el: lunes, 08 de julio de 2013 13:05 > Para: LUIS MIGUEL CONTRERAS MURILLO; pim@ietf.org > CC: Zuniga, Juan Carlos (JuanCarlos.Zuniga@InterDigital.com) > Asunto: RE: Draft submission on MLD with multiple upstreams > > Hi, > > I had posted some general question on this work. Its available in the message http://www.ietf.org/mail-archive/web/pim/current/msg02696.html > > Now that there are three docuemtns resolving the same problem, I request all the authors to reply to my questions. > > Regards, > Bharat > ________________________________________ > From: pim-bounces@ietf.org [pim-bounces@ietf.org] on behalf of LUIS MIGUEL CONTRERAS MURILLO [lmcm@tid.es] > Sent: Monday, July 08, 2013 3:36 PM > To: pim@ietf.org > Cc: Zuniga, Juan Carlos (JuanCarlos.Zuniga@InterDigital.com) > Subject: [pim] Draft submission on MLD with multiple upstreams > > Dear all, > > This is to announce that the draft-contreras-pim-multiple-upstreams have been already submitted to the PIM WG as mentioned during the last IETF meeting in Orlando. This draft was originally submitted to the multimob WG but presented to the PIM WG as well during the last two IETF meetings. > > The draft can be found in https://datatracker.ietf.org/doc/draft-contreras-pim-multiple-upstreams/ > > Any comment is welcome. > > Best regards, > > Luis > > ________________________________ > Luis M. Contreras > > Technology / Global CTO / Telef?nica > Efficiency Projects / Telef?nica I+D > > Distrito Telef?nica, Edificio Sur 3, Planta 3 > 28050 Madrid > Espa?a / Spain > > lmcm@tid.es > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > ------------------------------ > > Message: 3 > Date: Tue, 23 Jul 2013 10:59:34 +0000 > From: Bharat Joshi > To: LUIS MIGUEL CONTRERAS MURILLO , "pim@ietf.org" > > Cc: "Zuniga, Juan Carlos \(JuanCarlos.Zuniga@InterDigital.com\)" > > Subject: Re: [pim] Draft submission on MLD with multiple upstreams > Message-ID: > <35347FBF2796F94E936EE76C0E6047ED32EA3221@BLRKECMBX13.ad.infosys.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Luis, > > Thanks for your reply. Please see my replies in line. > > Regards, > Bharat > >> Sorry for my late response. Regarding your two questions on the topic: >> >>> 1. Something similar already exist and being used by the operators. >> Are we trying to standardize this? >> Having more than one upstream interface for IGMP/MLD proxy is not >> standard today. As you mention, if this feature is something being used >> today through some proprietary mechanism, this reveals the interest on >> the topic. Network operators definitely support standard solutions >> rather that proprietary mechanism. So, in my opinion, it is worthy to >> work on an standard solution for this. In >> draft-contreras-pim-multiple-upstreams-00 there are a number of >> potential scenarios of usage for this feature. Probably some others can >> be identified and added. > I am yet to read through any of the drafts. Before getting into that, I wanted to understand the need for the standardization of this purely because: > > 1. A solution already exist and different vendors have implemented it (differently) and deployed it. > 2. I cannot see how a standard solution will be better when this does not involve more than one router. > >>> 2. As this is device specific, won't a simple configuration is enough? >> The configuration could be vendor specific as there is no protocol >> interaction required. As far as I know, this is exactly what some of the >> vendors that implement this, used. >> There are existing proposal for automating the upstream selection >> process, as described in section 5.1 of >> draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also susceptible >> of such dynamic selection. > So what if configuration is vendor specific? Our requirement is to choose a specific upstream interface for a specific group. Right? This can be done with whatever vendors support today. So what I am not able to understand is that why do we need a standard algorithm to do this? > >> Best regards, >> >> Luis >> >> > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > notify the sender by e-mail and delete the original message. Further, you are not > to copy, disclose, or distribute this e-mail or its contents to any other person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has taken > every reasonable precaution to minimize this risk, but is not liable for any damage > you may sustain as a result of any virus in this e-mail. You should carry out your > own virus checks before opening the e-mail or attachment. Infosys reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Jul 2013 11:55:25 +0000 > From: LUIS MIGUEL CONTRERAS MURILLO > To: Bharat Joshi , "pim@ietf.org" > > Cc: "Zuniga, Juan Carlos \(JuanCarlos.Zuniga@InterDigital.com\)" > > Subject: Re: [pim] Draft submission on MLD with multiple upstreams > Message-ID: > <823234EF5C7C334998D973D822FF801B44F913BB@EX10-MB2-MAD.hi.inet> > Content-Type: text/plain; charset=utf-8 > > Hi Bharat, > > About your comments. > > The usefulness of an standardized feature is that the expected behavior is the same even if implemented by different vendors. The network operator does not need to adapt to particular solutions, but to well defined and generic ones. No particular hidden problems nor issues. Also thanks to the standard behavior, the hardware from a vendor can be substituted by other in the future (for instance, due to obsolescence) without need of re-customizing the network. This clearly reduces operational costs. > > Even if only one router is involved in the implementation of this feature, there are some issues to address (as per comparison with RFC4605 contents): > .- membership database structure: now more information would be needed because more than one upstream interface is in place. > .- operation with IGMP and MLD: separate upstream for each of them? Separated versions of protocols for each upstream interface? > .- loop prevention: think that you can find chained IGMP/MLD proxies in some deployments. > .- multicast sender support: what is the process for selecting the appropriate upstream interface? How to do it dynamically (for instance, as a function of the received subscriptions)? > .- SSM: what upstream interface is selected? RPF-like mechanism? > Plus some additional interesting issues like: > .- dynamic selection of the upstream in use: e.g., for maintenance reasons or due to a change in the multicast routing in the core network > .- redundancy: how to implement redundancy method taking advantage of a different upstream interface > .- load balancing: how to share the demand between distinct interfaces > .- service demarcation: how to smoothly integrate different multicast streams from different providers on the same distribution tree. > .- handover support in mobile services: simultaneous subscription of the same multicast streams for mitigating service disruption. > > In my opinion these are arguments in favor of standardizing this feature. > > Best regards, > > Luis > > > -----Mensaje original----- > De: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Enviado el: martes, 23 de julio de 2013 13:00 > Para: LUIS MIGUEL CONTRERAS MURILLO; pim@ietf.org > CC: Zuniga, Juan Carlos (JuanCarlos.Zuniga@InterDigital.com); cjbc@it.uc3m.es > Asunto: RE: Draft submission on MLD with multiple upstreams > > Hi Luis, > > Thanks for your reply. Please see my replies in line. > > Regards, > Bharat > >> Sorry for my late response. Regarding your two questions on the topic: >> >>> 1. Something similar already exist and being used by the operators. >> Are we trying to standardize this? >> Having more than one upstream interface for IGMP/MLD proxy is not >> standard today. As you mention, if this feature is something being >> used today through some proprietary mechanism, this reveals the >> interest on the topic. Network operators definitely support standard >> solutions rather that proprietary mechanism. So, in my opinion, it is >> worthy to work on an standard solution for this. In >> draft-contreras-pim-multiple-upstreams-00 there are a number of >> potential scenarios of usage for this feature. Probably some others >> can be identified and added. > I am yet to read through any of the drafts. Before getting into that, I wanted to understand the need for the standardization of this purely because: > > 1. A solution already exist and different vendors have implemented it (differently) and deployed it. > 2. I cannot see how a standard solution will be better when this does not involve more than one router. > >>> 2. As this is device specific, won't a simple configuration is enough? >> The configuration could be vendor specific as there is no protocol >> interaction required. As far as I know, this is exactly what some of >> the vendors that implement this, used. >> There are existing proposal for automating the upstream selection >> process, as described in section 5.1 of >> draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also >> susceptible of such dynamic selection. > So what if configuration is vendor specific? Our requirement is to choose a specific upstream interface for a specific group. Right? This can be done with whatever vendors support today. So what I am not able to understand is that why do we need a standard algorithm to do this? > >> Best regards, >> >> Luis >> >> > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > ------------------------------ > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > > End of pim Digest, Vol 111, Issue 13 > ************************************ > . > From bharat_joshi@infosys.com Fri Aug 16 23:39:42 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047D121F9C53 for ; Fri, 16 Aug 2013 23:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9MNCp8KFyj7T for ; Fri, 16 Aug 2013 23:39:37 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3E20C21F9C46 for ; Fri, 16 Aug 2013 23:39:35 -0700 (PDT) X-TM-IMSS-Message-ID: <80152a2f00135135@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 80152a2f00135135 ; Sat, 17 Aug 2013 12:06:34 +0530 Received: from BLRKECHUB07.ad.infosys.com (10.66.236.117) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 17 Aug 2013 12:09:13 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB07.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Sat, 17 Aug 2013 12:09:12 +0530 From: Bharat Joshi To: Javed Asghar , "pim@ietf.org" Thread-Topic: [pim] pim Digest, Vol 111, Issue 13 Thread-Index: AQHOmt/R+LSraBWDoEOAaIj6GY4UBpmY7Cx8 Date: Sat, 17 Aug 2013 06:39:11 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32EB8868@BLRKECMBX13.ad.infosys.com> References: , <520EC202.9030707@cisco.com> In-Reply-To: <520EC202.9030707@cisco.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.37.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] pim Digest, Vol 111, Issue 13 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 06:39:42 -0000 Hi Javed, My replies in line. Chairs and members, One question for you at the end of my reply. Regards, Bharat > > ? In section 8, as mentioned before, metric may not be zero. Even the= n > do we not want to use metric here? BTW, I wanted to understand why do > you want to give special mention for this here. Even if metric is zero, > PIM assert uses preference and IP address as well so whether we use > metric or not, the outcome will remain same. Or am I missing something > here? > > JA>>> This is standard behavior and nothing different. This was not so > necessary at all but we added this "only" based on your insistence for > completeness, I'll correct the wording to avoid confusing > interpretation > if any. > I think this was not added based on my comment. It was always there. When= I first mentioned about this in my first set of suggestions, you did mad= e some changes but I was still not convinced and so asked the same questi= on again. I think Stig also asked about the need to mention this in the draft. I am not sure if you really need to mention this at all. > > ? Please read through Section 10 once. There is some conflict coming > the way third sentence is framed. The second sentence using 'will not b= e > able to remove' does not look correct. > > JA>>> No, I really disagree. Its looks fine to me in the context. Your > comments are inconsistent. We had changed this very early based on your= > comments and then there was no more issue raised after the change by > you. Its coming back again after long time. I am not sure what exactly you mean by saying 'Its coming back again afte= r long time'. I had made some suggestions in previous revision of this draft. Authors a= greed and made those changes and submitted the new revision. I read throu= gh the changed revision and felt that the changes made is not proper and = so mention that in this mail. So first of all, this is not coming back af= ter long time. Second, I am fine with you not agreeing to my suggestion. = If you think this makes sense as it is, please leave this as it is. > As the author I feel the WGLC adoption is getting stalled unfairly. > I am not sure what do you mean by this. I did only two rounds of review o= f two different revisions of this drafts. Whatever suggestions I provided= , you agreed to take care most of these suggestions. I kind of tried to g= enerate some quality discussion on your draft and I am really shocked to = know that you feel I am stalling your draft. Do you really mean to say that people reviewing your draft and providing = suggestions (which most of you have agreed to) is stalling your draft unf= airly? As I am not sure what to say/do about this, I would request chairs and an= y other member of the mailing-list to let me know if this is what they al= so feel about such reviews. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From mmcbride7@gmail.com Sat Aug 17 00:16:30 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E4C21F9B92 for ; Sat, 17 Aug 2013 00:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qVYEQLqj1k08 for ; Sat, 17 Aug 2013 00:16:30 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9078A21F9B8D for ; Sat, 17 Aug 2013 00:16:28 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so1080497pbb.5 for ; Sat, 17 Aug 2013 00:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zSqXRMJ+vIJqbOyQ98jjurnc+oiY/XzwxLkXbbVdIwE=; b=nVm5N7c6uIy3xZzQY9q6g/8GXcTop9/KOa4BFLtza1iFMrwHvgViu1mbsdBOkbu9Xg baQLoM2XGS7F+SRErbJfKfQeUla4rgGEU8DRv31/fEnE3YtJ2ifhMZdq0oQJ86eLjuSb 6r8f72Hem2zyPCHQUDb8nvOL7pbN6+doMc+Ku/bQPKdpeYh6E0Z9r9AOjAa9Kfup6E8f E5eg5AvKkxe6qhq+qb9yj/rfowvI4mcgoMHB+RMcLar2RpAS/E0qRFtvKzUEGGPhPW0m HpuqP8qdmsQ/c1t5SlZ8D+Z5z5xhNr8UVpqSNQ0JseodXI6+8Y2X9U2KL+HkMAh7Esa4 tFfQ== MIME-Version: 1.0 X-Received: by 10.69.0.129 with SMTP id ay1mr1703673pbd.12.1376723787996; Sat, 17 Aug 2013 00:16:27 -0700 (PDT) Received: by 10.68.32.233 with HTTP; Sat, 17 Aug 2013 00:16:27 -0700 (PDT) In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32EB8868@BLRKECMBX13.ad.infosys.com> References: <520EC202.9030707@cisco.com> <35347FBF2796F94E936EE76C0E6047ED32EB8868@BLRKECMBX13.ad.infosys.com> Date: Sat, 17 Aug 2013 00:16:27 -0700 Message-ID: From: Mike McBride To: Bharat Joshi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pim@ietf.org" , Javed Asghar Subject: Re: [pim] pim Digest, Vol 111, Issue 13 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 07:16:31 -0000 Bharat, Thank you for your reviews. The working group appreciates the time you, and others, take to comment and help the quality of the drafts. We don't believe you are stalling any drafts, quite the contrary. We are in no particular hurry with this, or other, drafts and will error on the side of being thorough. We will progress this draft once your comments are addressed and we have consensus. mike On Fri, Aug 16, 2013 at 11:39 PM, Bharat Joshi w= rote: > Hi Javed, > > My replies in line. > > Chairs and members, > One question for you at the end of my reply. > > Regards, > Bharat > >> > ? In section 8, as mentioned before, metric may not be zero. Even then >> do we not want to use metric here? BTW, I wanted to understand why do >> you want to give special mention for this here. Even if metric is zero, >> PIM assert uses preference and IP address as well so whether we use >> metric or not, the outcome will remain same. Or am I missing something >> here? >> >> JA>>> This is standard behavior and nothing different. This was not so >> necessary at all but we added this "only" based on your insistence for >> completeness, I'll correct the wording to avoid confusing >> interpretation >> if any. >> > > I think this was not added based on my comment. It was always there. When= I first mentioned about this in my first set of suggestions, you did made = some changes but I was still not convinced and so asked the same question a= gain. > > I think Stig also asked about the need to mention this in the draft. > > I am not sure if you really need to mention this at all. > >> > ? Please read through Section 10 once. There is some conflict coming >> the way third sentence is framed. The second sentence using 'will not be >> able to remove' does not look correct. >> >> JA>>> No, I really disagree. Its looks fine to me in the context. Your >> comments are inconsistent. We had changed this very early based on your >> comments and then there was no more issue raised after the change by >> you. Its coming back again after long time. > > I am not sure what exactly you mean by saying 'Its coming back again afte= r long time'. > > I had made some suggestions in previous revision of this draft. Authors a= greed and made those changes and submitted the new revision. I read through= the changed revision and felt that the changes made is not proper and so m= ention that in this mail. So first of all, this is not coming back after lo= ng time. Second, I am fine with you not agreeing to my suggestion. If you t= hink this makes sense as it is, please leave this as it is. > >> As the author I feel the WGLC adoption is getting stalled unfairly. >> > > I am not sure what do you mean by this. I did only two rounds of review o= f two different revisions of this drafts. Whatever suggestions I provided, = you agreed to take care most of these suggestions. I kind of tried to gener= ate some quality discussion on your draft and I am really shocked to know t= hat you feel I am stalling your draft. > > Do you really mean to say that people reviewing your draft and providing = suggestions (which most of you have agreed to) is stalling your draft unfai= rly? > > As I am not sure what to say/do about this, I would request chairs and an= y other member of the mailing-list to let me know if this is what they also= feel about such reviews. > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely > for the use of the addressee(s). If you are not the intended recipient, p= lease > notify the sender by e-mail and delete the original message. Further, you= are not > to copy, disclose, or distribute this e-mail or its contents to any other= person and > any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken > every reasonable precaution to minimize this risk, but is not liable for = any damage > you may sustain as a result of any virus in this e-mail. You should carry= out your > own virus checks before opening the e-mail or attachment. Infosys reserve= s the > right to monitor and review the content of all messages sent to or from t= his e-mail > address. Messages sent to or from this e-mail address may be stored on th= e > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Sun Aug 18 12:31:37 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EDD21F9D12 for ; Sun, 18 Aug 2013 12:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 FFGDoXL4SL9o for ; Sun, 18 Aug 2013 12:31:36 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id B191421F9CA1 for ; Sun, 18 Aug 2013 12:31:36 -0700 (PDT) Received: from [10.21.103.58] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 1C34C7FC8; Sun, 18 Aug 2013 21:31:33 +0200 (CEST) Message-ID: <521122A0.3050503@venaas.com> Date: Sun, 18 Aug 2013 12:38:08 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mike McBride References: <520EC202.9030707@cisco.com> <35347FBF2796F94E936EE76C0E6047ED32EB8868@BLRKECMBX13.ad.infosys.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pim@ietf.org" , Bharat Joshi , Javed Asghar Subject: Re: [pim] pim Digest, Vol 111, Issue 13 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 19:31:37 -0000 On 17.08.2013 00:16, Mike McBride wrote: > Bharat, > > Thank you for your reviews. The working group appreciates the time > you, and others, take to comment and help the quality of the drafts. > We don't believe you are stalling any drafts, quite the contrary. We > are in no particular hurry with this, or other, drafts and will error > on the side of being thorough. We will progress this draft once your > comments are addressed and we have consensus. Thanks for the reviews and discussion Bharat. This is exactly what we need. It would be great if more people in our WG would review and comment on the draft as well, so that we can get some good discussions and increase the quality of the documents. Stig > mike From iesg-secretary@ietf.org Tue Aug 20 11:24:47 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4294A11E819C; Tue, 20 Aug 2013 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, 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 0dnOPAgsqXjB; Tue, 20 Aug 2013 11:24:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9111E8125; Tue, 20 Aug 2013 11:24:41 -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 Sender: Message-ID: <20130820182441.28706.16184.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2013 11:24:41 -0700 Cc: pim@ietf.org Subject: [pim] Last Call: (Survey Report on PIM-SM Implementations and Deployments) to Informational RFC X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:24:47 -0000 The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'Survey Report on PIM-SM Implementations and Deployments' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from IETF Proposed Standard to Internet Standard. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601-update-survey-report/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601-update-survey-report/ballot/ No IPR declarations have been submitted directly on this I-D. From mmcbride7@gmail.com Tue Aug 20 20:21:13 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47911E837C for ; Tue, 20 Aug 2013 20:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_84=0.6, 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 8-G9u48cZqbt for ; Tue, 20 Aug 2013 20:21:12 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 69F3511E8379 for ; Tue, 20 Aug 2013 20:21:12 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so264662pab.39 for ; Tue, 20 Aug 2013 20:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OpeGtEULzqyx8vj4NcbwIW7bcQO02CwX9gb9CoVZ484=; b=LtgC9ZQRtmch9uKotTqRDy9ppCBc0C0GZVvlPLKB89IhSZG0iKwziXtgYZl02B6p8z ey0LjX5xw4hF8CzO8T0wSyxtu+/kAAgJnl8Hf8ZrniVRjr+uOfpYixzK4iNMmTuv4sTw e5oUPKNjmTT0C3uN/Nwur0KBYs6mnfZ3WNqdLezpUBtEfDyKkWdWOjTyc7ZXpf2a1MDq pDrzJEtHjcXs806CAfpJSvWCEidjLx12iVjEIYoV5vi+WStYiqhp959u2MaMuj2HSbzY DntnpeRrbrlny64QmIgheutN1NnMsEUNUyuFlHvngi1D3z2XfaWRnyLqU0Urwa+bSXPU kyDQ== MIME-Version: 1.0 X-Received: by 10.68.191.231 with SMTP id hb7mr5334312pbc.82.1377055271990; Tue, 20 Aug 2013 20:21:11 -0700 (PDT) Received: by 10.68.32.233 with HTTP; Tue, 20 Aug 2013 20:21:11 -0700 (PDT) Date: Tue, 20 Aug 2013 20:21:11 -0700 Message-ID: From: Mike McBride To: "pim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [pim] Berlin meeting notes X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 03:21:13 -0000 Please review the following draft meeting notes from our meeting in Berlin. If you have corrections or additions please let Stig and I know. Thank you to Hitoshi for taking the minutes. thanks, mike PIM WG minutes Thursday 8/1, 1-3pm Stig Venaas, Mike McBride Notes: Hitoshi Asaeda No comments on agenda Status (Stig/Mike) ================== rfc4601-update passed WGLC explicit-tracking draft passed WGLC. One more update. explicit-rpf-vector passed WGLC, needs updating based on ML comments. igmp-mld wireless will go to WG draft. 4 yes in the meeting. joinattributes draft: 4 in the room in favor. 3 in the room last time. Bharat offered comments. Will poll the list. draft-zhou-pim-vrrp-01 adoption discussion (Mike) ================================================= Adoption currently on hold. Authors of draft-xu-pim-drpriority-auto-adjustment-04 would like wg to consider a merge because there is an overlap particularly with aligning vrrp with pim. We will have a brief overview of both and discuss how to proceed. draft-xu-pim-drpriority-auto-adjustment wasn't accepted as a wg item a couple of years ago. No strong interest in the group. The WG needs to decide if its interested in this work, the earlier draft. If not we proceed with draft-zhou-pim-vrrp adoption call if there is interest. If intereste we either: -Adopt and progress both drafts. One as a problem statement, the other as protocol work. -Reference earlier draft in draft-zhou-pim-vrrp -Merge drafts into new draft Any interest in VRRP in general? No hands. Will take it to the list and see if there is any interest. If no one but the authors care we won't work it. 4 in favor last time in addition to authors. Note: the usual suspects were not in the room primarily due to conflicting WG meetings. draft-ietf-6man-multicast-addr-arch-update-01 (Stig) ==================================================== stig: should not ff2x::/32 also be SSM? ???: a little bit scared about cleaning up for something in the future. Maybe put this in information draft. Multiple implementations in the field so wouldn't be easy but there are definite inconsistancies. Stig: implementations would treat those addresses differently. Brian Haberman:Stig and i have talked about this off/on for a year. There are some issues in the document. Looking for values for the flag rather then looking at bits. One way would be to write errata statements saying to not do that. Need to look at existing implementations, someone will need to change code. Do we really need this changed? See if you can get a couple implementatons to say if that are doing the bit wise comparisons like they are suppose to. Or check entire thing as a single value. ???: Errata probably is the best way. stig: lots of people don't read errata. Action: pim to review the draft, maybe a joint wglc. draft-joshi-pim-ecmp-neighbor-select-00 (Stig) ============================================== Stig presenting in his behalf. Is it worth standardizing this hash to select the upstream neighbor because currently its undefined. Stig: could be complications with implementations supporting old and new. 2 people have read it. Bob kebler: not sure if its solving the problem they hope. You can still have an assert with a hash. R2 can still have a different path to the source then R1. Depends upon topology. Jeffrey Zhang: Not taking on the work would be fine. ???: it works, its a transient problem. draft-wignands-pim-source-discovery-bsr-03 (Ice) ============================================== highly redudant mcast network without single point of failure. Jeffrey: Of the 10k flows how many groups? Ice: the sources are what's relevant. 10k s,gs. Not introducing a new routing protocol. Jeffrey: Could use mospf. pim bidir is another viable approach. With bidir, while the RPA canbe an address that is not tried to any router (the address would be associated with a LAN), the LAN that the RPA is on could become partitioned. When that happens, traffic cannot be exchanged on the LAN between the partitions, affecting lots of receivers. That's the problem using PIM-BIDIR instead of BSR flooing. However, that can be easily resolved by a protocol extension. I should be able to publish it for the next IETF meeting. With that resolved, PIM bidir will be a better solution for the targeted deployment scenario. stig: one issue with bidir is you don't have the optimal path. operator DT: I like the use case and support. Hitoshi: flooding is not typically optimal. Ice: its only using mechanisms that exist today with bsr. jeffrey: the amount of information is more with today. Hitoshi: Why not use SAP (I'm not a fan of SAP though)? Whats the meaning of flooding. Use MSDP if interdomain? lighthouse networks: you mentioned dns, why can't you use that? Ice; this is a case where you don't know the source. bsr based flooding. not inter domain discussion. Enterprise network. Mike: applaud any efforts to make multicast more simple. But flooding may be a problem. 1 room interested. 2 operators on draft interested. Mike will poll on list. draft-kebler-pim-mrt-protection-01 (Rob Kebler) =========================================== Rob: pim extensions to support maximally redundant trees. MRT being done in rtgwg. Ice: how do you do rpf check? Rob: If the link is down Stig: GRE or MPLS is simpler? Mike: any operators needing this beyond what's there today? Which routers need to support (LHR or other)? Rob: All routers, but incremental deployment scenario is also considered. Stig: How much MRT is interested in? Rob: MRT is discussed in rtgrg Ice: local protection? Rob: we can discuss Stig: 4 people interested Rob: ask for adoption after the next revision. Ice: link and local protection hard to do. what should be done in pim versus mldp, etc draft-contreras-pim-multiple-upstreams-00: Brian: In magma, no strong interest of multiple upstream for IGMP proxy. Second, reducing complexity is the way to go. not sure if we wanted to go down the road because the whole point of proxy is to simply multicast. Behcet: Why not multimob? Brian: pim has the responsibility in specifying group mgmt protocols. Adrian: This WG has mld/igmp. multimob does not have work on igmp/mld protocols. Stig: igmp/mld solutions belong here. Good to have people with protocol knowledge. Ice: would be good to see a better use case explanation and motivation. Hitoshi: well written draft. good to publish as a requirements draft. Bechet: already an industry practice having multiple interfaces. Hitoshi's explicit tracking is also widely implemented so why are we. Carlos: these extensions may be useful and bring to a more wide area. Brian: Area Director: don't want to see core protocol development over multiple groups. igmp work should be done here so we don't have people step on each other. Brian: would highly encourage discussion in mboned because that is where operators live. Hitoshi: document is useful. could be useful in mboned. Stig: typically initial work done in mboned and solutions done here. Carlos: have non multimob scenarios. Brian: just talked about multiple upstreams, don't confuse about mobility. Take to the list. please get input from mboned. Carlos: comfortable with this being an Informational requirements/use case document. Stig: present to mboned and then come to pim and report. zhang: initial idea. Hitoshi: similar draft. submitted last year. What is the next step? Stig: Good to discuss, but early to make decision, whether selecting a single doc or merging into one doc. From durgam.iit@gmail.com Tue Aug 20 20:35:38 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02311E818E for ; Tue, 20 Aug 2013 20:35:38 -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 T5Vl0SmuEY9m for ; Tue, 20 Aug 2013 20:35:37 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E911E8150 for ; Tue, 20 Aug 2013 20:35:37 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id id13so923899vcb.4 for ; Tue, 20 Aug 2013 20:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CMntMDzEml4dOyqOaUQ228jbRHhhXArVcjPG7piqo7I=; b=r5ga7oC+SElkZuY3EQ78TdNZnFStDPlP8MABofzLK3REMbFVr+crkl7wxq8xm72o/o J74AjwXghTYWthfFqSMQ5MgGHecrRUPO1ut3/swm/rD0Fm8IMQGzFSxFIMnk7SxAvhh9 vBwqKks2xKsBU9wH9CTxsonx3lKy8S8hquE08kQEjB7JH0ZHM5TJ+jlV60epAlCKj5Jk uvod1b12gDuEcqC28eDTIn6/Ar+u0MyEPqKzyp3FlK0idnE8B7HoOl3xnk2a1KBQN+FG /hDBxQrU1C/zZRdMSkSRKifMWcHuMKxOTEwMJSL/ztRc6tRh8ahFVrJTePvBBkNMFhRl P0sw== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr4270503vcb.16.1377056135626; Tue, 20 Aug 2013 20:35:35 -0700 (PDT) Received: by 10.58.245.1 with HTTP; Tue, 20 Aug 2013 20:35:35 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Aug 2013 20:35:35 -0700 Message-ID: From: phani Ayyappa To: pim@ietf.org Content-Type: multipart/alternative; boundary=047d7b5db26accc64104e46cddb4 Subject: Re: [pim] reg snooping switch participating in vrf X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 03:35:38 -0000 --047d7b5db26accc64104e46cddb4 Content-Type: text/plain; charset=ISO-8859-1 > Hi, > On a vlan , snooping is configured . On this vlan interface l3 address > and vrf are configured but no pim routing is enabled. If this vlan > interface moves from one vrf to other vrf , does it impact already learnt > snooping groups state ? Can you please let me know the behaviour ? > > Thanks > Phani > --047d7b5db26accc64104e46cddb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
Hi,
=A0= On a vlan , snooping is configured . On this vlan interface l3 address and= vrf are configured but no pim routing is enabled.=A0 If this vlan interfac= e moves from one vrf to other vrf , does it impact already learnt snooping = groups state ? Can you please let me know the behaviour ?

Thanks
Phani

--047d7b5db26accc64104e46cddb4-- From myselfindranil@gmail.com Tue Aug 20 21:48:03 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5704511E8319 for ; Tue, 20 Aug 2013 21:48:03 -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 UVFH+748UE8w for ; Tue, 20 Aug 2013 21:48:01 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7F07A11E8173 for ; Tue, 20 Aug 2013 21:47:58 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz10so469523bkb.31 for ; Tue, 20 Aug 2013 21:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w0m2Hccs7hE1TtVS6eWssTTWtWh80tfTrmuhD90CF28=; b=LPvd26CX2Gcax0QLp4FNLRw1yDirIwM6mWFIFMz3xfCjNPk/HkTswyA4iMR06NlZnA 1/9r9VDVrPybY/rNaNVk6reH7+/WMsD0N2WenjNTW8YgVKKlMvixpx97oEO1v5z3mtvO 1g3ZV0yr8Ia0EZYZmanfilaGAxbd6NA0UPWRFmca7fja49VbqPfWFmgAZHFM0V+6cgOb 1vaHc4/CBpwbtQ5J9DJ+Z+0+0pnqKf+iH/PgMbdSLvqulrVpRuDW+Af2KwR5/JsiyEyX UOUWOuPbJJsMm6rDs1WC1xzJc3r76IxFGVoptZvX+SMY42nILp0AaIeDeZ/v3GeyrDaI 0I7A== MIME-Version: 1.0 X-Received: by 10.204.188.200 with SMTP id db8mr3412906bkb.12.1377060477483; Tue, 20 Aug 2013 21:47:57 -0700 (PDT) Received: by 10.204.225.205 with HTTP; Tue, 20 Aug 2013 21:47:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Aug 2013 10:17:57 +0530 Message-ID: From: Indranil Bhattacharya To: phani Ayyappa Content-Type: multipart/alternative; boundary=20cf302d50cc986b5c04e46de056 Cc: "pim@ietf.org" Subject: Re: [pim] reg snooping switch participating in vrf X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 04:48:03 -0000 --20cf302d50cc986b5c04e46de056 Content-Type: text/plain; charset=ISO-8859-1 Hi Phani, Lets say you are providing one customer using vlan10 and you have enabled l3 routing on the ve/svi. Now changing vrf means you are providing some other customer using that vlan. So carrying forward snoop group information will be wrong as the other customer may not have interest in the existing groups. So I think if ve/svi is configured and it changes vrf then you should delete the snooping groups. Thanks, Indranil On Wed, Aug 21, 2013 at 9:05 AM, phani Ayyappa wrote: > > Hi, >> On a vlan , snooping is configured . On this vlan interface l3 address >> and vrf are configured but no pim routing is enabled. If this vlan >> interface moves from one vrf to other vrf , does it impact already learnt >> snooping groups state ? Can you please let me know the behaviour ? >> >> Thanks >> Phani >> > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > --20cf302d50cc986b5c04e46de056 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Phani,

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Lets say you are providing one customer using vlan10 and= you have enabled l3 routing on the ve/svi. Now changing vrf means you are = providing some other customer using that vlan. So carrying forward snoop gr= oup information will be wrong as the other customer may not have interest i= n the existing groups. So I think if ve/svi is configured and it changes vr= f then you should delete the snooping groups.

Thanks,
Indranil

On Wed, Aug 21, 2013 at 9:05 AM, phani Ayya= ppa <durgam.iit@gmail.com> wrote:

Hi,
=A0 On a vlan , snooping is config= ured . On this vlan interface l3 address and vrf are configured but no pim = routing is enabled.=A0 If this vlan interface moves from one vrf to other v= rf , does it impact already learnt snooping groups state ? Can you please l= et me know the behaviour ?

Thanks
Phani


_______________________________________________
pim mailing list
pim@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/pim


--20cf302d50cc986b5c04e46de056-- From bharat_joshi@infosys.com Wed Aug 21 09:19:48 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7421F9AE3 for ; Wed, 21 Aug 2013 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 L9LEt6TEk6SB for ; Wed, 21 Aug 2013 09:19:43 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosysconsulting.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C721F9A90 for ; Wed, 21 Aug 2013 09:19:36 -0700 (PDT) X-TM-IMSS-Message-ID: <9768005d00177e51@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 9768005d00177e51 ; Wed, 21 Aug 2013 21:46:32 +0530 Received: from BLRKECHUB08.ad.infosys.com (10.66.236.138) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 21 Aug 2013 21:48:59 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB08.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Wed, 21 Aug 2013 21:48:57 +0530 From: Bharat Joshi To: Mike McBride , "pim@ietf.org" Thread-Topic: [pim] Berlin meeting notes Thread-Index: AQHOnh1yWl0dVJxtHUir0H1UzSb2MpmfwKBK Date: Wed, 21 Aug 2013 16:18:56 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32EB9586@BLRKECMBX13.ad.infosys.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.37.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] Berlin meeting notes X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:19:48 -0000 Hi, Unfortunately I could not attend the IETF meeting. Thanks to Stig fo= r presenting our draft 'draft-joshi-pim-ecmp-neighbor-select-00'. I have = few replies on the questions raised on our draft. Thanks, Bharat draft-joshi-pim-ecmp-neighbor-select-00 (Stig) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Stig presenting in his behalf. Is it worth standardizing this hash to select the upstream neighbor because currently its undefined. Stig: could be complications with implementations supporting old and new. 2 people have read it. Bob kebler: not sure if its solving the problem they hope. You can still have an assert with a hash. R2 can still have a different path to the source then R1. Depends upon topology. Jeffrey Zhang: Not taking on the work would be fine. ???: it works, its a transient problem. : This draft tries to solve a problem where downstream routers have consist= ent forwarding table but they decide to send PIM join to different upstre= am neighbor as the route towards source/RP is an ECMP route and these two= routers (may be from two different vendors or may be using different sof= tware releases) select different neighbors. If these two routers uses some mechanism (like hash) with which they sele= ct the same neighbor, we can avoid building two multicast tree and assert= when traffic flows. I see Bob suggested that it will depend upon the topology. Yes, I agree t= hat it will depend upon the topology. Deployments do use ECMP routes and = I think it would be better to avoid choosing different upstream neighbors= if possible. Someone suggested that its a transient problem. My thinking is that this = transient problem can end up wasting lot-of-resources depending upon the = network topology. So why not fix this transient problem if we can. Someone suggested that things have been working with Assert so why do we = need this work. My reply is that things might be working because either E= CMP routes are not used in their topology or both the downstream routers = are from the same vendor and so they have not seen this issue. This issue will be more visible if the two downstream routers are from tw= o different vendors. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From adapa.ajith@gmail.com Mon Aug 26 09:29:04 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8040B21F9AFE for ; Mon, 26 Aug 2013 09:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 weyVyiZhovQc for ; Mon, 26 Aug 2013 09:29:03 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83F21F9A43 for ; Mon, 26 Aug 2013 09:29:02 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id b10so1736853eae.10 for ; Mon, 26 Aug 2013 09:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=av77KFcnUF3k8g/IBX6wWIE3B7nwZ4OBwZhljcWqfwk=; b=sVhlODnucs8xOTZxw0f54mt8Oa4Uxm3iH9R7zTsT2TSWr75l2ltpNstf84ui8vCwl3 W8HLi/UrSlVssIQEJygIGxk1coRhG2QLSLc4ml0DwC59ir8FsrtgwSLvYPSvHrKj66Iw j+PYlrDkz6OJV+6cSOPrIyQW16GHSLSbDWsqNirw9nkEEfGDsPmE3hKY93l1c7SzKZNa nXL9aXECflfkyeYljWOX6uYrpMvVmTBDzpP6PtCtMQywEpwI8YL/l/5ICTb2iQ4wLkn4 ADJwSxqkJnytbTMnByVHSE2Cnbo3xWobLr8o8CB1gwSnZOTOatNuVeR7eq8QaJoz2Y6e xSRA== X-Received: by 10.15.26.7 with SMTP id m7mr4526645eeu.56.1377534540776; Mon, 26 Aug 2013 09:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.89.28 with HTTP; Mon, 26 Aug 2013 09:28:22 -0700 (PDT) In-Reply-To: References: From: Ajith Adapa Date: Mon, 26 Aug 2013 21:58:22 +0530 Message-ID: To: Indranil Bhattacharya Content-Type: text/plain; charset=UTF-8 Cc: "pim@ietf.org" Subject: Re: [pim] reg snooping switch participating in vrf X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:29:04 -0000 Sorry to intrude but I would like to ask one question down here. What is the advantage of IGMP/MLD snooping under VRF ? Any pointers to right article would be of great help to me. Regards, Ajith -------------------------------------------- codingfreak.in On Wed, Aug 21, 2013 at 10:17 AM, Indranil Bhattacharya wrote: > Hi Phani, > > Lets say you are providing one customer using vlan10 and you > have enabled l3 routing on the ve/svi. Now changing vrf means you are > providing some other customer using that vlan. So carrying forward snoop > group information will be wrong as the other customer may not have interest > in the existing groups. So I think if ve/svi is configured and it changes > vrf then you should delete the snooping groups. > > Thanks, > Indranil > > > On Wed, Aug 21, 2013 at 9:05 AM, phani Ayyappa wrote: >> >> >>> Hi, >>> On a vlan , snooping is configured . On this vlan interface l3 address >>> and vrf are configured but no pim routing is enabled. If this vlan >>> interface moves from one vrf to other vrf , does it impact already learnt >>> snooping groups state ? Can you please let me know the behaviour ? >>> >>> Thanks >>> Phani >> >> >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From internet-drafts@ietf.org Tue Aug 27 11:23:13 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F95E21F9E3B; Tue, 27 Aug 2013 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, 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 AB8ZVzSS3ErL; Tue, 27 Aug 2013 11:23:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C547F21F9E37; Tue, 27 Aug 2013 11:23:12 -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: <20130827182312.1084.86288.idtracker@ietfa.amsl.com> Date: Tue, 27 Aug 2013 11:23:12 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-igmp-mld-wireless-mobile-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:23:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Working Gr= oup of the IETF. Title : IGMP/MLD Optimizations in Wireless and Mobile Networks Author(s) : Hui Liu Mike McBride Hitoshi Asaeda Filename : draft-ietf-pim-igmp-mld-wireless-mobile-00.txt Pages : 13 Date : 2013-08-23 Abstract: This document proposes a variety of optimization approaches for IGMP and MLD in wireless and mobile networks. It aims to provide useful guidelines to allow efficient multicast communication in these networks using IGMP or MLD protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-igmp-mld-wireless-mobile There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pim-igmp-mld-wireless-mobile-00 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 stig@venaas.com Thu Aug 29 10:53:36 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9886421E80C3 for ; Thu, 29 Aug 2013 10:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 vaLtuR2JcExK for ; Thu, 29 Aug 2013 10:53:35 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id A928321E80BD for ; Thu, 29 Aug 2013 10:53:33 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:5425:10dd:5aed:3806] (unknown [IPv6:2001:420:4:ea0c:5425:10dd:5aed:3806]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6D8FA802A for ; Thu, 29 Aug 2013 19:53:32 +0200 (CEST) Message-ID: <521F8A93.2090309@venaas.com> Date: Thu, 29 Aug 2013 10:53:23 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "pim@ietf.org" References: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> In-Reply-To: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> X-Forwarded-Message-Id: <074601cea4c6$8189ba90$849d2fb0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Fwd: FW: Mail lost yesterday X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:53:36 -0000 FYI, emails sent to IETF lists (including this list) yesterday lost. Stig -------- Original Message -------- From: Adrian Farrel Reply-To: To: For those of you who haven't noticed the message from Steve Young in your In box, mail to all IETF lists between 15:30 and and 20:55 Pacific Time yesterday seems to have been lost. Aside from needing to re-send all mail you personally sent during that time period, you also need to inform your working groups.