From stig@venaas.com Tue Jun 1 01:42:26 2010 Return-Path: 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 7C7C33A6972 for ; Tue, 1 Jun 2010 01:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 kCkmD2cYycyZ for ; Tue, 1 Jun 2010 01:42:22 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 4D2FA3A67B7 for ; Tue, 1 Jun 2010 01:42:22 -0700 (PDT) Received: from [IPv6:2001:778:0:37:a01f:2bd4:cd94:e220] (unknown [IPv6:2001:778:0:37:a01f:2bd4:cd94:e220]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9957F8055; Tue, 1 Jun 2010 10:42:09 +0200 (CEST) Message-ID: <4C04C7E0.7020603@venaas.com> Date: Tue, 01 Jun 2010 01:42:08 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> In-Reply-To: <4C04347D.3080001@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Tue, 01 Jun 2010 08:42:26 -0000 This version looks good to me. I didn't check carefully for typos, but "looses" should be "loses" I believe. Stig From luisc@it.uc3m.es Tue Jun 1 04:02:30 2010 Return-Path: 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 5751E28C0DF for ; Tue, 1 Jun 2010 04:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 U+zXKLKfu0Gy for ; Tue, 1 Jun 2010 04:02:29 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 1014728C0D7 for ; Tue, 1 Jun 2010 04:02:27 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 8EC406CD5ED; Tue, 1 Jun 2010 13:02:09 +0200 (CEST) Received: from 85.62.13.196.static.abi.uni2.es (85.62.13.196.static.abi.uni2.es [85.62.13.196]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 01 Jun 2010 13:02:07 +0200 Message-ID: <20100601130207.z87oiq07k8kk4wo8@webcartero01.uc3m.es> Date: Tue, 01 Jun 2010 13:02:07 +0200 From: "Luis M. Contreras" To: "Thomas C. Schmidt" , multimob@ietf.org References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <4C04C7E0.7020603@venaas.com> In-Reply-To: <4C04C7E0.7020603@venaas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17418.006 Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Tue, 01 Jun 2010 11:02:30 -0000 Hi all, after a change on my e-mail server I lost my subscription to the list. I was not aware of the new draft versions till yesterday. Sorry for coming late to comment the base solution. Please, find some few comments on draft-ietf-multimob-pmipv6-base-solution-02.txt only for clarification. .- Group membership aggregation from the MAG to the LMA --> it is indicated along the document that the MAG will sent aggregated reports to the LMA as an intrinsic function of the MLD proxy. I think it is ok in an steady state behaviour. However it is somehow strange for me to see this highlighted when describing the handover process, as showed in figure 2. Let me explain. Once the MN attaches to the new MAG and responses the MLD General Query sent by the new MAG, in case there is no other MN requesting simultaneously the same content, there is no room for aggregation of the MLD report. If the MAG has already an active subscription for such content, the MAG will no forward the report towards the LMA. On the contrary, if the MAG has not a subscription for such content should send an unsolicited Report as soon as possible towards the LMA, because membership database changes. The aggregated report as depicted in figure 2 has sense as a response of an MLD General query coming from the LMA, but, in a general case, I can't see it for the Report sent by the MN after handover .- Sentence about "make-before-break" in multihoming support section --> What is the reason for this constraint? I mean, Is it your proposal or is it something already agreed? As you explain in other mail, your vision is to avoid an smooth handover by changing the interface where the content is received before the MN moves. Due that the MN is not aware in PMIPv6 of its movement at IP level, I think such smooth handover does not apply, and the statement can be removed from the base solution document (I think it can be a matter for protocol extension issues). Best regards, Luis From schmidt@informatik.haw-hamburg.de Tue Jun 1 06:34:26 2010 Return-Path: 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 67F343A69E8 for ; Tue, 1 Jun 2010 06:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 mLl5OPV1ifIk for ; Tue, 1 Jun 2010 06:34:25 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 2F4C33A68BF for ; Tue, 1 Jun 2010 06:34:24 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from wlan75-108.tnc2010.litnet.lt ([158.129.75.108]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OJRbf-0002qs-LH; Tue, 01 Jun 2010 15:34:11 +0200 Message-ID: <4C050C4D.9080101@informatik.haw-hamburg.de> Date: Tue, 01 Jun 2010 16:34:05 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Luis M. Contreras" References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <4C04C7E0.7020603@venaas.com> <20100601130207.z87oiq07k8kk4wo8@webcartero01.uc3m.es> In-Reply-To: <20100601130207.z87oiq07k8kk4wo8@webcartero01.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Tue, 01 Jun 2010 13:34:26 -0000 Dear Luis, thanks for your feedback. Please see below (marked with [Thomas=>) On 01.06.2010 14:02, Luis M. Contreras wrote: > Hi all, > > after a change on my e-mail server I lost my subscription to the list. I > was not aware of the new draft versions till yesterday. Sorry for coming > late to comment the base solution. > > Please, find some few comments on > draft-ietf-multimob-pmipv6-base-solution-02.txt only for clarification. > > .- Group membership aggregation from the MAG to the LMA --> it is > indicated along the document that the MAG will sent aggregated reports > to the LMA as an intrinsic function of the MLD proxy. I think it is ok > in an steady state behaviour. However it is somehow strange for me to > see this highlighted when describing the handover process, as showed in > figure 2. Let me explain. Once the MN attaches to the new MAG and > responses the MLD General Query sent by the new MAG, in case there is no > other MN requesting simultaneously the same content, there is no room > for aggregation of the MLD report. If the MAG has already an active > subscription for such content, the MAG will no forward the report > towards the LMA. On the contrary, if the MAG has not a subscription for > such content should send an unsolicited Report as soon as possible > towards the LMA, because membership database changes. The aggregated > report as depicted in figure 2 has sense as a response of an MLD General > query coming from the LMA, but, in a general case, I can't see it for > the Report sent by the MN after handover > [Thomas=> I guess we agree on the operations: The MAG sends reports that aggregate all MN subscriptions. So in case of a single handover, it either sends an immediate report (if the new MN has a unique group membership) or it just refreshes periodically, if group states are shared among several MNs. Aggregation again plays a "real" role, whenever several MNs handover about simultaneously. You raise the question on the proper presentation in Figure 2. In writing "aggregated Join" we tried to combine these different behaviors under one name ... otherwise we should need something like a case distinction in the graph. So we believe that this summarizing term "aggregated Join" helps to keep the flow chart simple and hints to the correct mechanisms and intuitions .... > .- Sentence about "make-before-break" in multihoming support section --> > What is the reason for this constraint? I mean, Is it your proposal or > is it something already agreed? As you explain in other mail, your > vision is to avoid an smooth handover by changing the interface where > the content is received before the MN moves. Due that the MN is not > aware in PMIPv6 of its movement at IP level, I think such smooth > handover does not apply, and the statement can be removed from the base > solution document (I think it can be a matter for protocol extension > issues). > [Thomas=> This seems like a misunderstanding: The objective of the multihoming support section is to clarify the behavior of multihomed PMIPv6 nodes that are subscribed to multicast groups. It is just explaining the base solution in this context, there are no personal opinions in there. The statement about "make-before-break" just clarifies that multihoming in this situation cannot be used for smoothing mobility management. As you may have heard, there is an active debate on this "make-before-break" based on multihoming and people might be mistakenly tempted to believe that this scenario applies here ... That's all, just clarification, no proposal or new solution here. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From pierrick.seite@orange-ftgroup.com Tue Jun 1 09:25:45 2010 Return-Path: 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 6976228C0FD for ; Tue, 1 Jun 2010 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.651 X-Spam-Level: * X-Spam-Status: No, score=1.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, MANGLED_SOLTNS=2.3, 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 3Q83zd5rEINB for ; Tue, 1 Jun 2010 09:25:41 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 7A18028C171 for ; Tue, 1 Jun 2010 09:25:40 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 608C78B800D; Tue, 1 Jun 2010 18:25:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0C3E68B800C; Tue, 1 Jun 2010 18:25:03 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 18:24:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 18:24:03 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462E39A1D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4BFC2AF4.90001@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob]I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt Thread-Index: Acr8RB10VGMtMRHwRXSMqqBFkSV/cAFYfc2w References: <20100525194501.E676E3A6970@core3.amsl.com> <4BFC2AF4.90001@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 01 Jun 2010 16:24:05.0944 (UTC) FILETIME=[DAEE4B80:01CB01A6] Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.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: , X-List-Received-Date: Tue, 01 Jun 2010 16:25:45 -0000 Hi Thomas, I've read draft-ietf-multimob-pmipv6-base-solution-02 that I found in = very good shape. Actually, I have only very few comments: On section 3 (overview):=20 I think, it would help to remind that the aggregated join is part of the = normal operations of an IGMP/MLD proxy. It is not clear (at least to me :-)) how the MAG manages duplicate = traffic. Maybe the issue could be clarified. If I understood correcly, = when two MNs, being attached to two different LMAs, subscribe to the = same group, two multicast flow of the same group are received at the = MAG.=20 However, from my understanding, one multicast flow may arrive at the MAG = with delay in comparison to the other multicast flow (end-to-end = transmission delay from source to MN1 via LMA1 may differ from = end-to-end transmission delay from source to MN2 via LMA2). So, to avoid = data loss, the MAG must forward the right multicast flow to the = corresponding MN. But, thanks to the PMIP model, it is not an issue: the = MAG can forward each multicast stream, received via a particular tunnel, = to the corresponding MN since the MN-MAG interface is a point-to-point = link. Correct? In 4.2 you wrote: To learn about multicast groups subscribed by a newly attaching MN, the = MAG SHOULD send a General Query to the MN's link. : Is it really a = SHOULD? not a MUST? If the MAG does not send a general query, how the = MAG learns the group subscribed by the new MN? Still in 4.2: What do you mean by "Note that the actual observable state = depends on the access link model in use." we are considering only = point-to-point access link, right? And few typos: 2. Terminology: s/protocols[RFC3376]/protocols [RFC3376] In last paragraph of section 3: s/an MAG/a MAG 4. Deployment details: s/Multicast activation in a PMIPv6 domain requires to deploy general = multicast functions at PMIPv6 routers and to define its interaction with = the PMIPv6 protocol in the following way:/Multicast activation in a = PMIPv6 domain requires to deploy general multicast functions at PMIPv6 = routers and to define _their_ interaction with the PMIPv6 protocol in = the following way: Regards, Pierrick=20 -----Message d'origine----- De : multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la = part de Thomas C. Schmidt Envoy=E9 : mardi 25 mai 2010 21:54 =C0 : multimob@ietf.org Objet : Re: [multimob]I-D = Action:draft-ietf-multimob-pmipv6-base-solution-01.txt Hi all, we just submitted the updated version of = draft-ietf-multimob-pmipv6-base-solution as discussed in Anaheim. From the change log: 1. Added section on multihoming. 2. Updated security section. 3. Several editorial improvements and minor extensions. Please have a firm look ;) so that we can finalize the document. Thanks, Thomas On 25.05.2010 21:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multicast Mobility Working Group of = the IETF. > > > Title : Base Deployment for Multicast Listener Support in = PMIPv6 Domains > Author(s) : T. Schmidt, et al. > Filename : draft-ietf-multimob-pmipv6-base-solution-01.txt > Pages : 19 > Date : 2010-05-25 > > This document describes deployment options for activating multicast=20 > listener functions in Proxy Mobile IPv6 domains without modifying=20 > mobility and multicast protocol standards. Similar to Home Agents in=20 > Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast=20 > subscription anchor points, while Mobile Access Gateways provide MLD=20 > proxy functions. In this scenario, Mobile Nodes remain agnostic of=20 > multicast mobility operations. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-so > lution-01.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=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Tue Jun 1 10:01:06 2010 Return-Path: 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 659E83A6A4B for ; Tue, 1 Jun 2010 10:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-1.237, BAYES_50=0.001, HELO_EQ_DE=0.35, MANGLED_SOLTNS=2.3] 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 KcHvYaetf888 for ; Tue, 1 Jun 2010 10:01:05 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 291EC3A68BC for ; Tue, 1 Jun 2010 10:01:04 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from wlan75-108.tnc2010.litnet.lt ([158.129.75.108]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OJUpf-0004lC-F1 for multimob@ietf.org; Tue, 01 Jun 2010 19:00:51 +0200 Message-ID: <4C053CBC.10205@informatik.haw-hamburg.de> Date: Tue, 01 Jun 2010 20:00:44 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100525194501.E676E3A6970@core3.amsl.com> <4BFC2AF4.90001@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462E39A1D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462E39A1D@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.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: , X-List-Received-Date: Tue, 01 Jun 2010 17:01:06 -0000 Hi Pierrick, many thanks for your careful review. Please see below marks [Thomas=>: On 01.06.2010 19:24, pierrick.seite@orange-ftgroup.com wrote: > Hi Thomas, > > I've read draft-ietf-multimob-pmipv6-base-solution-02 that I found in very good shape. Actually, I have only very few comments: > > > On section 3 (overview): > > I think, it would help to remind that the aggregated join is part of the normal operations of an IGMP/MLD proxy. > [Thomas=> Well, it says "According to standard proxy operations, MLD Report messages will be forwarded under aggregation up the tunnel interface to its corresponding LMA." and cites the RFC4605 ... that should be a pretty strong reminder ... > It is not clear (at least to me :-)) how the MAG manages duplicate traffic. Maybe the issue could be clarified. If I understood correcly, when two MNs, being attached to two different LMAs, subscribe to the same group, two multicast flow of the same group are received at the MAG. [Thomas=> Correct. > However, from my understanding, one multicast flow may arrive at the MAG with delay in comparison to the other multicast flow (end-to-end transmission delay from source to MN1 via LMA1 may differ from end-to-end transmission delay from source to MN2 via LMA2). So, to avoid data loss, the MAG must forward the right multicast flow to the corresponding MN. But, thanks to the PMIP model, it is not an issue: the MAG can forward each multicast stream, received via a particular tunnel, to the corresponding MN since the MN-MAG interface is a point-to-point link. Correct? [Thomas=> Actually, these operations are independent of PMIP, but follow from isolated proxy instances. The Proxy instance at the MAG will serve its downstream link with whatever group is subscribed and received. For exactly this reason we stated in 4.2, 2nd para: "At this stage, it is important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of section 4.2 in [RFC4605], i.e., treat proxy instances in isolation of each other while forwarding." > > In 4.2 you wrote: > > To learn about multicast groups subscribed by a newly attaching MN, the MAG SHOULD send a General Query to the MN's link. : Is it really a SHOULD? not a MUST? If the MAG does not send a general query, how the MAG learns the group subscribed by the new MN? [Thomas=> Well, the MLD proxy always queries, so the (non-proxy-attached) interface is not required to query. Querying will occur anyway, but it is faster if done as soon as the link comes up. > > Still in 4.2: What do you mean by "Note that the actual observable state depends on the access link model in use." we are considering only point-to-point access link, right? [Thomas=> Yes, but at this point it matters ... that's why we stressed it. > > And few typos: [Thomas=> THANKS! Best regards, Thomas > > 2. Terminology: > > s/protocols[RFC3376]/protocols [RFC3376] > > In last paragraph of section 3: > > s/an MAG/a MAG > > 4. Deployment details: > > s/Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define its interaction with the PMIPv6 protocol in the following way:/Multicast activation in a PMIPv6 domain requires to deploy general multicast functions at PMIPv6 routers and to define _their_ interaction with the PMIPv6 protocol in the following way: > > Regards, > Pierrick > > -----Message d'origine----- > De : multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] De la part de Thomas C. Schmidt > Envoyé : mardi 25 mai 2010 21:54 > À : multimob@ietf.org > Objet : Re: [multimob]I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt > > Hi all, > > we just submitted the updated version of draft-ietf-multimob-pmipv6-base-solution as discussed in Anaheim. > > From the change log: > > 1. Added section on multihoming. > > 2. Updated security section. > > 3. Several editorial improvements and minor extensions. > > > Please have a firm look ;) so that we can finalize the document. > > Thanks, > > Thomas > > > On 25.05.2010 21:45, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multicast Mobility Working Group of the IETF. >> >> >> Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains >> Author(s) : T. Schmidt, et al. >> Filename : draft-ietf-multimob-pmipv6-base-solution-01.txt >> Pages : 19 >> Date : 2010-05-25 >> >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards. Similar to Home Agents in >> Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast >> subscription anchor points, while Mobile Access Gateways provide MLD >> proxy functions. In this scenario, Mobile Nodes remain agnostic of >> multicast mobility operations. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-so >> lution-01.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. >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Tue Jun 1 12:23:04 2010 Return-Path: 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 9E6263A680A for ; Tue, 1 Jun 2010 12:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.772 X-Spam-Level: X-Spam-Status: No, score=0.772 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_50=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 PltDYNL7J-Au for ; Tue, 1 Jun 2010 12:23:00 -0700 (PDT) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id 1F6FD3A6A49 for ; Tue, 1 Jun 2010 12:23:00 -0700 (PDT) Received: (qmail 32607 invoked by uid 60001); 1 Jun 2010 19:22:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275420168; bh=VpyAPQl00qcGZ3OVkM4TD89IFXQYCAlCJZtzyd3eFes=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ffWecY6mLsQUFoIW8b3V8yQYeFeQajFpUwippzEcSjh0LRV2rRYe2OvCcqG/DZG4PGBmSBYj2512mdw4p0WJEnjj41aOMWxXlFLEc+9knHCNGYux3bqbVvwKg3GsJfDww9FibSHKvkkSMzZ3+JXcafSOp2mh4NX7AHQpwENBDgk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UaWQfP/yWdE/V2vuw7ry7QOsoD1s9TfG/Gccfmz75l/PTR0BytRZx04XunnGzNUllJbrXOfs+2mvBvMmIWf4oN1XD6NEAj0qtW4ONZa8XO4SMC1Fx0+iAQQafHkev4OuHa2bu+5S2ieJcGL+M36LVmHxAoWcqpl9uLJkF2B9NTc=; Message-ID: <125247.22571.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: QaS45GgVM1mvJ7jOHxN7qJnKeCEFD.3yUbbuwYpSZh_71xw UUL1VQ3StygaXdGO78MJWoxphYlEprJwDP57NNbsox5oyU1Es7.OX6gcTCc_ HsheirS3FISPlAj85tlkgLq0Ys5zr1OuhTOO9EM0QmXaZaK5MScBTepfgNQj 0PkTfv96NGit1y7766Yj2WWG9rRiIyaqdOfkubw7l_VTYvFlr3vXqhLGaQkR 4eBYjgKdvTZ2Gwtp.45MS5hk6DIlsyTf2pnKueqQjWOtP_BSqnpUaTCimwxT cZv.hEHtwWWIkHuCx2_YFFCVnzQGb8Edjx9bEfiFmXS5cJbVgoVMIyFNGF2v 5PZB1vIWtk_Oc Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Tue, 01 Jun 2010 12:22:47 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> Date: Tue, 1 Jun 2010 12:22:47 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4C04347D.3080001@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Tue, 01 Jun 2010 19:23:04 -0000 Hi Thomas,=0A=A0 It seems like you have not done almost any of the correcti= ons/comments I posted earlier at:=0Ahttp://www.ietf.org/mail-archive/web/mu= ltimob/current/msg00853.html=0A=0ACan you please offer an explaination, ite= m by item why?=0A=0AThx.=0A=0ABehcet=0A=0A=0A From pierrick.seite@orange-ftgroup.com Wed Jun 2 01:01:00 2010 Return-Path: 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 2BE3828C13C for ; Wed, 2 Jun 2010 01:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_50=0.001, 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 qxoclGTaRDux for ; Wed, 2 Jun 2010 01:00:53 -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 BF1D93A6973 for ; Wed, 2 Jun 2010 01:00:52 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 57CE0798005; Wed, 2 Jun 2010 10:01:44 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id CA342798001; Wed, 2 Jun 2010 10:01:37 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 09:59:32 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Jun 2010 09:59:31 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462E39AF5@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C053CBC.10205@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob]I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.txt Thread-Index: AcsBrBMERVDUID/bTrSJFl1ghWj4zAAefkEw References: <20100525194501.E676E3A6970@core3.amsl.com> <4BFC2AF4.90001@informatik.haw-hamburg.de><843DA8228A1BA74CA31FB4E111A5C462E39A1D@ftrdmel0.rd.francetelecom.fr> <4C053CBC.10205@informatik.haw-hamburg.de> From: To: , X-OriginalArrivalTime: 02 Jun 2010 07:59:32.0716 (UTC) FILETIME=[89180AC0:01CB0229] Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.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: , X-List-Received-Date: Wed, 02 Jun 2010 08:01:00 -0000 =20 Hi Thomas, > > On section 3 (overview): > > I think, it would help to remind that the aggregated join is part of the normal operations of an IGMP/MLD proxy. > [Thomas=3D> Well, it says "According to standard proxy operations, MLD Report messages will be forwarded under aggregation up the tunnel interface to its corresponding LMA." and cites the RFC4605 ... that should be a pretty strong reminder ... [pierrick] your're right. It proves that my review was not so careful :-) > It is not clear (at least to me :-)) how the MAG manages duplicate traffic. Maybe the issue could be clarified. If I understood correcly, when two MNs, being attached to two different LMAs, subscribe to the same group, two multicast flow of the same group are received at the MAG. [Thomas=3D> Correct. > However, from my understanding, one multicast flow may arrive at the MAG with delay in comparison to the other multicast flow (end-to-end transmission delay from source to MN1 via LMA1 may differ from end-to-end transmission delay from source to MN2 via LMA2). So, to avoid data loss, the MAG must forward the right multicast flow to the corresponding MN. But, thanks to the PMIP model, it is not an issue: the MAG can forward each multicast stream, received via a particular tunnel, to the corresponding MN since the MN-MAG interface is a point-to-point link. Correct? [Thomas=3D> Actually, these operations are independent of PMIP, but = follow from isolated proxy instances. The Proxy instance at the MAG will serve its downstream link with whatever group is subscribed and received. For exactly this reason we stated in 4.2, 2nd para: "At this stage, it is important to note that IGMP/MLD proxy implementations capable of multiple instances are expected to closely follow the specifications of section 4.2 in [RFC4605], i.e., treat proxy instances in isolation of each other while forwarding." [pierrick] I understand. I find your sentence "follow from isolated proxy instances, the MAG will serve its downstream link with whatever group is subscribed and received" more clear; it could be added to the draft. Anyway, it's not a big deal. > > In 4.2 you wrote: > > To learn about multicast groups subscribed by a newly attaching MN, the MAG SHOULD send a General Query to the MN's link. : Is it really a SHOULD? not a MUST? If the MAG does not send a general query, how the MAG learns the group subscribed by the new MN? [Thomas=3D> Well, the MLD proxy always queries, so the (non-proxy-attached) interface is not required to query. Querying will occur anyway, but it is faster if done as soon as the link comes up. [pierrick] Thanks for clarifications. Your answers address all my concerns. BR, Pierrick From schmidt@informatik.haw-hamburg.de Wed Jun 2 01:17:26 2010 Return-Path: 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 8F5C228C150 for ; Wed, 2 Jun 2010 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.839 X-Spam-Level: X-Spam-Status: No, score=0.839 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_50=0.001, 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 fTg4HN2qs5bi for ; Wed, 2 Jun 2010 01:17:23 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id DB33C3A696E for ; Wed, 2 Jun 2010 01:17:22 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from wlan75-108.tnc2010.litnet.lt ([158.129.75.108]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OJj8O-000NbC-W6 for multimob@ietf.org; Wed, 02 Jun 2010 10:17:09 +0200 Message-ID: <4C061381.9070602@informatik.haw-hamburg.de> Date: Wed, 02 Jun 2010 11:17:05 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100525194501.E676E3A6970@core3.amsl.com> <4BFC2AF4.90001@informatik.haw-hamburg.de><843DA8228A1BA74CA31FB4E111A5C462E39A1D@ftrdmel0.rd.francetelecom.fr> <4C053CBC.10205@informatik.haw-hamburg.de> <843DA8228A1BA74CA31FB4E111A5C462E39AF5@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462E39AF5@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-01.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: , X-List-Received-Date: Wed, 02 Jun 2010 08:17:26 -0000 Thanks Pierrick, we have changed all the points you were pointing at ... it will be part of the next update. Cheers, Thomas On 02.06.2010 10:59, pierrick.seite@orange-ftgroup.com wrote: > > Hi Thomas, > > >> >> On section 3 (overview): >> >> I think, it would help to remind that the aggregated join is part of > the normal operations of an IGMP/MLD proxy. >> > [Thomas=> Well, it says "According to > standard proxy operations, MLD Report messages will be forwarded > under aggregation up the tunnel interface to its corresponding LMA." > > and cites the RFC4605 ... that should be a pretty strong reminder ... > > [pierrick] your're right. It proves that my review was not so careful > :-) > >> It is not clear (at least to me :-)) how the MAG manages duplicate > traffic. Maybe the issue could be clarified. If I understood correcly, > when two MNs, being attached to two different LMAs, subscribe to the > same group, two multicast flow of the same group are received at the > MAG. > > [Thomas=> Correct. > >> However, from my understanding, one multicast flow may arrive at the > MAG with delay in comparison to the other multicast flow (end-to-end > transmission delay from source to MN1 via LMA1 may differ from > end-to-end transmission delay from source to MN2 via LMA2). So, to avoid > data loss, the MAG must forward the right multicast flow to the > corresponding MN. But, thanks to the PMIP model, it is not an issue: the > MAG can forward each multicast stream, received via a particular tunnel, > to the corresponding MN since the MN-MAG interface is a point-to-point > link. Correct? > > [Thomas=> Actually, these operations are independent of PMIP, but follow > from isolated proxy instances. The Proxy instance at the MAG will serve > its downstream link with whatever group is subscribed and received. > > For exactly this reason we stated in 4.2, 2nd para: > > "At this stage, it is important to note that > IGMP/MLD proxy implementations capable of multiple instances are > expected to closely follow the specifications of section 4.2 in > [RFC4605], i.e., treat proxy instances in isolation of each other > while forwarding." > > [pierrick] I understand. I find your sentence "follow from isolated > proxy instances, the MAG will serve its downstream link with whatever > group is subscribed and received" more clear; it could be added to the > draft. Anyway, it's not a big deal. > >> >> In 4.2 you wrote: >> >> To learn about multicast groups subscribed by a newly attaching MN, > the MAG SHOULD send a General Query to the MN's link. : Is it really a > SHOULD? not a MUST? If the MAG does not send a general query, how the > MAG learns the group subscribed by the new MN? > > [Thomas=> Well, the MLD proxy always queries, so the > (non-proxy-attached) interface is not required to query. Querying will > occur anyway, but it is faster if done as soon as the link comes up. > > [pierrick] Thanks for clarifications. Your answers address all my > concerns. > > BR, > Pierrick > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Wed Jun 2 06:33:59 2010 Return-Path: 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 B5CE53A687A for ; Wed, 2 Jun 2010 06:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.647 X-Spam-Level: X-Spam-Status: No, score=0.647 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_50=0.001, 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 FmqB57d73xYZ for ; Wed, 2 Jun 2010 06:33:58 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 4682E3A69EC for ; Wed, 2 Jun 2010 06:33:48 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from wlan75-108.tnc2010.litnet.lt ([158.129.75.108]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OJo4c-000DSy-Jc for multimob@ietf.org; Wed, 02 Jun 2010 15:33:34 +0200 Message-ID: <4C065DA8.6020308@informatik.haw-hamburg.de> Date: Wed, 02 Jun 2010 16:33:28 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <125247.22571.qm@web111412.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Wed, 02 Jun 2010 13:33:59 -0000 X-List-Received-Date: Wed, 02 Jun 2010 13:33:59 -0000 Hi Behcet, from a thematic point of view, I've picked up the state of the discussion. Those not picked up (like the NAT) were already discussed on the list. On the editorial side: I did not pick up the continuous spell out of all protocol names as this appears unusual and makes the document more difficult to read. (it should suffice to spell out PMIPv6 in the abstract and at its first use, but keep the well-known abbreviation the dozen other times) In addition, if there are nits on this level, the RFC-editor will take care of this before AUTH48. Aside, I'm not aware of any open issue. Best regards, Thomas On 01.06.2010 22:22, Behcet Sarikaya wrote: > Hi Thomas, > It seems like you have not done almost any of the corrections/comments I posted earlier at: > http://www.ietf.org/mail-archive/web/multimob/current/msg00853.html > > Can you please offer an explaination, item by item why? > > Thx. > > Behcet > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Thu Jun 3 12:36:41 2010 Return-Path: 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 66F513A6916 for ; Thu, 3 Jun 2010 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.685 X-Spam-Level: X-Spam-Status: No, score=0.685 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_50=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 nByparhocCFK for ; Thu, 3 Jun 2010 12:36:40 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id A91CF3A683E for ; Thu, 3 Jun 2010 12:36:40 -0700 (PDT) Received: (qmail 82344 invoked by uid 60001); 3 Jun 2010 19:36:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275593785; bh=los0vK+iyL6vKNvngwCAGK5oPrjcwoOMiISzoQ6cP/0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6v//ydVq7IO7trQ1rd0nY1M26ShtACqL41ltZCSqpgu1KagbD/g0qirL4r52fJFVfxD1SUk7Ut6F68JXwnacDgsNSGOQIfaqkwfaoLBIDGnpUTXWVkCl45MNxCRhAEtJz0TWK5wRL65hGD9KOJHF8MmotEWGPCZpgbOGxMc/L6c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tMzSlMeUU+aX6QtsDcYlmYyaTRq3Xpz9jLEi9A4XDPPPZ2rWdL8tOWiinylHRfnXuY+X8Srmq9FvmmOTxNaE+itsn9s8wdSq8HuOs1zW+dUlicV4GkuUyfwW3ccgHuEdzK17TsyWKx4ThPOXyV/7w5TFzdmnVkknUB5NVQrHs8k=; Message-ID: <24001.82312.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: EYPxNhQVM1kdS9qjO4wbqvs9KNfQdxyGM8CWg22o26fC0qM 7Dyo35s6J53JUtyde3ljh7fOTSdJMjp5nsg639zASoYltcCtKz6kmgPYX19w Ra2aNeFpQxGZUlftdaGIVcu3usPbXQesk2NW0AFmL.pXmI7qUflgDBTPDp0a aZRvhlE2lCqTcyxiYAVVF2TDw_jHrUK5wz2RJuRyqW7gbo7i0GmfWZGtK3oW s40yQfbBI.TUlv8AMngvsSs0kbEn6cKt9lUbCCG9o7V47P1rESnJaroKcgaC cjItVaJfKLph.wHivrxV6X3TKMnRsESpCi3f3DZm7iN84i973SqK5BrvFr38 nTdmKVtM0XUIf Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Thu, 03 Jun 2010 12:36:24 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> Date: Thu, 3 Jun 2010 12:36:24 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , multimob@ietf.org In-Reply-To: <4C065DA8.6020308@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Thu, 03 Jun 2010 19:36:41 -0000 Hi Thomas,=0A=A0 Only a few issues left, I think we are getting there.=0ASe= e below.=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A----- Original Message ----= =0A> From: Thomas C. Schmidt =0A> To: mu= ltimob@ietf.org=0A> Sent: Wed, June 2, 2010 8:33:28 AM=0A> Subject: Re: [mu= ltimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt=0A>= =0A> Hi Behcet,=0A=0A> from a thematic point of view, I've picked up the s= tate of the =0A> discussion. =0A=0AWhich ones?=0A=0AFor example Section 1 P= aragraph 3, you have not picked up and also not offering any explaination w= hy. =0AIn your new text you are making some statements that may not be corr= ect.=0A=0ASection 5.1 and 5.2 have not picked up.=0A=0AAbout some informati= ve references?=0A=0A=0A> Those not picked up (like the NAT) were already di= scussed on the =0A> list.=0A=0AI am not sure if it would be sufficient to o= nly say that IGMP is supported analogously =0A=0Abecause IPv4 is different.= =0A=0A=0A> On the editorial side: I did not pick up the continuous spell ou= t =0A> of all protocol names as this appears unusual=A0 and makes the docum= ent more =0A> difficult to read. (it should suffice to spell out PMIPv6 in = the abstract and at =0A> its first use, but keep the well-known abbreviatio= n the dozen other times) In =0A> addition, if there are nits on this level,= the RFC-editor will take care of this =0A> before AUTH48.=0A=0AAre you say= ing that RFC 3775, 5213, 5844 are difficult to read?=0A=0A=0A From Akbar.Rahman@InterDigital.com Thu Jun 3 13:13:06 2010 Return-Path: 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 7A7713A68B3 for ; Thu, 3 Jun 2010 13:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 VXQmHqexCoGD for ; Thu, 3 Jun 2010 13:13:04 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 6CA703A6811 for ; Thu, 3 Jun 2010 13:13:04 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 16:12:50 -0400 Received: from SAM.InterDigital.com ([10.30.2.12]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 16:12:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Jun 2010 16:12:47 -0400 Message-ID: In-Reply-To: <4C04347D.3080001@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt Thread-Index: AcsBDoOd1aBfFXZET/mmQKGYDz16uACSkLGQ References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> From: "Rahman, Akbar" To: "Thomas C. Schmidt" X-OriginalArrivalTime: 03 Jun 2010 20:12:50.0748 (UTC) FILETIME=[2460AFC0:01CB0359] Cc: multimob@ietf.org Subject: Re: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Thu, 03 Jun 2010 20:13:06 -0000 Hi Thomas, Thank you for the updates, and for addressing our previous comments. = Overall the document looks in good shape. We have the following = comments and suggestions for your consideration for any future update: - Section 1 o In the 3rd paragraph, the key (background) motivation point of what = multicast is supported in PMIPv6 and MIPv6 is mentioned as follows: "[RFC5213] does not explicitly address multicast communication and thus relies on the minimal multicast support provided by MIPv6. But unfortunately, bi-directional home tunneling, the minimal multicast support arranged by MIPv6, cannot be applied in network-based management scenarios, since a mobility- unaware node will not initiate such a tunnel after movement." o However, the second sentence above is very hard to decipher and should = be re-worded to make it more understandable. Also the above two = sentences taken together seem to imply that there is a fault in RFC5213 = (i.e. that RFC5213 suggests to use MIPv6 multicast approach but that = this is not intrinsically possible by the MN since it is unaware of = network mobility). Was that the intent? - Figure 2 o The Rtr Adv reply to the Rtr Sol is missing o MN2 moves to MAG2. However it is not clear where the arrow "Movement = to MAG2 & PMIP Binding Update" points to. - Section 3 o The paragraph talking about IPv4 ("These multicast deployment = considerations likewise apply for mobile nodes that operate with their = IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Support - Section 4.5 o This section on multi-homing is clear on the details of PMIPv6 = operation over the multiple interfaces of an MN. However, what was not = clear was how the multicast application would operate and react if it = got, for example, the same multicast group subscription over the = multiple interfaces? Could you add some more explanatory description as = for example your description in section 3 "It will submit MLD Report and = Done messages, based on application triggers, using its link-local = source address and multicast destination addresses ..."] - Appendix C:=20 o In the Appendix it states: "For scenario A it should be also noted that the high stream replication requirements at LMAs in setting 1 can be attenuated by deploying additional LMAs in a PMIP domain, while scenario B does not allow for distributing the LMA-M, as no handover management is available at LMA-M." o Please note in our latest draft (draft-zuniga-multimob-smspmip-03, = section 3.1) we clarify that multiple LMA-M's can be deployed to address = the scalability issue. So the key difference between scenarios A and B = is that in scenario B we separate the unicast and multicast paths (and = not in the number of LMAs) o In the Appendix it states: "These considerations of extremal settings show that tunnel convergence, i.e., duplicate data arriving at a MAG, does cause = much smaller problems in scalability than the stream replication at LMAs (avalanche problem)" o In the previous working group discussions, the terms "tunnel = convergence" and "avalanche problem" were used interchangeably. In this = paragraph they now seem to have different meanings. Also, scenario B = does not replicate streams at the LMA. Sincerely, Akbar, Juan-Carlos, Guang -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On = Behalf Of Thomas C. Schmidt Sent: Monday, May 31, 2010 6:13 PM To: multimob@ietf.org Subject: [multimob] Fwd:I-D = Action:draft-ietf-multimob-pmipv6-base-solution-02.txt Hi all, following the comments on the list, we just updated the draft. There=20 have been a number of editorial changes, but the core content remains=20 stable. Please find the updated version at=20 http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-02 and drop us your feedback. Thanks, Thomas On 01.06.2010 01:00, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Multicast Mobility Working Group of = the IETF. > > > Title : Base Deployment for Multicast Listener Support in = PMIPv6 Domains > Author(s) : T. Schmidt, et al. > Filename : draft-ietf-multimob-pmipv6-base-solution-02.txt > Pages : 20 > Date : 2010-05-31 > > This document describes deployment options for activating multicast > listener functions in Proxy Mobile IPv6 domains without modifying > mobility and multicast protocol standards. Similar to Home Agents in > Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, while Mobile Access Gateways > provide MLD proxy functions. In this scenario, Mobile Nodes remain > agnostic of multicast mobility operations. > > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solut= ion-02.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. > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob --=20 Prof. Dr. Thomas C. Schmidt =B0 Hamburg University of Applied Sciences Berliner = Tor 7 =B0 =B0 Dept. Informatik, Internet Technologies Group 20099 Hamburg, = Germany =B0 =B0 http://www.haw-hamburg.de/inet Fon: = +49-40-42875-8452 =B0 =B0 http://www.informatik.haw-hamburg.de/~schmidt Fax: = +49-40-42875-8409 =B0 _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jun 3 13:40:21 2010 Return-Path: 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 2E7EA3A6895 for ; Thu, 3 Jun 2010 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.627 X-Spam-Level: X-Spam-Status: No, score=0.627 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_50=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 WvXcNRoIjs8r for ; Thu, 3 Jun 2010 13:40:20 -0700 (PDT) Received: from web111409.mail.gq1.yahoo.com (web111409.mail.gq1.yahoo.com [67.195.15.180]) by core3.amsl.com (Postfix) with SMTP id 308383A63D3 for ; Thu, 3 Jun 2010 13:40:20 -0700 (PDT) Received: (qmail 84831 invoked by uid 60001); 3 Jun 2010 20:40:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275597604; bh=y5B0Ta0PdMPr0Kn/g1QXTxrRA436CH3c7dKOvM3Hs4U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CRFSVjrAx8XF706OKR+0jfDMW3QvcRn8XUvIDZvK8gdDhpN+Yrhy1eqZYv/XnZv8QErRgWy9Z1yVom5DoG75x5Q8jwxZjKAWrj9qRUt+WafVizvgtJbG/8Z+YJpMRbhLHlTg/5Hq5eP1nKc9NuQ3QRFL0VOeXzD3N13x8nyRJt8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hQo57ohbopOHAkeI4zjEEGCc+18ll2ZPROCZ1TY33V3uk5zOiO5/DDtDWLMyvpJX1e5ItOZhpcOmYwcvoZpobyLcST5CAIdF6akieislf//4sy+2ZHq9ORuuMa3rA1b0O8std6P5KH5PUS/7kYlivF+iGqbOPR9dlCIrajSZit8=; Message-ID: <467251.84048.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: M5wt7.QVM1nnObRBTO8BPmePuXx9upb_5VAfpvXoUOoJPf1 qjQBeGSRjmL1.DAThnYcq8Oe9_zIsOT_EY.XR.jNRmqVHwqIx7aEyq4rCvTf 7O3BalRPD1ZhKxjae8HI0ZWooGQNJ_K15xSQ5YNdwiVayM1FKz_XmkC0L0dF _7YPUFO26U_XWkgCZgzzLTvTvnx33jPGlWjzJUMpWIBfo8usJ00LU0hQ_0GU GT9_hdquVEgzoRwwSQQPaiV1Yn4izyF2kpct5rt3SlXT4YqVxtbdigKNogD7 9Z04Sj_KDbu58NJdcw8s- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 03 Jun 2010 13:40:04 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 Date: Thu, 3 Jun 2010 13:40:04 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Multimob WG Last Call on draft-ietf-multimob-pmipv6-base-solution 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: , X-List-Received-Date: Thu, 03 Jun 2010 20:40:21 -0000 All,=0A=0AThis message starts a 1-week Multimob Working Group Last Call on = advancing:=0ATitle=A0 =A0 =A0 =A0 =A0 : Base Deployment for Multicast Liste= ner Support in PMIPv6 Domains=0A=A0Author(s)=A0 =A0 =A0 : T. Schmidt, et al= .=0AFilename=A0 =A0 =A0 =A0 : draft-ietf-multimob-pmipv6-base-solution-02.t= xt=0APages=A0 =A0 =A0 =A0 =A0 : 20=0ADate=A0 =A0 =A0 =A0 =A0 =A0 : 2010-05-= 31=0A=0Aas a BCP.=A0 Some substantive comments have already been posted, pl= ease post yours if you have any.=A0 This last call will end on June 10, 201= 0.=0A=0ARegards,=0A=0AChairs=0A=0A=0A From schmidt@informatik.haw-hamburg.de Thu Jun 3 14:08:46 2010 Return-Path: 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 4D5903A6A45 for ; Thu, 3 Jun 2010 14:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_50=0.001, 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 ZD6i2hCKpueZ for ; Thu, 3 Jun 2010 14:08:45 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 21B033A6841 for ; Thu, 3 Jun 2010 14:08:44 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.197.167.14] (helo=[10.20.4.24]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OKHeO-0002KD-Od; Thu, 03 Jun 2010 23:08:30 +0200 Message-ID: <4C0819BE.80200@informatik.haw-hamburg.de> Date: Fri, 04 Jun 2010 00:08:14 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Behcet Sarikaya References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> In-Reply-To: <24001.82312.qm@web111415.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: Behcet Sarikaya , multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Thu, 03 Jun 2010 21:08:46 -0000 Hi Behcet, please see below: On 03.06.2010 22:36, Behcet Sarikaya wrote: > Hi Thomas, > Only a few issues left, I think we are getting there. > See below. > > Regards, > > Behcet > > > > ----- Original Message ---- >> From: Thomas C. Schmidt >> To: multimob@ietf.org >> Sent: Wed, June 2, 2010 8:33:28 AM >> Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt >> >> Hi Behcet, > >> from a thematic point of view, I've picked up the state of the >> discussion. > > Which ones? > > For example Section 1 Paragraph 3, you have not picked up and also not offering any explaination why. > In your new text you are making some statements that may not be correct. > ?? Unclear to me: what is incorrect? (There was only a clarification added about RFC3775 bi-directional tunneling which does not work for PMIPv6 as we all know. > Section 5.1 and 5.2 have not picked up. > 5.1/5.2 explain resp. give reference to the use of addressing in MLD. As destination addresses depend on the context of the messaging (as differently defined in RFCs 2710 and 3810), only the pointer is given in this overview. Regarding IPv4: This document is focused on PMIP*v6* - and there is an obvious correspondence between MLD and IGMP. I don't see much value in repeating the tables with the obvious changes ... but this is not a crucial part. It would just make the text longer. > About some informative references? > > >> Those not picked up (like the NAT) were already discussed on the >> list. > > I am not sure if it would be sufficient to only say that IGMP is supported analogously > > because IPv4 is different. > ??? Section 4.4. explains the analogy. > >> On the editorial side: I did not pick up the continuous spell out >> of all protocol names as this appears unusual and makes the document more >> difficult to read. (it should suffice to spell out PMIPv6 in the abstract and at >> its first use, but keep the well-known abbreviation the dozen other times) In >> addition, if there are nits on this level, the RFC-editor will take care of this >> before AUTH48. > > Are you saying that RFC 3775, 5213, 5844 are difficult to read? > No, I was referring to writing "Proxy Mobile IPv6" instead of PMIPv6 (likewise MLD) after the well-known abbreviations have been introduded in the draft. But that's only editorial details and will be guided by the RFC-Editor. Best, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Thu Jun 3 15:09:37 2010 Return-Path: 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 8E7E528C122 for ; Thu, 3 Jun 2010 15:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.585 X-Spam-Level: X-Spam-Status: No, score=0.585 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_50=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 7Il4p6iBpr3p for ; Thu, 3 Jun 2010 15:09:36 -0700 (PDT) Received: from web111404.mail.gq1.yahoo.com (web111404.mail.gq1.yahoo.com [67.195.15.150]) by core3.amsl.com (Postfix) with SMTP id B008C3A6A2A for ; Thu, 3 Jun 2010 15:09:36 -0700 (PDT) Received: (qmail 39191 invoked by uid 60001); 3 Jun 2010 22:09:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275602960; bh=cV7GWiyOUoq5VGR1ydE9eG2s5sytSez9VJMobfjH5iI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Yrvbebd/zMGjHBtzJ82IHCH2FnHDp4+dgpzFtYVfuP8+qD8q9wS9gd05RTNsF0s3YNAIJuuItsufwCw2ZH+8NDL3qoBaVsOHFdL8HzfvDjLpJpMdHF2Ihmp4aJBzQTKJCN0R4NmKixc8w7HmTGr9uxLMJIWSCDCXAWvcr7W8Fh8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1D+J7/ZoeXnaO65lJoWgliSfSd/MX64+Wc38I6CrWuEXhK8vr0zjLT9URkoFvUHD/uEhHtIvWDeGY15XI7wH1w0gC/MBA43p9DKanuYbb2cTeTu2PWLgjpqE689r9DjnNrZs/4PQdESUiYvCUouZRgT8GgzYda5oFbIpM1C8ZOk=; Message-ID: <739329.39085.qm@web111404.mail.gq1.yahoo.com> X-YMail-OSG: XECtGL8VM1kqOaPJFMuQzPFDX2TFPs7hJm03TOYVS4Psthk OPn.7_tInj.BAo7YOSw2uRX0LA1AfazWLVbf9vUm2w7zmvbhffu9f5Lxur07 9jJjiypVXv5WRagOfoWuozYfCHfZZTH_0OkApAc5oLGsu9DBbFVQNzlgIA2d _P66Ql8jHrtbg9uo9AW3BuoIiV_vAbCSreACRfyCo7Hxv20ZxYRF0xcReCc1 otHgfixchaQ2.K65EipAZ.PAPSS3sKvauvsNgCNUyCWj33fYEH9rHAw5CXI7 O09zYaG0qmXo8UYBLUoK2rA1UJ2pAEEiwncRtq1zb Received: from [206.16.17.212] by web111404.mail.gq1.yahoo.com via HTTP; Thu, 03 Jun 2010 15:09:20 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> Date: Thu, 3 Jun 2010 15:09:20 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4C0819BE.80200@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Thu, 03 Jun 2010 22:09:37 -0000 Hi Thomas,=0A=A0 Inline.=0A...........=0Asnipped=0A=0A> For example Section= 1 Paragraph 3, you have not picked up and also not offering =0A> any expla= ination why.=0A> In your new text you are making some statements =0A> that = may not be correct.=0A>=0A=0A> ?? Unclear to me: what is incorrect? =0A> (T= here was only a clarification =0Aadded about RFC3775 bi-directional tunneli= ng =0A> which does not work for =0APMIPv6 as we all know.=0A=0AIt depends o= n what you wish to say.=0ABased on what I could see, I suggested the follow= ing:=0A[behcet] The above paragraph needs to be rewritten to state that PMI= Pv6 does not explicitly address multicast communication. =0AIt was a choice= to design multicast extension for PMIPv6 similar to MIPv6 but due to the i= nefficiencies=0Ainvolved in bi-directional home tunneling a proxy based sol= ution described in this document has=0Ainstead been opted for. =0A[behcet] = please add several sentences on why proxy approach is better (as has been d= iscussed on ML).=0A=0AThe above would solve the problem and make the text m= uch clearer.=0A=0A=0A> Section 5.1 and =0A> 5.2 have not picked up.=0A>=0A= =0A> 5.1/5.2 explain resp. give reference to =0A> the use of addressing in = MLD. As =0Adestination addresses depend on the context =0A> of the messagin= g (as =0Adifferently defined in RFCs 2710 and 3810), only the =0A> pointer = is given in =0A> this overview.=0A=0AIf that is the case then state the spe= cific values for each, I don't think MLD has a million different messages.= =0A=0A=0AIn a section that is about Message Source and Destination Address= =0Awe also need multicast data (but v6 and v4) information, this is missing= .=0A=0A=0A> Regarding IPv4: This document is =0A> focused on PMIP*v6* - and= there is an =0Aobvious correspondence between MLD and =0A> IGMP. I don't s= ee much value in =0Arepeating the tables with the obvious =0A> changes ... = but this is not a =0Acrucial part. It would just make the text =0A> longer.= =0A=0AWhy not? It is some useful detail.=0A=0AHow do multicast data packets= look like is missing as I said above.=A0=0A=0A=0A> About some informative = =0A> references?=0A>=0A>=0A>> Those not picked up (like the NAT) were =0A> = already discussed on the=0A>> list.=0A>=0A> I am not sure if it =0A> would = be sufficient to only say that IGMP is supported =0A> analogously=0A>=0A> b= ecause IPv4 is different.=0A>=0A=0A> ??? =0A> Section 4.4. explains the ana= logy.=0A=0AYes this helps.=0AYou should add=A0one paragraph there on RFC 51= 35.=0A=0A>=0A>> On the editorial =0A> side: I did not pick up the continuou= s spell out=0A>> of all protocol =0A> names as this appears unusual=A0 and = makes the document more=0A>> =0A> difficult to read. (it should suffice to = spell out PMIPv6 in the abstract and =0A> at=0A>> its first use, but keep t= he well-known abbreviation the dozen =0A> other times) In=0A>> addition, if= there are nits on this level, the =0A> RFC-editor will take care of this= =0A>> before AUTH48.=0A>=0A> Are =0A> you saying that RFC 3775, 5213, 5844 = are difficult to read?=0A>=0A=0A> No, I =0A> was referring to writing "Prox= y Mobile IPv6" instead of PMIPv6 =0A(likewise =0A> MLD) after the well-know= n abbreviations have been introduded =0Ain the draft. =0A> But that's only = editorial details and will be guided by =0Athe =0A> RFC-Editor.=0A=0AIt is = up to you but I think it is good practive to follow these well known RFCs. = Besides it is very easy to do it.=0A=0A=0A From behcetsarikaya@yahoo.com Thu Jun 3 15:19:41 2010 Return-Path: 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 DA0A63A6A2A for ; Thu, 3 Jun 2010 15:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=2.219, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, 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 W5xPtphh1T56 for ; Thu, 3 Jun 2010 15:19:31 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id BA98B3A69F3 for ; Thu, 3 Jun 2010 15:19:29 -0700 (PDT) Received: (qmail 20499 invoked by uid 60001); 3 Jun 2010 22:19:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275603555; bh=msiQEkIB79b3w2olV5FvQ1hX2XEKwcyXE0RXMxmvdQk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZeebZbnmKyIKAWfiTeJyHICejYwv2dPtDY83tx1eQWqHaadVU7Me/zaNqy08Ku9KganzXFFYP49rFBZzgIWYcdNQ/eQKkJ3ThcUetQcOphrUEkZTH2RBEEd6xT4k40r6EE8aBNyJp6EAnJH+MP6OmcTCDnh5vT6JYcqki9c1TSE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=fRImVIARCqZtbrKwbzCb67pUsPtcOP8suTn13MrHeMvsSTGSyAZKyyucclQjE+C1ZlzadAfFiOQbbmkPbvGZJsNO0Kfhn/8XDqRUag8GIVB4WeUO81mDTqKgKnYwtoKb6Cr50b0xzAku/tHh4E+YRw6JndyViWfk/h2GoNuLA3c=; Message-ID: <931041.20150.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: Eu._TqgVM1mPY1S301ZkWvHzDkRIFn.1jkTEo.a01ARjL_Y AqT0WHh7p2wBm3GzVqtUGbGUz9DkKB_oZJFRzaC13xd4DYE852qKRCOMF.SD zA8N.vx17a9Jo7HXSCqQNQ48aM3ultmwTCRcHDy95qo38DoB3a8Xoo5tTbON ABNXysnJMUDfnpq5bLSim5OT5Sfmckt4WEibgEiNjhRqUuHXGEuYZZmRSvXS h8nJqWhG._CwGxuhO4ROS9b2dtMNHoaNcA.5nB_ikYT_Wpw8tiu7QeJOlvHm bNja.PSp1SmE7DPN0WdniIqjGb5jpG_e35g.kYMYYFufQEDQL7DvktlUt2GR UlUC.8eHL1yXZ.nqq.TMCobbF9g-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Thu, 03 Jun 2010 15:19:15 PDT X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680 Date: Thu, 3 Jun 2010 15:19:15 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [multimob] Fw: IETF 78 - Meeting and Sponsorship Information 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: , X-List-Received-Date: Thu, 03 Jun 2010 22:19:41 -0000 78th IETF Meeting =0AMaastricht, Netherlands=0AJuly 25-30, 2010 =0A=0A1. Sp= onsorship Opportunities=0A2. Registration Types=0A3. Visas and Letters of I= nvitation=0A4. Accommodations & Breakfast Information=0A5. IETF 79 (Beijing= ) Visa Information=0A=0A1) Sponsorship Opportunities=0AThere are still spon= sorship opportunities and benefits for high profile=0Acompany/organizationa= l exposure at the upcoming IETF meeting in=0AMaastricht, Netherlands from J= uly 25-30, 2010.=C2=A0 All sponsorship fees go=0Adirectly to fund the opera= tions of the IETF.=C2=A0 See the options at:=0Ahttp://www.ietf.org/meeting/= 78/index.html =E2=80=9CSponsorship Opportunities=E2=80=9D=0Aunder =E2=80=9C= General=E2=80=9D.=C2=A0 Each of the sponsorship options provide extended an= d=0Arepeat exposure at this weeklong meeting.=C2=A0 =0A=0APlease contact Dr= ew Dvorshak, dvorshak@isoc.org, with any questions=0Aand/or to reserve your= organization=E2=80=99s spot.=C2=A0 Thanks in advance for=0Asupporting the = critical work of the IETF!=0A=0A2) Register online at:=C2=A0 http://www.iet= f.org/meetings/78/=0A=0A3) Letters of Invitation and Visas =0ALetters of In= vitation=0AAfter you complete the meeting registration process, you will be= given the=0Aoption to request a letter of invitation. You can request the = Letter of=0AInvitation as soon as you finish registration, or at a later ti= me by=0Afollowing the link provided in the confirmation email.=0A=0AVisas= =0APlease check the Netherlands Ministry of Foreign Affairs site=0A(http://= www.minbuza.nl/en/Services/Consular_Services/Visa) for list of=0Acountries = with visa exemptions.=0A=0AWe recommend you give yourself at least one mont= h to complete the visa=0Aprocess.=0A=0A4) Accommodations & Breakfast Inform= ation=0Ahttp://www.ietf.org/meeting/78/hotel.html=0A=0A5) If you want to st= art planning for your trip to IETF 79 in Beijing, we=0Ahave visa informatio= n online here:=0Ahttp://www.ietf.org/meeting/79/visa.html=0A=0AOnly 52 days= until IETF 78!=0A=0A=0A=0A From schmidt@informatik.haw-hamburg.de Fri Jun 4 04:14:27 2010 Return-Path: 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 D36EB3A696C for ; Fri, 4 Jun 2010 04:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.416 X-Spam-Level: X-Spam-Status: No, score=-0.416 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_50=0.001, 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 KaqaOoPhobKX for ; Fri, 4 Jun 2010 04:14:25 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 8E9C53A692E for ; Fri, 4 Jun 2010 04:14:24 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.197.167.14] (helo=[10.20.4.233]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OKUqn-000PXl-Rp; Fri, 04 Jun 2010 13:14:10 +0200 Message-ID: <4C08DFFD.90205@informatik.haw-hamburg.de> Date: Fri, 04 Jun 2010 14:14:05 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Rahman, Akbar" References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Fri, 04 Jun 2010 11:14:28 -0000 Hi Akbar, thanks for your careful review: please see inline (marked with [Thomas=>). On 03.06.2010 23:12, Rahman, Akbar wrote: > > Thank you for the updates, and for addressing our previous comments. Overall the document looks in good shape. We have the following comments and suggestions for your consideration for any future update: > > - Section 1 > o In the 3rd paragraph, the key (background) motivation point of what multicast is supported in PMIPv6 and MIPv6 is mentioned as follows: > > "[RFC5213] does not explicitly address > multicast communication and thus relies on the minimal multicast > support provided by MIPv6. But unfortunately, bi-directional home > tunneling, the minimal multicast support arranged by MIPv6, cannot be > applied in network-based management scenarios, since a mobility- > unaware node will not initiate such a tunnel after movement." > > o However, the second sentence above is very hard to decipher and should be re-worded to make it more understandable. Also the above two sentences taken together seem to imply that there is a fault in RFC5213 (i.e. that RFC5213 suggests to use MIPv6 multicast approach but that this is not intrinsically possible by the MN since it is unaware of network mobility). Was that the intent? > [Thomas=> :-) ... this sentence is the result of too many change requests. It actually explains a trivial observation, but there seems to be surprisingly little clearness about "Why PMIP needs a dedicated multicast treatment" ... Here is our replacement: " Multicast routing functions need to be placed carefully within the PMIPv6 domain to augment unicast transmission with group communication services. does not explicitly address multicast communication. Bi-directional home tunneling, the minimal multicast support arranged by MIPv6, cannot be directly transfered to network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. Consequently, even a minimal multicast listener support in PMIPv6 domains requires an explicit deployment of additional functions." > > - Figure 2 > o The Rtr Adv reply to the Rtr Sol is missing O.K., we added it. > o MN2 moves to MAG2. However it is not clear where the arrow "Movement to MAG2& PMIP Binding Update" points to. > "< Movement to MAG2 & PMIP Binding Update >" does not contain an arrow, but is an explanatory comment in a common notation form. > > - Section 3 > o The paragraph talking about IPv4 ("These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Support > Don't think so: Section 3 is the Overview, so redundant in topic (but of reduced details) to section 4. IMHO it is perfectly o.k. to already mention IPv4 in the overview (as we mention MAG and LMA ...) > > - Section 4.5 > o This section on multi-homing is clear on the details of PMIPv6 operation over the multiple interfaces of an MN. However, what was not clear was how the multicast application would operate and react if it got, for example, the same multicast group subscription over the multiple interfaces? Could you add some more explanatory description as for example your description in section 3 "It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses ..."] [Thomas=> There are two things to note here, which are completely independent of mobility: (i) An application can choose (via the socket API), how and where to join a multicast group. It does not need to do this explicitly, but it is free to do and there is no general rule ... (ii) A multicast client application is supposed to be robust with respect to packet loss, duplication etc. It is a UDP receiver. There is not much more to say about it ... We included some discussion on multihoming, n-casting, interface treatment and transport in RFC 5757, but I don't think we should repeat this - it is a very general Multicast/UDP discussion/observation. And 5757 is referenced ;) > > > - Appendix C: > o In the Appendix it states: > "For scenario A it should be also noted that the > high stream replication requirements at LMAs in setting 1 can be > attenuated by deploying additional LMAs in a PMIP domain, while > scenario B does not allow for distributing the LMA-M, as no handover > management is available at LMA-M." > > o Please note in our latest draft (draft-zuniga-multimob-smspmip-03, section 3.1) we clarify that multiple LMA-M's can be deployed to address the scalability issue. So the key difference between scenarios A and B is that in scenario B we separate the unicast and multicast paths (and not in the number of LMAs) [Thomas=> From the Diff I see that you added: "Note that there can multiple LMAs for unicast traffic (not shown in Figure 1) in a given PMIPv6 domain. Similarly, more than one multicast dedicated LMA can be deployed by the operator (not shown in Figure 1)." This is just a claim. [Thomas=> As we have discussed several times (in meetings and on the list), the core problem with the "Dedicated LMA" solution is that it carries the wrong name. This is not an LMA as it has no MN-states, and it cannot perform handover management, which would be needed in the case of several LMAs serving different groups or MNs. So this "Dedicated LMA" is actually only a Multicast DR (see Section 4.6 in draft-ietf-multimob-pmipv6-base-solution-02.txt for a more general explanation) - and this has no notion of mobility and consequently cannot perform handovers. Thus it needs to be a centralized entity (free of handovers) within one PMIP domain. IMHO, a future discussion on optimizing solutions should actually treat the field of "direct multicast access" as a whole, i.e. by considering a flat network access (like in draft-seijon), static tunnels like in your draft, or dynamic tunneling via AMT. But that's another story. > > o In the Appendix it states: > > "These considerations of extremal settings show that tunnel > convergence, i.e., duplicate data arriving at a MAG, does cause much > smaller problems in scalability than the stream replication at LMAs > (avalanche problem)" > > o In the previous working group discussions, the terms "tunnel convergence" and "avalanche problem" were used interchangeably. In this paragraph they now seem to have different meanings. Also, scenario B does not replicate streams at the LMA. [Thomas=> The terms "tunnel convergence problem" and "avalanche problem" have not been coined by us. Actually, they come from the MIPv4 area where you have this FoA etc. The definition is very simple: o An entity that has very many outgoing tunnels (needs to send data to many tunnel interfaces) suffers from an "avalanche problem". o An entity that has very many incoming tunnel interfaces (needs to receive (possibly replicated) data from many tunnel interfaces) has to deal with a "tunnel convergence problem". Aside from this, these are just names. However, one should use the names correctly, I suppose. Best wishes, Thomas > > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behalf Of Thomas C. Schmidt > Sent: Monday, May 31, 2010 6:13 PM > To: multimob@ietf.org > Subject: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt > > Hi all, > > following the comments on the list, we just updated the draft. There > have been a number of editorial changes, but the core content remains > stable. > > Please find the updated version at > http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-02 > > and drop us your feedback. > > Thanks, > > Thomas > > On 01.06.2010 01:00, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Multicast Mobility Working Group of the IETF. >> >> >> Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains >> Author(s) : T. Schmidt, et al. >> Filename : draft-ietf-multimob-pmipv6-base-solution-02.txt >> Pages : 20 >> Date : 2010-05-31 >> >> This document describes deployment options for activating multicast >> listener functions in Proxy Mobile IPv6 domains without modifying >> mobility and multicast protocol standards. Similar to Home Agents in >> Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as >> multicast subscription anchor points, while Mobile Access Gateways >> provide MLD proxy functions. In this scenario, Mobile Nodes remain >> agnostic of multicast mobility operations. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-02.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. >> >> >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Fri Jun 4 04:53:59 2010 Return-Path: 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 B1C833A698D for ; Fri, 4 Jun 2010 04:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_50=0.001, 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 umxEnCRnYle9 for ; Fri, 4 Jun 2010 04:53:58 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 860013A691F for ; Fri, 4 Jun 2010 04:53:58 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.197.167.14] (helo=[10.20.4.233]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OKVT5-0008sd-Qa for multimob@ietf.org; Fri, 04 Jun 2010 13:53:44 +0200 Message-ID: <4C08E943.8050502@informatik.haw-hamburg.de> Date: Fri, 04 Jun 2010 14:53:39 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: multimob@ietf.org References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> In-Reply-To: <739329.39085.qm@web111404.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Fri, 04 Jun 2010 11:53:59 -0000 Hi Behcet, please see inline. On 04.06.2010 01:09, Behcet Sarikaya wrote: > Hi Thomas, > Inline. > ........... > snipped > >> For example Section 1 Paragraph 3, you have not picked up and also not offering >> any explaination why. >> In your new text you are making some statements >> that may not be correct. >> > >> ?? Unclear to me: what is incorrect? >> (There was only a clarification > added about RFC3775 bi-directional tunneling >> which does not work for > PMIPv6 as we all know. > > It depends on what you wish to say. > Based on what I could see, I suggested the following: > [behcet] The above paragraph needs to be rewritten to state that PMIPv6 does not explicitly address multicast communication. > It was a choice to design multicast extension for PMIPv6 similar to MIPv6 but due to the inefficiencies > involved in bi-directional home tunneling a proxy based solution described in this document has > instead been opted for. > [behcet] please add several sentences on why proxy approach is better (as has been discussed on ML). > > The above would solve the problem and make the text much clearer. > [Thomas=> A rewording has been done (see previous mail). > >> Section 5.1 and >> 5.2 have not picked up. >> > >> 5.1/5.2 explain resp. give reference to >> the use of addressing in MLD. As > destination addresses depend on the context >> of the messaging (as > differently defined in RFCs 2710 and 3810), only the >> pointer is given in >> this overview. > > If that is the case then state the specific values for each, I don't think MLD has a million different messages. > [Thomas=> Unclear: if you (or any reader) wants to know about the details of MLD, you should read the corresponding document. There is no sense (and for good reasons no practice) to retell the content of previous RFCs. This would only be a source of misunderstandings. > >> Regarding IPv4: This document is >> focused on PMIP*v6* - and there is an > obvious correspondence between MLD and >> IGMP. I don't see much value in > repeating the tables with the obvious >> changes ... but this is not a > crucial part. It would just make the text >> longer. > > Why not? It is some useful detail. [Thomas=> I don't see the point. This draft is about deployment and not implementation. Readers should get the idea of what is happening in the network, but should not be guided to re-implement IGMP or MLD. However, this seems to turn into a matter of taste. Maybe we should follow a third party advise - Stig, what would you consider more appropriate: additional IGMP address tables or not? >> ??? >> Section 4.4. explains the analogy. > > Yes this helps. > You should add one paragraph there on RFC 5135. > [Thomas=> As discussed: this sentence could only be "RFC 5135 plays no role here" ... So I guess we are pretty much through ... Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Fri Jun 4 08:08:21 2010 Return-Path: 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 9313A3A6800 for ; Fri, 4 Jun 2010 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_50=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 8UHdfrfjgLkl for ; Fri, 4 Jun 2010 08:08:20 -0700 (PDT) Received: from web111412.mail.gq1.yahoo.com (web111412.mail.gq1.yahoo.com [67.195.15.198]) by core3.amsl.com (Postfix) with SMTP id AD9B73A6839 for ; Fri, 4 Jun 2010 08:08:20 -0700 (PDT) Received: (qmail 92868 invoked by uid 60001); 4 Jun 2010 15:08:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275664083; bh=fshJqBbGylfZoIHPVARBLlAC0z4ZucPN5CNoz0T2vH0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u6zyFxM/YfCU0VFyg+wMLz+u25G8psZ5km/IKX5exF3S4Ztngaf+RWwy2G9Jkdj3s08fZNtI5jWmzQ1qDadn+5bryGIbAvMCp4N+PIaeVQE5/KbKX+B8vtmIlZnRWlVGv8ZJZwX52t6S0pDcBOxGsTdAi4CQ3l3NRzOrMoRGv7M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=12Ygw1vqsMzfZTCmvOGif+tExAXZunSUnPw+t6ndV2oekPfW2UGGTHP5wO0UrYJes29m0w0T2gs7QebjWbzUqbzGstrjSkVTztKngR6/JBn6Hf8cBdTOISvMiYToSanLyXh/ZQccZIMymFC0dwJnp9OMcXp/SZDth+y2jOM6d+o=; Message-ID: <470436.92236.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: EF4pIu4VM1k54R9.vZCa3ujBG1kHvE8GtHQG6t.Gy6EXGCr NbMtFbb7UbZIbb0tKt_KlaP2SeguRCfqrCCJZczshl.O5SQKXkVX8mBYwnvI gIUI3DO73qJzMBpbrgbxP.jTLsQmXOG_lwnw10qgYx5lpRn1.KzkthDWhK2Z 7wtTz4HviJ.WKBZDqNSMapxDc0Sgcht2XBpS0JwAIh6xio4IVfz7vGWOIb1W LlwUpLRDXMtRBiapk4HuKef36NkwvX0j.xu2C2W09bT1Xg6KVKSgLcSZXIO4 dxeQXvO_whStcLcW_7KkNPAYAnK9e3mTPTMnwhDbq Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Fri, 04 Jun 2010 08:08:03 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> Date: Fri, 4 Jun 2010 08:08:03 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" , multimob@ietf.org In-Reply-To: <4C08E943.8050502@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Fri, 04 Jun 2010 15:08:21 -0000 Hi Thomas,=0A=A0 See inline.=0A=0A=0A=0A>> For example Section 1 Paragraph = =0A> 3, you have not picked up and also not offering=0A>> any explaination = =0A> why.=0A>> In your new text you are making some statements=0A>> =0A> th= at may not be correct.=0A>>=0A>=0A>> ?? Unclear to me: what =0A> is incorre= ct?=0A>> (There was only a clarification=0A> added about =0A> RFC3775 bi-di= rectional tunneling=0A>> which does not work for=0A> =0A> PMIPv6 as we all = know.=0A>=0A> It depends on what you wish to =0A> say.=0A> Based on what I = could see, I suggested the following:=0A> =0A> [behcet] The above paragraph= needs to be rewritten to state that PMIPv6 does not =0A> explicitly addres= s multicast communication.=0A> It was a choice to design =0A> multicast ext= ension for PMIPv6 similar to MIPv6 but due to the =0A> inefficiencies=0A> i= nvolved in bi-directional home tunneling a proxy based =0A> solution descri= bed in this document has=0A> instead been opted for.=0A> =0A> [behcet] plea= se add several sentences on why proxy approach is better (as has =0A> been = discussed on ML).=0A>=0A> The above would solve the problem and =0A> make t= he text much clearer.=0A>=0A=0A> [Thomas=3D> A rewording has been =0A> done= (see previous mail).=0A=0A[behcet]=0AYou mean the current text? Current=A0= text in -02=A0is not correct and unfortunately not acceptable. MIPv6 based = solution was proposed as you know. That solution was not worked out in the = working group. What gives you freedom to speculate on that proposal without= even referencing the draft?=0AWhy are you not then speculating about 3 or = 4 other proposals that have not been selected?=0A=0ASorry but this is total= ly inacceptable.=0A=0A=0A>=0A>> Section 5.1 and=0A>> =0A> 5.2 have not pick= ed up.=0A>>=0A>=0A>> 5.1/5.2 explain resp. =0A> give reference to=0A>> the = use of addressing in MLD. As=0A> =0A> destination addresses depend on the c= ontext=0A>> of the messaging =0A> (as=0A> differently defined in RFCs 2710 = and 3810), only the=0A>> =0A> pointer is given in=0A>> this overview.=0A>= =0A> If that is the =0A> case then state the specific values for each, I do= n't think MLD has a million =0A> different messages.=0A>=0A=0A>[Thomas=3D> = Unclear: if you (or any reader) =0A> wants to know about the =0Adetails of = MLD, you should read the corresponding =0A> document. There is no =0Asense = (and for good reasons no practice) to retell the =0A> content of =0Apreviou= s RFCs. This would only be a source of =0A> misunderstandings.=0A=0A[behcet= ]=0ABy the way, I read those RFCs. Thank you for your advice :-)!=0A=0AHowe= ver, I find it strange to give a whole RFC of 61 pages (3810) to figure out= what the destination address will be. Plus 22 pages for 2710.=0A=0AYou cre= ated this problem you should correct it. See more below.=0A=0A=0A=0A>=0A>> = Regarding IPv4: This document =0A> is=0A>> focused on PMIP*v6* - and there = is an=0A> obvious =0A> correspondence between MLD and=0A>> IGMP. I don't se= e much value =0A> in=0A> repeating the tables with the obvious=0A>> changes= ... but =0A> this is not a=0A> crucial part. It would just make the text= =0A>> =0A> longer.=0A>=0A> Why not? It is some useful detail.=0A=0A> [Thoma= s=3D> I =0A> don't see the point. This draft is about deployment and not = =0Aimplementation. =0A> Readers should get the idea of what is happening in= the =0Anetwork, but should =0A> not be guided to re-implement IGMP or MLD.= =0A=0A[behcet]=0AHere you are contradicting yourself.=0A=0AWhy have Section= s 5.1 and 5.2 then? It was you who included them, all I am asking is to mak= e it more clear and complete.=0A=0A> However, this seems to turn =0A> into = a matter of taste. Maybe we should =0Afollow a third party advise - Stig, = =0A> what would you consider more =0Aappropriate: additional IGMP address t= ables or =0A> not?=0A=0A[behcet]=0AThere is no third party here. We are a w= orking group and WG has members. I posted my comments as=A0a member of WG= =A0not as chair's comments.=0A=0AI don't know what you are talking about? C= an you explain?=0A=0A=0A>> ???=0A>> Section 4.4. explains the =0A> analogy.= =0A>=0A> Yes this helps.=0A> You should add one paragraph =0A> there on RFC= 5135.=0A>=0A=0A> [Thomas=3D> As discussed: this sentence could =0A> only b= e "RFC 5135 plays no =0Arole here" ...=0A=0A[behcet]=0AEven that would be u= seful.=0A=0A=0A From schmidt@informatik.haw-hamburg.de Fri Jun 4 08:25:39 2010 Return-Path: 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 D53073A67A3 for ; Fri, 4 Jun 2010 08:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_50=0.001, 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 XdqWlWB6p0K3 for ; Fri, 4 Jun 2010 08:25:38 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 1AC393A6405 for ; Fri, 4 Jun 2010 08:25:37 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [213.197.167.14] (helo=[10.20.4.233]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OKYlu-00012P-S1; Fri, 04 Jun 2010 17:25:23 +0200 Message-ID: <4C091ADE.7080703@informatik.haw-hamburg.de> Date: Fri, 04 Jun 2010 18:25:18 +0300 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Behcet Sarikaya References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <470436.92236.qm@web111412.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: Behcet Sarikaya , multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Fri, 04 Jun 2010 15:25:39 -0000 Hi Behcet, only brief, as there is no progress: On 04.06.2010 18:08, Behcet Sarikaya wrote: >>> For example Section 1 Paragraph >> 3, you have not picked up and also not offering >>> any explaination >> why. >>> In your new text you are making some statements >>> >> that may not be correct. >>> >> >>> ?? Unclear to me: what >> is incorrect? >>> (There was only a clarification >> added about >> RFC3775 bi-directional tunneling >>> which does not work for >> >> PMIPv6 as we all know. >> >> It depends on what you wish to >> say. >> Based on what I could see, I suggested the following: >> >> [behcet] The above paragraph needs to be rewritten to state that PMIPv6 does not >> explicitly address multicast communication. >> It was a choice to design >> multicast extension for PMIPv6 similar to MIPv6 but due to the >> inefficiencies >> involved in bi-directional home tunneling a proxy based >> solution described in this document has >> instead been opted for. >> >> [behcet] please add several sentences on why proxy approach is better (as has >> been discussed on ML). >> >> The above would solve the problem and >> make the text much clearer. >> > >> [Thomas=> A rewording has been >> done (see previous mail). > > [behcet] > You mean the current text? Current text in -02 is not correct and unfortunately not acceptable. MIPv6 based solution was proposed as you know. That solution was not worked out in the working group. What gives you freedom to speculate on that proposal without even referencing the draft? > Why are you not then speculating about 3 or 4 other proposals that have not been selected? > > Sorry but this is totally inacceptable. > [Thomas => I guess it is time to re-approach reality: 1. The text has never been incorrect, but supposedly hard to parse. In particular, MIPv6 bi-directional tunneling just does not work in PMIPv6 - and has never been proposed in a document 2. We had the text reworded (sent in a previous mail today) as: " Multicast routing functions need to be placed carefully within the PMIPv6 domain to augment unicast transmission with group communication services. does not explicitly address multicast communication. Bi-directional home tunneling, the minimal multicast support arranged by MIPv6, cannot be directly transfered to network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. Consequently, even a minimal multicast listener support in PMIPv6 domains requires an explicit deployment of additional functions." ... and I guess that's about it. Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Akbar.Rahman@InterDigital.com Mon Jun 7 12:40:30 2010 Return-Path: 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 EDA073A67C0 for ; Mon, 7 Jun 2010 12:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 zjUcv3OHNWUZ for ; Mon, 7 Jun 2010 12:40:29 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 1F3AA3A63CB for ; Mon, 7 Jun 2010 12:40:22 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 15:40:23 -0400 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jun 2010 15:40:23 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Jun 2010 15:40:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <4C08DFFD.90205@informatik.haw-hamburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt Thread-Index: AcsD1xAgoF1YJVvVSGWUHYcXRxVNIwCn/ajw References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <4C08DFFD.90205@informatik.haw-hamburg.de> From: "Rahman, Akbar" To: "Thomas C. Schmidt" X-OriginalArrivalTime: 07 Jun 2010 19:40:23.0236 (UTC) FILETIME=[4538F040:01CB0679] Cc: multimob@ietf.org Subject: Re: [multimob] Fwd:I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Mon, 07 Jun 2010 19:40:31 -0000 Hi Thomas, Thanks for the prompt reply. Below is my feedback (marked with **** Akbar =3D>). Sincerely, Akbar -- snip --- [Thomas=3D> :-) ... this sentence is the result of too many change requests. It=20 actually explains a trivial observation, but there seems to be=20 surprisingly little clearness about "Why PMIP needs a dedicated=20 multicast treatment" ... Here is our replacement: " Multicast routing functions need to be placed carefully within the=20 PMIPv6 domain to augment unicast transmission with group communication=20 services. does not explicitly address=20 multicast communication. Bi-directional home tunneling, the minimal=20 multicast support arranged by MIPv6, cannot be directly transfered to=20 network-based management scenarios, since a mobility-unaware node will=20 not initiate such a tunnel after movement. Consequently, even a minimal=20 multicast listener support in PMIPv6 domains requires an explicit=20 deployment of additional functions." **** Akbar =3D> Okay. > > - Figure 2 > o The Rtr Adv reply to the Rtr Sol is missing O.K., we added it. **** Akbar =3D> Thanks. > o MN2 moves to MAG2. However it is not clear where the arrow "Movement to MAG2& PMIP Binding Update" points to. > "< Movement to MAG2 & PMIP Binding Update >" does not contain an arrow,=20 but is an explanatory comment in a common notation form. **** Akbar =3D> Okay, but you may want to consider stretching the = comment to include the whole line as otherwise other readers may have the same confusion as us. But we leave that to your good judgment. > > - Section 3 > o The paragraph talking about IPv4 ("These multicast deployment considerations likewise apply for mobile nodes that operate with their IPv4 stack ...") seems to fit in better in section 4.4 IPv4 Support > Don't think so: Section 3 is the Overview, so redundant in topic (but of reduced details) to section 4. IMHO it is perfectly o.k. to already=20 mention IPv4 in the overview (as we mention MAG and LMA ...) **** Akbar =3D> Okay. > > - Section 4.5 > o This section on multi-homing is clear on the details of PMIPv6 operation over the multiple interfaces of an MN. However, what was not clear was how the multicast application would operate and react if it got, for example, the same multicast group subscription over the multiple interfaces? Could you add some more explanatory description as for example your description in section 3 "It will submit MLD Report and Done messages, based on application triggers, using its link-local source address and multicast destination addresses ..."] [Thomas=3D> There are two things to note here, which are completely=20 independent of mobility: (i) An application can choose (via the socket API), how and where to=20 join a multicast group. It does not need to do this explicitly, but it=20 is free to do and there is no general rule ... (ii) A multicast client application is supposed to be robust with=20 respect to packet loss, duplication etc. It is a UDP receiver. There is=20 not much more to say about it ... We included some discussion on multihoming, n-casting, interface=20 treatment and transport in RFC 5757, but I don't think we should repeat=20 this - it is a very general Multicast/UDP discussion/observation. And=20 5757 is referenced ;) **** Akbar =3D> Okay, but perhaps at least you could add the reference = to RFC 5757 in this section. I found it useful to read (and only went to re-read it after your comment). Again, I leave it to your good judgment to make the final decision. > > > - Appendix C: > o In the Appendix it states: > "For scenario A it should be also noted that the > high stream replication requirements at LMAs in setting 1 can be > attenuated by deploying additional LMAs in a PMIP domain, while > scenario B does not allow for distributing the LMA-M, as no handover > management is available at LMA-M." > > o Please note in our latest draft (draft-zuniga-multimob-smspmip-03, section 3.1) we clarify that multiple LMA-M's can be deployed to address the scalability issue. So the key difference between scenarios A and B is that in scenario B we separate the unicast and multicast paths (and not in the number of LMAs) [Thomas=3D> From the Diff I see that you added: "Note that there can multiple LMAs for unicast traffic (not shown in=20 Figure 1) in a=09 given PMIPv6 domain. Similarly, more than one multicast dedicated LMA=09 can be deployed by the operator (not shown in Figure 1)." This is just a claim. [Thomas=3D> As we have discussed several times (in meetings and on the=20 list), the core problem with the "Dedicated LMA" solution is that it=20 carries the wrong name. This is not an LMA as it has no MN-states, and=20 it cannot perform handover management, which would be needed in the case of several LMAs serving different groups or MNs. So this "Dedicated LMA" is actually only a Multicast DR (see Section 4.6 in draft-ietf-multimob-pmipv6-base-solution-02.txt for a more general=20 explanation) - and this has no notion of mobility and consequently=20 cannot perform handovers. Thus it needs to be a centralized entity (free of handovers) within one PMIP domain. IMHO, a future discussion on optimizing solutions should actually treat=20 the field of "direct multicast access" as a whole, i.e. by considering a flat network access (like in draft-seijon), static tunnels like in your=20 draft, or dynamic tunneling via AMT. But that's another story. **** Akbar =3D> You are right that we have discussed it several times. Our proposal is not a simply a Multicast DR (as you also acknowledge in your Appendix C). We have mentioned several times that we will have some PMIP impacts to provide us mobility multicast management. We will provide these details in our next draft. > > o In the Appendix it states: > > "These considerations of extremal settings show that tunnel > convergence, i.e., duplicate data arriving at a MAG, does cause much > smaller problems in scalability than the stream replication at LMAs > (avalanche problem)" > > o In the previous working group discussions, the terms "tunnel convergence" and "avalanche problem" were used interchangeably. In this paragraph they now seem to have different meanings. Also, scenario B does not replicate streams at the LMA. [Thomas=3D> The terms "tunnel convergence problem" and "avalanche = problem" have not been coined by us. Actually, they come from the MIPv4 area=20 where you have this FoA etc. The definition is very simple: o An entity that has very many outgoing tunnels (needs to send data to many tunnel interfaces) suffers from an "avalanche problem". o An entity that has very many incoming tunnel interfaces (needs to=20 receive (possibly replicated) data from many tunnel interfaces) has to=20 deal with a "tunnel convergence problem". Aside from this, these are just names. However, one should use the names correctly, I suppose. **** Akbar =3D> Okay. --- snip --- From stig@venaas.com Tue Jun 8 10:27:59 2010 Return-Path: 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 A801E3A68C3 for ; Tue, 8 Jun 2010 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 qzjjgXb3FBR0 for ; Tue, 8 Jun 2010 10:27:58 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 086243A67E7 for ; Tue, 8 Jun 2010 10:27:58 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c] (unknown [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c]) by ufisa.uninett.no (Postfix) with ESMTPSA id 226C58136; Tue, 8 Jun 2010 19:27:56 +0200 (CEST) Message-ID: <4C0E7D9B.6060709@venaas.com> Date: Tue, 08 Jun 2010 10:27:55 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Thomas C. Schmidt" References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C091ADE.7080703@informatik.haw-hamburg.de> In-Reply-To: <4C091ADE.7080703@informatik.haw-hamburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Behcet Sarikaya , multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Tue, 08 Jun 2010 17:27:59 -0000 Thomas C. Schmidt wrote: > Hi Behcet, > > only brief, as there is no progress: > > On 04.06.2010 18:08, Behcet Sarikaya wrote: > >>>> For example Section 1 Paragraph >>> 3, you have not picked up and also not offering >>>> any explaination >>> why. >>>> In your new text you are making some statements >>>> >>> that may not be correct. >>>> >>> >>>> ?? Unclear to me: what >>> is incorrect? >>>> (There was only a clarification >>> added about >>> RFC3775 bi-directional tunneling >>>> which does not work for >>> >>> PMIPv6 as we all know. >>> >>> It depends on what you wish to >>> say. >>> Based on what I could see, I suggested the following: >>> >>> [behcet] The above paragraph needs to be rewritten to state that >>> PMIPv6 does not >>> explicitly address multicast communication. >>> It was a choice to design >>> multicast extension for PMIPv6 similar to MIPv6 but due to the >>> inefficiencies >>> involved in bi-directional home tunneling a proxy based >>> solution described in this document has >>> instead been opted for. >>> >>> [behcet] please add several sentences on why proxy approach is better >>> (as has >>> been discussed on ML). >>> >>> The above would solve the problem and >>> make the text much clearer. >>> >> >>> [Thomas=> A rewording has been >>> done (see previous mail). >> >> [behcet] >> You mean the current text? Current text in -02 is not correct and >> unfortunately not acceptable. MIPv6 based solution was proposed as you >> know. That solution was not worked out in the working group. What >> gives you freedom to speculate on that proposal without even >> referencing the draft? >> Why are you not then speculating about 3 or 4 other proposals that >> have not been selected? >> >> Sorry but this is totally inacceptable. >> > > [Thomas => I guess it is time to re-approach reality: > > 1. The text has never been incorrect, but supposedly hard to parse. In > particular, MIPv6 bi-directional tunneling just does not work in PMIPv6 > - and has never been proposed in a document > 2. We had the text reworded (sent in a previous mail today) as: > > " > Multicast routing functions need to be placed carefully within the > PMIPv6 domain to augment unicast transmission with group communication > services. does not explicitly address > multicast communication. Bi-directional home tunneling, the minimal > multicast support arranged by MIPv6, cannot be directly transfered to > network-based management scenarios, since a mobility-unaware node will > not initiate such a tunnel after movement. Consequently, even a minimal > multicast listener support in PMIPv6 domains requires an explicit > deployment of additional functions." This text looks OK to me, but I may be unaware of some of the MIPv6 considerations. The main thing is to explain why this basic approach is needed in PMIPv6. Discussion of other solutions should be minimal, only enough to explain why this was the choice made. Stig > ... and I guess that's about it. > > Cheers, > > Thomas > From stig@venaas.com Tue Jun 8 10:44:25 2010 Return-Path: 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 238C33A67E7 for ; Tue, 8 Jun 2010 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.001, NO_RELAYS=-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 ivfrwX3A71Qv for ; Tue, 8 Jun 2010 10:44:22 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id ACF0D3A688D for ; Tue, 8 Jun 2010 10:44:18 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c] (unknown [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c]) by ufisa.uninett.no (Postfix) with ESMTPSA id BA0B880B6; Tue, 8 Jun 2010 19:44:18 +0200 (CEST) Message-ID: <4C0E8170.1030005@venaas.com> Date: Tue, 08 Jun 2010 10:44:16 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Behcet Sarikaya References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> In-Reply-To: <470436.92236.qm@web111412.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org, "Thomas C. Schmidt" Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Tue, 08 Jun 2010 17:44:25 -0000 Behcet Sarikaya wrote: > Hi Thomas, > See inline. [...] >>> Section 5.1 and >>> >> 5.2 have not picked up. >>> 5.1/5.2 explain resp. >> give reference to >>> the use of addressing in MLD. As >> destination addresses depend on the context >>> of the messaging >> (as >> differently defined in RFCs 2710 and 3810), only the >> pointer is given in >>> this overview. >> If that is the >> case then state the specific values for each, I don't think MLD has a million >> different messages. >> > >> [Thomas=> Unclear: if you (or any reader) >> wants to know about the > details of MLD, you should read the corresponding >> document. There is no > sense (and for good reasons no practice) to retell the >> content of > previous RFCs. This would only be a source of >> misunderstandings. > > [behcet] > By the way, I read those RFCs. Thank you for your advice :-)! > > However, I find it strange to give a whole RFC of 61 pages (3810) to figure out what the destination address will be. Plus 22 pages for 2710. > > You created this problem you should correct it. See more below. > > > >>> Regarding IPv4: This document >> is >>> focused on PMIP*v6* - and there is an >> obvious >> correspondence between MLD and >>> IGMP. I don't see much value >> in >> repeating the tables with the obvious >>> changes ... but >> this is not a >> crucial part. It would just make the text >> longer. >> >> Why not? It is some useful detail. > >> [Thomas=> I >> don't see the point. This draft is about deployment and not > implementation. >> Readers should get the idea of what is happening in the > network, but should >> not be guided to re-implement IGMP or MLD. > > [behcet] > Here you are contradicting yourself. > > Why have Sections 5.1 and 5.2 then? It was you who included them, all I am asking is to make it more clear and complete. > >> However, this seems to turn >> into a matter of taste. Maybe we should > follow a third party advise - Stig, >> what would you consider more > appropriate: additional IGMP address tables or >> not? > > [behcet] > There is no third party here. We are a working group and WG has members. I posted my comments as a member of WG not as chair's comments. > > I don't know what you are talking about? Can you explain? I would, frankly speaking, say that section 5 is pretty useless. Is there any value in this section? I think all the reader needs to know is that MLD/IGMP is encapsulated and sent as normal. So maybe remove it? One should not include more details from other RFCs than is needed to explain the idea at hand. So talking about exact MLD/IGMP message formats and addressing should be avoided if it behaves exactly as normal. Otherwise one may start to wonder whether it behaves differently in this specific context. Just my personal opinion, Stig From stig@venaas.com Tue Jun 8 13:08:14 2010 Return-Path: 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 809443A68E3 for ; Tue, 8 Jun 2010 13:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.123 X-Spam-Level: X-Spam-Status: No, score=-0.123 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_50=0.001, NO_RELAYS=-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 9c0MQkMWjh7k for ; Tue, 8 Jun 2010 13:08:13 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 2197A3A6897 for ; Tue, 8 Jun 2010 13:08:13 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c] (unknown [IPv6:2001:420:4:ea0c:10eb:2ef0:447e:9a1c]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3CF28808A; Tue, 8 Jun 2010 22:08:13 +0200 (CEST) Message-ID: <4C0EA32B.7080704@venaas.com> Date: Tue, 08 Jun 2010 13:08:11 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: multimob@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Liuhui47967@huawei.com Subject: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.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: , X-List-Received-Date: Tue, 08 Jun 2010 20:08:14 -0000 Hi I've read through your draft and think it is a good starting point for a wg draft on this topic. I believe more work is needed, but I find that the current document has some analyzes of many interesting issues. The analyzes should be extended on some points, and maybe also some more concrete recommendations, but it's a good starting point. Below are some comments on part of the text. I may have some more issues and comments later. Text from the draft is indented. Section 2: use. Current IGMPv3 and MLDv2 provide the reliability for these messages by simple retransmission, which is not adequate from both the robustness and efficiency aspects [ROBUST]. This issue can be enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. I think this statement is a bit too strong. Whether it is adequate depends on the scenario. In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to suppress duplicated multicast listener reports on the link. In IGMPv3 and MLDv2 host suppression mechanism is removed. Instead, Explicit Tracking for per-host tracking is adopted. It sounds like Explicit Tracking is mandatory with IGMPv3/MLDv2, but it is only optional. The following paragraph is fine, where you write that it is possible to do tracking. Section 3.1: O Various types of links: Wireless link is usually asymmetrical link and is restricted to unidirectional data retransmission. The performance also varies with each link type. I must say I'm a bit unsure about this one. In particular whether the links are usually asymmetrical, and the "unidirectional data retransmission". One thing that maybe can be mentioned somewhere is that some link types provide better reliability for unicast than multicast. E.g. link-layer acks and retransmissions for unicast but not multicast. O Increased Leave Latency: Unlike wired multicast, the leave latency in the wireless multicast will be increased with user movement. I guess this is latency as seen by the network? 4.1.1: O Reducing Power consumption: Due to elimination of the suppression of multicast listener reports, the host does not need to hear and suppress the duplicated report message which is beneficial to mobile hosts that do not have enough battery power. I don't get this. Suppression of reports would save battery power since fewer reports are received and you may not have to send your own. Or your point is that sending your own report is cheaper than receiving other's reports which is needed if you do suppression? Anyway, it is not clear to me. 4.1.3: The large number of Queries and bad link condition may result in packets burst. This packet burst can be mitigated by having the downstream router intercept and response to IGMP/MLD Queries packets sent by upstream router. Typically this means that the router will: What to do you mean with a router intercepting queries and responses. Normally you would just do IGMP/MLD at the edge and do say PIM between the routers. Are you discussing the IGMP/MLD proxy case here? - Never send a specific query to any client, and - Forward general queries only to those clients receiving at least one multicast group What do you mean by forwarding queries? 4.1.7: Are you suggesting using specific queries instead of general queries? How would that work? What if you missed the unsolicited report from a host joining a new group? Stig From sunseawq@huawei.com Wed Jun 9 00:51:44 2010 Return-Path: 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 2C7593A6915 for ; Wed, 9 Jun 2010 00:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 MXjW1+QHSHf1 for ; Wed, 9 Jun 2010 00:51:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5B6C93A6910 for ; Wed, 9 Jun 2010 00:51:42 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3Q00FX8LU46C@szxga03-in.huawei.com> for multimob@ietf.org; Wed, 09 Jun 2010 15:51:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3Q00MOULU39S@szxga03-in.huawei.com> for multimob@ietf.org; Wed, 09 Jun 2010 15:51:39 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3Q00KCHLU3H9@szxml06-in.huawei.com> for multimob@ietf.org; Wed, 09 Jun 2010 15:51:39 +0800 (CST) Date: Wed, 09 Jun 2010 15:51:38 +0800 From: Qin Wu To: Stig Venaas , multimob@ietf.org Message-id: <028001cb07a8$97d94590$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C0EA32B.7080704@venaas.com> Subject: Re: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.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: , X-List-Received-Date: Wed, 09 Jun 2010 07:51:44 -0000 Hi, Chair: Thank you for spending time reviewing this I-D and indicating your support being wg draft. I agree although many of detailed issues specified in this I-D need further extending and polishing, the structure of this document has been in good shape.:-) Hope to hear more discussions on this topic and get this work moving forward. As regarding your valuable comments, please see my reply belows and check whether I have addressed your concerns. Regards! -Qin ----- Original Message ----- From: "Stig Venaas" To: Cc: ; Sent: Wednesday, June 09, 2010 4:08 AM Subject: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt > Hi > > I've read through your draft and think it is a good starting point for a > wg draft on this topic. > > I believe more work is needed, but I find that the current document has > some analyzes of many interesting issues. The analyzes should be > extended on some points, and maybe also some more concrete > recommendations, but it's a good starting point. > > Below are some comments on part of the text. I may have some more issues > and comments later. Text from the draft is indented. > > Section 2: > > use. Current IGMPv3 and MLDv2 provide the reliability for these > messages by simple retransmission, which is not adequate from both > the robustness and efficiency aspects [ROBUST]. This issue can be > enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. > > I think this statement is a bit too strong. Whether it is adequate > depends on the scenario. [Qin]: Good point, How about " Current IGMPv3 and MLDv2 provide the reliability for these messages by non responsive retransmission, which* is not guaranteed the messages to be retransmitted is received * and *may* be not adequate from both the robustness and efficiency aspects [ROBUST]. This issue could be enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. " > In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to > suppress duplicated multicast listener reports on the link. In > IGMPv3 and MLDv2 host suppression mechanism is removed. Instead, > Explicit Tracking for per-host tracking is adopted. > > It sounds like Explicit Tracking is mandatory with IGMPv3/MLDv2, but > it is only optional. The following paragraph is fine, where you write > that it is possible to do tracking. [Qin]: Okay. We could say " In IGMPv3 and MLDv2, this suppression of host membership reports is removed. This is mainly because multiple group records can be reported in one message in IGMPv3 and MLDv2 which brings the advantage of decreasing the number of packets sent. Also, Explicit Tracking for per-host tracking can be adopted in IGMPv3 and MLDv2 as one optional feature to further decrease the number of unnecessary packets sent. " What do you think of it? > Section 3.1: > > O Various types of links: Wireless link is usually asymmetrical link > and is restricted to unidirectional data retransmission. The > performance also varies with each link type. > > I must say I'm a bit unsure about this one. In particular whether the > links are usually asymmetrical, and the "unidirectional data > retransmission". [Qin]: I agree. Acutally what I really want to say is wireless link for multicast is possible asymmetrical link and/ or unidirectional link. That is to say, from the multicast data delivery perspective, the multicast data will be only sent from router to the host, not the other way around. So we could say " Wireless link for multicast is possible asymetrical link and is restrict to unidirectional data retransmission. The performance also varies with each link type. " > One thing that maybe can be mentioned somewhere is that some link > types provide better reliability for unicast than multicast. E.g. > link-layer acks and retransmissions for unicast but not multicast. [Qin]: Good suggestion. How about saying: " O Various types of links: Wireless link for multicast is possible asymmetrical link and is restricted to unidirectional data retransmission. The corresponding performance also varies with each link type. Also some link types provide better reliability for unicast than multicast, e.g., by unicast retransmission. " What do you say? > O Increased Leave Latency: Unlike wired multicast, the leave latency > in the wireless multicast will be increased with user movement. > > I guess this is latency as seen by the network? [Qin]: You are right. Normally inthe wired network, user will not move or change the device. But this is not in wireless network. > 4.1.1: > > O Reducing Power consumption: Due to elimination of the suppression > of multicast listener reports, the host does not need to hear and > suppress the duplicated report message which is beneficial to mobile > hosts that do not have enough battery power. > > I don't get this. Suppression of reports would save battery power since > fewer reports are received and you may not have to send your own. Or > your point is that sending your own report is cheaper than receiving > other's reports which is needed if you do suppression? Anyway, it is > not clear to me. [Qin]: I guess you misunderstand what I said here. The clarification I have is: With the host suppression, the host MUST spend processing power all along to listen and determine whether there are duplicated report message, which require the host to consume too muchmore power to do this. But from the router perspective, the router may benefit from this host suppression, becos, a certain number of duplicated reports are suppressed, which may save lots of processing power for the router. On the other hand, if we remove host suppression, then the host does not need to spend any processing power to listen and determine whether there are duplicated report message. The cost may be the router need some process power to process the reporet unsuppressed. Fortunetely , this is not issue for the router. becos the multicast group records can be carried in one compound report messages which decrease unnecessary report to the routers. Does this clarify? > 4.1.3: > > The large number of Queries and bad link condition may result in > packets burst. This packet burst can be mitigated by having the > downstream router intercept and response to IGMP/MLD Queries packets > sent by upstream router. Typically this means that the router will: > > What to do you mean with a router intercepting queries and responses. > Normally you would just do IGMP/MLD at the edge and do say PIM between > the routers. Are you discussing the IGMP/MLD proxy case here? [Qin]: The router intecepting queries is one intermediate router between the host and router. This router may also provide explicit tracking function. In this case, the router does not need to forward the queries to all the hosts behind itself. becos, the router know whether there are listeners on the downlinks with explicit tracking function, therefore the router can response to the queries from upstream routers on behalf of these listeners. Here the intermediate router can be looked on as proxy described in RFC 4605. This case is applicable especially when there are several hops between the host and the upstream router. The intermediate router can sit at DSLAM between the host and the upstream router. > - Never send a specific query to any client, and > > - Forward general queries only to those clients receiving at least > one multicast group > > What do you mean by forwarding queries? [Qin]: Good question. Let me give you one example below. Suppose there are three hosts sitting behind this intermediate router (i.e., DSLAM), Host A and Host B only join multicast group 1 through this intermdiate router, Host C not only join multicast group 1 and multicast group 2. In this case, the router has three host interfaces which respectively corresponding to Host A, Host B and Host C. then the router only send the General Query message to the host interface that is corresponding to the Host C. That is what we called forwarding queries. > > 4.1.7: > > Are you suggesting using specific queries instead of general queries? > How would that work? What if you missed the unsolicited report from a > host joining a new group? [Qin]: Not exactly. Using specific queris instead of general queries depend on the sceanrio you are looking at. In the case mentioned in 4.1.7, when the the number of receivers on the link is large, we can use specific queries instead of sending general queries.The main incentive to use specific queries instead of general queries is to avoid solicited report bursts due to general queries recieved by large number of hosts at the same time. Let me give you one example to explain how it works. Suppose 500 hosts sitting behind the same upstream router belong to five different multicast groups, each multicast group has 100 users. If the router send only one General Query to all these 500 hosts, these hosts may repond with 500 reports at the same time when response delay for the hosts is poorly set , which may cause serious packet bursts. Instead, if we send five group specific Query to each 100 hosts with 100ms interval, 200 ms interval, 300ms interval,400ms interval, 500ms interval respectively. each 100 hosts may receive the Group Specific Query at the different time interval, which can greatly decrease the possibility to occur packet burstiness. Also If we allow IGMP/proxy sit between the hosts and the router, the proxy can stop forwarding Group specific Query to the hosts. which also can avoid packet burstiness. As regarding unsolicited report missing you raised, I belive it is not related to this case in 4.1.7. Becos the unsolicited report will not be used to respond to the General Query and Group Specific Query. The reports that may result in packet burstiness here is solicited reports. > > Stig > From stig@venaas.com Wed Jun 9 10:34:24 2010 Return-Path: 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 98B713A68EA for ; Wed, 9 Jun 2010 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 EHCnqhSDnhrb for ; Wed, 9 Jun 2010 10:34:23 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 1A4993A67B4 for ; Wed, 9 Jun 2010 10:34:22 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:1c09:1881:8690:506b] (unknown [IPv6:2001:420:4:ea0c:1c09:1881:8690:506b]) by ufisa.uninett.no (Postfix) with ESMTPSA id 22CE580BA; Wed, 9 Jun 2010 19:34:21 +0200 (CEST) Message-ID: <4C0FD097.6050600@venaas.com> Date: Wed, 09 Jun 2010 10:34:15 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Qin Wu References: <4C0EA32B.7080704@venaas.com> <028001cb07a8$97d94590$23548a0a@china.huawei.com> In-Reply-To: <028001cb07a8$97d94590$23548a0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.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: , X-List-Received-Date: Wed, 09 Jun 2010 17:34:24 -0000 Qin Wu wrote: > Hi, Chair: > Thank you for spending time reviewing this I-D and indicating your support being wg draft. I agree although > many of detailed issues specified in this I-D need further extending and polishing, the structure of this document > has been in good shape.:-) Hope to hear more discussions on this topic and get this work moving forward. > As regarding your valuable comments, please see my reply belows and check whether I have addressed your > concerns. Just to be sure, I think I should make some clarifications here so that we are all on the same page. I think you may be reading more into it than I intended. My comments should be regarded as coming from any member of the working group. And the opinions of a single wg member does not really count for much. For wg decisions there must be a rough consensus. I wrote that it is a good starting point for a wg draft on this topic. Since we have at least one other draft on the same topic, this does not necessarily imply that I think we should adopt your document. Note, I'm not saying we should not either, all I'm saying is that it doesn't imply that. But again, my opinion on this is not worth more than the opinion of any other individual in the wg. I'm hoping that my input can help stimulate discussion of your document in the wg. If you get input from the wg and you update your document based on that, then hopefully the quality would improve further, and also probably more support for your document in the wg. Even though it is a good starting point, there is a lot of work to do. See inline below. > Regards! > -Qin > > ----- Original Message ----- > From: "Stig Venaas" > To: > Cc: ; > Sent: Wednesday, June 09, 2010 4:08 AM > Subject: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt > > >> Hi >> >> I've read through your draft and think it is a good starting point for a >> wg draft on this topic. >> >> I believe more work is needed, but I find that the current document has >> some analyzes of many interesting issues. The analyzes should be >> extended on some points, and maybe also some more concrete >> recommendations, but it's a good starting point. >> >> Below are some comments on part of the text. I may have some more issues >> and comments later. Text from the draft is indented. >> >> Section 2: >> >> use. Current IGMPv3 and MLDv2 provide the reliability for these >> messages by simple retransmission, which is not adequate from both >> the robustness and efficiency aspects [ROBUST]. This issue can be >> enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. >> >> I think this statement is a bit too strong. Whether it is adequate >> depends on the scenario. > > [Qin]: Good point, How about > " > Current IGMPv3 and MLDv2 provide the reliability for these messages by non responsive > retransmission, which* is not guaranteed the messages to be retransmitted is received * and *may* > be not adequate from both the robustness and efficiency aspects [ROBUST]. This issue could be > enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. > " Yes, that is better. >> In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to >> suppress duplicated multicast listener reports on the link. In >> IGMPv3 and MLDv2 host suppression mechanism is removed. Instead, >> Explicit Tracking for per-host tracking is adopted. >> >> It sounds like Explicit Tracking is mandatory with IGMPv3/MLDv2, but >> it is only optional. The following paragraph is fine, where you write >> that it is possible to do tracking. > > [Qin]: Okay. We could say > " > In IGMPv3 and MLDv2, this suppression of host membership > reports is removed. This is mainly because multiple > group records can be reported in one message in IGMPv3 > and MLDv2 which brings the advantage of decreasing the > number of packets sent. Also, Explicit Tracking for > per-host tracking can be adopted in IGMPv3 and MLDv2 > as one optional feature to further decrease the > number of unnecessary packets sent. > " > What do you think of it? Maybe say something like: That there is no suppression, also allows for explicit tracking of host memberships. Or something like that. At least they key is that explicit tracking is possible, and as you say, an optional feature. >> Section 3.1: >> >> O Various types of links: Wireless link is usually asymmetrical link >> and is restricted to unidirectional data retransmission. The >> performance also varies with each link type. >> >> I must say I'm a bit unsure about this one. In particular whether the >> links are usually asymmetrical, and the "unidirectional data >> retransmission". > > [Qin]: I agree. Acutally what I really want to say is wireless link for multicast is possible asymmetrical link > and/ or unidirectional link. That is to say, from the multicast data delivery perspective, > the multicast data will be only sent from router to the host, not the other way around. So we could > say > " > Wireless link for multicast is possible asymetrical link > and is restrict to unidirectional data retransmission. > The performance also varies with each link type. > " It's possible for hosts to send multicast data on a wireless link too. Maybe you don't need to say anything about this. At least for the MLD/IGMP discussion you only care about receiving multicast data (apart from the MLD/IGMP messages that also are multicast). >> One thing that maybe can be mentioned somewhere is that some link >> types provide better reliability for unicast than multicast. E.g. >> link-layer acks and retransmissions for unicast but not multicast. > > [Qin]: Good suggestion. How about saying: > " > O Various types of links: Wireless link for multicast is possible asymmetrical link > and is restricted to unidirectional data retransmission. The corresponding > performance also varies with each link type. Also some link types provide better > reliability for unicast than multicast, e.g., by unicast retransmission. > " > What do you say? Yes, this is better. But I still don't necessarily agree about the unidirectional part. At least not in general. There are wireless links that are not unidirectional, but I'm not surprised if there are some links that behave as you say. > >> O Increased Leave Latency: Unlike wired multicast, the leave latency >> in the wireless multicast will be increased with user movement. >> >> I guess this is latency as seen by the network? > > [Qin]: You are right. Normally inthe wired network, user will not move or change the device. > But this is not in wireless network. > >> 4.1.1: >> >> O Reducing Power consumption: Due to elimination of the suppression >> of multicast listener reports, the host does not need to hear and >> suppress the duplicated report message which is beneficial to mobile >> hosts that do not have enough battery power. >> >> I don't get this. Suppression of reports would save battery power since >> fewer reports are received and you may not have to send your own. Or >> your point is that sending your own report is cheaper than receiving >> other's reports which is needed if you do suppression? Anyway, it is >> not clear to me. > > [Qin]: I guess you misunderstand what I said here. The clarification I have is: > > With the host suppression, the host MUST spend processing power all along to > listen and determine whether there are duplicated report message, which > require the host to consume too muchmore power to do this. But from the router perspective, > the router may benefit from this host suppression, becos, a certain number > of duplicated reports are suppressed, which may save lots of processing power > for the router. > > On the other hand, if we remove host suppression, then the host does not need > to spend any processing power to listen and determine whether there are > duplicated report message. The cost may be the router need some process power > to process the reporet unsuppressed. Fortunetely , this is not issue for the router. > becos the multicast group records can be carried in one compound report messages > which decrease unnecessary report to the routers. > > Does this clarify? Yes. So good if the text in the document can go into some more detail. >> 4.1.3: >> >> The large number of Queries and bad link condition may result in >> packets burst. This packet burst can be mitigated by having the >> downstream router intercept and response to IGMP/MLD Queries packets >> sent by upstream router. Typically this means that the router will: >> >> What to do you mean with a router intercepting queries and responses. >> Normally you would just do IGMP/MLD at the edge and do say PIM between >> the routers. Are you discussing the IGMP/MLD proxy case here? > > [Qin]: The router intecepting queries is one intermediate router between the host and > router. This router may also provide explicit tracking function. In this case, the router > does not need to forward the queries to all the hosts behind itself. becos, the router > know whether there are listeners on the downlinks with explicit tracking function, therefore > the router can response to the queries from upstream routers on behalf of these listeners. > Here the intermediate router can be looked on as proxy described in RFC 4605. This case > is applicable especially when there are several hops between the host and the upstream router. > The intermediate router can sit at DSLAM between the host and the upstream router. OK, I think you need to explicitly talk about IGMP/MLD proxying then. And use a different term than "intercept". The proxy is listening to the appropriate IGMP/MLD-groups and receives the reports similar to a multicast router. Then based on the aggregate state it sends messages upstream. >> - Never send a specific query to any client, and >> >> - Forward general queries only to those clients receiving at least >> one multicast group >> >> What do you mean by forwarding queries? > > [Qin]: Good question. Let me give you one example below. > Suppose there are three hosts sitting behind this intermediate router (i.e., DSLAM), > Host A and Host B only join multicast group 1 through this intermdiate router, Host C not only join multicast > group 1 and multicast group 2. In this case, the router has three host interfaces which respectively corresponding > to Host A, Host B and Host C. then the router only send the General Query message to the host interface that is > corresponding to the Host C. That is what we called forwarding queries. I still don't think I get it. But, if you talk about MLD proxies, then they may send general queries downstream, independently of when the upstream sends them. So it is not forwarding. There is also the term MLD snooping which would be close to what you describe, but that is also different. >> 4.1.7: >> >> Are you suggesting using specific queries instead of general queries? >> How would that work? What if you missed the unsolicited report from a >> host joining a new group? > > [Qin]: Not exactly. Using specific queris instead of general queries depend on the sceanrio you are looking at. > In the case mentioned in 4.1.7, when the the number of receivers on the link is large, we can use specific queries > instead of sending general queries.The main incentive to use specific queries instead of general > queries is to avoid solicited report bursts due to general queries recieved by large number of hosts at the same > time. Let me give you one example to explain how it works. > Suppose 500 hosts sitting behind the same upstream router belong to five different multicast groups, each multicast group > has 100 users. > If the router send only one General Query to all these 500 hosts, these hosts may repond with 500 reports at the same time > when response delay for the hosts is poorly set , which may cause serious packet bursts. > Instead, if we send five group specific Query to each 100 hosts with 100ms interval, 200 ms interval, 300ms interval,400ms interval, > 500ms interval respectively. each 100 hosts may receive the Group Specific Query at the different time interval, which can greatly > decrease the possibility to occur packet burstiness. > > Also If we allow IGMP/proxy sit between the hosts and the router, the proxy can stop forwarding Group specific Query to the hosts. > which also can avoid packet burstiness. > > As regarding unsolicited report missing you raised, I belive it is not related to this case in 4.1.7. Becos the unsolicited report will not > be used to respond to the General Query and Group Specific Query. The reports that may result in packet burstiness here is solicited > reports. My point is that you cannot just do specific queries instead of general queries. My concern is that if the router never received an unsolicited report from the host, then the router can only learn about that group if it sends a general query (unless perhaps if another host joins the same group). If you don't do general queries, you only learn about new groups from unsolicited reports, and if you miss some of those reports... I hope others can contribute to the discussion of these and other points. Stig > >> Stig >> From sunseawq@huawei.com Thu Jun 10 05:00:15 2010 Return-Path: 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 2029B3A688D for ; Thu, 10 Jun 2010 05:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 O4bDr9C0SNkE for ; Thu, 10 Jun 2010 05:00:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E6C2D3A68FA for ; Thu, 10 Jun 2010 05:00:12 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3S00B4SS034F@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 10 Jun 2010 20:00:04 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3S00ED5S03MY@szxga03-in.huawei.com> for multimob@ietf.org; Thu, 10 Jun 2010 20:00:03 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3S00LYCS02UJ@szxml04-in.huawei.com> for multimob@ietf.org; Thu, 10 Jun 2010 20:00:03 +0800 (CST) Date: Thu, 10 Jun 2010 20:00:02 +0800 From: Qin Wu To: Stig Venaas Message-id: <01bb01cb0894$75a3c440$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C0EA32B.7080704@venaas.com> <028001cb07a8$97d94590$23548a0a@china.huawei.com> <4C0FD097.6050600@venaas.com> Cc: multimob@ietf.org Subject: Re: [multimob] Some comments on draft-wu-multimob-igmp-mld-tuning-01.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: , X-List-Received-Date: Thu, 10 Jun 2010 12:00:15 -0000 Hi,Stig: Thank for your justification. I value your open opinion and believe we need more volunteers to produce good review and move this work on. Also I would like to thank for your effort on helping stimulate the discussion to this document. Here is my reply belows. Regards! -Qin ----- Original Message ----- From: "Stig Venaas" To: "Qin Wu" Cc: ; Sent: Thursday, June 10, 2010 1:34 AM Subject: Re: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt > Qin Wu wrote: >> Hi, Chair: >> Thank you for spending time reviewing this I-D and indicating your support being wg draft. I agree although >> many of detailed issues specified in this I-D need further extending and polishing, the structure of this document >> has been in good shape.:-) Hope to hear more discussions on this topic and get this work moving forward. >> As regarding your valuable comments, please see my reply belows and check whether I have addressed your >> concerns. > > Just to be sure, I think I should make some clarifications here so that > we are all on the same page. I think you may be reading more into it > than I intended. > > My comments should be regarded as coming from any member of the working > group. And the opinions of a single wg member does not really count for > much. For wg decisions there must be a rough consensus. > > I wrote that it is a good starting point for a wg draft on this topic. > Since we have at least one other draft on the same topic, this does not > necessarily imply that I think we should adopt your document. Note, I'm > not saying we should not either, all I'm saying is that it doesn't imply > that. > > But again, my opinion on this is not worth more than the opinion of any > other individual in the wg. > > I'm hoping that my input can help stimulate discussion of your document > in the wg. If you get input from the wg and you update your document > based on that, then hopefully the quality would improve further, and > also probably more support for your document in the wg. > > Even though it is a good starting point, there is a lot of work to do. > > See inline below. > >> Regards! >> -Qin >> >> ----- Original Message ----- >> From: "Stig Venaas" >> To: >> Cc: ; >> Sent: Wednesday, June 09, 2010 4:08 AM >> Subject: Some comments on draft-wu-multimob-igmp-mld-tuning-01.txt >> >> >>> Hi >>> >>> I've read through your draft and think it is a good starting point for a >>> wg draft on this topic. >>> >>> I believe more work is needed, but I find that the current document has >>> some analyzes of many interesting issues. The analyzes should be >>> extended on some points, and maybe also some more concrete >>> recommendations, but it's a good starting point. >>> >>> Below are some comments on part of the text. I may have some more issues >>> and comments later. Text from the draft is indented. >>> >>> Section 2: >>> >>> use. Current IGMPv3 and MLDv2 provide the reliability for these >>> messages by simple retransmission, which is not adequate from both >>> the robustness and efficiency aspects [ROBUST]. This issue can be >>> enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. >>> >>> I think this statement is a bit too strong. Whether it is adequate >>> depends on the scenario. >> >> [Qin]: Good point, How about >> " >> Current IGMPv3 and MLDv2 provide the reliability for these messages by non responsive >> retransmission, which* is not guaranteed the messages to be retransmitted is received * and *may* >> be not adequate from both the robustness and efficiency aspects [ROBUST]. This issue could be >> enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK]. >> " > > Yes, that is better. [Qin]:Okay, thanks. >>> In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to >>> suppress duplicated multicast listener reports on the link. In >>> IGMPv3 and MLDv2 host suppression mechanism is removed. Instead, >>> Explicit Tracking for per-host tracking is adopted. >>> >>> It sounds like Explicit Tracking is mandatory with IGMPv3/MLDv2, but >>> it is only optional. The following paragraph is fine, where you write >>> that it is possible to do tracking. >> >> [Qin]: Okay. We could say >> " >> In IGMPv3 and MLDv2, this suppression of host membership >> reports is removed. This is mainly because multiple >> group records can be reported in one message in IGMPv3 >> and MLDv2 which brings the advantage of decreasing the >> number of packets sent. Also, Explicit Tracking for >> per-host tracking can be adopted in IGMPv3 and MLDv2 >> as one optional feature to further decrease the >> number of unnecessary packets sent. >> " >> What do you think of it? > > Maybe say something like: That there is no suppression, also > allows for explicit tracking of host memberships. > > Or something like that. At least they key is that explicit > tracking is possible, and as you say, an optional feature. [Qin]: I like your proposal, we could say: " In IGMPv3 and MLDv2, there is no such host suppression and explicit tracking of host membership is allowed, which can be used to decrease the number of unnecessary packets sent. " >>> Section 3.1: >>> >>> O Various types of links: Wireless link is usually asymmetrical link >>> and is restricted to unidirectional data retransmission. The >>> performance also varies with each link type. >>> >>> I must say I'm a bit unsure about this one. In particular whether the >>> links are usually asymmetrical, and the "unidirectional data >>> retransmission". >> >> [Qin]: I agree. Acutally what I really want to say is wireless link for multicast is possible asymmetrical link >> and/ or unidirectional link. That is to say, from the multicast data delivery perspective, >> the multicast data will be only sent from router to the host, not the other way around. So we could >> say >> " >> Wireless link for multicast is possible asymetrical link >> and is restrict to unidirectional data retransmission. >> The performance also varies with each link type. >> " > It's possible for hosts to send multicast data on a wireless link > too. Maybe you don't need to say anything about this. At least for > the MLD/IGMP discussion you only care about receiving multicast > data (apart from the MLD/IGMP messages that also are multicast). [Qin]: Right, also I realize in the wired network, it is also possible to have one asymmetric link which has different rates for the upstream direction and downstream direction. Therefore I propose to remove the bullet 1: Varous types of links from Section 3.1. And I would like to incorporate your proposal " Also some link types provide better reliability for unicast than multicast, e.g., by unicast retransmission. " into bullet 5: Reliability as " o Reliability: In various type links, some link types provide better reliability for unicast than multicast, e.g., by unicast retransmission. Due to possible unwanted interaction of protocols across layers and user movement, the wireless network may be overwhelmed with more excessive traffic than wired network. In worse case, this may lead to network performance degrading and network connection complete loss. " Are you satisfying with this? >>> One thing that maybe can be mentioned somewhere is that some link >>> types provide better reliability for unicast than multicast. E.g. >>> link-layer acks and retransmissions for unicast but not multicast. >> >> [Qin]: Good suggestion. How about saying: >> " >> O Various types of links: Wireless link for multicast is possible asymmetrical link >> and is restricted to unidirectional data retransmission. The corresponding >> performance also varies with each link type. Also some link types provide better >> reliability for unicast than multicast, e.g., by unicast retransmission. >> " >> What do you say? > > Yes, this is better. But I still don't necessarily agree about the > unidirectional part. At least not in general. There are wireless > links that are not unidirectional, but I'm not surprised if there > are some links that behave as you say. [Qin]: See above. >>> O Increased Leave Latency: Unlike wired multicast, the leave latency >>> in the wireless multicast will be increased with user movement. >>> >>> I guess this is latency as seen by the network? >> >> [Qin]: You are right. Normally inthe wired network, user will not move or change the device. >> But this is not in wireless network. >> >>> 4.1.1: >>> >>> O Reducing Power consumption: Due to elimination of the suppression >>> of multicast listener reports, the host does not need to hear and >>> suppress the duplicated report message which is beneficial to mobile >>> hosts that do not have enough battery power. >>> >>> I don't get this. Suppression of reports would save battery power since >>> fewer reports are received and you may not have to send your own. Or >>> your point is that sending your own report is cheaper than receiving >>> other's reports which is needed if you do suppression? Anyway, it is >>> not clear to me. >> >> [Qin]: I guess you misunderstand what I said here. The clarification I have is: >> >> With the host suppression, the host MUST spend processing power all along to >> listen and determine whether there are duplicated report message, which >> require the host to consume too muchmore power to do this. But from the router perspective, >> the router may benefit from this host suppression, becos, a certain number >> of duplicated reports are suppressed, which may save lots of processing power >> for the router. >> >> On the other hand, if we remove host suppression, then the host does not need >> to spend any processing power to listen and determine whether there are >> duplicated report message. The cost may be the router need some process power >> to process the reporet unsuppressed. Fortunetely , this is not issue for the router. >> becos the multicast group records can be carried in one compound report messages >> which decrease unnecessary report to the routers. >> >> Does this clarify? > > Yes. So good if the text in the document can go into some more detail. [Qin]: Okay. And will update it into the next version. >>> 4.1.3: >>> >>> The large number of Queries and bad link condition may result in >>> packets burst. This packet burst can be mitigated by having the >>> downstream router intercept and response to IGMP/MLD Queries packets >>> sent by upstream router. Typically this means that the router will: >>> >>> What to do you mean with a router intercepting queries and responses. >>> Normally you would just do IGMP/MLD at the edge and do say PIM between >>> the routers. Are you discussing the IGMP/MLD proxy case here? >> >> [Qin]: The router intecepting queries is one intermediate router between the host and >> router. This router may also provide explicit tracking function. In this case, the router >> does not need to forward the queries to all the hosts behind itself. becos, the router >> know whether there are listeners on the downlinks with explicit tracking function, therefore >> the router can response to the queries from upstream routers on behalf of these listeners. >> Here the intermediate router can be looked on as proxy described in RFC 4605. This case >> is applicable especially when there are several hops between the host and the upstream router. >> The intermediate router can sit at DSLAM between the host and the upstream router. > > OK, I think you need to explicitly talk about IGMP/MLD proxying then. > And use a different term than "intercept". The proxy is listening to > the appropriate IGMP/MLD-groups and receives the reports similar to a > multicast router. Then based on the aggregate state it sends messages > upstream. [Qin]: This is what we said in the previous section 4.1.2 "Report suppression". In other words, In the section 4.1.2, membership report can be aggregated together into a single membership report, which save lots of processing power for the upstream router. But in the section 4.1.3, we discuss another case, i.e, "Query Suppression", In this case, "Intercept" actually means "Stop Forwarding". The example is: Queries may be sent from hundreds of different upstream routers, but passing through the same downstream router sitting between the hosts and the upstreams routers to the hosts. In order to reduce unnecessary Queries sent to the hosts, the downstreams router who acts as proxy can filter out the queries sent to the hosts behind itself and respond with reports to the upstream routers. If you agree with this, we could reword the section 4.1.3 as follows: " 4.1.3. Query Suppression for the routers The large number of Queries and bad link condition may result in packets burst. This packet burst can be mitigated by having the downstream router stops forwarding IGMP/MLD Queries packets sent to the hosts and responds with report as IGMP/MLD proxy to the upstream router. Typically this means that the router will: " >>> - Never send a specific query to any client, and >>> >>> - Forward general queries only to those clients receiving at least >>> one multicast group >>> >>> What do you mean by forwarding queries? >> >> [Qin]: Good question. Let me give you one example below. >> Suppose there are three hosts sitting behind this intermediate router (i.e., DSLAM), >> Host A and Host B only join multicast group 1 through this intermdiate router, Host C not only join multicast >> group 1 and multicast group 2. In this case, the router has three host interfaces which respectively corresponding >> to Host A, Host B and Host C. then the router only send the General Query message to the host interface that is >> corresponding to the Host C. That is what we called forwarding queries. > > I still don't think I get it. But, if you talk about MLD proxies, then > they may send general queries downstream, independently of when the > upstream sends them. So it is not forwarding. > > There is also the term MLD snooping which would be close to what you > describe, but that is also different. [Qin]: Probably you are right. Actually we are discussing selective sending the Query to the hosts in this case, which could be supported by MLD snooping functionality. If you like, we can change " Forwarding general queries ... " into "Selective send general queries...." or just "send general queries" >>> 4.1.7: >>> >>> Are you suggesting using specific queries instead of general queries? >>> How would that work? What if you missed the unsolicited report from a >>> host joining a new group? >> >> [Qin]: Not exactly. Using specific queris instead of general queries depend on the sceanrio you are looking at. >> In the case mentioned in 4.1.7, when the the number of receivers on the link is large, we can use specific queries >> instead of sending general queries.The main incentive to use specific queries instead of general >> queries is to avoid solicited report bursts due to general queries recieved by large number of hosts at the same >> time. Let me give you one example to explain how it works. >> Suppose 500 hosts sitting behind the same upstream router belong to five different multicast groups, each multicast group >> has 100 users. >> If the router send only one General Query to all these 500 hosts, these hosts may repond with 500 reports at the same time >> when response delay for the hosts is poorly set , which may cause serious packet bursts. >> Instead, if we send five group specific Query to each 100 hosts with 100ms interval, 200 ms interval, 300ms interval,400ms interval, >> 500ms interval respectively. each 100 hosts may receive the Group Specific Query at the different time interval, which can greatly >> decrease the possibility to occur packet burstiness. >> >> Also If we allow IGMP/proxy sit between the hosts and the router, the proxy can stop forwarding Group specific Query to the hosts. >> which also can avoid packet burstiness. >> >> As regarding unsolicited report missing you raised, I belive it is not related to this case in 4.1.7. Becos the unsolicited report will not >> be used to respond to the General Query and Group Specific Query. The reports that may result in packet burstiness here is solicited >> reports. > > My point is that you cannot just do specific queries instead of general > queries. My concern is that if the router never received an unsolicited > report from the host, then the router can only learn about that group if > it sends a general query (unless perhaps if another host joins the same > group). If you don't do general queries, you only learn about new groups > from unsolicited reports, and if you miss some of those reports... [Qin]: Good point. Sorry for my early misunderstanding. That is to say, if we use Group Queries to replace General Queries, in some cases, we may miss lots of solicited report which is early used to do membership state update and new group collection on the router. In worse case, unsolciited reports are also losted due to bad link condition, which will cause some new group information can not be collected by the router. Therefore the limitation of this case is we should guarantee that the unsolicited report will not be lost. Right? With this limiation, do you have any proposal? Remove this case in 4.1.7 or add some text in 4.1.7 to explain this limitation? > I hope others can contribute to the discussion of these and other > points. > > Stig > >> >>> Stig >>> > From Dirk.von-Hugo@telekom.de Fri Jun 11 03:27:14 2010 Return-Path: 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 06F6228C136 for ; Fri, 11 Jun 2010 03:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=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 Vt1zMbQXcP0p for ; Fri, 11 Jun 2010 03:27:13 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id A0E5E28C12C for ; Fri, 11 Jun 2010 03:27:12 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 11 Jun 2010 12:27:08 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 12:27:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 12:27:07 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848023F3A7C@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-von-hugo-multimob-future-work-02 Thread-Index: AcsJSOKjzUXftCrhTzyDwaKVz5/0nwABzpDQ From: To: X-OriginalArrivalTime: 11 Jun 2010 10:27:08.0413 (UTC) FILETIME=[A537EAD0:01CB0950] Subject: [multimob] WG: New Version Notification for draft-von-hugo-multimob-future-work-02 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: , X-List-Received-Date: Fri, 11 Jun 2010 10:27:14 -0000 =20 Dear all, We have posted an update of the draft on future extension for multimob = optimizations focusing on currently discussed drafts ... thus covering = the near-future work. Please comment if you think we should add or = modify topics for preparation of the re-chartering discussion in = Maastricht. Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Gesendet: Freitag, 11. Juni 2010 11:31 An: von Hugo, Dirk Cc: asaeda@wide.ad.jp; sarikaya@ieee.org; = pierrick.seite@orange-ftgroup.com Betreff: New Version Notification for = draft-von-hugo-multimob-future-work-02=20 A new version of I-D, draft-von-hugo-multimob-future-work-02.txt has = been successfully submitted by Dirk von Hugo and posted to the IETF = repository. Filename: draft-von-hugo-multimob-future-work Revision: 02 Title: Evaluation of further issues on Multicast Mobility: Potential = future work for WG MultiMob Creation_date: 2010-06-08 WG ID: Independent Submission Number_of_pages: 15 Abstract: The WG MultiMob aims at defining a basic mobile multicast solution leveraging on network localized mobility management, i.e. Proxy Mobile IPv6 protocol. The solution would be basically based on multicast group management, i.e. IGMP/MLD, proxying at the access gateway. If such a basic solution is essential from an operational point of view, challenges with efficient resource utilization and user perceived service quality still persist. These issues may prevent large scale deployments of mobile multicast applications. This document attempts to identify topics for near future extension of work such as modifying multimob base solution, PMIPv6 and MLD/ IGMP for optimal multicast support, and adaptation of Handover optimization. Far future items such as extending to and modifying of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of multiple flows and multihoming will be dealt with in a future version. = =20 The IETF Secretariat. From Dirk.von-Hugo@telekom.de Fri Jun 11 03:36:51 2010 Return-Path: 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 D4B4D28C136 for ; Fri, 11 Jun 2010 03:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=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 wn1XACwrHZRB for ; Fri, 11 Jun 2010 03:36:50 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id E1D763A6927 for ; Fri, 11 Jun 2010 03:36:49 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 11 Jun 2010 12:36:50 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 12:36:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 12:36:49 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC8027848023F3A90@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <78F1C759D89E1C44A6DD4C06B9A4B270BA9A4502C0@E2K7MBX.napier-mail.napier.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] WG: New Version Notification fordraft-von-hugo-multimob-future-work-02 Thread-Index: AcsJSOKjzUXftCrhTzyDwaKVz5/0nwABzpDQAABNQ4wAABdH8A== References: <643B0A1D1A13AB498304E0BBC8027848023F3A7C@S4DE8PSAAQC.mitte.t-com.de> <78F1C759D89E1C44A6DD4C06B9A4B270BA9A4502C0@E2K7MBX.napier-mail.napier.ac.uk> From: To: X-OriginalArrivalTime: 11 Jun 2010 10:36:50.0210 (UTC) FILETIME=[FFFF1820:01CB0951] Cc: I.Romdhani@napier.ac.uk Subject: Re: [multimob] WG: New Version Notification fordraft-von-hugo-multimob-future-work-02 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: , X-List-Received-Date: Fri, 11 Jun 2010 10:36:52 -0000 =20 Dear all, And this is the link ... sorry for having forgotten to include before = ;-( Thanks for pointing to this, Imed! http://www.ietf.org/internet-drafts/draft-von-hugo-multimob-future-work-0= 2.txt Best wishes Dirk=20 ________________________________________ From: multimob-bounces@ietf.org [multimob-bounces@ietf.org] On Behalf Of = Dirk.von-Hugo@telekom.de [Dirk.von-Hugo@telekom.de] Sent: 11 June 2010 11:27 To: multimob@ietf.org Subject: [multimob] WG: New Version Notification for = draft-von-hugo-multimob-future-work-02 Dear all, We have posted an update of the draft on future extension for multimob = optimizations focusing on currently discussed drafts ... thus covering = the near-future work. Please comment if you think we should add or = modify topics for preparation of the re-chartering discussion in = Maastricht. Best regards Dirk -----Urspr=FCngliche Nachricht----- Von: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Gesendet: Freitag, 11. Juni 2010 11:31 An: von Hugo, Dirk Cc: asaeda@wide.ad.jp; sarikaya@ieee.org; = pierrick.seite@orange-ftgroup.com Betreff: New Version Notification for = draft-von-hugo-multimob-future-work-02 A new version of I-D, draft-von-hugo-multimob-future-work-02.txt has = been successfully submitted by Dirk von Hugo and posted to the IETF = repository. Filename: draft-von-hugo-multimob-future-work Revision: 02 Title: Evaluation of further issues on Multicast Mobility: = Potential future work for WG MultiMob Creation_date: 2010-06-08 WG ID: Independent Submission Number_of_pages: 15 Abstract: The WG MultiMob aims at defining a basic mobile multicast solution leveraging on network localized mobility management, i.e. Proxy Mobile IPv6 protocol. The solution would be basically based on multicast group management, i.e. IGMP/MLD, proxying at the access gateway. If such a basic solution is essential from an operational point of view, challenges with efficient resource utilization and user perceived service quality still persist. These issues may prevent large scale deployments of mobile multicast applications. This document attempts to identify topics for near future extension of work such as modifying multimob base solution, PMIPv6 and MLD/ IGMP for optimal multicast support, and adaptation of Handover optimization. Far future items such as extending to and modifying of MIPv4/v6 and DSMIP, sender (source) mobility, consideration of multiple flows and multihoming will be dealt with in a future version. The IETF Secretariat. _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob Edinburgh Napier University - one of the top 10 universities in the UK = for graduate employability (HESA 2009) and proud winners of the Queen's = Anniversary Prizes for Higher and Further Education 2009, awarded for = innovative housing construction for environmental benefit and quality of = life. This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the = University without the permission of the sender. It is your = responsibility to ensure that this message and any attachments are = scanned for viruses or other defects.=20 Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors = or omissions arising after it was sent. Email is not a secure medium. = Email entering the University's system is subject to routine monitoring = and filtering by the University.=20 Edinburgh Napier University is a registered Scottish charity. Registration number SC018373 From behcetsarikaya@yahoo.com Sun Jun 13 21:21:31 2010 Return-Path: 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 90D3D3A67CC for ; Sun, 13 Jun 2010 21:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=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 DawqiTgGX399 for ; Sun, 13 Jun 2010 21:21:30 -0700 (PDT) Received: from web111406.mail.gq1.yahoo.com (web111406.mail.gq1.yahoo.com [67.195.15.162]) by core3.amsl.com (Postfix) with SMTP id 235563A67A3 for ; Sun, 13 Jun 2010 21:21:29 -0700 (PDT) Received: (qmail 94316 invoked by uid 60001); 14 Jun 2010 04:21:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1276489292; bh=Ky/o/BdhJl2k9xpu65eJUZrKoDezfLSez9QpQ4Qc/00=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3S6/gBVO3SValiDejxi7kVLIrf0pMCxMzhZX+0Ktr3iUjH5VqdxhhmqKICpnJ/OgzwJc8VgC9No6CkO/85pqwiIOeEVK5qYZldgUID/8paMqYLIPht+qj6O75GZPvquaNL5ZDFR8nNATLTdGaMlRYn6HmgNvVnOS1hTTib6TpJ4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TjEsDQwr0hvt5v1DDGO9li4HlklGglDh3k4gHyMPCSM/8opGNkMrnODh1ubc+uBrUXCUfzrnAS+/3Dff9QihAbQNeXDKqv44G2q905dMk6sk2Th6z/iItXWN88cKoSeDvbh0y2dpbDqs/UFnAGz1utHqZgpl3XpfiJC7n7PSvaQ=; Message-ID: <100873.94032.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: iSIzYaMVM1nh9kb05vG4xrVJftmN013IsbMaI5jdn4MhNZO Yeu_IrCCeK89oOyWVbgCEmw2hDUdlgVgr563oeoD9tRUKiWrzwGMiwBeEcSC 5uDA13gTKzQklQ2lYnAkhIEpfyqPr4qkEPPykj1LhsDnGvDNASmjBHgXSro. rfiR1xI98uOQFJBKlY.QfNFJyxC7176rbaEyn3NsEYRsqj0KxwxGg1I446To e5JQfRNaAEQsh2Bcid6zuwXbmiGNn9xsTazuvvk0zC3mmLOlJBgGPoXbpc1Y F1s5PWXIzYEK07_tFtYj7ZQiIWenHPzGhVQqEz9hQ Received: from [72.64.108.212] by web111406.mail.gq1.yahoo.com via HTTP; Sun, 13 Jun 2010 21:21:32 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C091ADE.7080703@informatik.haw-hamburg.de> Date: Sun, 13 Jun 2010 21:21:32 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4C091ADE.7080703@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Mon, 14 Jun 2010 04:21:31 -0000 Hi Thomas, Here are my proposals: 1. Section 1. Par. 2: With these entities in place, the mobile node looses transparent end-to-end connectivity to the static Internet, and in the particular case of multicast communication, group membership management as signaled by the Multicast Listener Discovery protocol [RFC3810], [RFC2710] requires dedicated treatment at the network side. Section 1 Paragraph 3, here only state the pros of the proxy approach like avoiding avalanche of packet duplication at the LMA and subsequent delivery from LMA to MAG. 2. IPv4 support section, OK, no need for NAT text. RFC 5135 requires NAT boxes at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe it is out of scope. You may wish to mention something like this though. 3. Section 5.1 destination address: FF02::1 and 5.2 destination address FF02::16 Add Section 5.3 Multicast Data IPv6: outer LMAA - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- 232.255.255.255 Appendix C. Remove Appendix B. May be keep, removing is also OK. Regards, Behcet From schmidt@informatik.haw-hamburg.de Mon Jun 14 04:02:12 2010 Return-Path: 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 2F9983A68B8 for ; Mon, 14 Jun 2010 04:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ol70szpd0U+u for ; Mon, 14 Jun 2010 04:02:10 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B9B3C3A68B1 for ; Mon, 14 Jun 2010 04:02:09 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231226016.adsl.alicedsl.de ([92.231.226.16] helo=[192.168.178.116]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OO7Qi-000HwZ-73; Mon, 14 Jun 2010 13:02:12 +0200 Message-ID: <4C160C2F.80500@informatik.haw-hamburg.de> Date: Mon, 14 Jun 2010 13:02:07 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Stig Venaas References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C0E8170.1030005@venaas.com> In-Reply-To: <4C0E8170.1030005@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Mon, 14 Jun 2010 11:02:12 -0000 Hi Stig, On 08.06.2010 19:44, Stig Venaas wrote: > Behcet Sarikaya wrote: >> Hi Thomas, >> See inline. > [...] >>>> Section 5.1 and >>>> >>> 5.2 have not picked up. >>>> 5.1/5.2 explain resp. >>> give reference to >>>> the use of addressing in MLD. As >>> destination addresses depend on the context >>>> of the messaging >>> (as >>> differently defined in RFCs 2710 and 3810), only the >>> pointer is given in >>>> this overview. >>> If that is the case then state the specific values for each, I don't >>> think MLD has a million different messages. >>> >> >>> [Thomas=> Unclear: if you (or any reader) wants to know about the >> details of MLD, you should read the corresponding >>> document. There is no >> sense (and for good reasons no practice) to retell the >>> content of >> previous RFCs. This would only be a source of >>> misunderstandings. >> >> [behcet] >> By the way, I read those RFCs. Thank you for your advice :-)! >> >> However, I find it strange to give a whole RFC of 61 pages (3810) to >> figure out what the destination address will be. Plus 22 pages for 2710. >> >> You created this problem you should correct it. See more below. >> >> >> >>>> Regarding IPv4: This document >>> is >>>> focused on PMIP*v6* - and there is an >>> obvious correspondence between MLD and >>>> IGMP. I don't see much value >>> in >>> repeating the tables with the obvious >>>> changes ... but >>> this is not a >>> crucial part. It would just make the text >>> longer. >>> >>> Why not? It is some useful detail. >> >>> [Thomas=> I don't see the point. This draft is about deployment and not >> implementation. >>> Readers should get the idea of what is happening in the >> network, but should >>> not be guided to re-implement IGMP or MLD. >> >> [behcet] >> Here you are contradicting yourself. >> >> Why have Sections 5.1 and 5.2 then? It was you who included them, all >> I am asking is to make it more clear and complete. >> >>> However, this seems to turn into a matter of taste. Maybe we should >> follow a third party advise - Stig, >>> what would you consider more >> appropriate: additional IGMP address tables or >>> not? >> >> [behcet] >> There is no third party here. We are a working group and WG has >> members. I posted my comments as a member of WG not as chair's comments. >> >> I don't know what you are talking about? Can you explain? > > I would, frankly speaking, say that section 5 is pretty useless. Is > there any value in this section? I think all the reader needs to know > is that MLD/IGMP is encapsulated and sent as normal. So maybe remove it? The reason for this section actually is Jouni Korhonen who asked for explicitly laying out MLD addressing/encapsulation. I perfectly agree with you that there is nothing new or surprising here. Still with Jouni asking for it, there seemed to be a need for making this more visible ... > > One should not include more details from other RFCs than is needed to > explain the idea at hand. So talking about exact MLD/IGMP message > formats and addressing should be avoided if it behaves exactly as > normal. > > Otherwise one may start to wonder whether it behaves differently in this > specific context. > Maybe we should add a sentence that this is just a recap of the standard behavior? Cheers, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From schmidt@informatik.haw-hamburg.de Mon Jun 14 04:39:13 2010 Return-Path: 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 B2A673A68B5 for ; Mon, 14 Jun 2010 04:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=1.166, 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 fmhmTjEFw2w2 for ; Mon, 14 Jun 2010 04:39:12 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 84E383A68C0 for ; Mon, 14 Jun 2010 04:39:12 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231226016.adsl.alicedsl.de ([92.231.226.16] helo=[192.168.178.116]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OO80Z-000MYQ-4L; Mon, 14 Jun 2010 13:39:15 +0200 Message-ID: <4C1614DD.6090003@informatik.haw-hamburg.de> Date: Mon, 14 Jun 2010 13:39:09 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Behcet Sarikaya References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C091ADE.7080703@informatik.haw-hamburg.de> <100873.94032.qm@web111406.mail.gq1.yahoo.com> In-Reply-To: <100873.94032.qm@web111406.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: Behcet Sarikaya , multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Mon, 14 Jun 2010 11:39:14 -0000 Hi Behcet, On 14.06.2010 06:21, Behcet Sarikaya wrote: > Section 1 Paragraph 3, > here only state the pros of the proxy approach like avoiding avalanche of packet duplication at the LMA and subsequent delivery from LMA to MAG. Sorry, I don't agree: this section is not on how to avoid avalanches or other performance degradations, but on the requirement of defining a solution at all. As Stig wrote in a previous mail, it is very important to make clear why an explicit multicast solution is needed in PMIPv6 - this is because the "MIPv6 minimal solution", namely bi-directional tunneling, does not work in PMIP. This should be clearly stated ... and after several discussions and revisions, we should have arrived at a proper formulation (see mail to Pierrick), I believe. > > 2. IPv4 support section, > OK, no need for NAT text. > RFC 5135 requires NAT boxes at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe it is out of scope. You may wish to mention something like this though. > RFC 5135 does not require a deployment of NAT boxes! - Section 3 of RFC 5135 just gives background scenarios on common use of NAT boxes in access networks - but this is a scenario for cable modem, completely orthogonal to a PMIP deployment. > 3. Section 5.1 > destination address: FF02::1 > > > and > 5.2 destination address FF02::16 This is not the full truth: there are different queries and reports defined in MLD ... re-pointing to the dialog with Stig: it certainly does not make sense to expand the MLD recap ... if it is helpful to readers, we should add a warning like "this is just a recap" ... if not, we should remove it. > > Add Section 5.3 Multicast Data > IPv6: outer LMAA - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF > > IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- 232.255.255.255 > Multicast data is not a problem here, as routing is explained in detail in sections 3 and 4. The somewhat intricate part is the signaling - that's why Jouni asked for clarification. > Appendix C. Remove > > Appendix B. May be keep, removing is also OK. > I guess we already agreed that the Appendices should be judged according to AD review - we can remove any of those if desired, but we should keep them for the reviews so that they remain accessible for evaluation. For the general progress: If there are no more comments showing up, we would update the version 2 of this document and include the various feedbacks from WG last call this evening and await further actions ;) Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From behcetsarikaya@yahoo.com Mon Jun 14 08:01:11 2010 Return-Path: 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 DF7E43A68C4 for ; Mon, 14 Jun 2010 08:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=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 fF3EVMj-galG for ; Mon, 14 Jun 2010 08:01:11 -0700 (PDT) Received: from web111401.mail.gq1.yahoo.com (web111401.mail.gq1.yahoo.com [67.195.15.132]) by core3.amsl.com (Postfix) with SMTP id DF57A3A67B8 for ; Mon, 14 Jun 2010 08:01:10 -0700 (PDT) Received: (qmail 92028 invoked by uid 60001); 14 Jun 2010 15:01:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1276527671; bh=bixVAFXgCiLq9FlpRPwxIZZ1Coepsf/t1Fdir2+iXOU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tafENVLJu4yk98DwG5T1WU3SVpOauqnk0DxNzkaErz8JUKBu2EVV8lrer9ToPIPAgn/08RrzSbo2ZVHLUs7mGq9U+bckUQKDbigjp3F5qrFCGHSCVD1WU6TFmX11LKFqzr/RWLjxQGZr//m7XGaZY5LCffuve448YW2YP7zvYPg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=C+NtgesJ5jSjU8wYr4ghLEaTCg26fs192RWS+eluqcMElcjZUKJlHrhZMSWOPTDZGlPCKKoaDdU3xwK2JEjpmapLopmcnvKPXFwEeQErvjLigU0bpVtH5r2Y/FO02mX2eEl4NMrJ0oDtkBsxuGHa380Be7EpILh55zV48w5R3+o=; Message-ID: <804731.80425.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: G4s8mBcVM1lbLPBY2JEmNZ3S0QnNR7wy66aEbJqy3.tDHfs k3MrhIc9PmXeAh47D8Dqh13ib5cnYDGD6s3ilUtgo1vq70HJVDYosjk6nbzE C_xgxJ_St_lWhZHHh42SF1qA2k8Ij9lxNJLl_CjwC5GDWsNR08atFoRPgYO3 DJpXu9pQfKJ8QDUmbrVuwt5LdyXBwO1TJDivCAft.JZNeDZcYgf6ZnypWvDv bqWKUmNtLSjP0YStA3WRkBbM0RY6Niarq8f4PSwJSSJeMmpW52PK4Pk4lL8s PQgjbFZ7nrlQgWa0huy.xtQxXw6UiFatuqIcYCtgEymXc4TvC0KGnskgtGlS Ar9_uMlJ61HXx Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Mon, 14 Jun 2010 08:01:11 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.103.269680 References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C091ADE.7080703@informatik.haw-hamburg.de> <100873.94032.qm@web111406.mail.gq1.yahoo.com> <4C1614DD.6090003@informatik.haw-hamburg.de> Date: Mon, 14 Jun 2010 08:01:11 -0700 (PDT) From: Behcet Sarikaya To: "Thomas C. Schmidt" In-Reply-To: <4C1614DD.6090003@informatik.haw-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt 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: , X-List-Received-Date: Mon, 14 Jun 2010 15:01:12 -0000 Hi Thomas,=0A=0A=A0=0A=0A=0A----- Original Message ----=0A> From: Thomas C.= Schmidt =0A> To: Behcet Sarikaya =0A> Cc: Behcet Sarikaya ; multimob@= ietf.org=0A> Sent: Mon, June 14, 2010 6:39:09 AM=0A> Subject: Re: [multimob= ] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt=0A> =0A> = Hi Behcet,=0A=0AOn 14.06.2010 06:21, Behcet Sarikaya wrote:=0A=0A=0A> =0A> = Section 1 Paragraph 3,=0A> here only state the pros of the proxy approach = =0A> like avoiding avalanche of packet duplication at the LMA and subsequen= t delivery =0A> from LMA to MAG.=0A=0A> Sorry, I don't agree: this section = is not on how to =0A> avoid avalanches or other performance degradations, b= ut on the requirement of =0A> defining a solution at all.=0A=0A[behcet] Did= I say that it is about avoiding avalanches?=0AI don't know on what you are= basing your biased statements :-).=0A=0A> As Stig wrote in a previous mail= , it is very =0A> important to make clear why an explicit multicast solutio= n is needed in PMIPv6 - =0A> this is because the "MIPv6 minimal solution", = namely bi-directional tunneling, =0A> does not work in PMIP. =0A=0A[behcet]= Why not? How do you know?=0A=0A> This should be clearly stated ... and aft= er several =0A> discussions and revisions, we should have arrived at a prop= er formulation (see =0A> mail to Pierrick), =0A=0A> I believe.=0A=0A[behcet= ] No I don't.=0A=0A> =0A> 2. IPv4 support =0A> section,=0A> OK, no need for= NAT text.=0A> RFC 5135 requires NAT boxes =0A> at the CPEs like Cable mode= m to have an IGMP Proxy for correct operation. Maybe =0A> it is out of scop= e. You may wish to mention something like this though.=0A> =0A> =0A=0A> RFC= 5135 does not require a deployment of NAT boxes! - =0A=0A[behcet] What are= you talking about?=0A=0A> Section 3 of RFC =0A> 5135 just gives background= scenarios on common use of NAT boxes in access =0A> networks - but this is= a scenario for cable modem, completely orthogonal to a =0A> PMIP deploymen= t.=0A=0A[behcet] May be so.=0A=0A> 3. Section 5.1=0A> destination address: = =0A> FF02::1=0A> =0A> =0A> and=0A> 5.2 destination address =0A> FF02::16=0A= =0A> This is not the full truth: there are different queries and =0A> repor= ts defined in MLD ... re-pointing to the dialog with Stig: it certainly =0A= > does not make sense to expand the MLD recap ... if it is helpful to reade= rs, we =0A> should add a warning like "this is just a recap" ... if not, we= should remove =0A> it.=0A=0A[behcet] Yes, MLD allows the destination addre= ss to be MAG or LMA address as well but I don't think it is an important "r= ecap" or what ever. If there are other important values please feel free to= add.=0A=0A=0A> =0A> Add Section 5.3 Multicast Data=0A> IPv6: outer LMAA = =0A> - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF=0A> =0A= > =0A> IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- = =0A> 232.255.255.255=0A> =0A=0A> Multicast data is not a problem here, as r= outing =0A> is explained in detail in sections 3 and 4. The somewhat intric= ate part is the =0A> signaling - that's why Jouni asked for clarification.= =0A=0A[behcet] I have not seen this mail on the list but my reaction is ple= ase go ahead and make the required changes. Be positive.=0A=0A=0A[behcet] T= he point here is that unlike the authors, I went ahead and read the standar= ds and found these values and now proposing them.=0A=0A=0A=0A> Appendix C. = =0A> Remove=0A> =0A> Appendix B. May be keep, removing is also OK.=0A> =0A>= =0A=0A> I guess we already agreed that the Appendices should be judged acc= ording =0A> to AD review - we can remove any of those if desired, but we sh= ould keep them =0A> for the reviews so that they remain accessible for eval= uation.=0A=0A[behcet] There are steps. Now we are at the WGLC step. You nee= d to pass this step before going to the next.=0A=0AAs for Annex C, it does = not add any value to the draft and it has a reference to an individual draf= t. It is not a complete analysis of all possible solution approaches.=0ASho= uld I say more?=0A=0A> For =0A> the general progress:=0A=0A> If there are n= o more comments showing up, we would =0A> update the version 2 of this docu= ment and include the various feedbacks from WG =0A> last call this evening = and await further actions ;)=0A=0A[behcet] I don't think the draft authors = are to judge on such things. Please concentrate on each step one by one.=0A= =0A[behcet] =0AOverall, the authors should=A0be open to make positive impro= vements on their draft so that WGLC can progress with success.=0A=0ARegards= ,=0A=0ABehcet=0A=0A=0A From schmidt@informatik.haw-hamburg.de Mon Jun 14 14:15:21 2010 Return-Path: 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 6A3E93A69F0 for ; Mon, 14 Jun 2010 14:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.539, 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 MwQhf6e0i5w7 for ; Mon, 14 Jun 2010 14:14:54 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id EE9083A6946 for ; Mon, 14 Jun 2010 14:14:49 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231226016.adsl.alicedsl.de ([92.231.226.16] helo=[192.168.178.117]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OOGzb-000H3x-4U; Mon, 14 Jun 2010 23:14:51 +0200 Message-ID: <4C169BC9.6080403@informatik.haw-hamburg.de> Date: Mon, 14 Jun 2010 23:14:49 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Behcet Sarikaya References: <20100531220002.3D5D33A691B@core3.amsl.com> <4C04347D.3080001@informatik.haw-hamburg.de> <125247.22571.qm@web111412.mail.gq1.yahoo.com> <4C065DA8.6020308@informatik.haw-hamburg.de> <24001.82312.qm@web111415.mail.gq1.yahoo.com> <4C0819BE.80200@informatik.haw-hamburg.de> <739329.39085.qm@web111404.mail.gq1.yahoo.com> <4C08E943.8050502@informatik.haw-hamburg.de> <470436.92236.qm@web111412.mail.gq1.yahoo.com> <4C091ADE.7080703@informatik.haw-hamburg.de> <100873.94032.qm@web111406.mail.gq1.yahoo.com> <4C1614DD.6090003@informatik.haw-hamburg.de> <804731.80425.qm@web111401.mail.gq1.yahoo.com> In-Reply-To: <804731.80425.qm@web111401.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: Behcet Sarikaya , multimob@ietf.org Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.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: , X-List-Received-Date: Mon, 14 Jun 2010 21:15:21 -0000 Hi Behcet, On 14.06.2010 17:01, Behcet Sarikaya wrote: > Hi Thomas, > > > > > ----- Original Message ---- >> From: Thomas C. Schmidt >> To: Behcet Sarikaya >> Cc: Behcet Sarikaya; multimob@ietf.org >> Sent: Mon, June 14, 2010 6:39:09 AM >> Subject: Re: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-02.txt >> >> Hi Behcet, > > On 14.06.2010 06:21, Behcet Sarikaya wrote: > > >> >> Section 1 Paragraph 3, >> here only state the pros of the proxy approach >> like avoiding avalanche of packet duplication at the LMA and subsequent delivery >> from LMA to MAG. > >> Sorry, I don't agree: this section is not on how to >> avoid avalanches or other performance degradations, but on the requirement of >> defining a solution at all. > > [behcet] Did I say that it is about avoiding avalanches? > I don't know on what you are basing your biased statements :-). [Thomas => Well, as you still can see above, you wrote "state the pros of the proxy approach like avoiding avalanche" ... so I just thought you were talking about "avoiding avalanche" ... > >> As Stig wrote in a previous mail, it is very >> important to make clear why an explicit multicast solution is needed in PMIPv6 - >> this is because the "MIPv6 minimal solution", namely bi-directional tunneling, >> does not work in PMIP. > > [behcet] Why not? How do you know? > [thomas => Well, the issue has been debated already when setting up the charter ... and thereafter several times on the list and in meetings. The core argument is clearly given in this paragraph - there is no counter-argument on the table. So I just don't see room for questioning the statement. However, if you actually do have a counter-argument, you should release it right now. >> This should be clearly stated ... and after several >> discussions and revisions, we should have arrived at a proper formulation (see >> mail to Pierrick), > >> I believe. > > [behcet] No I don't. > [thomas => It seems you are the only one. As said, this has been under discussion several times. >> >> 2. IPv4 support >> section, >> OK, no need for NAT text. >> RFC 5135 requires NAT boxes >> at the CPEs like Cable modem to have an IGMP Proxy for correct operation. Maybe >> it is out of scope. You may wish to mention something like this though. >> >> > >> RFC 5135 does not require a deployment of NAT boxes! - > > [behcet] What are you talking about? > >> Section 3 of RFC >> 5135 just gives background scenarios on common use of NAT boxes in access >> networks - but this is a scenario for cable modem, completely orthogonal to a >> PMIP deployment. > > [behcet] May be so. > >> 3. Section 5.1 >> destination address: >> FF02::1 >> >> >> and >> 5.2 destination address >> FF02::16 > >> This is not the full truth: there are different queries and >> reports defined in MLD ... re-pointing to the dialog with Stig: it certainly >> does not make sense to expand the MLD recap ... if it is helpful to readers, we >> should add a warning like "this is just a recap" ... if not, we should remove >> it. > > [behcet] Yes, MLD allows the destination address to be MAG or LMA address as well but I don't think it is an important "recap" or what ever. If there are other important values please feel free to add. [thomas => I have not seen any mobility-related entities being mentioned in any of the MLD RFCs. My pointer was on different query/report types as defined in the MLD specs. > > >> >> Add Section 5.3 Multicast Data >> IPv6: outer LMAA >> - Proxy-CoA1 inner CP address - FF3X::8000:0 - FF3X::FFFF:FFFF >> >> >> IPv4 outer IPv4-LMAA - IPv4-Proxy-CoA inner CP address - 232.0.1.0- >> 232.255.255.255 >> > >> Multicast data is not a problem here, as routing >> is explained in detail in sections 3 and 4. The somewhat intricate part is the >> signaling - that's why Jouni asked for clarification. > > [behcet] I have not seen this mail on the list but my reaction is please go ahead and make the required changes. Be positive. > [thomas => So we did: following the argument of Jouni, we added section 5. The status of this section is now as follows: * Jouni requested it as is * You proposed to copy significant parts from the MLD and IGMP specs into it * Stig said, the whole section could be removed as it is already defined elsewhere and could irritate people * We proposed a compromise in adding a statement that clarifies that there are no new definitions here, but just the translation of (encapsulated) MLD signaling into PMIPv6 language. > > [behcet] The point here is that unlike the authors, I went ahead and read the standards and found these values and now proposing them. [thomas => I don't understand - but it's good to care for mcast addresses: btw - we are not restricted to SSM ... > > > >> Appendix C. >> Remove >> >> Appendix B. May be keep, removing is also OK. >> >> > >> I guess we already agreed that the Appendices should be judged according >> to AD review - we can remove any of those if desired, but we should keep them >> for the reviews so that they remain accessible for evaluation. > > [behcet] There are steps. Now we are at the WGLC step. You need to pass this step before going to the next. [thomas => I'm not sure what you are saying. In WGLC we have received quite a number of good comments, have exchanged a set of additional arguments, and are about to improve the document accordingly. Your comments, as they are not on formal procedures but on content, must be treated as individual comments. And if your suggestions are obviously incorrect (as all the addresses above), then it is the responsibility of the authors (and the WG) to prevent failures from sneaking into the document. I guess that's what you wanted to say, right? > > As for Annex C, it does not add any value to the draft and it has a reference to an individual draft. It is not a complete analysis of all possible solution approaches. > Should I say more? > >> For >> the general progress: > >> If there are no more comments showing up, we would >> update the version 2 of this document and include the various feedbacks from WG >> last call this evening and await further actions ;) > > [behcet] I don't think the draft authors are to judge on such things. Please concentrate on each step one by one. > > [behcet] > Overall, the authors should be open to make positive improvements on their draft so that WGLC can progress with success. > [thomas => Exactly! Authors need to take up comments that lead to *positive improvements* and update their draft so that WGLC can progress with success. That's what we're saying and that's what we are doing. To be precise, I was proposing to do this right now. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From root@core3.amsl.com Mon Jun 14 15:45:03 2010 Return-Path: X-Original-To: multimob@ietf.org Delivered-To: multimob@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 015E63A6A01; Mon, 14 Jun 2010 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100614224503.015E63A6A01@core3.amsl.com> Date: Mon, 14 Jun 2010 15:45:02 -0700 (PDT) Cc: multimob@ietf.org Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-03.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: , X-List-Received-Date: Mon, 14 Jun 2010 22:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-03.txt Pages : 20 Date : 2010-06-14 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-03.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-14153414.I-D@ietf.org> --NextPart-- From schmidt@informatik.haw-hamburg.de Mon Jun 14 15:59:56 2010 Return-Path: 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 9754E3A6A0B for ; Mon, 14 Jun 2010 15:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.330, 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 w673F7lf4+Kj for ; Mon, 14 Jun 2010 15:59:55 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id B63C93A69A8 for ; Mon, 14 Jun 2010 15:59:55 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231226016.adsl.alicedsl.de ([92.231.226.16] helo=[192.168.178.117]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OOIdK-0005U7-JM for multimob@ietf.org; Tue, 15 Jun 2010 00:59:58 +0200 Message-ID: <4C16B46C.1020808@informatik.haw-hamburg.de> Date: Tue, 15 Jun 2010 00:59:56 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "multimob@ietf.org" Content-Type: multipart/mixed; boundary="------------050000040309030305010406" X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: [multimob] Fwd: I-D Action:draft-ietf-multimob-pmipv6-base-solution-03.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: , X-List-Received-Date: Mon, 14 Jun 2010 22:59:56 -0000 This is a multi-part message in MIME format. --------------050000040309030305010406 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have just updated draft-ietf-multimob-pmipv6-base-solution. The update includes clarifications and editorial improvements as proposed and discussed on the list. Thanks to all careful reviewers! Cheers, Thomas -------- Original Message -------- Subject: [multimob] I-D Action:draft-ietf-multimob-pmipv6-base-solution-03.txt Date: Mon, 14 Jun 2010 15:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: multimob@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Mobility Working Group of the IETF. Title : Base Deployment for Multicast Listener Support in PMIPv6 Domains Author(s) : T. Schmidt, et al. Filename : draft-ietf-multimob-pmipv6-base-solution-03.txt Pages : 20 Date : 2010-06-14 This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to Home Agents in Mobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide MLD proxy functions. In this scenario, Mobile Nodes remain agnostic of multicast mobility operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solution-03.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. --------------050000040309030305010406 Content-Type: Message/External-body; name="draft-ietf-multimob-pmipv6-base-solution-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-multimob-pmipv6-base-solution-03.txt" Content-Type: text/plain Content-ID: <2010-06-14153414.I-D@ietf.org> --------------050000040309030305010406 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob --------------050000040309030305010406-- From behcetsarikaya@yahoo.com Tue Jun 15 08:54:36 2010 Return-Path: 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 35F1228C12C for ; Tue, 15 Jun 2010 08:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 EZbami3UvTPv for ; Tue, 15 Jun 2010 08:54:35 -0700 (PDT) Received: from web111415.mail.gq1.yahoo.com (web111415.mail.gq1.yahoo.com [67.195.15.216]) by core3.amsl.com (Postfix) with SMTP id 7161628C101 for ; Tue, 15 Jun 2010 08:54:35 -0700 (PDT) Received: (qmail 21818 invoked by uid 60001); 15 Jun 2010 15:54:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1276617279; bh=4018A1TcppXB/VMu62lNWbumu5BNX48Erp59abjmQTA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=F0zIWwQHAUc2Z1YKvk2m+o7SLrkr/Ztkqc6f5O4QjKYGWvVRaQG7K/4PaLce2Kjvy0lSWmDfNsZVNI4otBNAFuliFvU5eJz+50Abss2pk6+tpn8iHBIsFJphKbJM/AbNqXdarGAfnYKL8KbainNC92Hi62o6VqkecpvsxZhELjA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=BOUuUJSPgHsshmh5KIgvzY2eT/VoF5PcB8Or28jMjcpJzfOhqkl4zlFO58EtYWw+xkLf6E9PS1hoihGbN7dTFH2xdoBROPs0PslBQha7l4DaMRwxF6eWp1J11ELURbEOZmyrLT40aIHLT7w1Wy5sHGVYS4JMdRcPukAYDQD8K44=; Message-ID: <88358.21693.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: D0e8BiUVM1kuZqwWaOHYMMZUyQLNxatgl0v2Ud63PLRIUHU 9ZYHSP18lHtxLcY1UkH6OITTdBe3873lgoUgl0vw7joFQQA0.07CIjTCtDDk tWlSAhdBk2JswUbV1rGtU_722aAOqDZo1Zll9.TfgAa7CI96nd4PmAMtTdY3 MSep5BDZGJOZ4o8U9qjET8ilHOx68SFpMvuaQPjN9LARO_puK29u0ovfctP9 wGLQlw25Te2m8uCTFpXStefhuanMk.TBr407.jidDBdY4RdFyq2DhtvKD.pR acSYL.YqQiswdb2dhE0sIpfZvS.IJziMYhW3_wLbPAxe0AcqzfV3NPymJUDz nyrGRKN5Qz2Zh Received: from [206.16.17.212] by web111415.mail.gq1.yahoo.com via HTTP; Tue, 15 Jun 2010 08:54:38 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.103.269680 Date: Tue, 15 Jun 2010 08:54:38 -0700 (PDT) From: Behcet Sarikaya To: Sri Gundavelli , multimob@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1235108740-1276617278=:21693" Subject: [multimob] Expert Review for draft-ietf-multimob-pmipv6-base-solution-03.txt 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: , X-List-Received-Date: Tue, 15 Jun 2010 15:54:36 -0000 --0-1235108740-1276617278=:21693 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sri,=0A=A0 Multimob WG has the attached draft in Working Group Last Call= . Before sending the draft to the IESG, I would like to ask you for an expe= rt review.=0A=A0 Can you please review the draft and send your comments in = a few days?=0A=0AThanks in advance,=0A=0ABehcet=0A=0A=0A=0A----- Forwarded = Message ----=0A> From: "Internet-Drafts@ietf.org" =0A> To: i-d-announce@ietf.org=0A> Cc: multimob@ietf.org=0A> Sent: Mon, Ju= ne 14, 2010 5:45:02 PM=0A> Subject: [multimob] I-D Action:draft-ietf-multim= ob-pmipv6-base-solution-03.txt=0A> =0A> A New Internet-Draft is available f= rom the on-line Internet-Drafts =0A> directories.=0AThis draft is a work it= em of the Multicast Mobility Working =0A> Group of the IETF.=0A=0A=0A=A0=A0= =A0 Title=A0 =A0 =A0 =0A> =A0 =A0 : Base Deployment for Multicast Listener = Support in PMIPv6 =0A> Domains=0A=A0=A0=A0 Author(s)=A0 =A0 =A0 : T. Schmid= t, et =0A> al.=0A=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : =0A> draft-ietf-multim= ob-pmipv6-base-solution-03.txt=0A=A0=A0=A0 =0A> Pages=A0 =A0 =A0 =A0 =A0 : = 20=0A=A0=A0=A0 Date=A0 =0A> =A0 =A0 =A0 =A0 =A0 : 2010-06-14=0A=0AThis docu= ment describes =0A> deployment options for activating multicast=0Alistener = functions in Proxy =0A> Mobile IPv6 domains without modifying=0Amobility an= d multicast protocol =0A> standards.=A0 Similar to Home Agents in=0AMobile = IPv6, Local Mobility =0A> Anchors of Proxy Mobile IPv6 serve as=0Amulticast= subscription anchor points, =0A> while Mobile Access Gateways=0Aprovide ML= D proxy functions.=A0 In this =0A> scenario, Mobile Nodes remain=0Aagnostic= of multicast mobility =0A> operations.=0A=0AA URL for this Internet-Draft = =0A> is:=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-b= ase-solution-03.txt=0A=0AInternet-Drafts =0A> are also available by anonymo= us FTP at:=0A> href=3D"ftp://ftp.ietf.org/internet-drafts/" =0A> target=3D_= blank>ftp://ftp.ietf.org/internet-drafts/=0A=0ABelow is the data =0A> which= will enable a MIME compliant mail reader=0Aimplementation to =0A> automati= cally retrieve the ASCII version of the=0AInternet-Draft.=0A=0A=0A --0-1235108740-1276617278=:21693 Content-Type: message/external-body; name="draft-ietf-multimob-pmipv6-base-solution-03.txt"; site="ftp.ietf.org"; access-type=anon-ftp; directory=internet-drafts Content-Transfer-Encoding: 8bit Content-Type: text/plain Content-ID: <2010-06-14153414.I-D@ietf.org> --0-1235108740-1276617278=:21693-- From sgundave@cisco.com Tue Jun 15 20:26:09 2010 Return-Path: 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 AF7293A66B4 for ; Tue, 15 Jun 2010 20:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 61PaUX1Rc5rF for ; Tue, 15 Jun 2010 20:26:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9C0233A65A6 for ; Tue, 15 Jun 2010 20:26:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACbhF0yrR7H+/2dsb2JhbACSLIxNcaYjmiKFGgSDUA X-IronPort-AV: E=Sophos;i="4.53,424,1272844800"; d="scan'208";a="212974225" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2010 03:26:13 +0000 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.14.3) with ESMTP id o5G3QDjs022454; Wed, 16 Jun 2010 03:26:13 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 20:26:13 -0700 Received: from 10.32.243.93 ([10.32.243.93]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Jun 2010 03:26:12 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Tue, 15 Jun 2010 20:26:55 -0700 From: Sri Gundavelli To: Behcet Sarikaya , Message-ID: Thread-Topic: Expert Review for draft-ietf-multimob-pmipv6-base-solution-03.txt Thread-Index: AcsNA8TrwskbTp46wUm5w+TrFsQ1HQ== In-Reply-To: <88358.21693.qm@web111415.mail.gq1.yahoo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Jun 2010 03:26:13.0393 (UTC) FILETIME=[AC1E7010:01CB0D03] Subject: Re: [multimob] Expert Review for draft-ietf-multimob-pmipv6-base-solution-03.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: , X-List-Received-Date: Wed, 16 Jun 2010 03:26:09 -0000 Hi Behcet, Sure. I will review and post the comments, some time next week. Thanks Sri On 6/15/10 8:54 AM, "Behcet Sarikaya" wrote: > Hi Sri, > =A0 Multimob WG has the attached draft in Working Group Last Call. Before > sending the draft to the IESG, I would like to ask you for an expert revi= ew. > =A0 Can you please review the draft and send your comments in a few days? >=20 > Thanks in advance, >=20 > Behcet >=20 >=20 >=20 > ----- Forwarded Message ---- >> From: "Internet-Drafts@ietf.org" >> To: i-d-announce@ietf.org >> Cc: multimob@ietf.org >> Sent: Mon, June 14, 2010 5:45:02 PM >> Subject: [multimob] I-D >> Action:draft-ietf-multimob-pmipv6-base-solution-03.txt >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. > This draft is a work item of the Multicast Mobility Working >> Group of the IETF. >=20 >=20 > =A0=A0=A0 Title=A0 =A0 =A0=20 >> =A0 =A0 : Base Deployment for Multicast Listener Support in PMIPv6 >> Domains > =A0=A0=A0 Author(s)=A0 =A0 =A0 : T. Schmidt, et >> al. > =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : >> draft-ietf-multimob-pmipv6-base-solution-03.txt > =A0=A0=A0=20 >> Pages=A0 =A0 =A0 =A0 =A0 : 20 > =A0=A0=A0 Date=A0=20 >> =A0 =A0 =A0 =A0 =A0 : 2010-06-14 >=20 > This document describes >> deployment options for activating multicast > listener functions in Proxy >> Mobile IPv6 domains without modifying > mobility and multicast protocol >> standards.=A0 Similar to Home Agents in > Mobile IPv6, Local Mobility >> Anchors of Proxy Mobile IPv6 serve as > multicast subscription anchor points, >> while Mobile Access Gateways > provide MLD proxy functions.=A0 In this >> scenario, Mobile Nodes remain > agnostic of multicast mobility >> operations. >=20 > A URL for this Internet-Draft >> is: > http://www.ietf.org/internet-drafts/draft-ietf-multimob-pmipv6-base-solut= ion-0 > 3.txt >=20 > Internet-Drafts=20 >> are also available by anonymous FTP at: >> href=3D"ftp://ftp.ietf.org/internet-drafts/" >> target=3D_blank>ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data >> which will enable a MIME compliant mail reader > implementation to >> automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 From sunseawq@huawei.com Sun Jun 20 17:34:04 2010 Return-Path: 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 43D453A693E for ; Sun, 20 Jun 2010 17:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=1.657, 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 PsD9QgLVz+Oa for ; Sun, 20 Jun 2010 17:34:02 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2EAE43A6947 for ; Sun, 20 Jun 2010 17:33:54 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4C0082H9KM5Y@szxga05-in.huawei.com> for multimob@ietf.org; Mon, 21 Jun 2010 08:33:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4C006FL9KMJV@szxga05-in.huawei.com> for multimob@ietf.org; Mon, 21 Jun 2010 08:33:58 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4C00CMZ9KMZG@szxml06-in.huawei.com> for multimob@ietf.org; Mon, 21 Jun 2010 08:33:58 +0800 (CST) Date: Mon, 21 Jun 2010 08:33:58 +0800 From: Qin Wu To: multimob@ietf.org Message-id: <014201cb10d9$702a2930$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20100621003004.BB1323A6948@core3.amsl.com> Subject: Re: [multimob] I-D Action:draft-wu-multimob-igmp-mld-tuning-02.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: , X-List-Received-Date: Mon, 21 Jun 2010 00:34:04 -0000 Dear all, we have just updated draft-wu-multimob-igmp-mld-tuning. http://www.ietf.org/internet-drafts/draft-wu-multimob-igmp-mld-tuning-02.txt The new version includes justification and editorial changes as discussed on the list. Look forward to your further comments on the list. Regards! -Qin ----- Original Message ----- From: To: Sent: Monday, June 21, 2010 8:30 AM Subject: I-D Action:draft-wu-multimob-igmp-mld-tuning-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and mobile networks > Author(s) : W. Wu, H. Liu > Filename : draft-wu-multimob-igmp-mld-tuning-02.txt > Pages : 19 > Date : 2010-06-20 > > This document proposes a variety of optimization approaches for > tuning IGMPv3 and MLDv2 designed to provide useful guideline to > allow wireless multicast communication in wireless networks using > the current IGMP/MLD protocols. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-multimob-igmp-mld-tuning-02.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 > From behcetsarikaya@yahoo.com Wed Jun 23 12:57:19 2010 Return-Path: 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 8BCAC3A69B7 for ; Wed, 23 Jun 2010 12:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_50=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 Ni9mat7C2NhO for ; Wed, 23 Jun 2010 12:57:18 -0700 (PDT) Received: from web111414.mail.gq1.yahoo.com (web111414.mail.gq1.yahoo.com [67.195.15.210]) by core3.amsl.com (Postfix) with SMTP id 954953A683F for ; Wed, 23 Jun 2010 12:57:18 -0700 (PDT) Received: (qmail 87620 invoked by uid 60001); 23 Jun 2010 19:57:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1277323044; bh=1PKN7eBOUN9Q5Fa0+fpkcXEZ8hran6N/GzrmGWimTbE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nmZkDZ+p9jd1NEmZHLq/frZ5lQaGHWZH7XOW0y6zvcip1UwKVv9+Qc4FGXOMUHqg/0t/4f5H0OdmDuo6IGIbgaRjyRwG5jDz4asYLq4vmlNvui7X+chojeosiq6Vxih4Lzm84VjE4KSayhNXujQU0wJQVXsRBpHgUrNztMCtnnQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n7+bX1glQJL1htXal6DGK2AuL5Alc5YopLqlj/v29vlSIRPJBLlUgQPDsI79lPhzCveyb4lOU+Dnv/7cIq+OMuI64Lft286YMnI3UTE0VWPsks1i2bSHke5IkaFqzzayMkMr5k6WGVdjH8FlYhgcjdHhe5m5F/KdebVMIMz6jeA=; Message-ID: <95096.87617.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: 2tQW51QVM1mc55HY8JnHIybugV95ME5AhwWKiQokAJlh0oB R.BVMCbnYYRmLejSAvwntVfzSqneJo05ToA6EmoM.tKv_HspMQyphs5UjOjA PG9FLVeTI2XfGIrMs_Dqe2aGW81MWRdWw_X9TPbZ0ddARRpo9mlbDr9d9hMc jwKaec2UCD2emY4o_03O7ffANihZ7qto7dX9ix7Du9Y5Oyzo9b2fl7rVTmW0 zHLZtblMHSegCmklt.ETWAn0UvnKjcs_wVCSIkPuoB.1ouKT9dqAhsaO.yJ7 S27zs2NxGiZ8Xjq4byozPUTBaIy0WqCUCUs_SWctuqxEwbR0jmOsWIpxQ5Ow tCzR..pyxaKya Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Wed, 23 Jun 2010 12:57:23 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 Date: Wed, 23 Jun 2010 12:57:23 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [multimob] 2nd WGLC for draft-ietf-multimob-pmipv6-base-solution 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: , X-List-Received-Date: Wed, 23 Jun 2010 19:57:19 -0000 Hi all,=0A=C2=A0 This mail starts a 2nd WGLC on our PMIPv6 Base Solution dr= aft. This call will end on June 29. =0A=C2=A0 We=C2=A0asked Carlos to be an= editor and he gracefully agreed. Thanks Carlos!=0A=C2=A0 Please post your = comments on the list or use the issue tracker as follows:=0A1.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 To submit an issue in TRAC, you first need to logi= n to the=C2=A0Multimob WG site on the tools server:=C2=A0 http://tools.ietf= .org/wg/multimob/trac/login =0A=0A2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If= you don=E2=80=99t already have a login ID, you can obtain one by navigatin= g to this site:=C2=A0=C2=A0 http://trac.tools.ietf.org/newlogin=0A=0A3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Once you have obtained an account, and ha= ve logged in, you can file an issue by navigating to the=C2=A0 ticket entry= form: http://trac.tools.ietf.org/wg/multimob/trac/newticket=0A=0AThanks,= =0A=0AChairs=0A=0A=0A From stig@venaas.com Wed Jun 23 13:44:30 2010 Return-Path: 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 3E19D3A69D2 for ; Wed, 23 Jun 2010 13:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-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 CIzpgJJAxkik for ; Wed, 23 Jun 2010 13:44:29 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 47C463A698F for ; Wed, 23 Jun 2010 13:44:29 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:78a4:dd4c:b998:bf32] (unknown [IPv6:2001:420:4:ea0c:78a4:dd4c:b998:bf32]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9034B8094 for ; Wed, 23 Jun 2010 22:44:35 +0200 (CEST) Message-ID: <4C22722F.9040007@venaas.com> Date: Wed, 23 Jun 2010 13:44:31 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: multimob@ietf.org References: <95096.87617.qm@web111414.mail.gq1.yahoo.com> In-Reply-To: <95096.87617.qm@web111414.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [multimob] 2nd WGLC for draft-ietf-multimob-pmipv6-base-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: , X-List-Received-Date: Wed, 23 Jun 2010 20:44:30 -0000 Behcet Sarikaya wrote: > Hi all, > This mail starts a 2nd WGLC on our PMIPv6 Base Solution draft. This call will end on June 29. If you are happy with the current version, please state so. We also need to know about positive support when submitting documents to the IESG. Stig > We asked Carlos to be an editor and he gracefully agreed. Thanks Carlos! > Please post your comments on the list or use the issue tracker as follows: > 1. To submit an issue in TRAC, you first need to login to the Multimob WG site on the tools server: http://tools.ietf.org/wg/multimob/trac/login > > 2. If you don’t already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin > > 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/multimob/trac/newticket > > Thanks, > > Chairs > > > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From trac@tools.ietf.org Wed Jun 23 14:42:03 2010 Return-Path: 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 EC7073A69CD for ; Wed, 23 Jun 2010 14:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 O3v9sW6-rda0 for ; Wed, 23 Jun 2010 14:42:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 79A513A6867 for ; Wed, 23 Jun 2010 14:42:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORXhu-0002xr-59; Wed, 23 Jun 2010 14:42:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cjbc@it.uc3m.es, sarikaya@ieee.org X-Trac-Project: multimob Date: Wed, 23 Jun 2010 21:42:06 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/multimob/trac/ticket/1 Message-ID: <060.2869b4c1b678628291fa44bf6bd8a1dd@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cjbc@it.uc3m.es, sarikaya@ieee.org, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 23 Jun 2010 14:45:21 -0700 Cc: multimob@ietf.org Subject: [multimob] #1: Section 1 expired draft reference X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 21:42:03 -0000 #1: Section 1 expired draft reference ----------------------------------+----------------------------------------- Reporter: sarikaya@… | Owner: Carlos Jesús Bernardos Cano Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: pmipv6-base-solution | Version: 1.0 Severity: In WG Last Call | Keywords: ----------------------------------+----------------------------------------- [Behcet]See Section 1 Paragraph 1 Problem: idnits tools gives a Comment about an expired draft reference. Solution: dropping reference to deng-multimob-pmip6-requirement may solve the problem. -- Ticket URL: multimob From trac@tools.ietf.org Wed Jun 23 14:58:34 2010 Return-Path: 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 4D6B63A68B0 for ; Wed, 23 Jun 2010 14:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 MlguQY4UUD2n for ; Wed, 23 Jun 2010 14:58:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 899A23A6801 for ; Wed, 23 Jun 2010 14:58:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORXxv-0006EZ-3W; Wed, 23 Jun 2010 14:58:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cjbc@it.uc3m.es, sarikaya@ieee.org X-Trac-Project: multimob Date: Wed, 23 Jun 2010 21:58:39 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/multimob/trac/ticket/2 Message-ID: <060.5b42d116a278ffe043fec45c4cbdbb6c@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cjbc@it.uc3m.es, sarikaya@ieee.org, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: multimob@ietf.org Subject: [multimob] #2: Section 1 Par. 3 difficult to understand X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 21:58:34 -0000 #2: Section 1 Par. 3 difficult to understand ----------------------------------+----------------------------------------- Reporter: sarikaya@… | Owner: Carlos Jesús Bernardos Cano Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: pmipv6-base-solution | Version: 1.0 Severity: In WG Last Call | Keywords: ----------------------------------+----------------------------------------- [behcet] Bi-directional home tunneling, the minimal multicast support arranged by MIPv6, cannot be directly transferred to network-based management scenarios, since a mobility-unaware node will not initiate such a tunnel after movement. Consequently, even a minimal multicast listener support in PMIPv6 domains requires an explicit deployment of additional functions. Problem: what is "such a tunnel" referring to? I think you mean bi- directional home tunneling. BUT remember that in PMIPv6, it is not MN which establishes the bi-directional home tunneling with LMA, it is MAG. So when MN moves to a new MAG, this new MAG HAS TO establish the new tunnel if there was none before. What is the ISSUE? What does " an explicit deployment of additional functions" refer to? Which additional functions? Solution: Maybe remove this paragraph and add some text to the next paragraph stating that proxy based solution instead of bi-directional home tunneling type of solution like in MIPv6 has been opted for. -- Ticket URL: multimob From trac@tools.ietf.org Wed Jun 23 15:09:22 2010 Return-Path: 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 5C7F53A69CF for ; Wed, 23 Jun 2010 15:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 RzGpvjxHB6wq for ; Wed, 23 Jun 2010 15:09:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A83A03A67D1 for ; Wed, 23 Jun 2010 15:09:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORY8N-000796-N3; Wed, 23 Jun 2010 15:09:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cjbc@it.uc3m.es, behcetsarikaya@yahoo.com X-Trac-Project: multimob Date: Wed, 23 Jun 2010 22:09:27 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/multimob/trac/ticket/3 Message-ID: <067.1da05552a677b6389924d62dd6e2dbba@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cjbc@it.uc3m.es, behcetsarikaya@yahoo.com, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: multimob@ietf.org Subject: [multimob] #3: Section 3 editorial X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 22:09:22 -0000 #3: Section 3 editorial --------------------------------------+------------------------------------- Reporter: behcetsarikaya@… | Owner: Carlos Jesús Bernardos Cano Type: enhancement | Status: new Priority: minor | Milestone: Component: pmipv6-base-solution | Version: 1.0 Severity: In WG Last Call | Keywords: --------------------------------------+------------------------------------- [behcet] see Section 3 last paragraph Problem: Editorial clarification is needed. Solution: (see Appendix C for further considerations on this problem which is referred to as tunnel convergence problem). -- Ticket URL: multimob From trac@tools.ietf.org Wed Jun 23 15:13:56 2010 Return-Path: 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 04B5F3A69DC for ; Wed, 23 Jun 2010 15:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 EXAgGiBbABRa for ; Wed, 23 Jun 2010 15:13:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EAAC43A687E for ; Wed, 23 Jun 2010 15:13:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORYCp-0001Ai-A3; Wed, 23 Jun 2010 15:14:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: sarikaya@ieee.org X-Trac-Project: multimob Date: Wed, 23 Jun 2010 22:14:03 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/multimob/trac/ticket/4 Message-ID: <060.2ccbb64d592f133a5bc6dfc82cb76d0b@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: sarikaya@ieee.org, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: multimob@ietf.org Subject: [multimob] #4: Section 5.1 Destination address values needed X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 22:13:56 -0000 #4: Section 5.1 Destination address values needed ----------------------------------+----------------------------------------- Reporter: sarikaya@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: pmipv6-base-solution | Version: Severity: - | Keywords: ----------------------------------+----------------------------------------- [behcet] see Section 5.1 for more details Problem: While the source address is given as described in 3810, the destination address is a reference to RFC 3810. The destination address is NOT given. Solution: General Query: FF02::1 Other Queries: multicast address -- Ticket URL: multimob From trac@tools.ietf.org Wed Jun 23 15:18:26 2010 Return-Path: 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 87E923A6801 for ; Wed, 23 Jun 2010 15:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 PaTvR+qaZB-q for ; Wed, 23 Jun 2010 15:18:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BBBFB3A69A8 for ; Wed, 23 Jun 2010 15:18:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORYH9-0003Ap-Hy; Wed, 23 Jun 2010 15:18:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cjbc@it.uc3m.es, sarikaya@ieee.org X-Trac-Project: multimob Date: Wed, 23 Jun 2010 22:18:31 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/multimob/trac/ticket/5 Message-ID: <060.90f6269c0dfd0e76d5bdb5fb1e746859@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cjbc@it.uc3m.es, sarikaya@ieee.org, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: multimob@ietf.org Subject: [multimob] #5: Section 5.2 Destination address values needed X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 22:18:26 -0000 #5: Section 5.2 Destination address values needed ----------------------------------+----------------------------------------- Reporter: sarikaya@… | Owner: Carlos Jesús Bernardos Cano Type: defect | Status: new Priority: major | Milestone: Component: pmipv6-base-solution | Version: 1.0 Severity: In WG Last Call | Keywords: ----------------------------------+----------------------------------------- [behcet] see Section 5.2 for more details Problem: While the source address is given as described in 3810, the destination address is a reference to RFC 3810. The destination address is NOT given. Solution: FF02:0:0:0:0:0:0:16 Since we have MLDv2 explicitly specified in the charter the above value is sufficient. -- Ticket URL: multimob From trac@tools.ietf.org Wed Jun 23 15:50:37 2010 Return-Path: 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 2FEE03A6801 for ; Wed, 23 Jun 2010 15:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 uFLnu3rqQyxF for ; Wed, 23 Jun 2010 15:50:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4431F3A67B8 for ; Wed, 23 Jun 2010 15:50:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1ORYmH-0002iP-5U; Wed, 23 Jun 2010 15:50:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "multimob issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: cjbc@it.uc3m.es, sarikaya@ieee.org X-Trac-Project: multimob Date: Wed, 23 Jun 2010 22:50:41 -0000 X-URL: http://tools.ietf.org/multimob/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/multimob/trac/ticket/6 Message-ID: <060.29fbafd423e25301b08ba97965098756@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cjbc@it.uc3m.es, sarikaya@ieee.org, multimob@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: multimob@ietf.org Subject: [multimob] #6: Appendix C X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.9 List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 22:50:37 -0000 #6: Appendix C ----------------------------------+----------------------------------------- Reporter: sarikaya@… | Owner: Carlos Jesús Bernardos Cano Type: enhancement | Status: new Priority: minor | Milestone: Component: pmipv6-base-solution | Version: 1.0 Severity: In WG Last Call | Keywords: ----------------------------------+----------------------------------------- [behcet] see Appendix C Problem: This annex only considers one possible alternative approach and does not cover the others. Solution: Remove Scenario B from the discussion by considering only the scenario where multicast is provided by combined unicast/multicast LMAs as described in this document. This annex should only show how serious the tunnel convergence problem is to the reader in terms of the number of duplicate packets and bandwidth lost at LMA-MAG tunnel due to the duplicate packets and not attempt to evaluate some other things. -- Ticket URL: multimob From jari.arkko@piuha.net Thu Jun 24 02:52:46 2010 Return-Path: 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 112233A6920 for ; Thu, 24 Jun 2010 02:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-1.561, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 X7V9+iwLQoLY for ; Thu, 24 Jun 2010 02:52:45 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A531D3A67A4 for ; Thu, 24 Jun 2010 02:52:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5D13D2CCCF; Thu, 24 Jun 2010 12:52:52 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjgGvX-exTHi; Thu, 24 Jun 2010 12:52:51 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8B6A22CC62; Thu, 24 Jun 2010 12:52:51 +0300 (EEST) Message-ID: <4C232AF3.7030707@piuha.net> Date: Thu, 24 Jun 2010 12:52:51 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [multimob] review of draft-ietf-multimob-pmipv6-base-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: , X-List-Received-Date: Thu, 24 Jun 2010 09:52:46 -0000 I have read this draft. Here are my comments.

Overall, I think the spec is in good shape and should move forward. A couple of relatively minor issues and questions below, however:

   With these entities in place, the mobile node loses transparent end-
   to-end connectivity to the static Internet, and in the particular
   case of multicast communication, group membership management as
   signaled by the Multicast Listener Discovery protocol (MLD)
   [RFC3810], [RFC2710] requires dedicated treatment at the network
   side, see [I-D.deng-multimob-pmip6-requirement].

The loss of transparenet e2e connectivity is a strong claim. What basis is there for making this statement? Its not like there is a NAT on the path, or if the mobile node would be prevented from sending some packets. I do agree though that group membership management requires care. Also, perhaps the reference to the draft can be moved to an acknowledgment section as prior work, since you do describe the issues yourself later in the document.


It therefore needs to
   implement an instance of the MLD proxy function [RFC4605] for each
   upstream tunnel interface that has been established with an LMA.
4.4.  IPv4 Support

Question: Are there any special things that you have to take care of for overlapping IPv4 address space situations and GRE-keyed tunnels?

7.  A Note on Explicit Tracking


   IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with
   explicit tracking, which allows routers to monitor each multicast
   receiver.  This mechanism is not standardized yet, but widely
   implemented by vendors as it supports faster leave latencies and
   reduced signaling.

   Enabling explicit tracking on downstream interfaces of the LMA and
   MAG would track a single MAG and MN respectively per interface.  It
   may be used to preserve bandwidth on the MAG-MN link.

This does not tell me what explicit tracking is. Is there any reference that could be used here? If there is no clear description of the what explicit tracking is, perhaps this part should not be in the document.

   At the MAG, MLD queries and multicast data will arrive on the
   (tunnel) interface that is assigned to a group of access links as
   identified by its Binding Update List (cf., section 6 of [RFC5213]).
Does this specification handle the case of multicast traffic originating from the mobile host? If not, please state so.

Jari

From schmidt@informatik.haw-hamburg.de Thu Jun 24 03:30:20 2010 Return-Path: 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 116F13A67ED for ; Thu, 24 Jun 2010 03:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.508 X-Spam-Level: X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, 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 SmOJRfm09lzz for ; Thu, 24 Jun 2010 03:30:18 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 9DEEE3A67C0 for ; Thu, 24 Jun 2010 03:30:14 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from g231226087.adsl.alicedsl.de ([92.231.226.87] helo=[192.168.178.121]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ORjhN-0005xP-Jb; Thu, 24 Jun 2010 12:30:21 +0200 Message-ID: <4C2333B9.5090405@informatik.haw-hamburg.de> Date: Thu, 24 Jun 2010 12:30:17 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko References: <4C232AF3.7030707@piuha.net> In-Reply-To: <4C232AF3.7030707@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-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: , X-List-Received-Date: Thu, 24 Jun 2010 10:30:20 -0000 Hi Jari, thanks for reviewing - please see answers inline: On 24.06.2010 11:52, Jari Arkko wrote: > I have read this draft. Here are my comments. > > Overall, I think the spec is in good shape and should move forward. A > couple of relatively minor issues and questions below, however: > >> With these entities in place, the mobile node loses transparent end- >> to-end connectivity to the static Internet, and in the particular >> case of multicast communication, group membership management as >> signaled by the Multicast Listener Discovery protocol (MLD) >> [RFC3810 ], [RFC2710 ] requires dedicated treatment at the network >> side, see [I-D.deng-multimob-pmip6-requirement ]. >> > > The loss of transparenet e2e connectivity is a strong claim. What basis > is there for making this statement? Its not like there is a NAT on the > path, or if the mobile node would be prevented from sending some > packets. I do agree though that group membership management requires > care. Also, perhaps the reference to the draft can be moved to an > acknowledgment section as prior work, since you do describe the issues > yourself later in the document. > The "loss of transparent e2e connectivity"-argument is referring to the setup that the MAG (tunnel entry) introduces a routing hop in situations, were the LMA architecturally acts as the next hop (or designated) router for the MN. This plays the particular role mentioned in MLD signaling (but may be relevant in other situations). Suggestion for clarification/improvement: "With these entities in place, the mobile node loses transparent end- to-end connectivity to the static Internet in the sense that the MAG introduces a routing hop also in situations, were the LMA architecturally acts as the next hop (or designated) router for the MN. In the particular case of multicast communication, group membership ... " As for the draft reference: This was only to indicate that some requirements-work has been done. We will move it to the acknowledgment. > >> It therefore needs to >> implement an instance of the MLD proxy function [RFC4605 ] for each >> upstream tunnel interface that has been established with an LMA. >> >> >> 4.4. IPv4 Support >> > > Question: Are there any special things that you have to take care of for > overlapping IPv4 address space situations and GRE-keyed tunnels? > Good point: we will have to think about this and will be back on the question later. >> >> 7. A Note on Explicit Tracking >> >> >> >> IGMPv3/MLDv2 [RFC3376 ], [RFC3810 ] may operate in combination with >> explicit tracking, which allows routers to monitor each multicast >> receiver. This mechanism is not standardized yet, but widely >> implemented by vendors as it supports faster leave latencies and >> reduced signaling. >> >> Enabling explicit tracking on downstream interfaces of the LMA and >> MAG would track a single MAG and MN respectively per interface. It >> may be used to preserve bandwidth on the MAG-MN link. >> > > This does not tell me what explicit tracking is. Is there any reference > that could be used here? If there is no clear description of the what > explicit tracking is, perhaps this part should not be in the document. > Explicit tracking is discussed in "A.2. Host Suppression" of RFC 3810 (MLDv2). However, it is not a standardized procedure and I agree that the term is somewhat colloquial. We will review the exact wording and propose a more concise formulation in the following mail. The technique of explicit multicast state tracking at routers facilitates a fast reaction of routers on state changes (without querying), which is useful (not only) in mobile regimes and actually used a lot in deployed systems. This is why we felt it is important to mention. >> At the MAG, MLD queries and multicast data will arrive on the >> (tunnel) interface that is assigned to a group of access links as >> identified by its Binding Update List (cf.,section 6 of [RFC5213] ). >> > Does this specification handle the case of multicast traffic originating > from the mobile host? If not, please state so. No, it doesn't according to the current Multimob charter. We will add the straight-forward statement in the abstract and the introduction. Thanks, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From asaeda@sfc.wide.ad.jp Thu Jun 24 16:51:06 2010 Return-Path: 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 54CE328C0E7; Thu, 24 Jun 2010 16:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.919 X-Spam-Level: **** X-Spam-Status: No, score=4.919 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 5cDTl4B6j90w; Thu, 24 Jun 2010 16:51:05 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 44B8828C0FB; Thu, 24 Jun 2010 16:51:03 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id AE5DE278103; Fri, 25 Jun 2010 08:51:04 +0900 (JST) Date: Fri, 25 Jun 2010 08:51:04 +0900 (JST) Message-Id: <20100625.085104.166774516.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf-action@ietf.org Subject: [multimob] test mail 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: , X-List-Received-Date: Thu, 24 Jun 2010 23:51:06 -0000 This is a test mail as my mails have been always discarded. Please ignore if you see this (except administrators:). -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Thu Jun 24 18:22:55 2010 Return-Path: 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 1D0B73A67B8 for ; Thu, 24 Jun 2010 18:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.966 X-Spam-Level: **** X-Spam-Status: No, score=4.966 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, 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 5WMzS-0kv5sL for ; Thu, 24 Jun 2010 18:22:54 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id 4E9933A677D for ; Thu, 24 Jun 2010 18:22:54 -0700 (PDT) Received: from localhost (KHP222006121211.ppp-bb.dion.ne.jp [222.6.121.211]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DF07427807A; Fri, 25 Jun 2010 10:22:57 +0900 (JST) Date: Fri, 25 Jun 2010 10:22:57 +0900 (JST) Message-Id: <20100625.102257.123411473.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4C2333B9.5090405@informatik.haw-hamburg.de> References: <4C232AF3.7030707@piuha.net> <4C2333B9.5090405@informatik.haw-hamburg.de> X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: multimob@ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-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: , X-List-Received-Date: Fri, 25 Jun 2010 01:22:55 -0000 Hi Thomas and Jari, >> This does not tell me what explicit tracking is. Is there any >> reference >> that could be used here? If there is no clear description of the what >> explicit tracking is, perhaps this part should not be in the document. > > Explicit tracking is discussed in "A.2. Host Suppression" of RFC 3810 > (MLDv2). However, it is not a standardized procedure and I agree that > the term is somewhat colloquial. We will review the exact wording and > propose a more concise formulation in the following mail. RFC3376 also mentions "track per-host membership status" and "explicit membership tracking". The word of "explicit tracking function" has been specified in my IGMP/MLD optimization draft and its primary draft igmp-mld-mobility-extensions-01 published in July 14, 2008. It is not a good idea to use different words meaning the same function. Moreover, this PMIP base solution draft does not have a mission to define IGMP/MLD related function or wording. Therefore I recommend to keep the word as is and refer the RFC or my draft. Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Fri Jun 25 07:11:38 2010 Return-Path: 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 3ECEA3A693A for ; Fri, 25 Jun 2010 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 s9lpBQpqRGks for ; Fri, 25 Jun 2010 07:11:34 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id DD3A63A689F for ; Fri, 25 Jun 2010 07:11:33 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from [141.45.120.245] by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OS9d6-0001fw-Vk; Fri, 25 Jun 2010 16:11:41 +0200 Message-ID: <4C24B918.7080400@informatik.haw-hamburg.de> Date: Fri, 25 Jun 2010 16:11:36 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jari Arkko References: <4C232AF3.7030707@piuha.net> In-Reply-To: <4C232AF3.7030707@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Cc: multimob@ietf.org, draft-ietf-multimob-pmipv6-base-solution@tools.ietf.org Subject: Re: [multimob] review of draft-ietf-multimob-pmipv6-base-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: , X-List-Received-Date: Fri, 25 Jun 2010 14:11:38 -0000 Hi Jari, now we are back on the remaining open issues: On 24.06.2010 11:52, Jari Arkko wrote: >> >> 4.4. IPv4 Support >> > > Question: Are there any special things that you have to take care of for > overlapping IPv4 address space situations and GRE-keyed tunnels? > You are referring to RFC5845 here and the scenario in which overlapping private address spaces of different operators can be hosted in a PMIP domain by using GRE encapsulation with key identification. This scenario implies that unicast communication in the MAG-LMA tunnel can be individually identified per MN by the GRE keys. This looks like an issue for multicast, but IMHO is not for the following reasons: MLD/IGMP signaling between MNs and the MAG is on point-to-point links (identical to unicast). Aggregated MLD/IGMP signaling between the MAG proxy instance and the LMA is link-local between the routers and independent of an individual MN. So the MAG-proxy and the LMA would not use GRE key identifiers, but plain GRE encapsulation to exchange MLD queries and reports. Similarly, multicast traffic sent from LMA to MAG is a router-to-router forwarding according to the MFIB of the LMA, independent of MN unicast addresses, while the MAG proxy instance distributes multicast data down the point-to-point links (interfaces) according to its MFIB, independent of MN's IP addresses. The question remains in a multi-operator scenario, where the LMA pulls multicast traffic from, i.e., how multicast traffic is routed to the LMA. This could be Operator-A, Operator-B or a third party. However, this backbone routing in general is out of scope of the document, and most likely more a matter of contracts. We will add this explanation and the reference to RFC5845 to the draft. >> >> 7. A Note on Explicit Tracking >> >> >> >> IGMPv3/MLDv2 [RFC3376 ], [RFC3810 ] may operate in combination with >> explicit tracking, which allows routers to monitor each multicast >> receiver. This mechanism is not standardized yet, but widely >> implemented by vendors as it supports faster leave latencies and >> reduced signaling. >> >> Enabling explicit tracking on downstream interfaces of the LMA and >> MAG would track a single MAG and MN respectively per interface. It >> may be used to preserve bandwidth on the MAG-MN link. >> > > This does not tell me what explicit tracking is. Is there any reference > that could be used here? If there is no clear description of the what > explicit tracking is, perhaps this part should not be in the document. > Also following the comment of Hitoshi, we would suggest to just add the references to RFC3376 and RFC3810. Does this clarify / resolve the issues? Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From Dirk.von-Hugo@telekom.de Mon Jun 28 04:49:29 2010 Return-Path: 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 B0C9D3A67B2 for ; Mon, 28 Jun 2010 04:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i42jTalUw-EL for ; Mon, 28 Jun 2010 04:49:29 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 3480E3A6782 for ; Mon, 28 Jun 2010 04:49:28 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 28 Jun 2010 13:49:30 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 13:49:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 13:49:30 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802518FE5@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <060.2ccbb64d592f133a5bc6dfc82cb76d0b@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] #4: Section 5.1 Destination address values needed Thread-Index: AcsTIWdafelhXCMyTOmdtkU5iWsTpgDlTrSA References: <060.2ccbb64d592f133a5bc6dfc82cb76d0b@tools.ietf.org> From: To: , X-OriginalArrivalTime: 28 Jun 2010 11:49:30.0757 (UTC) FILETIME=[F81B8350:01CB16B7] Cc: multimob@ietf.org Subject: Re: [multimob] #4: Section 5.1 Destination address values needed 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: , X-List-Received-Date: Mon, 28 Jun 2010 11:49:29 -0000 Dear all, Additionally to naming the IPv6 address in the table as FF02::1 I would = propose to also give the meaning according to RFC 3810, i.e. 'link-scope = all-nodes' or 'link scope all-nodes multicast address' for ease of = understanding. JM2C Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von multimob issue tracker Gesendet: Donnerstag, 24. Juni 2010 00:14 An: sarikaya@ieee.org Cc: multimob@ietf.org Betreff: [multimob] #4: Section 5.1 Destination address values needed #4: Section 5.1 Destination address values needed ----------------------------------+--------------------------------------= --- Reporter: sarikaya@... | Owner: =20 Type: defect | Status: new Priority: major | Milestone: =20 Component: pmipv6-base-solution | Version: =20 Severity: - | Keywords: =20 ----------------------------------+--------------------------------------= --- [behcet] see Section 5.1 for more details Problem: While the source address is given as described in 3810, the destination address is a reference to RFC 3810. The destination address is NOT = given. Solution: General Query: FF02::1 Other Queries: multicast address --=20 Ticket URL: multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From Dirk.von-Hugo@telekom.de Mon Jun 28 04:58:12 2010 Return-Path: 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 058933A6A26 for ; Mon, 28 Jun 2010 04:58:12 -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_DE=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 Y1x4kBpLhvTB for ; Mon, 28 Jun 2010 04:58:11 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id A480E3A6A21 for ; Mon, 28 Jun 2010 04:58:09 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 28 Jun 2010 13:58:17 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 13:58:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2010 13:58:16 +0200 Message-ID: <643B0A1D1A13AB498304E0BBC802784802518FF6@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <060.90f6269c0dfd0e76d5bdb5fb1e746859@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multimob] #5: Section 5.2 Destination address values needed Thread-Index: AcsTIglS3uLUuv+2QvueiwawePdEkwDlfXbg References: <060.90f6269c0dfd0e76d5bdb5fb1e746859@tools.ietf.org> From: To: , , X-OriginalArrivalTime: 28 Jun 2010 11:58:17.0523 (UTC) FILETIME=[3215A030:01CB16B9] Cc: multimob@ietf.org Subject: Re: [multimob] #5: Section 5.2 Destination address values needed 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: , X-List-Received-Date: Mon, 28 Jun 2010 11:58:12 -0000 Dear all, Accordingly to issue #4 my proposal here is to add the explanation for = FF02:0:0:0:0:0:0:16, i.e. 'all MLDv2-capable routers' in the table in = section 5.2. I think the other and all of the minor issues have all been = satisfactorily addressed by the authors meanwhile - so with the proposed = updates I am fine with the solution draft and herewith state my = happiness ;-) ... According to WGLC2 issued last week. Best regards Dirk=20 -----Urspr=FCngliche Nachricht----- Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im = Auftrag von multimob issue tracker Gesendet: Donnerstag, 24. Juni 2010 00:19 An: cjbc@it.uc3m.es; sarikaya@ieee.org Cc: multimob@ietf.org Betreff: [multimob] #5: Section 5.2 Destination address values needed #5: Section 5.2 Destination address values needed ----------------------------------+--------------------------------------= --- Reporter: sarikaya@... | Owner: Carlos Jes=FAs = Bernardos Cano =20 Type: defect | Status: new = =20 Priority: major | Milestone: = =20 Component: pmipv6-base-solution | Version: 1.0 = =20 Severity: In WG Last Call | Keywords: = =20 ----------------------------------+--------------------------------------= --- [behcet] see Section 5.2 for more details Problem: While the source address is given as described in 3810, the destination address is a reference to RFC 3810. The destination address is NOT = given. Solution: FF02:0:0:0:0:0:0:16 Since we have MLDv2 explicitly specified in the charter the above value = is sufficient. --=20 Ticket URL: multimob _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob From schmidt@informatik.haw-hamburg.de Mon Jun 28 05:04:05 2010 Return-Path: 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 87AE23A68EA for ; Mon, 28 Jun 2010 05:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, 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 y80LhX7JNvvi for ; Mon, 28 Jun 2010 05:04:04 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by core3.amsl.com (Postfix) with ESMTP id 3C2853A67EB for ; Mon, 28 Jun 2010 05:04:03 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178058243.adsl.alicedsl.de ([85.178.58.243] helo=[192.168.178.121]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OTD4O-000AnP-QU for multimob@ietf.org; Mon, 28 Jun 2010 14:04:13 +0200 Message-ID: <4C288FBC.4030904@informatik.haw-hamburg.de> Date: Mon, 28 Jun 2010 14:04:12 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: multimob@ietf.org References: <060.90f6269c0dfd0e76d5bdb5fb1e746859@tools.ietf.org> <643B0A1D1A13AB498304E0BBC802784802518FF6@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <643B0A1D1A13AB498304E0BBC802784802518FF6@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) Subject: Re: [multimob] #5: Section 5.2 Destination address values needed 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: , X-List-Received-Date: Mon, 28 Jun 2010 12:04:05 -0000 Hi Dirk, thanks for all the flowers :-) According to your proposal on the MLD-Addressing: As has been discussed recently, this is a little intricate. In particular, the draft covers MLDv1+2 (and IGMPv2+3), as this not only makes sense, but also was requested and discussed earlier on the list. I'll be back on this later. Best wishes, Thomas On 28.06.2010 13:58, Dirk.von-Hugo@telekom.de wrote: > Dear all, > Accordingly to issue #4 my proposal here is to add the explanation for FF02:0:0:0:0:0:0:16, i.e. 'all MLDv2-capable routers' in the table in section 5.2. > I think the other and all of the minor issues have all been satisfactorily addressed by the authors meanwhile - so with the proposed updates I am fine with the solution draft and herewith state my happiness ;-) ... According to WGLC2 issued last week. > > Best regards > Dirk > > -----Ursprüngliche Nachricht----- > Von: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] Im Auftrag von multimob issue tracker > Gesendet: Donnerstag, 24. Juni 2010 00:19 > An: cjbc@it.uc3m.es; sarikaya@ieee.org > Cc: multimob@ietf.org > Betreff: [multimob] #5: Section 5.2 Destination address values needed > > #5: Section 5.2 Destination address values needed > ----------------------------------+----------------------------------------- > Reporter: sarikaya@... | Owner: Carlos Jesús Bernardos Cano > Type: defect | Status: new > Priority: major | Milestone: > Component: pmipv6-base-solution | Version: 1.0 > Severity: In WG Last Call | Keywords: > ----------------------------------+----------------------------------------- > [behcet] see Section 5.2 for more details > > Problem: > While the source address is given as described in 3810, the destination > address is a reference to RFC 3810. The destination address is NOT given. > > Solution: > FF02:0:0:0:0:0:0:16 > Since we have MLDv2 explicitly specified in the charter the above value is > sufficient. > -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From luisc@it.uc3m.es Wed Jun 30 06:09:47 2010 Return-Path: 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 36B873A6A58 for ; Wed, 30 Jun 2010 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 lILLzhl3NLBB for ; Wed, 30 Jun 2010 06:09:46 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 387F83A6909 for ; Wed, 30 Jun 2010 06:09:46 -0700 (PDT) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp01.uc3m.es (Postfix) with ESMTP id 81C8FBAE1FB; Wed, 30 Jun 2010 15:09:53 +0200 (CEST) Received: from 85.62.13.196.static.abi.uni2.es (85.62.13.196.static.abi.uni2.es [85.62.13.196]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Wed, 30 Jun 2010 15:09:51 +0200 Message-ID: <20100630150951.7kh4n8dw0ckgggs0@webcartero01.uc3m.es> Date: Wed, 30 Jun 2010 15:09:51 +0200 From: "Luis M. Contreras" To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17476.007 Subject: [multimob] Fwd: New Version Notification for draft-contreras-multimob-rams-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: , X-List-Received-Date: Wed, 30 Jun 2010 13:09:47 -0000 Dear all, a new draft proposing a PMIPv6 protocol extension for rapid acquisition of the MN multicast subscription after handover has been submitted as contribution for Multimob working group. The draft can be found following this link: http://www.ietf.org/id/draft-contreras-multimob-rams-00.txt Any comments are very welcomed. Best regards, Luis ----- Mensaje reenviado de idsubmission@ietf.org ----- Fecha: Wed, 30 Jun 2010 05:57:18 -0700 (PDT) De: IETF I-D Submission Tool Responder-A: IETF I-D Submission Tool Asunto: New Version Notification for draft-contreras-multimob-rams-00 Para: luisc@it.uc3m.es A new version of I-D, draft-contreras-multimob-rams-00.txt has been successfully submitted by Luis Contreras and posted to the IETF repository. Filename: draft-contreras-multimob-rams Revision: 00 Title: Rapid acquisition of the MN multicast subscription after handover Creation_date: 2010-06-29 WG ID: Independent Submission Number_of_pages: 31 Abstract: A new proposal is presented for speeding up the acquisition by the MAG of the MN's active multicast subscription information, in order to accelerate the multicast delivery to the MN during handover. To do that, an extension of the current PMIPv6 protocol is required. The solution described in this memo is not only applicable to the base multicast solution, but also it can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, it is also independent of the role played by the MAG within the multicast metwork (either acting as MLD proxy or multicast router). The IETF Secretariat. ----- Terminar mensaje reenviado ----- From asaeda@sfc.wide.ad.jp Wed Jun 30 20:35:07 2010 Return-Path: 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 7ED243A67D3 for ; Wed, 30 Jun 2010 20:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.949 X-Spam-Level: ** X-Spam-Status: No, score=2.949 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, 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 c+8ZFXAr40bT for ; Wed, 30 Jun 2010 20:35:05 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) by core3.amsl.com (Postfix) with ESMTP id BA5E03A657C for ; Wed, 30 Jun 2010 20:35:03 -0700 (PDT) Received: from localhost (dhcp-143-184.sfc.wide.ad.jp [203.178.143.184]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 855CE278099 for ; Thu, 1 Jul 2010 12:35:08 +0900 (JST) Date: Thu, 01 Jul 2010 12:35:05 +0900 (JST) Message-Id: <20100701.123505.142878551.asaeda@sfc.wide.ad.jp> To: multimob@ietf.org From: Hitoshi Asaeda In-Reply-To: <20100630150951.7kh4n8dw0ckgggs0@webcartero01.uc3m.es> References: <20100630150951.7kh4n8dw0ckgggs0@webcartero01.uc3m.es> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Fwd: New Version Notification for draft-contreras-multimob-rams-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: , X-List-Received-Date: Thu, 01 Jul 2010 03:35:07 -0000 Hi Luis, > a new draft proposing a PMIPv6 protocol extension for rapid > acquisition of the MN multicast subscription after handover has been > submitted as contribution for Multimob working group. > > The draft can be found following this link: > http://www.ietf.org/id/draft-contreras-multimob-rams-00.txt I've not looked at this draft, but just FYI. The following draft may be relevant to your draft. http://tools.ietf.org/html/draft-xia-avt-proxy-rapid-acquisition-01 Mutual reference may achieve the goal. Regards, -- Hitoshi Asaeda