Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 22 May 2014 11:29 UTC
Return-Path: <prvs=2125dadc7=schmidt@informatik.haw-hamburg.de>
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 <multimob@ietfa.amsl.com>; 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 <multimob@ietfa.amsl.com>; 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 <multimob@ietf.org>; 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" <schmidt@informatik.haw-hamburg.de>
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 <stig@venaas.com>, 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 <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob/>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=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 °
- [multimob] Working group last call for draft-ietf… Stig Venaas
- Re: [multimob] Working group last call for draft-… Dirk.von-Hugo
- Re: [multimob] Working group last call for draft-… Thomas C. Schmidt
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Thomas C. Schmidt
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Thomas C. Schmidt
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Dirk.von-Hugo
- Re: [multimob] Working group last call for draft-… Thomas C. Schmidt
- Re: [multimob] Working group last call for draft-… Brian Haberman
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Thomas C. Schmidt
- Re: [multimob] Working group last call for draft-… Stig Venaas
- Re: [multimob] Working group last call for draft-… Stig Venaas