From behcetsarikaya@yahoo.com Thu Jun 2 09:31:02 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836D0E07E9 for ; Thu, 2 Jun 2011 09:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exn7Z13KLf3m for ; Thu, 2 Jun 2011 09:31:01 -0700 (PDT) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id D03DDE06CC for ; Thu, 2 Jun 2011 09:31:01 -0700 (PDT) Received: from [98.139.91.68] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 16:31:01 -0000 Received: from [98.139.91.15] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 16:31:01 -0000 Received: from [127.0.0.1] by omp1015.mail.sp2.yahoo.com with NNFMP; 02 Jun 2011 16:31:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 806096.32543.bm@omp1015.mail.sp2.yahoo.com Received: (qmail 74815 invoked by uid 60001); 2 Jun 2011 16:31:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307032261; bh=cjHItTHi2UzFtDDs8pfDeMCcMyDtbEsEnSEqQjcn6Dg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=dNonRo8oOn514JwVUmPPZM8p/V2QXrE437xqikmtsm0fae/+TpLCx/VSR2c/ViJZFRv3DD3lV2qaGXM1iCu3IBWI4O6qkuwuqnFOzx/wQa6hgmHKDgXO6GWWVaOHtsLc1KItNqHZAWW1ufRHRU7wDgG85WAmvFHqDklFwCBGJuU= 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=Hr5JcrGmeYjOZRzeGOIIDfz6y2vAgds4jzw/3R8/c5SuRPBCF3rUKLHp13BI/gX5Ogr5qnSZGyXyn4tF1Vwrd8vARe1FhieH9DvVVVFqIXrfxFbifqsyp+3mGb5+mAhbpzSDsZid8g8o8BEzqir0WL7PVZfVFEkTXfOAwMtN7cY=; Message-ID: <8054.73450.qm@web111406.mail.gq1.yahoo.com> X-YMail-OSG: bXEL7EYVM1kOalxQgB0P7Is6uJSUcVOha8Xd5RtvNHgQ9.X k_nxzrMepqoNVqYduO9XVqt4hsOPCHbYAGzNX4phZQUsIJTBSJPmBEvJsCEi UAQEA60.ROsIbI9BkSOFy_VjHIDqy7M4Wteu4nhHGLHuezsaOaGe7xt.mSaC H04sH4arAIHyWrX7FVasLq3HGvl4e0VkR6Gul5GL.7KRrHMMd39qyN3nPcYH 8H0SnhDQGfJdgFn9fGzh6yd_Zb80Qp_OsuhdAegImZ5_bJRzoAgMnZGfuApP YycSXCy9dGR4eP9iSqoHzjXeUhleyD2mcIYQAuwar_5WdAjPmvPdsz5XIaFs TlsGJs0mRRv9fdBM9D0yx4UqQt_R4_8fhigS7UogWXNQaTFhDWewbEQtliM_ u18LLp0f.85bwug-- Received: from [206.16.17.212] by web111406.mail.gq1.yahoo.com via HTTP; Thu, 02 Jun 2011 09:31:00 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 Date: Thu, 2 Jun 2011 09:31:00 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Session in IETF-81 X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2011 16:31:02 -0000 Folks, We need to come up with a draft agenda by June 10. I expect that Quebec City session will be more on handover related drafts. Tunnel convergence drafts were discussed in depth in Prague. Based on this, please send your session requests to the chairs. Regards, Behcet From I.Romdhani@napier.ac.uk Fri Jun 3 01:49:36 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF0EE065D for ; Fri, 3 Jun 2011 01:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdwyTqjR5mur for ; Fri, 3 Jun 2011 01:49:34 -0700 (PDT) Received: from DB3EHSOBE004.bigfish.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 30B66E0696 for ; Fri, 3 Jun 2011 01:49:33 -0700 (PDT) Received: from mail28-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 3 Jun 2011 08:49:32 +0000 Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3-R.bigfish.com (Postfix) with ESMTP id C5C3292826A; Fri, 3 Jun 2011 08:49:32 +0000 (UTC) X-SpamScore: -59 X-BigFish: VPS-59(zzbb2dK9371M1be0L62a3K1447R542M1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:146.176.222.89; KIP:(null); UIP:(null); IPVD:NLI; H:crl-hub-1.napier-mail.napier.ac.uk; RD:crl-hub-1.napier-mail.napier.ac.uk; EFVD:NLI Received-SPF: pass (mail28-db3: domain of napier.ac.uk designates 146.176.222.89 as permitted sender) client-ip=146.176.222.89; envelope-from=I.Romdhani@napier.ac.uk; helo=crl-hub-1.napier-mail.napier.ac.uk ; napier.ac.uk ; Received: from mail28-db3 (localhost.localdomain [127.0.0.1]) by mail28-db3 (MessageSwitch) id 1307090972415501_27828; Fri, 3 Jun 2011 08:49:32 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.246]) by mail28-db3.bigfish.com (Postfix) with ESMTP id 628391950051; Fri, 3 Jun 2011 08:49:32 +0000 (UTC) Received: from crl-hub-1.napier-mail.napier.ac.uk (146.176.222.89) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 3 Jun 2011 08:49:26 +0000 Received: from E2K7MBX.napier-mail.napier.ac.uk ([146.176.250.56]) by crl-hub-1.napier-mail.napier.ac.uk ([146.176.222.89]) with mapi; Fri, 3 Jun 2011 09:49:25 +0100 From: "Romdhani, Imed" To: Qin Wu , Stig Venaas , "multimob@ietf.org" Date: Fri, 3 Jun 2011 09:49:24 +0100 Thread-Topic: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document Thread-Index: AcwgFB1fLdgy+3yTQGigbSEJB5ZgOABteU+A Message-ID: <78F1C759D89E1C44A6DD4C06B9A4B270C398E2E971@E2K7MBX.napier-mail.napier.ac.uk> References: <4DC2FFA1.3040103@venaas.com> <4DDEA66C.2080107@venaas.com> <78F1C759D89E1C44A6DD4C06B9A4B270C398AFB8B5@E2K7MBX.napier-mail.napier.ac.uk> <014501cc2014$729ae3d0$46298a0a@china.huawei.com> In-Reply-To: <014501cc2014$729ae3d0$46298a0a@china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: napier.ac.uk Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 08:49:36 -0000 Dear Qin, Dear Folks, Thanks for these clarifications. To answer your question about the case whe= n a mobility agent is an IGMP/MLD Querier, the latest Mobile IPv6 RFC for e= xample (rfc3775bis-13, Section 10.4.3) highlights the necessity that the Ho= me Agent implement a sort of "per-tunnel behaviour" for multicast membershi= p control messages. This standard stated that "to avoid ambiguity on the ho= me agent, due to mobile nodes which may choose identical link-local source = addresses for their MLD function, it is necessary for the home agent to ide= ntify which mobile node was actually the issuer of a particular MLD message= . This may be accomplished by noting which tunnel such an MLD arrived by, = which IPsec SA was used, or by other distinguishing means". The implication= of that means that the tuning mechanism that we (Multimob) are proposing n= eeds to be adapted or adjusted to each mobile node specific needs. I am in= favour of a windowing style management where the timers can be increased o= r decreased gradually and in an automated and intelligent way of possible. = We can imitate the TCP windowing approach. For the unsolicited report, you are right. Mobile nodes can send their Repo= rts whenever they want independently of the subscription method (home or re= mote). In previous MIP standards, it was recommended that mobile nodes need= to wait first the reception of IGMP/MLD query on the bi-directional tunnel= before sending back their reports. For security raison, I think we cannot = avoid the initial step of validating the CoA if the remote subscription is = used. What optimal subscription method a mobile node should use depends on= many factors: availability of multicast service, access rights, scope boun= daries, QoS performance, etc. If the home subscription is used, the Querier= needs to speed up sending Query messages to mobile nodes to compensate the= transfer delay. This may be also applicable in the remote subscription sce= nario, but any timer manipulations (in case where the HA is a Querier or IG= MP/MLD forwarder for MNs) has be cautious! The behaviour of a mobile device= may be different also in delaying his report messages depending on its awa= reness of which subscription method is used and the proximity of the IGMP/M= LD Querier. = Finally, it is worth clarifying the case where the Querier is not a router = (case of IGMP/MLD Proxy for example). This will give us different IGMP/MLD = tuning scenarios: simple router; router with mobility agent function: MIP a= ccess router, HA, Mobility Anchor Point; and IGMP/MLD proxy. Again, I iterate my support for the adoption of this draft. Kind regards, Imed -----Original Message----- From: Qin Wu [mailto:sunseawq@huawei.com] = Sent: 01 June 2011 05:29 To: Romdhani, Imed; Stig Venaas; multimob@ietf.org Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimiza= tion-05 as a wg document Hi, Imed: Thank for your feedback, please see my reply inline. Regards! -Qin ----- Original Message ----- = From: "Romdhani, Imed" To: "Stig Venaas" ; Sent: Wednesday, June 01, 2011 12:50 AM Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimiza= tion-05 as a wg document > Dear all, > = > I am sorry for not commenting earlier on this draft. I would like to shar= e with all folks some comments that I have already sent to the authors. > = > I endorse the proposal and I do support it. However, I have some comments= on the draft. Overall, there is still a need to clarify and to distinguish= between two aspects in the operation of IGMP/MLD. A clear distinction betw= een Router Operation and Host Operation should be discussed especially when= it comes to tuning decision either to speed up or to slow down control sig= nalling messages. [Qin]: I agree it is more valuable to discuss how IGMP/tuning works in mobi= lity usage scenario rather than limited tuning mechanism to the pure wirele= ss cases. > Another point that the authors have probably "missed" to discuss is the c= ase where a Mobility Agent (Home Agent, Proxy or Anchor Point) is a Querier= . In this case, the agent has to run multiple instances of the IGMP/MLD pro= cesses on physical network interfaces and on tunnel interfaces. The behavio= ur of IGMP/MLD should be naturally different as the awareness level of the = multicast membership is different. [Qin]: You are talking about how to differentiate between remote subscripti= on case and home subscription case? = As I said, I agree to discuss how IGMP/MLD tuning is used in mobility scena= rio. However I am not sure what's the difference of the behavior of IGMP/MLD in= two different cases mentioned above? BTW: what kind of agent you are talking about process the IGMP/MLD message?= I suspect the agent is not mobility agent. In addition, the processes are not independent as one may affect the other= . Fixed members may affect mobile devices that are away due to their join/l= eave activities. = [Qin]: How, can you clarify it more? > As the values of the different timers are concerned, I think there is no = need to fix them. Authors have justified their choice based on analysis tha= t they have done, but I think there should be a sort of variation (range th= at can be enlarged or shortened) depending on different circumstances and t= he layer 2 technology used. [Qin]: Agree. It is reasonable to allow parameters to be tuned vary from di= fferent circumstances. > Having a track record of mobile members may be easy to detect and maintai= n if the Home Agent is a Querier. [Qin]: Agree since home agent or other agent can maintain the record of eac= h mobile members in the mobility scenario. In other cases, I don't see who we can distinguish the origin of an IGMP/M= LD report message (i.e. coming from a mobile or stationary device). Routers= are connected in general to Wireless Domain Systems or Access Points and t= hey are not directly connected to mobile devices (design assumption and man= agement issue). [Qin]: Why should we need to distinguish whther IGMP/MLD report message is = sent from mobile device or a fixed device? > Finally, a mobile device may need to speed up sending his IGMP/MLD report= . As far as I know, in Mobile IP specification, a mobile device needs to wa= it first the reception of an IGMP/MLD query before being eligible to send a= report (through the bidirectional tunnel), probably this is an implicit pa= rt of the Return Routability procedure (CoA needs to be validated before us= e). [Qin]:As regarding to whether IGMP/MLD query is needed each time, I am afai= d that I am not tending to agree. In some case, we need solicited = membership report, in some case, we use unsolicited membersip report. e.g.= , the first subscriber joins a multicast group, = or the last subscriber leaves a multicast group. > Hope my comments help to improve the draft. > = > Kind Regards, > Imed > --------------------------------------------------- > Imed Romdhani, PhD > IEEE Member, FHEA = > Lecturer in Networking > Room C 64 > Edinburgh Napier University > School of Computing > 10 Colinton Road > Edinburgh, EH10 5DT > UK > E-Mail: I.Romdhani@napier.ac.uk > Home Page: http://www.dcs.napier.ac.uk/~cs244/ > Telephone: +44(0)131 455 2726 > Fax: +44(0)131 455 2727 > --------------------------------------------------- > = > -----Original Message----- > From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Beh= alf Of Stig Venaas > Sent: 26 May 2011 20:14 > To: multimob@ietf.org > Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimi= zation-05 as a wg document > = > It looks like we have sufficient support to adopt this. Quite a few in > favor and no one against. > = > Hitoshi, please resubmit as a wg document, > = > Stig > = > On 5/5/2011 12:50 PM, Stig Venaas wrote: >> Hi >> >> The draft draft-asaeda-multimob-igmp-mld-optimization-05 was presented >> in the wg meeting in Prague. We were asking about adoption there. A few >> people supported it, none were against. >> >> To decide whether to adopt, we also need to check on the list. >> >> Please read the document, and state whether you think it is ready for >> adoption or not. >> >> Note that we have in our charter to submit a document on how to tune >> IGMPv3/MLDv2 for mobility. >> >> Stig >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > = > = > Edinburgh Napier University is Edinburgh's top university for graduate em= ployability (HESA 2010), and proud winner of the Queen's Anniversary Prize = for Higher and Further Education 2009, awarded for innovative housing const= ruction 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 Un= iversity without the permission of the sender. It is your responsibility to= ensure that this message and any attachments are scanned for viruses or ot= her defects. = > 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 filt= ering by the University. = > = > Edinburgh Napier University is a registered Scottish > charity. > Registration number SC018373 > = > = > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob Edinburgh Napier University is Edinburgh's top university for graduate empl= oyability (HESA 2010), and proud winner of the Queen's Anniversary Prize fo= r Higher and Further Education 2009, awarded for innovative housing constru= ction 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 Univ= ersity without the permission of the sender. It is your responsibility to e= nsure that this message and any attachments are scanned for viruses or othe= r defects. = 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 e= ntering the University's system is subject to routine monitoring and filter= ing by the University. = Edinburgh Napier University is a registered Scottish charity. Registration number SC018373 From sunseawq@huawei.com Fri Jun 3 02:26:44 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5D2E06F2 for ; Fri, 3 Jun 2011 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.092 X-Spam-Level: X-Spam-Status: No, score=-5.092 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjVW5o1fRIwl for ; Fri, 3 Jun 2011 02:26:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8BE072A for ; Fri, 3 Jun 2011 02:26: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 <0LM7009DFJJKRT@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 03 Jun 2011 17:26:08 +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 <0LM700ACWJJK17@szxga03-in.huawei.com> for multimob@ietf.org; Fri, 03 Jun 2011 17:26:08 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM700FF7JJJ87@szxml06-in.huawei.com> for multimob@ietf.org; Fri, 03 Jun 2011 17:26:07 +0800 (CST) Date: Fri, 03 Jun 2011 17:30:30 +0800 From: Qin Wu To: "Romdhani, Imed" , Stig Venaas , multimob@ietf.org Message-id: <02f501cc21d0$e2321930$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <4DC2FFA1.3040103@venaas.com> <4DDEA66C.2080107@venaas.com> <78F1C759D89E1C44A6DD4C06B9A4B270C398AFB8B5@E2K7MBX.napier-mail.napier.ac.uk> <014501cc2014$729ae3d0$46298a0a@china.huawei.com> <78F1C759D89E1C44A6DD4C06B9A4B270C398E2E971@E2K7MBX.napier-mail.napier.ac.uk> Subject: Re: [multimob] Adoption of draft-asaeda-multimob-igmp-mld-optimization-05 as a wg document X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 09:26:44 -0000 SGksIEltZWQ6DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvbWRoYW5p LCBJbWVkIiA8SS5Sb21kaGFuaUBuYXBpZXIuYWMudWs+DQpUbzogIlFpbiBXdSIgPHN1bnNlYXdx QGh1YXdlaS5jb20+OyAiU3RpZyBWZW5hYXMiIDxzdGlnQHZlbmFhcy5jb20+OyA8bXVsdGltb2JA aWV0Zi5vcmc+DQpDYzogIlJvbWRoYW5pLCBJbWVkIiA8SS5Sb21kaGFuaUBuYXBpZXIuYWMudWs+ DQpTZW50OiBGcmlkYXksIEp1bmUgMDMsIDIwMTEgNDo0OSBQTQ0KU3ViamVjdDogUkU6IFttdWx0 aW1vYl0gQWRvcHRpb24gb2YgZHJhZnQtYXNhZWRhLW11bHRpbW9iLWlnbXAtbWxkLW9wdGltaXph dGlvbi0wNSBhcyBhIHdnIGRvY3VtZW50DQoNCg0KRGVhciBRaW4sDQpEZWFyIEZvbGtzLA0KDQpU aGFua3MgZm9yIHRoZXNlIGNsYXJpZmljYXRpb25zLiBUbyBhbnN3ZXIgeW91ciBxdWVzdGlvbiBh Ym91dCB0aGUgY2FzZSB3aGVuIGEgbW9iaWxpdHkgYWdlbnQgaXMgYW4gSUdNUC9NTEQgUXVlcmll ciwgdGhlIGxhdGVzdCBNb2JpbGUgSVB2NiBSRkMgZm9yIGV4YW1wbGUgKHJmYzM3NzViaXMtMTMs IFNlY3Rpb24gMTAuNC4zKSBoaWdobGlnaHRzIHRoZSBuZWNlc3NpdHkgdGhhdCB0aGUgSG9tZSBB Z2VudCBpbXBsZW1lbnQgYSBzb3J0IG9mICJwZXItdHVubmVsIGJlaGF2aW91ciIgZm9yIG11bHRp Y2FzdCBtZW1iZXJzaGlwIGNvbnRyb2wgbWVzc2FnZXMuIFRoaXMgc3RhbmRhcmQgc3RhdGVkIHRo YXQgInRvIGF2b2lkIGFtYmlndWl0eSBvbiB0aGUgaG9tZSBhZ2VudCwgZHVlIHRvIG1vYmlsZSBu b2RlcyB3aGljaCBtYXkgY2hvb3NlIGlkZW50aWNhbCBsaW5rLWxvY2FsIHNvdXJjZSBhZGRyZXNz ZXMgZm9yIHRoZWlyIE1MRCBmdW5jdGlvbiwgaXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgaG9tZSBh Z2VudCB0byBpZGVudGlmeSB3aGljaCBtb2JpbGUgbm9kZSB3YXMgYWN0dWFsbHkgdGhlIGlzc3Vl ciBvZiBhIHBhcnRpY3VsYXIgTUxEIG1lc3NhZ2UuICBUaGlzIG1heSBiZSBhY2NvbXBsaXNoZWQg Ynkgbm90aW5nIHdoaWNoIHR1bm5lbCBzdWNoIGFuIE1MRCBhcnJpdmVkIGJ5LCB3aGljaCBJUHNl YyBTQSB3YXMgdXNlZCwgb3IgYnkgb3RoZXIgZGlzdGluZ3Vpc2hpbmcgbWVhbnMiLiBUaGUgaW1w bGljYXRpb24gb2YgdGhhdCBtZWFucyB0aGF0IHRoZSB0dW5pbmcgbWVjaGFuaXNtIHRoYXQgd2Ug KE11bHRpbW9iKSBhcmUgcHJvcG9zaW5nIG5lZWRzIHRvIGJlIGFkYXB0ZWQgb3IgYWRqdXN0ZWQg dG8gZWFjaCBtb2JpbGUgbm9kZSBzcGVjaWZpYyBuZWVkcy4gIA0KDQpbUWluXTogR29vZCBwb2lu dC4NCg0KSSBhbSBpbiBmYXZvdXIgb2YgYSB3aW5kb3dpbmcgc3R5bGUgbWFuYWdlbWVudCB3aGVy ZSB0aGUgdGltZXJzIGNhbiBiZSBpbmNyZWFzZWQgb3IgZGVjcmVhc2VkIGdyYWR1YWxseSBhbmQg aW4gYW4gYXV0b21hdGVkIGFuZCBpbnRlbGxpZ2VudCB3YXkgb2YgcG9zc2libGUuIFdlIGNhbiBp bWl0YXRlIHRoZSBUQ1Agd2luZG93aW5nIGFwcHJvYWNoLg0KDQpbUWluXTogIFlvdXIgcHJvcG9z YWwgbG9va3MgcmVhc29uYWJsZSB0byBtZS4NCg0KRm9yIHRoZSB1bnNvbGljaXRlZCByZXBvcnQs IHlvdSBhcmUgcmlnaHQuIE1vYmlsZSBub2RlcyBjYW4gc2VuZCB0aGVpciBSZXBvcnRzIHdoZW5l dmVyIHRoZXkgd2FudCBpbmRlcGVuZGVudGx5IG9mIHRoZSBzdWJzY3JpcHRpb24gbWV0aG9kICho b21lIG9yIHJlbW90ZSkuIEluIHByZXZpb3VzIE1JUCBzdGFuZGFyZHMsIGl0IHdhcyByZWNvbW1l bmRlZCB0aGF0IG1vYmlsZSBub2RlcyBuZWVkIHRvIHdhaXQgZmlyc3QgdGhlIHJlY2VwdGlvbiBv ZiBJR01QL01MRCBxdWVyeSBvbiB0aGUgYmktZGlyZWN0aW9uYWwgdHVubmVsIGJlZm9yZSBzZW5k aW5nIGJhY2sgdGhlaXIgcmVwb3J0cy4gRm9yIHNlY3VyaXR5IHJhaXNvbiwgSSB0aGluayB3ZSBj YW5ub3QgYXZvaWQgdGhlIGluaXRpYWwgc3RlcCBvZiB2YWxpZGF0aW5nIHRoZSBDb0EgaWYgdGhl IHJlbW90ZSBzdWJzY3JpcHRpb24gaXMgdXNlZC4gIFdoYXQgb3B0aW1hbCBzdWJzY3JpcHRpb24g bWV0aG9kIGEgbW9iaWxlIG5vZGUgc2hvdWxkIHVzZSBkZXBlbmRzIG9uIG1hbnkgZmFjdG9yczog YXZhaWxhYmlsaXR5IG9mIG11bHRpY2FzdCBzZXJ2aWNlLCBhY2Nlc3MgcmlnaHRzLCBzY29wZSBi b3VuZGFyaWVzLCBRb1MgcGVyZm9ybWFuY2UsIGV0Yy4gSWYgdGhlIGhvbWUgc3Vic2NyaXB0aW9u IGlzIHVzZWQsIHRoZSBRdWVyaWVyIG5lZWRzIHRvIHNwZWVkIHVwIHNlbmRpbmcgUXVlcnkgbWVz c2FnZXMgdG8gbW9iaWxlIG5vZGVzIHRvIGNvbXBlbnNhdGUgdGhlIHRyYW5zZmVyIGRlbGF5LiBU aGlzIG1heSBiZSBhbHNvIGFwcGxpY2FibGUgaW4gdGhlIHJlbW90ZSBzdWJzY3JpcHRpb24gc2Nl bmFyaW8sIGJ1dCBhbnkgdGltZXIgbWFuaXB1bGF0aW9ucyAoaW4gY2FzZSB3aGVyZSB0aGUgSEEg aXMgYSBRdWVyaWVyIG9yIElHTVAvTUxEIGZvcndhcmRlciBmb3IgTU5zKSBoYXMgYmUgY2F1dGlv dXMhIFRoZSBiZWhhdmlvdXIgb2YgYSBtb2JpbGUgZGV2aWNlIG1heSBiZSBkaWZmZXJlbnQgYWxz byBpbiBkZWxheWluZyBoaXMgcmVwb3J0IG1lc3NhZ2VzIGRlcGVuZGluZyBvbiBpdHMgYXdhcmVu ZXNzIG9mIHdoaWNoIHN1YnNjcmlwdGlvbiBtZXRob2QgaXMgdXNlZCBhbmQgdGhlIHByb3hpbWl0 eSBvZiB0aGUgSUdNUC9NTEQgUXVlcmllci4NCiANCltRaW5dOiAgRXhhY3RseS4gWW91IGhhdmUg YW5zd2VyZWQgbXkgcXVlc3Rpb24uIFRoYW5rcy4NCg0KRmluYWxseSwgaXQgaXMgd29ydGggY2xh cmlmeWluZyB0aGUgY2FzZSB3aGVyZSB0aGUgUXVlcmllciBpcyBub3QgYSByb3V0ZXIgKGNhc2Ug b2YgSUdNUC9NTEQgUHJveHkgZm9yIGV4YW1wbGUpLiBUaGlzIHdpbGwgZ2l2ZSB1cyBkaWZmZXJl bnQgSUdNUC9NTEQgdHVuaW5nIHNjZW5hcmlvczogc2ltcGxlIHJvdXRlcjsgcm91dGVyIHdpdGgg bW9iaWxpdHkgYWdlbnQgZnVuY3Rpb246IE1JUCBhY2Nlc3Mgcm91dGVyLCBIQSwgTW9iaWxpdHkg QW5jaG9yIFBvaW50OyBhbmQgSUdNUC9NTEQgcHJveHkuDQoNCltRaW5dOiBBZ3JlZS4gSG93ZXZl ciB0aGUgbW9ibGl0eSBwcm90b2NvbCBmYW1pbHkgaXMgbm90IGxpbWl0ZWQgdG8gTUlQLCB3ZSBh bHNvIGhhdmUgUE1JUCwgd2hpY2ggb25lIHdlIHNob3VsZCBjbGFyaWZ5IGZpcnN0LCB3aGljaCBv bmUgd2Ugc2hvdWxkIGZvY3VzIG9uLg0KDQpBZ2FpbiwgSSBpdGVyYXRlIG15IHN1cHBvcnQgZm9y IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpLaW5kIHJlZ2FyZHMsDQpJbWVkDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRaW4gV3UgW21haWx0bzpzdW5zZWF3cUBo dWF3ZWkuY29tXSANClNlbnQ6IDAxIEp1bmUgMjAxMSAwNToyOQ0KVG86IFJvbWRoYW5pLCBJbWVk OyBTdGlnIFZlbmFhczsgbXVsdGltb2JAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbXVsdGltb2Jd IEFkb3B0aW9uIG9mIGRyYWZ0LWFzYWVkYS1tdWx0aW1vYi1pZ21wLW1sZC1vcHRpbWl6YXRpb24t MDUgYXMgYSB3ZyBkb2N1bWVudA0KDQpIaSwgSW1lZDoNClRoYW5rIGZvciB5b3VyIGZlZWRiYWNr LCBwbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUm9tZGhhbmksIEltZWQiIDxJLlJvbWRoYW5p QG5hcGllci5hYy51az4NClRvOiAiU3RpZyBWZW5hYXMiIDxzdGlnQHZlbmFhcy5jb20+OyA8bXVs dGltb2JAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDEsIDIwMTEgMTI6NTAgQU0N ClN1YmplY3Q6IFJlOiBbbXVsdGltb2JdIEFkb3B0aW9uIG9mIGRyYWZ0LWFzYWVkYS1tdWx0aW1v Yi1pZ21wLW1sZC1vcHRpbWl6YXRpb24tMDUgYXMgYSB3ZyBkb2N1bWVudA0KDQoNCj4gRGVhciBh bGwsDQo+IA0KPiBJIGFtIHNvcnJ5IGZvciBub3QgY29tbWVudGluZyBlYXJsaWVyIG9uIHRoaXMg ZHJhZnQuIEkgd291bGQgbGlrZSB0byBzaGFyZSB3aXRoIGFsbCBmb2xrcyBzb21lIGNvbW1lbnRz IHRoYXQgSSBoYXZlIGFscmVhZHkgc2VudCB0byB0aGUgYXV0aG9ycy4NCj4gDQo+IEkgZW5kb3Jz ZSB0aGUgcHJvcG9zYWwgYW5kIEkgZG8gc3VwcG9ydCBpdC4gSG93ZXZlciwgSSBoYXZlIHNvbWUg Y29tbWVudHMgb24gdGhlIGRyYWZ0LiBPdmVyYWxsLCB0aGVyZSBpcyBzdGlsbCBhIG5lZWQgdG8g Y2xhcmlmeSBhbmQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0d28gYXNwZWN0cyBpbiB0aGUgb3Bl cmF0aW9uIG9mIElHTVAvTUxELiBBIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdlZW4gUm91dGVyIE9w ZXJhdGlvbiBhbmQgSG9zdCBPcGVyYXRpb24gc2hvdWxkIGJlIGRpc2N1c3NlZCBlc3BlY2lhbGx5 IHdoZW4gaXQgY29tZXMgdG8gdHVuaW5nIGRlY2lzaW9uIGVpdGhlciB0byBzcGVlZCB1cCBvciB0 byBzbG93IGRvd24gY29udHJvbCBzaWduYWxsaW5nIG1lc3NhZ2VzLg0KDQpbUWluXTogSSBhZ3Jl ZSBpdCBpcyBtb3JlIHZhbHVhYmxlIHRvIGRpc2N1c3MgaG93IElHTVAvdHVuaW5nIHdvcmtzIGlu IG1vYmlsaXR5IHVzYWdlIHNjZW5hcmlvIHJhdGhlciB0aGFuIGxpbWl0ZWQgdHVuaW5nIG1lY2hh bmlzbSB0byB0aGUgcHVyZSB3aXJlbGVzcyBjYXNlcy4NCg0KPiBBbm90aGVyIHBvaW50IHRoYXQg dGhlIGF1dGhvcnMgaGF2ZSBwcm9iYWJseSAibWlzc2VkIiB0byBkaXNjdXNzIGlzIHRoZSBjYXNl IHdoZXJlIGEgTW9iaWxpdHkgQWdlbnQgKEhvbWUgQWdlbnQsIFByb3h5IG9yIEFuY2hvciBQb2lu dCkgaXMgYSBRdWVyaWVyLiBJbiB0aGlzIGNhc2UsIHRoZSBhZ2VudCBoYXMgdG8gcnVuIG11bHRp cGxlIGluc3RhbmNlcyBvZiB0aGUgSUdNUC9NTEQgcHJvY2Vzc2VzIG9uIHBoeXNpY2FsIG5ldHdv cmsgaW50ZXJmYWNlcyBhbmQgb24gdHVubmVsIGludGVyZmFjZXMuIFRoZSBiZWhhdmlvdXIgb2Yg SUdNUC9NTEQgc2hvdWxkIGJlIG5hdHVyYWxseSBkaWZmZXJlbnQgYXMgdGhlIGF3YXJlbmVzcyBs ZXZlbCBvZiB0aGUgbXVsdGljYXN0IG1lbWJlcnNoaXAgaXMgZGlmZmVyZW50Lg0KDQpbUWluXTog WW91IGFyZSB0YWxraW5nIGFib3V0IGhvdyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gcmVtb3Rl IHN1YnNjcmlwdGlvbiBjYXNlIGFuZCBob21lIHN1YnNjcmlwdGlvbiBjYXNlPyANCkFzIEkgc2Fp ZCwgSSBhZ3JlZSB0byBkaXNjdXNzIGhvdyBJR01QL01MRCB0dW5pbmcgaXMgdXNlZCBpbiBtb2Jp bGl0eSBzY2VuYXJpby4NCkhvd2V2ZXIgSSBhbSBub3Qgc3VyZSB3aGF0J3MgdGhlIGRpZmZlcmVu Y2Ugb2YgdGhlIGJlaGF2aW9yICBvZiBJR01QL01MRCBpbiB0d28gZGlmZmVyZW50IGNhc2VzIG1l bnRpb25lZCBhYm92ZT8NCg0KQlRXOiB3aGF0IGtpbmQgb2YgYWdlbnQgeW91IGFyZSB0YWxraW5n IGFib3V0IHByb2Nlc3MgdGhlIElHTVAvTUxEIG1lc3NhZ2U/DQpJIHN1c3BlY3QgdGhlIGFnZW50 IGlzIG5vdCBtb2JpbGl0eSBhZ2VudC4NCg0KIEluIGFkZGl0aW9uLCB0aGUgcHJvY2Vzc2VzIGFy ZSBub3QgaW5kZXBlbmRlbnQgYXMgb25lIG1heSBhZmZlY3QgdGhlIG90aGVyLiBGaXhlZCBtZW1i ZXJzIG1heSBhZmZlY3QgbW9iaWxlIGRldmljZXMgdGhhdCBhcmUgYXdheSBkdWUgdG8gdGhlaXIg am9pbi9sZWF2ZSBhY3Rpdml0aWVzLiAgDQoNCltRaW5dOiBIb3csIGNhbiB5b3UgY2xhcmlmeSBp dCBtb3JlPw0KDQo+IEFzIHRoZSB2YWx1ZXMgb2YgdGhlIGRpZmZlcmVudCB0aW1lcnMgYXJlIGNv bmNlcm5lZCwgSSB0aGluayB0aGVyZSBpcyBubyBuZWVkIHRvIGZpeCB0aGVtLiBBdXRob3JzIGhh dmUganVzdGlmaWVkIHRoZWlyIGNob2ljZSBiYXNlZCBvbiBhbmFseXNpcyB0aGF0IHRoZXkgaGF2 ZSBkb25lLCBidXQgSSB0aGluayB0aGVyZSBzaG91bGQgYmUgYSBzb3J0IG9mIHZhcmlhdGlvbiAo cmFuZ2UgdGhhdCBjYW4gYmUgZW5sYXJnZWQgb3Igc2hvcnRlbmVkKSBkZXBlbmRpbmcgb24gZGlm ZmVyZW50IGNpcmN1bXN0YW5jZXMgYW5kIHRoZSBsYXllciAyIHRlY2hub2xvZ3kgdXNlZC4NCg0K W1Fpbl06IEFncmVlLiBJdCBpcyByZWFzb25hYmxlIHRvIGFsbG93IHBhcmFtZXRlcnMgdG8gYmUg dHVuZWQgdmFyeSBmcm9tIGRpZmZlcmVudCBjaXJjdW1zdGFuY2VzLg0KDQo+IEhhdmluZyBhIHRy YWNrIHJlY29yZCBvZiBtb2JpbGUgbWVtYmVycyBtYXkgYmUgZWFzeSB0byBkZXRlY3QgYW5kIG1h aW50YWluIGlmIHRoZSBIb21lIEFnZW50IGlzIGEgUXVlcmllci4NCg0KW1Fpbl06IEFncmVlIHNp bmNlIGhvbWUgYWdlbnQgb3Igb3RoZXIgYWdlbnQgY2FuIG1haW50YWluIHRoZSByZWNvcmQgb2Yg ZWFjaCBtb2JpbGUgbWVtYmVycyBpbiB0aGUgbW9iaWxpdHkgc2NlbmFyaW8uDQoNCiBJbiBvdGhl ciBjYXNlcywgSSBkb24ndCBzZWUgd2hvIHdlIGNhbiBkaXN0aW5ndWlzaCB0aGUgb3JpZ2luIG9m IGFuIElHTVAvTUxEIHJlcG9ydCBtZXNzYWdlIChpLmUuIGNvbWluZyBmcm9tIGEgbW9iaWxlIG9y IHN0YXRpb25hcnkgZGV2aWNlKS4gUm91dGVycyBhcmUgY29ubmVjdGVkIGluIGdlbmVyYWwgdG8g V2lyZWxlc3MgRG9tYWluIFN5c3RlbXMgb3IgQWNjZXNzIFBvaW50cyBhbmQgdGhleSBhcmUgbm90 IGRpcmVjdGx5IGNvbm5lY3RlZCB0byBtb2JpbGUgZGV2aWNlcyAoZGVzaWduIGFzc3VtcHRpb24g YW5kIG1hbmFnZW1lbnQgaXNzdWUpLg0KDQpbUWluXTogV2h5IHNob3VsZCB3ZSBuZWVkIHRvIGRp c3Rpbmd1aXNoIHdodGhlciBJR01QL01MRCByZXBvcnQgbWVzc2FnZSBpcyBzZW50IGZyb20gbW9i aWxlIGRldmljZSBvciBhIGZpeGVkIGRldmljZT8NCg0KPiBGaW5hbGx5LCBhIG1vYmlsZSBkZXZp Y2UgbWF5IG5lZWQgdG8gc3BlZWQgdXAgc2VuZGluZyBoaXMgSUdNUC9NTEQgcmVwb3J0LiBBcyBm YXIgYXMgSSBrbm93LCBpbiBNb2JpbGUgSVAgc3BlY2lmaWNhdGlvbiwgYSBtb2JpbGUgZGV2aWNl IG5lZWRzIHRvIHdhaXQgZmlyc3QgdGhlIHJlY2VwdGlvbiBvZiBhbiBJR01QL01MRCBxdWVyeSBi ZWZvcmUgYmVpbmcgZWxpZ2libGUgdG8gc2VuZCBhIHJlcG9ydCAodGhyb3VnaCB0aGUgYmlkaXJl Y3Rpb25hbCB0dW5uZWwpLCBwcm9iYWJseSB0aGlzIGlzIGFuIGltcGxpY2l0IHBhcnQgb2YgdGhl IFJldHVybiBSb3V0YWJpbGl0eSBwcm9jZWR1cmUgKENvQSBuZWVkcyB0byBiZSB2YWxpZGF0ZWQg YmVmb3JlIHVzZSkuDQoNCltRaW5dOkFzIHJlZ2FyZGluZyB0byB3aGV0aGVyIElHTVAvTUxEIHF1 ZXJ5IGlzIG5lZWRlZCBlYWNoIHRpbWUsIEkgYW0gYWZhaWQgdGhhdCBJIGFtIG5vdCB0ZW5kaW5n IHRvIGFncmVlLiBJbiBzb21lIGNhc2UsIHdlIG5lZWQgc29saWNpdGVkIA0KIG1lbWJlcnNoaXAg cmVwb3J0LCBpbiBzb21lIGNhc2UsIHdlIHVzZSB1bnNvbGljaXRlZCBtZW1iZXJzaXAgcmVwb3J0 LiBlLmcuLCB0aGUgZmlyc3Qgc3Vic2NyaWJlciBqb2lucyBhIG11bHRpY2FzdCBncm91cCwgDQog b3IgdGhlIGxhc3Qgc3Vic2NyaWJlciBsZWF2ZXMgYSBtdWx0aWNhc3QgZ3JvdXAuDQoNCg0KDQo+ IEhvcGUgbXkgY29tbWVudHMgaGVscCB0byBpbXByb3ZlIHRoZSBkcmFmdC4NCj4gDQo+IEtpbmQg UmVnYXJkcywNCj4gSW1lZA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gSW1lZCBSb21kaGFuaSwgUGhEDQo+IElFRUUgTWVtYmVyLCBGSEVB IA0KPiBMZWN0dXJlciBpbiBOZXR3b3JraW5nDQo+IFJvb20gQyA2NA0KPiBFZGluYnVyZ2ggTmFw aWVyIFVuaXZlcnNpdHkNCj4gU2Nob29sIG9mIENvbXB1dGluZw0KPiAxMCBDb2xpbnRvbiBSb2Fk DQo+IEVkaW5idXJnaCwgRUgxMCA1RFQNCj4gVUsNCj4gRS1NYWlsOiAgIEkuUm9tZGhhbmlAbmFw aWVyLmFjLnVrDQo+IEhvbWUgUGFnZTogaHR0cDovL3d3dy5kY3MubmFwaWVyLmFjLnVrL35jczI0 NC8NCj4gVGVsZXBob25lOiArNDQoMCkxMzEgNDU1IDI3MjYNCj4gRmF4OiArNDQoMCkxMzEgNDU1 IDI3MjcNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtdWx0aW1vYi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bXVsdGltb2ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFN0aWcgVmVuYWFzDQo+IFNlbnQ6IDI2IE1heSAyMDExIDIwOjE0DQo+IFRvOiBtdWx0 aW1vYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW211bHRpbW9iXSBBZG9wdGlvbiBvZiBkcmFm dC1hc2FlZGEtbXVsdGltb2ItaWdtcC1tbGQtb3B0aW1pemF0aW9uLTA1IGFzIGEgd2cgZG9jdW1l bnQNCj4gDQo+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBzdWZmaWNpZW50IHN1cHBvcnQgdG8gYWRv cHQgdGhpcy4gUXVpdGUgYSBmZXcgaW4NCj4gZmF2b3IgYW5kIG5vIG9uZSBhZ2FpbnN0Lg0KPiAN Cj4gSGl0b3NoaSwgcGxlYXNlIHJlc3VibWl0IGFzIGEgd2cgZG9jdW1lbnQsDQo+IA0KPiBTdGln DQo+IA0KPiBPbiA1LzUvMjAxMSAxMjo1MCBQTSwgU3RpZyBWZW5hYXMgd3JvdGU6DQo+PiBIaQ0K Pj4NCj4+IFRoZSBkcmFmdCBkcmFmdC1hc2FlZGEtbXVsdGltb2ItaWdtcC1tbGQtb3B0aW1pemF0 aW9uLTA1IHdhcyBwcmVzZW50ZWQNCj4+IGluIHRoZSB3ZyBtZWV0aW5nIGluIFByYWd1ZS4gV2Ug d2VyZSBhc2tpbmcgYWJvdXQgYWRvcHRpb24gdGhlcmUuIEEgZmV3DQo+PiBwZW9wbGUgc3VwcG9y dGVkIGl0LCBub25lIHdlcmUgYWdhaW5zdC4NCj4+DQo+PiBUbyBkZWNpZGUgd2hldGhlciB0byBh ZG9wdCwgd2UgYWxzbyBuZWVkIHRvIGNoZWNrIG9uIHRoZSBsaXN0Lg0KPj4NCj4+IFBsZWFzZSBy ZWFkIHRoZSBkb2N1bWVudCwgYW5kIHN0YXRlIHdoZXRoZXIgeW91IHRoaW5rIGl0IGlzIHJlYWR5 IGZvcg0KPj4gYWRvcHRpb24gb3Igbm90Lg0KPj4NCj4+IE5vdGUgdGhhdCB3ZSBoYXZlIGluIG91 ciBjaGFydGVyIHRvIHN1Ym1pdCBhIGRvY3VtZW50IG9uIGhvdyB0byB0dW5lDQo+PiBJR01QdjMv TUxEdjIgZm9yIG1vYmlsaXR5Lg0KPj4NCj4+IFN0aWcNCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj4+ IG11bHRpbW9iQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL211bHRpbW9iDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBtdWx0aW1vYiBtYWlsaW5nIGxpc3QNCj4gbXVsdGltb2JAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tdWx0aW1vYg0KPiANCj4g DQo+IEVkaW5idXJnaCBOYXBpZXIgVW5pdmVyc2l0eSBpcyBFZGluYnVyZ2gncyB0b3AgdW5pdmVy c2l0eSBmb3IgZ3JhZHVhdGUgZW1wbG95YWJpbGl0eSAoSEVTQSAyMDEwKSwgYW5kIHByb3VkIHdp bm5lciBvZiB0aGUgUXVlZW4ncyBBbm5pdmVyc2FyeSBQcml6ZSBmb3IgSGlnaGVyIGFuZCBGdXJ0 aGVyIEVkdWNhdGlvbiAyMDA5LCBhd2FyZGVkIGZvciBpbm5vdmF0aXZlIGhvdXNpbmcgY29uc3Ry dWN0aW9uIGZvciBlbnZpcm9ubWVudGFsIGJlbmVmaXQgYW5kIHF1YWxpdHkgb2YgbGlmZS4NCj4g DQo+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5DQo+ IGFuZCBzaG91bGQgbm90IGJlIHJlYWQsIGNvcGllZCBvciBkaXNjbG9zZWQgdG8gYW55b25lIGVs c2Ugb3V0d2l0aCB0aGUgVW5pdmVyc2l0eSB3aXRob3V0IHRoZSBwZXJtaXNzaW9uIG9mIHRoZSBz ZW5kZXIuIEl0IGlzIHlvdXIgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhpcyBtZXNz YWdlIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIHNjYW5uZWQgZm9yIHZpcnVzZXMgb3Igb3RoZXIg ZGVmZWN0cy4gDQo+IEVkaW5idXJnaCBOYXBpZXIgVW5pdmVyc2l0eSBkb2VzIG5vdCBhY2NlcHQg bGlhYmlsaXR5IGZvciBhbnkgbG9zcyBvcg0KPiBkYW1hZ2Ugd2hpY2ggbWF5IHJlc3VsdCBmcm9t IHRoaXMgZW1haWwgb3IgYW55IGF0dGFjaG1lbnQsIG9yIGZvciBlcnJvcnMgb3Igb21pc3Npb25z IGFyaXNpbmcgYWZ0ZXIgaXQgd2FzIHNlbnQuIEVtYWlsIGlzIG5vdCBhIHNlY3VyZSBtZWRpdW0u IEVtYWlsIGVudGVyaW5nIHRoZSBVbml2ZXJzaXR5J3Mgc3lzdGVtIGlzIHN1YmplY3QgdG8gcm91 dGluZSBtb25pdG9yaW5nIGFuZCBmaWx0ZXJpbmcgYnkgdGhlIFVuaXZlcnNpdHkuIA0KPiANCj4g RWRpbmJ1cmdoIE5hcGllciBVbml2ZXJzaXR5IGlzIGEgcmVnaXN0ZXJlZCBTY290dGlzaA0KPiBj aGFyaXR5Lg0KPiBSZWdpc3RyYXRpb24gbnVtYmVyIFNDMDE4MzczDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXVsdGltb2IgbWFp bGluZyBsaXN0DQo+IG11bHRpbW9iQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXVsdGltb2INCg0KDQpFZGluYnVyZ2ggTmFwaWVyIFVuaXZlcnNpdHkg aXMgRWRpbmJ1cmdoJ3MgdG9wIHVuaXZlcnNpdHkgZm9yIGdyYWR1YXRlIGVtcGxveWFiaWxpdHkg KEhFU0EgMjAxMCksIGFuZCBwcm91ZCB3aW5uZXIgb2YgdGhlIFF1ZWVuJ3MgQW5uaXZlcnNhcnkg UHJpemUgZm9yIEhpZ2hlciBhbmQgRnVydGhlciBFZHVjYXRpb24gMjAwOSwgYXdhcmRlZCBmb3Ig aW5ub3ZhdGl2ZSBob3VzaW5nIGNvbnN0cnVjdGlvbiBmb3IgZW52aXJvbm1lbnRhbCBiZW5lZml0 IGFuZCBxdWFsaXR5IG9mIGxpZmUuDQoNClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhl IGFkZHJlc3NlZShzKSBvbmx5DQphbmQgc2hvdWxkIG5vdCBiZSByZWFkLCBjb3BpZWQgb3IgZGlz Y2xvc2VkIHRvIGFueW9uZSBlbHNlIG91dHdpdGggdGhlIFVuaXZlcnNpdHkgd2l0aG91dCB0aGUg cGVybWlzc2lvbiBvZiB0aGUgc2VuZGVyLiBJdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIGVu c3VyZSB0aGF0IHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBzY2FubmVkIGZv ciB2aXJ1c2VzIG9yIG90aGVyIGRlZmVjdHMuIA0KRWRpbmJ1cmdoIE5hcGllciBVbml2ZXJzaXR5 IGRvZXMgbm90IGFjY2VwdCBsaWFiaWxpdHkgZm9yIGFueSBsb3NzIG9yDQpkYW1hZ2Ugd2hpY2gg bWF5IHJlc3VsdCBmcm9tIHRoaXMgZW1haWwgb3IgYW55IGF0dGFjaG1lbnQsIG9yIGZvciBlcnJv cnMgb3Igb21pc3Npb25zIGFyaXNpbmcgYWZ0ZXIgaXQgd2FzIHNlbnQuIEVtYWlsIGlzIG5vdCBh IHNlY3VyZSBtZWRpdW0uIEVtYWlsIGVudGVyaW5nIHRoZSBVbml2ZXJzaXR5J3Mgc3lzdGVtIGlz IHN1YmplY3QgdG8gcm91dGluZSBtb25pdG9yaW5nIGFuZCBmaWx0ZXJpbmcgYnkgdGhlIFVuaXZl cnNpdHkuIA0KDQpFZGluYnVyZ2ggTmFwaWVyIFVuaXZlcnNpdHkgaXMgYSByZWdpc3RlcmVkIFNj b3R0aXNoDQpjaGFyaXR5Lg0KUmVnaXN0cmF0aW9uIG51bWJlciBTQzAxODM3Mw0KDQo= From behcetsarikaya@yahoo.com Fri Jun 10 12:50:06 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DFD11E8160 for ; Fri, 10 Jun 2011 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZdv8SdQmQBH for ; Fri, 10 Jun 2011 12:50:06 -0700 (PDT) Received: from nm9-vm0.bullet.mail.sp2.yahoo.com (nm9-vm0.bullet.mail.sp2.yahoo.com [98.139.91.196]) by ietfa.amsl.com (Postfix) with SMTP id 1453311E8097 for ; Fri, 10 Jun 2011 12:50:06 -0700 (PDT) Received: from [98.139.91.62] by nm9.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 19:50:05 -0000 Received: from [98.139.91.29] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 19:50:05 -0000 Received: from [127.0.0.1] by omp1029.mail.sp2.yahoo.com with NNFMP; 10 Jun 2011 19:50:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 958061.73370.bm@omp1029.mail.sp2.yahoo.com Received: (qmail 67248 invoked by uid 60001); 10 Jun 2011 19:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307735403; bh=UY9bkKNA/lqA5HjTDmOwK+Mpxzgztz2F37fJSBuqTn4=; 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=BcDCio1j4FX/cAA0Ldn7pD18ap14BR74+swsmus4Q9phYuotpE4dZh/E6dc3DkDt2fCAWZqh+EjQ9tBKVBs4xOx5eSe0UYv/TWA1jhzm0KZpfZwrLvog2D2VH+I0zVJ31dGf9242WIbNj5Oduk6wJWB40Q/dDyKyEeLuJtIqdD0= 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=IOn+QsDOjszdWO4pLBVV6ysNwayKjDOx6sZpSH7fqNkD1AAj8piSrfHo88fAWPE5mSrIzz78GfRkqbOfVnAhZVT+Y5GhR0FFjtse/j72M9RmT0KPMIvRZ6vzpZvZMFtnekc/kC77kZQ1m2iIuuTORm/XqvkbIr1HeEwWXr/hkvE=; Message-ID: <627875.62000.qm@web111409.mail.gq1.yahoo.com> X-YMail-OSG: _E7VCy0VM1nAwr2ZctGdA5zvBTdUoJ6eEUMVR4i3zZpsKzH YAlg2gpZb8VoVCUFaLZrvM4AbF3IZ3xG4sGf7lIYYx6KYcPEYR3HkaHoF_Ce gHZH6TnuX_cM72RdEQgfVpCfc4653AXSrrwrvVPbK66Angy9vMVE0_O0XtXP s.BKAy6nzOsO2W0tHZECKw568R7zIaPugcUfxpmE3cAi1QALhb7c8kj1LRsB mNi0CIiAlnm6UsUmqryPRyo6QcSTuMAMfmCsEAtqZ3XA5tkLK0J8z3AiytSA UelVN5zoy3me00CaIsqB6H5dmMOQaNohQq8CJn2hyfVu2EsH_hRfEu8ffyMl LwC09rhb2QRDggdhVGQbJevmc3jAI_AuqstlvCuPb5OO5uWlUCwgIST7c04G wIWNfwfMyzH6NeQ-- Received: from [206.16.17.212] by web111409.mail.gq1.yahoo.com via HTTP; Fri, 10 Jun 2011 12:50:03 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2011 12:50:03 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 10 Jun 2011 19:50:06 -0000 Hi Hitoshi, While reading Section 3 on explicit tracking, I noticed that no mention of IGMP/MLD proxy architecture we have in RFC 6224 was made. I am curious as to how the explicit tracking can be performed in a proxy environment where the router only gets aggregate join messages. Maybe this section should discuss this issue which is very relevant to us. Regards, Behcet > 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 : Tuning the Behavior of IGMP and MLD for Mobile Hosts and >Routers > Author(s) : Hitoshi Asaeda > Hui Liu > Qin Wu > Filename : draft-ietf-multimob-igmp-mld-tuning-00.txt > Pages : 15 > Date : 2011-05-26 > > IGMP and MLD are the protocols used by hosts to report their IP > multicast group memberships to neighboring multicast routers. This > document describes the ways of IGMPv3 and MLDv2 protocol optimization > for mobility, and aims to become a guideline for query and other > timers tuning. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-multimob-igmp-mld-tuning-00.txt > _______________________________________________ > multimob b mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob > From asaeda@sfc.wide.ad.jp Sat Jun 11 00:40:32 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4611E8078 for ; Sat, 11 Jun 2011 00:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCuNpLqFza3T for ; Sat, 11 Jun 2011 00:40:32 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id E847511E8075 for ; Sat, 11 Jun 2011 00:40:30 -0700 (PDT) Received: from localhost (p8213-ipngn1901hodogaya.kanagawa.ocn.ne.jp [180.11.1.213]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F072A278091; Sat, 11 Jun 2011 16:39:57 +0900 (JST) Date: Sat, 11 Jun 2011 16:39:56 +0900 (JST) Message-Id: <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> To: sarikaya@ieee.org, behcetsarikaya@yahoo.com From: Hitoshi Asaeda In-Reply-To: <627875.62000.qm@web111409.mail.gq1.yahoo.com> References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> <627875.62000.qm@web111409.mail.gq1.yahoo.com> X-Mailer: Mew version 6.3 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] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 07:40:32 -0000 Hi Behcet, > While reading Section 3 on explicit tracking, I noticed that no mention of > IGMP/MLD proxy architecture we have in RFC 6224 was made. > > I am curious as to how the explicit tracking can be performed in a proxy > environment where the router only gets aggregate join messages. Above "the router" means MAG acting as IGMP/MLD proxy? If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD proxy, which is no difference from the standard IGMP/MLD proxy device (rfc4605), and hence there is no special explanation for 6224 is needed in this draft, I think. Or am I missing something? Regards, -- Hitoshi Asaeda From schmidt@informatik.haw-hamburg.de Sat Jun 11 03:37:03 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F211E809E for ; Sat, 11 Jun 2011 03:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIO7eKTrV-0c for ; Sat, 11 Jun 2011 03:37:03 -0700 (PDT) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 37DE411E808C for ; Sat, 11 Jun 2011 03:37:02 -0700 (PDT) Envelope-to: multimob@ietf.org Received: from e178061189.adsl.alicedsl.de ([85.178.61.189] helo=[192.168.178.36]) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QVLYq-000Dfg-LK; Sat, 11 Jun 2011 12:37:00 +0200 Message-ID: <4DF34547.10104@informatik.haw-hamburg.de> Date: Sat, 11 Jun 2011 12:36:55 +0200 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hitoshi Asaeda References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> <627875.62000.qm@web111409.mail.gq1.yahoo.com> <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> In-Reply-To: <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: multimob@ietf.org Cc: behcetsarikaya@yahoo.com, multimob@ietf.org Subject: Re: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 10:37:03 -0000 Hi Hitoshi, you're right in the sense that so far IETF work on multicast mobility has not produced protocols that are distinct from existing standards. According to the charter, we have all concentrated on efficient deployment and suitable tuning. This is true for draft-ietf-multimob-igmp-mld-tuning-00.txt, as well. However, I agree with Behcet that - even though it is not normative in the sense that standard dependencies are revealed - references and discussions should be included to the state of IETF/IRTF work. Questions like "how do MLD tuning proposals affect the RFC 6224 base solution?" should be asked and answered in your draft. Further, not only for the benefit of the readers, but also for the sake of transparency and conciseness, references and discussions should be included to the problem space (RFC5757) and the solution space (RFC6224 + existing *original* drafts) as informational pointers. Currently, the draft does not make any reference to related work on multicast mobility/MLD issues (neither within IETF/IRTF nor to the outside world). Without these links, it appears the authors are unaware of the extensive discussions that happened prior to their work on this draft, and statements in the document fall "out of the blue". As is, this is a clear quality issue of the document and degrades the visible value of Multimob work. Hence, I would strongly plead for adding discussions and references to the core aspects & documents in draft-ietf-multimob-igmp-mld-tuning to shift this to WG document standards. Cheers & best wishes, Thomas On 11.06.2011 09:39, Hitoshi Asaeda wrote: > Hi Behcet, > >> While reading Section 3 on explicit tracking, I noticed that no mention of >> IGMP/MLD proxy architecture we have in RFC 6224 was made. >> >> I am curious as to how the explicit tracking can be performed in a proxy >> environment where the router only gets aggregate join messages. > > Above "the router" means MAG acting as IGMP/MLD proxy? > If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD > proxy, which is no difference from the standard IGMP/MLD proxy device > (rfc4605), and hence there is no special explanation for 6224 is > needed in this draft, I think. > > Or am I missing something? > > Regards, > -- > Hitoshi Asaeda > _______________________________________________ > 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 asaeda@sfc.wide.ad.jp Sat Jun 11 10:22:57 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164F11E81F8 for ; Sat, 11 Jun 2011 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXFmvOw-njK5 for ; Sat, 11 Jun 2011 10:22:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8C99411E81F5 for ; Sat, 11 Jun 2011 10:22:56 -0700 (PDT) Received: from localhost (p8213-ipngn1901hodogaya.kanagawa.ocn.ne.jp [180.11.1.213]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7AD282782D8; Sun, 12 Jun 2011 02:22:22 +0900 (JST) Date: Sun, 12 Jun 2011 02:22:21 +0900 (JST) Message-Id: <20110612.022221.157916385.asaeda@sfc.wide.ad.jp> To: schmidt@informatik.haw-hamburg.de From: Hitoshi Asaeda In-Reply-To: <4DF34547.10104@informatik.haw-hamburg.de> References: <627875.62000.qm@web111409.mail.gq1.yahoo.com> <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> <4DF34547.10104@informatik.haw-hamburg.de> X-Mailer: Mew version 6.3 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] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 17:22:57 -0000 Thomas, ... snip ... > Currently, the draft does not make any reference to related work on > multicast mobility/MLD issues (neither within IETF/IRTF nor to the > outside world). Without these links, it appears the authors are > unaware of the extensive discussions that happened prior to their work > on this draft, and statements in the document fall "out of the > blue". As is, this is a clear quality issue of the document and > degrades the visible value of Multimob work. It seems you start the different talk. Anyway, let's go back to the original discussion. In fact, in section 4.4 of the tuning draft, it is mentioned that tuning the Startup Query Interval contributes to shortening handover delay for MNs in PMIPv6 domain. This tuning is therefore helpful for rfc6224. Currently, section 4.4 refers to rfc5213, but if multimob people agree, we will change the reference to rfc6224. If there are other relevant scenarios, please point out. Thanks. Regards, -- Hitoshi Asaeda From behcetsarikaya@yahoo.com Mon Jun 13 07:53:48 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EF711E8081 for ; Mon, 13 Jun 2011 07:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dLhO3C7G26f for ; Mon, 13 Jun 2011 07:53:48 -0700 (PDT) Received: from nm10.bullet.mail.sp2.yahoo.com (nm10.bullet.mail.sp2.yahoo.com [98.139.91.80]) by ietfa.amsl.com (Postfix) with SMTP id 00A6811E8075 for ; Mon, 13 Jun 2011 07:53:47 -0700 (PDT) Received: from [98.139.91.69] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2011 14:53:47 -0000 Received: from [98.139.91.21] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 13 Jun 2011 14:53:47 -0000 Received: from [127.0.0.1] by omp1021.mail.sp2.yahoo.com with NNFMP; 13 Jun 2011 14:53:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 954303.8695.bm@omp1021.mail.sp2.yahoo.com Received: (qmail 89735 invoked by uid 60001); 13 Jun 2011 14:53:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307976827; bh=xMW7bnNjYoVzcg2u8ZgUN+WRO8FY+oPJbLDDng3kUn4=; 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=ujRFy1tjREBQ/mTvgkcnvwEx5AxQNhzQltxIEC+m+8WNzhtoxau0RJCVyxuO1R0+o+yHCWumEq2fQLqFkwa4edz5wQL2AwFGER1S9jlZS6CYkP35tQ6nko/z75aC+kBkPo2O8ateNSjGW8UpASIoVvQEBSdCfWMifcB9yGz4+sY= 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=g0MkQApW3GeGpPYS1Tq3Sm1r8d0yu/FQ3DmjOfSG+UTa+hROBH8pqiZFyGKKU1V6xO4kPFs6waiHe3zdLqFjmbpZugnaXiuaQccWdKG5hXmEc6nXl5yGpQgjeWKLiqkZy154LFq571KkFphUYD6Ew6v/xoNTNV0bvqz7lb5TJ4k=; Message-ID: <494945.64841.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: lLczSJ0VM1lWaJFYTwYmyJ6QmJqVd2vDI5fg6IqSV.7hY1V mw.oUPBaBW7aCEp1oAhceOfkilstDK0SHbEXTdy9W7_hrgL2g7F3xycGkCXA 1ptdhh9qeQhXEEFKbZmrgbjQ0bEhbRJAM49z5qgJpQN1HfF3M9YBpoDvTm4W UOBZX4Cvu_TDwjxT7hpJhqXGXbKB2eQjhP2RbCcN7CFQhFJj8F17R2LbwjpU _4d_yT6YID8TM5IYuotohD_knFHVBW.u4RuffpGS_PpM9dmIW8qGEj3PYaFo mMWx7f_GKmmkC9WD7eUx3JpHY_sXSFA53PMWe.Gd36P8cjzxJdu.PM4fTWSC Z8BVr6zlIgmA2HL0QkkeVCzgLNbG_zjjvenDsWnc_IJDjTpjeHr6wXreJIeg H38cBiV3GX_iXqA-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Mon, 13 Jun 2011 07:53:47 PDT X-Mailer: YahooMailRC/570 YahooMailWebService/0.8.111.304355 References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> <627875.62000.qm@web111409.mail.gq1.yahoo.com> <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> Date: Mon, 13 Jun 2011 07:53:47 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda In-Reply-To: <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2011 14:53:48 -0000 Hi Hitoshi, > Hi Behcet, > > > While reading Section 3 on explicit tracking, I noticed that no mention of > > > IGMP/MLD proxy architecture we have in RFC 6224 was made. > > > > I am curious as to how the explicit tracking can be performed in a proxy > > environment where the router only gets aggregate join messages. > > Above "the router" means MAG acting as IGMP/MLD proxy? > If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD > proxy, which is no difference from the standard IGMP/MLD proxy device > (rfc4605), and hence there is no special explanation for 6224 is > needed in this draft, I think. Does 4605 talk about explicit tracking? > > Or am I missing something? What about if the router is the LMA? Of course LMA could be a proxy but we should consider LMA being a router as the most likely scenario? It seems to me that in that case explicit tracking will simply not work and all the timer tuning recommended. Maybe we should state that in the draft. Regards, Behcet From stig@venaas.com Tue Jun 21 10:46:33 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762C411E808B for ; Tue, 21 Jun 2011 10:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fmkvLLwlb+0 for ; Tue, 21 Jun 2011 10:46:33 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 048E211E8072 for ; Tue, 21 Jun 2011 10:46:31 -0700 (PDT) Received: from [10.33.12.67] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 353E98005 for ; Tue, 21 Jun 2011 19:46:27 +0200 (CEST) Message-ID: <4E00D8F0.2000605@venaas.com> Date: Tue, 21 Jun 2011 10:46:24 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: multimob@ietf.org References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> <627875.62000.qm@web111409.mail.gq1.yahoo.com> <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> <494945.64841.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <494945.64841.qm@web111407.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:46:33 -0000 Hi On 6/13/2011 7:53 AM, Behcet Sarikaya wrote: > Hi Hitoshi, > >> Hi Behcet, >> >>> While reading Section 3 on explicit tracking, I noticed that no mention of >> >>> IGMP/MLD proxy architecture we have in RFC 6224 was made. >>> >>> I am curious as to how the explicit tracking can be performed in a proxy >>> environment where the router only gets aggregate join messages. You can combine proxying and explicit tracking. If you have say a topology like this: R router / \ P1 P2 proxies / \ | \ H11 H12 H21 H22 hosts Then R, P1 and P2 can do explicit tracking in order to restrict sending of multicast packets, and perform fast leave etc. The point is to do it at each branching point. R won't be able to track the hosts, it may only know of P1 and P2, but that is fine. Stig >> Above "the router" means MAG acting as IGMP/MLD proxy? >> If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD >> proxy, which is no difference from the standard IGMP/MLD proxy device >> (rfc4605), and hence there is no special explanation for 6224 is >> needed in this draft, I think. > > Does 4605 talk about explicit tracking? > >> >> Or am I missing something? > > What about if the router is the LMA? > Of course LMA could be a proxy but we should consider LMA being a router as the > most likely scenario? It seems to me that in that case explicit tracking will > simply not work and all the timer tuning recommended. > > Maybe we should state that in the draft. > > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From stig@venaas.com Tue Jun 21 10:46:42 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E145F11E82CE for ; Tue, 21 Jun 2011 10:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBmgXHWXznQ7 for ; Tue, 21 Jun 2011 10:46:42 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF7411E82CD for ; Tue, 21 Jun 2011 10:46:42 -0700 (PDT) Received: from [10.33.12.67] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 591158005 for ; Tue, 21 Jun 2011 19:46:40 +0200 (CEST) Message-ID: <4E00D8FE.9070808@venaas.com> Date: Tue, 21 Jun 2011 10:46:38 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: multimob@ietf.org References: <20110527135549.12492.41487.idtracker@ietfa.amsl.com> <627875.62000.qm@web111409.mail.gq1.yahoo.com> <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> <494945.64841.qm@web111407.mail.gq1.yahoo.com> In-Reply-To: <494945.64841.qm@web111407.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 17:46:43 -0000 Hi On 6/13/2011 7:53 AM, Behcet Sarikaya wrote: > Hi Hitoshi, > >> Hi Behcet, >> >>> While reading Section 3 on explicit tracking, I noticed that no mention of >> >>> IGMP/MLD proxy architecture we have in RFC 6224 was made. >>> >>> I am curious as to how the explicit tracking can be performed in a proxy >>> environment where the router only gets aggregate join messages. You can combine proxying and explicit tracking. If you have say a topology like this: R router / \ P1 P2 proxies / \ | \ H11 H12 H21 H22 hosts Then R, P1 and P2 can do explicit tracking in order to restrict sending of multicast packets, and perform fast leave etc. The point is to do it at each branching point. R won't be able to track the hosts, it may only know of P1 and P2, but that is fine. Stig >> Above "the router" means MAG acting as IGMP/MLD proxy? >> If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD >> proxy, which is no difference from the standard IGMP/MLD proxy device >> (rfc4605), and hence there is no special explanation for 6224 is >> needed in this draft, I think. > > Does 4605 talk about explicit tracking? > >> >> Or am I missing something? > > What about if the router is the LMA? > Of course LMA could be a proxy but we should consider LMA being a router as the > most likely scenario? It seems to me that in that case explicit tracking will > simply not work and all the timer tuning recommended. > > Maybe we should state that in the draft. > > > Regards, > > Behcet > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From asaeda@sfc.wide.ad.jp Thu Jun 23 02:02:16 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AD811E80B6 for ; Thu, 23 Jun 2011 02:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RWKRN+UD1Sc for ; Thu, 23 Jun 2011 02:02:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 819A311E807D for ; Thu, 23 Jun 2011 02:02:15 -0700 (PDT) Received: from localhost (dhcp-143-228.sfc.wide.ad.jp [203.178.143.228]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1B1EB27806D; Thu, 23 Jun 2011 18:01:42 +0900 (JST) Date: Thu, 23 Jun 2011 18:01:41 +0900 (JST) Message-Id: <20110623.180141.190368939.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4E00D8F0.2000605@venaas.com> References: <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> <494945.64841.qm@web111407.mail.gq1.yahoo.com> <4E00D8F0.2000605@venaas.com> X-Mailer: Mew version 6.3 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] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 09:02:16 -0000 Hi Stig, I'm very sorry for my late response, and thank you for your explanation. > Hi > > On 6/13/2011 7:53 AM, Behcet Sarikaya wrote: >> Hi Hitoshi, >> >>> Hi Behcet, >>> >>>> While reading Section 3 on explicit tracking, I noticed that no >>>> mention of >>> >>>> IGMP/MLD proxy architecture we have in RFC 6224 was made. >>>> >>>> I am curious as to how the explicit tracking can be performed in a >>>> proxy >>>> environment where the router only gets aggregate join messages. > > You can combine proxying and explicit tracking. If you have say a > topology like this: > > R router > / \ > P1 P2 proxies > / \ | \ > H11 H12 H21 H22 hosts > > Then R, P1 and P2 can do explicit tracking in order to restrict > sending of multicast packets, and perform fast leave etc. The point is > to do it at each branching point. R won't be able to track the hosts, > it may only know of P1 and P2, but that is fine. > > Stig Right. The explicit tracking function cooperates with IGMP/MLD. So, whether LMA acts as a router or proxy, if LMA has adjacent downstream receivers (including IGMP/MLD proxies), it maintains the downstream membership state (which might be aggregated by downstream IGMP/MLD proxies), and the explicit tracking function works fine. BTW, the following draft specifying the explicit tracking function is now proposed in PIM WG, not MBONED WG. http://tools.ietf.org/html/draft-asaeda-mboned-explicit-tracking-02 So if some of you want to follow the discussion or support this draft, please comment in PIM WG. Regards, -- Hitoshi Asaeda >>> Above "the router" means MAG acting as IGMP/MLD proxy? >>> If so, the MAG just aggregates multiple MNs join requests as IGMP/MLD >>> proxy, which is no difference from the standard IGMP/MLD proxy device >>> (rfc4605), and hence there is no special explanation for 6224 is >>> needed in this draft, I think. >> >> Does 4605 talk about explicit tracking? >> >>> >>> Or am I missing something? >> >> What about if the router is the LMA? >> Of course LMA could be a proxy but we should consider LMA being a >> router as the >> most likely scenario? It seems to me that in that case explicit >> tracking will >> simply not work and all the timer tuning recommended. >> >> Maybe we should state that in the draft. >> >> >> Regards, >> >> Behcet >> >> _______________________________________________ >> multimob mailing list >> multimob@ietf.org >> https://www.ietf.org/mailman/listinfo/multimob > > _______________________________________________ > multimob mailing list > multimob@ietf.org > https://www.ietf.org/mailman/listinfo/multimob From behcetsarikaya@yahoo.com Thu Jun 23 09:03:50 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F111E80D8 for ; Thu, 23 Jun 2011 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxjnfT0PBlyO for ; Thu, 23 Jun 2011 09:03:49 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id C1DC111E80B2 for ; Thu, 23 Jun 2011 09:03:49 -0700 (PDT) Received: from [98.139.91.69] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:03:49 -0000 Received: from [98.139.91.24] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:03:49 -0000 Received: from [127.0.0.1] by omp1024.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:03:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 725582.45781.bm@omp1024.mail.sp2.yahoo.com Received: (qmail 71594 invoked by uid 60001); 23 Jun 2011 16:03:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308845029; bh=b58hHsNOwSs2JaVRlDysywSJK8+IAKL6lhUN6vgXjcU=; 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=pBXGko6hFxvm1dkJeBVpzjS1aiUF7m8F5r9D81Ci5dj6LrgErm1mlYuY9g9sclt/zPJN+RuAZDRTw69fnAvAU1sayuCVzNVjEDkIK/8LbTbkOCOnfLPd4qkw41OiNXHateXZNb+oe6k+1cKFL0QeCQtNZzEs7Ro72j9TL96d2fM= 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=dkM23nGfMlyxWHlm/3vuvMXnlLLMAsLiT9WFOWXyTOIGP6V7e6kSCAoWIYTszijh0D3f/ij66+CzDmTP4i8irqWpk04PUbIQ/X4CfhqcKY7UtsYe2xdhI1gB4LYrFyoFX7jLdhE5K5Ou/AoGTXIjYlHI+SpS3LuHOX+FGo2Ld6M=; Message-ID: <214287.70743.qm@web111401.mail.gq1.yahoo.com> X-YMail-OSG: ZafGOncVM1l9qk8ZV41yBBWlHmLjjq92RxuvQ10rZcHrA0q 5L8aT5BBad1B4I7pVTjzXdNKnITsORnpCFr0cJh8JQ58pkTx3dlq.L3HgOv7 3S3dMTH2f.DNp0DgQWBn75vkY_86kTX94etDrdX6kOCxnmmfY14iQvmWibbJ 6FpUZqNplEKPJO2tdeSIrKvU4RkOgdH__rBbdQ5UW7J8u0Mk8EgmIsbwguKT oiUB7XQdKEHvD.xnG7vCQ9CEEY1adKI.JkloR_0yU6zL7yLbyJBktKNoygxn BWrMlH6PclUb3rkjQO8j3yh7.f9FoZjZhFxlsVhiF5OejjlGxaEZCc5CTeO5 LGdmm8zsY2mIj0Qy3q7IMouHEQivNOa6x0hhh7k3EQTknX.qzgLSOog_IgpG 4fR6bUkqOgkUUKg-- Received: from [206.16.17.212] by web111401.mail.gq1.yahoo.com via HTTP; Thu, 23 Jun 2011 09:03:48 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.111.304355 References: <20110611.163956.64812121.asaeda@sfc.wide.ad.jp> <494945.64841.qm@web111407.mail.gq1.yahoo.com> <4E00D8F0.2000605@venaas.com> <20110623.180141.190368939.asaeda@sfc.wide.ad.jp> Date: Thu, 23 Jun 2011 09:03:48 -0700 (PDT) From: Behcet Sarikaya To: Hitoshi Asaeda , stig@venaas.com In-Reply-To: <20110623.180141.190368939.asaeda@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: multimob@ietf.org Subject: Re: [multimob] Comments on draft-ietf-multimob-igmp-mld-tuning-00.txt X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 16:03:50 -0000 > Hi Stig, > > I'm very sorry for my late response, and thank you for your > explanation. > > > Hi > > > > On 6/13/2011 7:53 AM, Behcet Sarikaya wrote: > >> Hi Hitoshi, > >> > >>> Hi Behcet, > >>> > >>>> While reading Section 3 on explicit tracking, I noticed that no > >>>> mention of > >>> > >>>> IGMP/MLD proxy architecture we have in RFC 6224 was made. > >>>> > >>>> I am curious as to how the explicit tracking can be performed in a > >>>> proxy > >>>> environment where the router only gets aggregate join messages. > > > > You can combine proxying and explicit tracking. If you have say a > > topology like this: > > > > R router > > / \ > > P1 P2 proxies > > / \ | \ > > H11 H12 H21 H22 hosts > > > > Then R, P1 and P2 can do explicit tracking in order to restrict > > sending of multicast packets, and perform fast leave etc. The point is > > to do it at each branching point. R won't be able to track the hosts, > > it may only know of P1 and P2, but that is fine. > > > > Stig > > Right. > > The explicit tracking function cooperates with IGMP/MLD. So, whether > LMA acts as a router or proxy, if LMA has adjacent downstream > receivers (including IGMP/MLD proxies), it maintains the downstream > membership state (which might be aggregated by downstream IGMP/MLD > proxies), and the explicit tracking function works fine. We have use cases for explicit tracking both at the router (for Mobile IPv6 architecture) and at the proxy (for PMIPv6 architecture). I suggest that you add some text to clarify these two use cases in the draft. Also those issues that Thomas raised. Regards, Behcet From behcetsarikaya@yahoo.com Thu Jun 23 16:05:22 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5006D11E81A0 for ; Thu, 23 Jun 2011 16:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNVTvX3EZGGa for ; Thu, 23 Jun 2011 16:05:21 -0700 (PDT) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by ietfa.amsl.com (Postfix) with SMTP id DA52411E819D for ; Thu, 23 Jun 2011 16:05:21 -0700 (PDT) Received: from [98.139.91.69] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 23:05:18 -0000 Received: from [98.139.91.5] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 23:05:18 -0000 Received: from [127.0.0.1] by omp1005.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 23:05:18 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 894522.48447.bm@omp1005.mail.sp2.yahoo.com Received: (qmail 70652 invoked by uid 60001); 23 Jun 2011 23:05:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308870318; bh=nBWaYFAOUDlTz2zATmQa+okG/svO2JuTQ35AEUGJRk8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Di5IRi6Btzqsv0tF4SuOgr3CuUT5xiseZYVHzg906pDul2EOpIXX+sxKUGadbM5qQpJhFQTZcsfwtx2rBx/fN2FySZYQOnMQFr8PTdlKv6kmFGfPqPLS0N+lYCNM4usK04cS3uAT8RR7hx27DoF9Nndgp9YES5rbL+XPdvQhCys= 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=VwPXwcr4gl0lv5yQfj636VlNqeMWbLH0BfRYsxBPjbVDT8RsozXajLHpFMmkAJ3XVusGRxwuQR+Rt2BDdPbAOB9WNuvDy+NuvEnywLxRQ3XAPYP3xfAXCHDEKzPzEklq2wW/M2N1PedpVDr4mhJgmJIX1uuAyjWMWVBuCsRWnNk=; Message-ID: <377296.27701.qm@web111413.mail.gq1.yahoo.com> X-YMail-OSG: VTn8NzgVM1k.9EmbvAeprTu8qUmlIpIcLVgjdcON02GRg38 jTMYms_ZDnNha8rCAIfWJ7Hje9Ro_hAEjSFajnw_3lGk5hVpqFP38gWAOF0z jR4D7SRl7eTG4D1jtcvH32UOFUZUDDib8kKiBGezUM6ibQQEFNISC5..xdPL 8CzxRd3RGUKCEIgP3Dnvqk2xKDDJ9VWATjULdxBhIm9C7fI83ia0jd0O5tVr .2Zt0ZOMRDo7my4_RPWctKEkAoQjeUUCwlMf_WXl1168Ie7Qt2lvLATkTyor KiZ_Zuu.EfpvldwxH4lLfSdeys3Gh26NUqU73fk396qpkKNRTwCYMvhMJumf gfkybqtakWVcQKNycguY.Y.SlkVzuR_xRmLqX8rMqxSOxhcMQonjy4ahosFb 3E.VPpaQtXHJ7 Received: from [206.16.17.212] by web111413.mail.gq1.yahoo.com via HTTP; Thu, 23 Jun 2011 16:05:18 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.111.304355 Date: Thu, 23 Jun 2011 16:05:18 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Multimob session in Quebec City X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 23 Jun 2011 23:05:22 -0000 Hi Folks, We have a session allocated as follows: Monday, Morning Session I 0900-1130 Room Name: 204 B Please send your session requests to the chairs. Regards, Behcet From behcetsarikaya@yahoo.com Thu Jun 30 08:36:16 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803F511E807E for ; Thu, 30 Jun 2011 08:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6EeJUgX8+VT for ; Thu, 30 Jun 2011 08:36:15 -0700 (PDT) Received: from nm3-vm1.bullet.mail.sp2.yahoo.com (nm3-vm1.bullet.mail.sp2.yahoo.com [98.139.90.231]) by ietfa.amsl.com (Postfix) with SMTP id 681D511E8166 for ; Thu, 30 Jun 2011 08:35:45 -0700 (PDT) Received: from [98.139.91.62] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jun 2011 15:35:41 -0000 Received: from [98.139.91.26] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 30 Jun 2011 15:35:41 -0000 Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 30 Jun 2011 15:35:41 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 951945.171.bm@omp1026.mail.sp2.yahoo.com Received: (qmail 75376 invoked by uid 60001); 30 Jun 2011 15:35:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309448140; bh=gvwP/KEt6K+wfJSu4VUEEVMG8hTXc24F0ZUW8nrZx5E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=WVlOTDF3GT/1Em1UWW/+qFLAyOMWuPjbQnuaR9ujp3ySzfatBsiJ3GvKXVLyQDNQo/lBhBbKHtpUbZX+XlZMZ0tvOWC5GCZUyqgcmIGgL0tZaA2DZfm9g0W8pSWexhGx/33tQntPIq/qK8V4HfrWPcxk01xzOqm9egcA3/FBHkQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=M3qarHuDUgK5CuXmU2A12TJDiY3NX8ukeMqP4cbzjQez1r9k4w+D1cmO1nLAZC05fP4VrI2PmhgU4SI2tSDejhFQtDuETHmjAEDM/L6l58l5qCRqZkqgl+cUdCJH04cMD+xnJAXGfqLxY5N3j4uotkhxAMG73s24IluOPZ/K3KM=; X-YMail-OSG: 6RBXNesVM1lJpJ7lpk1eIPZgzQsfe_sy72s1b1yekLQ.FYz PR4UzjE9JhJzjToZSkyNI68GAQ4mFTSsXWnmCnU6jYMmIa7bz2L5TmVG48pM EDEoZHsmGZK6xnZHzRCSNnCQCwHJhxqxd4xsKaxXvlMiVuwnCYIArasBS0rs KzdSH9q7Prd_4PW5Hbex7eHB4R.L3e630t4AWFEuteAwQHeGc2MkpvKivdSs WkR7BUfxWWQpXfBTzw_mfghuzDlc7VBnYS66I_vZwxgzxWwSTDHWsLXY3fJ3 OM3TmC.ng2ZvQxQ7F.TKjT.4AYjNtbFVwpcTuSxPn1jdiWN.zClI1n20jsyX vQBJDdM9RD1_vfMSWSWfOuVBL_dviiMMVYgngFuV7qbXvxQJOUbObE.SYpFi _.dcEmuJXDtFCIw-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Thu, 30 Jun 2011 08:35:40 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <4D91F335.40709@informatik.haw-hamburg.de> <4D95988A.9060703@informatik.haw-hamburg.de> Message-ID: <1309448140.75241.YahooMailRC@web111408.mail.gq1.yahoo.com> Date: Thu, 30 Jun 2011 08:35:40 -0700 (PDT) From: Behcet Sarikaya To: multimob@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jun 2011 15:36:16 -0000 Hi all, Let us get back to this thread and continue to discuss the issues involved on the solutions for tunnel convergence problem. Currently we have two proposals (somewhat quoting from Thomas' email) - direct routing (just enable multicast forwarding on MAGs assuming MAGs are in the local multicast cloud) - home tunneling (just perform multicast subscription to one LMA/Multicast DR called M-LMA). What are the issues? (again quoting Thomas) * the two operations are mixed * MN moves between PMIP-domains. To me the issue is separating unicast and multicast flow paths from the MAG-LMA that we have in the base solution. Can we have a solution that is faithful to the base solution and solves all the problems? Is such a design feasible? worth looking into? I am saying this because Mobile IPv6 spec says that if you have multicast locally available which corresponds to the local routing solution we have, go and use it and does not elaborate much. Regards, Behcet > >Hi, Thomas, > >Thanks for your useful comment. > >Please see below "Seil" > > > >2011/4/1 Thomas C. Schmidt > >Hi Luis, Seil, >> >>some additional remarks marked by [thomas] >> >> >>On 31.03.2011 23:03, Luis M. Contreras wrote: >> >>Hi Seil, >>>more discussion below: >>> >>> "Seil" => You don't see the benefit. why? ISPs are now making a >>> pitch for building and getting their own contents from public >>> broadcasters, cable broadcasters, ... so on. Obiviously, this is >>> inevitable trend to achieve competiveness from other ISPs. That will >>> be getting serious more than now. And as I presented in my >>> slot, this concept is reflected at MBMS architecture of 3GPP SAE. >>> Only appropriate manner needs to be handled between home and visited >>> network. About that, the draft will be updated. >>> In M-LMA, how about local contents? >>> >>>Luis>> It is just my personal view in this interesting and necessary >>>debate opened byThomas. I would like to distinguish two concepts: remote >>>content distributed locally, and local content distributed locally. In >>>the first case, I don't see the benefit. I think that the simplest way >>>to deliver the service is through M-LMA. In the second case, I agree >>>that it seems more optimal to use direct routing. But, in my opinion, >>>the direct routing can not be consider as the main solution, but an >>>ocassional optimization scenario in case the content is local to the >>>visited domain (probably the most common is that a MN usually will >>>demand contents from its Home Network, because the user maintains a >>>service contract its Home Operator). I think it is the same idea than in >>>the unicast case regarding the routing optimization: it is an >>>optimization case for a more general solution (which I believe it is the >>>M-LMA approach). >>> >>> >[thomas] The problem with direct routing as a "general solution" is that it is >unrealistic to assume all multicast traffic, which is globally available, is >routed directly into an access network of an operator. This will most likely >only be the case for content streams the operator is willing to offer to its >customers, e.g., selected IPTV channels ... So relying purely on the direct >routing might end up with a poor choice of content services, in particular with >changing offers between access network operators. >> >>However, the benefit of local routing in the "remote content distributed >>locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Stream >>...) guides the content into its access network and then simply turns on >>multicast routing (this is what wired operators do today). This will result in >>full scaling, no tunnels or extra boxes involved and at least optimizes Capex, >>but typically Opex, as well (depending on Mcast route management brains). >> >>The M-LMA, as mentioned many times, is an extra box that needs to handle all >>streams simultaneously and redistribute them via tunnels. This leads to a >>scaling bottleneck, traffic multiplication in the access network (including >>waste of bandwidth) and efforts in semi-manual configurations ... "Seil" => I agree this comment as my response to Luis's comment in previous mail. As I mentioned in previous comment, this is serious issue. In my opinion, it might be an instance of the biter getting bitten. * Coexistence of home/remote content retrieval (e.g., by the base >> solution) and access from local multicast routing. Thus a MAG would >> need to distinguish (preconfigured) local group subscriptions from >> non-local content. >> >> Luis>> This is not possible with current functionality on MAG as >> MLD proxy. It is only possible to define one upstream interface, >> so the operator would be forced to permanently choose between >> local or remote multicast for all kind of traffic. >> >> "Seil" => Yes, it's possible. Only one upstream interface is >> available but "per single MLD proxy instance". So, the choice will >> not be forced to operators. >> >>Luis>> I don't think so. According to base solution, the MN is >>associated to an MLD proxy instance as a function of the LMA it is bound >>to. That is, the association to an MLD instance is previous to the MLD >>Report processing. So, the MAG doesn't know the required content (local >>or remote) before associating the MN to a proxy instance. As >>consequence, the operator is forced to choose between using an MLD proxy >>pointing to the M-LMA or another one pointing to local MR for all kind >>of traffic, and for all the MNs associated to the same LMA. >> >> [Thomas] In my understanding, Luis is correct here. Upstream interfaces of RFC4605 MLD proxies cannot distinguish between different groups. For one downstream interface you always need to have one single proxy instance and this instance only can have one upstream interface. As the downstream interface corresponds to a link with an MN, this MN can either receive local or remote content. > >This is not what we want: we want to distinguish traffic per group, not per >host. So I guess, a solution for this scenario is not possible using a standard >MLD proxy function. It is of course easy to achieve by making MAGs PIM (SM or >BIDIR) routers and configuring RPs per group(-range). > > "Seil" => Considering the structure where several sources connect to an MAG, it could be a good candidate. Best wishes, > > >Thomas From I.Romdhani@napier.ac.uk Thu Jun 30 09:07:45 2011 Return-Path: X-Original-To: multimob@ietfa.amsl.com Delivered-To: multimob@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0155011E8215 for ; Thu, 30 Jun 2011 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPd7THMEDuu4 for ; Thu, 30 Jun 2011 09:07:42 -0700 (PDT) Received: from CH1EHSOBE006.bigfish.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D211E8210 for ; Thu, 30 Jun 2011 09:07:42 -0700 (PDT) Received: from mail168-ch1-R.bigfish.com (216.32.181.173) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.22; Thu, 30 Jun 2011 16:07:41 +0000 Received: from mail168-ch1 (localhost.localdomain [127.0.0.1]) by mail168-ch1-R.bigfish.com (Postfix) with ESMTP id BD7D1230194; Thu, 30 Jun 2011 16:07:41 +0000 (UTC) X-SpamScore: -53 X-BigFish: VPS-53(zzbb2dK1be0L542M1418M1432N98dK14ffOzz1202hzz1033IL8275dhz2fh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:146.176.222.88; KIP:(null); UIP:(null); IPVD:NLI; H:mer-hub-1.napier-mail.napier.ac.uk; RD:mer-hub-1.napier-mail.napier.ac.uk; EFVD:NLI Received-SPF: pass (mail168-ch1: domain of napier.ac.uk designates 146.176.222.88 as permitted sender) client-ip=146.176.222.88; envelope-from=I.Romdhani@napier.ac.uk; helo=mer-hub-1.napier-mail.napier.ac.uk ; napier.ac.uk ; Received: from mail168-ch1 (localhost.localdomain [127.0.0.1]) by mail168-ch1 (MessageSwitch) id 1309450061410203_24073; Thu, 30 Jun 2011 16:07:41 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail168-ch1.bigfish.com (Postfix) with ESMTP id 3EEED109004B; Thu, 30 Jun 2011 16:07:41 +0000 (UTC) Received: from mer-hub-1.napier-mail.napier.ac.uk (146.176.222.88) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.22; Thu, 30 Jun 2011 16:07:35 +0000 Received: from E2K7MBX.napier-mail.napier.ac.uk ([146.176.250.56]) by mer-hub-1.napier-mail.napier.ac.uk ([146.176.222.88]) with mapi; Thu, 30 Jun 2011 17:07:34 +0100 From: "Romdhani, Imed" To: Behcet Sarikaya , "multimob@ietf.org" Date: Thu, 30 Jun 2011 17:07:28 +0100 Thread-Topic: [multimob] Thoughts on PMIP Optimized Routing Thread-Index: Acw3PA04sQZtAlh6Q+6k/TItL5fbEgAAhCEw Message-ID: <78F1C759D89E1C44A6DD4C06B9A4B270C39A70E274@E2K7MBX.napier-mail.napier.ac.uk> References: <4D91F335.40709@informatik.haw-hamburg.de> <4D95988A.9060703@informatik.haw-hamburg.de> <1309448140.75241.YahooMailRC@web111408.mail.gq1.yahoo.com> In-Reply-To: <1309448140.75241.YahooMailRC@web111408.mail.gq1.yahoo.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: napier.ac.uk Subject: Re: [multimob] Thoughts on PMIP Optimized Routing X-BeenThere: multimob@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Mobility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 16:07:45 -0000 Dear all, In my opinion, there is no optimal solution to this problem as it depends o= n several constraints: - The location of the multicast source (Within the home network or elsewher= e); - The scope of distribution; - The location of the HA or equivalent entity in the home network (closenes= s to Ingress router); - The number and the mobility pattern of the mobile receivers; - and the availability and the accessibility of the same multicast service = in visited networks. Even inside the home network, when the home subscription method is used and= both the source and the receivers are located outside, we may have a dupli= cation of tunnels snaking within the home domain and carrying the same cont= ent towards remote mobile receivers. These tunnels may take the same route = or different routes. In other words, the multicast traffic enters natively = the home domain (down to the HA or equivalent) and leaves in tunnel mode (f= rom the same or different egress points) the home domain to the receivers. So, we may just limit our work by making some suggestions how to improve ea= ch specific scenario. Kind regards, Imed = -----Original Message----- From: multimob-bounces@ietf.org [mailto:multimob-bounces@ietf.org] On Behal= f Of Behcet Sarikaya Sent: 30 June 2011 16:36 To: multimob@ietf.org Subject: [multimob] Thoughts on PMIP Optimized Routing Hi all, Let us get back to this thread and continue to discuss the issues involve= d on = the solutions for tunnel convergence problem. Currently we have two proposals (somewhat quoting from Thomas' email) - direct routing (just enable multicast forwarding on MAGs = assuming MAGs are in the local multicast cloud) = - home tunneling (just = perform multicast subscription to one LMA/Multicast DR called M-LMA). What are the issues? (again quoting Thomas) * the two operations are mixed * MN moves between PMIP-domains. To me the issue is separating unicast and multicast flow paths from the MAG= -LMA = that we have in the base solution. Can we have a solution that is faithful to the base solution and solves all= the = problems? Is such a design feasible? worth looking into? I am saying this because Mobile IPv6 spec says that if you have multicast = locally available which corresponds to the local routing solution we have, = go = and use it and does not elaborate much. Regards, Behcet > >Hi, Thomas, > = >Thanks for your useful comment. > = >Please see below "Seil" > > > = >2011/4/1 Thomas C. Schmidt > >Hi Luis, Seil, >> >>some additional remarks marked by [thomas] = >> >> >>On 31.03.2011 23:03, Luis M. Contreras wrote: >> >>Hi Seil, >>>more discussion below: >>> >>> "Seil" =3D> You don't see the benefit. why? ISPs are now making a >>> pitch for building and getting their own contents from public >>> broadcasters, cable broadcasters, ... so on. Obiviously, this is >>> inevitable trend to achieve competiveness from other ISPs. That will >>> be getting serious more than now. And as I presented in my >>> slot, this concept is reflected at MBMS architecture of 3GPP SAE. >>> Only appropriate manner needs to be handled between home and visited >>> network. About that, the draft will be updated. >>> In M-LMA, how about local contents? >>> >>>Luis>> It is just my personal view in this interesting and necessary >>>debate opened byThomas. I would like to distinguish two concepts: remote= >>>content distributed locally, and local content distributed locally. In >>>the first case, I don't see the benefit. I think that the simplest way >>>to deliver the service is through M-LMA. In the second case, I agree >>>that it seems more optimal to use direct routing. But, in my opinion, >>>the direct routing can not be consider as the main solution, but an >>>ocassional optimization scenario in case the content is local to the >>>visited domain (probably the most common is that a MN usually will >>>demand contents from its Home Network, because the user maintains a >>>service contract its Home Operator). I think it is the same idea than in= >>>the unicast case regarding the routing optimization: it is an >>>optimization case for a more general solution (which I believe it is the= >>>M-LMA approach). >>> >>> >[thomas] The problem with direct routing as a "general solution" is that i= t is = >unrealistic to assume all multicast traffic, which is globally available, = is = >routed directly into an access network of an operator. This will most like= ly = >only be the case for content streams the operator is willing to offer to i= ts = >customers, e.g., selected IPTV channels ... So relying purely on the direc= t = >routing might end up with a poor choice of content services, in particular= with = >changing offers between access network operators. >> >>However, the benefit of local routing in the "remote content distributed = >>locally"-scenario seems obvious to me: The operator somehow (CDN, PtP-Str= eam = >>...) guides the content into its access network and then simply turns on = >>multicast routing (this is what wired operators do today). This will resu= lt in = >>full scaling, no tunnels or extra boxes involved and at least optimizes C= apex, = >>but typically Opex, as well (depending on Mcast route management brains).= >> >>The M-LMA, as mentioned many times, is an extra box that needs to handle = all = >>streams simultaneously and redistribute them via tunnels. This leads to a= = >>scaling bottleneck, traffic multiplication in the access network (includi= ng = >>waste of bandwidth) and efforts in semi-manual configurations ... = = "Seil" =3D> I agree this comment as my response to Luis's comment in previo= us = mail. As I mentioned in previous comment, this is serious issue. In my opin= ion, = it might be an instance of the biter getting bitten. = = * Coexistence of home/remote content retrieval (e.g., by the base >> solution) and access from local multicast routing. Thus a MAG would >> need to distinguish (preconfigured) local group subscriptions from >> non-local content. >> >> Luis>> This is not possible with current functionality on MAG as >> MLD proxy. It is only possible to define one upstream interface, >> so the operator would be forced to permanently choose between >> local or remote multicast for all kind of traffic. >> >> "Seil" =3D> Yes, it's possible. Only one upstream interface is >> available but "per single MLD proxy instance". So, the choice will >> not be forced to operators. >> >>Luis>> I don't think so. According to base solution, the MN is >>associated to an MLD proxy instance as a function of the LMA it is bound >>to. That is, the association to an MLD instance is previous to the MLD >>Report processing. So, the MAG doesn't know the required content (local >>or remote) before associating the MN to a proxy instance. As >>consequence, the operator is forced to choose between using an MLD proxy >>pointing to the M-LMA or another one pointing to local MR for all kind >>of traffic, and for all the MNs associated to the same LMA. >> >> [Thomas] In my understanding, Luis is correct here. Upstream interfaces of = RFC4605 MLD proxies cannot distinguish between different groups. For one = downstream interface you always need to have one single proxy instance and = this = instance only can have one upstream interface. As the downstream interface = corresponds to a link with an MN, this MN can either receive local or remot= e = content. > >This is not what we want: we want to distinguish traffic per group, not pe= r = >host. So I guess, a solution for this scenario is not possible using a sta= ndard = >MLD proxy function. It is of course easy to achieve by making MAGs PIM (SM= or = >BIDIR) routers and configuring RPs per group(-range). > > = "Seil" =3D> Considering the structure where several sources connect to an M= AG, = it could be a good candidate. = = = Best wishes, = > > >Thomas _______________________________________________ multimob mailing list multimob@ietf.org https://www.ietf.org/mailman/listinfo/multimob Edinburgh Napier University is Edinburgh's top university for graduate empl= oyability (HESA 2010), and proud winner of the Queen's Anniversary Prize fo= r Higher and Further Education 2009, awarded for innovative housing constru= ction 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 Univ= ersity without the permission of the sender. It is your responsibility to e= nsure that this message and any attachments are scanned for viruses or othe= r defects. = 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 e= ntering the University's system is subject to routine monitoring and filter= ing by the University. = Edinburgh Napier University is a registered Scottish charity. Registration number SC018373