Re: [multimob] PMIPv6 Requirements Draft Updated

From multimob-bounces@ietf.org Tue Sep 2 08:35:09 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6D23A6B74; Tue, 2 Sep 2008 08:35:09 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922873A689A for ; Tue, 2 Sep 2008 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIzjQgugATP2 for ; Tue, 2 Sep 2008 08:35:07 -0700 (PDT) Received: from web84301.mail.re1.yahoo.com (web84301.mail.re1.yahoo.com [69.147.74.180]) by core3.amsl.com (Postfix) with SMTP id A9B3F3A6AEF for ; Tue, 2 Sep 2008 08:35:07 -0700 (PDT) Received: (qmail 84692 invoked by uid 60001); 2 Sep 2008 15:35:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=SvMGNXv4DN2Zbn+cqFMBZCkzZqjc1GtvLrepd24oMKGmR7+XkAIv5Fs5alei3YRZgUkcMrvVghW319njWI0ayVCKjmZYyXaCjJvkK8ka7i90P4Y65+VX0zunE8e8+IQG7UxcrJ/LPL7lQzMgntWXB126398REeJTYQquqTzTS2U=; X-YMail-OSG: PG.u9uUVM1mnCMz4vNa2KFB74IQthMl5lyTcZKoTCTFUCjZVKg7TwxV1uemE.fOcoPi6CMoC32locbsEJRbEDR_s9QKtfxr190fUr_Gz41fznBYqFn6xZUcSrqJFY5k- Received: from [206.16.17.212] by web84301.mail.re1.yahoo.com via HTTP; Tue, 02 Sep 2008 08:35:10 PDT X-Mailer: YahooMailRC/1042.40 YahooMailWebService/0.7.218.2 Date: Tue, 2 Sep 2008 08:35:10 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <290515.83791.qm@web84301.mail.re1.yahoo.com> Subject: [multimob] Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979265739==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1979265739== Content-Type: multipart/alternative; boundary="0-460142554-1220369710=:83791" --0-460142554-1220369710=:83791 Content-Type: text/plain; charset=us-ascii Hi all, Currently PMIPv6 multicast support requirements I-D is almost ready to be submitted. Please post your comments on the list after it is submitted. As discussed in Dublin, the initial (-00) PMIPv6 multicast support solution draft should be posted in mid-October. IETF cut-off date for -00 draft submission is October 27, 2008. Group management protocol related drafts will also follow similar schedules. Internet draft final submission deadline is Nov. 3, 2008. We will also be making a BoF request by September 15, 2008. Please submit any drafts you have on Multimob related topics and announce it on the list. Regards, Behcet --0-460142554-1220369710=:83791 Content-Type: text/html; charset=us-ascii

Hi all,
Currently PMIPv6 multicast support requirements I-D is almost ready to be submitted. Please post your comments on the list after it is submitted.
As discussed in Dublin, the initial (-00) PMIPv6 multicast support solution draft should be posted in mid-October. IETF cut-off date for -00 draft submission is October 27, 2008.
Group management protocol related drafts will also follow similar schedules.
Internet draft final submission deadline is Nov. 3, 2008.

We will also be making a BoF request by September 15, 2008.

Please submit any drafts you have on Multimob related topics and announce it on the list.

Regards,

Behcet

--0-460142554-1220369710=:83791-- --===============1979265739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1979265739==-- From multimob-bounces@ietf.org Tue Sep 16 19:59:26 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7533A6823; Tue, 16 Sep 2008 19:59:26 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613BB3A6823 for ; Tue, 16 Sep 2008 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNHAkzz5hW8x for ; Tue, 16 Sep 2008 19:59:24 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 0A7153A6813 for ; Tue, 16 Sep 2008 19:59:23 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so1438994eyd.31 for ; Tue, 16 Sep 2008 19:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=w9qWujLP4dY7jJo2twNkznQkTqRW7JH/NRhhN6OINmM=; b=k7dyGEgEGPlfcEzEoJVfCiTHvY9LHw003ifOfl/cK+p2cXHe89GRFAd/U3TTeyl1Nb 7D2HkJPFuTNcavZOPz+GDJQR8rR66KqfosDJLMiNNi2OqYLzIFY9DaP3mvDNjkjrCF9u Ab2CSgxEi5aVL0T+iQQRru64fYaBQo1J4S/kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Lpw+a4gUSTs/+Cbr9cIrCY2lAGJ2aq1ZqNtW/eMQ1p5x25VDss6w5JFo5QABNXMqVJ JZwPAMsK+sUaCIJjcanBUdXX9Dwsq28DqErSnkGDqx+sYluwhRPJThb8GsbpSZHx12cU PW+8mE2BRjOOjq9m0VKpUCgBDwJFR96ZTbf0k= Received: by 10.210.117.1 with SMTP id p1mr2355436ebc.84.1221620374878; Tue, 16 Sep 2008 19:59:34 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Tue, 16 Sep 2008 19:59:34 -0700 (PDT) Message-ID: <1d38a3350809161959v6da3ee42j8726ff36b4877cb0@mail.gmail.com> Date: Wed, 17 Sep 2008 10:59:34 +0800 From: "Hui Deng" To: multimob@ietf.org In-Reply-To: <20080917024502.726393A68B8@core3.amsl.com> MIME-Version: 1.0 References: <20080917024502.726393A68B8@core3.amsl.com> Subject: [multimob] Fwd: I-D Action:draft-deng-multimob-pmip6-requirement-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195078373==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1195078373== Content-Type: multipart/alternative; boundary="----=_Part_18125_22404451.1221620374896" ------=_Part_18125_22404451.1221620374896 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all Design team have finished the basic document writing, we would like to extend more deep discussion in the mailing list, Please feels free to comment on this, many thanks -Hui ---------- Forwarded message ---------- From: Date: 2008/9/17 Subject: I-D Action:draft-deng-multimob-pmip6-requirement-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multicast Support Requirements for Proxy Mobile IPv6 Author(s) : H. Deng, et al. Filename : draft-deng-multimob-pmip6-requirement-00.txt Pages : 14 Date : 2008-09-16 This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_Part_18125_22404451.1221620374896 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hello, all

Design team have finished the basic document writing,

we would like to extend more deep discussion in the mailing list,

Please feels free to comment on this,

many thanks

-Hui

---------- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
Date: 2008/9/17
Subject: I-D Action:draft-deng-multimob-pmip6-requirement-00.txt
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Multicast Support Requirements for Proxy Mobile IPv6
Author(s) : H. Deng, et al.
Filename : draft-deng-multimob-pmip6-requirement-00.txt
Pages : 14
Date : 2008-09-16

This document summarizes requirements for multicast listener support
in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to
PMIPv6, multicast mobility management requirements do not request any
active participation of the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-00.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_Part_18125_22404451.1221620374896-- --===============1195078373== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1195078373==-- From multimob-bounces@ietf.org Tue Sep 16 23:55:56 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C0F28C241; Tue, 16 Sep 2008 23:55:56 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA86328C241 for ; Tue, 16 Sep 2008 23:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDVlQsjTeGCO for ; Tue, 16 Sep 2008 23:55:53 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id 5501E28C1C1 for ; Tue, 16 Sep 2008 23:55:53 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1764364nfh.39 for ; Tue, 16 Sep 2008 23:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=kYtESpvw9UDIPIv9d2a2F+qK+RiZ9PmTivQ8qjn5PwQ=; b=RZSXfOL8UjwfHxMiClT9U5FzF+TDacfNdHM5279jH2iiXjZF2WGpZySyssuYhCVvnN sk5pruI6tlby/QRxf9Lyspk05WVvP2ZsOZcubntnKHnic7WuvAxSHChVEsfpiGz/CLzf PdnaA52Be7bJ0yuLuA733y0tu1BaO2T4SMQVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ZTaPvwBm6tsRlvorBqeHRnZMSqgx9DoXdWCzWQRgNUdAni6A7AWgZFUycA33nxmtsJ Qx/gmehNJPCz+s8EMtzWiSlOV1YMNCKjHOmL68jtIPqToCCKoDrghAFA92HayXXiTwK+ BZUO9u61f86qXArFVojPfQlPLbUO3OxCLcKL4= Received: by 10.210.117.1 with SMTP id p1mr2657978ebc.84.1221634564810; Tue, 16 Sep 2008 23:56:04 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Tue, 16 Sep 2008 23:56:04 -0700 (PDT) Message-ID: <1d38a3350809162356t306a2135pc9f9814a29da300b@mail.gmail.com> Date: Wed, 17 Sep 2008 14:56:04 +0800 From: "Hui Deng" To: multimob@ietf.org MIME-Version: 1.0 Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1640882541==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1640882541== Content-Type: multipart/alternative; boundary="----=_Part_1156_24029349.1221634564810" ------=_Part_1156_24029349.1221634564810 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Hitoshi, I had posted the draft, let's discuss in the mailing list. Please check with: http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-00 .txt See reply inline. > -----Original Message----- > From: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > Sent: Tuesday, September 16, 2008 11:23 AM > To: schmidt@informatik.haw-hamburg.de > Cc: denghui@chinamobile.com; dirk.hugo@t-systems.com; john.zhao@huawei.com; > mw@fhtw-berlin.de; suresh.krishnan@ericsson.com; pyang@hitachi.cn; > sarikaya@ieee.org; brian@innovationslab.net > Subject: Re: PMIPv6 Requirements Draft Updated > > Hi, > > Couple of comments. > > 1. 3.1 > "R1 - PMIPv6 multicast mobility management MUST transparently support > the reception of ASM and SSM channels." > Why MUST? It's too strong assumption. Some SPs may want to support > only SSM. In my sense, SSM is MUST, ASM is MAY. ==> if I replace "and" by "or", does it remove your concern? > 2. 4.1 > Text of this section is so much aware of service model like IPTV. > AAA and QoS stuff should not "SHOULD" in any place of this > document. > The way how AAA/QoS is managed depends on service models or service > providers. Only we can say "AAA or QoS may be necessary for some > multicast services and depend on the service models or providers." ==> "IPTV" appear only as the example of here, As you said "QoS" only appear as May, For "AAA", how about this? AAA functions MAY resident at the LMA, in particular admission control and accounting, MAY be preserved and applicable under multicast services. > 3. 4.2 > "Hence support of MLDv2 [RFC3810] is required at the MAG." > I prefer to say, "MLDv2 or LW-MLDv2 is required". This document > only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not > needed? ==> fine, thanks > > CAC is common word except with ATM? :) ==> Sure, but prefer remove "CAC", keep "Connection Admission Control" > Anyway, we should put more functional statements; what functions > are needed, and why. ==> Please try to propose it, thanks, -Hui > > Regards, > -- > Hitoshi Asaeda ------=_Part_1156_24029349.1221634564810 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi, Hitoshi,

I had posted the draft, let's discuss in the mailing list.
Please check with:
http://www.ietf.org/internet-drafts/draft-deng-multimob-pmip6-requirement-00
.txt

See reply inline.

> -----Original Message-----
> From: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp]
> Sent: Tuesday, September 16, 2008 11:23 AM
> To: schmidt@informatik.haw-hamburg.de
> Cc: denghui@chinamobile.com; dirk.hugo@t-systems.com;
john.zhao@huawei.com;
> mw@fhtw-berlin.de; suresh.krishnan@ericsson.com; pyang@hitachi.cn;
> sarikaya@ieee.org; brian@innovationslab.net
> Subject: Re: PMIPv6 Requirements Draft Updated
>
> Hi,
>
> Couple of comments.
>
> 1. 3.1
>    "R1 - PMIPv6 multicast mobility management MUST transparently support
>    the reception of ASM and SSM channels."
>    Why MUST? It's too strong assumption. Some SPs may want to support
>    only SSM. In my sense, SSM is MUST, ASM is MAY.
==> if I replace "and" by "or", does it remove your concern?

> 2. 4.1
>    Text of this section is so much aware of service model like IPTV.
>    AAA and QoS stuff should not "SHOULD" in any place of this
>    document.
>    The way how AAA/QoS is managed depends on service models or service
>    providers. Only we can say "AAA or QoS may be necessary for some
>    multicast services and depend on the service models or providers."
==> "IPTV" appear only as the example of here, As you said "QoS" only appear as May, For "AAA", how about this?
   AAA functions MAY resident at the LMA, in
   particular admission control and accounting, MAY be preserved and
   applicable under multicast services.

> 3. 4.2
>    "Hence support of MLDv2 [RFC3810] is required at the MAG."
>    I prefer to say, "MLDv2 or LW-MLDv2 is required". This document
>    only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not
>    needed?
==> fine, thanks

>
> CAC is common word except with ATM? :)
==> Sure, but prefer remove "CAC", keep "Connection Admission Control"

> Anyway, we should put more functional statements; what functions
> are needed, and why.
==> Please try to propose it, thanks,

-Hui

>
> Regards,
> --
> Hitoshi Asaeda

------=_Part_1156_24029349.1221634564810-- --===============1640882541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1640882541==-- From multimob-bounces@ietf.org Wed Sep 17 07:23:48 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F723A6A75; Wed, 17 Sep 2008 07:23:48 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93EC3A6A85 for ; Wed, 17 Sep 2008 07:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.712 X-Spam-Level: *** X-Spam-Status: No, score=3.712 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYX3LoOfuZNe for ; Wed, 17 Sep 2008 07:23:46 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 158FF3A6A75 for ; Wed, 17 Sep 2008 07:23:45 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 96C9C13D03D6; Wed, 17 Sep 2008 23:07:18 +0900 (JST) Date: Wed, 17 Sep 2008 23:23:33 +0900 (JST) Message-Id: <20080917.232333.106764775.asaeda@sfc.wide.ad.jp> To: denghui02@gmail.com From: Hitoshi Asaeda In-Reply-To: <1d38a3350809162356t306a2135pc9f9814a29da300b@mail.gmail.com> References: <1d38a3350809162356t306a2135pc9f9814a29da300b@mail.gmail.com> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org > > 1. 3.1 > > "R1 - PMIPv6 multicast mobility management MUST transparently support > > the reception of ASM and SSM channels." > > Why MUST? It's too strong assumption. Some SPs may want to support > > only SSM. In my sense, SSM is MUST, ASM is MAY. > ==> if I replace "and" by "or", does it remove your concern? No, not really. ASM and SSM are independent. In fact, I'd rather simply say, "SSM must be supported in PMIPv6 multicast." > > 3. 4.2 > > "Hence support of MLDv2 [RFC3810] is required at the MAG." > > I prefer to say, "MLDv2 or LW-MLDv2 is required". This document > > only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not > > needed? > ==> fine, thanks Since this document only discusses ipv6, so only saying MLDv2 and LW-MLDv2 is fine. > > CAC is common word except with ATM? :) > ==> Sure, but prefer remove "CAC", keep "Connection Admission Control" > > > Anyway, we should put more functional statements; what functions > > are needed, and why. > ==> Please try to propose it, thanks, Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA should be preserved at LMA". Sect.4.2 says "CAC is supported at MAG, Network Attachment Control should be supported at MAG". In my feeling, the current statements require implementing these functions in multicast protocols used in PMIPv6. At first, these statements should be explained from operators viewpoint. Not "LMA should control bw, MAG supports CAC", but "Controlling bw is an operational requirement and may be implemented at LMA". Then improve the whole sentence. (What are other operators' requirement and why.) -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Sep 17 08:24:31 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E9528C2D2; Wed, 17 Sep 2008 08:24:31 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D4E328C2E2 for ; Wed, 17 Sep 2008 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6OZBQpJkAia for ; Wed, 17 Sep 2008 08:24:30 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 25A2E28C2D2 for ; Wed, 17 Sep 2008 08:24:03 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from sirius.rz.fhtw-berlin.de ([141.45.7.43] helo=webmail.fhtw-berlin.de) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Kfyt5-00097P-AC; Wed, 17 Sep 2008 17:24:15 +0200 Received: from 193.63.130.65 (SquirrelMail authenticated user tschmidt) by webmail.fhtw-berlin.de with HTTP; Wed, 17 Sep 2008 17:24:15 +0200 (CEST) Message-ID: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> Date: Wed, 17 Sep 2008 17:24:15 +0200 (CEST) From: "Thomas C. Schmidt" To: "Hitoshi Asaeda" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Hitoshi et al, I would like to take some counter positions: Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda: >> > 1. 3.1 >> > "R1 - PMIPv6 multicast mobility management MUST transparently >> support >> > the reception of ASM and SSM channels." >> > Why MUST? It's too strong assumption. Some SPs may want to support only SSM. In my sense, SSM is MUST, ASM is MAY. >> =3D=3D> if I replace "and" by "or", does it remove your concern? > > No, not really. ASM and SSM are independent. > In fact, I'd rather simply say, "SSM must be supported in PMIPv6 multicast." > ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and currently we see an IPTV deployment on the basis of ASM (SSM strength is interdomain transparency, which is not needed nor desired in provider-bound IPTV offers). Anyway, the multicast flavor to actually deploy is the choice of any = individual provider ... but we want to define protocols (multicast extensions to PMIPv6), which enable such deployment. Therefore we should offer both multicast flavors and preserve the choice. Also: from the client perspective, ASM is easier to implement. Since we are not heading to re-define multicast core routing (I suppose), we don't have to worry about ASM-specific problems in the inter-domain. That we can leave to the providers ... and to the work of the multicast routing WGs. >> > 3. 4.2 >> > "Hence support of MLDv2 [RFC3810] is required at the MAG." I prefer to say, "MLDv2 or LW-MLDv2 is required". This document only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not needed? >> =3D=3D> fine, thanks > > Since this document only discusses ipv6, so only saying MLDv2 and LW-MLDv2 is fine. > There have been earlier (striking) arguments by Patrick to keep the MLD debate(s) out of this document. The issue here is the version 2, which is needed for SSM. Otherwise I would agree with Patrick to remain agnostic of MLD flavors and optimizations. >> > CAC is common word except with ATM? :) >> =3D=3D> Sure, but prefer remove "CAC", keep "Connection Admission Contro= l" >> >> > Anyway, we should put more functional statements; what functions are needed, and why. >> =3D=3D> Please try to propose it, thanks, > > Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA should be preserved at LMA". > Sect.4.2 says "CAC is supported at MAG, Network Attachment Control should be supported at MAG". > > In my feeling, the current statements require implementing these functions in multicast protocols used in PMIPv6. > At first, these statements should be explained from operators > viewpoint. Not "LMA should control bw, MAG supports CAC", but > "Controlling bw is an operational requirement and may be implemented at LMA". Then improve the whole sentence. (What are other operators' requirement and why.) Here I agree with Hitoshi: The whole section 4 is problematic, if it is taken to be more than a general Caveat of the type "Here are things we also should consider". May be it should be rephrased as "General Architectural Background", or so. Best regards, Thomas -- = =B0 Prof. Dr. Thomas C. Schmidt =B0 HAW Hamburg, Dept. Informatik =B0 University of Applied Sciences =B0 Berliner Tor 7, D 20099 Hamburg, Germany =B0 Fon: +49-40-42875-8452, Fax: -8409 =B0 http://www.informatik.haw-hamburg.de/~schmidt _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Wed Sep 17 15:27:55 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCF303A67CF; Wed, 17 Sep 2008 15:27:55 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AEC3A67CF for ; Wed, 17 Sep 2008 15:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-iR0UWR1VAg for ; Wed, 17 Sep 2008 15:27:53 -0700 (PDT) Received: from web84308.mail.re1.yahoo.com (web84308.mail.re1.yahoo.com [69.147.74.187]) by core3.amsl.com (Postfix) with SMTP id 50D6E3A67AB for ; Wed, 17 Sep 2008 15:27:53 -0700 (PDT) Received: (qmail 88412 invoked by uid 60001); 17 Sep 2008 22:28:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=njHgnLYf5wiZwJOtJDVyqfE/gduuRG8mePLfa+kItAPcPVSX3H3fWR5j13C2aS+zbgJIXzRT/5k5lywcILeGzljff7asiqYIz2D8Jd5yp9FS9FnlQD41679qPt3ctGxpt899nK4YQTfbqQIUsophQ7Qrj3YXkg3NKpY/KijWGgM=; X-YMail-OSG: 6Wyp9FMVM1nD_EBXqp9tFvoH1O1BHJxhjKsX8sudBR08VsuIyIrHNIg4Fe4FAUuX_DiOrN90BT4pyNx6gGAOL99B03.571Oaj5B69I7ZemQWacXtVDo4UD93.vL02M_00aw- Received: from [206.16.17.212] by web84308.mail.re1.yahoo.com via HTTP; Wed, 17 Sep 2008 15:28:06 PDT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Wed, 17 Sep 2008 15:28:06 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <562169.88370.qm@web84308.mail.re1.yahoo.com> Subject: [multimob] Comments on draft-deng-multimob-pmip6-requirement-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799031307==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0799031307== Content-Type: multipart/alternative; boundary="0-506485687-1221690486=:88370" --0-506485687-1221690486=:88370 Content-Type: text/plain; charset=us-ascii Hi all, I read the draft. Here are my comments (mostly editorial): - RFC2119 is not referenced - SHALL in R7 and R9 should probably be changed to MUST as they have the same meaning according to RFC 2119. - In Sec. 4.2 you say: It is foreseeable that the MAG has to act as a multicast designated router. Hence support of MLDv2 [RFC3810] is required at the MAG. possibly change is required to MAY be required. Discuss more of these choices of support at MAG or at LMA? - Section 5. change protect mobile multicast multicast network to protect mobile multicast network. Regards, Behcet --0-506485687-1221690486=:88370 Content-Type: text/html; charset=us-ascii

Hi all,
I read the draft. Here are my comments (mostly editorial):
- RFC2119 is not referenced
- SHALL in R7 and R9 should probably be changed to MUST as they have the same meaning according to RFC 2119.
- In Sec. 4.2 you say:
It is foreseeable that the MAG has to act as a multicast designated
router. Hence support of MLDv2 [RFC3810] is required at the MAG.

possibly change is required to MAY be required.

Discuss more of these choices of support at MAG or at LMA?
- Section 5. change
protect mobile multicast multicast network
to protect mobile multicast network.

Regards,

Behcet

--0-506485687-1221690486=:88370-- --===============0799031307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0799031307==-- From multimob-bounces@ietf.org Wed Sep 17 20:10:26 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19A13A68F8; Wed, 17 Sep 2008 20:10:26 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 442723A6833 for ; Wed, 17 Sep 2008 20:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.204 X-Spam-Level: ** X-Spam-Status: No, score=2.204 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PUkJ6xZGLMP for ; Wed, 17 Sep 2008 20:10:23 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id A35493A6808 for ; Wed, 17 Sep 2008 20:10:23 -0700 (PDT) Received: from localhost (dhcp-143-254.sfc.wide.ad.jp [203.178.143.254]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 1DFEE13D03D6; Thu, 18 Sep 2008 11:54:16 +0900 (JST) Date: Thu, 18 Sep 2008 12:10:35 +0900 (JST) Message-Id: <20080918.121035.152801443.asaeda@sfc.wide.ad.jp> To: schmidt@fhtw-berlin.de From: Hitoshi Asaeda In-Reply-To: <3991.193.63.130.65.1221664954.squirrel@webmail.fhtw-berlin.de> References: <1d38a3350809162356t306a2135pc9f9814a29da300b@mail.gmail.com> <20080917.232333.106764775.asaeda@sfc.wide.ad.jp> <3991.193.63.130.65.1221664954.squirrel@webmail.fhtw-berlin.de> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi, > >> > 1. 3.1 > >> > "R1 - PMIPv6 multicast mobility management MUST transparently > >> support > >> > the reception of ASM and SSM channels." > >> > Why MUST? It's too strong assumption. Some SPs may want to support > >> > only SSM. In my sense, SSM is MUST, ASM is MAY. > >> ==> if I replace "and" by "or", does it remove your concern? > > > > No, not really. ASM and SSM are independent. > > In fact, I'd rather simply say, "SSM must be supported in PMIPv6 > > multicast." > > > > ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and > currently we see an IPTV deployment on the basis of ASM (SSM strength is > interdomain transparency, which is not needed nor desired in > provider-bound IPTV offers). It is not feasible. I strongly disagree the sentense, "ASM is MUST". > Anyway, the multicast flavor to actually deploy is the choice of any > individual provider ... but we want to define protocols (multicast > extensions to PMIPv6), which enable such deployment. Therefore we should > offer both multicast flavors and preserve the choice. This is not the reason, ASM is MUST. If you prefer the filexible choice, we should not say anything about ASM and SSM. > Also: from the client perspective, ASM is easier to implement. Since we > are not heading to re-define multicast core routing (I suppose), we don't > have to worry about ASM-specific problems in the inter-domain. That we can > leave to the providers ... and to the work of the multicast routing WGs. Obviously it is not always true; ASM is easier to implement. I cannot agree above statements. The possible solution is to not mention if ASM is required or not in this draft. Well, I can slightly think such discussion is not necessary in this draft. But if some requirement discussed in this draft relates to the multicast communication model and needs to mention ASM, then I do recommend to remove "ASM is MUST" and use weaker sentence. > >> > 3. 4.2 > >> > "Hence support of MLDv2 [RFC3810] is required at the MAG." > >> > I prefer to say, "MLDv2 or LW-MLDv2 is required". This document > >> > only discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not > >> > needed? > >> ==> fine, thanks > > > > Since this document only discusses ipv6, so only saying MLDv2 and > > LW-MLDv2 is fine. > > There have been earlier (striking) arguments by Patrick to keep the MLD > debate(s) out of this document. The issue here is the version 2, which is > needed for SSM. Otherwise I would agree with Patrick to remain agnostic of > MLD flavors and optimizations. I've not started MLD discussion in this draft. It is out of scope of this doc. My concern is that the sentence, "MLDv2 is required", seems to imply full functions defined in MLDv2 will be required. It is not true. The point we want to imply here is that this draft requires the capability of SSM by saying "MLDv2 is required". Therefore "MLDv2 or LW-MLDv2 is required" makes better sense. Regards, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Thu Sep 18 02:00:06 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB723A6899; Thu, 18 Sep 2008 02:00:06 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9555F3A6970 for ; Thu, 18 Sep 2008 02:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SzHINF7Z9g1 for ; Thu, 18 Sep 2008 02:00:03 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 25A5E3A68D5 for ; Thu, 18 Sep 2008 02:00:02 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id q7so649581uge.15 for ; Thu, 18 Sep 2008 02:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=EeY7F+CPTfwg8F78Nwy3YI6Mh0f064kiizZDvwBQ/Gw=; b=LHnrUBxS6HNJlufUnVMOAUW6K7jKNbCWRE3wfc9h4iAXLxQLD0lbe7tBwrwboktRD2 HYNXpRg5NrJPhY5qgTnfHK+VvnoMtjP0myjWyFdiP5y3ZX3MjMAomXNP8ydKjymZsvHu i8ygBgn+PpKimuyvCVzGMx/mLJyfXBnwsv9ns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=coiJo4qqQCqt+NTpVh48qBIvK2nnP4Lf/TtcjdGNS1qbKfRZaXaifEpQB3FU4gcnXR t1o2GRsxJ5iS3w0dXCt4Ru/2xA44BzkVOkpDpvMlqBFBEHWacDVn5AtGLMrkBQqiJbOI 4wTVlrgQ3kLSzxVITVuoFTWBIcda3nBFfKzlg= Received: by 10.210.65.2 with SMTP id n2mr3098073eba.19.1221728414217; Thu, 18 Sep 2008 02:00:14 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Thu, 18 Sep 2008 02:00:14 -0700 (PDT) Message-ID: <1d38a3350809180200ld01ee42qeef9ff575f0ec45d@mail.gmail.com> Date: Thu, 18 Sep 2008 17:00:14 +0800 From: "Hui Deng" To: "Behcet Sarikaya" In-Reply-To: <562169.88370.qm@web84308.mail.re1.yahoo.com> MIME-Version: 1.0 References: <562169.88370.qm@web84308.mail.re1.yahoo.com> Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-00 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0895416695==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============0895416695== Content-Type: multipart/alternative; boundary="----=_Part_18587_30166317.1221728414209" ------=_Part_18587_30166317.1221728414209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline done, updated in the next version. thanks -Hui 2008/9/18 Behcet Sarikaya > Hi all, > I read the draft. Here are my comments (mostly editorial): > - RFC2119 is not referenced > - SHALL in R7 and R9 should probably be changed to MUST as they have the > same meaning according to RFC 2119. > - In Sec. 4.2 you say: > It is foreseeable that the MAG has to act as a multicast designated > router. Hence support of MLDv2 [RFC3810] is required at the MAG. > > possibly change is required to MAY be required. > > Discuss more of these choices of support at MAG or at LMA? > - Section 5. change > protect mobile multicast multicast network > to protect mobile multicast network. > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > > ------=_Part_18587_30166317.1221728414209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

done,

updated in the next version.

thanks

-Hui

2008/9/18 Behcet Sarikaya <behcetsarikaya@yahoo.com>

Hi all,
I read the draft. Here are my comments (mostly editorial):
- RFC2119 is not referenced
- SHALL in R7 and R9 should probably be changed to MUST as they have the same meaning according to RFC 2119.
- In Sec. 4.2 you say:
It is foreseeable that the MAG has to act as a multicast designated
router. Hence support of MLDv2 [RFC3810] is required at the MAG.

possibly change is required to MAY be required.

Discuss more of these choices of support at MAG or at LMA?
- Section 5. change
protect mobile multicast multicast network
to protect mobile multicast network.

Regards,

Behcet

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

------=_Part_18587_30166317.1221728414209-- --===============0895416695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0895416695==-- From multimob-bounces@ietf.org Thu Sep 18 02:21:26 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F98328C3AF; Thu, 18 Sep 2008 02:21:26 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C4D3A67E1 for ; Thu, 18 Sep 2008 02:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d2CKgb076Nx for ; Thu, 18 Sep 2008 02:21:20 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 40C1C3A69A3 for ; Thu, 18 Sep 2008 02:21:20 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 11:21:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 11:21:26 +0200 Message-ID: In-Reply-To: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] PMIPv6 Requirements Draft Updated Thread-Index: AckY2YfBSAGg7OioT7C8MfkM/Wn0TgAldtgA References: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> From: To: , X-OriginalArrivalTime: 18 Sep 2008 09:21:29.0153 (UTC) FILETIME=[EE944B10:01C9196F] Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Thomas and Hitoshi, I see your concern about section 4, so I suggest the following rewording: ------------------------------------------ 4. Architecture requirements Deployment of mobile multicast services for listeners, e.g. Mobile IPTV,= may lead to operational requirements which MAY impact PMIPv6 architectural= entities. These potential features are sketched in the following and may c= ome in addition to protocol requirements, as listed in the preceding sectio= n: - Multicast Bandwidth Control: the system should be able to control the = total bandwidth of a user port that can be used for multicast service, thereby monitoring the fraction of the total bandwidth consumed by multicast. This requirement may lead for the LMA to support a range of = different service classes with various QoS requirements. = - Multicast session control: AAA functions, which may reside at the LMA,= in particular admission control and accounting, SHOULD be preserved and ap= plicable under multicast services. - Connection Admission Control (CAC): it is an operational requirement t= hat Connection Admission Control should be based on available resources. T= his feature may be supported at the MAG. - Network Attachment Control: the attachment control should be supported by a multicast control function and multicast replication function. - Considering deployment, it is foreseeable that the MAG MAY act as a multi= cast designated router. Hence support of MLDv2 [RFC3810] MAY be required a= t the MAG. -------------------------------------- What do you think? Regards, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la > part de Thomas C. Schmidt > Envoy=E9=A0: mercredi 17 septembre 2008 17:24 > =C0=A0: Hitoshi Asaeda > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] PMIPv6 Requirements Draft Updated > = > Hi Hitoshi et al, > = > I would like to take some counter positions: > = > Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda: > >> > 1. 3.1 > >> > "R1 - PMIPv6 multicast mobility management MUST transparently > >> support > >> > the reception of ASM and SSM channels." > >> > Why MUST? It's too strong assumption. Some SPs may want to support > only SSM. In my sense, SSM is MUST, ASM is MAY. > >> =3D=3D> if I replace "and" by "or", does it remove your concern? > > > > No, not really. ASM and SSM are independent. > > In fact, I'd rather simply say, "SSM must be supported in PMIPv6 > multicast." > > > = > ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and > currently we see an IPTV deployment on the basis of ASM (SSM strength is > interdomain transparency, which is not needed nor desired in > provider-bound IPTV offers). > = > Anyway, the multicast flavor to actually deploy is the choice of any > individual provider ... but we want to define protocols (multicast > extensions to PMIPv6), which enable such deployment. Therefore we should > offer both multicast flavors and preserve the choice. > = > Also: from the client perspective, ASM is easier to implement. Since we > are not heading to re-define multicast core routing (I suppose), we don't > have to worry about ASM-specific problems in the inter-domain. That we can > leave to the providers ... and to the work of the multicast routing WGs. > = > = > >> > 3. 4.2 > >> > "Hence support of MLDv2 [RFC3810] is required at the MAG." I > prefer to say, "MLDv2 or LW-MLDv2 is required". This document only > discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not needed? > >> =3D=3D> fine, thanks > > > > Since this document only discusses ipv6, so only saying MLDv2 and > LW-MLDv2 is fine. > > > = > There have been earlier (striking) arguments by Patrick to keep the MLD > debate(s) out of this document. The issue here is the version 2, which is > needed for SSM. Otherwise I would agree with Patrick to remain agnostic of > MLD flavors and optimizations. > = > = > >> > CAC is common word except with ATM? :) > >> =3D=3D> Sure, but prefer remove "CAC", keep "Connection Admission Cont= rol" > >> > >> > Anyway, we should put more functional statements; what functions > are needed, and why. > >> =3D=3D> Please try to propose it, thanks, > > > > Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA > should be preserved at LMA". > > Sect.4.2 says "CAC is supported at MAG, Network Attachment Control > should be supported at MAG". > > > > In my feeling, the current statements require implementing these > functions in multicast protocols used in PMIPv6. > > At first, these statements should be explained from operators > > viewpoint. Not "LMA should control bw, MAG supports CAC", but > > "Controlling bw is an operational requirement and may be implemented at > LMA". Then improve the whole sentence. (What are other operators' > requirement and why.) > = > Here I agree with Hitoshi: The whole section 4 is problematic, if it is > taken to be more than a general Caveat of the type "Here are things we > also should consider". > = > May be it should be rephrased as "General Architectural Background", or s= o. > = > Best regards, > = > Thomas > = > -- > = > =B0 Prof. Dr. Thomas C. Schmidt > =B0 HAW Hamburg, Dept. Informatik > =B0 University of Applied Sciences > =B0 Berliner Tor 7, D 20099 Hamburg, Germany > =B0 Fon: +49-40-42875-8452, Fax: -8409 > =B0 http://www.informatik.haw-hamburg.de/~schmidt > = > = > = > = > = > _______________________________________________ > 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 From multimob-bounces@ietf.org Thu Sep 18 02:50:31 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B6E28C3D9; Thu, 18 Sep 2008 02:50:31 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0441B28C3D9 for ; Thu, 18 Sep 2008 02:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jLqmalh9UoS for ; Thu, 18 Sep 2008 02:50:29 -0700 (PDT) Received: from mail2.rz.fhtw-berlin.de (mail2.rz.fhtw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 972E73A6765 for ; Thu, 18 Sep 2008 02:50:29 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from sirius.rz.fhtw-berlin.de ([141.45.7.43] helo=webmail.fhtw-berlin.de) by mail2.rz.fhtw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1KgG9q-000AfM-NP; Thu, 18 Sep 2008 11:50:42 +0200 Received: from 193.63.130.66 (SquirrelMail authenticated user tschmidt) by webmail.fhtw-berlin.de with HTTP; Thu, 18 Sep 2008 11:50:42 +0200 (CEST) Message-ID: <4217.193.63.130.66.1221731442.squirrel@webmail.fhtw-berlin.de> In-Reply-To: References: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> Date: Thu, 18 Sep 2008 11:50:42 +0200 (CEST) From: "Thomas C. Schmidt" To: pierrick.seite@orange-ftgroup.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Pierrick, thanks for the proposal: I'm fine with your formulation! Best regards, Thomas Am Do, 18.09.2008, 11:21, schrieb pierrick.seite@orange-ftgroup.com: > Hi Thomas and Hitoshi, > > I see your concern about section 4, so I suggest the following rewording: > > > ------------------------------------------ > > > 4. Architecture requirements > > Deployment of mobile multicast services for listeners, e.g. Mobile > IPTV, may lead to operational requirements which MAY impact PMIPv6 > architectural entities. These potential features are sketched in the > following and may come in addition to protocol requirements, as listed > in the preceding section: > > - Multicast Bandwidth Control: the system should be able to control the > total bandwidth of a user port that can be used for multicast service, > thereby monitoring the fraction of the total bandwidth consumed by > multicast. This requirement may lead for the LMA to support a range of > different service classes with various QoS requirements. > > - Multicast session control: AAA functions, which may reside at the > LMA, in particular admission control and accounting, SHOULD be > preserved and applicable under multicast services. > > - Connection Admission Control (CAC): it is an operational requirement > that Connection Admission Control should be based on available > resources. This feature may be supported at the MAG. > > - Network Attachment Control: the attachment control should be > supported by a multicast control function and multicast replication > function. > > - Considering deployment, it is foreseeable that the MAG MAY act as a > multicast designated router. Hence support of MLDv2 [RFC3810] MAY be > required at the MAG. > > -------------------------------------- > > What do you think? > > Regards, > Pierrick > >> -----Message d'origine----- >> De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la >> part de Thomas C. Schmidt >> Envoy=E9=A0: mercredi 17 septembre 2008 17:24 >> =C0=A0: Hitoshi Asaeda >> Cc=A0: multimob@ietf.org >> Objet=A0: Re: [multimob] PMIPv6 Requirements Draft Updated >> >> Hi Hitoshi et al, >> >> I would like to take some counter positions: >> >> Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda: >> >> > 1. 3.1 >> >> > "R1 - PMIPv6 multicast mobility management MUST transparently >> >> support >> >> > the reception of ASM and SSM channels." >> >> > Why MUST? It's too strong assumption. Some SPs may want to >> support >> only SSM. In my sense, SSM is MUST, ASM is MAY. >> >> =3D=3D> if I replace "and" by "or", does it remove your concern? >> > >> > No, not really. ASM and SSM are independent. >> > In fact, I'd rather simply say, "SSM must be supported in PMIPv6 >> multicast." >> > >> >> ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and >> currently we see an IPTV deployment on the basis of ASM (SSM strength >> is >> interdomain transparency, which is not needed nor desired in >> provider-bound IPTV offers). >> >> Anyway, the multicast flavor to actually deploy is the choice of any >> individual provider ... but we want to define protocols (multicast >> extensions to PMIPv6), which enable such deployment. Therefore we should >> offer both multicast flavors and preserve the choice. >> >> Also: from the client perspective, ASM is easier to implement. Since we >> are not heading to re-define multicast core routing (I suppose), we >> don't >> have to worry about ASM-specific problems in the inter-domain. That we >> can >> leave to the providers ... and to the work of the multicast routing WGs. >> >> >> >> > 3. 4.2 >> >> > "Hence support of MLDv2 [RFC3810] is required at the MAG." I >> prefer to say, "MLDv2 or LW-MLDv2 is required". This document only >> discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not needed? >> >> =3D=3D> fine, thanks >> > >> > Since this document only discusses ipv6, so only saying MLDv2 and >> LW-MLDv2 is fine. >> > >> >> There have been earlier (striking) arguments by Patrick to keep the MLD >> debate(s) out of this document. The issue here is the version 2, which >> is >> needed for SSM. Otherwise I would agree with Patrick to remain agnostic >> of >> MLD flavors and optimizations. >> >> >> >> > CAC is common word except with ATM? :) >> >> =3D=3D> Sure, but prefer remove "CAC", keep "Connection Admission >> Control" >> >> >> >> > Anyway, we should put more functional statements; what functions >> are needed, and why. >> >> =3D=3D> Please try to propose it, thanks, >> > >> > Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA >> should be preserved at LMA". >> > Sect.4.2 says "CAC is supported at MAG, Network Attachment Control >> should be supported at MAG". >> > >> > In my feeling, the current statements require implementing these >> functions in multicast protocols used in PMIPv6. >> > At first, these statements should be explained from operators >> > viewpoint. Not "LMA should control bw, MAG supports CAC", but >> > "Controlling bw is an operational requirement and may be implemented >> at >> LMA". Then improve the whole sentence. (What are other operators' >> requirement and why.) >> >> Here I agree with Hitoshi: The whole section 4 is problematic, if it is >> taken to be more than a general Caveat of the type "Here are things we >> also should consider". >> >> May be it should be rephrased as "General Architectural Background", or >> so. >> >> Best regards, >> >> Thomas >> >> -- >> >> =B0 Prof. Dr. Thomas C. Schmidt >> =B0 HAW Hamburg, Dept. Informatik >> =B0 University of Applied Sciences >> =B0 Berliner Tor 7, D 20099 Hamburg, Germany >> =B0 Fon: +49-40-42875-8452, Fax: -8409 >> =B0 http://www.informatik.haw-hamburg.de/~schmidt >> >> >> >> >> >> _______________________________________________ >> 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 From multimob-bounces@ietf.org Thu Sep 18 08:13:51 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32903A6B32; Thu, 18 Sep 2008 08:13:51 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1933A6999 for ; Thu, 18 Sep 2008 08:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.957 X-Spam-Level: **** X-Spam-Status: No, score=4.957 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_BAD_ID=2.837, RELAY_IS_220=2.118] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ww2MBVztnJa9 for ; Thu, 18 Sep 2008 08:13:49 -0700 (PDT) Received: from m12-11.163.com (m12-11.163.com [220.181.12.11]) by core3.amsl.com (Postfix) with SMTP id 902993A6947 for ; Thu, 18 Sep 2008 08:13:46 -0700 (PDT) Received: from sunguan (unknown [218.249.29.234]) by smtp7 (Coremail) with SMTP id C8CowLDb1d4xcNJI4MDJYA==.39272S2; Thu, 18 Sep 2008 23:13:53 +0800 (CST) Date: Thu, 18 Sep 2008 23:13:10 +0800 From: "guanjian8632" To: "multimob" Message-ID: <200809182313101876630@163.com> X-mailer: Foxmail 6, 10, 201, 22 [cn] Mime-Version: 1.0 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUUYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUj-kYjsxI4VWUJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1I0E4x80 FVCIwcAKzIAtM7C26IkvcIIF6IxKo4kEV4yl1IIY67AEw4v_Jr0_Jr4lnxkEFVAIw20F6c xK64vIFxWl5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE 14v26F4j6r4UJwAC62BYpTIE1TZKA3svLVAKvSnIqfZI6r4lFVCF04k20xvEw2I207IF0w CjxxvEw4Wlc2IjII80xcxEwVWxJVW3JwCF72vE52k0Y41lx4CE17CEb7AF67AKxVWUJVWU XwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMs8CjcxG 0xvEn4CqF7xvrbIYCTnIWIevJa73UjIFyTuYvjTRgyCWUUUUU Subject: [multimob] One PMIPv6 multicast solution X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1959641644==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============1959641644== Content-Type: multipart/alternative; boundary="=====003_Dragon247374224171_=====" This is a multi-part message in MIME format. --=====003_Dragon247374224171_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hello everyone We have submitted a initial draft about the PMIPv6 multicast. A URL for this Internet-Draft is: http://tools.ietf.org/html/draft-zhang-netlmm-pmipv6-mcast-00 Welcome the comments. :-) Tony Beijing Jiaotong University, NGIRC 2008-09-18 guanjian8632 --=====003_Dragon247374224171_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit

Hello everyone

We have submitted a initial draft about the PMIPv6 multicast.

A URL for this Internet-Draft is:

http://tools.ietf.org/html/draft-zhang-netlmm-pmipv6-mcast-00

Welcome the comments. :-)

Tony

Beijing Jiaotong University, NGIRC

2008-09-18

guanjian8632

--=====003_Dragon247374224171_=====-- --===============1959641644== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1959641644==-- From multimob-bounces@ietf.org Thu Sep 18 09:49:17 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00173A6E40; Thu, 18 Sep 2008 09:49:17 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AADB3A6B96 for ; Thu, 18 Sep 2008 09:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E-Gnm0f4U5i for ; Thu, 18 Sep 2008 09:49:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AD1DA3A69B4 for ; Thu, 18 Sep 2008 09:49:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,422,1217808000"; d="scan'208,217";a="79508660" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 18 Sep 2008 16:49:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m8IGnEEW020670; Thu, 18 Sep 2008 09:49:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8IGnESg029538; Thu, 18 Sep 2008 16:49:14 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 09:49:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 09:49:13 -0700 Message-ID: <47951CBFA6409B4C8916514FCB05BFBE2A6BA3@xmb-sjc-219.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] PMIPv6 Requirements Draft Updated Thread-Index: AckY2YfBSAGg7OioT7C8MfkM/Wn0TgAldtgAAA/F7TA= From: "Mike McBride (mmcbride)" To: , , X-OriginalArrivalTime: 18 Sep 2008 16:49:13.0670 (UTC) FILETIME=[7B144660:01C919AE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15079; t=1221756554; x=1222620554; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:=20=22Mike=20McBride=20(mmcbride)=22=20 |Subject:=20Re=3A=20[multimob]=20PMIPv6=20Requirements=20Dr aft=20Updated |Sender:=20; bh=t9A/agudt4sUWS2fiCwPJ1A3s0cmU7g1wMJhinaZYuM=; b=jqF7rx/kt8F8fayKS0TM63AJ4mIF/YuC4tpPwUKDBJFwCm4HzDmUEmWqwR G6MyWsbQC3YZdNoAsxjeIkCijff3BDJZizHe8Pmz5iDuQ9L4croICX029AWh azfp+EYHzN; Authentication-Results: sj-dkim-4; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0037079445==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org This is a multi-part message in MIME format. --===============0037079445== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C919AE.7AC44933" This is a multi-part message in MIME format. ------_=_NextPart_001_01C919AE.7AC44933 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That looks good.=20 Mike -----Original Message----- From: pierrick.seite@orange-ftgroup.com = [mailto:pierrick.seite@orange-ftgroup.com] Sent: Thursday, September 18, 2008 02:22 AM Pacific Standard Time To: schmidt@fhtw-berlin.de; asaeda@sfc.wide.ad.jp Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated Hi Thomas and Hitoshi, I see your concern about section 4, so I suggest the following = rewording: ------------------------------------------ 4. Architecture requirements Deployment of mobile multicast services for listeners, e.g. Mobile = IPTV, may lead to operational requirements which MAY impact PMIPv6 = architectural entities. These potential features are sketched in the = following and may come in addition to protocol requirements, as listed = in the preceding section: - Multicast Bandwidth Control: the system should be able to control = the total bandwidth of a user port that can be used for multicast = service, thereby monitoring the fraction of the total bandwidth consumed by multicast. This requirement may lead for the LMA to support a range = of different service classes with various QoS requirements.=20 - Multicast session control: AAA functions, which may reside at the = LMA, in particular admission control and accounting, SHOULD be preserved = and applicable under multicast services. - Connection Admission Control (CAC): it is an operational = requirement that Connection Admission Control should be based on = available resources. This feature may be supported at the MAG. - Network Attachment Control: the attachment control should be supported by a multicast control function and multicast replication function. - Considering deployment, it is foreseeable that the MAG MAY act as a = multicast designated router. Hence support of MLDv2 [RFC3810] MAY be = required at the MAG. -------------------------------------- What do you think? Regards, Pierrick > -----Message d'origine----- > De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De = la > part de Thomas C. Schmidt > Envoy=E9=A0: mercredi 17 septembre 2008 17:24 > =C0=A0: Hitoshi Asaeda > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] PMIPv6 Requirements Draft Updated >=20 > Hi Hitoshi et al, >=20 > I would like to take some counter positions: >=20 > Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda: > >> > 1. 3.1 > >> > "R1 - PMIPv6 multicast mobility management MUST transparently > >> support > >> > the reception of ASM and SSM channels." > >> > Why MUST? It's too strong assumption. Some SPs may want to = support > only SSM. In my sense, SSM is MUST, ASM is MAY. > >> =3D=3D> if I replace "and" by "or", does it remove your concern? > > > > No, not really. ASM and SSM are independent. > > In fact, I'd rather simply say, "SSM must be supported in PMIPv6 > multicast." > > >=20 > ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... and > currently we see an IPTV deployment on the basis of ASM (SSM strength = is > interdomain transparency, which is not needed nor desired in > provider-bound IPTV offers). >=20 > Anyway, the multicast flavor to actually deploy is the choice of any > individual provider ... but we want to define protocols (multicast > extensions to PMIPv6), which enable such deployment. Therefore we = should > offer both multicast flavors and preserve the choice. >=20 > Also: from the client perspective, ASM is easier to implement. Since = we > are not heading to re-define multicast core routing (I suppose), we = don't > have to worry about ASM-specific problems in the inter-domain. That we = can > leave to the providers ... and to the work of the multicast routing = WGs. >=20 >=20 > >> > 3. 4.2 > >> > "Hence support of MLDv2 [RFC3810] is required at the MAG." I > prefer to say, "MLDv2 or LW-MLDv2 is required". This document only > discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not needed? > >> =3D=3D> fine, thanks > > > > Since this document only discusses ipv6, so only saying MLDv2 and > LW-MLDv2 is fine. > > >=20 > There have been earlier (striking) arguments by Patrick to keep the = MLD > debate(s) out of this document. The issue here is the version 2, which = is > needed for SSM. Otherwise I would agree with Patrick to remain = agnostic of > MLD flavors and optimizations. >=20 >=20 > >> > CAC is common word except with ATM? :) > >> =3D=3D> Sure, but prefer remove "CAC", keep "Connection Admission = Control" > >> > >> > Anyway, we should put more functional statements; what = functions > are needed, and why. > >> =3D=3D> Please try to propose it, thanks, > > > > Sect.4.1 says "LMA should be able to control bw and monitor bw. AAA > should be preserved at LMA". > > Sect.4.2 says "CAC is supported at MAG, Network Attachment Control > should be supported at MAG". > > > > In my feeling, the current statements require implementing these > functions in multicast protocols used in PMIPv6. > > At first, these statements should be explained from operators > > viewpoint. Not "LMA should control bw, MAG supports CAC", but > > "Controlling bw is an operational requirement and may be implemented = at > LMA". Then improve the whole sentence. (What are other operators' > requirement and why.) >=20 > Here I agree with Hitoshi: The whole section 4 is problematic, if it = is > taken to be more than a general Caveat of the type "Here are things we > also should consider". >=20 > May be it should be rephrased as "General Architectural Background", = or so. >=20 > Best regards, >=20 > Thomas >=20 > -- >=20 > =B0 Prof. Dr. Thomas C. Schmidt > =B0 HAW Hamburg, Dept. Informatik > =B0 University of Applied Sciences > =B0 Berliner Tor 7, D 20099 Hamburg, Germany > =B0 Fon: +49-40-42875-8452, Fax: -8409 > =B0 http://www.informatik.haw-hamburg.de/~schmidt >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 ------_=_NextPart_001_01C919AE.7AC44933 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [multimob] PMIPv6 Requirements Draft Updated

That looks good.
Mike

-----Original Message-----
From: pierrick.seite@orange-ftgroup.com [mailto:pierrick.seite@o= range-ftgroup.com]
Sent:   Thursday, September 18, 2008 02:22 AM Pacific Standard = Time
To:     schmidt@fhtw-berlin.de; = asaeda@sfc.wide.ad.jp
Cc:     multimob@ietf.org
Subject:        Re: [multimob] PMIPv6 = Requirements Draft Updated

Hi Thomas and Hitoshi,

I see your concern about section 4, so I suggest the following = rewording:

------------------------------------------

4. Architecture requirements

   Deployment of mobile multicast services for listeners, e.g. = Mobile IPTV, may lead to operational requirements which MAY impact = PMIPv6 architectural entities. These potential features are sketched in = the following and may come in addition to protocol requirements, as = listed in the preceding section:

   - Multicast Bandwidth Control: the system should be able to = control the total bandwidth of a user port that can be used for = multicast service,
   thereby monitoring the fraction of the total bandwidth = consumed by
   multicast. This requirement may lead for the LMA to = support a range of different service classes with various QoS = requirements.

   - Multicast session control: AAA functions, which may = reside at the LMA, in particular admission control and accounting, = SHOULD be preserved and applicable under multicast services.

   - Connection Admission Control (CAC): it is an operational = requirement that Connection Admission Control should be based on = available resources. This feature may be supported at the MAG.

   - Network Attachment Control: the attachment control should = be
   supported by a multicast control function and multicast = replication
   function.

- Considering deployment, it is foreseeable that the MAG MAY act as a = multicast designated router. Hence support of MLDv2 [RFC3810] MAY = be required at the MAG.

--------------------------------------

What do you think?

Regards,
Pierrick

> -----Message d'origine-----
> De=A0: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.or= g] De la
> part de Thomas C. Schmidt
> Envoy=E9=A0: mercredi 17 septembre 2008 17:24
> =C0=A0: Hitoshi Asaeda
> Cc=A0: multimob@ietf.org
> Objet=A0: Re: [multimob] PMIPv6 Requirements Draft Updated
>
> Hi Hitoshi et al,
>
> I would like to take some counter positions:
>
> Am Mi, 17.09.2008, 16:23, schrieb Hitoshi Asaeda:
> >> > 1. 3.1
> >> >    "R1 - PMIPv6 multicast = mobility management MUST transparently
> >> support
> >> >    the reception of ASM and SSM = channels."
> >> >    Why MUST? It's too strong = assumption. Some SPs may want to support
> only SSM. In my sense, SSM is MUST, ASM is MAY.
> >> =3D=3D> if I replace "and" by "or", = does it remove your concern?
> >
> > No, not really. ASM and SSM are independent.
> > In fact, I'd rather simply say, "SSM must be supported in = PMIPv6
> multicast."
> >
>
> ASM & SSM are not completely independent (MLD, PIM-(S)SM) ... = and
> currently we see an IPTV deployment on the basis of ASM (SSM = strength is
> interdomain transparency, which is not needed nor desired in
> provider-bound IPTV offers).
>
> Anyway, the multicast flavor to actually deploy is the choice of = any
> individual provider ... but we want to define protocols = (multicast
> extensions to PMIPv6), which enable such deployment. Therefore we = should
> offer both multicast flavors and preserve the choice.
>
> Also: from the client perspective, ASM is easier to implement. = Since we
> are not heading to re-define multicast core routing (I suppose), we = don't
> have to worry about ASM-specific problems in the inter-domain. That = we can
> leave to the providers ... and to the work of the multicast routing = WGs.
>
>
> >> > 3. 4.2
> >> >    "Hence support of MLDv2 = [RFC3810] is required at the MAG." I
> prefer to say, "MLDv2 or LW-MLDv2 is required". This = document only
> discusses IPv6? Mentioning "IGMPv3 and LW-IGMPv3" is not = needed?
> >> =3D=3D> fine, thanks
> >
> > Since this document only discusses ipv6, so only saying MLDv2 = and
> LW-MLDv2 is fine.
> >
>
> There have been earlier (striking) arguments by Patrick to keep the = MLD
> debate(s) out of this document. The issue here is the version 2, = which is
> needed for SSM. Otherwise I would agree with Patrick to remain = agnostic of
> MLD flavors and optimizations.
>
>
> >> >    CAC is common word except with ATM? = :)
> >> =3D=3D> Sure, but prefer remove "CAC", keep = "Connection Admission Control"
> >>
> >> >    Anyway, we should put more = functional statements; what functions
> are needed, and why.
> >> =3D=3D> Please try to propose it, thanks,
> >
> > Sect.4.1 says "LMA should be able to control bw and = monitor bw. AAA
> should be preserved at LMA".
> > Sect.4.2 says "CAC is supported at MAG, Network = Attachment Control
> should be supported at MAG".
> >
> > In my feeling, the current statements require implementing = these
> functions in multicast protocols used in PMIPv6.
> > At first, these statements should be explained from = operators
> > viewpoint. Not "LMA should control bw, MAG supports = CAC", but
> > "Controlling bw is an operational requirement and may be = implemented at
> LMA". Then improve the whole sentence. (What are other = operators'
> requirement and why.)
>
> Here I agree with Hitoshi: The whole section 4 is problematic, if = it is
> taken to be more than a general Caveat of the type "Here are = things we
> also should consider".
>
> May be it should be rephrased as "General Architectural = Background", or so.
>
> Best regards,
>
> Thomas
>
> --
>
> =B0 Prof. Dr. Thomas C. Schmidt
> =B0 HAW Hamburg, Dept. Informatik
> =B0 University of Applied Sciences
> =B0 Berliner Tor 7, D 20099 Hamburg, Germany
> =B0 Fon: +49-40-42875-8452, Fax: -8409
> =B0 http://www.informa= tik.haw-hamburg.de/~schmidt
>
>
>
>
>
> _______________________________________________
> 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

------_=_NextPart_001_01C919AE.7AC44933-- --===============0037079445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============0037079445==-- From multimob-bounces@ietf.org Thu Sep 18 20:58:51 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDB73A6918; Thu, 18 Sep 2008 20:58:51 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0CB3A69B7 for ; Thu, 18 Sep 2008 20:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.554 X-Spam-Level: * X-Spam-Status: No, score=1.554 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fweaESEWAiU1 for ; Thu, 18 Sep 2008 20:58:49 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 7CF813A689F for ; Thu, 18 Sep 2008 20:58:49 -0700 (PDT) Received: from localhost (dhcp-143-254.sfc.wide.ad.jp [203.178.143.254]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 3F11F13D03D6; Fri, 19 Sep 2008 12:42:34 +0900 (JST) Date: Fri, 19 Sep 2008 12:59:02 +0900 (JST) Message-Id: <20080919.125902.250136943.asaeda@sfc.wide.ad.jp> To: pierrick.seite@orange-ftgroup.com From: Hitoshi Asaeda In-Reply-To: References: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Pierrick, Looks better now. Thanks. Several small comments below. > 4. Architecture requirements > > Deployment of mobile multicast services for listeners, > e.g. Mobile IPTV, may lead to operational requirements which MAY > impact PMIPv6 architectural entities. These potential features are > sketched in the following and may come in addition to protocol > requirements, as listed in the preceding section: > > - Multicast Bandwidth Control: the system should be able to > control the total bandwidth of a user port that can be used for > multicast service, > thereby monitoring the fraction of the total bandwidth consumed by > multicast. This requirement may lead for the LMA to support a > range of different service classes with various QoS requirements. > > - Multicast session control: AAA functions, which may reside at > the LMA, in particular admission control and accounting, SHOULD be > preserved and applicable under multicast services. This is not "multicast session control", which includes many general meanings. "AAA functions" is straightforward for your statement. > - Connection Admission Control (CAC): it is an operational > requirement that Connection Admission Control should be based on > available resources. This feature may be supported at the MAG. I don't recommend to use the word "CAC". As I said, it may not be a common term except with ATM, no? And the statement is a little ambiguous. What function do you require? > - Network Attachment Control: the attachment control should be > supported by a multicast control function and multicast replication > function. This is also a bit ambiguous. Multicast control means traffic control? Quality control? What information is needed for what? And what does multicast replication mean? > - Considering deployment, it is foreseeable that the MAG MAY act as > a multicast designated router. Hence support of MLDv2 [RFC3810] MAY > be required at the MAG. As I said, I perfer to also say "or LW-MLDv2" with MLDv2 here, but it's up to other members' opinions. Thanks, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Sun Sep 28 10:42:51 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 101A43A6AB7; Sun, 28 Sep 2008 10:42:51 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4626A3A68D3 for ; Sun, 28 Sep 2008 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSvBOe1dCN88 for ; Sun, 28 Sep 2008 10:42:46 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AB6B33A6B08 for ; Sun, 28 Sep 2008 10:42:42 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1A85A19870E; Sun, 28 Sep 2008 20:42:57 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id C185E1986D6; Sun, 28 Sep 2008 20:42:56 +0300 (EEST) Message-ID: <48DFC222.1000305@piuha.net> Date: Sun, 28 Sep 2008 20:42:58 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Behcet Sarikaya References: <290515.83791.qm@web84301.mail.re1.yahoo.com> In-Reply-To: <290515.83791.qm@web84301.mail.re1.yahoo.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: multimob@ietf.org Subject: Re: [multimob] Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Bechet, Thanks for the efforts in setting this up. We are discussing the approval of this BOF in the IESG and IAB on the coming Friday. I think the agenda and charter proposal look reasonable. I still need to read the new drafts. Is there anything else you or others on this list want to say about the readiness state of this effort? Did you succeed in updating the drafts as agreed in the bar BOF? Do people on the list agree with the contents of the requirements draft? Jari _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Sep 29 00:42:57 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A10128C117; Mon, 29 Sep 2008 00:42:57 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6B028C115 for ; Mon, 29 Sep 2008 00:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY58UXqsJpYY for ; Mon, 29 Sep 2008 00:42:51 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id ED58428C110 for ; Mon, 29 Sep 2008 00:42:50 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 09:42:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 09:42:46 +0200 Message-ID: In-Reply-To: <20080919.125902.250136943.asaeda@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] PMIPv6 Requirements Draft Updated Thread-Index: AckaDBCfdC2cgUdrTcqZ8hK5D1T9iQH9+Bcg References: <3999.193.63.130.65.1221665055.squirrel@webmail.fhtw-berlin.de> <20080919.125902.250136943.asaeda@sfc.wide.ad.jp> From: To: X-OriginalArrivalTime: 29 Sep 2008 07:42:48.0154 (UTC) FILETIME=[F7EECBA0:01C92206] Cc: multimob@ietf.org Subject: Re: [multimob] PMIPv6 Requirements Draft Updated X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Hitoshi, Thanks fo the comments and sorry for the late reply, please see inline for = clarifications. Regards, Pierrick > -----Message d'origine----- > De=A0: Hitoshi Asaeda [mailto:asaeda@sfc.wide.ad.jp] > Envoy=E9=A0: vendredi 19 septembre 2008 05:59 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: multimob@ietf.org > Objet=A0: Re: [multimob] PMIPv6 Requirements Draft Updated > = > Hi Pierrick, > = > Looks better now. Thanks. > = > Several small comments below. > = > > 4. Architecture requirements > > > > Deployment of mobile multicast services for listeners, > > e.g. Mobile IPTV, may lead to operational requirements which MAY > > impact PMIPv6 architectural entities. These potential features are > > sketched in the following and may come in addition to protocol > > requirements, as listed in the preceding section: > > > > - Multicast Bandwidth Control: the system should be able to > > control the total bandwidth of a user port that can be used for > > multicast service, > > thereby monitoring the fraction of the total bandwidth consumed by > > multicast. This requirement may lead for the LMA to support a > > range of different service classes with various QoS requirements. > > > > - Multicast session control: AAA functions, which may reside at > > the LMA, in particular admission control and accounting, SHOULD be > > preserved and applicable under multicast services. > = > This is not "multicast session control", which includes many general > meanings. > "AAA functions" is straightforward for your statement. I agree, we will fix that in next release. = > = > > - Connection Admission Control (CAC): it is an operational > > requirement that Connection Admission Control should be based on > > available resources. This feature may be supported at the MAG. > = > I don't recommend to use the word "CAC". As I said, it may not be > a common term except with ATM, no? > And the statement is a little ambiguous. What function do you require? > = > > - Network Attachment Control: the attachment control should be > > supported by a multicast control function and multicast replication > > function. > = > This is also a bit ambiguous. > Multicast control means traffic control? Quality control? What > information is needed for what? > And what does multicast replication mean? > = To clarify, I would suggest to group the two above statements in a single "= access control" (or something like that) requirement. But it's typically an= operational requirement, so, it would be valuable to hear Hui's opinion be= fore modifying. = > > - Considering deployment, it is foreseeable that the MAG MAY act as > > a multicast designated router. Hence support of MLDv2 [RFC3810] MAY > > be required at the MAG. > = > As I said, I perfer to also say "or LW-MLDv2" with MLDv2 here, but > it's up to other members' opinions. > = I have no religion on that... > Thanks, > -- > Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Sep 29 09:03:34 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1643A6B3E; Mon, 29 Sep 2008 09:03:34 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4803A6B3C for ; Mon, 29 Sep 2008 09:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.412 X-Spam-Level: ** X-Spam-Status: No, score=2.412 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SARE_RECV_IP_222000=1.508] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y26l6eSzVIEi for ; Mon, 29 Sep 2008 09:03:32 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 26CCB3A695B for ; Mon, 29 Sep 2008 09:03:31 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 586BD13D03D6; Tue, 30 Sep 2008 00:45:52 +0900 (JST) Date: Tue, 30 Sep 2008 01:03:47 +0900 (JST) Message-Id: <20080930.010347.226796255.asaeda@sfc.wide.ad.jp> To: jari.arkko@piuha.net From: Hitoshi Asaeda In-Reply-To: <48DFC222.1000305@piuha.net> References: <290515.83791.qm@web84301.mail.re1.yahoo.com> <48DFC222.1000305@piuha.net> X-Mailer: Mew version 5.2.54 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hi Jari and Behcet, > Is there anything else you or others on this list want to say about > the readiness state of this effort? Did you succeed in updating the > drafts as agreed in the bar BOF? Do people on the list agree with > the contents of the requirements draft? Regarding IGMP/MLD requirement draft (draft-liu-multimob-igmp-mld-mobility-req), we will submit the revised version (-01) about one week from now. Thanks, -- Hitoshi Asaeda _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Sep 29 10:24:32 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2F73A6A05; Mon, 29 Sep 2008 10:24:32 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0933A6A05 for ; Mon, 29 Sep 2008 10:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WS7Cn2TsG5mA for ; Mon, 29 Sep 2008 10:24:30 -0700 (PDT) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by core3.amsl.com (Postfix) with ESMTP id EB9283A68E1 for ; Mon, 29 Sep 2008 10:24:29 -0700 (PDT) Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.5]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KkMTd-00053D-I9; Mon, 29 Sep 2008 19:24:05 +0200 Message-ID: <48E10F37.1030104@cs.uni-goettingen.de> Date: Mon, 29 Sep 2008 19:24:07 +0200 From: Niklas Neumann Organization: University of Goettingen User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Hitoshi Asaeda References: <290515.83791.qm@web84301.mail.re1.yahoo.com> <48DFC222.1000305@piuha.net> <20080930.010347.226796255.asaeda@sfc.wide.ad.jp> In-Reply-To: <20080930.010347.226796255.asaeda@sfc.wide.ad.jp> X-Virus-Scanned: (clean) by exiscan+sophie Cc: multimob@ietf.org Subject: Re: [multimob] Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Hey Hitoshi, looking forward to the new version. The -00 version also was quite fine and I think it is a good starting point for a solution draft. Just two small suggestions: Maybe there should be some general requirements included about the requirements that can or cannot be impose on the network-capabilities of the PMIP domain. Especially I think the question whether a solution can or cannot require native multicast support from routers between the MAGs and the LMA might be interesting. Just a thought. Also I am not certain how to interpret "R6 - PMIPv6 multicast mobility management MUST equally cover IPv6/IPv4 only and dual stack nodes." Are we considering more than IPv6 multicast, i.e. MLDv2, or am I just reading it wrong? Best regards Niklas Hitoshi Asaeda wrote: > Hi Jari and Behcet, > >> Is there anything else you or others on this list want to say about >> the readiness state of this effort? Did you succeed in updating the >> drafts as agreed in the bar BOF? Do people on the list agree with >> the contents of the requirements draft? > > Regarding IGMP/MLD requirement draft > (draft-liu-multimob-igmp-mld-mobility-req), we will submit the revised > version (-01) about one week from now. > > Thanks, > -- > Hitoshi Asaeda > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Niklas Neumann - University of Goettingen, Institute of Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/ Tel: +49 551 39-172053 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Mon Sep 29 21:36:20 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0AE28B56A; Mon, 29 Sep 2008 21:36:20 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C173A6A3C for ; Mon, 29 Sep 2008 21:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gPIGsz70Wnz for ; Mon, 29 Sep 2008 21:36:18 -0700 (PDT) Received: from pione.sfc.wide.ad.jp (pione.sfc.wide.ad.jp [203.178.143.172]) by core3.amsl.com (Postfix) with ESMTP id 3926728B56A for ; Mon, 29 Sep 2008 21:36:17 -0700 (PDT) Received: from localhost (dhcp-143-204.sfc.wide.ad.jp [203.178.143.204]) by pione.sfc.wide.ad.jp (Postfix) with ESMTP id 6CFF013D03D6; Tue, 30 Sep 2008 13:18:36 +0900 (JST) Date: Tue, 30 Sep 2008 13:36:36 +0900 (JST) Message-Id: <20080930.133636.169894029.asaeda@sfc.wide.ad.jp> To: niklas.neumann@cs.uni-goettingen.de From: Hitoshi Asaeda In-Reply-To: <48E10F37.1030104@cs.uni-goettingen.de> References: <48DFC222.1000305@piuha.net> <20080930.010347.226796255.asaeda@sfc.wide.ad.jp> <48E10F37.1030104@cs.uni-goettingen.de> X-Mailer: Mew version 6.1 on Emacs 22.2.50 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: multimob@ietf.org Subject: Re: [multimob] Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org Niklas, > Maybe there should be some general requirements included about the > requirements that can or cannot be impose on the > network-capabilities of the PMIP domain. Especially I think the > question whether a solution can or cannot require native multicast > support from routers between the MAGs and the LMA might be > interesting. Just a thought. I assume you are talking about PMIPv6 requirement draft, while I mentioned about IGMP/MLD requirement draft in the last mail. Anyway, regarding your comment, except the case of "Local Routing" (Fig.2) in section 2, I think it is not necessary to consider multicast capability of routers between MAG and LMA, because LMA and MAG establish a bi-directional tunnel directly and every traffic between MAG and LMA goes through this tunnel. In the case of "Local Routing", routers between content source and MAG must be multicast capable, or MAG needs some tunneling function to attach the multicast routing tree. But I don't know whether this discussion is required in the PMIPv6 requirement draft. Do you have any concrete thoughts? Or am I missing something? > Also I am not certain how to interpret "R6 - PMIPv6 multicast > mobility management MUST equally cover IPv6/IPv4 only and dual stack > nodes." > Are we considering more than IPv6 multicast, i.e. MLDv2, or am I > just reading it wrong? My personal opinion is that this statement is a bit strong requirement. I think RFC5213 says PMIPv6 "may" support IPv4 or dual-stack mobile nodes with the extension of other draft. I think PMIPv6 multicast draft should also mention "may" not MUST for IPv4 or dual-stack mobile node support. Regards, -- Hitoshi Asaeda > Niklas > > Hitoshi Asaeda wrote: > > Hi Jari and Behcet, > > > >> Is there anything else you or others on this list want to say about > >> the readiness state of this effort? Did you succeed in updating the > >> drafts as agreed in the bar BOF? Do people on the list agree with > >> the contents of the requirements draft? > > Regarding IGMP/MLD requirement draft > > (draft-liu-multimob-igmp-mld-mobility-req), we will submit the revised > > version (-01) about one week from now. > > Thanks, > > -- > > Hitoshi Asaeda > > _______________________________________________ > > multimob mailing list > > multimob@ietf.org > > https://www.ietf.org/mailman/listinfo/multimob > > > > -- Niklas Neumann - University of Goettingen, Institute of Computer Science > http://user.informatik.uni-goettingen.de/~nneuman1/ > Tel: +49 551 39-172053 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From multimob-bounces@ietf.org Tue Sep 30 13:38:36 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0F328C14A; Tue, 30 Sep 2008 13:38:36 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587C128C14A for ; Tue, 30 Sep 2008 13:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.241 X-Spam-Level: X-Spam-Status: No, score=0.241 tagged_above=-999 required=5 tests=[AWL=-1.980, BAYES_50=0.001, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7E6bJ+hiFAHx for ; Tue, 30 Sep 2008 13:38:34 -0700 (PDT) Received: from web38806.mail.mud.yahoo.com (web38806.mail.mud.yahoo.com [209.191.125.97]) by core3.amsl.com (Postfix) with SMTP id A9F1C3A6BCE for ; Tue, 30 Sep 2008 13:38:34 -0700 (PDT) Received: (qmail 47496 invoked by uid 60001); 30 Sep 2008 20:38:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=ogRywUMH4y82Jk3OoZgqtFGTCX98YqpTyptl6boFbHeCAqvTE3ElsetyvXM7sISpc6/7d1Puae3fCm4I9WlCmJfBOKd2unZLrSSG9xDYHtzAtwvFJi3hh75goh9mOPa/Y7QDpMDVjTb6wE/lQs0bhndEaubDl6/ZoYlukrPe2E0=; X-YMail-OSG: 6TkRqywVM1kcQkKfubLRtycqzwuqmc4E5phhi6HQD6v.5ej6cczmQsqBeN.Fh2cuql61w3wH6VqZZ3qJBp5EGqehu997NiYsyosZoBEy9RmH11YPZXxi2zRQEUarea441kodEwR2hYUJ0yi8YtpDDzXV6Ks6EA-- Received: from [206.16.17.212] by web38806.mail.mud.yahoo.com via HTTP; Tue, 30 Sep 2008 13:38:56 PDT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Tue, 30 Sep 2008 13:38:56 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <547566.47008.qm@web38806.mail.mud.yahoo.com> Subject: [multimob] Test X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1942371746==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1942371746== Content-Type: multipart/alternative; boundary="0-1583244033-1222807136=:47008" --0-1583244033-1222807136=:47008 Content-Type: text/plain; charset=us-ascii --0-1583244033-1222807136=:47008 Content-Type: text/html; charset=us-ascii

--0-1583244033-1222807136=:47008-- --===============1942371746== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1942371746==-- From multimob-bounces@ietf.org Tue Sep 30 13:47:23 2008 Return-Path: X-Original-To: multimob-archive@optimus.ietf.org Delivered-To: ietfarch-multimob-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF583A6BCC; Tue, 30 Sep 2008 13:47:23 -0700 (PDT) X-Original-To: multimob@core3.amsl.com Delivered-To: multimob@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ACF23A68BD for ; Tue, 30 Sep 2008 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHYTZnFEM4gd for ; Tue, 30 Sep 2008 13:47:21 -0700 (PDT) Received: from web38807.mail.mud.yahoo.com (web38807.mail.mud.yahoo.com [209.191.125.98]) by core3.amsl.com (Postfix) with SMTP id 948133A6BCC for ; Tue, 30 Sep 2008 13:47:21 -0700 (PDT) Received: (qmail 9351 invoked by uid 60001); 30 Sep 2008 20:47:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=xNIYakAZ9/IT+0CtU3lIt5NYlxM684ib4YQAR2z7V33GYj32Fl5hx6J09pVfyf7e0Tom+CnjhWNjOB02PGCQT6g5kZQHch4vAjhSx29/U+8V2sym5ngcA2bYYTHhQP8Ul1y0DIGgmT9jKY09s4qqKnP/3CFr5YQukPQjvO2IHJw=; X-YMail-OSG: cZ_MfigVM1ldR3N6NkbwrQLomAxRO3A5uCmNQdmkBACbkbtS2gkJqKf57Cw.Dofn10xy8HN.HBgmqrINbSEnOq8ayaiwpqQR2yWM1ix.cCotURTMno.M1Tc5AfaQAX_vKlydRqUQevdl_aigFTOcsfOglm6snAQi8PX8SECwXRxWmt4jVmw- Received: from [206.16.17.212] by web38807.mail.mud.yahoo.com via HTTP; Tue, 30 Sep 2008 13:47:43 PDT X-Mailer: YahooMailRC/1096.28 YahooMailWebService/0.7.218.2 Date: Tue, 30 Sep 2008 13:47:43 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Message-ID: <476145.8521.qm@web38807.mail.mud.yahoo.com> Subject: [multimob] Reposting - Preparations for IETF-73 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624125052==" Sender: multimob-bounces@ietf.org Errors-To: multimob-bounces@ietf.org --===============1624125052== Content-Type: multipart/alternative; boundary="0-1376511424-1222807663=:8521" --0-1376511424-1222807663=:8521 Content-Type: text/plain; charset=us-ascii Hi Jari, Thanks for the good news. The bar BOF milestones were: PMIPv6 Requirements Draft -00 version has already been published. It received several comments. The authors are preparing to issue -01 version soon. PMIPv6 Solution draft -00 version will be issued mid October. There are a few people who volunteered are working on this draft. The work is to my knowledge advancing well. Apart from the above, a new version of requirements for IGMP/MLD extensions draft (draft-liu-multimob-igmp-mld-mobility-req-01.txt) will be out soon (to be confirmed by the authors) and the solution draft (draft-asaeda-multimob-igmp-mld-mobility-extensions-01.txt) was revised just before Dublin meeting. I think that Multimob is ready for the BOF. Regards, Behcet ----- Original Message ---- From: Jari Arkko To: Behcet Sarikaya Cc: multimob@ietf.org Sent: Sunday, September 28, 2008 12:42:58 PM Subject: Re: [multimob] Preparations for IETF-73 Bechet, Thanks for the efforts in setting this up. We are discussing the approval of this BOF in the IESG and IAB on the coming Friday. I think the agenda and charter proposal look reasonable. I still need to read the new drafts. Is there anything else you or others on this list want to say about the readiness state of this effort? Did you succeed in updating the drafts as agreed in the bar BOF? Do people on the list agree with the contents of the requirements draft? Jari --0-1376511424-1222807663=:8521 Content-Type: text/html; charset=us-ascii

Hi Jari,

Thanks for the good news.
The bar BOF milestones were:
PMIPv6 Requirements Draft -00 version has already been published. It received several comments. The authors are preparing to issue -01 version soon.
PMIPv6 Solution draft -00 version will be issued mid October. There are a few people who volunteered are working on this draft. The work is to my knowledge advancing well.

Apart from the above, a new version of requirements for IGMP/MLD extensions draft (draft-liu-multimob-igmp-mld-mobility-req-01.txt) will be out soon (to be confirmed by the authors) and the solution draft
(draft-asaeda-multimob-igmp-mld-mobility-extensions-01.txt) was revised just before Dublin meeting.

I think that Multimob is ready for the BOF.

Regards,

Behcet

----- Original Message ----
From: Jari Arkko <jari.arkko@piuha.net>
To: Behcet Sarikaya <sarikaya@ieee.org>
Cc: multimob@ietf.org
Sent: Sunday, September 28, 2008 12:42:58 PM
Subject: Re: [multimob] Preparations for IETF-73

Bechet,

Thanks for the efforts in setting this up. We are discussing the
approval of this BOF in the IESG and IAB on the coming Friday.

I think the agenda and charter proposal look reasonable. I still need to
read the new drafts.

Is there anything else you or others on this list want to say about the
readiness state of this effort? Did you succeed in updating the drafts
as agreed in the bar BOF? Do people on the list agree with the contents
of the requirements draft?

Jari

--0-1376511424-1222807663=:8521-- --===============1624125052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --===============1624125052==--