From brian@innovationslab.net Wed Jun 5 08:43:07 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD8E21F9AFD for ; Wed, 5 Jun 2013 08:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 R0DCASKbtdiE for ; Wed, 5 Jun 2013 08:43:01 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7E21F9AF8 for ; Wed, 5 Jun 2013 08:43:01 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 60E40880F7; Wed, 5 Jun 2013 08:43:01 -0700 (PDT) Received: from 102523118.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 19D1C130003; Wed, 5 Jun 2013 08:43:01 -0700 (PDT) Message-ID: <51AF5C82.8010703@innovationslab.net> Date: Wed, 05 Jun 2013 11:42:58 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: multimob@ietf.org, draft-ietf-multimob-pmipv6-ropt@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 15:43:08 -0000 All, Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt. Once these issues are resolved, the draft can move to the next step in the publication process (IETF Last Call). * There are several explicit mentions of the Multimob WG in the document. Those sentences should be re-worded to focus on the content of the draft, rather than who created the draft. * In the Intro : s/so-called tunnel convergence/tunnel convergence/ * Is the MTMA really just a variant of an LMA (i.e., LMA handling all multicast traffic)? If so, the definition should clarify that. * In 3.1 : s/is used used to/is used to/ * In 3.2, there is a reference to Figure 1 that I believe should be a reference to Figure 2. * In 3.2, what is meant by a "direct connection" between the MAG and a multicast router? Are they supposed to be on a shared link? Traffic is routable between the two? Additionally, why is that connectivity restricted from running over a tunnel? Could they be connected via AMT (draft-ietf-mboned-auto-multicast) or GRE tunnels? If not, some justification is needed since many multicast deployments use tunnels. * Section 4 jumps right into the two ways of getting multicast data to the MAG (direct routing and the MTMA) without providing any guidance as to when each of the approaches is applicable or describing *how* the modes are selected. Based on text elsewhere, I assume these modes are manually selected by the operator. It would be good to provide some operational guidance. * Section 4.1 references the "binding update list (BUL)" without any context. It would be good to provide either a brief description of what it is or a reference to the document that defines it. * Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. Based on the description of the MTMA, I assume it must utilize multicast routing protocols and should be acting as an MLD Querier. When the MAG provides its aggregated MLD Report, is that an unsolicited report or is it driven by the reception of an MLD Query? * Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy operation. The reference should point to RFC 4605. * In 4.2.2, I cannot parse the following : " ... an upstream interface of MLD Proxy instance is decided towards certain multicast router..." I would be good to reword that sentence (and possibly break it into two sentences). * Section 5.1.2, why does the option format only allow one Multicast Address Record? MLD Report messages can carry multiple address records to minimize overhead, so why the limitation here? * In general, there does not seem to be sufficient discussion of the versions of MLD (or IGMP) supported with this method. Is it strictly limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, and multicast routers utilize MLDv1? * Does the MTMA need any special considerations for support SSM or is it truly a multicast router? It is unclear as to what the differences would be between the MTMA and a multicast router, especially given the text in section 3.1 that says "The MTMA can be considered to be a form of upstream multicast router". I think there needs to be a crisper description of the MTMA. Regards, Brian From JuanCarlos.Zuniga@InterDigital.com Wed Jun 5 13:41:03 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0D21E804B for ; Wed, 5 Jun 2013 13:41: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] 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 TNp5G0wB3xLE for ; Wed, 5 Jun 2013 13:40:58 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2977D11E80A4 for ; Wed, 5 Jun 2013 13:40:57 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Jun 2013 16:40:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Jun 2013 16:40:55 -0400 Message-ID: In-Reply-To: <51AF5C82.8010703@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Evaluation : draft-ietf-multimob-pmipv6-ropt Thread-Index: Ac5iA3eAclorTR8rRlCcA7xKGBhDYgAKQzoQ References: <51AF5C82.8010703@innovationslab.net> From: "Zuniga, Juan Carlos" To: "Brian Haberman" , , X-OriginalArrivalTime: 05 Jun 2013 20:40:57.0127 (UTC) FILETIME=[FB1B3370:01CE622C] Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 20:41:03 -0000 Hi Brian, Thanks for the detailed review. We will look at the list of issues and produce a new version of the document so that we can move forward. Regards, Juan Carlos > -----Original Message----- > From: Brian Haberman [mailto:brian@innovationslab.net] > Sent: Wednesday, June 05, 2013 11:43 AM > To: multimob@ietf.org; draft-ietf-multimob-pmipv6-ropt@tools.ietf.org > Subject: AD Evaluation : draft-ietf-multimob-pmipv6-ropt >=20 > All, > Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt. Once > these issues are resolved, the draft can move to the next step in the > publication process (IETF Last Call). >=20 > * There are several explicit mentions of the Multimob WG in the > document. Those sentences should be re-worded to focus on the content > of the draft, rather than who created the draft. >=20 > * In the Intro : s/so-called tunnel convergence/tunnel convergence/ >=20 > * Is the MTMA really just a variant of an LMA (i.e., LMA handling all > multicast traffic)? If so, the definition should clarify that. >=20 > * In 3.1 : s/is used used to/is used to/ >=20 > * In 3.2, there is a reference to Figure 1 that I believe should be a > reference to Figure 2. >=20 > * In 3.2, what is meant by a "direct connection" between the MAG and a > multicast router? Are they supposed to be on a shared link? Traffic is > routable between the two? Additionally, why is that connectivity > restricted from running over a tunnel? Could they be connected via AMT > (draft-ietf-mboned-auto-multicast) or GRE tunnels? If not, some > justification is needed since many multicast deployments use tunnels. >=20 > * Section 4 jumps right into the two ways of getting multicast data to > the MAG (direct routing and the MTMA) without providing any guidance as > to when each of the approaches is applicable or describing *how* the > modes are selected. Based on text elsewhere, I assume these modes are > manually selected by the operator. It would be good to provide some > operational guidance. >=20 > * Section 4.1 references the "binding update list (BUL)" without any > context. It would be good to provide either a brief description of what > it is or a reference to the document that defines it. >=20 > * Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. > Based on the description of the MTMA, I assume it must utilize multicast > routing protocols and should be acting as an MLD Querier. When the MAG > provides its aggregated MLD Report, is that an unsolicited report or is > it driven by the reception of an MLD Query? >=20 > * Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy > operation. The reference should point to RFC 4605. >=20 > * In 4.2.2, I cannot parse the following : " ... an upstream interface > of MLD Proxy instance is decided towards certain multicast router..." I > would be good to reword that sentence (and possibly break it into two > sentences). >=20 > * Section 5.1.2, why does the option format only allow one Multicast > Address Record? MLD Report messages can carry multiple address records > to minimize overhead, so why the limitation here? >=20 > * In general, there does not seem to be sufficient discussion of the > versions of MLD (or IGMP) supported with this method. Is it strictly > limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, > and multicast routers utilize MLDv1? >=20 > * Does the MTMA need any special considerations for support SSM or is it > truly a multicast router? It is unclear as to what the differences > would be between the MTMA and a multicast router, especially given the > text in section 3.1 that says "The MTMA can be considered to be a form > of upstream multicast router". I think there needs to be a crisper > description of the MTMA. >=20 > Regards, > Brian From internet-drafts@ietf.org Tue Jun 18 06:34:28 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90F221F9EDF; Tue, 18 Jun 2013 06:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.091, 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 jn+gJQEUf3Ok; Tue, 18 Jun 2013 06:34:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EDD21F9E83; Tue, 18 Jun 2013 06:34:28 -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.51.p2 Message-ID: <20130618133428.23964.95813.idtracker@ietfa.amsl.com> Date: Tue, 18 Jun 2013 06:34:28 -0700 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-ropt-06.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:34:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multicast Mobility Working Group of the I= ETF. Title : Multicast Mobility Routing Optimizations for Proxy Mobil= e IPv6 Author(s) : Juan Carlos Zuniga Luis M. Contreras Carlos J. Bernardos Seil Jeon Younghan Kim Filename : draft-ietf-multimob-pmipv6-ropt-06.txt Pages : 27 Date : 2013-06-18 Abstract: A base solution to support IP multicasting in a PMIPv6 domain is specified in [RFC6224]. In this document, some enhancements to the base solution are described. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the MAG can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-ropt-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-ropt-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cjbc@it.uc3m.es Tue Jun 18 06:39:36 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A24221F9F4C for ; Tue, 18 Jun 2013 06:39:36 -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=[AWL=0.000, 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 1Bt+Z6f3DnOt for ; Tue, 18 Jun 2013 06:39:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0C21F9F4B for ; Tue, 18 Jun 2013 06:39:29 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0D4B9114FABF; Tue, 18 Jun 2013 15:39:29 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id EB56310FA10E; Tue, 18 Jun 2013 15:39:28 +0200 (CEST) Message-ID: <1371562768.4743.25.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Tue, 18 Jun 2013 15:39:28 +0200 In-Reply-To: <51AF5C82.8010703@innovationslab.net> References: <51AF5C82.8010703@innovationslab.net> 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-19950.007 X-TM-AS-Result: No--40.657-7.0-31-1 X-imss-scan-details: No--40.657-7.0-31-1 Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:39:36 -0000 Hi Brian, all, [Authors] Thanks Brian for the review. We have produced a new version (-06) addressing your comments. Please, see inline below for additional clarifications. On Wed, 2013-06-05 at 11:42 -0400, Brian Haberman wrote: > All, > Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt. Once > these issues are resolved, the draft can move to the next step in the > publication process (IETF Last Call). > > * There are several explicit mentions of the Multimob WG in the > document. Those sentences should be re-worded to focus on the content > of the draft, rather than who created the draft. [Authors] Fixed. > > * In the Intro : s/so-called tunnel convergence/tunnel convergence/ [Authors] Fixed. > > * Is the MTMA really just a variant of an LMA (i.e., LMA handling all > multicast traffic)? If so, the definition should clarify that. [Authors] We have improved the definition of MTMA in the terminology section: MTMA or multicast tree mobility anchor: An entity working as topological anchor point for multicast traffic. It manages the multicast groups subscribed by all (or a subset of) the MAGs in a PMIPv6 multicast domain, on behalf of the MNs attached to them. Hence, an MTMA performs the functions of either a designated multicast router or an MLD proxy. We have also added some explanatory text in Section 3.1. > > * In 3.1 : s/is used used to/is used to/ [Authors] Fixed. > > * In 3.2, there is a reference to Figure 1 that I believe should be a > reference to Figure 2. [Authors] That reference was part of some duplicated text that is already mentioned in Section 3.1. The whole sentence referencing Figure 1 in Section 3.2 has been removed. > > * In 3.2, what is meant by a "direct connection" between the MAG and a > multicast router? Are they supposed to be on a shared link? Traffic is > routable between the two? Additionally, why is that connectivity > restricted from running over a tunnel? Could they be connected via AMT > (draft-ietf-mboned-auto-multicast) or GRE tunnels? If not, some > justification is needed since many multicast deployments use tunnels. [Authors] We have tried to improve the text in Section 3.2 to clarify this point and explictily mention support for GRE and AMT tunnels: As seen in Figure 2, each MAG has a direct connection (i.e., not using the PMIPv6 tunnel interface) with a multicast router. Depending on the multicast support on the visited network, different schema can be used to provide this direct connection between the MAGs and the multicast router(s), e.g., being connected to the same shared link or using a tunneling approach, such as Generic Routing Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast Tunneling (AMT) [I-D.ietf-mboned-auto-multicast]. To facilitate IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy function defined in [RFC4605] SHOULD be implemented in the MAG. There SHOULD be direct connectivity between the MAG and the local multicast router (or additional MLD proxy). > > * Section 4 jumps right into the two ways of getting multicast data to > the MAG (direct routing and the MTMA) without providing any guidance as > to when each of the approaches is applicable or describing *how* the > modes are selected. Based on text elsewhere, I assume these modes are > manually selected by the operator. It would be good to provide some > operational guidance. [Authors] We have added a new Section 3.3 (MTMA/Direct routing mode selection), that introduces how each of the approaches can be selected. > > * Section 4.1 references the "binding update list (BUL)" without any > context. It would be good to provide either a brief description of what > it is or a reference to the document that defines it. [Authors] Fixed. > > * Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. > Based on the description of the MTMA, I assume it must utilize multicast > routing protocols and should be acting as an MLD Querier. When the MAG > provides its aggregated MLD Report, is that an unsolicited report or is > it driven by the reception of an MLD Query? [Authors] The aggregated report sent by the MAG is sent triggered by the reception of the MLD report generated by the MN (assuming that this report includes groups which the MAG had not previously subscribed to). The MTMA acts as an MLD Querier. We have re-worded a bit the text in Section 4.2.1 to make this clearer: MN1 sends the MLD report message (when required by its upper layer applications) as defined in [RFC3810] in response to an MLD Query from MAG (generated as defined by [RFC6224] upon handover). The MAG, acting as a MLD Proxy defined in [RFC4605], will then send an Aggregated MLD Report to the multicast anchor, MTMA (assuming that this is a new multicast group which the MAG had not previously subscribed to). Multicast traffic will then flow from the MTMA towards MN1. The MTMA acts as an MLD Querier, so it will periodically query each MAG about the subscriptions it maintains (not shown in Figure 3). > > * Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy > operation. The reference should point to RFC 4605. [Authors] Fixed. > > * In 4.2.2, I cannot parse the following : " ... an upstream interface > of MLD Proxy instance is decided towards certain multicast router..." I > would be good to reword that sentence (and possibly break it into two > sentences). [Authors] We have re-worded this part. > > * Section 5.1.2, why does the option format only allow one Multicast > Address Record? MLD Report messages can carry multiple address records > to minimize overhead, so why the limitation here? [Authors] We have updated the option format to remove that limitation. > > * In general, there does not seem to be sufficient discussion of the > versions of MLD (or IGMP) supported with this method. Is it strictly > limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, > and multicast routers utilize MLDv1? [Authors] We have updated the Dynamic IP Multicast Selector Option format and added additional text in Section 8 (IPv4 support) to provide additional information, as requested. > > * Does the MTMA need any special considerations for support SSM or is it > truly a multicast router? It is unclear as to what the differences > would be between the MTMA and a multicast router, especially given the > text in section 3.1 that says "The MTMA can be considered to be a form > of upstream multicast router". I think there needs to be a crisper > description of the MTMA. [Authors] As mentioned earlier, we have tried to improve the definition of MTMA in the document. Thanks, Carlos > > Regards, > Brian From brian@innovationslab.net Tue Jun 18 07:21:43 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8592F21F9EDB for ; Tue, 18 Jun 2013 07:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 kpt2+18+u8zb for ; Tue, 18 Jun 2013 07:21:37 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 017E521F9133 for ; Tue, 18 Jun 2013 07:21:36 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 8D25888130; Tue, 18 Jun 2013 07:21:36 -0700 (PDT) Received: from 10252371.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 231EC13680CF; Tue, 18 Jun 2013 07:21:36 -0700 (PDT) Message-ID: <51C06CEE.30406@innovationslab.net> Date: Tue, 18 Jun 2013 10:21:34 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> In-Reply-To: <1371562768.4743.25.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:21:43 -0000 Is there any particular reason why the option format defined in section 5.1.2 does not have a "number of MARs" field (similar to the MARs defined in 3810)? Regards, Brian On 6/18/13 9:39 AM, Carlos Jesús Bernardos Cano wrote: > Hi Brian, all, > > [Authors] Thanks Brian for the review. We have produced a new version > (-06) addressing your comments. Please, see inline below for additional > clarifications. > > On Wed, 2013-06-05 at 11:42 -0400, Brian Haberman wrote: >> All, >> Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt. Once >> these issues are resolved, the draft can move to the next step in the >> publication process (IETF Last Call). >> >> * There are several explicit mentions of the Multimob WG in the >> document. Those sentences should be re-worded to focus on the content >> of the draft, rather than who created the draft. > > [Authors] Fixed. > >> >> * In the Intro : s/so-called tunnel convergence/tunnel convergence/ > > [Authors] Fixed. > >> >> * Is the MTMA really just a variant of an LMA (i.e., LMA handling all >> multicast traffic)? If so, the definition should clarify that. > > [Authors] We have improved the definition of MTMA in the terminology > section: > > MTMA or multicast tree mobility anchor: An entity working as > topological anchor point for multicast traffic. It manages the > multicast groups subscribed by all (or a subset of) the MAGs in a > PMIPv6 multicast domain, on behalf of the MNs attached to them. > Hence, an MTMA performs the functions of either a designated > multicast router or an MLD proxy. > > We have also added some explanatory text in Section 3.1. > >> >> * In 3.1 : s/is used used to/is used to/ > > [Authors] Fixed. > >> >> * In 3.2, there is a reference to Figure 1 that I believe should be a >> reference to Figure 2. > > [Authors] That reference was part of some duplicated text that is > already mentioned in Section 3.1. The whole sentence referencing Figure > 1 in Section 3.2 has been removed. > >> >> * In 3.2, what is meant by a "direct connection" between the MAG and a >> multicast router? Are they supposed to be on a shared link? Traffic is >> routable between the two? Additionally, why is that connectivity >> restricted from running over a tunnel? Could they be connected via AMT >> (draft-ietf-mboned-auto-multicast) or GRE tunnels? If not, some >> justification is needed since many multicast deployments use tunnels. > > [Authors] We have tried to improve the text in Section 3.2 to clarify > this point and explictily mention support for GRE and AMT tunnels: > > As seen in Figure 2, each MAG has a direct connection (i.e., not > using the PMIPv6 tunnel interface) with a multicast router. > Depending on the multicast support on the visited network, different > schema can be used to provide this direct connection between the MAGs > and the multicast router(s), e.g., being connected to the same shared > link or using a tunneling approach, such as Generic Routing > Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast > Tunneling (AMT) [I-D.ietf-mboned-auto-multicast]. To facilitate > IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy > function defined in [RFC4605] SHOULD be implemented in the MAG. > There SHOULD be direct connectivity between the MAG and the local > multicast router (or additional MLD proxy). > >> >> * Section 4 jumps right into the two ways of getting multicast data to >> the MAG (direct routing and the MTMA) without providing any guidance as >> to when each of the approaches is applicable or describing *how* the >> modes are selected. Based on text elsewhere, I assume these modes are >> manually selected by the operator. It would be good to provide some >> operational guidance. > > [Authors] We have added a new Section 3.3 (MTMA/Direct routing mode > selection), that introduces how each of the approaches can be selected. > >> >> * Section 4.1 references the "binding update list (BUL)" without any >> context. It would be good to provide either a brief description of what >> it is or a reference to the document that defines it. > > [Authors] Fixed. > >> >> * Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. >> Based on the description of the MTMA, I assume it must utilize multicast >> routing protocols and should be acting as an MLD Querier. When the MAG >> provides its aggregated MLD Report, is that an unsolicited report or is >> it driven by the reception of an MLD Query? > > [Authors] The aggregated report sent by the MAG is sent triggered by > the reception of the MLD report generated by the MN (assuming that this > report includes groups which the MAG had not previously subscribed to). > The MTMA acts as an MLD Querier. We have re-worded a bit the text in > Section 4.2.1 to make this clearer: > > MN1 sends the MLD report message (when required by its upper layer > applications) as defined in [RFC3810] in response to an MLD Query > from MAG (generated as defined by [RFC6224] upon handover). The MAG, > acting as a MLD Proxy defined in [RFC4605], will then send an > Aggregated MLD Report to the multicast anchor, MTMA (assuming that > this is a new multicast group which the MAG had not previously > subscribed to). Multicast traffic will then flow from the MTMA > towards MN1. The MTMA acts as an MLD Querier, so it will > periodically query each MAG about the subscriptions it maintains (not > shown in Figure 3). > >> >> * Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy >> operation. The reference should point to RFC 4605. > > [Authors] Fixed. > >> >> * In 4.2.2, I cannot parse the following : " ... an upstream interface >> of MLD Proxy instance is decided towards certain multicast router..." I >> would be good to reword that sentence (and possibly break it into two >> sentences). > > [Authors] We have re-worded this part. > >> >> * Section 5.1.2, why does the option format only allow one Multicast >> Address Record? MLD Report messages can carry multiple address records >> to minimize overhead, so why the limitation here? > > [Authors] We have updated the option format to remove that limitation. > >> >> * In general, there does not seem to be sufficient discussion of the >> versions of MLD (or IGMP) supported with this method. Is it strictly >> limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, >> and multicast routers utilize MLDv1? > > [Authors] We have updated the Dynamic IP Multicast Selector Option > format and added additional text in Section 8 (IPv4 support) to provide > additional information, as requested. > >> >> * Does the MTMA need any special considerations for support SSM or is it >> truly a multicast router? It is unclear as to what the differences >> would be between the MTMA and a multicast router, especially given the >> text in section 3.1 that says "The MTMA can be considered to be a form >> of upstream multicast router". I think there needs to be a crisper >> description of the MTMA. > > [Authors] As mentioned earlier, we have tried to improve the definition > of MTMA in the document. > > Thanks, > > Carlos > >> >> Regards, >> Brian > From cjbc@it.uc3m.es Tue Jun 18 10:19:24 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8B11E80F0 for ; Tue, 18 Jun 2013 10:19:24 -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 j0eU4NqWMNwh for ; Tue, 18 Jun 2013 10:19:18 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1011E80E6 for ; Tue, 18 Jun 2013 10:19:17 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 67947894B2F; Tue, 18 Jun 2013 19:19:16 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 5A64B892E3B; Tue, 18 Jun 2013 19:19:16 +0200 (CEST) Message-ID: <1371575956.4743.64.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Tue, 18 Jun 2013 19:19:16 +0200 In-Reply-To: <51C06CEE.30406@innovationslab.net> References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> 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: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19952.000 X-TM-AS-Result: No--49.821-7.0-31-1 X-imss-scan-details: No--49.821-7.0-31-1 Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:19:24 -0000 Hi Brian, On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: > Is there any particular reason why the option format defined in section > 5.1.2 does not have a "number of MARs" field (similar to the MARs > defined in 3810)? Not really. The "Length" + "Protocol" fields can also be used to derive the number of MARs, without adding any additional information to the option, right? If you think it is better to add the "number of MARs" field, we can do it in a new revision of the draft. Thanks, Carlos > > Regards, > Brian > > On 6/18/13 9:39 AM, Carlos Jesús Bernardos Cano wrote: > > Hi Brian, all, > > > > [Authors] Thanks Brian for the review. We have produced a new version > > (-06) addressing your comments. Please, see inline below for additional > > clarifications. > > > > On Wed, 2013-06-05 at 11:42 -0400, Brian Haberman wrote: > >> All, > >> Here is my AD evaluation of draft-ietf-multimob-pmipv6-ropt. Once > >> these issues are resolved, the draft can move to the next step in the > >> publication process (IETF Last Call). > >> > >> * There are several explicit mentions of the Multimob WG in the > >> document. Those sentences should be re-worded to focus on the content > >> of the draft, rather than who created the draft. > > > > [Authors] Fixed. > > > >> > >> * In the Intro : s/so-called tunnel convergence/tunnel convergence/ > > > > [Authors] Fixed. > > > >> > >> * Is the MTMA really just a variant of an LMA (i.e., LMA handling all > >> multicast traffic)? If so, the definition should clarify that. > > > > [Authors] We have improved the definition of MTMA in the terminology > > section: > > > > MTMA or multicast tree mobility anchor: An entity working as > > topological anchor point for multicast traffic. It manages the > > multicast groups subscribed by all (or a subset of) the MAGs in a > > PMIPv6 multicast domain, on behalf of the MNs attached to them. > > Hence, an MTMA performs the functions of either a designated > > multicast router or an MLD proxy. > > > > We have also added some explanatory text in Section 3.1. > > > >> > >> * In 3.1 : s/is used used to/is used to/ > > > > [Authors] Fixed. > > > >> > >> * In 3.2, there is a reference to Figure 1 that I believe should be a > >> reference to Figure 2. > > > > [Authors] That reference was part of some duplicated text that is > > already mentioned in Section 3.1. The whole sentence referencing Figure > > 1 in Section 3.2 has been removed. > > > >> > >> * In 3.2, what is meant by a "direct connection" between the MAG and a > >> multicast router? Are they supposed to be on a shared link? Traffic is > >> routable between the two? Additionally, why is that connectivity > >> restricted from running over a tunnel? Could they be connected via AMT > >> (draft-ietf-mboned-auto-multicast) or GRE tunnels? If not, some > >> justification is needed since many multicast deployments use tunnels. > > > > [Authors] We have tried to improve the text in Section 3.2 to clarify > > this point and explictily mention support for GRE and AMT tunnels: > > > > As seen in Figure 2, each MAG has a direct connection (i.e., not > > using the PMIPv6 tunnel interface) with a multicast router. > > Depending on the multicast support on the visited network, different > > schema can be used to provide this direct connection between the MAGs > > and the multicast router(s), e.g., being connected to the same shared > > link or using a tunneling approach, such as Generic Routing > > Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast > > Tunneling (AMT) [I-D.ietf-mboned-auto-multicast]. To facilitate > > IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy > > function defined in [RFC4605] SHOULD be implemented in the MAG. > > There SHOULD be direct connectivity between the MAG and the local > > multicast router (or additional MLD proxy). > > > >> > >> * Section 4 jumps right into the two ways of getting multicast data to > >> the MAG (direct routing and the MTMA) without providing any guidance as > >> to when each of the approaches is applicable or describing *how* the > >> modes are selected. Based on text elsewhere, I assume these modes are > >> manually selected by the operator. It would be good to provide some > >> operational guidance. > > > > [Authors] We have added a new Section 3.3 (MTMA/Direct routing mode > > selection), that introduces how each of the approaches can be selected. > > > >> > >> * Section 4.1 references the "binding update list (BUL)" without any > >> context. It would be good to provide either a brief description of what > >> it is or a reference to the document that defines it. > > > > [Authors] Fixed. > > > >> > >> * Figure 3 does not show any MLD/IGMP traffic coming from the MTMA. > >> Based on the description of the MTMA, I assume it must utilize multicast > >> routing protocols and should be acting as an MLD Querier. When the MAG > >> provides its aggregated MLD Report, is that an unsolicited report or is > >> it driven by the reception of an MLD Query? > > > > [Authors] The aggregated report sent by the MAG is sent triggered by > > the reception of the MLD report generated by the MN (assuming that this > > report includes groups which the MAG had not previously subscribed to). > > The MTMA acts as an MLD Querier. We have re-worded a bit the text in > > Section 4.2.1 to make this clearer: > > > > MN1 sends the MLD report message (when required by its upper layer > > applications) as defined in [RFC3810] in response to an MLD Query > > from MAG (generated as defined by [RFC6224] upon handover). The MAG, > > acting as a MLD Proxy defined in [RFC4605], will then send an > > Aggregated MLD Report to the multicast anchor, MTMA (assuming that > > this is a new multicast group which the MAG had not previously > > subscribed to). Multicast traffic will then flow from the MTMA > > towards MN1. The MTMA acts as an MLD Querier, so it will > > periodically query each MAG about the subscriptions it maintains (not > > shown in Figure 3). > > > >> > >> * Section 4.2.2 references RFC 3810 when it is talking about MLD Proxy > >> operation. The reference should point to RFC 4605. > > > > [Authors] Fixed. > > > >> > >> * In 4.2.2, I cannot parse the following : " ... an upstream interface > >> of MLD Proxy instance is decided towards certain multicast router..." I > >> would be good to reword that sentence (and possibly break it into two > >> sentences). > > > > [Authors] We have re-worded this part. > > > >> > >> * Section 5.1.2, why does the option format only allow one Multicast > >> Address Record? MLD Report messages can carry multiple address records > >> to minimize overhead, so why the limitation here? > > > > [Authors] We have updated the option format to remove that limitation. > > > >> > >> * In general, there does not seem to be sufficient discussion of the > >> versions of MLD (or IGMP) supported with this method. Is it strictly > >> limited to MLDv2 (hence the reference to RFC 3810) or can MAGs, MTMAs, > >> and multicast routers utilize MLDv1? > > > > [Authors] We have updated the Dynamic IP Multicast Selector Option > > format and added additional text in Section 8 (IPv4 support) to provide > > additional information, as requested. > > > >> > >> * Does the MTMA need any special considerations for support SSM or is it > >> truly a multicast router? It is unclear as to what the differences > >> would be between the MTMA and a multicast router, especially given the > >> text in section 3.1 that says "The MTMA can be considered to be a form > >> of upstream multicast router". I think there needs to be a crisper > >> description of the MTMA. > > > > [Authors] As mentioned earlier, we have tried to improve the definition > > of MTMA in the document. > > > > Thanks, > > > > Carlos > > > >> > >> Regards, > >> Brian > > > From brian@innovationslab.net Tue Jun 18 15:39:49 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789BE11E8112 for ; Tue, 18 Jun 2013 15:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 cHj3-ySEky4Y for ; Tue, 18 Jun 2013 15:39:43 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD221F8952 for ; Tue, 18 Jun 2013 15:39:25 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B2A6B88130; Tue, 18 Jun 2013 15:39:24 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 165B813680CF; Tue, 18 Jun 2013 15:39:23 -0700 (PDT) Message-ID: <51C0E197.5070106@innovationslab.net> Date: Tue, 18 Jun 2013 18:39:19 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> In-Reply-To: <1371575956.4743.64.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:39:49 -0000 On 6/18/13 1:19 PM, Carlos Jesús Bernardos Cano wrote: > Hi Brian, > > On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: >> Is there any particular reason why the option format defined in section >> 5.1.2 does not have a "number of MARs" field (similar to the MARs >> defined in 3810)? > > Not really. The "Length" + "Protocol" fields can also be used to derive > the number of MARs, without adding any additional information to the > option, right? > It can, but adding an explicit count of the records gives you the ability to do some error checking. > If you think it is better to add the "number of MARs" field, we can do > it in a new revision of the draft. I wouldn't say it is better, just more robust. I would rather have the spec represent what has been implemented. Regards, Brian From iesg-secretary@ietf.org Wed Jun 19 08:17:51 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D8121F8FB3; Wed, 19 Jun 2013 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.280, 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 UnZCuf3YA1tb; Wed, 19 Jun 2013 08:17:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1920621F8EFE; Wed, 19 Jun 2013 08:17:47 -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.51.p2 Sender: Message-ID: <20130619151746.482.38112.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 08:17:46 -0700 Cc: multimob@ietf.org Subject: [multimob] Last Call: (Multicast Mobility Routing Optimizations for Proxy Mobile IPv6) to Informational RFC X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:17:51 -0000 The IESG has received a request from the Multicast Mobility WG (multimob) to consider the following document: - 'Multicast Mobility Routing Optimizations for Proxy Mobile IPv6' 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-07-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 A base solution to support IP multicasting in a PMIPv6 domain is specified in [RFC6224]. In this document, some enhancements to the base solution are described. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the MAG can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployment scenarios. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-ropt/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2075/ http://datatracker.ietf.org/ipr/2074/ http://datatracker.ietf.org/ipr/1723/ http://datatracker.ietf.org/ipr/2077/ From cjbc@it.uc3m.es Wed Jun 19 08:41:25 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1053B21F9CAB for ; Wed, 19 Jun 2013 08:41:25 -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 p+XiMKhFOD9M for ; Wed, 19 Jun 2013 08:41:19 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id CAB6521F9A7B for ; Wed, 19 Jun 2013 08:41:09 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E9A2E86C224; Wed, 19 Jun 2013 17:41:01 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id DC1D076712A; Wed, 19 Jun 2013 17:41:01 +0200 (CEST) Message-ID: <1371656462.4479.23.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Wed, 19 Jun 2013 17:41:02 +0200 In-Reply-To: <51C0E197.5070106@innovationslab.net> References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> 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: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19956.000 X-TM-AS-Result: No--28.700-7.0-31-1 X-imss-scan-details: No--28.700-7.0-31-1 Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:41:25 -0000 Hi Brian, On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: > On 6/18/13 1:19 PM, Carlos Jesús Bernardos Cano wrote: > > Hi Brian, > > > > On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: > >> Is there any particular reason why the option format defined in section > >> 5.1.2 does not have a "number of MARs" field (similar to the MARs > >> defined in 3810)? > > > > Not really. The "Length" + "Protocol" fields can also be used to derive > > the number of MARs, without adding any additional information to the > > option, right? > > > > It can, but adding an explicit count of the records gives you the > ability to do some error checking. > > > If you think it is better to add the "number of MARs" field, we can do > > it in a new revision of the draft. > > I wouldn't say it is better, just more robust. I would rather have the > spec represent what has been implemented. At the moment we have not yet implemented the multiple MAR option, so either solution would be equally feasible. Since you believe having an explicit counter is more robust, we can add the option. If there are no more comments from you or the group, we can make the change and produce a new version. BTW, I've just seen that IETF LC has been started on the document, but as Informational RFC. There was discussion within the WG about the intended status and the result was to make it Experimental. Is it a problem that the LC is initiated for Informational status? Thanks, Carlos > > Regards, > Brian > From brian@innovationslab.net Wed Jun 19 08:49:44 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07EE21F9D73 for ; Wed, 19 Jun 2013 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.613 X-Spam-Level: X-Spam-Status: No, score=-102.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 6FChKuFZEy72 for ; Wed, 19 Jun 2013 08:49:38 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 722EE21F9D71 for ; Wed, 19 Jun 2013 08:49:38 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 67A6788114; Wed, 19 Jun 2013 08:49:38 -0700 (PDT) Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id D8838130003; Wed, 19 Jun 2013 08:49:37 -0700 (PDT) Message-ID: <51C1D311.9020407@innovationslab.net> Date: Wed, 19 Jun 2013 11:49:37 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> <1371656462.4479.23.camel@acorde.it.uc3m.es> In-Reply-To: <1371656462.4479.23.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:49:44 -0000 On 6/19/13 11:41 AM, Carlos Jesús Bernardos Cano wrote: > Hi Brian, > > On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: >> On 6/18/13 1:19 PM, Carlos Jesús Bernardos Cano wrote: >>> Hi Brian, >>> >>> On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: >>>> Is there any particular reason why the option format defined in section >>>> 5.1.2 does not have a "number of MARs" field (similar to the MARs >>>> defined in 3810)? >>> >>> Not really. The "Length" + "Protocol" fields can also be used to derive >>> the number of MARs, without adding any additional information to the >>> option, right? >>> >> >> It can, but adding an explicit count of the records gives you the >> ability to do some error checking. >> >>> If you think it is better to add the "number of MARs" field, we can do >>> it in a new revision of the draft. >> >> I wouldn't say it is better, just more robust. I would rather have the >> spec represent what has been implemented. > > At the moment we have not yet implemented the multiple MAR option, so > either solution would be equally feasible. Since you believe having an > explicit counter is more robust, we can add the option. That is up to you. It may be worth waiting until you get additional comments. > > If there are no more comments from you or the group, we can make the > change and produce a new version. > > BTW, I've just seen that IETF LC has been started on the document, but > as Informational RFC. There was discussion within the WG about the > intended status and the result was to make it Experimental. Is it a > problem that the LC is initiated for Informational status? Informational and Experimental are equivalent. If the WG decides to change to Experimental, it can be done without another IETF Last Call. Regards, Brian From sarikaya2012@gmail.com Wed Jun 19 08:59:48 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FB021F9DB1 for ; Wed, 19 Jun 2013 08:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 VRzlRZBoHPQZ for ; Wed, 19 Jun 2013 08:59:44 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7495621F9D96 for ; Wed, 19 Jun 2013 08:59:43 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id o10so4804513lbi.25 for ; Wed, 19 Jun 2013 08:59:42 -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=OOuNkJsoO11B4C/zZBa/ARoldvh4wXOTZmrQ5Yq/2EQ=; b=HsyS9Cq2d6kUo012Q4qMf2TslB22QUty/EPXnZJzdGuOFdXSs1Mgd0wXW6YuZs8vuZ MGgQJMQvJJE1QCM56cNYYtnIM1ri0ug9UYI8ySqkWz2aGUGKfQnEeRj/DhiadcWAqtZV /NEcxNd24BjGvNqFjtEBEmMqNt0c63/KmUrFZV27FZI5VZZTFjJEx1tuaksSchf9BaZs ZAT0dnbBLSRwtRPEk481TKFEdNBTgfuIL5u5Wp/JiMtngVJAJEKiF4zXziahELtUvzAr GmcdoQSXZhk6+MAdxudfWftb3jP9XLfyqxJ4vK3iTPDGdhO+Hud2XOLZD/2IeI7Sc8eP zoSw== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr3576954lbr.53.1371657582338; Wed, 19 Jun 2013 08:59:42 -0700 (PDT) Received: by 10.114.186.104 with HTTP; Wed, 19 Jun 2013 08:59:42 -0700 (PDT) In-Reply-To: <51C1D311.9020407@innovationslab.net> References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> <1371656462.4479.23.camel@acorde.it.uc3m.es> <51C1D311.9020407@innovationslab.net> Date: Wed, 19 Jun 2013 10:59:42 -0500 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=001a1133d17af2e96804df83ea52 Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:59:48 -0000 --001a1133d17af2e96804df83ea52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks, Here is the discussion on the ropt draft so far. If you have additional comments please post now, do not wait because the draft is now on IETF Last Call. Also we need to confirm that this draft should be experimental not informational. Regards, Behcet On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman wrote: > On 6/19/13 11:41 AM, Carlos Jes=FAs Bernardos Cano wrote: > >> Hi Brian, >> >> On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: >> >>> On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano wrote: >>> >>>> Hi Brian, >>>> >>>> On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: >>>> >>>>> Is there any particular reason why the option format defined in secti= on >>>>> 5.1.2 does not have a "number of MARs" field (similar to the MARs >>>>> defined in 3810)? >>>>> >>>> >>>> Not really. The "Length" + "Protocol" fields can also be used to deriv= e >>>> the number of MARs, without adding any additional information to the >>>> option, right? >>>> >>>> >>> It can, but adding an explicit count of the records gives you the >>> ability to do some error checking. >>> >>> If you think it is better to add the "number of MARs" field, we can do >>>> it in a new revision of the draft. >>>> >>> >>> I wouldn't say it is better, just more robust. I would rather have the >>> spec represent what has been implemented. >>> >> >> At the moment we have not yet implemented the multiple MAR option, so >> either solution would be equally feasible. Since you believe having an >> explicit counter is more robust, we can add the option. >> > > That is up to you. It may be worth waiting until you get additional > comments. > > > >> If there are no more comments from you or the group, we can make the >> change and produce a new version. >> >> BTW, I've just seen that IETF LC has been started on the document, but >> as Informational RFC. There was discussion within the WG about the >> intended status and the result was to make it Experimental. Is it a >> problem that the LC is initiated for Informational status? >> > > Informational and Experimental are equivalent. If the WG decides to > change to Experimental, it can be done without another IETF Last Call. > > > Regards, > Brian > > > ______________________________**_________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/**listinfo/multimob > --001a1133d17af2e96804df83ea52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

Here is the discussion on the ropt draft so far.

If y= ou have additional comments please post now, do not wait because the draft = is now on IETF Last Call.

Also we need to confirm that this draft sh= ould be experimental not informational.

Regards,

Behcet

On Wed, Jun 19= , 2013 at 10:49 AM, Brian Haberman <brian@innovationslab.net>= ; wrote:
On 6/19/13 11:41 AM, Carlo= s Jes=FAs Bernardos Cano wrote:
Hi Brian,

On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote:
On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano wrote:
Hi Brian,

On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote:
Is there any particular reason why the option format defined in section
5.1.2 does not have a "number of MARs" field (similar to the MARs=
defined in 3810)?

Not really. The "Length" + "Protocol" fields can also b= e used to derive
the number of MARs, without adding any additional information to the
option, right?


It can, but adding an explicit count of the records gives you the
ability to do some error checking.

If you think it is better to add the "number of MARs" field, we c= an do
it in a new revision of the draft.

I wouldn't say it is better, just more robust. =A0I would rather have t= he
spec represent what has been implemented.

At the moment we have not yet implemented the multiple MAR option, so
either solution would be equally feasible. Since you believe having an
explicit counter is more robust, we can add the option.

That is up to you. =A0It may be worth waiting until you get additional comm= ents.



If there are no more comments from you or the group, we can make the
change and produce a new version.

BTW, I've just seen that IETF LC has been started on the document, but<= br> as Informational RFC. There was discussion within the WG about the
intended status and the result was to make it Experimental. Is it a
problem that the LC is initiated for Informational status?

Informational and Experimental are equivalent. =A0If the WG decides to chan= ge to Experimental, it can be done without another IETF Last Call.


Regards,
Brian


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

--001a1133d17af2e96804df83ea52-- From cjbc@it.uc3m.es Wed Jun 19 09:04:42 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CA221F9DE6 for ; Wed, 19 Jun 2013 09:04:42 -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=[AWL=0.000, 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 rZsP1jhA3Jfr for ; Wed, 19 Jun 2013 09:04:36 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8396721F9E0C for ; Wed, 19 Jun 2013 09:04:23 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F0EDC110AA70; Wed, 19 Jun 2013 18:04:21 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id DD1F710E9533; Wed, 19 Jun 2013 18:04:21 +0200 (CEST) Message-ID: <1371657861.4479.35.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Brian Haberman Date: Wed, 19 Jun 2013 18:04:21 +0200 In-Reply-To: <51C1D311.9020407@innovationslab.net> References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> <1371656462.4479.23.camel@acorde.it.uc3m.es> <51C1D311.9020407@innovationslab.net> 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: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-19956.000 X-TM-AS-Result: No--33.006-7.0-31-1 X-imss-scan-details: No--33.006-7.0-31-1 Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:04:42 -0000 Hi Brian, OK, thanks for the clarifications. Carlos On Wed, 2013-06-19 at 11:49 -0400, Brian Haberman wrote: > On 6/19/13 11:41 AM, Carlos Jesús Bernardos Cano wrote: > > Hi Brian, > > > > On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: > >> On 6/18/13 1:19 PM, Carlos Jesús Bernardos Cano wrote: > >>> Hi Brian, > >>> > >>> On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: > >>>> Is there any particular reason why the option format defined in section > >>>> 5.1.2 does not have a "number of MARs" field (similar to the MARs > >>>> defined in 3810)? > >>> > >>> Not really. The "Length" + "Protocol" fields can also be used to derive > >>> the number of MARs, without adding any additional information to the > >>> option, right? > >>> > >> > >> It can, but adding an explicit count of the records gives you the > >> ability to do some error checking. > >> > >>> If you think it is better to add the "number of MARs" field, we can do > >>> it in a new revision of the draft. > >> > >> I wouldn't say it is better, just more robust. I would rather have the > >> spec represent what has been implemented. > > > > At the moment we have not yet implemented the multiple MAR option, so > > either solution would be equally feasible. Since you believe having an > > explicit counter is more robust, we can add the option. > > That is up to you. It may be worth waiting until you get additional > comments. > > > > > If there are no more comments from you or the group, we can make the > > change and produce a new version. > > > > BTW, I've just seen that IETF LC has been started on the document, but > > as Informational RFC. There was discussion within the WG about the > > intended status and the result was to make it Experimental. Is it a > > problem that the LC is initiated for Informational status? > > Informational and Experimental are equivalent. If the WG decides to > change to Experimental, it can be done without another IETF Last Call. > > Regards, > Brian > > From stig@venaas.com Wed Jun 19 11:04:25 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C88521F9E04 for ; Wed, 19 Jun 2013 11:04:25 -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=[AWL=0.000, 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 cvFL+Hb4jUKG for ; Wed, 19 Jun 2013 11:04:24 -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 D66CD21F9E03 for ; Wed, 19 Jun 2013 11:04:23 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-235.cisco.com [128.107.239.235]) by ufisa.uninett.no (Postfix) with ESMTPSA id A773E7FF4; Wed, 19 Jun 2013 20:04:12 +0200 (CEST) Message-ID: <51C1F29A.9060702@venaas.com> Date: Wed, 19 Jun 2013 11:04:10 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sarikaya@ieee.org References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> <1371656462.4479.23.camel@acorde.it.uc3m.es> <51C1D311.9020407@innovationslab.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org, Behcet Sarikaya Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:04:25 -0000 On 6/19/2013 8:59 AM, Behcet Sarikaya wrote: > Folks, > > Here is the discussion on the ropt draft so far. > > If you have additional comments please post now, do not wait because the > draft is now on IETF Last Call. Personally I think a MARs counter could be useful. > Also we need to confirm that this draft should be experimental not > informational. For this, please read http://www.ietf.org/iesg/informational-vs-experimental.html first, and then try to see what looks the most appropriate. Stig > Regards, > > Behcet > > On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman > > wrote: > > On 6/19/13 11:41 AM, Carlos Jesús Bernardos Cano wrote: > > Hi Brian, > > On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: > > On 6/18/13 1:19 PM, Carlos Jesús Bernardos Cano wrote: > > Hi Brian, > > On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: > > Is there any particular reason why the option format > defined in section > 5.1.2 does not have a "number of MARs" field > (similar to the MARs > defined in 3810)? > > > Not really. The "Length" + "Protocol" fields can also be > used to derive > the number of MARs, without adding any additional > information to the > option, right? > > > It can, but adding an explicit count of the records gives > you the > ability to do some error checking. > > If you think it is better to add the "number of MARs" > field, we can do > it in a new revision of the draft. > > > I wouldn't say it is better, just more robust. I would > rather have the > spec represent what has been implemented. > > > At the moment we have not yet implemented the multiple MAR > option, so > either solution would be equally feasible. Since you believe > having an > explicit counter is more robust, we can add the option. > > > That is up to you. It may be worth waiting until you get additional > comments. > > > > If there are no more comments from you or the group, we can make the > change and produce a new version. > > BTW, I've just seen that IETF LC has been started on the > document, but > as Informational RFC. There was discussion within the WG about the > intended status and the result was to make it Experimental. Is it a > problem that the LC is initiated for Informational status? > > > Informational and Experimental are equivalent. If the WG decides to > change to Experimental, it can be done without another IETF Last Call. > > > Regards, > Brian > > > _________________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From JuanCarlos.Zuniga@InterDigital.com Wed Jun 19 11:23:16 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941E21F9E30 for ; Wed, 19 Jun 2013 11:23:16 -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 Ic-dyneD8UXG for ; Wed, 19 Jun 2013 11:23:12 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9845F21F9A11 for ; Wed, 19 Jun 2013 11:23:02 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 14:23:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jun 2013 14:23:00 -0400 Message-ID: In-Reply-To: <51C1F29A.9060702@venaas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt Thread-Index: Ac5tF64NGzYit+EDQEqHDMQwIEf2LAAAeb4A References: <51AF5C82.8010703@innovationslab.net><1371562768.4743.25.camel@acorde.it.uc3m.es><51C06CEE.30406@innovationslab.net><1371575956.4743.64.camel@acorde.it.uc3m.es><51C0E197.5070106@innovationslab.net><1371656462.4479.23.camel@acorde.it.uc3m.es><51C1D311.9020407@innovationslab.net> <51C1F29A.9060702@venaas.com> From: "Zuniga, Juan Carlos" To: "Stig Venaas" , X-OriginalArrivalTime: 19 Jun 2013 18:23:00.0892 (UTC) FILETIME=[07DE75C0:01CE6D1A] Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, Behcet Sarikaya Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 18:23:16 -0000 Hi Stig, all, > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf > Of Stig Venaas > Sent: Wednesday, June 19, 2013 2:04 PM > To: sarikaya@ieee.org > Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org; multimob@ietf.org; = Behcet > Sarikaya > Subject: Re: [multimob] AD Evaluation : = draft-ietf-multimob-pmipv6-ropt >=20 > On 6/19/2013 8:59 AM, Behcet Sarikaya wrote: > > Folks, > > > > Here is the discussion on the ropt draft so far. > > > > If you have additional comments please post now, do not wait because = the > > draft is now on IETF Last Call. >=20 > Personally I think a MARs counter could be useful. [JCZ] Seems like we have a preference for adding the counter, so my = recommendation would be to add it at the next revision. >=20 > > Also we need to confirm that this draft should be experimental not > > informational. >=20 > For this, please read > http://www.ietf.org/iesg/informational-vs-experimental.html > first, and then try to see what looks the most appropriate. [JCZ] Thanks for sending the link. After reading through it, I = personally believe Experimental is more appropriate. Regards, Juan Carlos=20 >=20 > Stig >=20 > > Regards, > > > > Behcet > > > > On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman > > > wrote: > > > > On 6/19/13 11:41 AM, Carlos Jes=FAs Bernardos Cano wrote: > > > > Hi Brian, > > > > On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: > > > > On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano wrote: > > > > Hi Brian, > > > > On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman = wrote: > > > > Is there any particular reason why the option = format > > defined in section > > 5.1.2 does not have a "number of MARs" field > > (similar to the MARs > > defined in 3810)? > > > > > > Not really. The "Length" + "Protocol" fields can = also be > > used to derive > > the number of MARs, without adding any additional > > information to the > > option, right? > > > > > > It can, but adding an explicit count of the records = gives > > you the > > ability to do some error checking. > > > > If you think it is better to add the "number of = MARs" > > field, we can do > > it in a new revision of the draft. > > > > > > I wouldn't say it is better, just more robust. I would > > rather have the > > spec represent what has been implemented. > > > > > > At the moment we have not yet implemented the multiple MAR > > option, so > > either solution would be equally feasible. Since you believe > > having an > > explicit counter is more robust, we can add the option. > > > > > > That is up to you. It may be worth waiting until you get = additional > > comments. > > > > > > > > If there are no more comments from you or the group, we can = make the > > change and produce a new version. > > > > BTW, I've just seen that IETF LC has been started on the > > document, but > > as Informational RFC. There was discussion within the WG = about the > > intended status and the result was to make it Experimental. = Is it a > > problem that the LC is initiated for Informational status? > > > > > > Informational and Experimental are equivalent. If the WG = decides to > > change to Experimental, it can be done without another IETF Last = Call. > > > > > > Regards, > > Brian > > > > > > _________________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From Akbar.Rahman@InterDigital.com Fri Jun 21 08:47:19 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1121E811B for ; Fri, 21 Jun 2013 08:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 texJ6x9KCtho for ; Fri, 21 Jun 2013 08:47:15 -0700 (PDT) Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 14FC521E8128 for ; Fri, 21 Jun 2013 08:47:11 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Jun 2013 11:47:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 2013 11:47:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt Thread-Index: Ac5tF64NGzYit+EDQEqHDMQwIEf2LAAAeb4AAF8u/RA= References: <51AF5C82.8010703@innovationslab.net><1371562768.4743.25.camel@acorde.it.uc3m.es><51C06CEE.30406@innovationslab.net><1371575956.4743.64.camel@acorde.it.uc3m.es><51C0E197.5070106@innovationslab.net><1371656462.4479.23.camel@acorde.it.uc3m.es><51C1D311.9020407@innovationslab.net><51C1F29A.9060702@venaas.com> From: "Rahman, Akbar" To: "Zuniga, Juan Carlos" , "Stig Venaas" , X-OriginalArrivalTime: 21 Jun 2013 15:47:10.0504 (UTC) FILETIME=[976DFA80:01CE6E96] Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org, Behcet Sarikaya Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:47:19 -0000 I also vote for making it Experimental as I have heard off line various = times that people would like to implement these ideas on running code = and see the performance results. Best Regards, Akbar -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Zuniga, Juan Carlos Sent: Wednesday, June 19, 2013 2:23 PM To: Stig Venaas; sarikaya@ieee.org Cc: multimob@ietf.org; draft-ietf-multimob-pmipv6-ropt@tools.ietf.org; = Behcet Sarikaya Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt Hi Stig, all, > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On=20 > Behalf Of Stig Venaas > Sent: Wednesday, June 19, 2013 2:04 PM > To: sarikaya@ieee.org > Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org; multimob@ietf.org; = > Behcet Sarikaya > Subject: Re: [multimob] AD Evaluation :=20 > draft-ietf-multimob-pmipv6-ropt >=20 > On 6/19/2013 8:59 AM, Behcet Sarikaya wrote: > > Folks, > > > > Here is the discussion on the ropt draft so far. > > > > If you have additional comments please post now, do not wait because = > > the draft is now on IETF Last Call. >=20 > Personally I think a MARs counter could be useful. [JCZ] Seems like we have a preference for adding the counter, so my = recommendation would be to add it at the next revision. >=20 > > Also we need to confirm that this draft should be experimental not=20 > > informational. >=20 > For this, please read > http://www.ietf.org/iesg/informational-vs-experimental.html > first, and then try to see what looks the most appropriate. [JCZ] Thanks for sending the link. After reading through it, I = personally believe Experimental is more appropriate. Regards, Juan Carlos=20 >=20 > Stig >=20 > > Regards, > > > > Behcet > > > > On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman=20 > > > wrote: > > > > On 6/19/13 11:41 AM, Carlos Jes=FAs Bernardos Cano wrote: > > > > Hi Brian, > > > > On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: > > > > On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano wrote: > > > > Hi Brian, > > > > On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman = wrote: > > > > Is there any particular reason why the option = format > > defined in section > > 5.1.2 does not have a "number of MARs" field > > (similar to the MARs > > defined in 3810)? > > > > > > Not really. The "Length" + "Protocol" fields can = also be > > used to derive > > the number of MARs, without adding any additional > > information to the > > option, right? > > > > > > It can, but adding an explicit count of the records = gives > > you the > > ability to do some error checking. > > > > If you think it is better to add the "number of = MARs" > > field, we can do > > it in a new revision of the draft. > > > > > > I wouldn't say it is better, just more robust. I would > > rather have the > > spec represent what has been implemented. > > > > > > At the moment we have not yet implemented the multiple MAR > > option, so > > either solution would be equally feasible. Since you believe > > having an > > explicit counter is more robust, we can add the option. > > > > > > That is up to you. It may be worth waiting until you get = additional > > comments. > > > > > > > > If there are no more comments from you or the group, we can = make the > > change and produce a new version. > > > > BTW, I've just seen that IETF LC has been started on the > > document, but > > as Informational RFC. There was discussion within the WG = about the > > intended status and the result was to make it Experimental. = Is it a > > problem that the LC is initiated for Informational status? > > > > > > Informational and Experimental are equivalent. If the WG = decides to > > change to Experimental, it can be done without another IETF Last = Call. > > > > > > Regards, > > Brian > > > > > > _________________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/__listinfo/multimob > > > > > > > > > > > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > >=20 > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From sarikaya2012@gmail.com Wed Jun 26 14:54:11 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B611E8142 for ; Wed, 26 Jun 2013 14:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 IqPWcUlSvUwF for ; Wed, 26 Jun 2013 14:53:59 -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 098B521F9ACB for ; Wed, 26 Jun 2013 14:53:28 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ea20so14060237lab.22 for ; Wed, 26 Jun 2013 14:52:41 -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=YNGmWXY5hWGSmkeA4/MrlizxvKWHNTMjOnn/RXiGdFI=; b=SNu7BEP+mXEBAi9UySYNClePFT1KinhTcfWy3A+ydjxnRy5O7pPdBt/MUNXapB0tID Y6QgTGs9g6OL7kl2d236hreiyeAAfsgHptclojea3w4iyQ/mU8PKKKPsSTFkF9zz3CvK E4g0988RDBqS1bqZTpMdZEPjgXlLixiKVP3J3xC7Ae5iPOIDjGiDI7sS75XP8KIl6MSP vxh/ZALDsqdSeJCcrllXrH2k8roXXSTZgX/SHrihGIxDjRUkdGX6AXp0AYnmxkMzHR2V Q5lSisp1SGiV153IVYwvNchKzAyugGpPqr4XrJCodZDLUgOSswJ1adTcQvzbJ6eqwUEA hvTw== MIME-Version: 1.0 X-Received: by 10.112.125.199 with SMTP id ms7mr2999930lbb.29.1372283561788; Wed, 26 Jun 2013 14:52:41 -0700 (PDT) Received: by 10.114.186.104 with HTTP; Wed, 26 Jun 2013 14:52:41 -0700 (PDT) In-Reply-To: <51C1F29A.9060702@venaas.com> References: <51AF5C82.8010703@innovationslab.net> <1371562768.4743.25.camel@acorde.it.uc3m.es> <51C06CEE.30406@innovationslab.net> <1371575956.4743.64.camel@acorde.it.uc3m.es> <51C0E197.5070106@innovationslab.net> <1371656462.4479.23.camel@acorde.it.uc3m.es> <51C1D311.9020407@innovationslab.net> <51C1F29A.9060702@venaas.com> Date: Wed, 26 Jun 2013 16:52:41 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: multipart/alternative; boundary=089e012284fa3b48fc04e015aa2d Cc: draft-ietf-multimob-pmipv6-ropt@tools.ietf.org, multimob@ietf.org Subject: Re: [multimob] AD Evaluation : draft-ietf-multimob-pmipv6-ropt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:54:12 -0000 --089e012284fa3b48fc04e015aa2d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2013 at 1:04 PM, Stig Venaas wrote: > On 6/19/2013 8:59 AM, Behcet Sarikaya wrote: > >> Folks, >> >> Here is the discussion on the ropt draft so far. >> >> If you have additional comments please post now, do not wait because the >> draft is now on IETF Last Call. >> > > Personally I think a MARs counter could be useful. > > I also agree. > > Also we need to confirm that this draft should be experimental not >> informational. >> > > For this, please read > http://www.ietf.org/iesg/**informational-vs-experimental.**html > first, and then try to see what looks the most appropriate. > > Of course Experimental looks the most appropriate. Regards, Behcet > Stig > > Regards, >> >> Behcet >> >> On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman >> >> >> wrote: >> >> On 6/19/13 11:41 AM, Carlos Jes=FAs Bernardos Cano wrote: >> >> Hi Brian, >> >> On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote: >> >> On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano wrote: >> >> Hi Brian, >> >> On Tue, 2013-06-18 at 10:21 -0400, Brian Haberman wrote: >> >> Is there any particular reason why the option format >> defined in section >> 5.1.2 does not have a "number of MARs" field >> (similar to the MARs >> defined in 3810)? >> >> >> Not really. The "Length" + "Protocol" fields can also be >> used to derive >> the number of MARs, without adding any additional >> information to the >> option, right? >> >> >> It can, but adding an explicit count of the records gives >> you the >> ability to do some error checking. >> >> If you think it is better to add the "number of MARs" >> field, we can do >> it in a new revision of the draft. >> >> >> I wouldn't say it is better, just more robust. I would >> rather have the >> spec represent what has been implemented. >> >> >> At the moment we have not yet implemented the multiple MAR >> option, so >> either solution would be equally feasible. Since you believe >> having an >> explicit counter is more robust, we can add the option. >> >> >> That is up to you. It may be worth waiting until you get additional >> comments. >> >> >> >> If there are no more comments from you or the group, we can make >> the >> change and produce a new version. >> >> BTW, I've just seen that IETF LC has been started on the >> document, but >> as Informational RFC. There was discussion within the WG about t= he >> intended status and the result was to make it Experimental. Is i= t >> a >> problem that the LC is initiated for Informational status? >> >> >> Informational and Experimental are equivalent. If the WG decides to >> change to Experimental, it can be done without another IETF Last Cal= l. >> >> >> Regards, >> Brian >> >> >> ______________________________**___________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/multimob >> >> > >> >> >> >> >> >> ______________________________**_________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/**listinfo/multimob >> >> > --089e012284fa3b48fc04e015aa2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 19, 2013 at 1:04 PM, Stig Ve= naas <stig@venaas.com> wrote:
On 6/19/2013 8:59 AM, Behcet Sarikaya wrote:
Folks,

Here is the discussion on the ropt draft so far.

If you have additional comments please post now, do not wait because the draft is now on IETF Last Call.

Personally I think a MARs counter could be useful.


I also agree.

Also we need to confirm that this draft should be experimental not
informational.

For this, please read
http://www.ietf.org/iesg/informational-vs-experimenta= l.html
first, and then try to see what looks the most appropriate.


Of course Experimental looks the most appropriate= .

Regards,

Behcet
Stig

Regards,

Behcet

On Wed, Jun 19, 2013 at 10:49 AM, Brian Haberman
<brian@inn= ovationslab.net <mailto:brian@innovationslab.net>> wrote:

=A0 =A0 On 6/19/13 11:41 AM, Carlos Jes=FAs Bernardos Cano wrote:

=A0 =A0 =A0 =A0 Hi Brian,

=A0 =A0 =A0 =A0 On Tue, 2013-06-18 at 18:39 -0400, Brian Haberman wrote:
=A0 =A0 =A0 =A0 =A0 =A0 On 6/18/13 1:19 PM, Carlos Jes=FAs Bernardos Cano w= rote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi Brian,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On Tue, 2013-06-18 at 10:21 -0400, Brian Ha= berman wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Is there any particular reason why = the option format
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defined in section
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5.1.2 does not have a "number = of MARs" field
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (similar to the MARs
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defined in 3810)?


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Not really. The "Length" + "= Protocol" fields can also be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 used to derive
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the number of MARs, without adding any addi= tional
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information to the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 option, right?


=A0 =A0 =A0 =A0 =A0 =A0 It can, but adding an explicit count of the records= gives
=A0 =A0 =A0 =A0 =A0 =A0 you the
=A0 =A0 =A0 =A0 =A0 =A0 ability to do some error checking.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If you think it is better to add the "= number of MARs"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 field, we can do
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it in a new revision of the draft.


=A0 =A0 =A0 =A0 =A0 =A0 I wouldn't say it is better, just more robust. = =A0I would
=A0 =A0 =A0 =A0 =A0 =A0 rather have the
=A0 =A0 =A0 =A0 =A0 =A0 spec represent what has been implemented.


=A0 =A0 =A0 =A0 At the moment we have not yet implemented the multiple MAR<= br> =A0 =A0 =A0 =A0 option, so
=A0 =A0 =A0 =A0 either solution would be equally feasible. Since you believ= e
=A0 =A0 =A0 =A0 having an
=A0 =A0 =A0 =A0 explicit counter is more robust, we can add the option.


=A0 =A0 That is up to you. =A0It may be worth waiting until you get additio= nal
=A0 =A0 comments.



=A0 =A0 =A0 =A0 If there are no more comments from you or the group, we can= make the
=A0 =A0 =A0 =A0 change and produce a new version.

=A0 =A0 =A0 =A0 BTW, I've just seen that IETF LC has been started on th= e
=A0 =A0 =A0 =A0 document, but
=A0 =A0 =A0 =A0 as Informational RFC. There was discussion within the WG ab= out the
=A0 =A0 =A0 =A0 intended status and the result was to make it Experimental.= Is it a
=A0 =A0 =A0 =A0 problem that the LC is initiated for Informational status?<= br>

=A0 =A0 Informational and Experimental are equivalent. =A0If the WG decides= to
=A0 =A0 change to Experimental, it can be done without another IETF Last Ca= ll.


=A0 =A0 Regards,
=A0 =A0 Brian


=A0 =A0 _________________________________________________
=A0 =A0 multimob mailing list
=A0 =A0 multimob@iet= f.org <mailto:multimob@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/multimob
=A0 =A0 <https://www.ietf.org/mailman/listinfo/multimob>=





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



--089e012284fa3b48fc04e015aa2d-- From sarikaya2012@gmail.com Thu Jun 27 13:44:44 2013 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181921F9F17 for ; Thu, 27 Jun 2013 13:44:44 -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 PhUR1VQ8xrFT for ; Thu, 27 Jun 2013 13:44:44 -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 C3F6D21F9E8B for ; Thu, 27 Jun 2013 13:44:40 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id ea20so1356837lab.36 for ; Thu, 27 Jun 2013 13:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=mhZFN/C3HhnE7AKOTegcyHDob5Kmfe4vnFbB++fE9oM=; b=QMt5EDQZUqlulY5zl2nO4uNxZNYG6DqQ9sS0eDeHxrbdpxrJSkzusmjDeKwL+RRtPV Xn2R03gbpIGTAaCPb6JCOdlTFy81r4QY1Md98yHd1mVW2IelzV+yaXsb0DjJxn/CQeRM cLa9EE4JpP6waxkRYymGws1kYY+kTvnBZIn2NBpqGeu85tRwOskvNOi+4MJVbZenlJ21 f2ZsxA3L7aMbk70YNedQ14swVE+aH49ARv2T8fmbIJmSDYXVKMQPLWtonju8bmrth4nn MVtsqXLx22mk36LrzHJVJxU8ftohtrhTCO4OI5KacmHcuXo3E9RcuYOV32UAcPpaE8qu Hfkw== MIME-Version: 1.0 X-Received: by 10.152.28.34 with SMTP id y2mr5066732lag.0.1372365879740; Thu, 27 Jun 2013 13:44:39 -0700 (PDT) Received: by 10.114.186.104 with HTTP; Thu, 27 Jun 2013 13:44:39 -0700 (PDT) Date: Thu, 27 Jun 2013 15:44:39 -0500 Message-ID: From: Behcet Sarikaya To: multimob@ietf.org Content-Type: multipart/alternative; boundary=089e0158c57ac38eff04e028d45e Subject: [multimob] Session in Berlin X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 20:44:44 -0000 --089e0158c57ac38eff04e028d45e Content-Type: text/plain; charset=ISO-8859-1 Folks, We have been assigned a session in Berlin on Thurday afternoon starting at 15:20. This is a one and half hour session. We will entertain slot requests fro now on. WG drafts and other topics of interest such as: - Multiple MTMAs and tunnel convergence problem possibly using multiple interfaced proxy, - How to keep track of individual MN's multicast activities in a proxy environment such as RFC 6224. Regards, Behcet multimob Session 1 (1:30:00) Thursday, Afternoon Session II 1520-1650 Room Name: Tiergarten 1/2 --089e0158c57ac38eff04e028d45e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

We have been assigned a session in Berlin on Thurday afternoo= n starting at 15:20. This is a one and half hour session.

We will en= tertain slot requests fro now on. WG drafts and other topics of interest su= ch as:
- Multiple MTMAs and tunnel convergence problem possibly using multiple int= erfaced proxy,
- How to keep track of individual MN's multicast acti= vities in a proxy environment such as RFC 6224.

Regards,

Behcet


multimob Session 1 (1:30:00)
=A0 =A0 Thursday, Afternoon Session II 1520-1650
=A0 =A0 Room Name: Tiergarten 1/2
--089e0158c57ac38eff04e028d45e--