Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02

"Thomas C. Schmidt" <schmidt@fhtw-berlin.de> Sat, 15 February 2014 00:03 UTC

Return-Path: <schmidt@fhtw-berlin.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 CD8301A040C for <multimob@ietfa.amsl.com>; Fri, 14 Feb 2014 16:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level:
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 D-Y5wXqYaTts for <multimob@ietfa.amsl.com>; Fri, 14 Feb 2014 16:03:38 -0800 (PST)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 774F71A00A5 for <multimob@ietf.org>; Fri, 14 Feb 2014 16:03:38 -0800 (PST)
Envelope-to: multimob@ietf.org
Received: from g231224147.adsl.alicedsl.de ([92.231.224.147] helo=[192.168.178.49]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@fhtw-berlin.de>) id 1WESjH-000KxM-Pp; Sat, 15 Feb 2014 01:03:36 +0100
Message-ID: <52FEAED6.6050307@fhtw-berlin.de>
Date: Sat, 15 Feb 2014 01:03:34 +0100
From: "Thomas C. Schmidt" <schmidt@fhtw-berlin.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: sarikaya@ieee.org, "multimob@ietf.org" <multimob@ietf.org>
References: <CAC8QAcfO9Gq6kbUt4kQOFuFQnjTgv9HC+Ps=f43j_tkwogvuNg@mail.gmail.com>
In-Reply-To: <CAC8QAcfO9Gq6kbUt4kQOFuFQnjTgv9HC+Ps=f43j_tkwogvuNg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: multimob@ietf.org
Archived-At: http://mailarchive.ietf.org/arch/msg/multimob/8_VXMw73XyG3Q8RPy6l8Y8OBDVI
Subject: Re: [multimob] Review of draft-ietf-multimob-fmipv6-pfmipv6-multicast-02
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: Sat, 15 Feb 2014 00:03:42 -0000

Hi Behcet,

thanks for your comments: we have updated and submitted the draft.

Please see answers inline:

On 03.02.2014 00:39, Behcet Sarikaya wrote:

> Sec. 2
> In addition, the following terms are
>     introduced:
>     where are the terms?
>

Oopsi, no further terms. We have cleared this.


> Sec. 3.1
> subnet link
>     use on of them
>

OK - it's subnet now.

> when the group is
>     natively received.
>     What does this mean, please explain
>

This means native multicast packet forwarding (instead of tunneling).

> As group membership information are
>     s/are/is
>

Thanks - corrected.


> Sec. 5.3
>    The size of this option in 8 octets
>    s/in/is
>

Thanks - corrected.

> Last but not least, I think the draft finishes without a discussion of
> why this solution is needed. We need some text on this. I don't know if
> the reference "FMIPv6-Analysis" could be useful.
>

This corresponds to a comment made be Georgios. We have added the 
following subsection to the introduction:

1.1.  Use Cases and Deployment Scenarios

    Multicast Extensions for Fast Handovers enable multicast services in
    those domains that operate any of the unicast fast handover protocols
    [RFC5568] or [RFC5949].  Typically, fast handover protocols are
    activated within an operator network or within a dedicated service
    installation.

    Multicast group communication has a variety of dominant use cases.
    One traditional application area is infotainment with voluminous
    multimedia streams delivered to a large number of receivers (e.g.,
    IPTV).  Other time-critical news items like stock-exchange prices are
    commonly transmitted via multicast to support fair and fast updates.
    Both may be mobile and both largely benefit from fast handover
    operations.  Operators may enhance their operational quality or offer
    premium services by enabling fast handovers.

    Another traditional application area for multicast is conversational
    group communication in scenarios like conferencing or gaming, but
    also in dedicated collaborative environments or teams.  Machine-to-
    machine communication in the emerging Internet of Things is expected



Schmidt, et al.          Expires August 19, 2014                [Page 4]

Internet-Draft        Multicast for FMIPv6/PFMIPv6         February 2014


    to generate various additional mobile use cases (e.g., among cars).
    High demands on transmission quality and rapidly moving parties may
    require fast handovers.

    Most of the deployment scenarios above are bound to a fixed
    infrastructure with consumer equipment at the edge.  Today, they are
    thus likely to follow an operator-centric approach like PFMIPv6.
    However, Internet technologies evolve for adoption in
    infrastructureless scenarios at disaster recovery, rescue, crisis
    prevention and civil safety.  Mobile end-to-end communication in
    groups is needed in Public Protection and Disaster Relief (PPDR)
    scenarios, where mobile multicast communication needs to be supported
    between members of rescue teams, police officers, fire brigade teams,
    paramedic teams, command control offices in order to support the
    protection and health of citizens.  These use cases require fast and
    reliable mobile services which cannot rely on operator
    infrastructure.  They are thus predestined to running multicast with
    FMIPv6.

Have a safe trip to Monty Python land!

Thomas