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

Stig Venaas <stig@venaas.com> Thu, 26 June 2014 17:24 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 BDF5E1B2B83 for <multimob@ietfa.amsl.com>; Thu, 26 Jun 2014 10:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 1u12_tBHE3hI for <multimob@ietfa.amsl.com>; Thu, 26 Jun 2014 10:24:55 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2::152:127]) by ietfa.amsl.com (Postfix) with ESMTP id C464E1B2B8E for <multimob@ietf.org>; Thu, 26 Jun 2014 10:24:48 -0700 (PDT)
Received: from [IPv6:2001:420:301:1004:1530:ce47:ecb5:8e4f] (unknown [IPv6:2001:420:301:1004:1530:ce47:ecb5:8e4f]) by ufisa.uninett.no (Postfix) with ESMTPSA id 2634C848F for <multimob@ietf.org>; Thu, 26 Jun 2014 19:24:46 +0200 (CEST)
Message-ID: <53AC5758.1020107@venaas.com>
Date: Thu, 26 Jun 2014 10:24:40 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <539EE499.7010702@innovationslab.net> <53ABE8CD.2030509@informatik.haw-hamburg.de>
In-Reply-To: <53ABE8CD.2030509@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/2FaivUxm5Rf0T1JFbw37FVnMQDw
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, 26 Jun 2014 17:24:59 -0000

Hi

On 6/26/2014 2:33 AM, Thomas C. Schmidt wrote:
> Hi all,
>
> as no more comments arrived, we have just updated the draft with the
> proposed text.

Great. I'll request publishing of this then. I'll try to get this
done early next week. Please everyone, have a look at the latest
document and let us know if any concerns. If you read the previous
versions the couple of latest diffs would be of help. See
http://tools.ietf.org/wg/multimob/draft-ietf-multimob-fmipv6-pfmipv6-multicast/
for the different versions and diffs.

Stig

> Best,
>
> Thomas
>
> On 16.06.2014 14:35, Brian Haberman wrote:
>> 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 mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/listinfo/multimob
>>
>