Re: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05

Stig Venaas <stig@venaas.com> Wed, 28 May 2014 22:27 UTC

Return-Path: <stig@venaas.com>
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 <multimob@ietfa.amsl.com>; 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 <multimob@ietfa.amsl.com>; 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 <multimob@ietf.org>; 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 <stig@venaas.com>
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" <schmidt@informatik.haw-hamburg.de>, 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 <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: 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>