Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
Brian Haberman <brian@innovationslab.net> Mon, 16 June 2014 12:35 UTC
Return-Path: <brian@innovationslab.net>
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 B9FBB1A000F for <multimob@ietfa.amsl.com>; Mon, 16 Jun 2014 05:35:33 -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 Kdw3Ft43WCvN for <multimob@ietfa.amsl.com>; Mon, 16 Jun 2014 05:35:31 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A059F1A0005 for <multimob@ietf.org>; Mon, 16 Jun 2014 05:35:31 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 853D7880E2 for <multimob@ietf.org>; Mon, 16 Jun 2014 05:35:31 -0700 (PDT)
Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 3BE3171C0002 for <multimob@ietf.org>; Mon, 16 Jun 2014 05:35:31 -0700 (PDT)
Message-ID: <539EE499.7010702@innovationslab.net>
Date: Mon, 16 Jun 2014 08:35:37 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: 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> <538662D3.6050708@venaas.com> <05C81A773E48DD49B181B04BA21A342A2E008D20CC@HE113484.emea1.cds.t-internal.com> <539EC636.2060303@informatik.haw-hamburg.de>
In-Reply-To: <539EC636.2060303@informatik.haw-hamburg.de>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="A0sKNHXFRI7f9lnc85gJvPL3FAwMcMq8s"
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/lzHUyczqR42VaGROb1vN80Fwd0A
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: Mon, 16 Jun 2014 12:35:33 -0000
You could always borrow legacy text from RFC 791... "Internet Header Length is the length of the internet header in 32 bit words" Regards, Brian On 6/16/14 6:25 AM, Thomas C. Schmidt wrote: > Hi Dirk, > > many thanks for you continued effort! > > Making the bit counting more apparent, should not be a problem. I agree > that this is a somewhat uncommon way of counting, but prevents us from > changing the encoding structure of the mobility options, which I believe > is the more relevant part. > > What is your opinion, Stig? > > Best regards, > > Thomas > > On 16.06.2014 12:00, Dirk.von-Hugo@telekom.de wrote: >> Hi all, >> I also had a look at the latest version -06 and it seems for me to be >> ok now. >> The only minor concern might be whether the expression "length in four >> octets" is familiar enough (I didn't find this in any other draft) or >> should be mentioned especially in terms of a warning "caution!" or >> explicit (e.g. "i.e. 32 bit") or similar? >> Otherwise I am fine with it ... >> Thanks! >> Best regards >> Dirk >> >> -----Original Message----- >> From: Stig Venaas [mailto:stig@venaas.com] >> Sent: Donnerstag, 29. Mai 2014 00:28 >> To: Thomas C. Schmidt; von Hugo, Dirk; multimob@ietf.org >> Subject: Re: [multimob] Working group last call for >> draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 >> >> 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-mu >>>>>>>>> lticast-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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob >> >
- [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