From sarikaya2012@gmail.com  Mon Sep  2 12:16:23 2013
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C940721F9655 for <multimob@ietfa.amsl.com>; Mon,  2 Sep 2013 12:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6mP5n0D12Dy for <multimob@ietfa.amsl.com>; Mon,  2 Sep 2013 12:16:22 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2C21F95DD for <multimob@ietf.org>; Mon,  2 Sep 2013 12:16:21 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id w6so4152543lbh.5 for <multimob@ietf.org>; Mon, 02 Sep 2013 12:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=vNeECAInGpwd9HFEcRh5qAb17Bc6oc3RHoUaiU0Ezyw=; b=xkPb3fZQqLHgeSNkCEUf8sMznWzZkS/jPADz7F3xfvcnEFtK8sOC5lED2bIAXyDdFN hEf9PDG13vMvlExVKqOvXUdt/dNr1ft5hoOMrp8fXF9HLhLjkCLmLFnv4j7Ik859jfNi CYoWTHIEqz1A3SGIm0gGfI6bR86J9rCelv0pUqabJTmp2douse6trkcYzBsOTcWdrAe7 HwXZriteGHrFAR2FfPafucpjzOtBmzJxeyWIorpMJ/IiWN6++hVo6vH3PuxS5UGY0i5c IjYtyLr85kecVDn4YEQ8vf0AszqIpcro4GaXzrM8ewM1ozu35JjGAY5orG8g0CnEEH+R 1Emg==
MIME-Version: 1.0
X-Received: by 10.152.115.176 with SMTP id jp16mr22867823lab.17.1378149381066;  Mon, 02 Sep 2013 12:16:21 -0700 (PDT)
Received: by 10.114.98.227 with HTTP; Mon, 2 Sep 2013 12:16:21 -0700 (PDT)
Date: Mon, 2 Sep 2013 14:16:21 -0500
Message-ID: <CAC8QAccTW+1-uSz7HohG5Mnqd9TJex1YDoD1G96s9m0C2EQbZw@mail.gmail.com>
From: Behcet Sarikaya <sarikaya2012@gmail.com>
To: "multimob@ietf.org" <multimob@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c350964e53df04e56b687d
Subject: [multimob] draft-ietf-multimob-handover-optimization-03 WGLC
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: sarikaya@ieee.org
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: Mon, 02 Sep 2013 19:16:23 -0000

--001a11c350964e53df04e56b687d
Content-Type: text/plain; charset=ISO-8859-1

Working group last call on this draft has ended.

The authors, please submit your revised version.

Regards,

Behcet

--001a11c350964e53df04e56b687d
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div><div><div>Working group last call on this draft has ended.<br><br></div>The authors, please submit your revised version.<br><br></div>Regards,<br><br></div>Behcet<br></div>

--001a11c350964e53df04e56b687d--

From Akbar.Rahman@InterDigital.com  Fri Sep  6 17:15:07 2013
Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786C121E80F1 for <multimob@ietfa.amsl.com>; Fri,  6 Sep 2013 17:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.227
X-Spam-Level: 
X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyIn3ZEKWpQf for <multimob@ietfa.amsl.com>; Fri,  6 Sep 2013 17:15:03 -0700 (PDT)
Received: from smtp-out1.interdigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B721E80B4 for <multimob@ietf.org>; Fri,  6 Sep 2013 17:15:00 -0700 (PDT)
Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 6 Sep 2013 20:14:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 6 Sep 2013 20:14:48 -0400
Message-ID: <D60519DB022FFA48974A25955FFEC08C054A3C8A@SAM.InterDigital.com>
In-Reply-To: <521BBA92.9070002@informatik.haw-hamburg.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
Thread-Index: Ac6imy76fcrxQXDtSiWFk5B6FSlr0AIuKWsw
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com><05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <521BBA92.9070002@informatik.haw-hamburg.de>
From: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
To: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
X-OriginalArrivalTime: 07 Sep 2013 00:14:59.0935 (UTC) FILETIME=[4A6EEEF0:01CEAB5F]
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Sep 2013 00:15:07 -0000

Hi Thomas,


I also reviewed draft-ietf-multimob-pmipv6-source-04 and following is my =
feedback/


Overall the I-D is in very nice shape and I think ready to progress to =
the next stage.  I only had a few comments for you to take into =
consideration (beyond the thorough review that Dirk already did).

1) Section 1 (Introduction)
- Can you put a reference for the 3rd paragraph?
- The word "enfold" in 4th paragraph does not seem grammatically correct =
in the given sentence.  Perhaps use another word?
- I am not a big gamer, so can you please explain why a "server-centric =
gaming" is multicast listener only?  How can you have a game without =
user feedback?


2) Section 3.1 (Overview)
- Do you think it would be worthwhile explaining the acronyms =
(notations) in Figure 1 (e.g. LMAA1, MN-HNP1, etc.)?  The meaning of =
some are not obvious.
- One question on "MRIB".  In this I-D it seems to be a key concept, but =
why was there no mention of it in RFC 6224?


3) Section 9 (Security Considerations)
- Remove the "TODO"
- I don't think the wording of the 1st paragraph is good.  I think that =
there definitely is a new threat introduced with the support of mobile =
multicast senders.  For example, wouldn't there be new modes of Denial =
of Service attacks?  For example, if flash mobs of mobile attackers =
appeared in certain localized areas (e.g. WiFi hotspot, cellular BS) and =
generated high amounts of multicast sender traffic.  I don't think that =
this type of attack was possible with RFC 6224.  Do you agree?



Best Regards,


Akbar


-----Original Message-----
From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On =
Behalf Of Thomas C. Schmidt
Sent: Monday, August 26, 2013 4:29 PM
To: Dirk.von-Hugo@telekom.de
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: =
draft-ietf-multimob-pmipv6-source-04.txt

Hi Dirk,

thanks for your thorough review. I'll come back to this in detail a few =
days.

Best regards,

Thomas

On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote:
> Dear all,
> As promised at IETF-87 I did a review of the source multicast mobility =
draft and think the document is in quite good shape.
>
> Being not the distinct expert in details of multicast protocols I am =
not sure to have understood everything in detail, so please correct me =
and forgive misunderstandings ...
>
> The three scenarios described are
> 1) the base solution with MLD proxies at MAGs (and optionally also at=20
> LMAs) (sect.3)
> 2) direct routing with or without MLD proxies at MAGs and with native=20
> Multicast support at MAG level or above via different established=20
> Multicast protocols (sect.4)
> 3) Routing optimization for direct routing with MLD proxies at MAGs=20
> (sect. 5) Right?
> IMHO from the abstract this is not easily to see.
>
> I have some comments and suggestions to increase readability, in =
addition to some nits found, given in the following:
>
> Fig. 1, fig.3 to be placed on single pages to simplify readability.
> Consistently use re-attach and re-distribute _or_ reattach and =
redistribute, respectively, throughout document.
> Is there any implicit meaning of Proxy with respect to proxy? Also MLD =
Proxy and MLD proxy are both used throughout the document ...
>
> p.1
>     optimizations for synchronizing PMIPv6 with PIM, as well as a =
peering
>     function for MLD Proxies defined.
> =3D>   optimizations for synchronizing PMIPv6 with PIM, as well as a =
peering
>     function for MLD Proxies are defined.
>
> p.3
> Such approaches (partially) follow the
>     business model of providing multicast data services in parallel to
>     PMIPv6 unicast routing.
> =3D=3D> shouldn't one or more references be added here such as to =
[I-D.ietf-multimob-pmipv6-ropt], =
draft-ietf-multimob-fmipv6-pfmipv6-multicast, =
draft-ietf-multimob-handover-optimization  ...?
>
> needs of receptive use cases
> =3D> needs of applications for mobile multicast reception of content=20
> from few and mainly fixed content sources
>
> p.5
>
> A multicast unaware MAG would simply discard these packets in
>     the absence of a multicast routing information base (MRIB).
> =3D=3D> shouldn't one add more information about MRIBs introduced here =
for non-multicast aware readers such as: Such tables similar to MFIBs =
mentioned in RFC 6224 ensure that the router is able to correctly =
route/forward packets with multicast addresses as destinations .
>
> In case of a handover, the MN (unaware of IP mobility) =3D> In case of =
a=20
> handover, the MN (being unaware of IP mobility)
>
> as soon as network connectivity is
>     reconfigured
> =3D> as soon as network connectivity is
>     re-established
>
> p.7
> multicast data is =3D> multicast data are
>
> p.8
> In addition, an LMA serving as PIM Designated Router is connected =3D> =
=20
> In addition, an LMA serving as PIM Designated Router (DR) is connected
>
> incoming interface validation is only performed by RPF
>     checks
> =3D> incoming interface validation is only performed by RPF (Reverse =
Path Forwarding)
>     checks
>
> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>     respect to source location and does not require special
>     configurations or state management for sources.
> =3D=3D> Wouldn't it make sense to add a reason for this, e.g.
> ... since BIDIR PIM automatically builds trees to allow multicast data =
to be natively forwarded from sources to receivers without requiring =
source-specific information ...
> On the other hand a reference to sect. 4.4 might be perhaps misleading =
here since this section is not on direct multicast routing?!
>
> an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as =
for
>     IPv6.
> =3D> an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as =
is done for an MLD proxy for
>     IPv6.
>
> p.9
> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances =
=3D>=20
> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances=20
> (i.e. IPMP/MLD proxy functions)
>
> In the following, efficiency-related issues remain.
> =3D> In the following, efficiency-related issues which remain unsolved =
within the above defined base PMIPv6 multicast source support are =
described.
>
> p.11
> upstream will lead traffic into the multicast infrastructure =3D> =20
> upstream will transfer traffic into the multicast infrastructure
>
> p.12
> configurations have completed =3D> configurations have been completed
>
> traffic from the mobile source continues to be transmitted via the
>     same next-hop router using the same source address =3D>  traffic=20
> from the mobile source continues to be transmitted via the
>     same next-hop multicast router using the same source address
>
> by aggregating proxies on a lower layer.
> =3D=3D> please clarify: what layer exactly is proposed? PIM DR at =
MAGs?
>
>    in the access network for providing multicast services in parallel =
to
>     unicast routes.
> =3D>  in the access network for providing multicast services in =
parallel to
>     unicast routes ( see Fig. 3(b)).
>
> p.13
>    The following information is needed for all phases of PIM.
> =3D>  The following information is needed for all three phases of PIM =
as outlined in [RFC4601].
>
> P.14
> configured to not initiated (S,G) shortest path tress for mobile =3D>=20
> configured to not initiated (S,G) shortest path trees for mobile
>
> mobile source.  This tree can be of lesser routing efficiency than =
=3D>=20
> mobile source.  This tree can be of lower routing efficiency than
>
> In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface immediately responds with a register stop.
> =3D> In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface and thus (?) immediately respond with a =
register stop.
>
> As the
>     RP had joined the shortest path tree to receive from the source =
via
>     the LMA,
> =3D>As the
>     RP has joined the shortest path tree to receive data from the =
source via
>     the LMA,
>
> the LMA, it will see an RPF change when data arrives at a new =3D> the =

> LMA, it will see an RPF change when data arrive at a new
>
> In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiated a source-specific Join for =
=3D>=20
> In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiate a source-specific Join for
>
> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
>     mobile source
> =3D>
> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the =
serving MAG to the
>     mobile source (described from leave to root?)
>
> This tree is of higher routing efficiency than established in the=20
> previous phase two =3D> This tree is of higher routing efficiency than
>   that established in the previous phase two
>
> p.15
> via the source register tunnel.  Tree mainenance eventually triggered=20
> =3D> via the source register tunnel.  Tree maintenance eventually=20
> triggered
>
> p.16
>    BIDIR-PIM MAY be deployed in the access network =3D>  BIDIR-PIM=20
> [RFC5015] MAY be deployed in the access network
>
> remain uneffected by node mobility =3D> remain unaffected by node=20
> mobility
>
> spanning group tree =3D> spanning tree for the multicast group=20
> /multicast spanning tree
>
> p.17
> document.  To overcome these deficits, an optimized approach to =
=3D=3D>=20
> AFAIU it does mainly cover deficits mentioned in sect. 4, if also=20
> those inefficiencies described in 3.2.5 are tackled this should be=20
> explained
>
> Following different techniques, these requirements are met in the
>     following solutions.
> =3D=3D> to me it seems to be one solution only (peering between MLD=20
> proxies) adapted to several multicast protocol implementations for ASM =

> and SSM
>
> but provide superior performance in the presence of source-
>     specific signaling (IGMPv3/MLDv2).
> =3D=3D> Wouldn't a reference to RFC 4604 ("Using Internet Group =
Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery =
Protocol Version 2 (MLDv2) for Source-Specific Multicast") make sense or =
be helpful here?
>
> p.18
> This filter base Must be updated, if and =3D> This filter base MUST be =

> updated, if and
>
> In
>     addition, local multicast packets are transferred =3D> In
>     addition, multicast packets from locally attached sources are=20
> transferred
> or:
>   In addition, such locally arriving multicast packets are transferred
>
> p.19
> 6.  IANA Considerations
>     TODO.
> =3D=3D> to me there seem to be no IANA activities arising from the =
proposed protocol modifications, right?
>
> p.20
> the PMIPv6 domain will not actively terminate group membership prior
>     to departure.
> =3D>
> the PMIPv6 domain will in general not actively terminate group =
membership prior
>     to departure.
>
> p.22
> but alternate configuriations =3D> but alternate configurations
>
> a state decomposition , if needed =3D> a state decomposition, if =
needed...
>
> Hope this helps.
> Thanks!
>
> Best regards
> Dirk
>
> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On=20
> Behalf Of internet-drafts@ietf.org
> Sent: Samstag, 13. Juli 2013 00:50
> To: i-d-announce@ietf.org
> Cc: multimob@ietf.org
> Subject: [multimob] I-D Action:=20
> draft-ietf-multimob-pmipv6-source-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>   This draft is a work item of the Multicast Mobility Working Group of =
the IETF.
>
> 	Title           : Mobile Multicast Sender Support in Proxy Mobile =
IPv6 (PMIPv6) Domains
> 	Author(s)       : Thomas C. Schmidt
>                            Shuai Gao
>                            Hong-Ke Zhang
>                            Matthias Waehlisch
> 	Filename        : draft-ietf-multimob-pmipv6-source-04.txt
> 	Pages           : 24
> 	Date            : 2013-07-12
>
> Abstract:
>     Multicast communication can be enabled in Proxy Mobile IPv6 =
domains
>     via the Local Mobility Anchors by deploying MLD Proxy functions at
>     Mobile Access Gateways, via a direct traffic distribution within =
an
>     ISP's access network, or by selective route optimization schemes.
>     This document describes the support of mobile multicast senders in
>     Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>     optimizations for synchronizing PMIPv6 with PIM, as well as a =
peering
>     function for MLD Proxies defined.  Mobile sources always remain
>     agnostic of multicast mobility operations.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04
>
> A diff from the previous version is available at:
> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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
>

--=20

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg University of Applied Sciences                   Berliner =
Tor 7 =B0
=B0 Dept. Informatik, Internet Technologies Group    20099 Hamburg, =
Germany =B0
=B0 http://www.haw-hamburg.de/inet                   Fon: =
+49-40-42875-8452 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt    Fax: =
+49-40-42875-8409 =B0
_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

From internet-drafts@ietf.org  Wed Sep 11 12:07:35 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9B921E8122; Wed, 11 Sep 2013 12:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level: 
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOw0U58NmhXi; Wed, 11 Sep 2013 12:06:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C79E21F9E9F; Wed, 11 Sep 2013 12:06:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.71.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130911190556.12012.240.idtracker@ietfa.amsl.com>
Date: Wed, 11 Sep 2013 12:05:56 -0700
Cc: multimob@ietf.org
Subject: [multimob] I-D Action: draft-ietf-multimob-handover-optimization-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Sep 2013 19:07:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multicast Mobility Working Group of the I=
ETF.

	Title           : PMIPv6 multicast handover optimization by the Subscripti=
on Information Acquisition through the LMA (SIAL)
	Author(s)       : Luis M. Contreras
                          Carlos J. Bernardos
                          Ignacio Soto
	Filename        : draft-ietf-multimob-handover-optimization-04.txt
	Pages           : 36
	Date            : 2013-09-11

Abstract:
   This document specifies an experimental multicast handover
   optimization mechanism for Proxy Mobile IPv6 to accelerate the
   delivery of multicast traffic to mobile nodes after handovers.  The
   mechanism is based on speeding up the acquisition of mobile nodes'
   multicast context by the mobile access gateways.  To do that,
   extensions to the current Proxy Mobile IPv6 protocol are proposed.
   These extensions are not only applicable to the base solution for
   multicast support in Proxy Mobile IPv6, but they can also be applied
   to other solutions developed to avoid the tunnel convergence problem.
   Furthermore, these extensions are also independent of the role played
   by the mobile access gateway within the multicast network (either
   acting as multicast listener discovery proxy or multicast router).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-multimob-handover-optimization

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-multimob-handover-optimization-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-handover-optimizatio=
n-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From lmcm@tid.es  Wed Sep 11 12:12:53 2013
Return-Path: <lmcm@tid.es>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4023B21F9EA2 for <multimob@ietfa.amsl.com>; Wed, 11 Sep 2013 12:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXviZgWQZuXk for <multimob@ietfa.amsl.com>; Wed, 11 Sep 2013 12:12:48 -0700 (PDT)
Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7B34621F8443 for <multimob@ietf.org>; Wed, 11 Sep 2013 12:11:51 -0700 (PDT)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MSZ009K06NQ5I@tid.hi.inet> for multimob@ietf.org; Wed, 11 Sep 2013 21:11:50 +0200 (MEST)
Received: from vanvan (vanvan.hi.inet [10.95.78.49])	by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 78.37.28420.570C0325; Wed, 11 Sep 2013 21:11:49 +0200 (CEST)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MSZ009JV6NO5I@tid.hi.inet> for multimob@ietf.org; Wed, 11 Sep 2013 21:11:49 +0200 (MEST)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 21:11:48 +0200
Date: Wed, 11 Sep 2013 19:11:47 +0000
From: LUIS MIGUEL CONTRERAS MURILLO <lmcm@tid.es>
In-reply-to: <CAC8QAccTW+1-uSz7HohG5Mnqd9TJex1YDoD1G96s9m0C2EQbZw@mail.gmail.com>
X-Originating-IP: [10.95.64.115]
To: "sarikaya@ieee.org" <sarikaya@ieee.org>, "multimob@ietf.org" <multimob@ietf.org>
Message-id: <823234EF5C7C334998D973D822FF801B44FDFEF2@EX10-MB2-MAD.hi.inet>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_NVqlRT75wrrV6YchA+ckkQ)"
Content-language: es-ES
Accept-Language: es-ES, en-US
Thread-topic: [multimob] draft-ietf-multimob-handover-optimization-03 WGLC
Thread-index: AQHOqBDy+vifgRZ32kuyHzTGfjUsEJnA9Jxg
X-AuditID: 0a5f4e69-b7fe58e000006f04-68-5230c07514bb
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhivcz1C07YBBk8GgKn8WMj30sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6Di2m7HglmbF7RWtLA2MU1W7GDk5JARMJHYdfc4OYYtJXLi3 nq2LkYtDSGA7o8SuzStYIZw/jBKb9/xkhnA2Mkocf/OIGaSFRUBVou3MTiYQm03AUGLWzkms ILawgKdE48XZLCA2p0CwxL0nt1khVihI/Dn3GCwuIhAmsa5lEtgcZoE0iY/nr4LFeQW8Ja48 uwllC0r8mHyPBaImV+Jhyx5GCFtcYs6viWAzGQVkJVaeP80IMdNLYvqf80wQtpHEwv+/oPYK SCzZc54ZwhaVePn4H1hcSCBAYmPHMaYJjGKzkKybhWTdLCTrIGwdiQW7P7FB2NoSyxa+Zoax zxx4zIQsvoCRfRWjWHFSUWZ6RkluYmZOuoGRXkamXmZeaskmRkjkZe5gXL5T5RCjAAejEg9v xyyDICHWxLLiytxDjBIczEoivO0TgEK8KYmVValF+fFFpTmpxYcYmTg4pRoY1adfuahx0HJx 2a21+pt8bhWeqHm8j+fD3ZX1t7wiNXqfbD+Xdf5R4kO+h+umqL5/4zD5b1H42p9KhQUqP8rr k8u3LfuxjLXxT84x3WTmuNuOLz+YTsqs815ps3mpr4APi5x/3YmTPsvV8ooYYh+eVIl80L1S OvKBdkzIxuCtH3Q/7w4stgrVV2Ipzkg01GIuKk4EAN2idTmaAgAA
References: <CAC8QAccTW+1-uSz7HohG5Mnqd9TJex1YDoD1G96s9m0C2EQbZw@mail.gmail.com>
Subject: Re: [multimob] draft-ietf-multimob-handover-optimization-03 WGLC
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Sep 2013 19:12:53 -0000

--Boundary_(ID_NVqlRT75wrrV6YchA+ckkQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Behcet,

The version of the draft addressing the comments received during the WG last call process has been just uploaded.

Thanks,

Best regards,

Luis


De: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] En nombre de Behcet Sarikaya
Enviado el: lunes, 02 de septiembre de 2013 21:16
Para: multimob@ietf.org
Asunto: [multimob] draft-ietf-multimob-handover-optimization-03 WGLC

Working group last call on this draft has ended.
The authors, please submit your revised version.
Regards,
Behcet

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

--Boundary_(ID_NVqlRT75wrrV6YchA+ckkQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
	{font-family:Calibri}
@font-face
	{font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline}
span.EstiloCorreo17
	{font-family:"Calibri","sans-serif";
	color:#1F497D}
.MsoChpDefault
	{font-family:"Calibri","sans-serif"}
@page WordSection1
	{margin:70.85pt 3.0cm 70.85pt 3.0cm}
div.WordSection1
	{}
-->
</style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Hi Behcet,
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">The version of the draft addressing the comments received during the WG last call process has been just uploaded.
</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Thanks,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Best regards,</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">Luis</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt; font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;; color:#1F497D">&nbsp;</span></p>
<p class="MsoNormal"><b><span lang="ES" style="font-size:10.0pt; font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">De:</span></b><span lang="ES" style="font-size:10.0pt; font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org]
<b>En nombre de </b>Behcet Sarikaya<br>
<b>Enviado el:</b> lunes, 02 de septiembre de 2013 21:16<br>
<b>Para:</b> multimob@ietf.org<br>
<b>Asunto:</b> [multimob] draft-ietf-multimob-handover-optimization-03 WGLC</span></p>
<p class="MsoNormal">&nbsp;</p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Working group last call on this draft has ended.</p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The authors, please submit your revised version.</p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Regards,</p>
</div>
<p class="MsoNormal">Behcet</p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol&iacute;tica de env&iacute;o y recepci&oacute;n de correo electr&oacute;nico en el enlace situado m&aacute;s abajo.<br>
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:<br>
http://www.tid.es/ES/PAGINAS/disclaimer.aspx<br>
</font>
</body>
</html>

--Boundary_(ID_NVqlRT75wrrV6YchA+ckkQ)--

From wwwrun@rfc-editor.org  Fri Sep 20 12:56:15 2013
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8109D21F9E0B; Fri, 20 Sep 2013 12:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.286
X-Spam-Level: 
X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVkqNZmeGui9; Fri, 20 Sep 2013 12:56:15 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D781621F9E02; Fri, 20 Sep 2013 12:56:14 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 2964BB1E011; Fri, 20 Sep 2013 12:49:39 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130920194939.2964BB1E011@rfc-editor.org>
Date: Fri, 20 Sep 2013 12:49:39 -0700 (PDT)
Cc: drafts-update-ref@iana.org, multimob@ietf.org, rfc-editor@rfc-editor.org
Subject: [multimob] RFC 7028 on Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 20 Sep 2013 19:56:15 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7028

        Title:      Multicast Mobility Routing Optimizations for 
                    Proxy Mobile IPv6 
        Author:     JC. Zuniga, LM. Contreras,
                    CJ. Bernardos, S. Jeon,
                    Y. Kim
        Status:     Experimental
        Stream:     IETF
        Date:       September 2013
        Mailbox:    JuanCarlos.Zuniga@InterDigital.com,
                    lmcm@tid.es,
                    cjbc@it.uc3m.es,
                    seiljeon@av.it.pt,
                    yhkim@dcn.ssu.ac.kr
        Pages:      29
        Characters: 63110
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-multimob-pmipv6-ropt-08.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7028.txt

This document proposes some experimental enhancements to the base
solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6)
domain.  These enhancements include the use of a multicast tree
mobility anchor as the topological anchor point for multicast
traffic, as well as a direct routing option where the Mobile Access
Gateway can provide access to multicast content in the local network.
The goal of these enhancements is to provide benefits such as
reducing multicast traffic replication and supporting different
PMIPv6 deployment scenarios.

This document is a product of the Multicast Mobility Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

From gaoxlh@gmail.com  Wed Sep 25 00:49:24 2013
Return-Path: <gaoxlh@gmail.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E540421F9E76 for <multimob@ietfa.amsl.com>; Wed, 25 Sep 2013 00:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.018
X-Spam-Level: ****
X-Spam-Status: No, score=4.018 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Feiji891lMzS for <multimob@ietfa.amsl.com>; Wed, 25 Sep 2013 00:49:24 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5A59921F9F8F for <multimob@ietf.org>; Wed, 25 Sep 2013 00:49:22 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id q10so5666431pdj.7 for <multimob@ietf.org>; Wed, 25 Sep 2013 00:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-transfer-encoding; bh=2hJyYZF5hKvYW/wXGentKE30qVm52RrzHBc7m63WV8o=; b=va39gvy3wu1vjbRnFBQAxQINmvAzCdEbx2j9fh0J+oWq8DPhOen+DzaUDDJG6z4KvL VVnUt2TI74SKjbnuz1Y3KYjzH59arvmhgtDn5VifCfiGg/n7dmT9PK+9wC9k7TWTchLx nQCvBpSGblVSRn3hYJ5kvLJQa+2rMRQm1U9N2x7llkmaKoGXWlzrKN9VEraP1RVQNZtY Fol24W5+uHvWmE3/s2ylNfEcqgwZmexuI39Ek1SW722ICmAcpuVVZUwQjJWSg/EC/Op2 ZoMVbmvx9W0MWK1coqfSZGNWE3I2JPnDeIHmJ9AcmrIInE2+k6fnxbN3qJHbBLtoBXZ4 fj5Q==
X-Received: by 10.66.248.130 with SMTP id ym2mr9510997pac.177.1380095361099; Wed, 25 Sep 2013 00:49:21 -0700 (PDT)
Received: from admin-PC ([221.130.41.92]) by mx.google.com with ESMTPSA id ia5sm45728911pbc.42.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 00:49:19 -0700 (PDT)
Date: Wed, 25 Sep 2013 15:49:14 +0800
From: "Shuai Gao" <gaoxlh@gmail.com>
To: "schmidt" <schmidt@informatik.haw-hamburg.de>
Message-ID: <201309251549114085692@gmail.com>
X-mailer: Foxmail 6, 14, 103, 30 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Cc: multimob <multimob@ietf.org>
Subject: Re: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 07:49:25 -0000

SGkgVGhvbWFzLA0KDQpBcyBwcm9taXNlZCBhdCBJRVRGLTg3LCBJIGhhdmUgcmV2aWV3ZWQgdGhl
IEZhc3QgSGFuZG92ZXIgZHJhZnQuIE92ZXJhbGwgdGhlIEktRCBpcyBpbiB2ZXJ5IGdvb2Qgc2hh
cGUuIEkgaGF2ZSBhIGZldyBjb21tZW50cyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLiANCg0KMSkJ
UDM6IGltcHJvdmUgdGhlc2UgaGFuZG92ZXIgZGVsYXlzIGZvciB1bmljYXN0IGNvbW11bmljYXRp
b24gdG8gdGhlIG9yZGVyIG9mIHRoZSBtYXhpbXVtIGRlbGF5IG5lZWRlZCBmb3IgbGluayBzd2l0
Y2hpbmcgYW5kIHNpZ25hbGluZyBiZXR3ZWVuIEFjY2VzcyBSb3V0ZXJzIChBUnMpIG9yIE1vYmls
ZSBBY2Nlc3MgR2F0ZXdheXMgKE1BR3MpIFtGTUlQdjYtQW5hbHlzaXNdLiA9PT4gaW1wcm92ZSB0
aGUgcGVyZm9ybWFuY2Ugb2YgaGFuZG92ZXIgZGVsYXlzoa2hrSBBbHNvLCB3aGF0IGRvZXMgobB0
byB0aGUgb3JkZXKhsSBtZWFuIGluIHRoaXMgc2VudGVuY2U/DQoNCjIpCVA1OiBUaGUgc3BlY2lm
aWVkIG1lY2hhbmlzbXMgYXBwbHkgd2hlbiBhIG1vYmlsZSBub2RlIGhhcyBqb2luZWQgYW5kIG1h
aW50YWluc6GtID09PiBUaGUgc3BlY2lmaWVkIG1lY2hhbmlzbXMgYXBwbHkgd2hlbiBhIG1vYmls
ZSBub2RlIGhhcyBqb2luZWQgYW5kIG1haW50YWluZWShrQ0KDQozKQlQNjogRGVwZW5kaW5nIG9u
IHRoZSBzcGVjaWZpYyBuZXR3b3JrIHRvcG9sb2d5IHRob3VnaCwgbXVsdGljYXN0IHRyYWZmaWMg
Zm9yIHNvbWUgZ3JvdXBzIKGtID09PiBkZWxldGUgdGhlIHdvcmQgobB0aG91Z2ihsSBpbiB0aGlz
IHNlbnRlbmNlLiANCg0KNCkJUDY6IHRoYXQgbWFrZSBpdCB1bmRlc2lyYWJsZSB0byBmb3J3YXJk
IHRoZSBtdWx0aWNhc3QgdHJhZmZpYy5UaGUgUEFSIGNhbqGtID09PiB0aGF0IG1ha2UgaXQgdW5k
ZXNpcmFibGUgdG8gZm9yd2FyZCB0aGUgbXVsdGljYXN0IHRyYWZmaWMuIFRoZSBQQVIgY2Fuoa0N
Cg0KNSkJUDc6IFRoZSBOQVIgaW1wbGVtZW50cyBhbiBNTEQgcHJveHkgW1JGQzQ2MDVdIHByb3Zp
ZGluZyBob3N0LXNpZGUgYmVoYXZpb3VyIG9uIGJlaGFsZiBvZiB0aGUgdXBzdHJlYW0gUEFSLiA9
PT4gIEhlcmUsIKGwb24gYmVoYWxmIG9mIHRoZSB1cHN0cmVhbSBQQVKhsSBpcyBsaXR0bGUgY29u
ZnVzaW5nLiBJIHN1Z2dlc3QgdG8gbW9kaWZ5IHRvIKGxIHRvd2FyZHMgdGhlIHVwc3RyZWFtIFBB
Ui6hsQ0KDQo2KQlQOTogSW4gZmlndXJlIDMsIEZCVSBoYXMgY29udGFpbmVkIHRoZSBNdWx0aWNh
c3QgT3B0aW9uLCBhbmQgdGhlcmVieSBib3RoIFBBUiBhbmQgTkFSIGhhdmUga25vd24gdGhlIHJl
bGF0ZWQgbXVsdGljYXN0IGluZm9ybWF0aW9uLiBTbyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciBp
dKGvcyBuZWNlc3NhcnkgdG8gaW5jbHVkZSBNdWx0aWNhc3QgT3B0aW9uIGluIHRoZSBISSBtZXNz
YWdlIGhlcmU/IA0KDQpCZXN0IFJlZ2FyZHMsDQpTaHVhaQ0KCQ0KDQo9PT09PT09IDIwMTMtMDIt
MjYgMDc6NDQ6MTAgxPrU2sC00MXW0NC0tcCjuj09PT09PT0NCg0KPg0KPkEgTmV3IEludGVybmV0
LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl
Y3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGljYXN0IE1v
YmlsaXR5IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+CVRpdGxlICAgICAgICAgICA6
IE11bHRpY2FzdCBMaXN0ZW5lciBFeHRlbnNpb25zIGZvciBNSVB2NiBhbmQgUE1JUHY2IEZhc3Qg
SGFuZG92ZXJzDQo+CUF1dGhvcihzKSAgICAgICA6IFRob21hcyBDLiBTY2htaWR0DQo+ICAgICAg
ICAgICAgICAgICAgICAgICAgICBNYXR0aGlhcyBXYWVobGlzY2gNCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgIFJhamVldiBLb29kbGkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEdvZHJl
ZCBGYWlyaHVyc3QNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIERhcGVuZyBMaXUNCj4JRmls
ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tdWx0aW1vYi1mbWlwdjYtcGZtaXB2Ni1tdWx0aWNh
c3QtMDEudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDI3DQo+CURhdGUgICAgICAgICAgICA6IDIw
MTMtMDItMjUNCj4NCj5BYnN0cmFjdDoNCj4gICBGYXN0IGhhbmRvdmVyIHByb3RvY29scyBmb3Ig
TUlQdjYgYW5kIFBNSVB2NiBkZWZpbmUgbW9iaWxpdHkNCj4gICBtYW5hZ2VtZW50IHByb2NlZHVy
ZXMgdGhhdCBzdXBwb3J0IHVuaWNhc3QgY29tbXVuaWNhdGlvbiBhdCByZWR1Y2VkDQo+ICAgaGFu
ZG92ZXIgbGF0ZW5jeS4gIEZhc3QgaGFuZG92ZXIgYmFzZSBvcGVyYXRpb25zIGRvIG5vdCBhZmZl
Y3QNCj4gICBtdWx0aWNhc3QgY29tbXVuaWNhdGlvbiwgYW5kIGhlbmNlIGRvIG5vdCBhY2NlbGVy
YXRlIGhhbmRvdmVyDQo+ICAgbWFuYWdlbWVudCBmb3IgbmF0aXZlIG11bHRpY2FzdCBsaXN0ZW5l
cnMuICBNYW55IG11bHRpY2FzdA0KPiAgIGFwcGxpY2F0aW9ucyBsaWtlIElQVFYgb3IgY29uZmVy
ZW5jaW5nLCB0aG91Z2gsIGFyZSBjb21wcmlzZWQgb2YNCj4gICBkZWxheS1zZW5zaXRpdmUgcmVh
bC10aW1lIHRyYWZmaWMgYW5kIHdpbGwgYmVuZWZpdCBmcm9tIGZhc3QgaGFuZG92ZXINCj4gICBl
eGVjdXRpb24uICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBleHRlbnNpb24gb2YgdGhlIE1vYmls
ZSBJUHY2IEZhc3QNCj4gICBIYW5kb3ZlcnMgKEZNSVB2NikgYW5kIHRoZSBGYXN0IEhhbmRvdmVy
cyBmb3IgUHJveHkgTW9iaWxlIElQdjYNCj4gICAoUEZNSVB2NikgcHJvdG9jb2xzIHRvIGluY2x1
ZGUgbXVsdGljYXN0IHRyYWZmaWMgbWFuYWdlbWVudCBpbiBmYXN0DQo+ICAgaGFuZG92ZXIgb3Bl
cmF0aW9ucy4gIFRoaXMgbXVsdGljYXN0IHN1cHBvcnQgaXMgcHJvdmlkZWQgZmlyc3QgYXQgdGhl
DQo+ICAgY29udHJvbCBwbGFuZSBieSBhIG1hbmFnZW1lbnQgb2YgcmFwaWQgY29udGV4dCB0cmFu
c2ZlciBiZXR3ZWVuDQo+ICAgYWNjZXNzIHJvdXRlcnMsIHNlY29uZCBhdCB0aGUgZGF0YSBwbGFu
ZSBieSBhbiBvcHRpb25hbCBmYXN0IHRyYWZmaWMNCj4gICBmb3J3YXJkaW5nIHRoYXQgbWF5IGlu
Y2x1ZGUgYnVmZmVyaW5nLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl
IGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtbXVsdGltb2ItZm1pcHY2LXBmbWlwdjYtbXVsdGljYXN0DQo+DQo+VGhlcmUncyBh
bHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1tdWx0aW1vYi1mbWlwdjYtcGZtaXB2Ni1tdWx0aWNhc3QtMDEN
Cj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+
aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tdWx0aW1vYi1mbWlw
djYtcGZtaXB2Ni1tdWx0aWNhc3QtMDENCj4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g
YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPm11bHRpbW9iIG1haWxpbmcgbGlzdA0KPm11bHRpbW9iQGlldGYub3JnDQo+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYg0KDQo9ID0gPSA9ID0g
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqhoaGhoaGhoaGhoaGhoaGh1sIN
CsDxo6ENCiANCgkJCQkgDQpTaHVhaSBHYW8NCkFzc29jaWF0ZSBQcm9mZXNzb3INCk5hdGlvbmFs
IEVuZ2luZWVyaW5nIExhYiBmb3IgTmV4dCBHZW5lcmF0aW9uIEludGVybmV0IEludGVyY29ubmVj
dGlvbiBEZXZpY2VzDQpCZWlqaW5nIEppYW90b25nIFVuaXZlcnNpdHkNCkJlaWppbmcsIENoaW5h
LCAxMDAwNDQNCmdhb3hsaEBnbWFpbC5jb20NCjIwMTMtMDktMjUNCg0K


From schmidt@informatik.haw-hamburg.de  Sun Sep 29 16:06:28 2013
Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EF11E8143 for <multimob@ietfa.amsl.com>; Sun, 29 Sep 2013 16:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.592
X-Spam-Level: 
X-Spam-Status: No, score=-104.592 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxxju4gCOQN6 for <multimob@ietfa.amsl.com>; Sun, 29 Sep 2013 16:06:22 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id A692221F9D1C for <multimob@ietf.org>; Sun, 29 Sep 2013 16:06:21 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from g231104206.adsl.alicedsl.de ([92.231.104.206] helo=[192.168.178.33]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1VQQ4B-0007SX-My; Mon, 30 Sep 2013 01:06:20 +0200
Message-ID: <5248B269.2020507@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 01:06:17 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dirk.von-Hugo@telekom.de
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com>
In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: multimob@ietf.org
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 29 Sep 2013 23:06:28 -0000

Hi Dirk,

thanks again for your detailed comments. Please see replies inline.

On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote:

> As promised at IETF-87 I did a review of the source multicast mobility draft and think the document is in quite good shape.
>
> Being not the distinct expert in details of multicast protocols I am not sure to have understood everything in detail, so please correct me and forgive misunderstandings ...
>
> The three scenarios described are
> 1) the base solution with MLD proxies at MAGs (and optionally also at LMAs) (sect.3)
> 2) direct routing with or without MLD proxies at MAGs and with native Multicast support at MAG level or above via different established Multicast protocols (sect.4)
> 3) Routing optimization for direct routing with MLD proxies at MAGs (sect. 5)
> Right?

Yes, this is it.

> IMHO from the abstract this is not easily to see.
>

We have adjusted the abstract. In any case, it explicitly addresses 
(enumerates) the three scenarios mentioned abobe.

> I have some comments and suggestions to increase readability, in addition to some nits found, given in the following:
>
> Fig. 1, fig.3 to be placed on single pages to simplify readability.

This is a fine-tuning that shall be done with the RFC-editor. In the 
process of RFC-editing, the boilerplate will change and so will the 
positioning of floating text and figures.

> Consistently use re-attach and re-distribute _or_ reattach and redistribute, respectively, throughout document.
> Is there any implicit meaning of Proxy with respect to proxy? Also MLD Proxy and MLD proxy are both used throughout the document ...

Thanks ... this should be corrected, now.

>
> p.1
>     optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>     function for MLD Proxies defined.
> =>   optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>     function for MLD Proxies are defined.
>

Thanks, corrected.

> p.3
> Such approaches (partially) follow the
>     business model of providing multicast data services in parallel to
>     PMIPv6 unicast routing.
> ==> shouldn't one or more references be added here such as to [I-D.ietf-multimob-pmipv6-ropt], draft-ietf-multimob-fmipv6-pfmipv6-multicast, draft-ietf-multimob-handover-optimization  ...?
>

Yes, good point: It's added now.

> needs of receptive use cases
> => needs of applications for mobile multicast reception of content from few and mainly fixed content sources
>
> p.5
>
> A multicast unaware MAG would simply discard these packets in
>     the absence of a multicast routing information base (MRIB).
> ==> shouldn't one add more information about MRIBs introduced here for non-multicast aware readers such as: Such tables similar to MFIBs mentioned in RFC 6224 ensure that the router is able to correctly route/forward packets with multicast addresses as destinations .

O.K. - we've added a brief explanatory insert ... even though I believe 
that a mulitcast unaware reader will not succeed in taking profit from 
this document ;)

>
> In case of a handover, the MN (unaware of IP mobility)
> => In case of a handover, the MN (being unaware of IP mobility)
>

O.K., fixed.

> as soon as network connectivity is
>     reconfigured
> => as soon as network connectivity is
>     re-established
>
O.K., fixed.


> p.7
> multicast data is => multicast data are
>

Mhmm, my dictionary says "data is" ... "data" is a singular term that 
subsumes (uncountable) plural ...


> p.8
> In addition, an LMA serving as PIM Designated Router is connected
> =>  In addition, an LMA serving as PIM Designated Router (DR) is connected
>

O.K., fixed.

> incoming interface validation is only performed by RPF
>     checks
> => incoming interface validation is only performed by RPF (Reverse Path Forwarding)
>     checks
>

O.K., fixed.

> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>     respect to source location and does not require special
>     configurations or state management for sources.
> ==> Wouldn't it make sense to add a reason for this, e.g.
> ... since BIDIR PIM automatically builds trees to allow multicast data to be natively forwarded from sources to receivers without requiring source-specific information ...
> On the other hand a reference to sect. 4.4 might be perhaps misleading here since this section is not on direct multicast routing?!

This is about the nature of BIDIR-PIM. The reason for this property is 
the bidirectional use of a static (= source-independent) spanning tree 
... but explaining the ideas behind BIDIR-PIM may really go too far here 
... if readers haven't heard about BIDIR-PIM, the should look up the 
reference.

>
> an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as for
>     IPv6.
> => an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as is done for an MLD proxy for
>     IPv6.
>
> p.9
> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
> => For a dual-stack IPv4/IPv6 access network, the MAG proxy instances (i.e. IPMP/MLD proxy functions)
>
> In the following, efficiency-related issues remain.
> => In the following, efficiency-related issues which remain unsolved within the above defined base PMIPv6 multicast source support are described.
>

Here, we would prefer the shorter forms.

> p.11
> upstream will lead traffic into the multicast infrastructure
> =>  upstream will transfer traffic into the multicast infrastructure
>

o.k.

> p.12
> configurations have completed => configurations have been completed
>

o.k.

> traffic from the mobile source continues to be transmitted via the
>     same next-hop router using the same source address
> =>  traffic from the mobile source continues to be transmitted via the
>     same next-hop multicast router using the same source address
>

o.k.

> by aggregating proxies on a lower layer.
> ==> please clarify: what layer exactly is proposed? PIM DR at MAGs?
>

A lower layer is meant in the (OSI) layered model: Layer 2 or below.

>    in the access network for providing multicast services in parallel to
>     unicast routes.
> =>  in the access network for providing multicast services in parallel to
>     unicast routes ( see Fig. 3(b)).
>

O.K.

> p.13
>    The following information is needed for all phases of PIM.
> =>  The following information is needed for all three phases of PIM as outlined in [RFC4601].
>

O.K.

> P.14
> configured to not initiated (S,G) shortest path tress for mobile
> => configured to not initiated (S,G) shortest path trees for mobile
>

Thanks, o.k.

> mobile source.  This tree can be of lesser routing efficiency than
> => mobile source.  This tree can be of lower routing efficiency than
>

o.k.

> In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface immediately responds with a register stop.
> => In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface and thus (?) immediately respond with a register stop.
>

O.k., fixed.

> As the
>     RP had joined the shortest path tree to receive from the source via
>     the LMA,
> =>As the
>     RP has joined the shortest path tree to receive data from the source via
>     the LMA,
>

Meanwhile replaced.

> the LMA, it will see an RPF change when data arrives at a new
> => the LMA, it will see an RPF change when data arrive at a new
>

s.o.

> In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiated a source-specific Join for
> => In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiate a source-specific Join for
>

Thanks, fixed.

> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
>     mobile source
> =>
> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the serving MAG to the
>     mobile source (described from leave to root?)
>

o.k.

> This tree is of higher routing efficiency than
> established in the previous phase two
> =>
> This tree is of higher routing efficiency than
>   that established in the previous phase two
>

thanks, o.k.

> p.15
> via the source register tunnel.  Tree mainenance eventually triggered
> => via the source register tunnel.  Tree maintenance eventually triggered
>

Thanks, o.k.

> p.16
>    BIDIR-PIM MAY be deployed in the access network =>  BIDIR-PIM [RFC5015] MAY be deployed in the access network
>

Ref has been provided before.

> remain uneffected by node mobility => remain unaffected by node mobility
>

Thanks, fixed.

> spanning group tree => spanning tree for the multicast group /multicast spanning tree
>

o.k., thanks.

> p.17
> document.  To overcome these deficits, an optimized approach to
> ==> AFAIU it does mainly cover deficits mentioned in sect. 4, if also those inefficiencies described in 3.2.5 are tackled this should be explained

Actually, the main concerns that are addressed in this peering approach 
are from section 3.2.5, namely the parallel proxy instances, which route 
via an LMA.

We've added text to make this clearer.

>
> Following different techniques, these requirements are met in the
>     following solutions.
> ==> to me it seems to be one solution only (peering between MLD proxies) adapted to several multicast protocol implementations for ASM and SSM
>

Yes, the original text covered also the multiple-upstream proxy, which 
moved to the appendix now. The text has been corrected now.

> but provide superior performance in the presence of source-
>     specific signaling (IGMPv3/MLDv2).
> ==> Wouldn't a reference to RFC 4604 ("Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast") make sense or be helpful here?

O.k., we've added this.
>
> p.18
> This filter base Must be updated, if and => This filter base MUST be updated, if and
>

thanks, fixed.

> In
>     addition, local multicast packets are transferred
> =>
> In
>     addition, multicast packets from locally attached sources are transferred
> or:
>   In addition, such locally arriving multicast packets are transferred
>

O.k., reworded.

> p.19
> 6.  IANA Considerations
>     TODO.
> ==> to me there seem to be no IANA activities arising from the proposed protocol modifications, right?
>

Yes.

> p.20
> the PMIPv6 domain will not actively terminate group membership prior
>     to departure.
> =>
> the PMIPv6 domain will in general not actively terminate group membership prior
>     to departure.
>

o.k.

> p.22
> but alternate configuriations => but alternate configurations
>
> a state decomposition , if needed => a state decomposition, if needed...
>

Thanks, fixed.

> Hope this helps.

Yes, thanks a lot for this detailed review!

Best wishes,

Thomas


> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Samstag, 13. Juli 2013 00:50
> To: i-d-announce@ietf.org
> Cc: multimob@ietf.org
> Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Multicast Mobility Working Group of the IETF.
>
> 	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
> 	Author(s)       : Thomas C. Schmidt
>                            Shuai Gao
>                            Hong-Ke Zhang
>                            Matthias Waehlisch
> 	Filename        : draft-ietf-multimob-pmipv6-source-04.txt
> 	Pages           : 24
> 	Date            : 2013-07-12
>
> Abstract:
>     Multicast communication can be enabled in Proxy Mobile IPv6 domains
>     via the Local Mobility Anchors by deploying MLD Proxy functions at
>     Mobile Access Gateways, via a direct traffic distribution within an
>     ISP's access network, or by selective route optimization schemes.
>     This document describes the support of mobile multicast senders in
>     Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>     optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>     function for MLD Proxies defined.  Mobile sources always remain
>     agnostic of multicast mobility operations.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

From gnocuil@gmail.com  Sun Sep 29 23:47:50 2013
Return-Path: <gnocuil@gmail.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32F011E80DF for <multimob@ietfa.amsl.com>; Sun, 29 Sep 2013 23:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TguLO2BgE9hT for <multimob@ietfa.amsl.com>; Sun, 29 Sep 2013 23:47:48 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF7211E80DE for <multimob@ietf.org>; Sun, 29 Sep 2013 23:47:43 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hj3so3202133wib.2 for <multimob@ietf.org>; Sun, 29 Sep 2013 23:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Jnsst93/GmTJSHsgiLYBXcBrd0MegBlff+s4JtMJJF8=; b=PHt1I+QoudGw6JA76JnUcBqcywK+NV+C5ioH5vJwh/6FNkkRXd/JglONvmwjjcPccu MevR+1d+KSmbiDIsoe4qFBnx+u2cM2/qtejz7Kq5Nf5iozQOuQym52ps/krZFiEnlmVi ROeUg/xLctDt5TqK/OafImIQCFi9XMjIrV9/bo1sqBuMtGLUAalFTnpdyQhDciAIz2bT pfWAMrg0a/7g/M/J0vx6hHjhXdNP5oT4m5fYkV5ao5YFlgwqsnsO6CIL5ijY9MrBIq29 A1SlfpFhZl08fRSnmBDjvW3f/bdvTyFO+swlhh7Gc6VtdmPSIFT9kHBSZjr8hMXPBVE4 spYQ==
X-Received: by 10.180.109.132 with SMTP id hs4mr12411485wib.46.1380523662597;  Sun, 29 Sep 2013 23:47:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.122.226 with HTTP; Sun, 29 Sep 2013 23:47:22 -0700 (PDT)
In-Reply-To: <5248B269.2020507@informatik.haw-hamburg.de>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de>
From: Cong Liu <gnocuil@gmail.com>
Date: Mon, 30 Sep 2013 14:47:22 +0800
Message-ID: <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com>
To: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
Content-Type: multipart/alternative; boundary=e89a8f2355c78367a304e7943645
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 06:47:50 -0000

--e89a8f2355c78367a304e7943645
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear all,

Regarding this draft, I have the following comments for consideration.

P14: "This tree can be of lesser routing efficiency than the PIM source
register tunnel established in phase one, but provides the advantage of
immediate data delivery to receivers that share a MAG with S."
- This sentence implicitly indicates that local receivers sharing a MAG
with S cannot receive immediate multicast traffic from the S in phase one.
In my opinion, even in phase one, the MAG acting as the DR has the related
multicast state so that immediate data delivery is possible. If so, the
sentence here is not appropriate.

Some nits:
1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy or
MLD Proxy
2) P14: This tree can be of lesser routing efficiency
- This tree can be of less routing efficiency

Thanks!

Best Regards,
Cong Liu


2013/9/30 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de>

> Hi Dirk,
>
> thanks again for your detailed comments. Please see replies inline.
>
> On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote:
>
>  As promised at IETF-87 I did a review of the source multicast mobility
>> draft and think the document is in quite good shape.
>>
>> Being not the distinct expert in details of multicast protocols I am not
>> sure to have understood everything in detail, so please correct me and
>> forgive misunderstandings ...
>>
>> The three scenarios described are
>> 1) the base solution with MLD proxies at MAGs (and optionally also at
>> LMAs) (sect.3)
>> 2) direct routing with or without MLD proxies at MAGs and with native
>> Multicast support at MAG level or above via different established Multic=
ast
>> protocols (sect.4)
>> 3) Routing optimization for direct routing with MLD proxies at MAGs
>> (sect. 5)
>> Right?
>>
>
> Yes, this is it.
>
>  IMHO from the abstract this is not easily to see.
>>
>>
> We have adjusted the abstract. In any case, it explicitly addresses
> (enumerates) the three scenarios mentioned abobe.
>
>  I have some comments and suggestions to increase readability, in additio=
n
>> to some nits found, given in the following:
>>
>> Fig. 1, fig.3 to be placed on single pages to simplify readability.
>>
>
> This is a fine-tuning that shall be done with the RFC-editor. In the
> process of RFC-editing, the boilerplate will change and so will the
> positioning of floating text and figures.
>
>  Consistently use re-attach and re-distribute _or_ reattach and
>> redistribute, respectively, throughout document.
>> Is there any implicit meaning of Proxy with respect to proxy? Also MLD
>> Proxy and MLD proxy are both used throughout the document ...
>>
>
> Thanks ... this should be corrected, now.
>
>
>> p.1
>>     optimizations for synchronizing PMIPv6 with PIM, as well as a peerin=
g
>>     function for MLD Proxies defined.
>> =3D>   optimizations for synchronizing PMIPv6 with PIM, as well as a pee=
ring
>>     function for MLD Proxies are defined.
>>
>>
> Thanks, corrected.
>
>  p.3
>> Such approaches (partially) follow the
>>     business model of providing multicast data services in parallel to
>>     PMIPv6 unicast routing.
>> =3D=3D> shouldn't one or more references be added here such as to
>> [I-D.ietf-multimob-pmipv6-**ropt], draft-ietf-multimob-fmipv6-**pfmipv6-=
multicast,
>> draft-ietf-multimob-handover-**optimization  ...?
>>
>>
> Yes, good point: It's added now.
>
>  needs of receptive use cases
>> =3D> needs of applications for mobile multicast reception of content fro=
m
>> few and mainly fixed content sources
>>
>> p.5
>>
>> A multicast unaware MAG would simply discard these packets in
>>     the absence of a multicast routing information base (MRIB).
>> =3D=3D> shouldn't one add more information about MRIBs introduced here f=
or
>> non-multicast aware readers such as: Such tables similar to MFIBs mentio=
ned
>> in RFC 6224 ensure that the router is able to correctly route/forward
>> packets with multicast addresses as destinations .
>>
>
> O.K. - we've added a brief explanatory insert ... even though I believe
> that a mulitcast unaware reader will not succeed in taking profit from th=
is
> document ;)
>
>
>> In case of a handover, the MN (unaware of IP mobility)
>> =3D> In case of a handover, the MN (being unaware of IP mobility)
>>
>>
> O.K., fixed.
>
>  as soon as network connectivity is
>>     reconfigured
>> =3D> as soon as network connectivity is
>>     re-established
>>
>>  O.K., fixed.
>
>
>  p.7
>> multicast data is =3D> multicast data are
>>
>>
> Mhmm, my dictionary says "data is" ... "data" is a singular term that
> subsumes (uncountable) plural ...
>
>
>  p.8
>> In addition, an LMA serving as PIM Designated Router is connected
>> =3D>  In addition, an LMA serving as PIM Designated Router (DR) is conne=
cted
>>
>>
> O.K., fixed.
>
>  incoming interface validation is only performed by RPF
>>     checks
>> =3D> incoming interface validation is only performed by RPF (Reverse Pat=
h
>> Forwarding)
>>     checks
>>
>>
> O.K., fixed.
>
>  Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>>     respect to source location and does not require special
>>     configurations or state management for sources.
>> =3D=3D> Wouldn't it make sense to add a reason for this, e.g.
>> ... since BIDIR PIM automatically builds trees to allow multicast data t=
o
>> be natively forwarded from sources to receivers without requiring
>> source-specific information ...
>> On the other hand a reference to sect. 4.4 might be perhaps misleading
>> here since this section is not on direct multicast routing?!
>>
>
> This is about the nature of BIDIR-PIM. The reason for this property is th=
e
> bidirectional use of a static (=3D source-independent) spanning tree ... =
but
> explaining the ideas behind BIDIR-PIM may really go too far here ... if
> readers haven't heard about BIDIR-PIM, the should look up the reference.
>
>
>> an IGMP proxy
>>     function needs to be deployed at MAGs in exactly the same way as for
>>     IPv6.
>> =3D> an IGMP proxy
>>     function needs to be deployed at MAGs in exactly the same way as is
>> done for an MLD proxy for
>>     IPv6.
>>
>> p.9
>> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
>> =3D> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
>> (i.e. IPMP/MLD proxy functions)
>>
>> In the following, efficiency-related issues remain.
>> =3D> In the following, efficiency-related issues which remain unsolved
>> within the above defined base PMIPv6 multicast source support are descri=
bed.
>>
>>
> Here, we would prefer the shorter forms.
>
>  p.11
>> upstream will lead traffic into the multicast infrastructure
>> =3D>  upstream will transfer traffic into the multicast infrastructure
>>
>>
> o.k.
>
>  p.12
>> configurations have completed =3D> configurations have been completed
>>
>>
> o.k.
>
>  traffic from the mobile source continues to be transmitted via the
>>     same next-hop router using the same source address
>> =3D>  traffic from the mobile source continues to be transmitted via the
>>     same next-hop multicast router using the same source address
>>
>>
> o.k.
>
>  by aggregating proxies on a lower layer.
>> =3D=3D> please clarify: what layer exactly is proposed? PIM DR at MAGs?
>>
>>
> A lower layer is meant in the (OSI) layered model: Layer 2 or below.
>
>     in the access network for providing multicast services in parallel to
>>     unicast routes.
>> =3D>  in the access network for providing multicast services in parallel=
 to
>>     unicast routes ( see Fig. 3(b)).
>>
>>
> O.K.
>
>  p.13
>>    The following information is needed for all phases of PIM.
>> =3D>  The following information is needed for all three phases of PIM as
>> outlined in [RFC4601].
>>
>>
> O.K.
>
>  P.14
>> configured to not initiated (S,G) shortest path tress for mobile
>> =3D> configured to not initiated (S,G) shortest path trees for mobile
>>
>>
> Thanks, o.k.
>
>  mobile source.  This tree can be of lesser routing efficiency than
>> =3D> mobile source.  This tree can be of lower routing efficiency than
>>
>>
> o.k.
>
>  In
>>     response, the PIM RP will recognize the known source at a new
>>     (tunnel) interface immediately responds with a register stop.
>> =3D> In
>>     response, the PIM RP will recognize the known source at a new
>>     (tunnel) interface and thus (?) immediately respond with a register
>> stop.
>>
>>
> O.k., fixed.
>
>  As the
>>     RP had joined the shortest path tree to receive from the source via
>>     the LMA,
>> =3D>As the
>>     RP has joined the shortest path tree to receive data from the source
>> via
>>     the LMA,
>>
>>
> Meanwhile replaced.
>
>  the LMA, it will see an RPF change when data arrives at a new
>> =3D> the LMA, it will see an RPF change when data arrive at a new
>>
>>
> s.o.
>
>  In response to an exceeded threshold of packet transmission, DRs of
>>     receivers eventually will initiated a source-specific Join for
>> =3D> In response to an exceeded threshold of packet transmission, DRs of
>>     receivers eventually will initiate a source-specific Join for
>>
>>
> Thanks, fixed.
>
>  this (S,G) tree will range from
>>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
>>     mobile source
>> =3D>
>> this (S,G) tree will range from
>>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the
>> serving MAG to the
>>     mobile source (described from leave to root?)
>>
>>
> o.k.
>
>  This tree is of higher routing efficiency than
>> established in the previous phase two
>> =3D>
>> This tree is of higher routing efficiency than
>>   that established in the previous phase two
>>
>>
> thanks, o.k.
>
>  p.15
>> via the source register tunnel.  Tree mainenance eventually triggered
>> =3D> via the source register tunnel.  Tree maintenance eventually trigge=
red
>>
>>
> Thanks, o.k.
>
>  p.16
>>    BIDIR-PIM MAY be deployed in the access network =3D>  BIDIR-PIM
>> [RFC5015] MAY be deployed in the access network
>>
>>
> Ref has been provided before.
>
>  remain uneffected by node mobility =3D> remain unaffected by node mobili=
ty
>>
>>
> Thanks, fixed.
>
>  spanning group tree =3D> spanning tree for the multicast group /multicas=
t
>> spanning tree
>>
>>
> o.k., thanks.
>
>  p.17
>> document.  To overcome these deficits, an optimized approach to
>> =3D=3D> AFAIU it does mainly cover deficits mentioned in sect. 4, if als=
o
>> those inefficiencies described in 3.2.5 are tackled this should be expla=
ined
>>
>
> Actually, the main concerns that are addressed in this peering approach
> are from section 3.2.5, namely the parallel proxy instances, which route
> via an LMA.
>
> We've added text to make this clearer.
>
>
>> Following different techniques, these requirements are met in the
>>     following solutions.
>> =3D=3D> to me it seems to be one solution only (peering between MLD prox=
ies)
>> adapted to several multicast protocol implementations for ASM and SSM
>>
>>
> Yes, the original text covered also the multiple-upstream proxy, which
> moved to the appendix now. The text has been corrected now.
>
>  but provide superior performance in the presence of source-
>>     specific signaling (IGMPv3/MLDv2).
>> =3D=3D> Wouldn't a reference to RFC 4604 ("Using Internet Group Manageme=
nt
>> Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol
>> Version 2 (MLDv2) for Source-Specific Multicast") make sense or be helpf=
ul
>> here?
>>
>
> O.k., we've added this.
>
>>
>> p.18
>> This filter base Must be updated, if and =3D> This filter base MUST be
>> updated, if and
>>
>>
> thanks, fixed.
>
>  In
>>     addition, local multicast packets are transferred
>> =3D>
>> In
>>     addition, multicast packets from locally attached sources are
>> transferred
>> or:
>>   In addition, such locally arriving multicast packets are transferred
>>
>>
> O.k., reworded.
>
>  p.19
>> 6.  IANA Considerations
>>     TODO.
>> =3D=3D> to me there seem to be no IANA activities arising from the propo=
sed
>> protocol modifications, right?
>>
>>
> Yes.
>
>  p.20
>> the PMIPv6 domain will not actively terminate group membership prior
>>     to departure.
>> =3D>
>> the PMIPv6 domain will in general not actively terminate group membershi=
p
>> prior
>>     to departure.
>>
>>
> o.k.
>
>  p.22
>> but alternate configuriations =3D> but alternate configurations
>>
>> a state decomposition , if needed =3D> a state decomposition, if needed.=
..
>>
>>
> Thanks, fixed.
>
>  Hope this helps.
>>
>
> Yes, thanks a lot for this detailed review!
>
> Best wishes,
>
> Thomas
>
>
>  -----Original Message-----
>> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.**org<mult=
imob-bounces@ietf.org>]
>> On Behalf Of internet-drafts@ietf.org
>> Sent: Samstag, 13. Juli 2013 00:50
>> To: i-d-announce@ietf.org
>> Cc: multimob@ietf.org
>> Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-**
>> source-04.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Multicast Mobility Working Group of
>> the IETF.
>>
>>         Title           : Mobile Multicast Sender Support in Proxy Mobil=
e
>> IPv6 (PMIPv6) Domains
>>         Author(s)       : Thomas C. Schmidt
>>                            Shuai Gao
>>                            Hong-Ke Zhang
>>                            Matthias Waehlisch
>>         Filename        : draft-ietf-multimob-pmipv6-**source-04.txt
>>         Pages           : 24
>>         Date            : 2013-07-12
>>
>> Abstract:
>>     Multicast communication can be enabled in Proxy Mobile IPv6 domains
>>     via the Local Mobility Anchors by deploying MLD Proxy functions at
>>     Mobile Access Gateways, via a direct traffic distribution within an
>>     ISP's access network, or by selective route optimization schemes.
>>     This document describes the support of mobile multicast senders in
>>     Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>>     optimizations for synchronizing PMIPv6 with PIM, as well as a peerin=
g
>>     function for MLD Proxies defined.  Mobile sources always remain
>>     agnostic of multicast mobility operations.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/**doc/draft-ietf-multimob-**pmipv6-source<h=
ttps://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/**draft-ietf-multimob-pmipv6-**source-04<http=
://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?**url2=3Ddraft-ietf-multimob-**pmipv6-source=
-04<http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-04=
>
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts=
/>
>>
>> ______________________________**_________________
>> multimob mailing list
>> multimob@ietf.org
>> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/ma=
ilman/listinfo/multimob>
>>
>>
> --
>
> Prof. Dr. Thomas C. Schmidt
> =B0 Hamburg University of Applied Sciences                   Berliner Tor=
 7 =B0
> =B0 Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germa=
ny =B0
> =B0 http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-84=
52
> =B0
> =B0 http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik=
.haw-hamburg.de/~schmidt>   Fax: +49-40-42875-8409 =B0
> ______________________________**_________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mai=
lman/listinfo/multimob>
>

--e89a8f2355c78367a304e7943645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Dear all,</div><div><br></div><div>Regarding this dra=
ft, I have the following comments for consideration.</div><div><br></div><d=
iv>P14: &quot;This tree can be of lesser routing efficiency than the PIM so=
urce register tunnel established in phase one, but provides the advantage o=
f immediate data delivery to receivers that share a MAG with S.&quot;</div>

<div>- This sentence implicitly indicates that local receivers sharing a MA=
G with S cannot receive immediate multicast traffic from the S in phase one=
. In my opinion, even in phase one, the MAG acting as the DR has the relate=
d multicast state so that immediate data delivery is possible. If so, the s=
entence here is not appropriate.</div>

<div><br></div><div>Some nits:</div><div>1) The term &quot;MLD proxy&quot; =
and &quot;MLD Proxy&quot; should be unified as MLD proxy or MLD Proxy<br></=
div><div>2) P14: This tree can be of lesser routing efficiency<br></div>

<div>- This tree can be of less routing efficiency</div><div><br></div><div=
>Thanks!</div><div><br></div><div>Best Regards,</div><div>Cong Liu<br></div=
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/9/30 Th=
omas C. Schmidt <span dir=3D"ltr">&lt;<a href=3D"mailto:schmidt@informatik.=
haw-hamburg.de" target=3D"_blank">schmidt@informatik.haw-hamburg.de</a>&gt;=
</span><br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Dirk,<br>
<br>
thanks again for your detailed comments. Please see replies inline.<br>
<br>
On 26.08.2013 18:29, <a href=3D"mailto:Dirk.von-Hugo@telekom.de" target=3D"=
_blank">Dirk.von-Hugo@telekom.de</a> wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As promised at IETF-87 I did a review of the source multicast mobility draf=
t and think the document is in quite good shape.<br>
<br>
Being not the distinct expert in details of multicast protocols I am not su=
re to have understood everything in detail, so please correct me and forgiv=
e misunderstandings ...<br>
<br>
The three scenarios described are<br>
1) the base solution with MLD proxies at MAGs (and optionally also at LMAs)=
 (sect.3)<br>
2) direct routing with or without MLD proxies at MAGs and with native Multi=
cast support at MAG level or above via different established Multicast prot=
ocols (sect.4)<br>
3) Routing optimization for direct routing with MLD proxies at MAGs (sect. =
5)<br>
Right?<br>
</blockquote>
<br>
Yes, this is it.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
IMHO from the abstract this is not easily to see.<br>
<br>
</blockquote>
<br>
We have adjusted the abstract. In any case, it explicitly addresses (enumer=
ates) the three scenarios mentioned abobe.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I have some comments and suggestions to increase readability, in addition t=
o some nits found, given in the following:<br>
<br>
Fig. 1, fig.3 to be placed on single pages to simplify readability.<br>
</blockquote>
<br>
This is a fine-tuning that shall be done with the RFC-editor. In the proces=
s of RFC-editing, the boilerplate will change and so will the positioning o=
f floating text and figures.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Consistently use re-attach and re-distribute _or_ reattach and redistribute=
, respectively, throughout document.<br>
Is there any implicit meaning of Proxy with respect to proxy? Also MLD Prox=
y and MLD proxy are both used throughout the document ...<br>
</blockquote>
<br>
Thanks ... this should be corrected, now.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
p.1<br>
=A0 =A0 optimizations for synchronizing PMIPv6 with PIM, as well as a peeri=
ng<br>
=A0 =A0 function for MLD Proxies defined.<br>
=3D&gt; =A0 optimizations for synchronizing PMIPv6 with PIM, as well as a p=
eering<br>
=A0 =A0 function for MLD Proxies are defined.<br>
<br>
</blockquote>
<br>
Thanks, corrected.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.3<br>
Such approaches (partially) follow the<br>
=A0 =A0 business model of providing multicast data services in parallel to<=
br>
=A0 =A0 PMIPv6 unicast routing.<br>
=3D=3D&gt; shouldn&#39;t one or more references be added here such as to [I=
-D.ietf-multimob-pmipv6-<u></u>ropt], draft-ietf-multimob-fmipv6-<u></u>pfm=
ipv6-multicast, draft-ietf-multimob-handover-<u></u>optimization =A0...?<br=
>


<br>
</blockquote>
<br>
Yes, good point: It&#39;s added now.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
needs of receptive use cases<br>
=3D&gt; needs of applications for mobile multicast reception of content fro=
m few and mainly fixed content sources<br>
<br>
p.5<br>
<br>
A multicast unaware MAG would simply discard these packets in<br>
=A0 =A0 the absence of a multicast routing information base (MRIB).<br>
=3D=3D&gt; shouldn&#39;t one add more information about MRIBs introduced he=
re for non-multicast aware readers such as: Such tables similar to MFIBs me=
ntioned in RFC 6224 ensure that the router is able to correctly route/forwa=
rd packets with multicast addresses as destinations .<br>


</blockquote>
<br>
O.K. - we&#39;ve added a brief explanatory insert ... even though I believe=
 that a mulitcast unaware reader will not succeed in taking profit from thi=
s document ;)<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
In case of a handover, the MN (unaware of IP mobility)<br>
=3D&gt; In case of a handover, the MN (being unaware of IP mobility)<br>
<br>
</blockquote>
<br>
O.K., fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
as soon as network connectivity is<br>
=A0 =A0 reconfigured<br>
=3D&gt; as soon as network connectivity is<br>
=A0 =A0 re-established<br>
<br>
</blockquote>
O.K., fixed.<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.7<br>
multicast data is =3D&gt; multicast data are<br>
<br>
</blockquote>
<br>
Mhmm, my dictionary says &quot;data is&quot; ... &quot;data&quot; is a sing=
ular term that subsumes (uncountable) plural ...<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.8<br>
In addition, an LMA serving as PIM Designated Router is connected<br>
=3D&gt; =A0In addition, an LMA serving as PIM Designated Router (DR) is con=
nected<br>
<br>
</blockquote>
<br>
O.K., fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
incoming interface validation is only performed by RPF<br>
=A0 =A0 checks<br>
=3D&gt; incoming interface validation is only performed by RPF (Reverse Pat=
h Forwarding)<br>
=A0 =A0 checks<br>
<br>
</blockquote>
<br>
O.K., fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with<br>
=A0 =A0 respect to source location and does not require special<br>
=A0 =A0 configurations or state management for sources.<br>
=3D=3D&gt; Wouldn&#39;t it make sense to add a reason for this, e.g.<br>
... since BIDIR PIM automatically builds trees to allow multicast data to b=
e natively forwarded from sources to receivers without requiring source-spe=
cific information ...<br>
On the other hand a reference to sect. 4.4 might be perhaps misleading here=
 since this section is not on direct multicast routing?!<br>
</blockquote>
<br>
This is about the nature of BIDIR-PIM. The reason for this property is the =
bidirectional use of a static (=3D source-independent) spanning tree ... bu=
t explaining the ideas behind BIDIR-PIM may really go too far here ... if r=
eaders haven&#39;t heard about BIDIR-PIM, the should look up the reference.=
<br>


<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
an IGMP proxy<br>
=A0 =A0 function needs to be deployed at MAGs in exactly the same way as fo=
r<br>
=A0 =A0 IPv6.<br>
=3D&gt; an IGMP proxy<br>
=A0 =A0 function needs to be deployed at MAGs in exactly the same way as is=
 done for an MLD proxy for<br>
=A0 =A0 IPv6.<br>
<br>
p.9<br>
For a dual-stack IPv4/IPv6 access network, the MAG proxy instances<br>
=3D&gt; For a dual-stack IPv4/IPv6 access network, the MAG proxy instances =
(i.e. IPMP/MLD proxy functions)<br>
<br>
In the following, efficiency-related issues remain.<br>
=3D&gt; In the following, efficiency-related issues which remain unsolved w=
ithin the above defined base PMIPv6 multicast source support are described.=
<br>
<br>
</blockquote>
<br>
Here, we would prefer the shorter forms.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.11<br>
upstream will lead traffic into the multicast infrastructure<br>
=3D&gt; =A0upstream will transfer traffic into the multicast infrastructure=
<br>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.12<br>
configurations have completed =3D&gt; configurations have been completed<br=
>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
traffic from the mobile source continues to be transmitted via the<br>
=A0 =A0 same next-hop router using the same source address<br>
=3D&gt; =A0traffic from the mobile source continues to be transmitted via t=
he<br>
=A0 =A0 same next-hop multicast router using the same source address<br>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
by aggregating proxies on a lower layer.<br>
=3D=3D&gt; please clarify: what layer exactly is proposed? PIM DR at MAGs?<=
br>
<br>
</blockquote>
<br>
A lower layer is meant in the (OSI) layered model: Layer 2 or below.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=A0 =A0in the access network for providing multicast services in parallel t=
o<br>
=A0 =A0 unicast routes.<br>
=3D&gt; =A0in the access network for providing multicast services in parall=
el to<br>
=A0 =A0 unicast routes ( see Fig. 3(b)).<br>
<br>
</blockquote>
<br>
O.K.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.13<br>
=A0 =A0The following information is needed for all phases of PIM.<br>
=3D&gt; =A0The following information is needed for all three phases of PIM =
as outlined in [RFC4601].<br>
<br>
</blockquote>
<br>
O.K.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
P.14<br>
configured to not initiated (S,G) shortest path tress for mobile<br>
=3D&gt; configured to not initiated (S,G) shortest path trees for mobile<br=
>
<br>
</blockquote>
<br>
Thanks, o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
mobile source. =A0This tree can be of lesser routing efficiency than<br>
=3D&gt; mobile source. =A0This tree can be of lower routing efficiency than=
<br>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In<br>
=A0 =A0 response, the PIM RP will recognize the known source at a new<br>
=A0 =A0 (tunnel) interface immediately responds with a register stop.<br>
=3D&gt; In<br>
=A0 =A0 response, the PIM RP will recognize the known source at a new<br>
=A0 =A0 (tunnel) interface and thus (?) immediately respond with a register=
 stop.<br>
<br>
</blockquote>
<br>
O.k., fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As the<br>
=A0 =A0 RP had joined the shortest path tree to receive from the source via=
<br>
=A0 =A0 the LMA,<br>
=3D&gt;As the<br>
=A0 =A0 RP has joined the shortest path tree to receive data from the sourc=
e via<br>
=A0 =A0 the LMA,<br>
<br>
</blockquote>
<br>
Meanwhile replaced.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
the LMA, it will see an RPF change when data arrives at a new<br>
=3D&gt; the LMA, it will see an RPF change when data arrive at a new<br>
<br>
</blockquote>
<br>
s.o.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In response to an exceeded threshold of packet transmission, DRs of<br>
=A0 =A0 receivers eventually will initiated a source-specific Join for<br>
=3D&gt; In response to an exceeded threshold of packet transmission, DRs of=
<br>
=A0 =A0 receivers eventually will initiate a source-specific Join for<br>
<br>
</blockquote>
<br>
Thanks, fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
this (S,G) tree will range from<br>
=A0 =A0 the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the<br=
>
=A0 =A0 mobile source<br>
=3D&gt;<br>
this (S,G) tree will range from<br>
=A0 =A0 the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the =
serving MAG to the<br>
=A0 =A0 mobile source (described from leave to root?)<br>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This tree is of higher routing efficiency than<br>
established in the previous phase two<br>
=3D&gt;<br>
This tree is of higher routing efficiency than<br>
=A0 that established in the previous phase two<br>
<br>
</blockquote>
<br>
thanks, o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.15<br>
via the source register tunnel. =A0Tree mainenance eventually triggered<br>
=3D&gt; via the source register tunnel. =A0Tree maintenance eventually trig=
gered<br>
<br>
</blockquote>
<br>
Thanks, o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.16<br>
=A0 =A0BIDIR-PIM MAY be deployed in the access network =3D&gt; =A0BIDIR-PIM=
 [RFC5015] MAY be deployed in the access network<br>
<br>
</blockquote>
<br>
Ref has been provided before.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
remain uneffected by node mobility =3D&gt; remain unaffected by node mobili=
ty<br>
<br>
</blockquote>
<br>
Thanks, fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
spanning group tree =3D&gt; spanning tree for the multicast group /multicas=
t spanning tree<br>
<br>
</blockquote>
<br>
o.k., thanks.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.17<br>
document. =A0To overcome these deficits, an optimized approach to<br>
=3D=3D&gt; AFAIU it does mainly cover deficits mentioned in sect. 4, if als=
o those inefficiencies described in 3.2.5 are tackled this should be explai=
ned<br>
</blockquote>
<br>
Actually, the main concerns that are addressed in this peering approach are=
 from section 3.2.5, namely the parallel proxy instances, which route via a=
n LMA.<br>
<br>
We&#39;ve added text to make this clearer.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Following different techniques, these requirements are met in the<br>
=A0 =A0 following solutions.<br>
=3D=3D&gt; to me it seems to be one solution only (peering between MLD prox=
ies) adapted to several multicast protocol implementations for ASM and SSM<=
br>
<br>
</blockquote>
<br>
Yes, the original text covered also the multiple-upstream proxy, which move=
d to the appendix now. The text has been corrected now.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
but provide superior performance in the presence of source-<br>
=A0 =A0 specific signaling (IGMPv3/MLDv2).<br>
=3D=3D&gt; Wouldn&#39;t a reference to RFC 4604 (&quot;Using Internet Group=
 Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Pr=
otocol Version 2 (MLDv2) for Source-Specific Multicast&quot;) make sense or=
 be helpful here?<br>


</blockquote>
<br>
O.k., we&#39;ve added this.<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
p.18<br>
This filter base Must be updated, if and =3D&gt; This filter base MUST be u=
pdated, if and<br>
<br>
</blockquote>
<br>
thanks, fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In<br>
=A0 =A0 addition, local multicast packets are transferred<br>
=3D&gt;<br>
In<br>
=A0 =A0 addition, multicast packets from locally attached sources are trans=
ferred<br>
or:<br>
=A0 In addition, such locally arriving multicast packets are transferred<br=
>
<br>
</blockquote>
<br>
O.k., reworded.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.19<br>
6. =A0IANA Considerations<br>
=A0 =A0 TODO.<br>
=3D=3D&gt; to me there seem to be no IANA activities arising from the propo=
sed protocol modifications, right?<br>
<br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.20<br>
the PMIPv6 domain will not actively terminate group membership prior<br>
=A0 =A0 to departure.<br>
=3D&gt;<br>
the PMIPv6 domain will in general not actively terminate group membership p=
rior<br>
=A0 =A0 to departure.<br>
<br>
</blockquote>
<br>
o.k.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
p.22<br>
but alternate configuriations =3D&gt; but alternate configurations<br>
<br>
a state decomposition , if needed =3D&gt; a state decomposition, if needed.=
..<br>
<br>
</blockquote>
<br>
Thanks, fixed.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hope this helps.<br>
</blockquote>
<br>
Yes, thanks a lot for this detailed review!<br>
<br>
Best wishes,<br>
<br>
Thomas<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: <a href=3D"mailto:multimob-bounces@ietf.org" target=3D"_blank">multim=
ob-bounces@ietf.org</a> [mailto:<a href=3D"mailto:multimob-bounces@ietf.org=
" target=3D"_blank">multimob-bounces@ietf.<u></u>org</a>] On Behalf Of <a h=
ref=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-drafts@i=
etf.org</a><br>


Sent: Samstag, 13. Juli 2013 00:50<br>
To: <a href=3D"mailto:i-d-announce@ietf.org" target=3D"_blank">i-d-announce=
@ietf.org</a><br>
Cc: <a href=3D"mailto:multimob@ietf.org" target=3D"_blank">multimob@ietf.or=
g</a><br>
Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-<u></u>source-04=
.txt<br>
<br>
<br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=A0 This draft is a work item of the Multicast Mobility Working Group of th=
e IETF.<br>
<br>
=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Mobile Multicast Sender Support=
 in Proxy Mobile IPv6 (PMIPv6) Domains<br>
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Thomas C. Schmidt<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Shuai Gao<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hong-Ke Zhang<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Matthias Waehlisch<b=
r>
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-multimob-pmipv6-<u></u=
>source-04.txt<br>
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 24<br>
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-12<br>
<br>
Abstract:<br>
=A0 =A0 Multicast communication can be enabled in Proxy Mobile IPv6 domains=
<br>
=A0 =A0 via the Local Mobility Anchors by deploying MLD Proxy functions at<=
br>
=A0 =A0 Mobile Access Gateways, via a direct traffic distribution within an=
<br>
=A0 =A0 ISP&#39;s access network, or by selective route optimization scheme=
s.<br>
=A0 =A0 This document describes the support of mobile multicast senders in<=
br>
=A0 =A0 Proxy Mobile IPv6 domains for all three scenarios. =A0Protocol<br>
=A0 =A0 optimizations for synchronizing PMIPv6 with PIM, as well as a peeri=
ng<br>
=A0 =A0 function for MLD Proxies defined. =A0Mobile sources always remain<b=
r>
=A0 =A0 agnostic of multicast mobility operations.<br>
<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-sour=
ce" target=3D"_blank">https://datatracker.ietf.org/<u></u>doc/draft-ietf-mu=
ltimob-<u></u>pmipv6-source</a><br>
<br>
There&#39;s also a htmlized version available at:<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04"=
 target=3D"_blank">http://tools.ietf.org/html/<u></u>draft-ietf-multimob-pm=
ipv6-<u></u>source-04</a><br>
<br>
A diff from the previous version is available at:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-so=
urce-04" target=3D"_blank">http://www.ietf.org/rfcdiff?<u></u>url2=3Ddraft-=
ietf-multimob-<u></u>pmipv6-source-04</a><br>
<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp=
.ietf.org/internet-<u></u>drafts/</a><br>
<br>
______________________________<u></u>_________________<br>
multimob mailing list<br>
<a href=3D"mailto:multimob@ietf.org" target=3D"_blank">multimob@ietf.org</a=
><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/multimob" target=3D"_blank=
">https://www.ietf.org/mailman/<u></u>listinfo/multimob</a><br>
<br><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote><span class=3D"HOEnZb"><font color=3D"#888888">
<br>
-- <br>
<br>
Prof. Dr. Thomas C. Schmidt<br>
=B0 Hamburg University of Applied Sciences =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 Berliner Tor 7 =B0<br>
=B0 Dept. Informatik, Internet Technologies Group =A0 =A020099 Hamburg, Ger=
many =B0<br>
=B0 <a href=3D"http://www.haw-hamburg.de/inet" target=3D"_blank">http://www=
.haw-hamburg.de/inet</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fon: +49-40-42=
875-8452 =B0<br>
=B0 <a href=3D"http://www.informatik.haw-hamburg.de/~schmidt" target=3D"_bl=
ank">http://www.informatik.haw-<u></u>hamburg.de/~schmidt</a> =A0 =A0Fax: +=
49-40-42875-8409 =B0<br>
______________________________<u></u>_________________<br>
multimob mailing list<br>
<a href=3D"mailto:multimob@ietf.org" target=3D"_blank">multimob@ietf.org</a=
><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/multimob" target=3D"_blank=
">https://www.ietf.org/mailman/<u></u>listinfo/multimob</a><br>
</font></span></blockquote></div><br></div></div>

--e89a8f2355c78367a304e7943645--

From schmidt@informatik.haw-hamburg.de  Mon Sep 30 05:08:32 2013
Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419F721F9A78 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 05:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.15
X-Spam-Level: 
X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZRitvaOmhsZ for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 05:08:10 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB9321F9C47 for <multimob@ietf.org>; Mon, 30 Sep 2013 05:08:08 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from g231107117.adsl.alicedsl.de ([92.231.107.117] helo=[192.168.178.33]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1VQcGk-000D6n-7W; Mon, 30 Sep 2013 14:08:06 +0200
Message-ID: <524969A3.4010907@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 14:08:03 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Cong Liu <gnocuil@gmail.com>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com>
In-Reply-To: <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: multimob@ietf.org
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 12:08:32 -0000

Dear Cong Liu,

thanks for your feedback - please see inline.

On 30.09.2013 08:47, Cong Liu wrote:

> Regarding this draft, I have the following comments for consideration.
>
> P14: "This tree can be of lesser routing efficiency than the PIM source
> register tunnel established in phase one, but provides the advantage of
> immediate data delivery to receivers that share a MAG with S."
> - This sentence implicitly indicates that local receivers sharing a MAG
> with S cannot receive immediate multicast traffic from the S in phase
> one. In my opinion, even in phase one, the MAG acting as the DR has the
> related multicast state so that immediate data delivery is possible. If
> so, the sentence here is not appropriate.
>

This sentence actually refers to the building of an (S,G)-Tree at the 
end of PIM phase II. This tree follows reverse unicast routes and thus 
traverses the LMA-MAG tunnel - this is why it may be of lower efficiency 
than the forward (register) tunnel in phase I.

What you are referring to is the question of source-local traffic 
distribution in PIM phase I. According to the way I understand  PIM-SM, 
it does not distribute source-specific traffic locally in Phase I. This 
is because a local source S generates an (S,G)-State at the sender's 
local router (DR), but a receiver in ASM requires an (*,G) service.

If (S,G) traffic were distributed locally, then the required (*,G)-Join 
to the RP would cause duplicate (S,G) traffic arriving at the 
source-local receiver.

Looking at the spec in Section 3.1 of RFC4601:

   "At the end of phase one, multicast traffic is flowing encapsulated to
    the RP, and then natively over the RP tree to the multicast receivers."


> Some nits:
> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy
> or MLD Proxy
> 2) P14: This tree can be of lesser routing efficiency
> - This tree can be of less routing efficiency
>

Thanks, it's fixed.

Best regards,

Thomas

> Thanks!
>
> Best Regards,
> Cong Liu
>
>
> 2013/9/30 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
> <mailto:schmidt@informatik.haw-hamburg.de>>
>
>     Hi Dirk,
>
>     thanks again for your detailed comments. Please see replies inline.
>
>     On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de
>     <mailto:Dirk.von-Hugo@telekom.de> wrote:
>
>         As promised at IETF-87 I did a review of the source multicast
>         mobility draft and think the document is in quite good shape.
>
>         Being not the distinct expert in details of multicast protocols
>         I am not sure to have understood everything in detail, so please
>         correct me and forgive misunderstandings ...
>
>         The three scenarios described are
>         1) the base solution with MLD proxies at MAGs (and optionally
>         also at LMAs) (sect.3)
>         2) direct routing with or without MLD proxies at MAGs and with
>         native Multicast support at MAG level or above via different
>         established Multicast protocols (sect.4)
>         3) Routing optimization for direct routing with MLD proxies at
>         MAGs (sect. 5)
>         Right?
>
>
>     Yes, this is it.
>
>         IMHO from the abstract this is not easily to see.
>
>
>     We have adjusted the abstract. In any case, it explicitly addresses
>     (enumerates) the three scenarios mentioned abobe.
>
>         I have some comments and suggestions to increase readability, in
>         addition to some nits found, given in the following:
>
>         Fig. 1, fig.3 to be placed on single pages to simplify readability.
>
>
>     This is a fine-tuning that shall be done with the RFC-editor. In the
>     process of RFC-editing, the boilerplate will change and so will the
>     positioning of floating text and figures.
>
>         Consistently use re-attach and re-distribute _or_ reattach and
>         redistribute, respectively, throughout document.
>         Is there any implicit meaning of Proxy with respect to proxy?
>         Also MLD Proxy and MLD proxy are both used throughout the
>         document ...
>
>
>     Thanks ... this should be corrected, now.
>
>
>         p.1
>              optimizations for synchronizing PMIPv6 with PIM, as well as
>         a peering
>              function for MLD Proxies defined.
>         =>   optimizations for synchronizing PMIPv6 with PIM, as well as
>         a peering
>              function for MLD Proxies are defined.
>
>
>     Thanks, corrected.
>
>         p.3
>         Such approaches (partially) follow the
>              business model of providing multicast data services in
>         parallel to
>              PMIPv6 unicast routing.
>         ==> shouldn't one or more references be added here such as to
>         [I-D.ietf-multimob-pmipv6-__ropt],
>         draft-ietf-multimob-fmipv6-__pfmipv6-multicast,
>         draft-ietf-multimob-handover-__optimization  ...?
>
>
>     Yes, good point: It's added now.
>
>         needs of receptive use cases
>         => needs of applications for mobile multicast reception of
>         content from few and mainly fixed content sources
>
>         p.5
>
>         A multicast unaware MAG would simply discard these packets in
>              the absence of a multicast routing information base (MRIB).
>         ==> shouldn't one add more information about MRIBs introduced
>         here for non-multicast aware readers such as: Such tables
>         similar to MFIBs mentioned in RFC 6224 ensure that the router is
>         able to correctly route/forward packets with multicast addresses
>         as destinations .
>
>
>     O.K. - we've added a brief explanatory insert ... even though I
>     believe that a mulitcast unaware reader will not succeed in taking
>     profit from this document ;)
>
>
>         In case of a handover, the MN (unaware of IP mobility)
>         => In case of a handover, the MN (being unaware of IP mobility)
>
>
>     O.K., fixed.
>
>         as soon as network connectivity is
>              reconfigured
>         => as soon as network connectivity is
>              re-established
>
>     O.K., fixed.
>
>
>         p.7
>         multicast data is => multicast data are
>
>
>     Mhmm, my dictionary says "data is" ... "data" is a singular term
>     that subsumes (uncountable) plural ...
>
>
>         p.8
>         In addition, an LMA serving as PIM Designated Router is connected
>         =>  In addition, an LMA serving as PIM Designated Router (DR) is
>         connected
>
>
>     O.K., fixed.
>
>         incoming interface validation is only performed by RPF
>              checks
>         => incoming interface validation is only performed by RPF
>         (Reverse Path Forwarding)
>              checks
>
>
>     O.K., fixed.
>
>         Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>              respect to source location and does not require special
>              configurations or state management for sources.
>         ==> Wouldn't it make sense to add a reason for this, e.g.
>         ... since BIDIR PIM automatically builds trees to allow
>         multicast data to be natively forwarded from sources to
>         receivers without requiring source-specific information ...
>         On the other hand a reference to sect. 4.4 might be perhaps
>         misleading here since this section is not on direct multicast
>         routing?!
>
>
>     This is about the nature of BIDIR-PIM. The reason for this property
>     is the bidirectional use of a static (= source-independent) spanning
>     tree ... but explaining the ideas behind BIDIR-PIM may really go too
>     far here ... if readers haven't heard about BIDIR-PIM, the should
>     look up the reference.
>
>
>         an IGMP proxy
>              function needs to be deployed at MAGs in exactly the same
>         way as for
>              IPv6.
>         => an IGMP proxy
>              function needs to be deployed at MAGs in exactly the same
>         way as is done for an MLD proxy for
>              IPv6.
>
>         p.9
>         For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
>         => For a dual-stack IPv4/IPv6 access network, the MAG proxy
>         instances (i.e. IPMP/MLD proxy functions)
>
>         In the following, efficiency-related issues remain.
>         => In the following, efficiency-related issues which remain
>         unsolved within the above defined base PMIPv6 multicast source
>         support are described.
>
>
>     Here, we would prefer the shorter forms.
>
>         p.11
>         upstream will lead traffic into the multicast infrastructure
>         =>  upstream will transfer traffic into the multicast infrastructure
>
>
>     o.k.
>
>         p.12
>         configurations have completed => configurations have been completed
>
>
>     o.k.
>
>         traffic from the mobile source continues to be transmitted via the
>              same next-hop router using the same source address
>         =>  traffic from the mobile source continues to be transmitted
>         via the
>              same next-hop multicast router using the same source address
>
>
>     o.k.
>
>         by aggregating proxies on a lower layer.
>         ==> please clarify: what layer exactly is proposed? PIM DR at MAGs?
>
>
>     A lower layer is meant in the (OSI) layered model: Layer 2 or below.
>
>             in the access network for providing multicast services in
>         parallel to
>              unicast routes.
>         =>  in the access network for providing multicast services in
>         parallel to
>              unicast routes ( see Fig. 3(b)).
>
>
>     O.K.
>
>         p.13
>             The following information is needed for all phases of PIM.
>         =>  The following information is needed for all three phases of
>         PIM as outlined in [RFC4601].
>
>
>     O.K.
>
>         P.14
>         configured to not initiated (S,G) shortest path tress for mobile
>         => configured to not initiated (S,G) shortest path trees for mobile
>
>
>     Thanks, o.k.
>
>         mobile source.  This tree can be of lesser routing efficiency than
>         => mobile source.  This tree can be of lower routing efficiency than
>
>
>     o.k.
>
>         In
>              response, the PIM RP will recognize the known source at a new
>              (tunnel) interface immediately responds with a register stop.
>         => In
>              response, the PIM RP will recognize the known source at a new
>              (tunnel) interface and thus (?) immediately respond with a
>         register stop.
>
>
>     O.k., fixed.
>
>         As the
>              RP had joined the shortest path tree to receive from the
>         source via
>              the LMA,
>         =>As the
>              RP has joined the shortest path tree to receive data from
>         the source via
>              the LMA,
>
>
>     Meanwhile replaced.
>
>         the LMA, it will see an RPF change when data arrives at a new
>         => the LMA, it will see an RPF change when data arrive at a new
>
>
>     s.o.
>
>         In response to an exceeded threshold of packet transmission, DRs of
>              receivers eventually will initiated a source-specific Join for
>         => In response to an exceeded threshold of packet transmission,
>         DRs of
>              receivers eventually will initiate a source-specific Join for
>
>
>     Thanks, fixed.
>
>         this (S,G) tree will range from
>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel
>         to the
>              mobile source
>         =>
>         this (S,G) tree will range from
>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel,
>         and the serving MAG to the
>              mobile source (described from leave to root?)
>
>
>     o.k.
>
>         This tree is of higher routing efficiency than
>         established in the previous phase two
>         =>
>         This tree is of higher routing efficiency than
>            that established in the previous phase two
>
>
>     thanks, o.k.
>
>         p.15
>         via the source register tunnel.  Tree mainenance eventually
>         triggered
>         => via the source register tunnel.  Tree maintenance eventually
>         triggered
>
>
>     Thanks, o.k.
>
>         p.16
>             BIDIR-PIM MAY be deployed in the access network =>
>           BIDIR-PIM [RFC5015] MAY be deployed in the access network
>
>
>     Ref has been provided before.
>
>         remain uneffected by node mobility => remain unaffected by node
>         mobility
>
>
>     Thanks, fixed.
>
>         spanning group tree => spanning tree for the multicast group
>         /multicast spanning tree
>
>
>     o.k., thanks.
>
>         p.17
>         document.  To overcome these deficits, an optimized approach to
>         ==> AFAIU it does mainly cover deficits mentioned in sect. 4, if
>         also those inefficiencies described in 3.2.5 are tackled this
>         should be explained
>
>
>     Actually, the main concerns that are addressed in this peering
>     approach are from section 3.2.5, namely the parallel proxy
>     instances, which route via an LMA.
>
>     We've added text to make this clearer.
>
>
>         Following different techniques, these requirements are met in the
>              following solutions.
>         ==> to me it seems to be one solution only (peering between MLD
>         proxies) adapted to several multicast protocol implementations
>         for ASM and SSM
>
>
>     Yes, the original text covered also the multiple-upstream proxy,
>     which moved to the appendix now. The text has been corrected now.
>
>         but provide superior performance in the presence of source-
>              specific signaling (IGMPv3/MLDv2).
>         ==> Wouldn't a reference to RFC 4604 ("Using Internet Group
>         Management Protocol Version 3 (IGMPv3) and Multicast Listener
>         Discovery Protocol Version 2 (MLDv2) for Source-Specific
>         Multicast") make sense or be helpful here?
>
>
>     O.k., we've added this.
>
>
>         p.18
>         This filter base Must be updated, if and => This filter base
>         MUST be updated, if and
>
>
>     thanks, fixed.
>
>         In
>              addition, local multicast packets are transferred
>         =>
>         In
>              addition, multicast packets from locally attached sources
>         are transferred
>         or:
>            In addition, such locally arriving multicast packets are
>         transferred
>
>
>     O.k., reworded.
>
>         p.19
>         6.  IANA Considerations
>              TODO.
>         ==> to me there seem to be no IANA activities arising from the
>         proposed protocol modifications, right?
>
>
>     Yes.
>
>         p.20
>         the PMIPv6 domain will not actively terminate group membership prior
>              to departure.
>         =>
>         the PMIPv6 domain will in general not actively terminate group
>         membership prior
>              to departure.
>
>
>     o.k.
>
>         p.22
>         but alternate configuriations => but alternate configurations
>
>         a state decomposition , if needed => a state decomposition, if
>         needed...
>
>
>     Thanks, fixed.
>
>         Hope this helps.
>
>
>     Yes, thanks a lot for this detailed review!
>
>     Best wishes,
>
>     Thomas
>
>
>         -----Original Message-----
>         From: multimob-bounces@ietf.org
>         <mailto:multimob-bounces@ietf.org>
>         [mailto:multimob-bounces@ietf.__org
>         <mailto:multimob-bounces@ietf.org>] On Behalf Of
>         internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>         Sent: Samstag, 13. Juli 2013 00:50
>         To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>         Cc: multimob@ietf.org <mailto:multimob@ietf.org>
>         Subject: [multimob] I-D Action:
>         draft-ietf-multimob-pmipv6-__source-04.txt
>
>
>         A New Internet-Draft is available from the on-line
>         Internet-Drafts directories.
>            This draft is a work item of the Multicast Mobility Working
>         Group of the IETF.
>
>                  Title           : Mobile Multicast Sender Support in
>         Proxy Mobile IPv6 (PMIPv6) Domains
>                  Author(s)       : Thomas C. Schmidt
>                                     Shuai Gao
>                                     Hong-Ke Zhang
>                                     Matthias Waehlisch
>                  Filename        :
>         draft-ietf-multimob-pmipv6-__source-04.txt
>                  Pages           : 24
>                  Date            : 2013-07-12
>
>         Abstract:
>              Multicast communication can be enabled in Proxy Mobile IPv6
>         domains
>              via the Local Mobility Anchors by deploying MLD Proxy
>         functions at
>              Mobile Access Gateways, via a direct traffic distribution
>         within an
>              ISP's access network, or by selective route optimization
>         schemes.
>              This document describes the support of mobile multicast
>         senders in
>              Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>              optimizations for synchronizing PMIPv6 with PIM, as well as
>         a peering
>              function for MLD Proxies defined.  Mobile sources always remain
>              agnostic of multicast mobility operations.
>
>
>
>         The IETF datatracker status page for this draft is:
>         https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source
>         <https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>
>         There's also a htmlized version available at:
>         http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04
>         <http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>
>         A diff from the previous version is available at:
>         http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04
>         <http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04>
>
>
>         Internet-Drafts are also available by anonymous FTP at:
>         ftp://ftp.ietf.org/internet-__drafts/
>         <ftp://ftp.ietf.org/internet-drafts/>
>
>         _________________________________________________
>         multimob mailing list
>         multimob@ietf.org <mailto:multimob@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/multimob
>         <https://www.ietf.org/mailman/listinfo/multimob>
>
>
>     --
>
>     Prof. Dr. Thomas C. Schmidt
>     ° Hamburg University of Applied Sciences                   Berliner
>     Tor 7 °
>     ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
>     Germany °
>     ° http://www.haw-hamburg.de/inet                   Fon:
>     +49-40-42875-8452 °
>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>     +49-40-42875-8409 °
>     _________________________________________________
>     multimob mailing list
>     multimob@ietf.org <mailto:multimob@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/multimob
>     <https://www.ietf.org/mailman/listinfo/multimob>
>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

From schmidt@informatik.haw-hamburg.de  Mon Sep 30 05:48:33 2013
Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8010B21F9BF7 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 05:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.212
X-Spam-Level: 
X-Spam-Status: No, score=-105.212 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lijcSaMg3jCm for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 05:48:29 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id C68EC21F9C28 for <multimob@ietf.org>; Mon, 30 Sep 2013 05:48:23 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from g231107117.adsl.alicedsl.de ([92.231.107.117] helo=[192.168.178.33]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1VQcti-000FLO-71; Mon, 30 Sep 2013 14:48:22 +0200
Message-ID: <52497313.1050508@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 14:48:19 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Rahman, Akbar" <Akbar.Rahman@InterDigital.com>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com><05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <521BBA92.9070002@informatik.haw-hamburg.de> <D60519DB022FFA48974A25955FFEC08C054A3C8A@SAM.InterDigital.com>
In-Reply-To: <D60519DB022FFA48974A25955FFEC08C054A3C8A@SAM.InterDigital.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: multimob@ietf.org
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 12:48:33 -0000

Hi Akbar,

many thanks for the review. Please see answers inline:

On 07.09.2013 02:14, Rahman, Akbar wrote:
> Hi Thomas,
>
>
> I also reviewed draft-ietf-multimob-pmipv6-source-04 and following is my feedback/
>
>
> Overall the I-D is in very nice shape and I think ready to progress to the next stage.  I only had a few comments for you to take into consideration (beyond the thorough review that Dirk already did).
>
> 1) Section 1 (Introduction)
> - Can you put a reference for the 3rd paragraph?

O.K., done.

> - The word "enfold" in 4th paragraph does not seem grammatically correct in the given sentence.  Perhaps use another word?

Right ... we put "develop".

> - I am not a big gamer, so can you please explain why a "server-centric gaming" is multicast listener only?  How can you have a game without user feedback?

For gaming we need to ask the kids ;) ... anyway, the story or 
architecture is simple and straight forward: The game server holds the 
entire state of the game and may distribute this via multicast. 
Individual feedback is unicast (client -> server).

>
>
> 2) Section 3.1 (Overview)
> - Do you think it would be worthwhile explaining the acronyms (notations) in Figure 1 (e.g. LMAA1, MN-HNP1, etc.)?  The meaning of some are not obvious.

O.K., we added that to the caption ... makes it lengthy, but easier to 
comprehend.

> - One question on "MRIB".  In this I-D it seems to be a key concept, but why was there no mention of it in RFC 6224?
>

Mmcast sources are in a different picture, here mcast traffic arrives 
first from a local source. In 6224, not Mcast data, but MLD reports 
arrive at the MAGs. Those are equally discarded in the absence of 
multicast capabilities (i.e., a proxy), but for different reasons 
(because these are link-local signaling packets).

>
> 3) Section 9 (Security Considerations)
> - Remove the "TODO"
> - I don't think the wording of the 1st paragraph is good.  I think that there definitely is a new threat introduced with the support of mobile multicast senders.  For example, wouldn't there be new modes of Denial of Service attacks?  For example, if flash mobs of mobile attackers appeared in certain localized areas (e.g. WiFi hotspot, cellular BS) and generated high amounts of multicast sender traffic.  I don't think that this type of attack was possible with RFC 6224.  Do you agree?

Yes, I agree. The Security Section was reworked anyway ... this was only 
incomplete sample text.

Best regards,

Thomas

>
>
>
> Best Regards,
>
>
> Akbar
>
>
> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt
> Sent: Monday, August 26, 2013 4:29 PM
> To: Dirk.von-Hugo@telekom.de
> Cc: multimob@ietf.org
> Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
>
> Hi Dirk,
>
> thanks for your thorough review. I'll come back to this in detail a few days.
>
> Best regards,
>
> Thomas
>
> On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote:
>> Dear all,
>> As promised at IETF-87 I did a review of the source multicast mobility draft and think the document is in quite good shape.
>>
>> Being not the distinct expert in details of multicast protocols I am not sure to have understood everything in detail, so please correct me and forgive misunderstandings ...
>>
>> The three scenarios described are
>> 1) the base solution with MLD proxies at MAGs (and optionally also at
>> LMAs) (sect.3)
>> 2) direct routing with or without MLD proxies at MAGs and with native
>> Multicast support at MAG level or above via different established
>> Multicast protocols (sect.4)
>> 3) Routing optimization for direct routing with MLD proxies at MAGs
>> (sect. 5) Right?
>> IMHO from the abstract this is not easily to see.
>>
>> I have some comments and suggestions to increase readability, in addition to some nits found, given in the following:
>>
>> Fig. 1, fig.3 to be placed on single pages to simplify readability.
>> Consistently use re-attach and re-distribute _or_ reattach and redistribute, respectively, throughout document.
>> Is there any implicit meaning of Proxy with respect to proxy? Also MLD Proxy and MLD proxy are both used throughout the document ...
>>
>> p.1
>>      optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>>      function for MLD Proxies defined.
>> =>   optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>>      function for MLD Proxies are defined.
>>
>> p.3
>> Such approaches (partially) follow the
>>      business model of providing multicast data services in parallel to
>>      PMIPv6 unicast routing.
>> ==> shouldn't one or more references be added here such as to [I-D.ietf-multimob-pmipv6-ropt], draft-ietf-multimob-fmipv6-pfmipv6-multicast, draft-ietf-multimob-handover-optimization  ...?
>>
>> needs of receptive use cases
>> => needs of applications for mobile multicast reception of content
>> from few and mainly fixed content sources
>>
>> p.5
>>
>> A multicast unaware MAG would simply discard these packets in
>>      the absence of a multicast routing information base (MRIB).
>> ==> shouldn't one add more information about MRIBs introduced here for non-multicast aware readers such as: Such tables similar to MFIBs mentioned in RFC 6224 ensure that the router is able to correctly route/forward packets with multicast addresses as destinations .
>>
>> In case of a handover, the MN (unaware of IP mobility) => In case of a
>> handover, the MN (being unaware of IP mobility)
>>
>> as soon as network connectivity is
>>      reconfigured
>> => as soon as network connectivity is
>>      re-established
>>
>> p.7
>> multicast data is => multicast data are
>>
>> p.8
>> In addition, an LMA serving as PIM Designated Router is connected =>
>> In addition, an LMA serving as PIM Designated Router (DR) is connected
>>
>> incoming interface validation is only performed by RPF
>>      checks
>> => incoming interface validation is only performed by RPF (Reverse Path Forwarding)
>>      checks
>>
>> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>>      respect to source location and does not require special
>>      configurations or state management for sources.
>> ==> Wouldn't it make sense to add a reason for this, e.g.
>> ... since BIDIR PIM automatically builds trees to allow multicast data to be natively forwarded from sources to receivers without requiring source-specific information ...
>> On the other hand a reference to sect. 4.4 might be perhaps misleading here since this section is not on direct multicast routing?!
>>
>> an IGMP proxy
>>      function needs to be deployed at MAGs in exactly the same way as for
>>      IPv6.
>> => an IGMP proxy
>>      function needs to be deployed at MAGs in exactly the same way as is done for an MLD proxy for
>>      IPv6.
>>
>> p.9
>> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances =>
>> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
>> (i.e. IPMP/MLD proxy functions)
>>
>> In the following, efficiency-related issues remain.
>> => In the following, efficiency-related issues which remain unsolved within the above defined base PMIPv6 multicast source support are described.
>>
>> p.11
>> upstream will lead traffic into the multicast infrastructure =>
>> upstream will transfer traffic into the multicast infrastructure
>>
>> p.12
>> configurations have completed => configurations have been completed
>>
>> traffic from the mobile source continues to be transmitted via the
>>      same next-hop router using the same source address =>  traffic
>> from the mobile source continues to be transmitted via the
>>      same next-hop multicast router using the same source address
>>
>> by aggregating proxies on a lower layer.
>> ==> please clarify: what layer exactly is proposed? PIM DR at MAGs?
>>
>>     in the access network for providing multicast services in parallel to
>>      unicast routes.
>> =>  in the access network for providing multicast services in parallel to
>>      unicast routes ( see Fig. 3(b)).
>>
>> p.13
>>     The following information is needed for all phases of PIM.
>> =>  The following information is needed for all three phases of PIM as outlined in [RFC4601].
>>
>> P.14
>> configured to not initiated (S,G) shortest path tress for mobile =>
>> configured to not initiated (S,G) shortest path trees for mobile
>>
>> mobile source.  This tree can be of lesser routing efficiency than =>
>> mobile source.  This tree can be of lower routing efficiency than
>>
>> In
>>      response, the PIM RP will recognize the known source at a new
>>      (tunnel) interface immediately responds with a register stop.
>> => In
>>      response, the PIM RP will recognize the known source at a new
>>      (tunnel) interface and thus (?) immediately respond with a register stop.
>>
>> As the
>>      RP had joined the shortest path tree to receive from the source via
>>      the LMA,
>> =>As the
>>      RP has joined the shortest path tree to receive data from the source via
>>      the LMA,
>>
>> the LMA, it will see an RPF change when data arrives at a new => the
>> LMA, it will see an RPF change when data arrive at a new
>>
>> In response to an exceeded threshold of packet transmission, DRs of
>>      receivers eventually will initiated a source-specific Join for =>
>> In response to an exceeded threshold of packet transmission, DRs of
>>      receivers eventually will initiate a source-specific Join for
>>
>> this (S,G) tree will range from
>>      the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
>>      mobile source
>> =>
>> this (S,G) tree will range from
>>      the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the serving MAG to the
>>      mobile source (described from leave to root?)
>>
>> This tree is of higher routing efficiency than established in the
>> previous phase two => This tree is of higher routing efficiency than
>>    that established in the previous phase two
>>
>> p.15
>> via the source register tunnel.  Tree mainenance eventually triggered
>> => via the source register tunnel.  Tree maintenance eventually
>> triggered
>>
>> p.16
>>     BIDIR-PIM MAY be deployed in the access network =>  BIDIR-PIM
>> [RFC5015] MAY be deployed in the access network
>>
>> remain uneffected by node mobility => remain unaffected by node
>> mobility
>>
>> spanning group tree => spanning tree for the multicast group
>> /multicast spanning tree
>>
>> p.17
>> document.  To overcome these deficits, an optimized approach to ==>
>> AFAIU it does mainly cover deficits mentioned in sect. 4, if also
>> those inefficiencies described in 3.2.5 are tackled this should be
>> explained
>>
>> Following different techniques, these requirements are met in the
>>      following solutions.
>> ==> to me it seems to be one solution only (peering between MLD
>> proxies) adapted to several multicast protocol implementations for ASM
>> and SSM
>>
>> but provide superior performance in the presence of source-
>>      specific signaling (IGMPv3/MLDv2).
>> ==> Wouldn't a reference to RFC 4604 ("Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast") make sense or be helpful here?
>>
>> p.18
>> This filter base Must be updated, if and => This filter base MUST be
>> updated, if and
>>
>> In
>>      addition, local multicast packets are transferred => In
>>      addition, multicast packets from locally attached sources are
>> transferred
>> or:
>>    In addition, such locally arriving multicast packets are transferred
>>
>> p.19
>> 6.  IANA Considerations
>>      TODO.
>> ==> to me there seem to be no IANA activities arising from the proposed protocol modifications, right?
>>
>> p.20
>> the PMIPv6 domain will not actively terminate group membership prior
>>      to departure.
>> =>
>> the PMIPv6 domain will in general not actively terminate group membership prior
>>      to departure.
>>
>> p.22
>> but alternate configuriations => but alternate configurations
>>
>> a state decomposition , if needed => a state decomposition, if needed...
>>
>> Hope this helps.
>> Thanks!
>>
>> Best regards
>> Dirk
>>
>> -----Original Message-----
>> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On
>> Behalf Of internet-drafts@ietf.org
>> Sent: Samstag, 13. Juli 2013 00:50
>> To: i-d-announce@ietf.org
>> Cc: multimob@ietf.org
>> Subject: [multimob] I-D Action:
>> draft-ietf-multimob-pmipv6-source-04.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>    This draft is a work item of the Multicast Mobility Working Group of the IETF.
>>
>> 	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
>> 	Author(s)       : Thomas C. Schmidt
>>                             Shuai Gao
>>                             Hong-Ke Zhang
>>                             Matthias Waehlisch
>> 	Filename        : draft-ietf-multimob-pmipv6-source-04.txt
>> 	Pages           : 24
>> 	Date            : 2013-07-12
>>
>> Abstract:
>>      Multicast communication can be enabled in Proxy Mobile IPv6 domains
>>      via the Local Mobility Anchors by deploying MLD Proxy functions at
>>      Mobile Access Gateways, via a direct traffic distribution within an
>>      ISP's access network, or by selective route optimization schemes.
>>      This document describes the support of mobile multicast senders in
>>      Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>>      optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>>      function for MLD Proxies defined.  Mobile sources always remain
>>      agnostic of multicast mobility operations.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> 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
>>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

From internet-drafts@ietf.org  Mon Sep 30 06:24:12 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C476821F9C4A; Mon, 30 Sep 2013 06:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNAieovuyaaO; Mon, 30 Sep 2013 06:24:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2204121F9C28; Mon, 30 Sep 2013 06:24:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.72
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130930132412.31558.93179.idtracker@ietfa.amsl.com>
Date: Mon, 30 Sep 2013 06:24:12 -0700
Cc: multimob@ietf.org
Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-05.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 13:24:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Multicast Mobility Working Group of the I=
ETF.

	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 (PM=
IPv6) Domains
	Author(s)       : Thomas C. Schmidt
                          Shuai Gao
                          Hong-Ke Zhang
                          Matthias Waehlisch
	Filename        : draft-ietf-multimob-pmipv6-source-05.txt
	Pages           : 27
	Date            : 2013-09-30

Abstract:
   Multicast communication can be enabled in Proxy Mobile IPv6 domains
   via the Local Mobility Anchors by deploying MLD proxy functions at
   Mobile Access Gateways, via a direct traffic distribution within an
   ISP's access network, or by selective route optimization schemes.
   This document describes the support of mobile multicast senders in
   Proxy Mobile IPv6 domains for all three scenarios.  Protocol
   optimizations for synchronizing PMIPv6 with PIM, as well as a peering
   function for MLD Proxies are defined.  Mobile sources always remain
   agnostic of multicast mobility operations.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From schmidt@informatik.haw-hamburg.de  Mon Sep 30 06:29:36 2013
Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C721F8F61 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 06:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.243
X-Spam-Level: 
X-Spam-Status: No, score=-105.243 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPF+6-B1d2Dc for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 06:29:31 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 082B821F8F09 for <multimob@ietf.org>; Mon, 30 Sep 2013 06:29:30 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from g231107117.adsl.alicedsl.de ([92.231.107.117] helo=[192.168.178.33]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1VQdXV-000Hzq-Td for multimob@ietf.org; Mon, 30 Sep 2013 15:29:30 +0200
Message-ID: <52497CB7.6080008@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 15:29:27 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "multimob@ietf.org" <multimob@ietf.org>
References: <20130930132412.31558.93179.idtracker@ietfa.amsl.com>
In-Reply-To: <20130930132412.31558.93179.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130930132412.31558.93179.idtracker@ietfa.amsl.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
Subject: [multimob] Fwd: I-D Action: draft-ietf-multimob-pmipv6-source-05.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 13:29:36 -0000

Hi all,

the new version of the PMIPv6 Mcast source draft includes all work 
promised in the Berlin meeting. The update also accounts for all reviews 
and proposed improvements therein.

It should now be ready for WGLC, we believe.

Thanks,

thomas


-------- Original Message --------
Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-05.txt
Date: Mon, 30 Sep 2013 06:24:12 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: multimob@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Multicast Mobility Working Group of 
the IETF.

	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 
(PMIPv6) Domains
	Author(s)       : Thomas C. Schmidt
                           Shuai Gao
                           Hong-Ke Zhang
                           Matthias Waehlisch
	Filename        : draft-ietf-multimob-pmipv6-source-05.txt
	Pages           : 27
	Date            : 2013-09-30

Abstract:
    Multicast communication can be enabled in Proxy Mobile IPv6 domains
    via the Local Mobility Anchors by deploying MLD proxy functions at
    Mobile Access Gateways, via a direct traffic distribution within an
    ISP's access network, or by selective route optimization schemes.
    This document describes the support of mobile multicast senders in
    Proxy Mobile IPv6 domains for all three scenarios.  Protocol
    optimizations for synchronizing PMIPv6 with PIM, as well as a peering
    function for MLD Proxies are defined.  Mobile sources always remain
    agnostic of multicast mobility operations.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob



From Dirk.von-Hugo@telekom.de  Mon Sep 30 06:52:17 2013
Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EC121F9385 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 06:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFrUlgqjHjbA for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 06:52:13 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9333621F9343 for <multimob@ietf.org>; Mon, 30 Sep 2013 06:52:11 -0700 (PDT)
Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 30 Sep 2013 15:51:50 +0200
Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 30 Sep 2013 15:51:50 +0200
From: <Dirk.von-Hugo@telekom.de>
To: <schmidt@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 15:51:48 +0200
Thread-Topic: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
Thread-Index: Ac69aIOUfO7COYFYRpaGsiCxQcZjZgAeSCLw
Message-ID: <05C81A773E48DD49B181B04BA21A342A2C72A132A6@HE113484.emea1.cds.t-internal.com>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de>
In-Reply-To: <5248B269.2020507@informatik.haw-hamburg.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 13:52:17 -0000

Hi Thomas and co-authors,
Thank you for the effort.
I am fine with the changes and all other improvements introduced in v05 and=
 agree that we could go for WGLC now ...
Best regards
Dirk

-----Original Message-----
From: Thomas C. Schmidt [mailto:schmidt@informatik.haw-hamburg.de]=20
Sent: Montag, 30. September 2013 01:06
To: von Hugo, Dirk
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.tx=
t

Hi Dirk,

thanks again for your detailed comments. Please see replies inline.

On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de wrote:

> As promised at IETF-87 I did a review of the source multicast mobility dr=
aft and think the document is in quite good shape.
>
> Being not the distinct expert in details of multicast protocols I am not =
sure to have understood everything in detail, so please correct me and forg=
ive misunderstandings ...
>
> The three scenarios described are
> 1) the base solution with MLD proxies at MAGs (and optionally also at=20
> LMAs) (sect.3)
> 2) direct routing with or without MLD proxies at MAGs and with native=20
> Multicast support at MAG level or above via different established=20
> Multicast protocols (sect.4)
> 3) Routing optimization for direct routing with MLD proxies at MAGs=20
> (sect. 5) Right?

Yes, this is it.

> IMHO from the abstract this is not easily to see.
>

We have adjusted the abstract. In any case, it explicitly addresses
(enumerates) the three scenarios mentioned abobe.

> I have some comments and suggestions to increase readability, in addition=
 to some nits found, given in the following:
>
> Fig. 1, fig.3 to be placed on single pages to simplify readability.

This is a fine-tuning that shall be done with the RFC-editor. In the proces=
s of RFC-editing, the boilerplate will change and so will the positioning o=
f floating text and figures.

> Consistently use re-attach and re-distribute _or_ reattach and redistribu=
te, respectively, throughout document.
> Is there any implicit meaning of Proxy with respect to proxy? Also MLD Pr=
oxy and MLD proxy are both used throughout the document ...

Thanks ... this should be corrected, now.

>
> p.1
>     optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>     function for MLD Proxies defined.
> =3D>   optimizations for synchronizing PMIPv6 with PIM, as well as a peer=
ing
>     function for MLD Proxies are defined.
>

Thanks, corrected.

> p.3
> Such approaches (partially) follow the
>     business model of providing multicast data services in parallel to
>     PMIPv6 unicast routing.
> =3D=3D> shouldn't one or more references be added here such as to [I-D.ie=
tf-multimob-pmipv6-ropt], draft-ietf-multimob-fmipv6-pfmipv6-multicast, dra=
ft-ietf-multimob-handover-optimization  ...?
>

Yes, good point: It's added now.

> needs of receptive use cases
> =3D> needs of applications for mobile multicast reception of content=20
> from few and mainly fixed content sources
>
> p.5
>
> A multicast unaware MAG would simply discard these packets in
>     the absence of a multicast routing information base (MRIB).
> =3D=3D> shouldn't one add more information about MRIBs introduced here fo=
r non-multicast aware readers such as: Such tables similar to MFIBs mention=
ed in RFC 6224 ensure that the router is able to correctly route/forward pa=
ckets with multicast addresses as destinations .

O.K. - we've added a brief explanatory insert ... even though I believe tha=
t a mulitcast unaware reader will not succeed in taking profit from this do=
cument ;)

>
> In case of a handover, the MN (unaware of IP mobility)
> =3D> In case of a handover, the MN (being unaware of IP mobility)
>

O.K., fixed.

> as soon as network connectivity is
>     reconfigured
> =3D> as soon as network connectivity is
>     re-established
>
O.K., fixed.


> p.7
> multicast data is =3D> multicast data are
>

Mhmm, my dictionary says "data is" ... "data" is a singular term that=20
subsumes (uncountable) plural ...


> p.8
> In addition, an LMA serving as PIM Designated Router is connected
> =3D>  In addition, an LMA serving as PIM Designated Router (DR) is connec=
ted
>

O.K., fixed.

> incoming interface validation is only performed by RPF
>     checks
> =3D> incoming interface validation is only performed by RPF (Reverse Path=
 Forwarding)
>     checks
>

O.K., fixed.

> Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>     respect to source location and does not require special
>     configurations or state management for sources.
> =3D=3D> Wouldn't it make sense to add a reason for this, e.g.
> ... since BIDIR PIM automatically builds trees to allow multicast data to=
 be natively forwarded from sources to receivers without requiring source-s=
pecific information ...
> On the other hand a reference to sect. 4.4 might be perhaps misleading he=
re since this section is not on direct multicast routing?!

This is about the nature of BIDIR-PIM. The reason for this property is=20
the bidirectional use of a static (=3D source-independent) spanning tree=20
... but explaining the ideas behind BIDIR-PIM may really go too far here=20
... if readers haven't heard about BIDIR-PIM, the should look up the=20
reference.

>
> an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as for
>     IPv6.
> =3D> an IGMP proxy
>     function needs to be deployed at MAGs in exactly the same way as is d=
one for an MLD proxy for
>     IPv6.
>
> p.9
> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances
> =3D> For a dual-stack IPv4/IPv6 access network, the MAG proxy instances (=
i.e. IPMP/MLD proxy functions)
>
> In the following, efficiency-related issues remain.
> =3D> In the following, efficiency-related issues which remain unsolved wi=
thin the above defined base PMIPv6 multicast source support are described.
>

Here, we would prefer the shorter forms.

> p.11
> upstream will lead traffic into the multicast infrastructure
> =3D>  upstream will transfer traffic into the multicast infrastructure
>

o.k.

> p.12
> configurations have completed =3D> configurations have been completed
>

o.k.

> traffic from the mobile source continues to be transmitted via the
>     same next-hop router using the same source address
> =3D>  traffic from the mobile source continues to be transmitted via the
>     same next-hop multicast router using the same source address
>

o.k.

> by aggregating proxies on a lower layer.
> =3D=3D> please clarify: what layer exactly is proposed? PIM DR at MAGs?
>

A lower layer is meant in the (OSI) layered model: Layer 2 or below.

>    in the access network for providing multicast services in parallel to
>     unicast routes.
> =3D>  in the access network for providing multicast services in parallel =
to
>     unicast routes ( see Fig. 3(b)).
>

O.K.

> p.13
>    The following information is needed for all phases of PIM.
> =3D>  The following information is needed for all three phases of PIM as =
outlined in [RFC4601].
>

O.K.

> P.14
> configured to not initiated (S,G) shortest path tress for mobile
> =3D> configured to not initiated (S,G) shortest path trees for mobile
>

Thanks, o.k.

> mobile source.  This tree can be of lesser routing efficiency than
> =3D> mobile source.  This tree can be of lower routing efficiency than
>

o.k.

> In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface immediately responds with a register stop.
> =3D> In
>     response, the PIM RP will recognize the known source at a new
>     (tunnel) interface and thus (?) immediately respond with a register s=
top.
>

O.k., fixed.

> As the
>     RP had joined the shortest path tree to receive from the source via
>     the LMA,
> =3D>As the
>     RP has joined the shortest path tree to receive data from the source =
via
>     the LMA,
>

Meanwhile replaced.

> the LMA, it will see an RPF change when data arrives at a new
> =3D> the LMA, it will see an RPF change when data arrive at a new
>

s.o.

> In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiated a source-specific Join for
> =3D> In response to an exceeded threshold of packet transmission, DRs of
>     receivers eventually will initiate a source-specific Join for
>

Thanks, fixed.

> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the
>     mobile source
> =3D>
> this (S,G) tree will range from
>     the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the se=
rving MAG to the
>     mobile source (described from leave to root?)
>

o.k.

> This tree is of higher routing efficiency than
> established in the previous phase two
> =3D>
> This tree is of higher routing efficiency than
>   that established in the previous phase two
>

thanks, o.k.

> p.15
> via the source register tunnel.  Tree mainenance eventually triggered
> =3D> via the source register tunnel.  Tree maintenance eventually trigger=
ed
>

Thanks, o.k.

> p.16
>    BIDIR-PIM MAY be deployed in the access network =3D>  BIDIR-PIM [RFC50=
15] MAY be deployed in the access network
>

Ref has been provided before.

> remain uneffected by node mobility =3D> remain unaffected by node mobilit=
y
>

Thanks, fixed.

> spanning group tree =3D> spanning tree for the multicast group /multicast=
 spanning tree
>

o.k., thanks.

> p.17
> document.  To overcome these deficits, an optimized approach to
> =3D=3D> AFAIU it does mainly cover deficits mentioned in sect. 4, if also=
 those inefficiencies described in 3.2.5 are tackled this should be explain=
ed

Actually, the main concerns that are addressed in this peering approach=20
are from section 3.2.5, namely the parallel proxy instances, which route=20
via an LMA.

We've added text to make this clearer.

>
> Following different techniques, these requirements are met in the
>     following solutions.
> =3D=3D> to me it seems to be one solution only (peering between MLD proxi=
es) adapted to several multicast protocol implementations for ASM and SSM
>

Yes, the original text covered also the multiple-upstream proxy, which=20
moved to the appendix now. The text has been corrected now.

> but provide superior performance in the presence of source-
>     specific signaling (IGMPv3/MLDv2).
> =3D=3D> Wouldn't a reference to RFC 4604 ("Using Internet Group Managemen=
t Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Ver=
sion 2 (MLDv2) for Source-Specific Multicast") make sense or be helpful her=
e?

O.k., we've added this.
>
> p.18
> This filter base Must be updated, if and =3D> This filter base MUST be up=
dated, if and
>

thanks, fixed.

> In
>     addition, local multicast packets are transferred
> =3D>
> In
>     addition, multicast packets from locally attached sources are transfe=
rred
> or:
>   In addition, such locally arriving multicast packets are transferred
>

O.k., reworded.

> p.19
> 6.  IANA Considerations
>     TODO.
> =3D=3D> to me there seem to be no IANA activities arising from the propos=
ed protocol modifications, right?
>

Yes.

> p.20
> the PMIPv6 domain will not actively terminate group membership prior
>     to departure.
> =3D>
> the PMIPv6 domain will in general not actively terminate group membership=
 prior
>     to departure.
>

o.k.

> p.22
> but alternate configuriations =3D> but alternate configurations
>
> a state decomposition , if needed =3D> a state decomposition, if needed..=
.
>

Thanks, fixed.

> Hope this helps.

Yes, thanks a lot for this detailed review!

Best wishes,

Thomas


> -----Original Message-----
> From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Beh=
alf Of internet-drafts@ietf.org
> Sent: Samstag, 13. Juli 2013 00:50
> To: i-d-announce@ietf.org
> Cc: multimob@ietf.org
> Subject: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>   This draft is a work item of the Multicast Mobility Working Group of th=
e IETF.
>
> 	Title           : Mobile Multicast Sender Support in Proxy Mobile IPv6 (=
PMIPv6) Domains
> 	Author(s)       : Thomas C. Schmidt
>                            Shuai Gao
>                            Hong-Ke Zhang
>                            Matthias Waehlisch
> 	Filename        : draft-ietf-multimob-pmipv6-source-04.txt
> 	Pages           : 24
> 	Date            : 2013-07-12
>
> Abstract:
>     Multicast communication can be enabled in Proxy Mobile IPv6 domains
>     via the Local Mobility Anchors by deploying MLD Proxy functions at
>     Mobile Access Gateways, via a direct traffic distribution within an
>     ISP's access network, or by selective route optimization schemes.
>     This document describes the support of mobile multicast senders in
>     Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>     optimizations for synchronizing PMIPv6 with PIM, as well as a peering
>     function for MLD Proxies defined.  Mobile sources always remain
>     agnostic of multicast mobility operations.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-pmipv6-source-04
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> multimob mailing list
> multimob@ietf.org
> https://www.ietf.org/mailman/listinfo/multimob
>

--=20

Prof. Dr. Thomas C. Schmidt
=B0 Hamburg University of Applied Sciences                   Berliner Tor 7=
 =B0
=B0 Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany=
 =B0
=B0 http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452=
 =B0
=B0 http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409=
 =B0

From stig@venaas.com  Mon Sep 30 12:19:55 2013
Return-Path: <stig@venaas.com>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C9121F8EA8 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 12:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.382
X-Spam-Level: 
X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsgxy34Mj2Oq for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 12:19:54 -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 6617321F8E3D for <multimob@ietf.org>; Mon, 30 Sep 2013 12:19:52 -0700 (PDT)
Received: from [10.33.12.93] (128-107-239-235.cisco.com [128.107.239.235]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3DC8C7FED; Mon, 30 Sep 2013 21:19:47 +0200 (CEST)
Message-ID: <5249CED1.5070305@venaas.com>
Date: Mon, 30 Sep 2013 12:19:45 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com> <524969A3.4010907@informatik.haw-hamburg.de>
In-Reply-To: <524969A3.4010907@informatik.haw-hamburg.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 19:19:55 -0000

Hi

On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote:
> Dear Cong Liu,
>
> thanks for your feedback - please see inline.
>
> On 30.09.2013 08:47, Cong Liu wrote:
>
>> Regarding this draft, I have the following comments for consideration.
>>
>> P14: "This tree can be of lesser routing efficiency than the PIM source
>> register tunnel established in phase one, but provides the advantage of
>> immediate data delivery to receivers that share a MAG with S."
>> - This sentence implicitly indicates that local receivers sharing a MAG
>> with S cannot receive immediate multicast traffic from the S in phase
>> one. In my opinion, even in phase one, the MAG acting as the DR has the
>> related multicast state so that immediate data delivery is possible. If
>> so, the sentence here is not appropriate.
>>
>
> This sentence actually refers to the building of an (S,G)-Tree at the
> end of PIM phase II. This tree follows reverse unicast routes and thus
> traverses the LMA-MAG tunnel - this is why it may be of lower efficiency
> than the forward (register) tunnel in phase I.
>
> What you are referring to is the question of source-local traffic
> distribution in PIM phase I. According to the way I understand  PIM-SM,
> it does not distribute source-specific traffic locally in Phase I. This
> is because a local source S generates an (S,G)-State at the sender's
> local router (DR), but a receiver in ASM requires an (*,G) service.

Traffic is distributed locally independent of the registration process.
I assume you're talking about a source on one interface, and receivers
on other interfaces on the same router? In that case for ASM (receivers
joining a group, not specific sources), there would already be
(*,G)-join state, and packets from the source would both be forwarded
on the joined interfaces and sent as PIM registers.

> If (S,G) traffic were distributed locally, then the required (*,G)-Join
> to the RP would cause duplicate (S,G) traffic arriving at the
> source-local receiver.

No, that shouldn't happen.

> Looking at the spec in Section 3.1 of RFC4601:
>
>    "At the end of phase one, multicast traffic is flowing encapsulated to
>     the RP, and then natively over the RP tree to the multicast receivers."

That is sort of the general picture, but any receivers connected to the
first hop router (and also later any routers on the path from the FHR to
the RP) would receive packets before this.

Stig

>
>> Some nits:
>> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy
>> or MLD Proxy
>> 2) P14: This tree can be of lesser routing efficiency
>> - This tree can be of less routing efficiency
>>
>
> Thanks, it's fixed.
>
> Best regards,
>
> Thomas
>
>> Thanks!
>>
>> Best Regards,
>> Cong Liu
>>
>>
>> 2013/9/30 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
>> <mailto:schmidt@informatik.haw-hamburg.de>>
>>
>>     Hi Dirk,
>>
>>     thanks again for your detailed comments. Please see replies inline.
>>
>>     On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de
>>     <mailto:Dirk.von-Hugo@telekom.de> wrote:
>>
>>         As promised at IETF-87 I did a review of the source multicast
>>         mobility draft and think the document is in quite good shape.
>>
>>         Being not the distinct expert in details of multicast protocols
>>         I am not sure to have understood everything in detail, so please
>>         correct me and forgive misunderstandings ...
>>
>>         The three scenarios described are
>>         1) the base solution with MLD proxies at MAGs (and optionally
>>         also at LMAs) (sect.3)
>>         2) direct routing with or without MLD proxies at MAGs and with
>>         native Multicast support at MAG level or above via different
>>         established Multicast protocols (sect.4)
>>         3) Routing optimization for direct routing with MLD proxies at
>>         MAGs (sect. 5)
>>         Right?
>>
>>
>>     Yes, this is it.
>>
>>         IMHO from the abstract this is not easily to see.
>>
>>
>>     We have adjusted the abstract. In any case, it explicitly addresses
>>     (enumerates) the three scenarios mentioned abobe.
>>
>>         I have some comments and suggestions to increase readability, in
>>         addition to some nits found, given in the following:
>>
>>         Fig. 1, fig.3 to be placed on single pages to simplify
>> readability.
>>
>>
>>     This is a fine-tuning that shall be done with the RFC-editor. In the
>>     process of RFC-editing, the boilerplate will change and so will the
>>     positioning of floating text and figures.
>>
>>         Consistently use re-attach and re-distribute _or_ reattach and
>>         redistribute, respectively, throughout document.
>>         Is there any implicit meaning of Proxy with respect to proxy?
>>         Also MLD Proxy and MLD proxy are both used throughout the
>>         document ...
>>
>>
>>     Thanks ... this should be corrected, now.
>>
>>
>>         p.1
>>              optimizations for synchronizing PMIPv6 with PIM, as well as
>>         a peering
>>              function for MLD Proxies defined.
>>         =>   optimizations for synchronizing PMIPv6 with PIM, as well as
>>         a peering
>>              function for MLD Proxies are defined.
>>
>>
>>     Thanks, corrected.
>>
>>         p.3
>>         Such approaches (partially) follow the
>>              business model of providing multicast data services in
>>         parallel to
>>              PMIPv6 unicast routing.
>>         ==> shouldn't one or more references be added here such as to
>>         [I-D.ietf-multimob-pmipv6-__ropt],
>>         draft-ietf-multimob-fmipv6-__pfmipv6-multicast,
>>         draft-ietf-multimob-handover-__optimization  ...?
>>
>>
>>     Yes, good point: It's added now.
>>
>>         needs of receptive use cases
>>         => needs of applications for mobile multicast reception of
>>         content from few and mainly fixed content sources
>>
>>         p.5
>>
>>         A multicast unaware MAG would simply discard these packets in
>>              the absence of a multicast routing information base (MRIB).
>>         ==> shouldn't one add more information about MRIBs introduced
>>         here for non-multicast aware readers such as: Such tables
>>         similar to MFIBs mentioned in RFC 6224 ensure that the router is
>>         able to correctly route/forward packets with multicast addresses
>>         as destinations .
>>
>>
>>     O.K. - we've added a brief explanatory insert ... even though I
>>     believe that a mulitcast unaware reader will not succeed in taking
>>     profit from this document ;)
>>
>>
>>         In case of a handover, the MN (unaware of IP mobility)
>>         => In case of a handover, the MN (being unaware of IP mobility)
>>
>>
>>     O.K., fixed.
>>
>>         as soon as network connectivity is
>>              reconfigured
>>         => as soon as network connectivity is
>>              re-established
>>
>>     O.K., fixed.
>>
>>
>>         p.7
>>         multicast data is => multicast data are
>>
>>
>>     Mhmm, my dictionary says "data is" ... "data" is a singular term
>>     that subsumes (uncountable) plural ...
>>
>>
>>         p.8
>>         In addition, an LMA serving as PIM Designated Router is connected
>>         =>  In addition, an LMA serving as PIM Designated Router (DR) is
>>         connected
>>
>>
>>     O.K., fixed.
>>
>>         incoming interface validation is only performed by RPF
>>              checks
>>         => incoming interface validation is only performed by RPF
>>         (Reverse Path Forwarding)
>>              checks
>>
>>
>>     O.K., fixed.
>>
>>         Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>>              respect to source location and does not require special
>>              configurations or state management for sources.
>>         ==> Wouldn't it make sense to add a reason for this, e.g.
>>         ... since BIDIR PIM automatically builds trees to allow
>>         multicast data to be natively forwarded from sources to
>>         receivers without requiring source-specific information ...
>>         On the other hand a reference to sect. 4.4 might be perhaps
>>         misleading here since this section is not on direct multicast
>>         routing?!
>>
>>
>>     This is about the nature of BIDIR-PIM. The reason for this property
>>     is the bidirectional use of a static (= source-independent) spanning
>>     tree ... but explaining the ideas behind BIDIR-PIM may really go too
>>     far here ... if readers haven't heard about BIDIR-PIM, the should
>>     look up the reference.
>>
>>
>>         an IGMP proxy
>>              function needs to be deployed at MAGs in exactly the same
>>         way as for
>>              IPv6.
>>         => an IGMP proxy
>>              function needs to be deployed at MAGs in exactly the same
>>         way as is done for an MLD proxy for
>>              IPv6.
>>
>>         p.9
>>         For a dual-stack IPv4/IPv6 access network, the MAG proxy
>> instances
>>         => For a dual-stack IPv4/IPv6 access network, the MAG proxy
>>         instances (i.e. IPMP/MLD proxy functions)
>>
>>         In the following, efficiency-related issues remain.
>>         => In the following, efficiency-related issues which remain
>>         unsolved within the above defined base PMIPv6 multicast source
>>         support are described.
>>
>>
>>     Here, we would prefer the shorter forms.
>>
>>         p.11
>>         upstream will lead traffic into the multicast infrastructure
>>         =>  upstream will transfer traffic into the multicast
>> infrastructure
>>
>>
>>     o.k.
>>
>>         p.12
>>         configurations have completed => configurations have been
>> completed
>>
>>
>>     o.k.
>>
>>         traffic from the mobile source continues to be transmitted via
>> the
>>              same next-hop router using the same source address
>>         =>  traffic from the mobile source continues to be transmitted
>>         via the
>>              same next-hop multicast router using the same source address
>>
>>
>>     o.k.
>>
>>         by aggregating proxies on a lower layer.
>>         ==> please clarify: what layer exactly is proposed? PIM DR at
>> MAGs?
>>
>>
>>     A lower layer is meant in the (OSI) layered model: Layer 2 or below.
>>
>>             in the access network for providing multicast services in
>>         parallel to
>>              unicast routes.
>>         =>  in the access network for providing multicast services in
>>         parallel to
>>              unicast routes ( see Fig. 3(b)).
>>
>>
>>     O.K.
>>
>>         p.13
>>             The following information is needed for all phases of PIM.
>>         =>  The following information is needed for all three phases of
>>         PIM as outlined in [RFC4601].
>>
>>
>>     O.K.
>>
>>         P.14
>>         configured to not initiated (S,G) shortest path tress for mobile
>>         => configured to not initiated (S,G) shortest path trees for
>> mobile
>>
>>
>>     Thanks, o.k.
>>
>>         mobile source.  This tree can be of lesser routing efficiency
>> than
>>         => mobile source.  This tree can be of lower routing
>> efficiency than
>>
>>
>>     o.k.
>>
>>         In
>>              response, the PIM RP will recognize the known source at a
>> new
>>              (tunnel) interface immediately responds with a register
>> stop.
>>         => In
>>              response, the PIM RP will recognize the known source at a
>> new
>>              (tunnel) interface and thus (?) immediately respond with a
>>         register stop.
>>
>>
>>     O.k., fixed.
>>
>>         As the
>>              RP had joined the shortest path tree to receive from the
>>         source via
>>              the LMA,
>>         =>As the
>>              RP has joined the shortest path tree to receive data from
>>         the source via
>>              the LMA,
>>
>>
>>     Meanwhile replaced.
>>
>>         the LMA, it will see an RPF change when data arrives at a new
>>         => the LMA, it will see an RPF change when data arrive at a new
>>
>>
>>     s.o.
>>
>>         In response to an exceeded threshold of packet transmission,
>> DRs of
>>              receivers eventually will initiated a source-specific
>> Join for
>>         => In response to an exceeded threshold of packet transmission,
>>         DRs of
>>              receivers eventually will initiate a source-specific Join
>> for
>>
>>
>>     Thanks, fixed.
>>
>>         this (S,G) tree will range from
>>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel
>>         to the
>>              mobile source
>>         =>
>>         this (S,G) tree will range from
>>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel,
>>         and the serving MAG to the
>>              mobile source (described from leave to root?)
>>
>>
>>     o.k.
>>
>>         This tree is of higher routing efficiency than
>>         established in the previous phase two
>>         =>
>>         This tree is of higher routing efficiency than
>>            that established in the previous phase two
>>
>>
>>     thanks, o.k.
>>
>>         p.15
>>         via the source register tunnel.  Tree mainenance eventually
>>         triggered
>>         => via the source register tunnel.  Tree maintenance eventually
>>         triggered
>>
>>
>>     Thanks, o.k.
>>
>>         p.16
>>             BIDIR-PIM MAY be deployed in the access network =>
>>           BIDIR-PIM [RFC5015] MAY be deployed in the access network
>>
>>
>>     Ref has been provided before.
>>
>>         remain uneffected by node mobility => remain unaffected by node
>>         mobility
>>
>>
>>     Thanks, fixed.
>>
>>         spanning group tree => spanning tree for the multicast group
>>         /multicast spanning tree
>>
>>
>>     o.k., thanks.
>>
>>         p.17
>>         document.  To overcome these deficits, an optimized approach to
>>         ==> AFAIU it does mainly cover deficits mentioned in sect. 4, if
>>         also those inefficiencies described in 3.2.5 are tackled this
>>         should be explained
>>
>>
>>     Actually, the main concerns that are addressed in this peering
>>     approach are from section 3.2.5, namely the parallel proxy
>>     instances, which route via an LMA.
>>
>>     We've added text to make this clearer.
>>
>>
>>         Following different techniques, these requirements are met in the
>>              following solutions.
>>         ==> to me it seems to be one solution only (peering between MLD
>>         proxies) adapted to several multicast protocol implementations
>>         for ASM and SSM
>>
>>
>>     Yes, the original text covered also the multiple-upstream proxy,
>>     which moved to the appendix now. The text has been corrected now.
>>
>>         but provide superior performance in the presence of source-
>>              specific signaling (IGMPv3/MLDv2).
>>         ==> Wouldn't a reference to RFC 4604 ("Using Internet Group
>>         Management Protocol Version 3 (IGMPv3) and Multicast Listener
>>         Discovery Protocol Version 2 (MLDv2) for Source-Specific
>>         Multicast") make sense or be helpful here?
>>
>>
>>     O.k., we've added this.
>>
>>
>>         p.18
>>         This filter base Must be updated, if and => This filter base
>>         MUST be updated, if and
>>
>>
>>     thanks, fixed.
>>
>>         In
>>              addition, local multicast packets are transferred
>>         =>
>>         In
>>              addition, multicast packets from locally attached sources
>>         are transferred
>>         or:
>>            In addition, such locally arriving multicast packets are
>>         transferred
>>
>>
>>     O.k., reworded.
>>
>>         p.19
>>         6.  IANA Considerations
>>              TODO.
>>         ==> to me there seem to be no IANA activities arising from the
>>         proposed protocol modifications, right?
>>
>>
>>     Yes.
>>
>>         p.20
>>         the PMIPv6 domain will not actively terminate group membership
>> prior
>>              to departure.
>>         =>
>>         the PMIPv6 domain will in general not actively terminate group
>>         membership prior
>>              to departure.
>>
>>
>>     o.k.
>>
>>         p.22
>>         but alternate configuriations => but alternate configurations
>>
>>         a state decomposition , if needed => a state decomposition, if
>>         needed...
>>
>>
>>     Thanks, fixed.
>>
>>         Hope this helps.
>>
>>
>>     Yes, thanks a lot for this detailed review!
>>
>>     Best wishes,
>>
>>     Thomas
>>
>>
>>         -----Original Message-----
>>         From: multimob-bounces@ietf.org
>>         <mailto:multimob-bounces@ietf.org>
>>         [mailto:multimob-bounces@ietf.__org
>>         <mailto:multimob-bounces@ietf.org>] On Behalf Of
>>         internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>         Sent: Samstag, 13. Juli 2013 00:50
>>         To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>         Cc: multimob@ietf.org <mailto:multimob@ietf.org>
>>         Subject: [multimob] I-D Action:
>>         draft-ietf-multimob-pmipv6-__source-04.txt
>>
>>
>>         A New Internet-Draft is available from the on-line
>>         Internet-Drafts directories.
>>            This draft is a work item of the Multicast Mobility Working
>>         Group of the IETF.
>>
>>                  Title           : Mobile Multicast Sender Support in
>>         Proxy Mobile IPv6 (PMIPv6) Domains
>>                  Author(s)       : Thomas C. Schmidt
>>                                     Shuai Gao
>>                                     Hong-Ke Zhang
>>                                     Matthias Waehlisch
>>                  Filename        :
>>         draft-ietf-multimob-pmipv6-__source-04.txt
>>                  Pages           : 24
>>                  Date            : 2013-07-12
>>
>>         Abstract:
>>              Multicast communication can be enabled in Proxy Mobile IPv6
>>         domains
>>              via the Local Mobility Anchors by deploying MLD Proxy
>>         functions at
>>              Mobile Access Gateways, via a direct traffic distribution
>>         within an
>>              ISP's access network, or by selective route optimization
>>         schemes.
>>              This document describes the support of mobile multicast
>>         senders in
>>              Proxy Mobile IPv6 domains for all three scenarios.  Protocol
>>              optimizations for synchronizing PMIPv6 with PIM, as well as
>>         a peering
>>              function for MLD Proxies defined.  Mobile sources always
>> remain
>>              agnostic of multicast mobility operations.
>>
>>
>>
>>         The IETF datatracker status page for this draft is:
>>
>> https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source
>>
>> <https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>>
>>         There's also a htmlized version available at:
>>
>> http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04
>>         <http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>>
>>         A diff from the previous version is available at:
>>
>> http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04
>>
>> <http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04>
>>
>>
>>         Internet-Drafts are also available by anonymous FTP at:
>>         ftp://ftp.ietf.org/internet-__drafts/
>>         <ftp://ftp.ietf.org/internet-drafts/>
>>
>>         _________________________________________________
>>         multimob mailing list
>>         multimob@ietf.org <mailto:multimob@ietf.org>
>>         https://www.ietf.org/mailman/__listinfo/multimob
>>         <https://www.ietf.org/mailman/listinfo/multimob>
>>
>>
>>     --
>>
>>     Prof. Dr. Thomas C. Schmidt
>>     ° Hamburg University of Applied Sciences                   Berliner
>>     Tor 7 °
>>     ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
>>     Germany °
>>     ° http://www.haw-hamburg.de/inet                   Fon:
>>     +49-40-42875-8452 °
>>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>>     +49-40-42875-8409 °
>>     _________________________________________________
>>     multimob mailing list
>>     multimob@ietf.org <mailto:multimob@ietf.org>
>>     https://www.ietf.org/mailman/__listinfo/multimob
>>     <https://www.ietf.org/mailman/listinfo/multimob>
>>
>>
>


From schmidt@informatik.haw-hamburg.de  Mon Sep 30 13:37:39 2013
Return-Path: <schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EB721F9E39 for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 13:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.262
X-Spam-Level: 
X-Spam-Status: No, score=-105.262 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+S-0KDNzOTq for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 13:37:33 -0700 (PDT)
Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5B21F9DD6 for <multimob@ietf.org>; Mon, 30 Sep 2013 13:37:32 -0700 (PDT)
Envelope-to: multimob@ietf.org
Received: from g231107117.adsl.alicedsl.de ([92.231.107.117] helo=[192.168.178.33]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <schmidt@informatik.haw-hamburg.de>) id 1VQkDh-000DTr-N7; Mon, 30 Sep 2013 22:37:30 +0200
Message-ID: <5249E105.8040405@informatik.haw-hamburg.de>
Date: Mon, 30 Sep 2013 22:37:25 +0200
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Stig Venaas <stig@venaas.com>
References: <20130712225013.13108.48313.idtracker@ietfa.amsl.com> <05C81A773E48DD49B181B04BA21A342A2C60C13A2A@HE113484.emea1.cds.t-internal.com> <5248B269.2020507@informatik.haw-hamburg.de> <CAF+sHxEd5zx3N_9nwOGHS2C7SwiKHc6W-=GEcGk3qzQa6cESOw@mail.gmail.com> <524969A3.4010907@informatik.haw-hamburg.de> <5249CED1.5070305@venaas.com>
In-Reply-To: <5249CED1.5070305@venaas.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de)
X-HTW-DELIVERED-TO: multimob@ietf.org
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D Action: draft-ietf-multimob-pmipv6-source-04.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 30 Sep 2013 20:37:39 -0000

Hi Stig,

you're the PIM expert ... however, your statements confuse me.

Event though the discussion does not matter to the source draft, I would 
like to clarify. Please see inline.

On 30.09.2013 21:19, Stig Venaas wrote:
> Hi
>
> On 9/30/2013 5:08 AM, Thomas C. Schmidt wrote:
>> Dear Cong Liu,
>>
>> thanks for your feedback - please see inline.
>>
>> On 30.09.2013 08:47, Cong Liu wrote:
>>
>>> Regarding this draft, I have the following comments for consideration.
>>>
>>> P14: "This tree can be of lesser routing efficiency than the PIM source
>>> register tunnel established in phase one, but provides the advantage of
>>> immediate data delivery to receivers that share a MAG with S."
>>> - This sentence implicitly indicates that local receivers sharing a MAG
>>> with S cannot receive immediate multicast traffic from the S in phase
>>> one. In my opinion, even in phase one, the MAG acting as the DR has the
>>> related multicast state so that immediate data delivery is possible. If
>>> so, the sentence here is not appropriate.
>>>
>>
>> This sentence actually refers to the building of an (S,G)-Tree at the
>> end of PIM phase II. This tree follows reverse unicast routes and thus
>> traverses the LMA-MAG tunnel - this is why it may be of lower efficiency
>> than the forward (register) tunnel in phase I.
>>
>> What you are referring to is the question of source-local traffic
>> distribution in PIM phase I. According to the way I understand  PIM-SM,
>> it does not distribute source-specific traffic locally in Phase I. This
>> is because a local source S generates an (S,G)-State at the sender's
>> local router (DR), but a receiver in ASM requires an (*,G) service.
>
> Traffic is distributed locally independent of the registration process.
> I assume you're talking about a source on one interface, and receivers
> on other interfaces on the same router? In that case for ASM (receivers
> joining a group, not specific sources), there would already be
> (*,G)-join state, and packets from the source would both be forwarded
> on the joined interfaces and sent as PIM registers.
>

Mhmm ... this would mean that you have two feeds into the distribution 
tree: One rooted at the source (valid for local receivers), and one 
rooted at the RP - at this stage, we are still in phase I.

>> If (S,G) traffic were distributed locally, then the required (*,G)-Join
>> to the RP would cause duplicate (S,G) traffic arriving at the
>> source-local receiver.
>
> No, that shouldn't happen.
>

How do you exclude? In phase I, all traffic is tunneled to the RP and 
the "path" from source to RP is not visible to the multicast 
distribution system. The DR of the receiver, which happens to be the DR 
of one of the sources, would just initiate an (*,G) join towards the RP 
... and all traffic tunneled to the RP would be distributed down to the 
receivers.

Thus traffic from the (local) source would reach the (local) DR and the 
receiver twice ????

>> Looking at the spec in Section 3.1 of RFC4601:
>>
>>    "At the end of phase one, multicast traffic is flowing encapsulated to
>>     the RP, and then natively over the RP tree to the multicast
>> receivers."
>
> That is sort of the general picture, but any receivers connected to the
> first hop router (and also later any routers on the path from the FHR to
> the RP) would receive packets before this.
>

I guess not: If multicast packets are tunneled in source register 
packets, how can an intermediate router distribute them locally? I 
suppose you are talking about PIM phase II, aren't you?

Cheers,

Thomas


>>> Some nits:
>>> 1) The term "MLD proxy" and "MLD Proxy" should be unified as MLD proxy
>>> or MLD Proxy
>>> 2) P14: This tree can be of lesser routing efficiency
>>> - This tree can be of less routing efficiency
>>>
>>
>> Thanks, it's fixed.
>>
>> Best regards,
>>
>> Thomas
>>
>>> Thanks!
>>>
>>> Best Regards,
>>> Cong Liu
>>>
>>>
>>> 2013/9/30 Thomas C. Schmidt <schmidt@informatik.haw-hamburg.de
>>> <mailto:schmidt@informatik.haw-hamburg.de>>
>>>
>>>     Hi Dirk,
>>>
>>>     thanks again for your detailed comments. Please see replies inline.
>>>
>>>     On 26.08.2013 18:29, Dirk.von-Hugo@telekom.de
>>>     <mailto:Dirk.von-Hugo@telekom.de> wrote:
>>>
>>>         As promised at IETF-87 I did a review of the source multicast
>>>         mobility draft and think the document is in quite good shape.
>>>
>>>         Being not the distinct expert in details of multicast protocols
>>>         I am not sure to have understood everything in detail, so please
>>>         correct me and forgive misunderstandings ...
>>>
>>>         The three scenarios described are
>>>         1) the base solution with MLD proxies at MAGs (and optionally
>>>         also at LMAs) (sect.3)
>>>         2) direct routing with or without MLD proxies at MAGs and with
>>>         native Multicast support at MAG level or above via different
>>>         established Multicast protocols (sect.4)
>>>         3) Routing optimization for direct routing with MLD proxies at
>>>         MAGs (sect. 5)
>>>         Right?
>>>
>>>
>>>     Yes, this is it.
>>>
>>>         IMHO from the abstract this is not easily to see.
>>>
>>>
>>>     We have adjusted the abstract. In any case, it explicitly addresses
>>>     (enumerates) the three scenarios mentioned abobe.
>>>
>>>         I have some comments and suggestions to increase readability, in
>>>         addition to some nits found, given in the following:
>>>
>>>         Fig. 1, fig.3 to be placed on single pages to simplify
>>> readability.
>>>
>>>
>>>     This is a fine-tuning that shall be done with the RFC-editor. In the
>>>     process of RFC-editing, the boilerplate will change and so will the
>>>     positioning of floating text and figures.
>>>
>>>         Consistently use re-attach and re-distribute _or_ reattach and
>>>         redistribute, respectively, throughout document.
>>>         Is there any implicit meaning of Proxy with respect to proxy?
>>>         Also MLD Proxy and MLD proxy are both used throughout the
>>>         document ...
>>>
>>>
>>>     Thanks ... this should be corrected, now.
>>>
>>>
>>>         p.1
>>>              optimizations for synchronizing PMIPv6 with PIM, as well as
>>>         a peering
>>>              function for MLD Proxies defined.
>>>         =>   optimizations for synchronizing PMIPv6 with PIM, as well as
>>>         a peering
>>>              function for MLD Proxies are defined.
>>>
>>>
>>>     Thanks, corrected.
>>>
>>>         p.3
>>>         Such approaches (partially) follow the
>>>              business model of providing multicast data services in
>>>         parallel to
>>>              PMIPv6 unicast routing.
>>>         ==> shouldn't one or more references be added here such as to
>>>         [I-D.ietf-multimob-pmipv6-__ropt],
>>>         draft-ietf-multimob-fmipv6-__pfmipv6-multicast,
>>>         draft-ietf-multimob-handover-__optimization  ...?
>>>
>>>
>>>     Yes, good point: It's added now.
>>>
>>>         needs of receptive use cases
>>>         => needs of applications for mobile multicast reception of
>>>         content from few and mainly fixed content sources
>>>
>>>         p.5
>>>
>>>         A multicast unaware MAG would simply discard these packets in
>>>              the absence of a multicast routing information base (MRIB).
>>>         ==> shouldn't one add more information about MRIBs introduced
>>>         here for non-multicast aware readers such as: Such tables
>>>         similar to MFIBs mentioned in RFC 6224 ensure that the router is
>>>         able to correctly route/forward packets with multicast addresses
>>>         as destinations .
>>>
>>>
>>>     O.K. - we've added a brief explanatory insert ... even though I
>>>     believe that a mulitcast unaware reader will not succeed in taking
>>>     profit from this document ;)
>>>
>>>
>>>         In case of a handover, the MN (unaware of IP mobility)
>>>         => In case of a handover, the MN (being unaware of IP mobility)
>>>
>>>
>>>     O.K., fixed.
>>>
>>>         as soon as network connectivity is
>>>              reconfigured
>>>         => as soon as network connectivity is
>>>              re-established
>>>
>>>     O.K., fixed.
>>>
>>>
>>>         p.7
>>>         multicast data is => multicast data are
>>>
>>>
>>>     Mhmm, my dictionary says "data is" ... "data" is a singular term
>>>     that subsumes (uncountable) plural ...
>>>
>>>
>>>         p.8
>>>         In addition, an LMA serving as PIM Designated Router is
>>> connected
>>>         =>  In addition, an LMA serving as PIM Designated Router (DR) is
>>>         connected
>>>
>>>
>>>     O.K., fixed.
>>>
>>>         incoming interface validation is only performed by RPF
>>>              checks
>>>         => incoming interface validation is only performed by RPF
>>>         (Reverse Path Forwarding)
>>>              checks
>>>
>>>
>>>     O.K., fixed.
>>>
>>>         Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with
>>>              respect to source location and does not require special
>>>              configurations or state management for sources.
>>>         ==> Wouldn't it make sense to add a reason for this, e.g.
>>>         ... since BIDIR PIM automatically builds trees to allow
>>>         multicast data to be natively forwarded from sources to
>>>         receivers without requiring source-specific information ...
>>>         On the other hand a reference to sect. 4.4 might be perhaps
>>>         misleading here since this section is not on direct multicast
>>>         routing?!
>>>
>>>
>>>     This is about the nature of BIDIR-PIM. The reason for this property
>>>     is the bidirectional use of a static (= source-independent) spanning
>>>     tree ... but explaining the ideas behind BIDIR-PIM may really go too
>>>     far here ... if readers haven't heard about BIDIR-PIM, the should
>>>     look up the reference.
>>>
>>>
>>>         an IGMP proxy
>>>              function needs to be deployed at MAGs in exactly the same
>>>         way as for
>>>              IPv6.
>>>         => an IGMP proxy
>>>              function needs to be deployed at MAGs in exactly the same
>>>         way as is done for an MLD proxy for
>>>              IPv6.
>>>
>>>         p.9
>>>         For a dual-stack IPv4/IPv6 access network, the MAG proxy
>>> instances
>>>         => For a dual-stack IPv4/IPv6 access network, the MAG proxy
>>>         instances (i.e. IPMP/MLD proxy functions)
>>>
>>>         In the following, efficiency-related issues remain.
>>>         => In the following, efficiency-related issues which remain
>>>         unsolved within the above defined base PMIPv6 multicast source
>>>         support are described.
>>>
>>>
>>>     Here, we would prefer the shorter forms.
>>>
>>>         p.11
>>>         upstream will lead traffic into the multicast infrastructure
>>>         =>  upstream will transfer traffic into the multicast
>>> infrastructure
>>>
>>>
>>>     o.k.
>>>
>>>         p.12
>>>         configurations have completed => configurations have been
>>> completed
>>>
>>>
>>>     o.k.
>>>
>>>         traffic from the mobile source continues to be transmitted via
>>> the
>>>              same next-hop router using the same source address
>>>         =>  traffic from the mobile source continues to be transmitted
>>>         via the
>>>              same next-hop multicast router using the same source
>>> address
>>>
>>>
>>>     o.k.
>>>
>>>         by aggregating proxies on a lower layer.
>>>         ==> please clarify: what layer exactly is proposed? PIM DR at
>>> MAGs?
>>>
>>>
>>>     A lower layer is meant in the (OSI) layered model: Layer 2 or below.
>>>
>>>             in the access network for providing multicast services in
>>>         parallel to
>>>              unicast routes.
>>>         =>  in the access network for providing multicast services in
>>>         parallel to
>>>              unicast routes ( see Fig. 3(b)).
>>>
>>>
>>>     O.K.
>>>
>>>         p.13
>>>             The following information is needed for all phases of PIM.
>>>         =>  The following information is needed for all three phases of
>>>         PIM as outlined in [RFC4601].
>>>
>>>
>>>     O.K.
>>>
>>>         P.14
>>>         configured to not initiated (S,G) shortest path tress for mobile
>>>         => configured to not initiated (S,G) shortest path trees for
>>> mobile
>>>
>>>
>>>     Thanks, o.k.
>>>
>>>         mobile source.  This tree can be of lesser routing efficiency
>>> than
>>>         => mobile source.  This tree can be of lower routing
>>> efficiency than
>>>
>>>
>>>     o.k.
>>>
>>>         In
>>>              response, the PIM RP will recognize the known source at a
>>> new
>>>              (tunnel) interface immediately responds with a register
>>> stop.
>>>         => In
>>>              response, the PIM RP will recognize the known source at a
>>> new
>>>              (tunnel) interface and thus (?) immediately respond with a
>>>         register stop.
>>>
>>>
>>>     O.k., fixed.
>>>
>>>         As the
>>>              RP had joined the shortest path tree to receive from the
>>>         source via
>>>              the LMA,
>>>         =>As the
>>>              RP has joined the shortest path tree to receive data from
>>>         the source via
>>>              the LMA,
>>>
>>>
>>>     Meanwhile replaced.
>>>
>>>         the LMA, it will see an RPF change when data arrives at a new
>>>         => the LMA, it will see an RPF change when data arrive at a new
>>>
>>>
>>>     s.o.
>>>
>>>         In response to an exceeded threshold of packet transmission,
>>> DRs of
>>>              receivers eventually will initiated a source-specific
>>> Join for
>>>         => In response to an exceeded threshold of packet transmission,
>>>         DRs of
>>>              receivers eventually will initiate a source-specific Join
>>> for
>>>
>>>
>>>     Thanks, fixed.
>>>
>>>         this (S,G) tree will range from
>>>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel
>>>         to the
>>>              mobile source
>>>         =>
>>>         this (S,G) tree will range from
>>>              the receiving DR via the (stable) LMA, the LMA-MAG tunnel,
>>>         and the serving MAG to the
>>>              mobile source (described from leave to root?)
>>>
>>>
>>>     o.k.
>>>
>>>         This tree is of higher routing efficiency than
>>>         established in the previous phase two
>>>         =>
>>>         This tree is of higher routing efficiency than
>>>            that established in the previous phase two
>>>
>>>
>>>     thanks, o.k.
>>>
>>>         p.15
>>>         via the source register tunnel.  Tree mainenance eventually
>>>         triggered
>>>         => via the source register tunnel.  Tree maintenance eventually
>>>         triggered
>>>
>>>
>>>     Thanks, o.k.
>>>
>>>         p.16
>>>             BIDIR-PIM MAY be deployed in the access network =>
>>>           BIDIR-PIM [RFC5015] MAY be deployed in the access network
>>>
>>>
>>>     Ref has been provided before.
>>>
>>>         remain uneffected by node mobility => remain unaffected by node
>>>         mobility
>>>
>>>
>>>     Thanks, fixed.
>>>
>>>         spanning group tree => spanning tree for the multicast group
>>>         /multicast spanning tree
>>>
>>>
>>>     o.k., thanks.
>>>
>>>         p.17
>>>         document.  To overcome these deficits, an optimized approach to
>>>         ==> AFAIU it does mainly cover deficits mentioned in sect. 4, if
>>>         also those inefficiencies described in 3.2.5 are tackled this
>>>         should be explained
>>>
>>>
>>>     Actually, the main concerns that are addressed in this peering
>>>     approach are from section 3.2.5, namely the parallel proxy
>>>     instances, which route via an LMA.
>>>
>>>     We've added text to make this clearer.
>>>
>>>
>>>         Following different techniques, these requirements are met in
>>> the
>>>              following solutions.
>>>         ==> to me it seems to be one solution only (peering between MLD
>>>         proxies) adapted to several multicast protocol implementations
>>>         for ASM and SSM
>>>
>>>
>>>     Yes, the original text covered also the multiple-upstream proxy,
>>>     which moved to the appendix now. The text has been corrected now.
>>>
>>>         but provide superior performance in the presence of source-
>>>              specific signaling (IGMPv3/MLDv2).
>>>         ==> Wouldn't a reference to RFC 4604 ("Using Internet Group
>>>         Management Protocol Version 3 (IGMPv3) and Multicast Listener
>>>         Discovery Protocol Version 2 (MLDv2) for Source-Specific
>>>         Multicast") make sense or be helpful here?
>>>
>>>
>>>     O.k., we've added this.
>>>
>>>
>>>         p.18
>>>         This filter base Must be updated, if and => This filter base
>>>         MUST be updated, if and
>>>
>>>
>>>     thanks, fixed.
>>>
>>>         In
>>>              addition, local multicast packets are transferred
>>>         =>
>>>         In
>>>              addition, multicast packets from locally attached sources
>>>         are transferred
>>>         or:
>>>            In addition, such locally arriving multicast packets are
>>>         transferred
>>>
>>>
>>>     O.k., reworded.
>>>
>>>         p.19
>>>         6.  IANA Considerations
>>>              TODO.
>>>         ==> to me there seem to be no IANA activities arising from the
>>>         proposed protocol modifications, right?
>>>
>>>
>>>     Yes.
>>>
>>>         p.20
>>>         the PMIPv6 domain will not actively terminate group membership
>>> prior
>>>              to departure.
>>>         =>
>>>         the PMIPv6 domain will in general not actively terminate group
>>>         membership prior
>>>              to departure.
>>>
>>>
>>>     o.k.
>>>
>>>         p.22
>>>         but alternate configuriations => but alternate configurations
>>>
>>>         a state decomposition , if needed => a state decomposition, if
>>>         needed...
>>>
>>>
>>>     Thanks, fixed.
>>>
>>>         Hope this helps.
>>>
>>>
>>>     Yes, thanks a lot for this detailed review!
>>>
>>>     Best wishes,
>>>
>>>     Thomas
>>>
>>>
>>>         -----Original Message-----
>>>         From: multimob-bounces@ietf.org
>>>         <mailto:multimob-bounces@ietf.org>
>>>         [mailto:multimob-bounces@ietf.__org
>>>         <mailto:multimob-bounces@ietf.org>] On Behalf Of
>>>         internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>>         Sent: Samstag, 13. Juli 2013 00:50
>>>         To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>>         Cc: multimob@ietf.org <mailto:multimob@ietf.org>
>>>         Subject: [multimob] I-D Action:
>>>         draft-ietf-multimob-pmipv6-__source-04.txt
>>>
>>>
>>>         A New Internet-Draft is available from the on-line
>>>         Internet-Drafts directories.
>>>            This draft is a work item of the Multicast Mobility Working
>>>         Group of the IETF.
>>>
>>>                  Title           : Mobile Multicast Sender Support in
>>>         Proxy Mobile IPv6 (PMIPv6) Domains
>>>                  Author(s)       : Thomas C. Schmidt
>>>                                     Shuai Gao
>>>                                     Hong-Ke Zhang
>>>                                     Matthias Waehlisch
>>>                  Filename        :
>>>         draft-ietf-multimob-pmipv6-__source-04.txt
>>>                  Pages           : 24
>>>                  Date            : 2013-07-12
>>>
>>>         Abstract:
>>>              Multicast communication can be enabled in Proxy Mobile IPv6
>>>         domains
>>>              via the Local Mobility Anchors by deploying MLD Proxy
>>>         functions at
>>>              Mobile Access Gateways, via a direct traffic distribution
>>>         within an
>>>              ISP's access network, or by selective route optimization
>>>         schemes.
>>>              This document describes the support of mobile multicast
>>>         senders in
>>>              Proxy Mobile IPv6 domains for all three scenarios.
>>> Protocol
>>>              optimizations for synchronizing PMIPv6 with PIM, as well as
>>>         a peering
>>>              function for MLD Proxies defined.  Mobile sources always
>>> remain
>>>              agnostic of multicast mobility operations.
>>>
>>>
>>>
>>>         The IETF datatracker status page for this draft is:
>>>
>>> https://datatracker.ietf.org/__doc/draft-ietf-multimob-__pmipv6-source
>>>
>>> <https://datatracker.ietf.org/doc/draft-ietf-multimob-pmipv6-source>
>>>
>>>         There's also a htmlized version available at:
>>>
>>> http://tools.ietf.org/html/__draft-ietf-multimob-pmipv6-__source-04
>>>
>>> <http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-source-04>
>>>
>>>         A diff from the previous version is available at:
>>>
>>> http://www.ietf.org/rfcdiff?__url2=draft-ietf-multimob-__pmipv6-source-04
>>>
>>>
>>> <http://www.ietf.org/rfcdiff?url2=draft-ietf-multimob-pmipv6-source-04>
>>>
>>>
>>>         Internet-Drafts are also available by anonymous FTP at:
>>>         ftp://ftp.ietf.org/internet-__drafts/
>>>         <ftp://ftp.ietf.org/internet-drafts/>
>>>
>>>         _________________________________________________
>>>         multimob mailing list
>>>         multimob@ietf.org <mailto:multimob@ietf.org>
>>>         https://www.ietf.org/mailman/__listinfo/multimob
>>>         <https://www.ietf.org/mailman/listinfo/multimob>
>>>
>>>
>>>     --
>>>
>>>     Prof. Dr. Thomas C. Schmidt
>>>     ° Hamburg University of Applied Sciences                   Berliner
>>>     Tor 7 °
>>>     ° Dept. Informatik, Internet Technologies Group    20099 Hamburg,
>>>     Germany °
>>>     ° http://www.haw-hamburg.de/inet                   Fon:
>>>     +49-40-42875-8452 °
>>>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>>>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>>>     +49-40-42875-8409 °
>>>     _________________________________________________
>>>     multimob mailing list
>>>     multimob@ietf.org <mailto:multimob@ietf.org>
>>>     https://www.ietf.org/mailman/__listinfo/multimob
>>>     <https://www.ietf.org/mailman/listinfo/multimob>
>>>
>>>
>>
>

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

From karagian@cs.utwente.nl  Mon Sep 30 23:06:43 2013
Return-Path: <karagian@cs.utwente.nl>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBD721F995F for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 23:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.797
X-Spam-Level: 
X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[AWL=-1.300,  BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DkNRyGHOyAD for <multimob@ietfa.amsl.com>; Mon, 30 Sep 2013 23:06:33 -0700 (PDT)
Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5713C21F995B for <multimob@ietf.org>; Mon, 30 Sep 2013 23:06:31 -0700 (PDT)
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 1 Oct 2013 08:06:32 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.114]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 08:06:30 +0200
From: <karagian@cs.utwente.nl>
To: <schmidt@informatik.haw-hamburg.de>
Thread-Topic: [multimob] I-D Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt
Thread-Index: AQHOucPFGQ0RZJFPB0+MtdBpNsnqrZnfY3m/gAABv4Y=
Date: Tue, 1 Oct 2013 06:06:28 +0000
Message-ID: <FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509A@EXMBX23.ad.utwente.nl>
References: <201309251549114085692@gmail.com>
In-Reply-To: <201309251549114085692@gmail.com>
Accept-Language: nl-NL, en-US
Content-Language: nl-NL
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mimectl: Produced By Microsoft Exchange V14.2.247.1
x-originating-ip: [86.91.134.3]
Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509AEXMBX23adutwent_"
MIME-Version: 1.0
Cc: multimob@ietf.org
Subject: Re: [multimob] I-D	Action:draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 01 Oct 2013 06:06:43 -0000

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509AEXMBX23adutwent_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Hi Thomas,



During the last multimob WG meeting in Berlin I had volunteerd to provide c=
omments on the last version of this draft.

Here are these comments:


Comment_1:  The draft is useful since it is providing a solution for seamle=
ss and fast handover for multicast applications by extending existing seaml=
ess and fast handover solutions used for unicast applications, which are th=
e Mobile IPv6 Fast Handovers (FMIPv6) specified in RFC5568 and the Fast Han=
dovers for Proxy Mobile IPv6 (PFMIPv6) specified in RFC5949.

Comment_2: A motivation section is missing from the draft. In my opinion it=
 is very useful to include such section in this draft. In particular, this =
draft mentions that a seamless and fast handover solutions is needed for mu=
lticast applications like IPTV. Other scenarios and applications that will =
make use of such a solutions are Public Protection and Disaster Relief (PPD=
R) scenarios, where mobile multicast communications need to be supported be=
tween members of rescue teams, police officers, fire brigade teams, paramed=
ic teams, command control offices in order to support the protection and he=
alth of citizens.

In particular three main PPDR scenarios & application types could be distin=
guished:

1)            City security scenario:  that can be used to support the day =
to day safety and security of citizens.
2)            Disaster recovery scenario that deals with the protection of =
people and rescue teams during large scale natural or man-made disasters, l=
ike flooding, earth quakes and nuclear disasters.
3)            Temporary Protection PPDR scenario that deals with safety and=
 security of citizens visiting large planned events like football matches, =
pop concerts and protest demonstrations.


Comment_3: List the requirements that need to be satisfied by this solution=
. You may use as example Section 1.1 of  http://www.ietf.org/id/draft-ietf-=
multimob-handover-optimization-04.txt


Comment_4: Provide a more detailed message flow description, similar to the=
 one that is given in Section 5.1.2 in=1B$B!^=1B(B
http://www.ietf.org/id/draft-ietf-multimob-handover-optimization-04.txt
This comment holds for Figures 2, 3, 4, 5

Comment_5: There is no description on how this draft, which specifies a mob=
ile multicast listener support solution, can be used in combination a the m=
obile multicast senders, solution e.g., http://www.ietf.org/id/draft-ietf-m=
ultimob-pmipv6-source-05.txt.
There are scenarios and applications that require the use of these two solu=
tions simultaneously.


Best regards,

Georgios



>
>A New Internet-Draft is available from the on-line Internet-Drafts directo=
ries.
> This draft is a work item of the Multicast Mobility Working Group of the =
IETF.
>
>       Title           : Multicast Listener Extensions for MIPv6 and PMIPv=
6 Fast Handovers
>       Author(s)       : Thomas C. Schmidt
>                          Matthias Waehlisch
>                          Rajeev Koodli
>                          Godred Fairhurst
>                          Dapeng Liu
>       Filename        : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.t=
xt
>       Pages           : 27
>       Date            : 2013-02-25
>
>Abstract:
>   Fast handover protocols for MIPv6 and PMIPv6 define mobility
>   management procedures that support unicast communication at reduced
>   handover latency.  Fast handover base operations do not affect
>   multicast communication, and hence do not accelerate handover
>   management for native multicast listeners.  Many multicast
>   applications like IPTV or conferencing, though, are comprised of
>   delay-sensitive real-time traffic and will benefit from fast handover
>   execution.  This document specifies extension of the Mobile IPv6 Fast
>   Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6
>   (PFMIPv6) protocols to include multicast traffic management in fast
>   handover operations.  This multicast support is provided first at the
>   control plane by a management of rapid context transfer between
>   access routers, second at the data plane by an optional fast traffic
>   forwarding that may include buffering.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-pfmipv6-multic=
ast
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv6-multicast-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fmipv6-pfmipv6-mult=
icast-01
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>multimob mailing list
>multimob@ietf.org
>https://www.ietf.org/mailman/listinfo/multimob

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=
 =3D


=1B$B!!!!!!!!!!!!!!!!CW=1B(B
=1B$BNi!*=1B(B


Shuai Gao
Associate Professor
National Engineering Lab for Next Generation Internet Interconnection Devic=
es
Beijing Jiaotong University
Beijing, China, 100044
gaoxlh@gmail.com
2013-09-25

_______________________________________________
multimob mailing list
multimob@ietf.org
https://www.ietf.org/mailman/listinfo/multimob

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509AEXMBX23adutwent_
Content-Type: text/html; charset="iso-2022-jp"
Content-ID: <C8347F9479330047B325A3F5ED15B1C1@exchange.utwente.nl>
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr" xmlns:o=3D"urn:schemas-microsoft-com:office:office">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-=
jp">
<style>.EmailQuote {
	BORDER-LEFT: #800000 2px solid; PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt
}
</style><style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body ocsi=3D"0" fPStyle=3D"1">
<font size=3D"2"><span style=3D"FONT-SIZE: 10pt"></span></font>
<div style=3D"FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZ=
E: 10pt">
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">Hi Thomas,</span></font=
></p>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt"></span></font>&nbsp;</p=
>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">During the last multimo=
b WG meeting in Berlin I had volunteerd to provide comments on the last ver=
sion of this draft.</span></font></p>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">Here are these comments=
:</span></font></p>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt"></span></font>&nbsp;</p=
>
<font size=3D"2"><span style=3D"FONT-SIZE: 10pt">
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">Comment_1:<span style=3D"m=
so-spacerun: yes">&nbsp;
</span>The draft is useful since it is providing a solution for seamless an=
d fast handover for multicast applications by extending existing seamless a=
nd fast handover solutions used for unicast applications, which are the Mob=
ile IPv6 Fast Handovers (FMIPv6)
 specified in RFC5568 and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6=
) specified in RFC5949.</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">Comment_2: A motivation se=
ction is missing from the draft. In my opinion it is very useful to include=
 such section in this draft. In particular,
 this draft mentions that a seamless and fast handover solutions is needed =
for multicast applications like IPTV. Other scenarios and applications that=
 will make use of such a solutions are Public Protection and Disaster Relie=
f (PPDR) scenarios, where mobile
 multicast communications need to be supported between members of rescue te=
ams, police officers, fire brigade teams, paramedic teams, command control =
offices in order to support the protection and health of citizens.</font></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">In particular three main P=
PDR scenarios &amp; application types could be distinguished:</font></span>=
</p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">1)<span style=3D"mso-tab-c=
ount: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>City security scenario:<span style=3D"mso-spacerun: yes">&nbsp; </sp=
an>that can be used to support the day to day safety and security of citize=
ns.</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">2)<span style=3D"mso-tab-c=
ount: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>Disaster recovery scenario that deals with the protection of people =
and rescue teams during large scale natural or man-made disasters, like flo=
oding, earth quakes and nuclear disasters.</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">3)<span style=3D"mso-tab-c=
ount: 1">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span>Temporary Protection PPDR scenario that deals with safety and securi=
ty of citizens visiting large planned events like football matches, pop con=
certs and protest demonstrations.</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">Comment_3: List the requir=
ements that need to be satisfied by this solution. You may use as example S=
ection 1.1 of&nbsp; http://www.ietf.org/id/draft-ietf-multimob-handover-opt=
imization-04.txt</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">Comment_4: Provide a more =
detailed message flow description, similar to the one that is given in Sect=
ion 5.1.2 in=1B$B!^=1B(B</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">http://www.ietf.org/id/dra=
ft-ietf-multimob-handover-optimization-04.txt</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">This comment holds for Fig=
ures 2, 3, 4, 5</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">Comment_5: There is no des=
cription on how this draft, which specifies a mobile multicast listener sup=
port solution, can be used in combination
 a the mobile multicast senders, solution e.g., http://www.ietf.org/id/draf=
t-ietf-multimob-pmipv6-source-05.txt.</font></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><font size=3D"2">There are scenarios and ap=
plications that require the use of these two solutions simultaneously.</fon=
t></span></p>
<p style=3D"TEXT-ALIGN: left; MARGIN: 0cm 0cm 0pt" class=3D"MsoNormal" alig=
n=3D"left"><span lang=3D"EN-US"><o:p><font size=3D"2">&nbsp;</font></o:p></=
span></p>
</span></font>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">Best regards,</span></f=
ont></p>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">Georgios</span></font><=
/p>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt"></span></font>&nbsp;</p=
>
<p><font size=3D"2"><span style=3D"FONT-SIZE: 10pt">&gt;<br>
&gt;A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.<br>
&gt; This draft is a work item of the Multicast Mobility Working Group of t=
he IETF.<br>
&gt;<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Multicast Listener Extensions for MIPv6 a=
nd PMIPv6 Fast Handovers<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; : Thomas C. Schmidt<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Matthias Waehlisch<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Rajeev Koodli<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Godred Fairhurst<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; Dapeng Liu<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; : draft-ietf-multimob-fmipv6-pfmipv6-multicast-01.txt<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 27<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2013-02-25<br>
&gt;<br>
&gt;Abstract:<br>
&gt;&nbsp;&nbsp; Fast handover protocols for MIPv6 and PMIPv6 define mobili=
ty<br>
&gt;&nbsp;&nbsp; management procedures that support unicast communication a=
t reduced<br>
&gt;&nbsp;&nbsp; handover latency.&nbsp; Fast handover base operations do n=
ot affect<br>
&gt;&nbsp;&nbsp; multicast communication, and hence do not accelerate hando=
ver<br>
&gt;&nbsp;&nbsp; management for native multicast listeners.&nbsp; Many mult=
icast<br>
&gt;&nbsp;&nbsp; applications like IPTV or conferencing, though, are compri=
sed of<br>
&gt;&nbsp;&nbsp; delay-sensitive real-time traffic and will benefit from fa=
st handover<br>
&gt;&nbsp;&nbsp; execution.&nbsp; This document specifies extension of the =
Mobile IPv6 Fast<br>
&gt;&nbsp;&nbsp; Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile=
 IPv6<br>
&gt;&nbsp;&nbsp; (PFMIPv6) protocols to include multicast traffic managemen=
t in fast<br>
&gt;&nbsp;&nbsp; handover operations.&nbsp; This multicast support is provi=
ded first at the<br>
&gt;&nbsp;&nbsp; control plane by a management of rapid context transfer be=
tween<br>
&gt;&nbsp;&nbsp; access routers, second at the data plane by an optional fa=
st traffic<br>
&gt;&nbsp;&nbsp; forwarding that may include buffering.<br>
&gt;<br>
&gt;<br>
&gt;The IETF datatracker status page for this draft is:<br>
&gt;<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-multimob-fmipv6-=
pfmipv6-multicast" target=3D"_blank">https://datatracker.ietf.org/doc/draft=
-ietf-multimob-fmipv6-pfmipv6-multicast</a><br>
&gt;<br>
&gt;There's also a htmlized version available at:<br>
&gt;<a href=3D"http://tools.ietf.org/html/draft-ietf-multimob-fmipv6-pfmipv=
6-multicast-01" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-mul=
timob-fmipv6-pfmipv6-multicast-01</a><br>
&gt;<br>
&gt;A diff from the previous version is available at:<br>
&gt;<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-multimob-fmipv=
6-pfmipv6-multicast-01" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=
=3Ddraft-ietf-multimob-fmipv6-pfmipv6-multicast-01</a><br>
&gt;<br>
&gt;<br>
&gt;Internet-Drafts are also available by anonymous FTP at:<br>
&gt;<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:/=
/ftp.ietf.org/internet-drafts/</a><br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;multimob mailing list<br>
&gt;multimob@ietf.org<br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/multimob" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/multimob</a><br>
<br>
=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D=
 =3D<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
<br>
=1B$B!!!!!!!!!!!!!!!!CW=1B(B<br>
=1B$BNi!*=1B(B<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
Shuai Gao<br>
Associate Professor<br>
National Engineering Lab for Next Generation Internet Interconnection Devic=
es<br>
Beijing Jiaotong University<br>
Beijing, China, 100044<br>
gaoxlh@gmail.com<br>
2013-09-25<br>
<br>
_______________________________________________<br>
multimob mailing list<br>
multimob@ietf.org<br>
<a href=3D"https://www.ietf.org/mailman/listinfo/multimob" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/multimob</a><br>
</p>
</span></font></div>
</body>
</html>

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3D509AEXMBX23adutwent_--