From nobody Mon Mar 3 01:34:35 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7DE1A0D83; Mon, 3 Mar 2014 01:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfFr8wUgFaF5; Mon, 3 Mar 2014 01:34:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4F31A0B78; Mon, 3 Mar 2014 01:34:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303093431.4834.51312.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 01:34:31 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/102gIk0MlbM1vkRzl18ghyzLauE Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-08.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:34:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Authors : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-08.txt Pages : 28 Date : 2014-03-03 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 01:34:41 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F61A0012 for ; Mon, 3 Mar 2014 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61hXQxZ9GxUq; Mon, 3 Mar 2014 01:34:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E801A0652; Mon, 3 Mar 2014 01:34:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: multimob-chairs@tools.ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303093432.4834.28033.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 01:34:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/w1Ddhi_tpMLTP1l1dlPUvDQS7HE Subject: [multimob] New Version Notification - draft-ietf-multimob-pmipv6-source-08.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:34:35 -0000 A new version (-08) has been submitted for draft-ietf-multimob-pmipv6-source: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-source-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Mar 13 15:30:23 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21291A0768 for ; Thu, 13 Mar 2014 15:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPTpRtWjst3b for ; Thu, 13 Mar 2014 15:30:20 -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 E96BE1A076F for ; Thu, 13 Mar 2014 15:30:19 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:9d8d:9681:1552:34db] (unknown [IPv6:2001:420:301:1004:9d8d:9681:1552:34db]) by ufisa.uninett.no (Postfix) with ESMTPSA id 1AFFA8047; Thu, 13 Mar 2014 23:30:11 +0100 (CET) Message-ID: <53223171.8000608@venaas.com> Date: Thu, 13 Mar 2014 15:30:09 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org References: <53222064.5030808@venaas.com> <532220D4.2090009@informatik.haw-hamburg.de> In-Reply-To: <532220D4.2090009@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/-Sfit_Mxv4gIoLkz9SE9fg9fILA Cc: "multimob@ietf.org" Subject: [multimob] Some comments on draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 22:30:21 -0000 Hi Here are my comments on the 03 version. There may be a line that is too long, and there is one case where a "MUST not" needs to be replaced with "MUST NOT". Please see the idnits. http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt One thing is unclear to me in 3.3. It says: There are two ways to obtain the multicast membership of an MN. First, MAGs may perform explicit tracking (see [RFC4605], [RFC6224]) or extract membership status from forwarding states at node-specific point-to-point links. Second, routers can issue a general MLD query at handovers. Both methods are equally Are you assuming point-to-point links in this second case? If not, then I don't see how the PAR can find out the MNs subscribed groups just by doing an MLD query. Also wondering if it should be pointed out here that it's not just groups. For SSM it would be (S,G) or channels. I see it says groups/channels many other places though. It might be worth explaining what the term channel means. applicable. However, a router that does not operate explicit tracking needs to query its downstream links after a handover. The MLD membership information then allows the PAR to know the multicast group subscriptions of the MN. In predictive mode, the PMAG (PAR) will learn about the upcoming movement of the mobile node. Without explicit tracking, it will immediately submit a general MLD query and receive MLD reports for the subscribed group(s). As displayed in Figure 4, it will initiate binding and context transfer with the NMAG (NAR) by issuing a HI message that is augmented by multicast contexts in the mobility options defined in Section 5.3. NAR will extract multicast context information and act as described in Section 3.1. In 4.2.2 it says "it MAY need to issue". I don't think this is the appropriate use of MAY. It's not like MAY implement, or MAY do something. There is no freedom of choice here. Whether it is done or not just depends on the situation. I think you could replace "MAY" with "will". In 5.3 it says: Length: 8-bit unsigned integer. The size of this option is 8 octets including the Type, Option-Code, and Length fields. How can this be 8 octets. It looks like 4 octets when including the reserved field, and then the total length varies with the size of the report payload? But I guess the payload is always at least 4 octets? In 5.4 it says: Length: 8-bit unsigned integer. The size of this option in 8 octets. The length is 1 when the MLD (IGMP) Unsupported Report Payload field contains no Mcast Address Record. Should it say "is" like in 5.3, or should 5.4 say "in"? It looks to me like the length is 4 if there is no payload. Or is the payload at least 4 octets? In 5.4 it says: that are not supported or prohibited in the new access network. This field MUST always contain the first header line (reserved field and No of Mcast Address Records), but MUST NOT contain any Mcast Address Records, if the status code equals 1. Should it say this in 5.3 as well? It might be good to make the IANA considerations more explicit. It would be good to explicitly specify what the new tables look like. Stig From nobody Fri Mar 14 04:26:00 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DF01A010E for ; Fri, 14 Mar 2014 04:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAta3bhMGX9E for ; Fri, 14 Mar 2014 04:25:55 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 771D71A0108 for ; Fri, 14 Mar 2014 04:25:54 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 14 Mar 2014 12:25:46 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 87B8210679D7; Fri, 14 Mar 2014 12:25:46 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20640-05; Fri, 14 Mar 2014 12:25:45 +0100 (CET) Received: from [192.168.178.49] (g231226162.adsl.alicedsl.de [92.231.226.162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 0717B10679CF; Fri, 14 Mar 2014 12:25:44 +0100 (CET) Message-ID: <5322E737.4040606@informatik.haw-hamburg.de> Date: Fri, 14 Mar 2014 12:25:43 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Stig Venaas , draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org References: <53222064.5030808@venaas.com> <532220D4.2090009@informatik.haw-hamburg.de> <53223171.8000608@venaas.com> In-Reply-To: <53223171.8000608@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/CohSycJ8LgKFEqUI0P3O-D0O9D0 Cc: "multimob@ietf.org" Subject: Re: [multimob] Some comments on draft-ietf-multimob-fmipv6-pfmipv6-multicast-03 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 11:25:59 -0000 Hi Stig, many thanks - please see comments inline. On 13.03.2014 23:30, Stig Venaas wrote: > Here are my comments on the 03 version. Oops, sorry ... working on version 03 included unnecessary work ... many of the issues below had already been fixed in the 04 preliminary version I had sent ... > > There may be a line that is too long, and there is one case where a > "MUST not" needs to be replaced with "MUST NOT". Please see the idnits. > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt > 'MUST NOT' is fixed now. The line issue seems to be an artifact of the idnits tool - I could not find a too long line, and there is definitely no line that is 67 characters in excess of 72. > > One thing is unclear to me in 3.3. It says: > > There are two ways to obtain the multicast > membership of an MN. First, MAGs may perform explicit tracking (see > [RFC4605], [RFC6224]) or extract membership status from forwarding > states at node-specific point-to-point links. Second, routers can > issue a general MLD query at handovers. Both methods are equally > > Are you assuming point-to-point links in this second case? If not, > then I don't see how the PAR can find out the MNs subscribed groups > just by doing an MLD query. > Yes, in this PMIPv6 case, the MN is always connected via node-specific point-to-point links. It is probably irritating that we mention this only for the first case. Here comes a rewording: " In a proxy mobile IPv6 environment, the MN remains agnostic of network layer changes, and fast handover procedures are operated by the access routers or MAGs to which MNs are connected via node- specific point-to-point links. The handover initiation, or the re- association respectively are managed by the access networks. Consequently, access routers need to be aware of multicast membership state at the mobile node. There are two ways to obtain the multicast membership of an MN. First, MAGs may perform explicit tracking (see [RFC4605], [RFC6224]) or extract membership status from forwarding states at node-specific links. " > Also wondering if it should be pointed out here that it's not just > groups. For SSM it would be (S,G) or channels. I see it says > groups/channels many other places though. It might be worth explaining > what the term channel means. > O.K. - first we added channels here: " The MLD membership information then allows the PMAG (PAR) to learn the multicast group/ channel subscriptions of the MN." For the general introduction of groups/channels etc. we added the following to the introduction: " This document specifies extensions to FMIPv6 and PFMIPv6 that include multicast traffic management for fast handover operations in the presence of any source or source specific multicast. ... The solution common to both underlying unicast protocols defines the per-group or per channel transfer of multicast contexts between ARs or MAGs. The protocol defines corresponding message extensions necessary for carrying (*,G) or (S,G) context information independent of the particular handover protocol." Hope this explains it more clearly. > applicable. However, a router that does not operate explicit > tracking needs to query its downstream links after a handover. The > MLD membership information then allows the PAR to know the multicast > group subscriptions of the MN. > > In predictive mode, the PMAG (PAR) will learn about the upcoming > movement of the mobile node. Without explicit tracking, it will > immediately submit a general MLD query and receive MLD reports for > the subscribed group(s). As displayed in Figure 4, it will initiate > binding and context transfer with the NMAG (NAR) by issuing a HI > message that is augmented by multicast contexts in the mobility > options defined in Section 5.3. NAR will extract multicast context > information and act as described in Section 3.1. > > In 4.2.2 it says "it MAY need to issue". I don't think this is the > appropriate use of MAY. It's not like MAY implement, or MAY do > something. There is no freedom of choice here. Whether it is done or > not just depends on the situation. I think you could replace "MAY" > with "will". > Yes, I see - it's changed now. [Length Corrections] These lengths issues are somewhat historic ... they have been already corrected. It is now conformal to the general design of the Multicast Mobility Option. > In 5.3 it says: > > Length: 8-bit unsigned integer. The size of this option is 8 octets > including the Type, Option-Code, and Length fields. > > How can this be 8 octets. It looks like 4 octets when including the > reserved field, and then the total length varies with the size of the > report payload? But I guess the payload is always at least 4 octets? > > In 5.4 it says: > > Length: 8-bit unsigned integer. The size of this option in 8 octets. > The length is 1 when the MLD (IGMP) Unsupported Report Payload field > contains no Mcast Address Record. > > Should it say "is" like in 5.3, or should 5.4 say "in"? It looks to me > like the length is 4 if there is no payload. Or is the payload at least > 4 octets? > --------- end of length issues ------------ > In 5.4 it says: > that are not supported or prohibited in the new access network. This > field MUST always contain the first header line (reserved field and > No of Mcast Address Records), but MUST NOT contain any Mcast Address > Records, if the status code equals 1. > > Should it say this in 5.3 as well? > I don't think so. This context transfer is organised in a request/response manner and only the response message (as of 5.4) contains a status code. In the request case (as of 5.3), the PAR/PMAG just enumerates the multicast context records it wants to transfer. > It might be good to make the IANA considerations more explicit. It would > be good to explicitly specify what the new tables look like. > Yes, that was also done. Thanks again! - we will submit a revised version today that will also contain the open subject of Georgios (Appendix on mobile sources). Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Sun Mar 16 04:39:07 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42211A01BE; Sun, 16 Mar 2014 04:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8eIS-C4NmEq; Sun, 16 Mar 2014 04:38:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCED71A02DD; Sun, 16 Mar 2014 04:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> Date: Sun, 16 Mar 2014 04:38:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/yFzDJRHN9FQgdhL6Jvv2AMiY3sc Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 11:39:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers Authors : Thomas C. Schmidt Matthias Waehlisch Rajeev Koodli Godred Fairhurst Dapeng Liu Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt Pages : 30 Date : 2014-03-16 Abstract: Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay- sensitive real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that may include buffering. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 19 12:01:56 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF50C1A06FD for ; Wed, 19 Mar 2014 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCJLj7l-j3mf for ; Wed, 19 Mar 2014 12:01:52 -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 99A701A0401 for ; Wed, 19 Mar 2014 12:01:52 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:c1f2:ff8f:1b6c:60dc] (unknown [IPv6:2001:420:301:1004:c1f2:ff8f:1b6c:60dc]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2B4A3804B; Wed, 19 Mar 2014 20:01:40 +0100 (CET) Message-ID: <5329E98E.1020205@venaas.com> Date: Wed, 19 Mar 2014 12:01:34 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: multimob@ietf.org References: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> In-Reply-To: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/x9LQUYtAymxVf_0oMkfqAeOME9g Cc: draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 19:01:55 -0000 Hi Thanks for posting this much improved version. I have some comments on this one too though. Can others in the WG please also see if they are happy with this latest one? Here are my minor comments. Mark it as an update of RFC5568. Typo in 4.1.2: indicatior IN 4.2.2 it says: The PMAG then waits for receiving the Multicast Acknowledgement Option(s) with a HACK message (see Section 5.4) and the creation of the bidirectional tunnel with NMAG. Better language to write "wait until it receives"? Also: It SHOULD start forwarding traffic down the tunnel interface for those groups an MLD listener report was received from NMAG. Add "for which"? "For those groups for which an MLD"... 5.2: In most of the document you use FBACK and HACK, but here you refer to them as FBAck and HAck. Appendix A: You write "In this section", but perhaps say appendix? Remove change log? Not that useful in the RFC I think. Stig From nobody Wed Mar 19 14:53:02 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FAD1A07F2; Wed, 19 Mar 2014 14:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYD6oyN6QKiO; Wed, 19 Mar 2014 14:52:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D231A078A; Wed, 19 Mar 2014 14:52:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140319215254.19113.51171.idtracker@ietfa.amsl.com> Date: Wed, 19 Mar 2014 14:52:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/mIG_T2XeJCbDRU0CvcrrOJFX4kI Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-05.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 21:52:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers Authors : Thomas C. Schmidt Matthias Waehlisch Rajeev Koodli Godred Fairhurst Dapeng Liu Filename : draft-ietf-multimob-fmipv6-pfmipv6-multicast-05.txt Pages : 28 Date : 2014-03-19 Abstract: Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay- sensitive real-time traffic and will benefit from fast handover completion. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy Router Advertisements message format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multicast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 19 14:54:08 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EF51A07FF for ; Wed, 19 Mar 2014 14:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB3n3lNq3QmK for ; Wed, 19 Mar 2014 14:53:58 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id EF5D51A0805 for ; Wed, 19 Mar 2014 14:53:56 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 19 Mar 2014 22:53:47 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6CA0410679D7; Wed, 19 Mar 2014 22:53:47 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25646-02; Wed, 19 Mar 2014 22:53:47 +0100 (CET) Received: from [141.22.28.186] (unknown [141.22.28.186]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id C438910679CF; Wed, 19 Mar 2014 22:53:46 +0100 (CET) Message-ID: <532A11E4.4060404@informatik.haw-hamburg.de> Date: Wed, 19 Mar 2014 22:53:40 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Stig Venaas , multimob@ietf.org References: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> <5329E98E.1020205@venaas.com> In-Reply-To: <5329E98E.1020205@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/9rcWfu516Un5KOTNvxl64Eb8YVM Cc: draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 21:54:02 -0000 Hi Stig, thanks for looking at the details carefully! All should be fixed in the present submission. Thomas On 19.03.2014 20:01, Stig Venaas wrote: > Hi > > Thanks for posting this much improved version. I have some comments on > this one too though. Can others in the WG please also see if they are > happy with this latest one? > > Here are my minor comments. > > Mark it as an update of RFC5568. > > Typo in 4.1.2: indicatior > > IN 4.2.2 it says: > > The PMAG then waits for receiving the Multicast Acknowledgement > Option(s) with a HACK message (see Section 5.4) and the creation of > the bidirectional tunnel with NMAG. > > Better language to write "wait until it receives"? > > Also: > > It SHOULD start forwarding traffic down the > tunnel interface for those groups an MLD listener report was > received from NMAG. > > Add "for which"? "For those groups for which an MLD"... > > 5.2: > In most of the document you use FBACK and HACK, but here you refer > to them as FBAck and HAck. > > Appendix A: > You write "In this section", but perhaps say appendix? > > Remove change log? Not that useful in the RFC I think. > > Stig > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Wed Mar 19 15:30:38 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D553A1A0319 for ; Wed, 19 Mar 2014 15:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aefv2iykVcwb for ; Wed, 19 Mar 2014 15:30:34 -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 6142D1A023C for ; Wed, 19 Mar 2014 15:30:34 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:c1f2:ff8f:1b6c:60dc] (unknown [IPv6:2001:420:301:1004:c1f2:ff8f:1b6c:60dc]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2EEB98063; Wed, 19 Mar 2014 23:30:23 +0100 (CET) Message-ID: <532A1A7D.4090801@venaas.com> Date: Wed, 19 Mar 2014 15:30:21 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Thomas C. Schmidt" , multimob@ietf.org References: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> <5329E98E.1020205@venaas.com> <532A11E4.4060404@informatik.haw-hamburg.de> In-Reply-To: <532A11E4.4060404@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/WkrJ4Ts2HapLwBlCQYFIoqD3c2o Cc: draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 22:30:37 -0000 On 3/19/2014 2:53 PM, Thomas C. Schmidt wrote: > Hi Stig, > > thanks for looking at the details carefully! > > All should be fixed in the present submission. Thanks for the quick response! Can others in the WG please see if they have any issues? I'll request publication as soon as all the authors have stated whether they are aware of any IPRs. Only missing one author and we're good to go. Stig > Thomas > > On 19.03.2014 20:01, Stig Venaas wrote: >> Hi >> >> Thanks for posting this much improved version. I have some comments on >> this one too though. Can others in the WG please also see if they are >> happy with this latest one? >> >> Here are my minor comments. >> >> Mark it as an update of RFC5568. >> >> Typo in 4.1.2: indicatior >> >> IN 4.2.2 it says: >> >> The PMAG then waits for receiving the Multicast Acknowledgement >> Option(s) with a HACK message (see Section 5.4) and the creation of >> the bidirectional tunnel with NMAG. >> >> Better language to write "wait until it receives"? >> >> Also: >> >> It SHOULD start forwarding traffic down the >> tunnel interface for those groups an MLD listener report was >> received from NMAG. >> >> Add "for which"? "For those groups for which an MLD"... >> >> 5.2: >> In most of the document you use FBACK and HACK, but here you refer >> to them as FBAck and HAck. >> >> Appendix A: >> You write "In this section", but perhaps say appendix? >> >> Remove change log? Not that useful in the RFC I think. >> >> Stig >> > From nobody Thu Mar 20 00:56:22 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4831A039D for ; Thu, 20 Mar 2014 00:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mLdi9pN6sBO for ; Thu, 20 Mar 2014 00:56:14 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id CE2C41A08A9 for ; Thu, 20 Mar 2014 00:56:13 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 40B2F2B4568; Thu, 20 Mar 2014 07:56:04 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 20 Mar 2014 07:56:04 -0000 Message-ID: <1016b5f1f9d7b24e49d5a423d6600bcb.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <532A1A7D.4090801@venaas.com> References: <20140316113858.12029.20135.idtracker@ietfa.amsl.com> <5329E98E.1020205@venaas.com> <532A11E4.4060404@informatik.haw-hamburg.de> <532A1A7D.4090801@venaas.com> Date: Thu, 20 Mar 2014 07:56:04 -0000 From: gorry@erg.abdn.ac.uk To: "Stig Venaas" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/sjo9RF2Xl9aAfvoV81gcQYh4vvs Cc: multimob@ietf.org, "Thomas C. Schmidt" , draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org Subject: Re: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-04.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 07:56:16 -0000 To avoid any doubt. I (gorry) do not claim any IPR rights for this document, and transfer all my rights to the IETF. Gorry > On 3/19/2014 2:53 PM, Thomas C. Schmidt wrote: >> Hi Stig, >> >> thanks for looking at the details carefully! >> >> All should be fixed in the present submission. > > Thanks for the quick response! Can others in the WG please see if they > have any issues? > > I'll request publication as soon as all the authors have stated whether > they are aware of any IPRs. Only missing one author and we're good to go. > > Stig > >> Thomas >> >> On 19.03.2014 20:01, Stig Venaas wrote: >>> Hi >>> >>> Thanks for posting this much improved version. I have some comments on >>> this one too though. Can others in the WG please also see if they are >>> happy with this latest one? >>> >>> Here are my minor comments. >>> >>> Mark it as an update of RFC5568. >>> >>> Typo in 4.1.2: indicatior >>> >>> IN 4.2.2 it says: >>> >>> The PMAG then waits for receiving the Multicast Acknowledgement >>> Option(s) with a HACK message (see Section 5.4) and the creation of >>> the bidirectional tunnel with NMAG. >>> >>> Better language to write "wait until it receives"? >>> >>> Also: >>> >>> It SHOULD start forwarding traffic down the >>> tunnel interface for those groups an MLD listener report was >>> received from NMAG. >>> >>> Add "for which"? "For those groups for which an MLD"... >>> >>> 5.2: >>> In most of the document you use FBACK and HACK, but here you refer >>> to them as FBAck and HAck. >>> >>> Appendix A: >>> You write "In this section", but perhaps say appendix? >>> >>> Remove change log? Not that useful in the RFC I think. >>> >>> Stig >>> >> > From nobody Mon Mar 24 13:30:22 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0387E1A0298 for ; Mon, 24 Mar 2014 13:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR-U6gZwJa-t for ; Mon, 24 Mar 2014 13:29:52 -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 2AB0E1A026C for ; Mon, 24 Mar 2014 13:29:49 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:45ab:1610:2a70:1bfe] (unknown [IPv6:2001:420:301:1004:45ab:1610:2a70:1bfe]) by ufisa.uninett.no (Postfix) with ESMTPSA id 25B0F7FCD for ; Mon, 24 Mar 2014 21:29:46 +0100 (CET) Message-ID: <533095B8.8080207@venaas.com> Date: Mon, 24 Mar 2014 13:29:44 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/BiHWaVKO1c2d2TA7-AizFtU9K2A Subject: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 20:29:59 -0000 This is a working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Please state whether you think it is ready for publishing or if you believe there are issues with the document or that it is not ready for other reasons. The document has already been reviewed by several people, but it is still good to hear from the working group what you think. The last call ends one week from now on Monday March 31st. The draft is available at http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Stig From nobody Tue Mar 25 09:27:49 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DC11A01E9; Tue, 25 Mar 2014 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7wKb4NETkdV; Tue, 25 Mar 2014 09:27:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0247D1A01D1; Tue, 25 Mar 2014 09:27:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140325162722.24921.24684.idtracker@ietfa.amsl.com> Date: Tue, 25 Mar 2014 09:27:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/HbeBys6kbQgaXcw00zoVfpfwySc Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob-chairs@tools.ietf.org Subject: [multimob] Spencer Dawkins' No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 16:27:25 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-multimob-pmipv6-source-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a couple of questions about text clarity. Please consider them, along with any other comments you receive from other reviewers. And I should say that MIP/PMIP drafts I've often read have been dense for me, and this one is clearer than most - thank you for that. 4.3.2. Operations of PIM in Phase One (RP Tree) Source handover management in PIM phase one admits low complexity and remains transparent to receivers. In addition, the source register tunnel management of PIM is a fast protocol operation and little overhead is induced thereof. ^^^^^^^^^^^^^^^ I didn't understand this text clearly. Is it saying something like "little overhead is introduced"? 7. Security Considerations In addition to proper authorization checks of MNs, rate controls at routing agents and replicators MAY be required to protect the agents and the downstream networks. In ^^^^^^^^ is this "may be needed"? The passive voice doesn't make the text easy to parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separate issue). particular, MLD proxy implementations at MAGs SHOULD carefully procure for automatic multicast state extinction on the departure of ^^^^^^^ This word doesn't fit (a quick google of online directionaries pointed toward "procure" as obtaining something by special effort, for example). I wondered if you meant "probe", but I'm guessing. MNs, as mobile multicast listeners in the PMIPv6 domain will in general not actively terminate group membership prior to departure. Consequently, implementations of peering-enabled proxies SHOULD take particular care on maintaining (varying) IP configurations at the downstream in ^^^^^^^^^ I don't understand what "varying" means in this context (my first guess was that it was being used as a synonym for "maintaining", which didn't work). Is it needed at all? a reliable and timely manner (see [RFC6224] for requirements on PMIPv6-compliant implementations of MLD proxies). From nobody Wed Mar 26 23:23:55 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A0A1A029E; Wed, 26 Mar 2014 23:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fP09gAmEC-a; Wed, 26 Mar 2014 23:23:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680911A00C6; Wed, 26 Mar 2014 23:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140327062352.11332.88617.idtracker@ietfa.amsl.com> Date: Wed, 26 Mar 2014 23:23:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/bQGAXsJtvbet4v1tPRQzvkks5fA Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob-chairs@tools.ietf.org Subject: [multimob] Pete Resnick's No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 06:23:54 -0000 Pete Resnick has entered the following ballot position for draft-ietf-multimob-pmipv6-source-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A quick review reveals nothing of significance for applications that I can find. I do wonder about why this is Experimental. Seems to me it could have been a Proposed Standard, and there's nothing in the document to indicate any "experimenting" that's truly going to be done or what the WG expects to discover from this "experiment". But if the AD is OK with it, I'm not going to hold it up. From nobody Thu Mar 27 04:29:52 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B62A1A0644; Thu, 27 Mar 2014 04:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Znif8y77BrwH; Thu, 27 Mar 2014 04:29:45 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4CADD1A031B; Thu, 27 Mar 2014 04:29:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5FE4F2CC61; Thu, 27 Mar 2014 13:29:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C44stpG4AuAb; Thu, 27 Mar 2014 13:29:37 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 11C812CC48; Thu, 27 Mar 2014 13:29:37 +0200 (EET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076BE77DD9@MX15A.corp.emc.com> Date: Thu, 27 Mar 2014 13:29:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712076BE77DD9@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/KC9r3beJLhnX_JLgYwtynTgbLnw Cc: multimob@ietf.org, "General Area Review Team \(gen-art@ietf.org\)" , hkzhang@bjtu.edu.cn, shgao@bjtu.edu.cn, schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] [Gen-art] Gen-ART review of draft-ietf-multimob-pmipv6-source-08 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 11:29:51 -0000 David: Thank you very much for the review. The Gen-ART reviews are = important for me, in that they help me decide when I need to look at the = details of the documents and not. And I'm happy to see that the new = version resolved issues that you had identified earlier. (This is the = case with most of the Gen-ART reviews, by the way. Issues get identified = and resolved. Great!) Jari On Mar 21, 2014, at 5:48 PM, "Black, David" wrote: > The -08 version of this draft addresses all of the nits noted in the = Gen-ART > review of the -07 version. The -08 version is ready for publication = as an > Experimental RFC. >=20 > Thanks, > --David >=20 >=20 >> -----Original Message----- >> From: Black, David >> Sent: Sunday, February 16, 2014 10:23 PM >> To: schmidt@informatik.haw-hamburg.de; shgao@bjtu.edu.cn; = hkzhang@bjtu.edu.cn; >> mw@link-lab.net; General Area Review Team (gen-art@ietf.org) >> Cc: Black, David; multimob@ietf.org; Brian Haberman >> (brian@innovationslab.net); ietf@ietf.org >> Subject: Gen-ART review of draft-ietf-multimob-pmipv6-source-07 >>=20 >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >>=20 >> . >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-multimob-pmipv6-source-07 >> Reviewer: David L. Black >> Review Date: Feb 16, 2014 >> IETF LC End Date: Feb 24, 2014 >>=20 >> Summary: This draft is basically ready for publication, but has nits = that >> should be fixed before publication. >>=20 >> This draft describes multicast support for proxy mobile IPv6. It = assumes >> significant understanding of multicast and specifically the PIM-SM = protocol. >>=20 >> Nits/editorial comments: >>=20 >> -- Introduction, 3rd paragraph >>=20 >> Remove the word business from the following text, please: >>=20 >> Such approaches (partially) follow >> the business model of providing multicast data services in parallel >> to PMIPv6 unicast routing = [I-D.ietf-multimob-handover-optimization]. >>=20 >> -- 4.3.1 >>=20 >> The fact that PIM-SM has three phases could be made somewhat clearer = here. >> Suggestion: >>=20 >> OLD >> The granularity of mobility-related routing >> locators required in PIM depends on the complexity (phases) of its >> deployment. >>=20 >> The following information is needed for all three phases of PIM as >> defined in [RFC4601]. >> NEW >> The granularity of mobility-related routing >> locators required in PIM depends on the complexity (specific phase) >> of its deployment. >>=20 >> For all three phases of PIM deployment (see [RFC4601]), the = following >> information is needed. >>=20 >> Also, is "deployment" the right word to describe the phases? It = implies >> that not all of the phases need to be present in an implementation or >> used, even if applicable. >>=20 >> -- 4.3.2 - 4.3.4 >>=20 >> I would also suggest including the names of the phases from RFC 4601 = in >> these section titles, e.g.: >>=20 >> 4.3.2. Operations of PIM in Phase One (RP Tree) >>=20 >> -- idnits >>=20 >> idnits 2.13.01 found an unused reference and a couple of drafts that >> have been updated: >>=20 >> =3D=3D Unused Reference: 'RFC2236' is defined on line 1047, but no = explicit >> reference was found in the text >>=20 >> =3D=3D Outdated reference: A later version (-02) exists of >> draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 >>=20 >> =3D=3D Outdated reference: A later version (-07) exists of >> draft-ietf-multimob-handover-optimization-06 >>=20 >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer >> EMC Corporation, 176 South St., Hopkinton, MA 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Mar 27 08:30:41 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83C1A00FD for ; Thu, 27 Mar 2014 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2XyEjQS-Uu3 for ; Thu, 27 Mar 2014 08:30:37 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 10D681A00DC for ; Thu, 27 Mar 2014 08:30:36 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Mar 2014 16:30:33 +0100 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 27 Mar 2014 16:30:32 +0100 From: To: , Date: Thu, 27 Mar 2014 16:30:32 +0100 Thread-Topic: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Thread-Index: Ac9Hn+EGCzzGAcHCSISkF+LRuDDK5wCEagig Message-ID: <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> References: <533095B8.8080207@venaas.com> In-Reply-To: <533095B8.8080207@venaas.com> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/Kvr85TdBao9D9QewlffwgcElA_Y Cc: schmidt@informatik.haw-hamburg.de Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:30:40 -0000 Dear all, Sorry that I missed the preceding WGLC - I do think that this document is r= eady for publication. It has greatly improved since version 00 ;-) Though some (minor) nits came to my mind after re-reading: p.1. Updates: 5568 (if approved) =3D> shouldn't be added 5949 since it does also= update PFMIPv6? As mentioned by others for prior versions there is still mixed usage of FBa= ck, Hack, ... and FBACK, HACK, ... Same for PMAG/NMAG and pMAG/nMAG. p.10ff "Section 3.3. Protocol Operations Specific to PFMIPv6" and Figs. 4/5 do in= clude "PMAG (PAR)" and "NMAG (NAR)" - isn't it all about PMIP - so no relev= ance for AR? Otherwise I would expect a statement like that also a mixed sc= enario MIP/PMIP is in focus here ... I tried to find out whether this was explained in prior posts but didn't ca= tch any ... sorry if I missed it! =20 p.15 sect. 4.1.3 is on NAR, so I guess: of the PAR =3D> of the NAR the NAR joins the groups subscribed for forwarding on the tunnel link. < sounds puzzling to me =3D> the NAR joins the groups the MN has subscribed for (which are then forwarded by PAR) via the tunnel link. < is it that = what is meant? p.21 number of muticast records =3D> number of multicast records or Section 4.2 of [RFC3376]) for the =3D> or Section 4.2 of [RFC3376] for t= he p.23 5.5. Length Considerations: Number of Records and Addresses I understand why the maximum number of multicast address records is 72 or s= ources for MLDv2 is 89 (also given in http://tools.ietf.org/html/rfc3810#se= ction-5.1.10), but I miss a consideration of specific limitation due to 8-b= it Length format in new Mobility Header Multicast Option (Fig.7). Have I misunderstood something or isn't there a much stricter limit for mul= ticast address records to (512-2-4)/(4+16) < 26 (w/o source addresses) ?? for that multicast address to their MLDv2 (IGMPv2) equivalents=20 =3D> for that multicast address to their MLDv2 (IGMPv3) equivalents Hope this helps Best regards Dirk -----Original Message----- From: multimob [mailto:multimob-bounces@ietf.org] On Behalf Of Stig Venaas Sent: Montag, 24. M=E4rz 2014 21:30 To: multimob@ietf.org Subject: [multimob] Working group last call for draft-ietf-multimob-fmipv6-= pfmipv6-multicast-05 This is a working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Please state whether you think it is ready for publishing or if you believe= there are issues with the document or that it is not ready for other reaso= ns. The document has already been reviewed by several people, but it is still g= ood to hear from the working group what you think. The last call ends one week from now on Monday March 31st. The draft is available at http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 Stig _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From nobody Mon Mar 31 10:56:26 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11851A6F51; Mon, 31 Mar 2014 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8bRUTRO0-xH; Mon, 31 Mar 2014 10:56:16 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id C8B0B1A6F15; Mon, 31 Mar 2014 10:56:15 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 31 Mar 2014 19:56:11 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 0A1C910679D7; Mon, 31 Mar 2014 19:56:11 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18801-08; Mon, 31 Mar 2014 19:56:10 +0200 (CEST) Received: from [192.168.178.49] (g231227163.adsl.alicedsl.de [92.231.227.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 7534810679CF; Mon, 31 Mar 2014 19:56:09 +0200 (CEST) Message-ID: <5339AC38.4000706@informatik.haw-hamburg.de> Date: Mon, 31 Mar 2014 19:56:08 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20140325162722.24921.24684.idtracker@ietfa.amsl.com> In-Reply-To: <20140325162722.24921.24684.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/3qSQanA64qqgGoHsZ70OITVwxW8 Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob-chairs@tools.ietf.org Subject: Re: [multimob] Spencer Dawkins' No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:56:18 -0000 Hi Spencer, thanks for the review and comments on presentation issues. Please see inline. On 25.03.2014 17:27, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-multimob-pmipv6-source-08: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a couple of questions about text clarity. Please consider them, > along with any other comments you receive from other reviewers. > > And I should say that MIP/PMIP drafts I've often read have been dense for > me, and this one is clearer than most - thank you for that. > :-) > 4.3.2. Operations of PIM in Phase One (RP Tree) > > Source handover management in PIM phase one admits low complexity and > remains transparent to receivers. In addition, the source register > tunnel management of PIM is a fast protocol operation and little > overhead is induced thereof. > ^^^^^^^^^^^^^^^ > > I didn't understand this text clearly. Is it saying something like > "little overhead is introduced"? > Yes, we reworded: "... PIM is a fast protocol operation that introduces little overhead." > 7. Security Considerations > > In addition to proper authorization checks > of MNs, rate controls at routing agents and replicators MAY be > required to protect the agents and the downstream networks. In > ^^^^^^^^ > > is this "may be needed"? The passive voice doesn't make the text easy to > parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separate > issue). > Yes, you're right: "may be needed" is what we wanted to say ;) > particular, MLD proxy implementations at MAGs SHOULD carefully > procure for automatic multicast state extinction on the departure of > ^^^^^^^ > > This word doesn't fit (a quick google of online directionaries pointed > toward "procure" as obtaining something by special effort, for example). > I wondered if you meant "probe", but I'm guessing. > "Probe" would refer to a special solution to achieve this clean-up of state. We would reword: "MLD proxy implementations at MAGs SHOULD automatically extinct multicast state on the departure of" > Consequently, > implementations of peering-enabled proxies SHOULD take particular > care on maintaining (varying) IP configurations at the downstream in > ^^^^^^^^^ > I don't understand what "varying" means in this context (my first guess > was that it was being used as a synonym for "maintaining", which didn't > work). Is it needed at all? > The focus here is on the changing IP connectivity at a MAG's downstream. We reword: "implementations of peering-enabled proxies SHOULD take particular care on keeping IP configurations consistent" > a reliable and timely manner (see [RFC6224] for requirements on > PMIPv6-compliant implementations of MLD proxies). We will update the draft accordingly. Best, thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Mon Mar 31 11:00:08 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28421A6F4C; Mon, 31 Mar 2014 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvWnATs3JKte; Mon, 31 Mar 2014 11:00:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495A81A6F15; Mon, 31 Mar 2014 11:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331180003.30770.38752.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 11:00:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/Ajrm-OXr79smCLABnq6fwdGVcZg Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-09.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:00:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Authors : Thomas C. Schmidt Shuai Gao Hong-Ke Zhang Matthias Waehlisch Filename : draft-ietf-multimob-pmipv6-source-09.txt Pages : 26 Date : 2014-03-31 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 31 11:00:10 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B5A1A089A for ; Mon, 31 Mar 2014 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCXi5HbKY0Ua; Mon, 31 Mar 2014 11:00:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7E1A089D; Mon, 31 Mar 2014 11:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: multimob-chairs@tools.ietf.org, draft-ietf-multimob-pmipv6-source@tools.ietf.org, multimob@ietf.org, brian@innovationslab.net X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331180003.30770.20306.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 11:00:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/j0zRRSAsbiKhnEutzMY1r1ZZ7JI Subject: [multimob] New Version Notification - draft-ietf-multimob-pmipv6-source-09.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:00:06 -0000 A new version (-09) has been submitted for draft-ietf-multimob-pmipv6-source: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-source-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Mar 31 11:03:09 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A891A6F15 for ; Mon, 31 Mar 2014 11:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikNnqu1TgLvE for ; Mon, 31 Mar 2014 11:03:07 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id CF6C41A6F05 for ; Mon, 31 Mar 2014 11:03:06 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 31 Mar 2014 20:03:03 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 25A4E10679D7 for ; Mon, 31 Mar 2014 20:03:03 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20885-02 for ; Mon, 31 Mar 2014 20:03:02 +0200 (CEST) Received: from [192.168.178.49] (g231227163.adsl.alicedsl.de [92.231.227.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id A704710679CF for ; Mon, 31 Mar 2014 20:03:02 +0200 (CEST) Message-ID: <5339ADD5.10609@informatik.haw-hamburg.de> Date: Mon, 31 Mar 2014 20:03:01 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "multimob@ietf.org" References: <20140331180003.30770.71937.idtracker@ietfa.amsl.com> In-Reply-To: <20140331180003.30770.71937.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140331180003.30770.71937.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/k01fElqO7z9rzZlNw2tEM7yg2Jg Subject: [multimob] Fwd: New Version Notification for draft-ietf-multimob-pmipv6-source-09.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:03:08 -0000 Hi all, this update includes feedback from Radia Perlman (SecDir Review) and Spencer Dawkins (IESG Review). Best, Thomas -------- Original Message -------- Subject: New Version Notification for draft-ietf-multimob-pmipv6-source-09.txt Date: Mon, 31 Mar 2014 11:00:03 -0700 From: internet-drafts@ietf.org To: Shuai Gao , "Matthias Waehlisch" , Thomas C. Schmidt , "Thomas Schmidt" , "Hong-Ke Zhang" , Hong-Ke Zhang , "Shuai Gao" , Matthias Waehlisch A new version of I-D, draft-ietf-multimob-pmipv6-source-09.txt has been successfully submitted by Thomas C. Schmidt and posted to the IETF repository. Name: draft-ietf-multimob-pmipv6-source Revision: 09 Title: Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains Document date: 2014-03-31 Group: multimob Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-source-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source/ Htmlized: http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-09 Abstract: Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD Proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 31 12:27:19 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6A21A6F77; Mon, 31 Mar 2014 12:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKKBtimcuFHY; Mon, 31 Mar 2014 12:27:15 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 67A6F1A6F6C; Mon, 31 Mar 2014 12:27:13 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so8047923yho.15 for ; Mon, 31 Mar 2014 12:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u0cKJnnaqlJG1Mxqvgro7wFb7B5AMef6Y6jmX7T+TQY=; b=r513P2sLuU1LoWas/+lbX5s/3YIxBJ9gMND04ARdpf2knnMFhZliLsgOHuSi0zgLMg QvcLsJCMCP6RRHtWCPQRYAAURTr/wB4ZIv1llUAgUX1C/k53pEvA3J799D1MWm39mJCc zvUB+4XHmKwMBU0u92MaOXgdTm51b8wAhGpmf+wFuWAipN3QoJafY0rpsFdNo3mKCtkb 1mzRcuDicx+rUVZDywLZrrnPFAUyzh8n9++eoIQmn+PeXHfgKXjNeKdZcpfalXkop+QU xwxRS1t6OCsBhBc6nn1WNazTmxrp35IB5O10fAegIhup0/gycSERiZSS1mK+WaNt2msO fhQg== MIME-Version: 1.0 X-Received: by 10.236.85.45 with SMTP id t33mr38762860yhe.74.1396294029885; Mon, 31 Mar 2014 12:27:09 -0700 (PDT) Received: by 10.170.96.215 with HTTP; Mon, 31 Mar 2014 12:27:09 -0700 (PDT) In-Reply-To: <5339AC38.4000706@informatik.haw-hamburg.de> References: <20140325162722.24921.24684.idtracker@ietfa.amsl.com> <5339AC38.4000706@informatik.haw-hamburg.de> Date: Mon, 31 Mar 2014 14:27:09 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Thomas C. Schmidt" Content-Type: multipart/alternative; boundary=20cf3005dd4ea7446704f5ec09a4 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/YqlKxFyIs7qHRwOM0rWVMKCeaRM Cc: "multimob@ietf.org" , "draft-ietf-multimob-pmipv6-source@tools.ietf.org" , The IESG , "multimob-chairs@tools.ietf.org" Subject: Re: [multimob] Spencer Dawkins' No Objection on draft-ietf-multimob-pmipv6-source-08: (with COMMENT) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:27:18 -0000 --20cf3005dd4ea7446704f5ec09a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Thomas, These are all fine for me, and thank you. You might want to make sure your AD is ready for a revision, of course. Thanks, Spencer On Monday, March 31, 2014, Thomas C. Schmidt < schmidt@informatik.haw-hamburg.de> wrote: > Hi Spencer, > > thanks for the review and comments on presentation issues. Please see > inline. > > On 25.03.2014 17:27, Spencer Dawkins wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-multimob-pmipv6-source-08: No Objection >> >> > ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have a couple of questions about text clarity. Please consider them, >> along with any other comments you receive from other reviewers. >> >> And I should say that MIP/PMIP drafts I've often read have been dense fo= r >> me, and this one is clearer than most - thank you for that. >> >> > :-) > > 4.3.2. Operations of PIM in Phase One (RP Tree) >> >> Source handover management in PIM phase one admits low complexity an= d >> remains transparent to receivers. In addition, the source register >> tunnel management of PIM is a fast protocol operation and little >> overhead is induced thereof. >> ^^^^^^^^^^^^^^^ >> >> I didn't understand this text clearly. Is it saying something like >> "little overhead is introduced"? >> >> > Yes, we reworded: "... PIM is a fast protocol operation that introduces > little overhead." > > 7. Security Considerations >> >> In addition to proper authorization checks >> of MNs, rate controls at routing agents and replicators MAY be >> required to protect the agents and the downstream networks. In >> ^^^^^^^^ >> >> is this "may be needed"? The passive voice doesn't make the text easy to >> parse (and I'm thinking this MAY is not a 2119 MAY, but that's a separat= e >> issue). >> >> > Yes, you're right: "may be needed" is what we wanted to say ;) > > particular, MLD proxy implementations at MAGs SHOULD carefully >> procure for automatic multicast state extinction on the departure of >> ^^^^^^^ >> >> This word doesn't fit (a quick google of online directionaries pointed >> toward "procure" as obtaining something by special effort, for example). >> I wondered if you meant "probe", but I'm guessing. >> >> > "Probe" would refer to a special solution to achieve this clean-up of > state. We would reword: > > "MLD proxy implementations at MAGs SHOULD automatically extinct multicast > state on the departure of" > > > Consequently, >> implementations of peering-enabled proxies SHOULD take particular >> care on maintaining (varying) IP configurations at the downstream in >> ^^^^^^^^^ >> I don't understand what "varying" means in this context (my first guess >> was that it was being used as a synonym for "maintaining", which didn't >> work). Is it needed at all? >> >> > The focus here is on the changing IP connectivity at a MAG's downstream. > We reword: > > "implementations of peering-enabled proxies SHOULD take particular care o= n > keeping IP configurations consistent" > > a reliable and timely manner (see [RFC6224] for requirements on >> PMIPv6-compliant implementations of MLD proxies). >> > > We will update the draft accordingly. > > Best, > > thomas > > -- > > Prof. Dr. Thomas C. Schmidt > =B0 Hamburg University of Applied Sciences Berliner Tor= 7 =B0 > =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germa= ny =B0 > =B0 http://www.haw-hamburg.de/inet Fon: +49-40-42875-84= 52 > =B0 > =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-84= 09 > =B0 > --20cf3005dd4ea7446704f5ec09a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Thomas,

These are all fine for me, and thank you.

You might want to make sure your AD is ready for a r= evision, of course.

Thanks,

Spencer

On Monday, March 31, 2014, Thomas C. Schmidt = <schmidt@informatik= .haw-hamburg.de> wrote:
Hi Spencer,

thanks for the review and comments on presentation issues. Please see inlin= e.

On 25.03.2014 17:27, Spencer Dawkins wrote:
Spencer Dawkins has entered the following ballot position for
draft-ietf-multimob-pmipv6-source-08: No Objection


-------------------------------------------------------------= ---------
COMMENT:
-------------------------------------------------------------= ---------

I have a couple of questions about text clarity. Please consider them,
along with any other comments you receive from other reviewers.

And I should say that MIP/PMIP drafts I've often read have been dense f= or
me, and this one is clearer than most - thank you for that.


:-)

4.3.2. =A0Operations of PIM in Phase One (RP Tree)

=A0 =A0 Source handover management in PIM phase one admits low complexity a= nd
=A0 =A0 remains transparent to receivers. =A0In addition, the source regist= er
=A0 =A0 tunnel management of PIM is a fast protocol operation and little =A0 =A0 overhead is induced thereof.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^

I didn't understand this text clearly. Is it saying something like
"little overhead is introduced"?


Yes, we reworded: "... PIM is a fast protocol operation that introduce= s little overhead."

7. =A0Security Considerations

=A0 =A0 In addition to proper authorization checks
=A0 =A0 of MNs, rate controls at routing agents and replicators MAY be
=A0 =A0 required to protect the agents and the downstream networks. =A0In =A0 =A0 ^^^^^^^^

is this "may be needed"? The passive voice doesn't make the t= ext easy to
parse (and I'm thinking this MAY is not a 2119 MAY, but that's a se= parate
issue).


Yes, you're right: "may be needed" is what we wanted to say ;= )

=A0 =A0 particular, MLD proxy implementations at MAGs SHOULD carefully
=A0 =A0 procure for automatic multicast state extinction on the departure o= f
=A0 =A0 ^^^^^^^

This word doesn't fit (a quick google of online directionaries pointed<= br> toward "procure" as obtaining something by special effort, for ex= ample).
I wondered if you meant "probe", but I'm guessing.


"Probe" would refer to a special solution to achieve this clean-u= p of state. We would reword:

"MLD proxy implementations at MAGs SHOULD automatically extinct multic= ast state on the departure of"


=A0 =A0 Consequently,
=A0 =A0 implementations of peering-enabled proxies SHOULD take particular =A0 =A0 care on maintaining (varying) IP configurations at the downstream i= n
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^
I don't understand what "varying" means in this context (my f= irst guess
was that it was being used as a synonym for "maintaining", which = didn't
work). Is it needed at all?


The focus here is on the changing IP connectivity at a MAG's downstream= . We reword:

"implementations of peering-enabled proxies SHOULD take particular car= e on keeping IP configurations consistent"

=A0 =A0 a reliable and timely manner (see [RFC6224] for requirements on
=A0 =A0 PMIPv6-compliant implementations of MLD proxies).

We will update the draft accordingly.

Best,

thomas

--

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Berliner Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamburg, Ger= many =B0
=B0 http://www= .haw-hamburg.de/inet =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42= 875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt =A0 =A0Fax: += 49-40-42875-8409 =B0
--20cf3005dd4ea7446704f5ec09a4-- From nobody Mon Mar 31 12:47:10 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0F11A6FDF; Mon, 31 Mar 2014 12:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXNkx0jVYVxi; Mon, 31 Mar 2014 12:46:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EF5FA1A6FDD; Mon, 31 Mar 2014 12:46:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C392B7FC3AA; Mon, 31 Mar 2014 12:46:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20140331194654.C392B7FC3AA@rfc-editor.org> Date: Mon, 31 Mar 2014 12:46:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/M0bDIXe8gmi2DWqNrxbPa-4RQoM Cc: drafts-update-ref@iana.org, multimob@ietf.org, rfc-editor@rfc-editor.org Subject: [multimob] RFC 7161 on Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:47:00 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7161 Title: Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) Author: LM. Contreras, CJ. Bernardos, I. Soto Status: Experimental Stream: IETF Date: March 2014 Mailbox: lmcm@tid.es, cjbc@it.uc3m.es, isoto@it.uc3m.es Pages: 37 Characters: 85916 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-multimob-handover-optimization-07.txt URL: http://www.rfc-editor.org/rfc/rfc7161.txt This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem. Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router). This document is a product of the Multicast Mobility Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Mar 31 14:57:45 2014 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309091A08D5 for ; Mon, 31 Mar 2014 14:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEt9k74F0KfN for ; Mon, 31 Mar 2014 14:57:40 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6521A08DD for ; Mon, 31 Mar 2014 14:57:39 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 31 Mar 2014 23:57:35 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 0FD4210679D7; Mon, 31 Mar 2014 23:57:35 +0200 (CEST) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30341-09; Mon, 31 Mar 2014 23:57:34 +0200 (CEST) Received: from [192.168.178.49] (g231227163.adsl.alicedsl.de [92.231.227.163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id C5D7B10679CF; Mon, 31 Mar 2014 23:57:33 +0200 (CEST) Message-ID: <5339E4CC.9040809@informatik.haw-hamburg.de> Date: Mon, 31 Mar 2014 23:57:32 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Dirk.von-Hugo@telekom.de, stig@venaas.com, multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/gCDuSrt6r5TzwHpRhoiqWe_rAyc Subject: Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:57:43 -0000 Hi Dirk, many thanks for carefully looking through the draft. Please see comments inline. On 27.03.2014 16:30, Dirk.von-Hugo@telekom.de wrote: > Sorry that I missed the preceding WGLC - I do think that this document is ready for publication. It has greatly improved since version 00 ;-) > > Though some (minor) nits came to my mind after re-reading: > > p.1. > Updates: 5568 (if approved) => shouldn't be added 5949 since it does also update PFMIPv6? > I don't think so. The update of 5568 is with the PrRtAdv-Messages. 5949 does not contain such things, as there is no explicit messaging between MAGs and the MN. Mobility Options are explicitly under the control of IANA. > As mentioned by others for prior versions there is still mixed usage of FBack, Hack, ... and FBACK, HACK, ... > Same for PMAG/NMAG and pMAG/nMAG. > Oh yes, that was in the figures ... > p.10ff > "Section 3.3. Protocol Operations Specific to PFMIPv6" and Figs. 4/5 do include "PMAG (PAR)" and "NMAG (NAR)" - isn't it all about PMIP - so no relevance for AR? Otherwise I would expect a statement like that also a mixed scenario MIP/PMIP is in focus here ... > I tried to find out whether this was explained in prior posts but didn't catch any ... sorry if I missed it! > Actually the terms PAR and NAR in parenthesis are used to indicate the correspondence with FMIP ... it does not consider mixed terms, but should help the reader to see that this is all about the same "abstract entities" here. > p.15 > sect. 4.1.3 is on NAR, so I guess: > of the PAR => of the NAR > Yes, thanks. > the NAR joins the groups subscribed > for forwarding on the tunnel link. < sounds puzzling to me > => the NAR joins the groups the MN has subscribed > for (which are then forwarded by PAR) via the tunnel link. < is it that what is meant? > Yes, thanks. This is better. > p.21 > number of muticast records => number of multicast records > Thanks, fixed. > or Section 4.2 of [RFC3376]) for the => or Section 4.2 of [RFC3376] for the > Thanks, fixed. > p.23 > 5.5. Length Considerations: Number of Records and Addresses > I understand why the maximum number of multicast address records is 72 or sources for MLDv2 is 89 (also given in http://tools.ietf.org/html/rfc3810#section-5.1.10), but I miss a consideration of specific limitation due to 8-bit Length format in new Mobility Header Multicast Option (Fig.7). > Have I misunderstood something or isn't there a much stricter limit for multicast address records to (512-2-4)/(4+16) < 26 (w/o source addresses) ?? > I guess you hit a point: By bringing back length formatting to standard mobility options recently, we missed that this will not fill an Ethernet packet. I don't think this matters much, but we definitely should adjust the section on length considerations. > for that multicast address to their MLDv2 (IGMPv2) equivalents > => for that multicast address to their MLDv2 (IGMPv3) equivalents > Thanks, fixed. > Hope this helps Yes, it definitely does. We will wait for the next days to pass the call deadline and resubmit then. Thanks again & best regards, Thomas > -----Original Message----- > From: multimob [mailto:multimob-bounces@ietf.org] On Behalf Of Stig Venaas > Sent: Montag, 24. März 2014 21:30 > To: multimob@ietf.org > Subject: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 > > This is a working group last call for > draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 > > Please state whether you think it is ready for publishing or if you believe there are issues with the document or that it is not ready for other reasons. > > The document has already been reviewed by several people, but it is still good to hear from the working group what you think. > > The last call ends one week from now on Monday March 31st. > > The draft is available at > http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 > > Stig > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °