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

<Dirk.von-Hugo@telekom.de> Thu, 27 March 2014 15:30 UTC

Return-Path: <Dirk.von-Hugo@telekom.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 0D83C1A00FD for <multimob@ietfa.amsl.com>; Thu, 27 Mar 2014 08:30:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 H2XyEjQS-Uu3 for <multimob@ietfa.amsl.com>; Thu, 27 Mar 2014 08:30:37 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 10D681A00DC for <multimob@ietf.org>; Thu, 27 Mar 2014 08:30:36 -0700 (PDT)
Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 27 Mar 2014 16:30:33 +0100
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 27 Mar 2014 16:30:32 +0100
From: Dirk.von-Hugo@telekom.de
To: stig@venaas.com, multimob@ietf.org
Date: Thu, 27 Mar 2014 16:30:32 +0100
Thread-Topic: [multimob] Working group last call for draft-ietf-multimob-fmipv6-pfmipv6-multicast-05
Thread-Index: Ac9Hn+EGCzzGAcHCSISkF+LRuDDK5wCEagig
Message-ID: <05C81A773E48DD49B181B04BA21A342A2DE422B244@HE113484.emea1.cds.t-internal.com>
References: <533095B8.8080207@venaas.com>
In-Reply-To: <533095B8.8080207@venaas.com>
Accept-Language: de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/Kvr85TdBao9D9QewlffwgcElA_Y
Cc: schmidt@informatik.haw-hamburg.de
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, 27 Mar 2014 15:30:40 -0000

Dear all,
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?

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.

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!
 
p.15
sect. 4.1.3 is on NAR, so I guess:
of the PAR => of the NAR

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?

p.21
number of muticast records => number of multicast records

or Section 4.2 of [RFC3376]) for the => or Section 4.2 of [RFC3376] for the

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) ??

for that multicast address to their MLDv2 (IGMPv2) equivalents 
=> for that multicast address to their MLDv2 (IGMPv3) equivalents

Hope this helps
Best regards
Dirk
 -----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