[multimob] Some comments on draft-ietf-multimob-fmipv6-pfmipv6-multicast-03
Stig Venaas <stig@venaas.com> Thu, 13 March 2014 22:30 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 B21291A0768 for <multimob@ietfa.amsl.com>; Thu, 13 Mar 2014 15:30:21 -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 qPTpRtWjst3b for <multimob@ietfa.amsl.com>; Thu, 13 Mar 2014 15:30:20 -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 E96BE1A076F for <multimob@ietf.org>; Thu, 13 Mar 2014 15:30:19 -0700 (PDT)
Received: from [IPv6:2001:420:301:1004:9d8d:9681:1552:34db] (unknown [IPv6:2001:420:301:1004:9d8d:9681:1552:34db]) by ufisa.uninett.no (Postfix) with ESMTPSA id 1AFFA8047; Thu, 13 Mar 2014 23:30:11 +0100 (CET)
Message-ID: <53223171.8000608@venaas.com>
Date: Thu, 13 Mar 2014 15:30:09 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: draft-ietf-multimob-fmipv6-pfmipv6-multicast@tools.ietf.org
References: <53222064.5030808@venaas.com> <532220D4.2090009@informatik.haw-hamburg.de>
In-Reply-To: <532220D4.2090009@informatik.haw-hamburg.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/-Sfit_Mxv4gIoLkz9SE9fg9fILA
Cc: "multimob@ietf.org" <multimob@ietf.org>
Subject: [multimob] Some comments on draft-ietf-multimob-fmipv6-pfmipv6-multicast-03
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, 13 Mar 2014 22:30:21 -0000
Hi Here are my comments on the 03 version. There may be a line that is too long, and there is one case where a "MUST not" needs to be replaced with "MUST NOT". Please see the idnits. http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt One thing is unclear to me in 3.3. It says: There are two ways to obtain the multicast membership of an MN. First, MAGs may perform explicit tracking (see [RFC4605], [RFC6224]) or extract membership status from forwarding states at node-specific point-to-point links. Second, routers can issue a general MLD query at handovers. Both methods are equally Are you assuming point-to-point links in this second case? If not, then I don't see how the PAR can find out the MNs subscribed groups just by doing an MLD query. Also wondering if it should be pointed out here that it's not just groups. For SSM it would be (S,G) or channels. I see it says groups/channels many other places though. It might be worth explaining what the term channel means. applicable. However, a router that does not operate explicit tracking needs to query its downstream links after a handover. The MLD membership information then allows the PAR to know the multicast group subscriptions of the MN. In predictive mode, the PMAG (PAR) will learn about the upcoming movement of the mobile node. Without explicit tracking, it will immediately submit a general MLD query and receive MLD reports for the subscribed group(s). As displayed in Figure 4, it will initiate binding and context transfer with the NMAG (NAR) by issuing a HI message that is augmented by multicast contexts in the mobility options defined in Section 5.3. NAR will extract multicast context information and act as described in Section 3.1. In 4.2.2 it says "it MAY need to issue". I don't think this is the appropriate use of MAY. It's not like MAY implement, or MAY do something. There is no freedom of choice here. Whether it is done or not just depends on the situation. I think you could replace "MAY" with "will". In 5.3 it says: Length: 8-bit unsigned integer. The size of this option is 8 octets including the Type, Option-Code, and Length fields. How can this be 8 octets. It looks like 4 octets when including the reserved field, and then the total length varies with the size of the report payload? But I guess the payload is always at least 4 octets? In 5.4 it says: Length: 8-bit unsigned integer. The size of this option in 8 octets. The length is 1 when the MLD (IGMP) Unsupported Report Payload field contains no Mcast Address Record. Should it say "is" like in 5.3, or should 5.4 say "in"? It looks to me like the length is 4 if there is no payload. Or is the payload at least 4 octets? In 5.4 it says: that are not supported or prohibited in the new access network. This field MUST always contain the first header line (reserved field and No of Mcast Address Records), but MUST NOT contain any Mcast Address Records, if the status code equals 1. Should it say this in 5.3 as well? It might be good to make the IANA considerations more explicit. It would be good to explicitly specify what the new tables look like. Stig
- [multimob] Some comments on draft-ietf-multimob-f… Stig Venaas
- Re: [multimob] Some comments on draft-ietf-multim… Thomas C. Schmidt