From nobody Mon May 19 14:01:11 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 21FEB1A03FC for ; Mon, 19 May 2014 14:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] 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 SsRt8q2dTG05 for ; Mon, 19 May 2014 14:00:56 -0700 (PDT) Received: from ufisa.uninett.no (unknown [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4641A0176 for ; Mon, 19 May 2014 14:00:55 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:d7:a187:6bec:952a] (unknown [IPv6:2001:420:301:1004:d7:a187:6bec:952a]) by ufisa.uninett.no (Postfix) with ESMTPSA id D35158039; Mon, 19 May 2014 23:00:53 +0200 (CEST) Message-ID: <537A7102.30501@venaas.com> Date: Mon, 19 May 2014 14:00:50 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Thomas C. Schmidt" , Dirk.von-Hugo@telekom.de, multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> In-Reply-To: <5356B154.3030300@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/GfPpVI1G_N9siVgknnuVEKWd7XE 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, 19 May 2014 21:00:58 -0000 Hi On 4/22/2014 11:13 AM, Thomas C. Schmidt wrote: > Hi Stig, > > sorry, we've been busy otherwise. > > We'll try to update asap. How is this going? Looks like we're still waiting. Stig > Cheers, > > Thomas > > On 22.04.2014 19:29, Stig Venaas wrote: >> Thomas/authors, I think we're just waiting for 06 with these minor >> changes and we can request publication. >> >> Stig >> >> On 4/3/2014 2:15 PM, Stig Venaas wrote: >>> Hi >>> >>> On 3/31/2014 2:57 PM, Thomas C. Schmidt wrote: >>>> 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. Looks like these are the only outstanding issues. Thanks for >>> having a careful look Dirk. >>> >>> Once you submit the new version I'll allow a couple of days for myself >>> and others to review changes. If they look good I'll request publishing. >>> >>> If others have any issues, please let us know, even if passed the WGLC >>> deadline. >>> >>> Stig >>> >>>> 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 >>>>> >>>> >>> >> > From nobody Thu May 22 04:21: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 99C1D1A018F; Thu, 22 May 2014 04:21:49 -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 TAabDHfDs48U; Thu, 22 May 2014 04:21:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD11A017C; Thu, 22 May 2014 04:21:47 -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.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140522112147.26275.19565.idtracker@ietfa.amsl.com> Date: Thu, 22 May 2014 04:21:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/_rgAhHXTMFCnIaDyakKqmLPNUE4 Cc: multimob@ietf.org Subject: [multimob] I-D Action: draft-ietf-multimob-fmipv6-pfmipv6-multicast-06.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: Thu, 22 May 2014 11:21:49 -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-06.txt Pages : 28 Date : 2014-05-22 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-fmipv6-pfmipv6-multicast-06 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 Thu May 22 04:29:17 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 1C5E21A0180 for ; Thu, 22 May 2014 04:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] 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 gb2dnvwvx9Cg for ; Thu, 22 May 2014 04:29:12 -0700 (PDT) Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257791A017C for ; Thu, 22 May 2014 04:29:11 -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; 22 May 2014 13:29:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 8932710679D7; Thu, 22 May 2014 13:29:09 +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 29502-07; Thu, 22 May 2014 13:29:08 +0200 (CEST) Received: from [193.1.167.106] (dhcp-c101a76a.ucd.ie [193.1.167.106]) (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 8AC0910679CF; Thu, 22 May 2014 13:29:06 +0200 (CEST) Message-ID: <537DDF80.7030804@informatik.haw-hamburg.de> Date: Thu, 22 May 2014 12:29:04 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stig Venaas , Dirk.von-Hugo@telekom.de, multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> In-Reply-To: <537A7102.30501@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/QQ0SrMybIEmUxv8JTKjt5Fu8ZtU 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, 22 May 2014 11:29:16 -0000 Hi Stig, Dirk, we just updated the document - sorry for me being slow. We have fixed all nits that you pointed at. In particular, the length counter issue should be resolved now: As this inherited 8 bit length counter is not long enough to count bytes of MLD state records, we propose to count four octets. This complies to the alignment and should not be a problem. However, it leads to a feasible number of MLD records in the payload which at least comes close to common packet lengths. Best, Thomas On 19.05.2014 22:00, Stig Venaas wrote: > Hi > > On 4/22/2014 11:13 AM, Thomas C. Schmidt wrote: >> Hi Stig, >> >> sorry, we've been busy otherwise. >> >> We'll try to update asap. > > How is this going? Looks like we're still waiting. > > Stig > >> Cheers, >> >> Thomas >> >> On 22.04.2014 19:29, Stig Venaas wrote: >>> Thomas/authors, I think we're just waiting for 06 with these minor >>> changes and we can request publication. >>> >>> Stig >>> >>> On 4/3/2014 2:15 PM, Stig Venaas wrote: >>>> Hi >>>> >>>> On 3/31/2014 2:57 PM, Thomas C. Schmidt wrote: >>>>> 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. Looks like these are the only outstanding issues. Thanks for >>>> having a careful look Dirk. >>>> >>>> Once you submit the new version I'll allow a couple of days for myself >>>> and others to review changes. If they look good I'll request >>>> publishing. >>>> >>>> If others have any issues, please let us know, even if passed the WGLC >>>> deadline. >>>> >>>> Stig >>>> >>>>> 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 ° From nobody Wed May 28 15:27:46 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 769481A06FA for ; Wed, 28 May 2014 15:27:42 -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 dEAlzgasGzMI for ; Wed, 28 May 2014 15:27:40 -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 A23E21A06F4 for ; Wed, 28 May 2014 15:27:39 -0700 (PDT) Received: from [10.154.208.178] (128-107-239-236.cisco.com [128.107.239.236]) by ufisa.uninett.no (Postfix) with ESMTPSA id 0E58F8025; Thu, 29 May 2014 00:27:33 +0200 (CEST) Message-ID: <538662D3.6050708@venaas.com> Date: Wed, 28 May 2014 15:27:31 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Thomas C. Schmidt" , Dirk.von-Hugo@telekom.de, multimob@ietf.org References: <533095B8.8080207@venaas.com> <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com> <5339E4CC.9040809@informatik.haw-hamburg.de> <533DCF54.1080805@venaas.com> <5356A713.1030906@venaas.com> <5356B154.3030300@informatik.haw-hamburg.de> <537A7102.30501@venaas.com> <537DDF80.7030804@informatik.haw-hamburg.de> In-Reply-To: <537DDF80.7030804@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/ZqYbBycfI_THpxxbbQOp5SrBZrg 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: Wed, 28 May 2014 22:27:42 -0000 Hi On 5/22/2014 4:29 AM, Thomas C. Schmidt wrote: > Hi Stig, Dirk, > > we just updated the document - sorry for me being slow. > > We have fixed all nits that you pointed at. > > In particular, the length counter issue should be resolved now: As this > inherited 8 bit length counter is not long enough to count bytes of MLD > state records, we propose to count four octets. This complies to the > alignment and should not be a problem. However, it leads to a feasible > number of MLD records in the payload which at least comes close to > common packet lengths. Thanks. I'll have a look at this shortly. Great if others can help verify that this change is OK as well. Stig > Best, > > Thomas > > > On 19.05.2014 22:00, Stig Venaas wrote: >> Hi >> >> On 4/22/2014 11:13 AM, Thomas C. Schmidt wrote: >>> Hi Stig, >>> >>> sorry, we've been busy otherwise. >>> >>> We'll try to update asap. >> >> How is this going? Looks like we're still waiting. >> >> Stig >> >>> Cheers, >>> >>> Thomas >>> >>> On 22.04.2014 19:29, Stig Venaas wrote: >>>> Thomas/authors, I think we're just waiting for 06 with these minor >>>> changes and we can request publication. >>>> >>>> Stig >>>> >>>> On 4/3/2014 2:15 PM, Stig Venaas wrote: >>>>> Hi >>>>> >>>>> On 3/31/2014 2:57 PM, Thomas C. Schmidt wrote: >>>>>> 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. Looks like these are the only outstanding issues. Thanks for >>>>> having a careful look Dirk. >>>>> >>>>> Once you submit the new version I'll allow a couple of days for myself >>>>> and others to review changes. If they look good I'll request >>>>> publishing. >>>>> >>>>> If others have any issues, please let us know, even if passed the WGLC >>>>> deadline. >>>>> >>>>> Stig >>>>> >>>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >